Kernel 2.6.24, binutils-2.18, and tftplilo on diskless MVME167.

[Stephen N Chivers <schivers@csc.com.au>]

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

This adds two three new program header of type load and note, the last
three in this 'readelf'
dump of vmlinux:

      Type           Offset   VirtAddr   PhysAddr   FileSiz MemSiz  Flg
Align
      LOAD           0x000000 0x00000000 0x00000000 0x21b4c0 0x2564b8 RWE
0x2000
      LOAD           0x21c4c0 0x002564c0 0x002564c0 0x15b40 0x15b40 RWE
0x2000
      LOAD           0x233000 0x00001000 0x00001000 0x21a4c0 0x2554b8 R E
0x2000
      LOAD           0x44e4c0 0x002564c0 0x002564c0 0x15b40 0x15b40 RWE
0x2000
      NOTE           0x3ddc88 0x001abc88 0x001abc88 0x6f838 0xa9614
0x10

The kernel builds and links but tftplilo fails to load it claiming:

      Unsupported backward seek in module gunzip (x, y)

      Failed to seek to kernel segment 3

The third kernel segment has virtAddr and PhysAddr less than that of the
preceding segment.
I think that is the original of the tftplilo diagnostic. To work around
that problem I removed the
two new LOAD program headers from vmlinux-std.lds and left the NOTE header.
The kernel still failed to load using tftplilo and this can be traced to
that programs failure to
ignore program headers whose type is not LOAD. I rebuilt tftplilo and could
load the new kernel
but it behaved as before apparently stopping after emitting 'ABCGHIJK' on
the console.

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.
The lack of diagnostics is due to fact that when the BUG_ON assertion fails
console IO has
not been set up and so the kernel traces will not appear but the processor
will appear to halt.

After disabling just this test I now have a 2.6.24 kernel that boots and
operates on a MVME167.
without disks.

Stephen Chivers,
CSC Australia, Pty. Ltd.