Hi Helmut, On 02/12/2014 10:56 AM, Helmut Raiger wrote: >> I understand the first two points, but why do you store the kernel again >> with 1bit HW-ECC ? The second U-Boot is able to check with 4bit BCH and >> your NAND requires 4bit. > > This is mainly due to performance requirements. Using 4bit BCH > increases overhead and makes DMA (currently not used in the > kernel driver) a lot slower. We thought we might slip through with > 1bit HW-ECC, but we will test this (hopefully not in the field this time > ;-) )
If your HW requires 4Bit it is highly recommended to do so. You will run your HW out of specs in other case and I think it is hard to qualify that 4Bit required ECC runs with 1Bit ECC and UBIFS as you stated in a previous mail. >> I agree with Andreas' analyses. It seems that the second u-boot >> overwrites your running U-Boot and only if they are identical you have >> no problem, that means that you are not changing the running code. > I double-checked now, the running u-boot is not overwritten. > When the 2nd u-boot relocates it overwrites the first one, but > that shouldn't be a problem. The first u-boot keeps working after > loading (but not running) the second one without issues. > > Only the 'go' crashes the system. u-boot starts stand-alone > application fine, just as the kernel. I really can't see the point > why another u-boot should be any different?! Just thinking ... have you checked the global data pointer? Is it possible that the global data of the first u-boot influences the global data of the second one? Best regards Andreas Bießmann _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
