[OpenWrt-Devel] NAND flashes in Broadcom routers: bad blocks, ECC

[Rafał Miłecki]

[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
openwrt-devel at lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel