Dear Helmut Raiger, On 02/10/2014 12:11 PM, Helmut Raiger wrote: > Hi, > > to give you some background why we would want to do something > (strange) like this: > > - 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! > - 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. > 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. > - 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 ;) > - it jumps to 0x87e00000 omitting the SPL for the second u-boot > - the second u-boot should relocated itself again > > The second u-boot is verified in RAM with crc32 and it is valid. > > I've tested many configuration and found, that it only works if both > u-boots are identical: > > - different builds of the same code work (different build date, but same > code) > - different configurations never work > - it does not matter if cashes are turned on or off > - I skipped the relocation of the second u-boot (actually not necessary) > to no avail > > I also tried u-boot standalone applications which always work (after > fixing a bug in u-boot r8<->r9 for gd), > again independent of cashes. > Using different configuration I never get any serial output of the > second u-boot (board info) or debugging stuff. > If I set a breakpoint in the second u-boot (after relocation) and > continue from there it works until it tries > to get the SPI clock (mxc_get_clock() when accessing CCM_CCMR) for the > PMIC access. > If I throw in a mxc_dump_clocks() earlier it hangs there. Well, it may be related to some freescale interna I do not know. However It is likely that you really overwrite the first u-boot version with the second one. > > I'm pretty much running out of ideas, so any pointers are appreciated. Hope it helps ... Best regards Andreas Bießmann _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
