WRT32X Sysupgrade Broken

For Developers
#22

When someone reviews it and approves/merges it.
Last time it took 48 hours. Then the build bots pick it up 24 hours later.

Sysupgrade being broken on the original you’ll need to revert to OEM and reflash to the new factory.
Or boot the system using serial/u-boot, you can then sysupgrade straight away.

#23

@lantis1008, just a note that on r7046-5857088c5e, with patch applied, appears to fail on flash of a rango, same build with patch backed out worked. I do not have a serial connected to this device so a little difficult to discern what is transpiring. Not much in the patch that should cause any grief on this front, will take another look, just a heads up.

#24

I’ll unbox my rango and take a look

#25

So this is now clearing the bootargs on devices that aren't venom.

It appears that i was right:

I'm currently trying to test a different method, but i'm pretty much out of ideas.
Anyone else got any? @slh any more inspirations?

#26

@slh - what we know the differences between rango and venom are:

  1. different mtd layout
  2. zimage vs uimage kernel
    how much is hardcoded in uboot and how much in eboot-env?
    i woke up today wondering -are other differences deliberate or a by-product/mistake?

i will try to dig around today. i used to have a wrt3200, now and wrt32xb, and saved most logs, but unfortunately can't test side by side.
i can upload what you might need too.

edit -

it seems the nandboot argument is seriously forshortened in the uboot209/wrt32x environment compared to original uboot and uboot1.00 in wrt3200acm. i am wondering if this makes parsing that line erroneous:

wrt3200acm original uboot:
nandboot=setenv bootargs console=ttyS0,115200 root=/dev/mtdblock6 ro rootdelay=1 rootfstype=jffs2 earlyprintk $mtdparts;nand read $defaultLoadAddr $priKernAddr $priKernSize; bootm $defaultLoadAddr

wrt3200acm uboot v100:
nandboot=setenv bootargs console=ttyS0,115200 root=/dev/mtdblock6 ro rootdelay=1 rootfstype=jffs2 earlyprintk $mtdparts;nand read $defaultLoadAddr $priKernAddr $priKernSize; bootm $defaultLoadAddr

wrt32xb:
nandboot=setenv bootargs console=ttyS0,115200 root=/dev/mtdblock6;nand read $defaultLoadAddr $priKernAddr $priKernSize; bootz $defaultLoadAddr

#27

I have both units (WRT32X and WRT3200ACM) and would be willing to running stuff for you.
I'm not completely understanding the status, but it looks like the wrt32x patch isn't quite ready?

#28

The current version of the patch fixes venom but breaks all other devices.
I’ve had one more idea which I compiled overnight but won’t be able to test until this evening.

#29

https://patchwork.ozlabs.org/patch/921907/

Could you please try this one? I've tested locally on WRT3200ACM and WRT32X and it works ok.

#30

@lantis -do you have binaries built for those of us who don't have that capability right now?
is the missing 'earlyprintk' argument the cause of the console error?

#31

Flashed and running fine on target rango.

@ghoffman, there are images with the @lantis1008 patch applied to be found on my drop (obvious qualifier on directory name); link is off my avatar.

#32

Kabuli –

Do you have a build for wrt32x? that is my current hardware.

#33

wrt3200acm == wrt32x, they are the same; as in the image is the same, with the mods as addressed by @lantis1008 patch.

#34

Actually, they are not the same.

Wrt32x has different image layout (zimage, not uimage) and codename has ‘venom’ not ‘rango’. I don’t think these will work. I might play around a little. Thanks again.

#35

Right you are, I did not turn it on in menuconfig. I will generate a new build and put it up.

#36

Got it. Thanks. I’ll try tonight

#37

I only have a Gargoyle image (this is what I normally develop for) I can share with you. May be best to wait if you’re after Clean Openwrt.

#38

When I posted this, I sure did not notice the subtarget in existence at that time... oh well.

#39

@anomeome, @lantis1008 -
on wrt32xb:
i used your wrt32x sysupgrade image to upgrade over OpenWrt 18.06-SNAPSHOT r6984-fa0275b, which was on partition 6 (boot_part 1) from the gui. the image flashed to partition 8 ( boot_part 2). i then used your image to flash again from the gui, which put your umage back on partition 6 (boot_part 1). so i dont htink it has solved the sysupgrade problem.

#40

Your description would indicate the correct behaviour of sysupgrade doing a flash to the inactive partition; i.e. it is a round-robin, where it flashes to the inactive partition in order to preserve your current good image, in case of a bad image/flash.

#41

Agreed, sounds fine to me.
Also, without the fix, sysupgrade would not have run at all and you would just end up straight back where you came from.