[U-Boot] Chain loading an u-boot from an u-boot

[Stefano Babic <sbabic@denx.de>]

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

-- 
=====================================================================
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sbabic at denx.de
=====================================================================