Hi Geert !
thanks a lot for the feedbacks.
On Thu, Jun 25, 2020 at 10:13 AM Geert Uytterhoeven
<geert@xxxxxxxxxxxxxx> wrote:
Hi Angelo,
Thanks for your patch!
On Thu, Jun 25, 2020 at 1:28 AM Angelo Dureghello
<angelo.dureghello@xxxxxxxxxxx> wrote:
On mcf5441x, mmu enabled, using a small initramfs, the boot was
recently hanging silently in the initial phase, inside
arch/m68k/mm/init.c, m68k_setup_node()
initrd at 0x47d2f000:0x47d82f64
overlap at 1073741889 for chunk 0
overlap at 1073746176 for chunk 0
overlap at 1073746736 for chunk 0
overlap at 1073746737 for chunk 0
overlap at 1073746738 for chunk 0
overlap at 1073746739 for chunk 0
overlap at 1073746740 for chunk 0
From some debugging, at m68k_setup_node(), the 25-bits shift value
(virt_to_node_shift) seems unset, because applied to a wrong
address (address previously set from m68k_fixup).
Tried some fixes, but the more low-risk and hopefully correct seems
to just add a volatile inside __virt_to_node_shift(). This seems to
produce correct addresses for the next fixup to work. Cannot test this
on other mmu ColdFire cpu's so every test is eventually welcome.
Signed-off-by: Angelo Dureghello <angelo.dureghello@xxxxxxxxxxx>
--- a/arch/m68k/include/asm/page_mm.h
+++ b/arch/m68k/include/asm/page_mm.h
@@ -135,7 +135,7 @@ static inline __attribute_const__ int __virt_to_node_shift(void)
{
int shift;
- asm (
+ asm volatile (
"1: moveq #0,%0\n"
m68k_fixup(%c1, 1b)
: "=d" (shift)
Perhaps we should add the volatile to the other asm statements, too?
Andreas?
I see volatile is there in other similar m68k asm code chunks,
it should not hurt.
Which compiler version are you using?
It's a toolchain i prepared up here years ago,
export CROSS_COMPILE=/opt/toolchains/m68k/gcc-5.2.0-nolibc/bin/m68k-linux-
If you have a link for a newer toolchain, happy to upgrade :)
Have you compared the difference in generated code?
With gcc version 8.4.0 (Ubuntu 8.4.0-1ubuntu1~18.04), the above makes
no difference for m68k_setup_node(), and the compiler doesn't even
optimize away the call to __virt_to_node_shift(), which is marked
__attribute_const__.
Well, i only checked the assembly by objdump in object files, right now,
at least looking the m68k_fixup section in both cases, opcodes seems ok.
with volatile:
00000000 <.m68k_fixup>:
0: 4e71 nop
...
6: R_68K_32 .init.text+0x1e
a: 4e71 nop
c: 4e71 nop
e: 0000 .short 0x0000
10: 0001 .short 0x0001
12: 0000 .short 0x0000
12: R_68K_32 .init.text+0x22 correct, points to
22: 7200 moveq #0,%d1
14: 0000 .short 0x0000
16: 4e71 nop
18: 4e71 nop
...
1e: R_68K_32 .init.text+0x46
22: 4e71 nop
without
00000000 <.m68k_fixup>:
0: 4e71 nop
2: 0000 .short 0x0000
4: 0001 .short 0x0001
6: 0000 .short 0x0000
6: R_68K_32 .init.text+0x10, corrrect, points to
10: 7200 moveq #0,%d1
8: 0000 .short 0x0000
a: 4e71 nop
c: 4e71 nop
Do you see anything strange ? Or, how can i objdump better ?
Gr{oetje,eeting}s,
Geert
Thanks, regards
angelo
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@xxxxxxxxxxxxxx
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
