Thanks for confirming this! It looks like we do need to put all symbols from head.o before any other symbols. To be clear, the patch I mentioned was not trying to do that -- it just makes sure the _stext is in the right places. I'll draft a patch for this. On Sun, Nov 24, 2024 at 12:40 PM Chris Packham <Chris.Packham@xxxxxxxxxxxxxxxxxxx> wrote: > > Hi Rong, > > On 22/11/24 18:02, Rong Xu wrote: > > Does the following patch fix your issue? > > https://lore.kernel.org/lkml/CAK7LNAQSpM2hh2=Wgribb92nHF5_peRb+gxdO1Bt1MkeL8N+hw@xxxxxxxxxxxxxx/t/ > > > > Masahiro Yamada already applied the patch to kbuild-tree. > > > > I also proposed a similar fix as yours. But we believe the above patch > > should also work (and probably is better). > > > > Please try and let us know. > > Looks like linux-next already has that patch and no it doesn't fix my > issue. For the record here's the start of my System.map > > $ head System.map > ffffffff80100000 T __split_text_end > ffffffff80100000 T __split_text_start > ffffffff80100000 T __unlikely_text_start > ffffffff80100000 T _stext > ffffffff80100000 T _text > ffffffff80100000 t run_init_process > ffffffff80100138 t try_to_run_init_process > ffffffff8010018c t put_page > ffffffff801001d0 t nr_blocks.isra.0 > ffffffff80100208 T ack_bad_irq > > It does look like whatever is supposed to put head.o first isn't kicking > in for me. > > > > > Thanks! > > > > -Rong > > > > On Thu, Nov 21, 2024 at 6:29 PM Chris Packham > > <chris.packham@xxxxxxxxxxxxxxxxxxx> wrote: > >> > >> On 22/11/24 14:58, Chris Packham wrote: > >>> Hi Rong, > >>> > >>> I was just trying some of my in-flight changes against linux-next and > >>> found that my RTL9300* based board no longer boots (nothing on the > >>> serial console after U-Boot hands off to the kernel). > >>> > >>> A bisect between Linus's tree and linux-next/master points to commit > >>> d4a7f2510ff4 ("vmlinux.lds.h: Adjust symbol ordering in text output > >>> section"). A build on d4a7f2510ff4^ boots successfully. That series is > >>> well beyond my area of knowledge, there may be something that the MIPS > >>> SoCs are doing (or not doing) that is being affected by the sections > >>> moving. > >> Based on the sparc change that accompanied this commit the following > >> does seem to restore working order for me: > >> > >> diff --git a/arch/mips/kernel/vmlinux.lds.S b/arch/mips/kernel/vmlinux.lds.S > >> index d575f945d422..e90b0f68290c 100644 > >> --- a/arch/mips/kernel/vmlinux.lds.S > >> +++ b/arch/mips/kernel/vmlinux.lds.S > >> @@ -62,6 +62,8 @@ SECTIONS > >> _text = .; /* Text and read-only data */ > >> _stext = .; > >> .text : { > >> + /* Match text section symbols in head.S first */ > >> + *head.o(.text) > >> TEXT_TEXT > >> SCHED_TEXT > >> LOCK_TEXT > >> > >> No idea if that's appropriate > >>
