Posted: Thu Sep 01, 2022 19:32 Post subject: MTD concat in DD-WRT, partition issues in TRENDnet TEW-811DR
part 1) MTD concat in DD-WRT
some devices have more than one available flash area separated by an unmovable area such as an nvram partition. in the few devices i looked, DD-WRT just uses one of the areas for firmware storage.
linux has and MTD concatenation driver that can concatenate MTD devices or partitions and present them as a single device to the system. this could be used in DD-WRT to create a larger firmware partiton for some devices: the kernel should fit in the first concat area (as expected by the bootloader) but squashfs could span several areas. the MTD concat driver can be configured in device tree for ARM devices.
is this used at all in DD-WRT?
TRENDnet TEW-811DR is specified as an 8GB flash device. however, all the 811's i've seen are populated a 16GB flash instead, with its second half going unused. this includes 2 devices i have as well as the bootlog in https://wikidevi.wi-cat.ru/TRENDnet_TEW-811DRU:
Code:
Found a ST compatible (Marconix) serial flash with 256 64KB blocks; total size 16MB
MTD concat could be used to create an alternate build for lucky 16GB 811's that would more than double the firmware space.
- linux can overwrite nvram. i don't know if this is a mistake or done purposely to maybe mimic stock partition and allow return to stock?
- ddwrt also overlaps nvram, which i think is a real issue. (but JFFS2 support is disabled in the build, see below.)
- firmware builds *seem* to fit before the ddwrt partition. but shouldn't JFFS2 be enabled or the the firmware build size restriction be removed, one of the two?
i'm in favor of enabling JFFS2: even just 512K (0x7a0000-0x7e0000) would make the router more useful. given that JFFS2 support is currently disables, it's totally ok to change the partition definition.
in case MTD concat can't be used in DD-WRT or having 2 builds is too much to ask...
wouldn't it make sense to use all of 0x40000-0x7e0000 for firmware and 0x800000-0x1000000 for JFFS2, to be enabled only on lucky routers populated by 16GB flash?
seems to me this last option is trivial to implement.
Some things like flash layout and firmware image size are limited by the vendor in the CFE bootloader. This is nothing new. And I'm pretty sure you meant 16MB, not 16GB. To which we already know that Broadcom does not have any proper 16MB firmware image still. _________________ "The woods are lovely, dark and deep,
But I have promises to keep,
And miles to go before I sleep,
And miles to go before I sleep." - Robert Frost
"I am one of the noticeable ones - notice me" - Dale Frances McKenzie Bozzio
Some things like flash layout and firmware image size are limited by the vendor in the CFE bootloader. This is nothing new. And I'm pretty sure you meant 16MB, not 16GB. To which we already know that Broadcom does not have any proper 16MB firmware image still.
> Some things like flash layout and firmware image size are limited by the vendor in the CFE bootloader.
no. kernel size is limited by the BL; the kernel can mount a larger squashfs. the BL does limit the recovery image that can be flashed, as does the stock FW. that only means you need an 8MB transition image. the standard 8MB build could fulfill that purpose.
> I'm pretty sure you meant 16MB
sorry
> we already know that Broadcom does not have any proper 16MB firmware image still
what do you mean? asus rt-n16 uses a 16MB images. netgear ac1450's is 25+ MB. both are broadcom. etc...
The Netgear AC1450 and similar devices can't fully utilize the 128MB flash space because of vendor-locked limitations. Any firmware over a certain size will brick them (due to the recovery image size, as you've stated, I presume). RT-N16 is MIPS, 32MB flash, but the build recipe would work on various Linksys E-Series Broadcom MIPS devices with 16MB flash (which are the devices I was referring to), but none of them have 16MB DD-WRT firmware images. What you're suggesting is a one-way ticket, which has had caveats on at least one router supported by DD-WRT. But I for one am curious to the details and how you'd propose to fix this - as I am sure others who are lurking are as well. As long as it was something that didn't muck up nvram sizes and create havoc with not being able to reset without losing a 5GHz radio (RT-AC66U A1). _________________ "The woods are lovely, dark and deep,
But I have promises to keep,
And miles to go before I sleep,
And miles to go before I sleep." - Robert Frost
"I am one of the noticeable ones - notice me" - Dale Frances McKenzie Bozzio
Joined: 18 Mar 2014 Posts: 12834 Location: Netherlands
Posted: Fri Sep 02, 2022 12:52 Post subject:
It looks like this is a "standard" Broadcom Northstar device.
I just looked at my builds and it looks like it just build with all other Northstar devices, I have a build tnet811.trx which is 20 MB so not useable for you, but with a smaller config it can be reduced.
sorry guys, it seems that im not getting notifications of this thread and i forgot.
> I for one am curious to the details and how you'd propose to fix this - as I am sure others who are lurking are as well. As long as it was something that didn't muck up nvram sizes
mtdconcat is a linux driver that allows you to concat 2 mtd devices to create a new.
the nvram* parts would of course be left alone. linux and rootfs would be mtdconcat devices spanning areas below and above nvram*. ddwrt would be moved towards the end of the 16MB flash.
we'd have 2 builds, the 8 and 16MB. (btw, i've never seen an 8MB device or seen bootlogs of one.) plus a single transition build, wich would be the 8MB build with the 16MB partition scheme. you flash the transition build, then the 16MB build.
but i was only asking if DDWRT was already doing this kind of thing. i wasn't proposing that you innovate for this crappy thing.
-----------------------
but this is something simple that i'd really like done:
currently the builds don't support JFFS2. so i'd change:
Code:
0x000000040000-0x0000007f0000 : "linux" # WARNING: steps over nvram! bug or
# feature to support return to stock?
-0x000000180000-0x000000790000 : "rootfs"
+0x000000180000-0x0000007e0000 : "rootfs" # extend up to nvram
-0x000000790000-0x0000007f0000 : "ddwrt" # (WARNING: original steps over nvram!)
+0x000000800000-0x000001000000 : "ddwrt" # use upper 8MB
0x0000007f0000-0x000000800000 : "nvram_cfe"
0x0000007e0000-0x0000007f0000 : "nvram"
and enable JFFS2.
but what happens if the device has only 8M? does it boot anyway or we need a split build?
-----------------------
in any case, on the 8MB builds the partitions are crap. we should either enable JFFS2 or delete ddwrt and extend rootfs. if we enable JFFS2, ddwrt must be fixed to not step over nvram.
finally, linux stepping over nvram also isn't nice. but as long as size checks are done during build, we are fine.
I don't think you understand the flash partition layout correctly. _________________ "The woods are lovely, dark and deep,
But I have promises to keep,
And miles to go before I sleep,
And miles to go before I sleep." - Robert Frost
"I am one of the noticeable ones - notice me" - Dale Frances McKenzie Bozzio
I don't think you understand the flash partition layout correctly.
ok. care to help me understand?
linux may reach all the way up to 0x7f0000 stepping over nvram because that might have been the stock partition size and we want to be able to flash everything flashable through stock. other than that, what is it you think i'm missing?