[U-Boot] [PATCH v3 2/4] sunxi: nand: Add basic sunxi NAND driver for SPL with DMA support

[Boris Brezillon]

Hi Hans,

On Fri, 31 Jul 2015 10:36:43 +0200
Hans de Goede <hdegoede at redhat.com> wrote:

> Hi,
> 
> On 31-07-15 02:47, Scott Wood wrote:
> > On Thu, 2015-07-23 at 14:33 +0200, Piotr Zierhoffer wrote:
> >> +int nand_spl_load_image(uint32_t offs, unsigned int size, void *dest)
> >> +{
> >> +     void *current_dest;
> >> +     uint32_t count;
> >> +     uint32_t current_count;
> >> +     uint32_t ecc_errors = 0;
> >> +
> >> +     memset(dest, 0x0, size); /* clean destination memory */
> >> +     for (current_dest = dest;
> >> +                     current_dest < (dest + size);
> >> +                     current_dest += CONFIG_NAND_SUNXI_SPL_ECC_PAGE_SIZE) {
> >> +             nand_read_page(offs, offs
> >> +                             < CONFIG_NAND_SUNXI_SPL_SYNDROME_PARTITIONS_END,
> >> +                            &ecc_errors);
> >> +             count = current_dest - dest;
> >> +
> >> +             if (size - count > CONFIG_NAND_SUNXI_SPL_ECC_PAGE_SIZE)
> >> +                     current_count = CONFIG_NAND_SUNXI_SPL_ECC_PAGE_SIZE;
> >> +             else
> >> +                     current_count = size - count;
> >> +
> >> +             memcpy(current_dest,
> >> +                    temp_buf,
> >> +                    current_count);
> >> +             offs += CONFIG_NAND_SUNXI_SPL_ECC_PAGE_SIZE;
> >> +     }
> >> +     return ecc_errors ? -1 : 0;
> >> +}
> >
> > No bad block marker handling?
> 
> The bootrom does not use bad block marker handling (and allwinner's
> own FTL does neither for the non boot area, the actually mess up
> things by writing metadata which looks like classic bad block
> markers).

Hm, checking for bad block markers (and skipping bad blocks) is always a
good thing, even if it does not by itself guarantee that the data
stored in there are not corrupted.

> 
> What we should do (in a follow up patch) is run some sanity
> checks (checksum of the image, etc.) and retry at a different
> offset if that fails. This is also what the bootrom does for
> loading the SPL itself, it simply tries to read it
> at a number of fixed addresses at the beginningen of the nand,
> so we should do the same looking for u-boot.bin at those same
> addresses (taking into account that u-boot.bin will be written
> after the SPL).

Yes that's a solution: putting the u-boot binary in 2 (or more)
distinct blocks (and maybe we should also repeat it over a given block
to be more robust against bitflips) should address the case where the
main u-boot block becomes bad.

Best Regards,

Boris

-- 
Boris Brezillon, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com