Linksys WRT32X - Partition Swap Issue

NullDev · June 24, 2020, 4:10pm

I have 2 Linksys WRT32X devices which have dual partitions with the OEM firmware on the primary and OpenWRT 19.07.2 on the secondary. Unfortunately, I am having multiple issues and they seem to be related to the dual partition layout.

Here's what I've noticed so far:

I cannot perform an upgrade while running from OpenWRT. I've tried via Luci and the command line. Both appear to upload the firmware fine, but upon reboot, I still have the same firmware loaded in both partitions.
I am able to force the active partitions to swap by using the 3 quick reboot trick.
I am able to upgrade the secondary (OpenWRT) partition by booting to the primary (OEM) partition and doing a standard install.
I installed luci-app-advanced-reboot and it correctly reports what is installed in both partitions. However, clicking the button to reboot to the alternate partition only results in a reboot without switching active partitions.
After reading the X32 OpenWRT page, I tried running "/usr/sbin/fw_printenv -n boot_part" with these results:

Warning: Bad CRC, using default environment
## Error: "boot_part" not defined

Does this mean that something in the bootloader environment has been clobbered? The odd thing is both devices have the same issue, so I doubt it's a random fluke. I can use the 3 quick boot workaround, but I'd prefer to fix the issue before I somehow end up with 2 bricked routers. Has anyone else seen this behavior?

anomeome · June 24, 2020, 4:21pm

If serial access reset uboot env from uboot prompt.
From OEM move to a more recent OpenWrt stable to see if that changes behaviour

ssh change partition

#!/bin/sh
#hacked from /lib/upgrade/linksys.sh

cur_boot_part=`/usr/sbin/fw_printenv -n boot_part`
target_firmware=""
if [ "$cur_boot_part" = "1" ]
then
    target_firmware="kernel2"
    fw_setenv boot_part 2
    fw_setenv bootcmd "run altnandboot"
elif [ "$cur_boot_part" = "2" ]
then
    target_firmware="kernel1"
    fw_setenv boot_part 1
    fw_setenv bootcmd "run nandboot"
fi
# re-enable recovery so we get back if the new firmware is broken
fw_setenv auto_recovery yes
echo "$target_firmware"
reboot

NullDev · June 24, 2020, 5:03pm

Thank you for the quick response!

When you say "reset uboot env from uboot prompt" do you mean this procedure?

If the root cause is the uboot env needs to be reset, how would it have gotten that way? I want to make sure I don't end up back here again if possible. Since both of my devices have this problem, I suspect they were caused by the same sequence of events.

anon50098793 · June 24, 2020, 7:22pm

power loss... especially during early boot... is the most common cause.

cat /etc/fw_env.config
uci show ubootenv

NullDev · June 24, 2020, 7:55pm

The "3 quick reboot" reference was regarding the built in method for forcing an active partition switch. Since it's one of the "approved" ways of accomplishing this, I would hope that it doesn't contribute to a corrupt uboot env.

The results of the commands are below:

# cat /etc/fw_env.config 
/dev/mtd1 0x0 0x10000 0x10000

# uci show ubootenv
ubootenv.@ubootenv[0]=ubootenv
ubootenv.@ubootenv[0].dev='/dev/mtd1'
ubootenv.@ubootenv[0].offset='0x0'
ubootenv.@ubootenv[0].envsize='0x10000'
ubootenv.@ubootenv[0].secsize='0x10000'

I'll source a 3.3V USB-TTL cable to attempt the uboot env reset.

anon50098793 · June 24, 2020, 7:59pm

someone else would have to confirm...above config

rango|venom)ubootenv_add_uci_config "/dev/mtd1" "0x0" "0x20000" "0x20000"

what do you get from this?;

strings /dev/mtd1

NullDev · June 24, 2020, 8:07pm

|CASset=max
MALLOC_len=5
MPmode=SMP
SMT-2D=NJ2PH4401667X01
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:C9:01:08
eth1mtu=1500
eth2addr=60:38:E0:C9:01:08
eth2mtu=1500
eth3addr=60:38:E0:C9:01:08
eth3mtu=1500
ethact=egiga0
ethaddr=60:38:E0:C9:01:08
ethmtu=1500
ethprime=egiga0
fdt_addr=2040000
fdt_skip_update=no
fdtaddr=0x1000000
fdtfile=armada-38x-modular.dtb
fileaddr=1000000
filesize=21E0000
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

anomeome · June 24, 2020, 8:51pm

From a rango

/etc# cat fw_env.config 
/dev/mtd1 0x0 0x20000 0x20000

but the layouts do differ. Are you able to flash an OEM image from OEM. I don't recall when venom came in the pipe, but there were some changes along the way.

NullDev · June 24, 2020, 9:06pm

That's one thing I have not tried yet. I don't see why it wouldn't work since I was able to flash OpenWRT from OEM. I'll give it a shot and report back.

Other than verifying that I can boot both OEM partitions, is there anything else that I should check while in that configuration?

NullDev · June 27, 2020, 7:05pm

I finally had a chance to try various flashing scenarios using the OEM firmware. I double checked log files each time to verify which partition was currently active.

Start - OEM (primary) and OpenWRT (secondary)
Test 1 - Boot to OEM (primary) and flash OEM to secondary - Success
Test 2 - Boot to OEM (secondary) and flash OEM to primary - Success
Test 3 - Boot to OEM (secondary) and flash OpenWRT to primary - Success
Test 4 - Boot to OpenWRT (primary) and use Advanced Reboot to boot into OEM (secondary) - Success
Test 5 - Boot to OpenWRT (primary) and flash OpenWRT to secondary - Success

This is rather odd since test 4 and 5 failed prior. The only difference was OpenWRT was operating from the primary partition rather than the secondary partition as before. Because of this, I tried the following:

Test 6 - Boot to OpenWRT (secondary) and use Advanced Reboot to boot into OpenWRT (primary) - Success
Test 7 - Boot to OpenWRT (secondary) and flash OpenWRT to Primary - Success

Now I am confused as these are the exact scenarios that failed before. Perhaps flashing the OEM firmware to both partitions cleared the error.

While I am glad to have the situation resolved, it would have been nice to know what actually fixed it. Thank you all for the help and suggestions.

NullDev · June 28, 2020, 4:10pm

One point of clarification for those reading this, after a clean reinstall, /etc/fw_env.config was:

/dev/mtd1 0x0 0x20000 0x20000

system · July 8, 2020, 4:10pm

This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.