What is partition layout for Netgear 3700v4?

Hello.
I have installed 21.02 rc1 on a Netgear 3700v4 and went into trouble. I tried to install a custom build with a few packages, size is > 8MB. I built a ligher custom build (< 8MB) and that one works. So there is some kind of 8MB limit size for build.
The device has a 128 MB nand flash. After install, there is about 100 MB available, which is big. So there is 28MB left for the partition layout.
I searched for this partition layout to confirm this, but was not able to fully understand (no rootfs partition). kernel partiton size is 4 MB. Firmware is supposed to be kernel + roofs according to doc, and its size is 6.9 MB. I can't find 8MB

Can someone expertize these data and enlighten me ?

Kernel log

[    0.352558] nand: device found, Manufacturer ID: 0x2c, Chip ID: 0xf1
[    0.359059] nand: Micron NAND 128MiB 3,3V 8-bit
[    0.363672] nand: 128 MiB, SLC, erase size: 128 KiB, page size: 2048, OOB size: 64
[    0.371401] Scanning device for bad blocks
[    0.379504] random: fast init done
[    0.463413] 12 fixed-partitions partitions found on MTD device ar934x-nand
[    0.470411] Creating 12 MTD partitions on "ar934x-nand":
[    0.475824] 0x000000000000-0x000000040000 : "u-boot"
[    0.481985] 0x000000040000-0x000000080000 : "u-boot-env"
[    0.488399] 0x000000080000-0x0000000c0000 : "caldata"
[    0.494668] 0x0000000c0000-0x000000140000 : "pot"
[    0.500508] 0x000000140000-0x000000340000 : "language"
[    0.506839] 0x000000340000-0x0000003c0000 : "config"
[    0.512954] 0x0000003c0000-0x0000006c0000 : "traffic_meter"
[    0.519722] 0x0000006c0000-0x000000ac0000 : "kernel"
[    0.525862] 0x000000ac0000-0x000001fc0000 : "ubiconcat0"
[    0.532456] 0x0000006c0000-0x000001fc0000 : "firmware"
[    0.670528] 0x000001fc0000-0x000002000000 : "caldata_backup"
[    0.677368] 0x000002000000-0x000008000000 : "ubiconcat1"
[    0.684645] Concatenating MTD devices:
[    0.688523] (0): "ubiconcat0"
[    0.691546] (1): "ubiconcat1"
[    0.694569] into device "ubi-concat"
[    0.698246] 1 fixed-partitions partitions found on MTD device ubi-concat
[    0.705054] Creating 1 MTD partitions on "ubi-concat":
[    0.710292] 0x000000000000-0x000007500000 : "ubi"

result of cat /proc/mtd which provides quite the same infos.

dev:    size   erasesize  name
mtd0: 00040000 00020000 "u-boot"
mtd1: 00040000 00020000 "u-boot-env"
mtd2: 00040000 00020000 "caldata"
mtd3: 00080000 00020000 "pot"
mtd4: 00200000 00020000 "language"
mtd5: 00080000 00020000 "config"
mtd6: 00300000 00020000 "traffic_meter"
mtd7: 00400000 00020000 "kernel"
mtd8: 01500000 00020000 "ubiconcat0"
mtd9: 01900000 00020000 "firmware"
mtd10: 00040000 00020000 "caldata_backup"
mtd11: 06000000 00020000 "ubiconcat1"
mtd12: 07500000 00020000 "ubi"

You're looking at split partitions.

Notice how the beginning and end of the firmware partition sit at 6c0000 and 1fc0000, respectively. The address ranges of the kernel and ubiconcat0 partition are squeezed right in there. Then notice the second ubiconcatX device:

The kernel and ubi-concat partition is what OpenWrt will write to. You can calculate the total size yourself.

Hello.
Thanks for the clue.
There are still unclear things : top memory adress for ubiconcat1 is 8000000, nevertheless top memory adress for the whole ubi-concat is 7500000. Weird concatenation as top is missing.
Kernel + ubiconcat is about 124MB. But I can't still figure out why is there a 8MB limit.

the factory firmware,recover interface, or older sysupgrade's with older or differing partition layouts
can restrict the size of the firmware file that is able to be uploaded
this is often a constraint of the original OEM firmware layout & keeping things compatible

but from what I see the image size restriction is "IMAGE_SIZE := 25600k"
it should be limited to the size of firmware 0x1900000 so in decimal 26214400
& divided by 1024 = 25600 * 1K
firmware is also allocated as kernel + ubiconcat0 this seems to be the limitation

I can't see an 8M limit

1 Like

I think we need more information
can you generate a file bigger then 8M ?
is that file able to be uploaded ?
do you have a serial interface setup to see the boot process for errors ?

in short where is the 8M+ file failing ?

I agree with your analysis.

can you generate a file bigger then 8M ?

Yes. I have generated a build with -ppp -wolfssl +openvpn, it was about 8.2 MB

is that file able to be uploaded ?

Yes, using luci upgrade

do you have a serial interface setup to see the boot process for errors ?
in short where is the 8M+ file failing ?

No
Furthermore I don't have physical access to the device anymore. It was lent by a friend for maintenance and update (to 21.02), and I gave it back. I plan to update it again only for the next rc or final. So, in the meantime, I'm trying to figure it out why I wasn't able to update with this >8M build.

Here is the history of the device : it has run original Netgear soft, than several Openwrt 19.07. I have always use web interface (netgear, luci) to upgrade. After bricking with the 8MB+ build, I used nmrpflash. I wasn't able to restore the original Netgear soft (>8M) but was able to restore the 21.02 squashfs-factory.bin wich has a 8MB size. Than I flashed a custom build (-ppp, -wolfssl , no openvpn <8M). That is why I'm suspecting a 8MB limit.

So far, one way to solve this issue is to flash a light build (<8MB), than manually add openvpn, that's what I have done. But it would be more efficient to directly include openvpn in the build (>8M).

different chip set but it reminds me of the below

it was boot loader limitation
need to watch serial boot log to watch the status of decompression

This device previously runs 19.07 on ar71xx target, and default builds were about 4.6MB. Now with 21.02 on ath79 target, default build is about 7.2MB. I suspect important changes in the partition layout. I still have a way to work around this issue by manual installation.
Thanks for answering anyway.

it's only a possibility something to look for in the boot log
I think if it was a partition layout it would error while compiling

I'll keep this thread alive in future tests (next rc).
Thank you.