the GTA02 NOR Flash story

[Werner Almesberger]

Hi Andy,

here's the story of our NOR Flash. The basic idea is that there has
to be a way to boot the GTA02 even if the NAND Flash is completely
hosed and you don't have a debug board.

The hardware works as follows: normally, we boot from NAND. This is
indicated by the OM[1:0] pins of the MCU, which are both pulled low.
However, if the AUX button is pressed while the system resets, it
pulls OM0 high, and this gets us to boot from NOR.

The NOR has a size of 2MB, so we could put all sorts of stuff there.
For now, it should be sufficient to have u-boot. This u-boot should
have a way to ignore the environment (which we still get from NAND).
Besides that, no special functionality is needed. I.e., it can (and
should) be identical to the u-boot we use in NAND.

If we want to do anything special in u-boot when starting from NOR,
we could use BWSCON[2:1] = OM[1:0] to detect this condition, and act
accordingly.

One possible snag may be the code in u-boot/cpu/arm920t/start.S
which hasn't been tested with NOR yet. If it needs fixing, I wish
thee luck :-) (Well, I'll help. After all, I'm responsible for a
considerable part of the messiness in there :-( )

Now, the NOR (M58WR016KB) should normally be protected against
writing by pulling VPP low. "Normally" refers to the configuration
the final device would have. So R2505 pulls down and R2506 is not
placed.

A user wishing to change the NOR content could enable writes either
by putting a 0R on R2506, or, easier, pull nNOR_WP high with the
debug v3 board. (Debug v2 can't do this.)

To ease development, our current boards have that logic reversed,
i.e., R2506 pulls up and R2505 is left open. Thus, the NOR can be
written to all the time. This write protection mechanism also still
needs to be tested. (And we should then switch permanently to the
"production" configuration.)

If we boot from NOR, it shows up at physical address 0x00000000
(GCS0).  However, this address range is occupied by the internal
boot SRAM when we boot from NAND, so the NOR is invisible.

We therefore also (whether we boot from NOR or from NAND) map it
into the physical address space at 0x18000000 (GCS3).

By the way, nWP is always pulled high. We don't use the per-page
protection since the write-protection through VPP is much more
comprehensive, and its granularity is sufficient for our needs.

(In future devices, I'd like to replace the NOR with a NAND that
has credible per-page protection, and implement the write protect
policy in software. That way, we would be more flexible when it
comes to memory space allocation, we could get rid of a comparably
large chip, and we still wouldn't require the presence of a debug
board for basic recovery.)

- Werner