Give me a few moments need to wake up fully.
1 Like
Here is uboot from my WRT32x running on 5.4.94 Kernel
CASset=max
MALLOC_len=5
MPmode=SMP
SMT-2D=NK90I0202455X01
altFwSize=0x7B00000
altKernAddr=0x8400000
altKernSize=0x0600000
altnandboot=setenv bootargs console=ttyS0,115200 root=/dev/mtdblock8;nand read $defaultLoadAddr $altKernAddr $altKernSize; bootz $defaultLoadAddr
autoload=no
baudrate=115200
boot_order=hd_scr usb_scr mmc_scr hd_img usb_img mmc_img pxe net_img net_scr
boot_part_ready=3
bootargs_dflt=$console $nandEcc $mtdparts_lgcy $bootargs_root nfsroot=$serverip:$rootpath ip=$ipaddr:$serverip$bootargs_end $mvNetConfig video=dovefb:lcd0:$lcd0_params clcd.lcd0_enable=$lcd0_enable clcd.lcd_panel=$lcd_panel
bootargs_end=:10.4.50.254:255.255.255.0:Armada38x:eth0:none
bootargs_root=root=/dev/nfs rw
bootcmd_auto=stage_boot $boot_order
bootcmd_fdt=tftpboot 0x2000000 $image_name;tftpboot $fdtaddr $fdtfile;setenv bootargs $console $nandEcc $mtdparts $bootargs_root nfsroot=$serverip:$rootpath ip=$ipaddr:$serverip$bootargs_end $mvNetConfig video=dovefb:lcd0:$lcd0_params clcd.lcd0_enable=$lcd0_enable clcd.lcd_panel=$lcd_panel; bootz 0x2000000 - $fdtaddr;
bootcmd_fdt_boot=tftpboot 0x2000000 $image_name; setenv bootargs $console $nandEcc $mtdparts $bootargs_root nfsroot=$serverip:$rootpath ip=$ipaddr:$serverip$bootargs_end $mvNetConfig video=dovefb:lcd0:$lcd0_params clcd.lcd0_enable=$lcd0_enable clcd.lcd_panel=$lcd_panel; bootz 0x2000000 - $fdtaddr;
bootcmd_fdt_edit=tftpboot $fdtaddr $fdtfile; fdt addr $fdtaddr; setenv bootcmd $bootcmd_fdt_boot
bootcmd_lgcy=tftpboot 0x2000000 $image_name;setenv bootargs $console $nandEcc $mtdparts_lgcy $bootargs_root nfsroot=$serverip:$rootpath ip=$ipaddr:$serverip$bootargs_end video=dovefb:lcd0:$lcd0_params clcd.lcd0_enable=$lcd0_enable clcd.lcd_panel=$lcd_panel; bootm $loadaddr;
bootdelay=3
cacheShare=no
console=console=ttyS0,115200
defaultLoadAddr=0x2000000
device_partition=0:1
disaMvPnp=no
eeeEnable=no
enaClockGating=no
enaCpuStream=no
enaFPU=yes
enaMonExt=no
enaWrAllo=no
eth1addr=60:38:E0:CE:37:58
eth1mtu=1500
eth2addr=60:38:E0:CE:37:58
eth2mtu=1500
eth3addr=60:38:E0:CE:37:58
eth3mtu=1500
ethact=egiga0
ethaddr=60:38:E0:CE:37:58
ethmtu=1500
ethprime=egiga0
fdt_addr=2040000
fdt_skip_update=no
fdtaddr=0x1000000
fdtfile=armada-38x-modular.dtb
fileaddr=2000000
filesize=C20000
firmwareName=venom.img
flash_alt_image=tftpboot $defaultLoadAddr $firmwareName && nand erase $altKernAddr $altFwSize && nand write $defaultLoadAddr $altKernAddr $filesize
flash_pri_image=tftpboot $defaultLoadAddr $firmwareName && nand erase $priKernAddr $priFwSize && nand write $defaultLoadAddr $priKernAddr $filesize
ide_path=/
image_name=uImage
initrd_name=uInitrd
ipaddr=192.168.1.1
kernel_addr_r=2080000
lcd0_enable=0
lcd0_params=640x480-16@60
lcd_panel=0
limit_dram_size=yes
loadaddr=0x02000000
loads_echo=0
mtddevname=uboot
mtddevnum=0
mtdids=nand0=armada-nand
mtdparts=mtdparts=armada-nand:2048K(uboot)ro,128K(u_env),256K(s_env),256K@8064K(devinfo),123m@9m(firmware1),123m@132m(firmware2)
mvNetConfig=mv_net_config=4,(00:50:43:11:11:11,0:1:2:3),mtu=1500
mv_pon_addr=00:50:43:db:f5:00
nandEcc=nfcConfig=4bitecc
nandboot=setenv bootargs console=ttyS0,115200 root=/dev/mtdblock6;nand read $defaultLoadAddr $priKernAddr $priKernSize; bootz $defaultLoadAddr
netbsd_en=no
netmask=255.255.255.0
netretry=no
partition=nand0,0
pcieTune=no
pexMode=RC
priFwSize=0x7B00000
priKernAddr=0x0900000
priKernSize=0x0600000
pxe_files_load=:default.arm-armadaxp-db:default.arm-armadaxp:default.arm
pxefile_addr_r=3100000
ramdisk_addr_r=2880000
rootpath=/srv/nfs/
run_script=no
sata_delay_reset=0
sata_dma_mode=yes
script_addr_r=3000000
script_name=boot.scr
sd_detection_dat3=no
serverip=192.168.1.254
standalone=fsload 0x2000000 $image_name;setenv bootargs $console $nandEcc $mtdparts_lgcy root=/dev/mtdblock0 rw ip=$ipaddr:$serverip$bootargs_end; bootm 0x2000000;
stderr=serial
stdin=serial
stdout=serial
update_both_images=tftpboot $defaultLoadAddr $firmwareName && nand erase $priKernAddr $priFwSize && nand erase $altKernAddr $altFwSize && nand write $defaultLoadAddr $priKernAddr $filesize && nand write $defaultLoadAddr $altKernAddr $filesize
usb0Mode=host
usbActive=0
usbType=2
vxworks_en=no
yuk_ethaddr=00:00:00:EE:51:81
auto_recovery=yes
boot_part=1
bootcmd="run nandboot"
Math looked ok to me.
Is anyone volunteering to test these? I've got both devices in the cupboard but my serial cables are already hooked up to other devices i'm working on.
I would however my WRT32x is in service atm, Else I would test. Flashing firmware when no one is using it is all fine, but flashing UBoot with an adjustment as big as the patches are with the risk of a brick wouldn't do my health any good after the pitch forks come out.
1 Like
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:
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.
There is an It shows mtdparts variable passed on the kernel command line with obviously wrong variables. Does OpenWrt make use of that?(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?
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"
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"
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.
What would be the best manner in which to create the largest possible kernel. bot settings on a 5.10.x build?
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
An easy method to make the kernel bigger for testing, would would be to add a couple of optional filesystems statically (ext4, xfs, jfs, ...).
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
@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
But, you went by way of factory? is that needed.
@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
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?
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