(GTA02, u-boot) better handling of vectors

Werner Almesberger werner at openmoko.org
Tue Mar 25 22:27:03 CET 2008


In GTA02 we have the issue that the item that's visible at address zero
(and a few kB following it) depends on whether the AUX button is pressed
or not: if it's not pressed, SteppingStone, a RAM buffer used when
booting from NAND is at address 0. If AUX is pressed, the NOR appears
there.

Alas, the state of AUX isn't sampled only at reset time, but each time
AUX is pressed or released, the content of address 0 changes. One of
the items that live at that address are the interrupt/exception/etc.
vectors.

Needless to say, when we boot from NOR, and then release AUX, the next
interrupt that happens will be very unhappy if it finds the random or
arbitrary content of SteppingStone there. Similarly, if an interrupt
occurs while we're running u-boot from NAND, and we just happen to hold
AUX, the vectors from NOR will probably not be entirely right.
(Although they may be very similar, since it's u-boot both times.)

One way to cause an interrupt is to connect USB. That's how this
problem was discovered.

The problem doesn't exist when running Linux, because Linux sets up the
MMU and maps the vectors to a safe address.

A while ago, I added a simple bit of logic to u-boot that would make it
wait until AUX is released (so the NOR disappears and SteppingStone
takes its place), then copy the vectors into SteppingStone, and only
then enable interrupts.

This solved the problem for NOR, but made the procedure for invoking
the boot menu fairly awkward. Also, it didn't to anything for NAND
(where this issue is admittedly less critical).

I've now made a cleaner solution that maps the address area 0x0... to
0x3..., where we're safe from the effects of AUX. This is done using a
"cheap" mapping hack in the MMU that's there for Windows CE. Thanks,
Microsoft, your hack saved me from having to set up the full MMU ! ;-)

I've given this some light testing, and it seems to work quite well.
When testing booting from NOR, I recommend to
nand erase u-boot
and then try to boot u-boot from NAND, to make sure that SteppingStone
really doesn't contain any valid data.

With this change, the invocation sequences are as follows: (*)

- Boot Linux directly from NAND
  Press and hold POWER, release it not before the splash screen comes
  up.

- Boot u-boot from NAND, enter the boot menu
  Press and hold POWER, then press and hold AUX. Release both not before
  the splash screen or boot menu comes up.

- Boot u-boot from NOR, enter the boot menu
  Press and hold AUX, then press and hold POWER. Release POWER not before
  the splash screen or boot menu comes up. AUX can be released anytime
  after POWER was pressed.

(*) Assuming we also use wait-for-power-DONTUSE.patch, which changes
    the splash screen timing a little. Otherwise, add a couple of
    seconds before releasing POWER or AUX.

This patch obsoletes nor-irqvec.patch. There's also similar logic in
uboot-s3c2410-norelocate_irqvec_cpy.patch which we could replace as
well. However, I don't want to introduce too many changes at the
present time, so I'd rather leave that part as it is.

This is the patch (in revision 4248):
http://svn.openmoko.org/trunk/src/target/u-boot/patches/remap-vec.patch

Unless someone finds a problem with it, I'll remove nor-irqvec.patch in
a few days and replace it with remap-vec.patch

Tony, Allen, I hope this can still make it into MP. I think it'll make
booting from NOR considerably less confusing.

- Werner




More information about the openmoko-kernel mailing list