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