Posted: Thu Oct 05, 2017 3:32 Post subject: MTD partition too small for upgrade, downgrade, or stock
Hi all,
Like a few others I'm stuck on a recent build (33375) that has a bug preventing upgrade or downgrade. GUI upgrade fails, just returning to the current build. Using "write" in a shell session fails too, with a complaint that the firmware image is too big:
Code:
root@DD-WRT:/tmp# write rosewill-RNX-N150RT-webflash_21061.bin linux
function stop_snmp not found
function stop_pppoeserver not found
function stop_openvpn not found
function stop_openvpnserver not found
function stop_freeradius not found
Image too big for partition: linux
linux: Invalid argument
root@DD-WRT:/tmp#
The boot loader on this router (Rosewill rnx-n150rt) doesn't seem to have a way to push or pull new firmware via tftp, so that option's not available.
The problem seems to be the MTD partition layout. the partition labeled "linux" (mtd1) has size 0x3a0000, but the size of the firmware images (dd-wrt or stock) is 0x3c0000, so they don't fit. Moreover, right after the "linux" partition, there is a partition labeled "ddwrt" of size 0x20000. It seems if this space were added to the adjacent "linux" partition, all would be well.
Here is the partition creation information from dmesg:
Code:
<0>[ 0.350000] guessed flashsize = 4M
<0>[ 0.360000] scanning for root partition
<0>[ 0.370000]
<0>[ 0.370000] found squashfs at F8000
<6>[ 0.380000] adjusted length 3D0000, original length 3CF21A
<5>[ 0.380000] Creating 9 MTD partitions on "ar7240-nor0":
<5>[ 0.390000] 0x000000000000-0x000000040000 : "RedBoot"
<5>[ 0.390000] 0x000000040000-0x0000003e0000 : "linux"
<5>[ 0.400000] 0x0000000f8000-0x0000003e0000 : "rootfs"
<4>[ 0.410000] mtd: partition "rootfs" must either start or end on erase block boundary or be smaller than an erase block -- forcing read-only
<5>[ 0.420000] mtd: partition "rootfs" set to be root filesystem
<5>[ 0.430000] 0x0000003e0000-0x000000400000 : "ddwrt"
<5>[ 0.430000] 0x0000003e0000-0x0000003f0000 : "nvram"
<5>[ 0.440000] 0x0000003f0000-0x000000400000 : "board_config"
<5>[ 0.450000] 0x000000000000-0x000000400000 : "fullflash"
<5>[ 0.450000] 0x000000000000-0x000000030000 : "fullboot"
<5>[ 0.460000] 0x000000040000-0x000000050000 : "uboot-env"
Anyone know what this "ddwrt" partition is for? Would anything bad happen if it were overwritten by the end of a new firmware image, and if not is there a way (using "mtd" maybe) to force an image to be written past the end of the "linux" partition into the "ddwrt" partition? Any other ideas on how to work around this issue?
I never had that model router but if I was in your situation I'd probably.
wget the ""correct file"" into /tmp
then do:
erase nvram
erase linux
erase dd-wrt
write ""correct file"" linux
That might work.......and while I was waiting on it to boot up I'd go find a serial cable just in case
EDIT:
Before you try to write file bl Iah blah.bin linux
You should change name so it has no spaces and no . in file name.
Best to do this before you wget it or however you want to place it in /tmp
You can change name after it's there but more simple to do it before
good luck -
I think I understand the problem a bit better now-- I dumped the entire contents of flash, and found that the firmware starts at 0x00020000, not 0x00040000. That is, the filesystem layout is not being properly set up at boot time. The RedBoot partition should start at 0x00000000 and be 0x00020000 bytes long, and the linux partition should start at 0x00020000 and be 0x003c0000 bytes long. I'm guessing the router still works because RedBoot is set up to boot the code starting at 0x00020000.
The remaining partions are probably as they should be. The ddwrt partition appears to be a copy of nvram (defaults, maybe?). It's twice as long as the nvram partition, but the extra half is just filled with ff's.
So now the question is, does anyone know a way to write to flash starting at the unlabeled address 0x00020000? I'm not too familiar with the tools here. Can dd write to mtd devices? I could imagine doing something like writing the firmware to /dev/mtd/6 (the "fullflash" partition) using seek= to skip ahead to 0x00020000. Is this legit?
@mrjcd: Thanks for the suggestion-- If I've got the above right, though, I think what might happen is that I'd end up erasing the firmware starting from 0x00040000, but still be unable to replace it with anything.
