[U-Boot-Users] Calling a kernel from a mini-bootloader

[Guillaume Dargaud <dargaud@lpsc.in2p3.fr>]

Hello all,
this question is a bit off-topic since I looked at using U-Boot but 
eventually wrote a simpler bootloader myself. Anyway, my experience with 
bootloader is limited to say the least.

The direct questions are at the end of this lengthy post (sorry), but here's 
some background first:

I have a working Linux kernel and a working bootloader... but not when the 
latter calls the former.

Case in point:
- load zImage.elf to DRAM 0x400000 with JTAG debugger. Run it. It runs fine.

- Load Bootloader.elf to BRAM 0xFFFF0000 with JTAG debugger. Run it. It runs 
fine (but it doesn't do much yet).

- Now load both of the previous ones, and have the bootloader perform a jump 
to kernel:
void main() {
     typedef void tFunc(void);
     ((tFunc *)0x400000)();
}

Now if the bootloader _only_ contains the above code, the kernel runs
perfectly.
Unfortunately I need to do some things in the bootloader: I use 6 GPIOs to 
control, among other things, a frontal set of LEDs, a card ID number and a 
serial flash memory. Those operations work. But here is the strange thing 
that leads me to believe there are interrupt 'interferences'.

If I just read from a GPIO before launching the kernel, it boots fine, with
a few NFS errors when mounting the rootnfs:
[    4.360060] Freeing unused kernel memory: 76k init
[   11.432269] nfs: server 192.168.1.185 not responding, still trying
[   11.441186] nfs: server 192.168.1.185 OK
init started: BusyBox v1.10.1 (2008-04-24 12:26:38 CEST)
genepy login:

Now if I also write to a 2nd GPIO, I get a lot more NFS errors.

And if I also access the flash through the 3rd GPIO, the kernel hangs:

> loaded at:     00400000 004EA19C
> board data at: 004E8120 004E819C
> relocated to:  0040405C 004040D8
> zimage at:     00404E48 004E7A7E
> avail ram:     004EB000 08000000
>
> Linux/PPC load: console=ttyUL0,115200 rw root=/dev/nfs ip=bootp
> Uncompressing Linux...done.
> Now booting the kernel

But then it hangs for exactly 3 minutes, nothing on the serial port, before 
the bootloader restarts.
Why should the behavior be different whether it's started from the debugger 
or from my bootloader ?

Now I've defined my hardware project [based on Xilinx ML405 card 
architecture] using interrupts on the GPIOs, which I don't need and frankly 
they don't make sense for an output GPIO. I would like to try to compile a 
kernel without GPIO interrupts, unfortunately the compilation fails:

$ make ARCH=ppc CROSS_COMPILE=powerpc-linux-uclibc-
[...]
  CC      arch/ppc/syslib/virtex_devices.o
arch/ppc/syslib/virtex_devices.c:535: error: 'XPAR_INTC_0_GPIO_0_VEC_ID'
undeclared here (not in a function)

Question breakdown:
- do I need interrupts for GPIOs ?
- how can I compile the ppc 2.6.25 kernel without them ?
- Why do I have problems running the kernel if the bootloader makes use of
the GPIOs ?
- does the bootloader need to perform some kind of special cleanup before
calling the kernel ?

Thanks a lot for shedding a light on those mysteries.
-- 
Guillaume Dargaud
http://www.gdargaud.net/
  "Programming is like sex: one mistake and you're providing support for a 
lifetime."    - Michael Sinz.