Hi Helmut,
On 12/02/2014 10:56, Helmut Raiger wrote:
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 know the MX31's NAND controller can only handle 1bit HW ECC ;-(
Let's know us your results - in my experience, when the NAND controller (I am not speaking about MX31, anyway) provides less ECC bits as requested by NAND, I always got problems. Sometimes UBIFS recovered it, but I got the point when rootfs was not mounted.
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?!
ok - then it could be that something is set twice (from first and second U-Boot), and it crashes the second time is set. Of course, the DDR controller must not be set by second U-Boot, but I suppose you have already commented out.
Maybe setting the main clock again (I see it in board_setup_clocks() ) can cause some problems. Is it called again in your modified U-Boot ? I am expecting that board_setup_sdram() and board_setup_clocks() are called only by your SPL.
Best regards, Stefano Babic