dd-wrt Boot Loop on R6300v2 -- any cure?

2 posts / 0 new
Last post
skneizys
skneizys's picture
dd-wrt Boot Loop on R6300v2 -- any cure?

I have a pair of Negear r6300v2.  Both load Netgear firmware just fine.  Only one works with recent dd-wrt builds due to the other having the bad eraseblock issue causing a kernel panic (using CFE serial console to recover.)  I was able to build an old DD-WRT v24-sp2 "mega" version and that worked just fine on the "defective" router, FW size 7,344,186, but when I try to load a more modern Kong Linux 4.4 file it fails.

I've read that the squashfs itself doesn't handle bad NAND blocks, but is there any strategy for for handling this?  As in -- if I used the firmware mod kit to strip the size down on a modern build, does that code have a strategy for loading from NAND memory with bad blocks such taht I could load a full-featured firmware?  Or is this something that requires CFE mods?

Thanks for any information!

Steve...

skneizys
skneizys's picture
Ive done more research ...
Ive done more research ... from file: dd-wrt/src/linux/universal/linux-4.4/drivers/mtd/ubi/Kconfig:
 
config MTD_UBI_BLOCK
bool "Read-only block devices on top of UBI volumes"
default n
depends on BLOCK
help
  This option enables read-only UBI block devices support. UBI block
  devices will be layered on top of UBI volumes, which means that the
  UBI driver will transparently handle things like bad eraseblocks and
  bit-flips. You can put any block-oriented file system on top of UBI
  volumes in read-only mode (e.g., ext4), but it is probably most
  practical for read-only file systems, like squashfs.
 
  When selected, this feature will be built in the UBI driver.
 
I was wondering -- can the firmware be built with this option such that squashfs is mounted on a UBI volume?  That way the bad eraseblocks are no longer a show-stopper.  Right now, on a "perfect" R6300v2/R7000, if a bad eraseblock pops up in the wrong spot and it is on dd-wrt then the device is bricked.
 
Thanks,
 
Steve...