[OpenWrt-Devel] Netgear R6260 EEPROM location
mail at david-bauer.net
Thu Jan 30 17:00:23 EST 2020
On 1/30/20 12:57 PM, Piotr Dymacz wrote:
>> I'm still waiting for him to send ma a photo of the routers backside, but it seems
>> we have to dynamically detect the partition map of the devices. I'll look into the
>> SC_PART_MAP partition and the routers GPL code to find a possible solution for this
> There was some work with custom 'SC_PART_MAP' mtd parser back in 2018 but mapping used in vendor firmware didn't match what was in flash, see:  and also  about 'different' R6220 models.
Yup, I've vaguely remembered following this discussion back then. I've just tried to catch
up on this topic and it seems my problem is connected with bad NAND blocks.
My OpenWrt bootlog shows this:
[ 3.153100] Bad eraseblock 396 at 0x000003180000
[ 3.204465] Bad eraseblock 578 at 0x000004840000
Which would explain, why the "SC Private Data" and "ML1" partitions have different sizes.
However, this would somewhat match the remap misbehavior, which we previously had issues
with on the R6220. This got eventually fixed, as it's not the NAND drivers job to shift
on bad blocks.
The factory firmware did not remap partitions on the R6220, while it
seems it does so on the R6260. Correct me if i got this wrong here.
Also, this would mean Netgear takes bad blocks into account when writing the calibration
data to NAND, correct?
What i do not understand: Blocks can go bad in operation (not common, but possible) -
for the R6260, this would mean the blocks are shifted once more, thus the factory
partition is not at the same offset?
I assume, if we want to fix this we need to do this from userspace, as either place
in the kernel seems wrong. Implementing it on the mtd layer is obviously wrong,
as it would mean breaking the wireless as soon as a block preceding the factory
partition goes bad.
If I'm wrong in any of my assumptions, please correct me ;)
openwrt-devel mailing list
openwrt-devel at lists.openwrt.org
More information about the openwrt-devel