On 26/11/24 07:48, Rong Xu wrote:
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.
Looking at other architectures it may just be a matter of adding __HEAD
to an appropriate place in arch/mips/kernel/head.S and HEAD_TEXT_SECTION
to arch/mips/kernel/vmlinux.lds.S. It might even be possible to drop
mips from scripts/head-object-list.txt.
I'll draft a patch for this.
I can give any patch a quick test on my setup.
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