[U-Boot] Chain loading an u-boot from an u-boot

[Scott Wood <scottwood@freescale.com>]

On Mon, 2014-02-10 at 13:57 +0100, Helmut Raiger wrote:
> On 02/10/2014 01:14 PM, Andreas Bie?mann wrote:
> > - we have a hardware design bug
> > - we have a few hundred i.MX31 TT-01 devices in the field
> > - the i.MX31 rom boot loader is only capable of using 1bit HW-ECC
> > (loading the first page (2k) from the NAND)
> > - the NAND chip specifies a requirement of 1bit ECC for the first 128kB
> > (PEB) and 4bit ECC for the rest
> > - our current u-boot uses 1-bit HW-ECC, the kernel uses UBIFS and 1bit
> > HW-ECC
> > D'oh!
> just about what I thought ...
> > - we face increasing bit errors in the field in the PEBs used by u-boot.
> >
> > Using UBIFS in the kernel mitigates the requirements of 4bit ECC for the
> > whole NAND because it moves
> > PEBs when bit errors show up. The real problem is the area where u-boot
> > is located (currently approx. 450kB,
> > including UBIFS, USB ethernet support and more ..).
> > I wouldn't say it is a good solution to have 1 bit ecc on NAND that
> > requires 4 bit, even though there is another layer reacting on bit
> > errors. I guess your BBT will increase significant in a very short time.
> Most operations are read (we use a separate YAFFS partition for time 
> predictable writes),
> so UBI will relocate read-only blocks anyway (due to read disturbances), 
> I think the
> effect wont be too dramatic, but don't make me proof that ;-)

This sounds like a very bad idea.

> >> So the idea was:
> >>
> >> - use a small u-boot (<128kB) in the first PEB of the NAND (written with
> >> 1bit HW-ECC) that supports 4bit BCH
> > How about using SPL here? I don't know the freescale universe but wonder
> > if SPL is fixed to 2k. Building SPL with SW BCH in less than 2k seems
> > not doable for me.
> SPL on i.MX31 is limited to 2kB so we can't use BCH 4 here, just as you 
> guessed.

You could use TPL (three stage extension of SPL).  2K SPL loads 126K
TPL, which has BCH code and can load the real U-Boot.

See doc/README.TPL, and include/configs/p1_p2_rdb_pc.h for an example.

> >> - let it load a second u-boot (<512kB) from the next 4 PEBs (written
> >> with 4bit BCH)
> >> - jump to the second u-boot and load the kernel from an UBI volume using
> >> 1bit HW-ECC again
> >>
> >> I did all that and it seemed to work just fine, but jumping to the
> >> second u-boot almost always
> >> crashes the system. In detail we do:
> >>
> >> - romboot loads the SPL (2kb)
> >> - SPL loads the first u-boot stage (which relocates and runs nicely)
> >> - the first u-boot 'boots' the second u-boot by loading it from the NAND
> >> - the second u-boot is loaded to the link address minus 2kB (for SPL)
> >> - this is the same for the first and the second u-boot  (link address
> >> 0x87e00000 - 0x800 = 0x87dff800)
> > The offset is about 125MiB, current mainline code tells me, that the
> > tt-01 board has just 128 MiB. It is likely your second uboot overwrites
> > the code of your first one while copying. You should link your code to
> > run at a far away address, maybe 0x80000000 ;)
> We have 256MiB (not yet contributed).
> First u-boot is loaded to 0x87e00000, then relocates to 0x8f... something.
> Second u-booot is loaded to 0x87e00000 again and relocates to 0x8f...,
> the same locations for both, the second u-boot is verified in RAM before 
> jumping to it.
> If I set a breakpoint in the do_go_exec() I can step right into the
> second u-boot.

Make sure you're cleaning the cache for that second load, if required.

-Scott