Re: Kernel 2.6.24, binutils-2.18, and tftplilo on diskless MVME167.
On Tue, 11 Nov 2008, Stephen N Chivers wrote:
> In the past few days I have attempted to get 2.6 kernels booting on my
> diskless MVME167 boards.
> I have tried several kernels, including:
> linux-image-2.6.26-1-mvme16x_2.6.26-9_m68k.deb.
>
> None of them appear to continue beyond the initialisation code in:
>
> arch/m68k/kernel/head.S
>
> They load normally via tftplilo and commence executing, apparently stopping
> with the only
> diagnostic available at the console being the magic:
>
> ABCGHIJK
>
> In frustration, I compiled my own 2.6.24 kernel from clean source using a
> cross compilation
> system based on binutils-2.18 and gcc-4.1.2. The linking of vmlinux failed
> with the infamous:
>
> m68k-linux-gnu-ld: .tmp_vmlinux1: Not enough room for program
> headers, try linking with -N
>
> I applied the patch for vmlinux-std.lds provided by Andreas Schwab:
>
> http://marc.info/?l=linux-m68k&m=120596505621019&w=2
That patch is not in the m68k tree. It also doesn't apply anymore, as we
already have a NOTES somewhere else now.
Do you still need it on e.g. 2.6.27?
> I traced the "freeze" of the kernel to the 'BUG_ON' test in
> 'm68k_setup_user_interrupt' in file
> arch/m68k/ints.c:
>
> BUG_ON(IRQ_USER + cnt >= NR_IRQS);
>
> Now, for the VME boards, IRQ_USER is 8, cnt is 192 and NR_IRQS is 200. So
> this test will
> trigger the BUG_ON action, and so the kernel appears to stop without
> logging any diagnostics.
Oops, that looks like an off-by-one error. It has been introduced by commit
69961c375288bdab7604e0bb1c8d22999bb8a347 ("[PATCH] m68k/Atari: Interrupt
updates").
I'll fix it.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
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
Reply to: