Hi Hans,
On Fri, 31 Jul 2015 10:36:43 +0200
Hans de Goede <hdego...@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
_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
