[U-Boot-Users] Loading from NAND using 'nboot' Periodically Fails Where 'nand read' Succeeds

[Grant Erickson]

On 6/5/08 3:30 PM, Grant Erickson wrote:
> I'm following up with you on this since 'git blame cmd_nand.c' seems to
> indicate you added the CONFIG_FIT support to this file.
> 
> Based on stepping through with the debugger, my initial guess about hardware
> issues may have been incorrect. Is there an implicit assumption in the
> following snippet from nand_load_image() in cmd_nand.c:
> 
> [ code omitted ]
> 
> that casting 'addr' to 'fit_hdr' represents more than 512 bytes of valid data
> to be accessed by fit_check_format()? If so, should not 'cnt = nand->oobblock'
> be explicitly set to match that assumption?
> 
> I am guessing that my observation that NFS booting and nand read.i addressed
> the issue strictly had to do with the fact that the 8 MiB address to which
> those operate were not getting used or otherwise updated between resets after
> the boot of the kernel allowing subsequent runs of 'nboot' to "leverage" the
> stale data.

The boot.itb image I have in NAND is 0x13CB98 bytes in size. Running a
series of 'nand read.i ${bootaddr} 0 <...>':

    => nand read.i ${bootaddr} 0 1000 && iminfo ${bootaddr}
    ## Checking Image at 00800000 ...
       FIT image found
    Bad FIT image format!
    
    => nand read.i ${bootaddr} 0 2000 && iminfo ${bootaddr}
    ...
    => nand read.i ${bootaddr} 0 4000 && iminfo ${bootaddr}
    ...
    => nand read.i ${bootaddr} 0 8000 && iminfo ${bootaddr}
    ...
    => nand read.i ${bootaddr} 0 10000 && iminfo ${bootaddr}
    ...
    => nand read.i ${bootaddr} 0 20000 && iminfo ${bootaddr}
    ...
    => nand read.i ${bootaddr} 0 40000 && iminfo ${bootaddr}
    ...
    => nand read.i ${bootaddr} 0 80000 && iminfo ${bootaddr}
    ...
    => nand read.i ${bootaddr} 0 100000 && iminfo ${bootaddr}
    ...
    => nand read.i ${bootaddr} 0 200000 && iminfo ${bootaddr}
    ...
    ## Checking Image at 00800000 ...
       FIT image found
       FIT description: Linux Kernel with Device Tree
        Image 0 (kernel at 1)
         Description:  Kernel
         Type:         Kernel Image
         Compression:  gzip compressed
         Data Start:   0x008000c8
    ...

So, it would appear that the answer, at least for this trivial boot.itb of a
kernel and DTB, for how large must the initial value of 'cnt' be is "as
large as the image being nboot'ed is". That said, it looks like nboot and
FIT images may not work together at present with today's code.

Any thoughts?

Regards,

Grant