Hi Stefano,
Hi Helmut,
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 ;-) )
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?!
Helmut
-- Scanned by MailScanner.