[cross-list e-mail to openwrt-devel and linux-mtd] Hi,
I wanted to finally switch from NAND_ECC_NONE to NAND_ECC_SOFT (there is no hw ECC) but it appears it won't be that straightforward. The problem is NAND implementation in Broadcom's CFE bootloader. It appears that all the bootloader cares about is if block is good or bad. I think it doesn't even use BBT. It simply checks for oob[0x0] (or oob[0x5] for small flashes) being 0xff. Then it writes to the block or skips it. The bootloader doesn't seem to even calculate ECC when writing! So after installing firmware using bootloader all OOB content is 0xFF. Of course enableing NAND_ECC_SOFT results in uncorrectable errors: bcm47xxnflash: NAND_CMD_RNDOUT len:0x0F bcm47xxnflash: NAND_CMD_RNDOUT data FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF __nand_correct_data: uncorrectable ECC error __nand_correct_data: uncorrectable ECC error __nand_correct_data: uncorrectable ECC error mtd_read error while reading (offset: 0x60000)! So I wonder how we could deal with that. Should I somehow detect if this is first boot after installation and calculate ECCs on my own? Hoping nothing wrong will happen of the first read? In case you wonder how Broadcom's firmware handles that. Well, horribly. They use two drivers: "nflash" and "brcmnand". The first one (bcm_nflash.c) is a plain MTD driver that follows poor bootloader logic. It's responsible for "kernel" and "rootfs" partitions. It does not care about BBT or ECC. It assumes reading always success and it may mark blocks as bad after failed erase or write. The second one (brcmnand_47xx.c) is a nice NAND driver. It uses (in a bit hacky way, but still) NAND subsystem, handles ECC, etc. Broadcom uses it for "brcmnand" partition located after "kernel" and "rootfs". -- Rafał _______________________________________________ openwrt-devel mailing list [email protected] https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
