Hi Hans,
On Fri, 31 Jul 2015 10:36:43 +0200 Hans de Goede hdegoede@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;elsecurrent_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