OpenWrt on WRT32X unable to sysupgrade

[cht]

Hi everyone!

I have the peculiar problem that OpenWrt is unable to perform any firmware upgrade on a Linksys WRT32X and was wondering if someone has an idea what the cause could be.

Details:

I started out installing OpenWrt on a new WRT32X. The WRT32X uses a dual partition layout, leaving the stock firmware on the other partition. OpenWrt works as expected, but when I try to sysupgrade (no matter which firmware image, with or without saving config files, via web interface or cli), it fails in the following way:

• The router immediately becomes unreachable via web interface and ssh (connection attempts are refused, they do not time out)
• The router responds to pings and continues to otherwise behave as configured, including things like SQM
• The heartbeat LED trigger indicates high load
• The router stays in this state indefinitely

Turning the router off and on again boots into the OpenWrt partition and restores normal operation. The stock firmware partition appears to be untouched and is also bootable. OpenWrt can be flashed from the stock firmware without issue, but every OpenWrt version I have tried, including 23.05.2, exhibits the above-mentioned behaviour.

What am I missing here?

[hnyman]

Pure guess, but it is possible that the dual-boot variables in u-boot env are somehow mixed, causing the router to try to write into the currently-in-use partition.

What does fw_printenv say?

You might test with the Luci alternative reboot app and try booting the Linksys firmware. (Similarly the Linksys OEM firmware offer a button to boot the "alternative firmware", "previous firmware" or something like that...

[hnyman]

You might also read these, as the issue might be something similar...

Linksys Wrt32X issue

Hello, I hope someone can help me regarding openwrt on a Linksys WRT32X router. I received this and absolutely can't get it off the part. No matter what I always try OpenWRT. Could someone possibly help me? My guess is that the previous owner somehow pushed openwrt to partition 1. I tested it via Tftp / Putty and various instructions but unfortunately without success. Sorry for the bad english!

Rebooting Linksys WRT3200ACM leads to the router reverting to 'default' settings

That is the u-boot env, which is common to both partitions. Only these two lines should change in sysupgrade: They should be bootcmd="run altnandboot" boot_part=2 Hmm... Now, when I look at your data, I notice that there are mixed values. There should be either boot_part 1 + bootcmd "run nandboot", or boot_part 2 + bootcmd "run altnandboot" You have somewhat illegal combination of boot_part 1 and altnandboot. That will likely straighten up when you do the next OpenWrt sysupgrad…

[cht]

Thanks for pointing me to the other topics. I didn't spot anything suspicious in fw_printenv based on my limited understanding:

CASset=max
MALLOC_len=5
MPmode=SMP
SMT-2D=NJ2PH3400325X01
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:C3:57:A8
eth1mtu=1500
eth2addr=60:38:E0:C3:57:A8
eth2mtu=1500
eth3addr=60:38:E0:C3:57:A8
eth3mtu=1500
ethact=egiga0
ethaddr=60:38:E0:C3:57:A8
ethmtu=1500
ethprime=egiga0
fdt_addr=2040000
fdt_skip_update=no
fdtaddr=0x1000000
fdtfile=armada-38x-modular.dtb
fileaddr=2000000
filesize=D20000
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:01:00: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
silent=1
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
boot_part=1
bootcmd=run nandboot
auto_recovery=yes

However, the problem seems to be somewhere in this area, because while Advanced Reboot shows OpenWrt and the Linksys firmware in partition 1 and 2 respectively (in line with fw_printenv output), I can't actually boot the Linksys firmware via Luci. After clicking the "Proceed" button, nothing happens, trying to access the Advanced Reboot app again leads to a time-out (all other Luci pages work fine), and running fw_printenv via ssh now also hangs. All of this is resolved by a reboot.

I never noticed this before - I think I previously always used the 3x power-off method to boot the Linksys firmware.