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 _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
