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