WRT1200AC small overlay size

For Developers
1

Ever since the mvebu move to kernel 6.6 I have not been able to flash my WRT1200AC device with a new build. In trying to figure this out, I noticed the /overlay is very small and very full:

Filesystem                Size      Used Available Use% Mounted on
/dev/root                27.8M     27.8M         0 100% /rom
tmpfs                   247.5M    400.0K    247.1M   0% /tmp
/dev/ubi0_1             456.0K    364.0K     32.0K  92% /overlay
overlayfs:/overlay      456.0K    364.0K     32.0K  92% /
ubi1:syscfg              29.6M    420.0K     27.6M   1% /tmp/syscfg
tmpfs                   512.0K         0    512.0K   0% /dev

The device partitions match up to the dts file, as far as I can tell:

dev:    size   erasesize  name
mtd0: 00200000 00020000 "u-boot"
mtd1: 00040000 00020000 "u_env"
mtd2: 00040000 00020000 "s_env"
mtd3: 00100000 00020000 "devinfo"
mtd4: 02800000 00020000 "kernel1"
mtd5: 02200000 00020000 "rootfs1"
mtd6: 02800000 00020000 "kernel2"
mtd7: 02200000 00020000 "ubi"
mtd8: 02600000 00020000 "syscfg"
mtd9: 00680000 00020000 "unused_area"

I can't figure out where the overlay partition size is set. This may not be related to the new kernel but it sure seems like something that should be corrected. The kernel and root sizes in menuconfig are correct for the models per the default config (16M and 104M) and all other models I have flash fine and have decent (30M+) /overlay sizes.

Any ideas where to look to correct the small overlay on the WRT1200AC model? TIA.

2

Issue

1 Like
3

While there are currently issues with sysupgrade (I've been using -F option and the firmware image) my upgrades have only been failing to take on the caiman model. Currently I'm trying to understand why my /overlay is so small, which may be a complicating factor and I think I may have it.

Caiman mtd partitions:

                /* kernel1 overlaps with rootfs1 by design */
                partition@a00000 {
                        label = "kernel1";
                        reg = <0xa00000 0x2800000>;  /* 40MiB */
                };

                partition@1000000 {
                        label = "rootfs1";
                        reg = <0x1000000 0x2200000>;  /* 34MiB */
                };

                /* kernel2 overlaps with rootfs2 by design */
                partition@3200000 {
                        label = "kernel2";
                        reg = <0x3200000 0x2800000>; /* 40MiB */
                };

                partition@3800000 {
                        label = "rootfs2";
                        reg = <0x3800000 0x2200000>; /* 34MiB */
                };

Mamba mtd partitions:

                        /* kernel1 overlaps with rootfs1 by design */
                        partition@a00000 {
                                label = "kernel1";
                                reg = <0xa00000 0x2800000>;  /* 40MB */
                        };

                        partition@e00000 {
                                label = "rootfs1";
                                reg = <0xe00000 0x2400000>;  /* 36MB */
                        };

                        /* kernel2 overlaps with rootfs2 by design */
                        partition@3200000 {
                                label = "kernel2";
                                reg = <0x3200000 0x2800000>; /* 40MB */
                        };

                        partition@3600000 {
                                label = "rootfs2";
                                reg = <0x3600000 0x2400000>; /* 36MB */
                        };

Both allocate 40M for kernel partition but caiman is allocating 2MB less of that for rootfs -- I'm curious regarding the reasoning for a 4 or 6 MB difference and why the caiman rootfs allocation can't be changed to 36MB as well.

I likely need to reduce my image size, as it's approaching these values (as I'm guessing is shown by the small /overlay remaining in my original post). Bloat from using dnscrypt-proxy-v2 and openssl among others may be starting to push a limit.

4

The upgrade issue did not start with the 6.6 kernel push for me, but at a later point.

sysypgrade -F factory.img actually upgrades correctly for you?

Your mamba can sysupgrade correctly? This fails for me on the same target device, been using tftp or mtd.

I think this stems from the original OEM FW reservation.

Upgrade fails for me with both a mamba and rango, and as indicated in the other thread, and the issue linked, the venom also fails. Both device overlay appear OK, maybe @ghoffman could check the venom.

For upgrade I have been working around by way of:

  • scp factory.img to device
  • scp backup to device
  • mtd write factory.img kernelx
  • sysupgrade -r backup
5

Yes, sysupgrade -v -F firmware.img upgrades mamba, rango and shelby (keeping config). The sysupgrade binary upgrade has been failing for some time, this is the first I've heard that it's not just a "me" problem.

I may try your method on the 1200 although I only have easy wireless access to most devices for upgrading (hence my desire for keeping config unless I absolutely can't).

I vaguely recall more memory being required for one of the kernel upgrades, somewhere in the 5.5 or 6.1 time frame. I'm wondering if I can add more room for rootfs vs. the kernel, as in the mamba version. I don't recall off-hand but the WRT1200AC may use the same wireless driver as the 3200, which results in a larger kernel.

6

my recollection of this issue goes bak to the original 3 mb kernel size allocation. for venom and caiman. The decision was made not to alter the mtd map because a 4 mb kernel could be allocated even though the original map had only a 3 mb. see

2 Likes
7

It is actually about 40 = 4 + 36 or 40 = 6 +34

You might start at

Originally WRT1900ACv1 had a smallish kernel partition size of 3 MB, while the later mvebu routers had 4 MB until WRT3200ACM that had 6 MB. Latest addition WRT32x then curiously had again only 3 MB.

That 3 MB proved to be too small when the kernel size grew along new kernel versions. Installing OpenWrt was impossible. So, following the example of ipq806x (https://github.com/openwrt/openwrt/commit/dc50694bd1a8f81b40c185bc8cacbdc8e821a3c6) I proposed increasing the kernel partition size similarly for mvebu WRT1900ACv1 and WRT32x.

So, the kernel size for those two routers was increased. The remaining part left for rootfs was then naturally reduced by the same amount. So 40 = 3+37 changed to 4+36 for WRT1900ACv1 with the smaller total size (and 123 = 3+120 --> 6+117 for WRT32x with flash abundance.)

Others (already with 4 MB or 6 MB kernel size) were not touched.
Your router has still its original 40 = 6 + 34 partitions.

1 Like
8

Yes, after ghoffman's post I began reviewing the history (crazy how easy it is to forget this stuff after a few years).

I don't think I'm pushing the limits of 4M on my kernel (for the mamba), but it appears I am pushing the limit on 34M flash space on the caiman. I was suggesting I could possibly reduce the caiman flash region to 4M, thus freeing up 2M in rootfs. However, that's still not a lot of margin and my time may be better spent working on reducing image size where possible.

I'm still missing something, as my WRT1900ACS devices have the same partitioning (6M / 34M) but the room on the overlay is about 2M greater. I'm not sure how I'm losing that room -- I don't take advantage of per-device packaging, the only overwriting that occurs is due to keeping configs. du -h in /overlay/upper shows 2.1M usage in the WRT1900ACS and the WRT1200 shows 1.4M, despite having 2M less total room. Bad flash blocks, maybe?

9

@InkblotAdmirer @hnyman @anomeome
for venom/wrt32x: even though the size of the kernel partition was increased to 6mb, only 4 mb was useable. i can't find the post, but some very knowledgable openwrt dev (certainly not me) stated something like "4mb should be enough for kernel size increases for a while".
the u-boot loader may not be able to load the full 6mb even if that size is set in the pri_kern_size and alt_kern_size env variables.

when i look at my wrt32x fw_printenv, i get

priKernSize=0x0600000
altKernSize=0x0600000

but when i look at the mtd map, there is only a 4mb offset from kernel to ubi:

dev:    size   erasesize  name
mtd0: 00200000 00020000 "u-boot"
mtd1: 00020000 00020000 "u_env"
mtd2: 00040000 00020000 "s_env"
mtd3: 005c0000 00020000 "unused_area"
mtd4: 00040000 00020000 "devinfo"
mtd5: 07b00000 00020000 "kernel1"
mtd6: 07500000 00020000 "ubi"
mtd7: 07b00000 00020000 "kernel2"
mtd8: 07500000 00020000 "rootfs2"
mtd9: 00100000 00020000 "BBT"

so i still am concerned the 4mb kernel size limit is a factor for venom at least.

10

?????
I see 6 MB there.
B - 5 = 6

Hex value:
7b00000 – 7500000 = 600000

Decimal value:
128974848 – 122683392 = 6291456

1 Like
11

@hnyman - yes, of course
(embarrassed I am - but i still recall something about 4mb limit even though the map suggested 6)

12

Kernel 6.6.49 builds yesterday, mamba is close, rest are OK:

4090623 Sep  5 15:50  linksys_wrt1200ac-kernel.bin
4090623 Sep  5 15:50  linksys_wrt1900acs-kernel.bin
4080795 Sep  5 15:50  linksys_wrt1900ac-v1-kernel.bin
4090607 Sep  5 15:50  linksys_wrt1900ac-v2-kernel.bin
4076602 Sep  5 15:50  linksys_wrt3200acm-kernel.bin
4076544 Sep  5 15:50  linksys_wrt32x-kernel.bin

IIRC for venom OEM is actually 6MB, OpenWrt came out of the gate with the smaller reservation size, followed by the increase in the resize thread.

13

off topic a little here - venom factory kernel from nov 2017 was 2077344 bytes! i'm tempted to reload to poke around again.
the problem i'm trying to solve is the sysupgrade issue so i'm trolling for anything related. i'll stop on this thread here.
thx