Increasing mamba and venom kernel partition to 6MB

For Developers
21

That would likely fail due to the two-step OpenWrt sysupgrade, like I said in my original message, linked in the first message of this thread.

Writing rootfs based on the currently running firmware's DTS partition table would likely overwrite the last part of kernel. (OpenWrt first writes kernel, and separately rootfs to the location specified by the currently running firmware)

I propose going via Linksys OEM firmware, or any other way to write a unified "factory" image instead of the two-part sysupgrade image.

(That's why ipq806x required flashing via OEM GUI or TFTP recovery flash)

Ps.
Sysupgrade force-flashing the OpenWrt factory image might also work, as you can return to OEM firmware via force, so the OpenWrt factory image should be similar as OEM images, and might work.

E.g. for my WRT3200ACM the factory image is 4 MB larger than the sysupgrade image, as the factory image contains lots of 00 padding upto 0x600000 (from the end of the actual kernel to end of the kernel area = the start of rootfs)

EDIT:
just to highlight the possible issue with "normal" sysupgrade, this is the structure of the wrt3200acm sysupgrade image: a TAR archive with separate kernel and rootfs files, which will be flashed separately according to the places specified by the currently running partition structure:

image
image1419×384 57.8 KB

22

I have booted mamba with the 4MB patch.
I first tested force flashing a regular factory image.
It worked fine.
So then I force flashed a factory image with the resize patch.
Restored backup.
And everything seems to be working.
:rocket:

There is an mtdparts variable passed on the kernel command line with obviously wrong variables. Does OpenWrt make use of that? It shows (ignored) a line later.

Otherwise df -h shows / as 1MB smaller.

They are here if anyone wants to test.
https://divested.dev/unofficial-openwrt-builds/mvebu-linksys/20210206-00-RESIZE_TESTING/
and obviously the patches above for anyone compiling.

edit:
padding in the factory image between kernel and root
old
start: 0x2C6709 2.9MB
end: 0x340FFF 3.4MB

new
start: 0x2C66D1 2.9MB
end: 0x440FFF 4.4MB

Anything else I should check for or test?

23

What does this look like now:

root@mamba:/sys/block# cat /proc/mtd
dev:    size   erasesize  name
mtd0: 00100000 00020000 "u-boot"
mtd1: 00040000 00020000 "u_env"
mtd2: 00040000 00020000 "s_env"
mtd3: 00100000 00020000 "devinfo"
mtd4: 02800000 00020000 "kernel1"
mtd5: 02500000 00020000 "rootfs1"
mtd6: 02800000 00020000 "kernel2"
mtd7: 02500000 00020000 "ubi"
mtd8: 02600000 00020000 "syscfg"
mtd9: 00780000 00020000 "unused_area"
mtd10: 00008000 00008000 "spi0.0"
24 
root@mamba:~# cat /proc/mtd
dev:    size   erasesize  name
mtd0: 00100000 00020000 "u-boot"
mtd1: 00040000 00020000 "u_env"
mtd2: 00040000 00020000 "s_env"
mtd3: 00100000 00020000 "devinfo"
mtd4: 02800000 00020000 "kernel1"
mtd5: 02400000 00020000 "ubi"
mtd6: 02800000 00020000 "kernel2"
mtd7: 02400000 00020000 "rootfs2"
mtd8: 02600000 00020000 "syscfg"
mtd9: 00780000 00020000 "unused_area"
mtd10: 00008000 00008000 "spi0.0"
25

Great that it worked for you.

The next thing would be sysupgrading with the modified sysupgrade image. As you are now running with the modified partition table, sysupgrade should work just fine.

Ps.
You might also look from the kernel log the mtd detection section. It shows you better the start and end of each partition.

26

What would be the best manner in which to create the largest possible kernel. bot settings on a 5.10.x build?

27

Strange
Advanced Reboot shows
Alternative Linksys/Unknown (Linux 5.4.95).

Sysupgrade a sysupgrade file worked fine.
And both descriptions on the Advanced Reboot were correct after.

@anomeome
that is what needs to be tested next.
making sure it really does boot with a kernel that is larger then 3MB

28

An easy method to make the kernel bigger for testing, would would be to add a couple of optional filesystems statically (ext4, xfs, jfs, ...).

29

So my patches that allow me to build a 5.10.x image taken out, the two from thread, on a 5.10.13 kernel yield:

3381799 Feb  6 11:57  linksys_wrt1900ac-v1-kernel.bin
3377127 Feb  6 11:57  linksys_wrt32x-kernel.bin

presumably

CONFIG_ALL_KMODS=y
CONFIG_ALL_NONSHARED=y

should increase size significantly. Does that last one add any builtin kmods.

@slh, some of the mvebu targets boot from f2fs / ext4, so those are in by default. I have been getting a 5.10.x image to build by patching to remove:

target/linux/mvebu/cortexa9/config-5.10 
# CONFIG_ATA is not set
# CONFIG_EXT4_FS is not set
# CONFIG_SATA_PMP is not set
# CONFIG_SCSI is not set

but presumably the above would build all kmods in?

Edit: (mamba) 3381799−3145728 = 236071 too big. I'll see if I can get OEM on to this device.

1 Like
30

@anomeome
I didn't use OEM for flashing.
I just used sysupgrade from LuCI.

I am compiling a larger kernel right now to test.

1 Like
31

But, you went by way of factory? is that needed.

32

@anomeome
I backed up.
I flashed the factory image from sysupgrade, force checked, keep settings unchecked.
Restored the backup.

I have no intent to ever run the outdated, insecure, proprietary firmware from LINKSYS.

My understanding is that flashing the factory image basically dd's the image into the kernel partition, which is 40MB and includes the root partition. That is why it has padding in it.
Normal sysupgrade flashes each partition separately like @hnyman mentioned which won't work because the currently loaded mtd region values are the old/wrong ones.

1 Like
33

nyet, failed boot.

1 Like
34

Did the DTS patch apply?

[    1.506864] Creating 10 MTD partitions on "pxa3xx_nand-0":
[    1.512373] 0x000000000000-0x000000100000 : "u-boot"
[    1.518034] 0x000000100000-0x000000140000 : "u_env"
[    1.523600] 0x000000140000-0x000000180000 : "s_env"
[    1.529040] 0x000000900000-0x000000a00000 : "devinfo"
[    1.534593] 0x000000a00000-0x000003200000 : "kernel1"
[    1.540278] 0x000000d00000-0x000003200000 : "ubi"
[    1.545602] 0x000003200000-0x000005a00000 : "kernel2"
[    1.551247] 0x000003500000-0x000005a00000 : "rootfs2"
[    1.556898] 0x000005a00000-0x000008000000 : "syscfg"
[    1.562456] 0x000000180000-0x000000900000 : "unused_area"
[    2.624243] VFS: Cannot open root device "(null)" or unknown-block(0,0): error -6
[    2.631767] Please append a correct "root=" boot option; here are the available partitions:
[    2.640162] 1f00            1024 mtdblock0 
[    2.640165]  (driver?)
[    2.646736] 1f01             256 mtdblock1 
[    2.646739]  (driver?)
[    2.653299] 1f02             256 mtdblock2 
[    2.653301]  (driver?)
[    2.659874] 1f03            1024 mtdblock3 
[    2.659877]  (driver?)
[    2.666452] 1f04           40960 mtdblock4 
[    2.666455]  (driver?)
[    2.673015] 1f05           37888 mtdblock5 
[    2.673018]  (driver?)
[    2.679587] 1f06           40960 mtdblock6 
[    2.679590]  (driver?)
[    2.686161] 1f07           37888 mtdblock7 
[    2.686164]  (driver?)
[    2.692723] 1f08           38912 mtdblock8 
[    2.692726]  (driver?)
[    2.699296] 1f09            7680 mtdblock9 
[    2.699299]  (driver?)
[    2.705873] 1f0a              32 mtdblock10 
[    2.705877]  (driver?)
[    2.712523] Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0)

those are still the old values, aren't they?
0x000000d00000-0x000003200000
should be
0x000000e00000

Did you make sure to copy the patch from patches-5.4 to patches-5.10?

35

Ha, I spotted the dts change in a quick git status, failed to notice it was venom, and that there is a 5.4 patch for the mamba, Try again.

1 Like
36

Nice spot, good boot

1 Like
37

@anomeome
How big is that image?

38

Same as above

3381799 Feb  6 13:33  linksys_wrt1900ac-v1-kernel.bin

16252928 Feb  6 13:33 openwrt-mvebu-cortexa9-linksys_wrt1900ac-v1-squashfs-factory.img

14122142 Feb  6 13:33 openwrt-mvebu-cortexa9-linksys_wrt1900ac-v1-squashfs-sysupgrade.bin

but I think it would be prudent to try and get as close as possible to the limit.

39

Yes, but still awesome!

1 Like
40

Nice work. However Venom i thought had a 6mb kernel partition or at least 0x600000 / 6291456 (SI base 10) is what i thought it was with Hex to decimal SI base 10 being bytes which make 6MB.

However its awesome, however it then needs to be reviewed by the team surely for it to get merged. I Take it this also means you loose /root storage space over all and it doesn't over write the second partition.