Upgrade Zyxel NBG6616 from 19.07.10 to 22.03.2 (ar71xx to ath79)

[mcow99]

Hi all!

I am trying to go from 19.07.10 to 22.03.2:

# sysupgrade -n -v /tmp/openwrt-22.03.2-ath79-generic-zyxel_nbg6616-squashfs-sysupgrade.bin 
Invalid image type.
Image check failed.

I can't find a tried-and-tested way to do it here either:

Upgrade from (old) ar71xx to ath79

ZyXEL NBG6616

I find some information here:

Ath79: NBG6616

Nope, the best would be to advice users to install 19.07.4 first, as the partition layout is still unchanged and doesn't require a change of the bootcmd. Yes, even 18.06.9 will include the required changes. Partially true. Users need to upgrade to either 18.06.9 or 19.07.4 before updating to 20.xx. No, doing so will result in a bootloop. Users have to change the bootcmd before using sysupgrade as the zyxel bootcmd wont find the new kernel. Because of this the uboot-env rw-permission change was …

but I am not sure of the exact procedure. From the text here, I get the impression that it is enough:

fw_setenv boot_openwrt bootm 0x9F120000
fw_setenv bootcmd run boot_openwrt

(the command "fw_saveenv" is also given, but I don't have it in the system)
And then do "sysupgrade". Does anyone have that kind of experience? Does it work?

Am I correct in understanding that I can proceed in this way and do not need to use TFTP?

If the above fails, will TFTP work? Or will I have to do some unlocking of the uboot and need a serial cable? Should I use the image "...-sysupgrade.bin" or "...-factory.bin" with TFTP?

[psherman]

you should just need to add the force argument on the sysupgrade method. Obviously be sure you do not keep settings across the upgrade. Make sure that the image hash/checksum matches before you run the command with the force argument.

sysupgrade -F -n -v /tmp/openwrt-22.03.2-ath79-generic-zyxel_nbg6616-squashfs-sysupgrade.bin

Sysupgrade – Technical Reference

Verifying OpenWrt firmware binary

[mcow99]

Thank you for your answer.

However, I understand from the discussions that in case of force sysupgrade over "-F" it ends bootloop in case of Zyxel NBG6616. Maybe something has changed. Do you have experience that this path is possible with NBG6616? Don't you need to set up via "fw_setenv" first?

[psherman]

@mcow99

in case of force sysupgrade over "-F" it ends bootloop in case of Zyxel NBG6616

If this is a common issue with the specific device you're using, please wait for someone to confirm or refute this as a current issue. I don't have any experience with this specific device and I don't want to cause a brick.

In my personal experience with other devices that have gone from ar71xx > ath79, the force argument was necessary and worked as expected. But those are different products (Routerstation Pro and WR902AC), so I can't speak to the NBG6616 specificially.

[achterin]

just using "-f" will indeed result in a bootloop because the load address has changed and uboot wont find anything useful to execute. thus you have to change the uboot env variables.

just follow the notes in the pr: https://github.com/openwrt/openwrt/commit/459c8c9ef816156107e297964d088ddee2b4eef5
if you need help editing uboot env vars, read this: https://openwrt.org/docs/techref/bootloader/uboot.config#accessing_u-boot_environment_variables_in_openwrt

[mcow99]

Thank you very much for your reply.

If I understand the comments made on github, I have to change the U-Boot environment, but the procedure here (as far as I understand it) requires a serial console and therefore probably some special serial cable, which I don't have. This procedure is impracticable for me due to the necessity of using a special cable. Did I get it right?

The second link to openwrt.or deals with the possibility of changing the U-Boot environment directly from running OpenWrt (which is still my case). And if it worked on NBG6616 I could use it (assuming I don't need a serial console in this case).

Is it really necessary to change the U-Boot environment? Isn't the way to use factory.img and the TFTP? Interestingly, for NBG6716 the Recovery procedure via TFTP (https://openwrt.org/toh/zyxel/nbg6716#recovery) does not change the U-Boot environment, but for NBG6616 the Recovery procedure via TFTP (https://openwrt.org/toh/zyxel/nbg6616#recovery) requires a change to the U-Boot environment.

factory.img does not contain the U-Boot environment?

[achterin]

The commands in the github pr are for the uboot environment, thats right. But they should be the same when executed from openwrt directly. Thats why i provided the second link.

Yes, it is necessary to change the env variables because the original bootm command is not able to boot the new image layout. I tried other methods first, nothing worked.

NBG6716 uses nand flash and maybe also other uboot env settings, i dont know.

No images contain u-boot for this router.

[mcow99]

Thank you very much for the information.

I understand now that it is definitely necessary to make the appropriate changes in the U-Boot environment in order to start OpenWrt 21.x or 22.x on NBG6616. This is also necessary for people who would choose to switch from the original ZyXEL firmware, which is not clear from the chapter "Upgrade from ZyXEL customized OpenWrt" (in https://openwrt.org/toh/zyxel/nbg6616#upgrade_from_zyxel_customized_openwrt).

The problem I see is that there is no tried and tested instruction manual for NBG6616 that clearly states the procedure how to set up the U-Boot environment in OpenWrt 19.x (for example 19.07.10).

What I have done so far:

1. Analysis

# cat /proc/mtd 
dev:    size   erasesize  name
mtd0: 00030000 00010000 "u-boot"
mtd1: 00010000 00010000 "env"
mtd2: 00010000 00010000 "RFdata"
mtd3: 00060000 00010000 "zyxel_rfsd"
mtd4: 00060000 00010000 "romd"
mtd5: 00010000 00010000 "header"
mtd6: 00200000 00010000 "kernel"
mtd7: 00ce0000 00010000 "rootfs"
mtd8: 00a10000 00010000 "rootfs_data"
mtd9: 00ee0000 00010000 "firmware"

# dmesg 
...
[    0.929778] m25p80 spi0.0: found mx25l12805d, expected m25p80
[    0.936218] m25p80 spi0.0: mx25l12805d (16384 Kbytes)
[    0.941376] 9 cmdlinepart partitions found on MTD device spi0.0
[    0.947406] Creating 9 MTD partitions on "spi0.0":
[    0.952274] 0x000000000000-0x000000030000 : "u-boot"
[    0.958443] 0x000000030000-0x000000040000 : "env"
[    0.964774] 0x000000040000-0x000000050000 : "RFdata"
[    0.970923] 0x000000050000-0x0000000b0000 : "zyxel_rfsd"
[    0.977914] 0x0000000b0000-0x000000110000 : "romd"
[    0.983825] 0x000000110000-0x000000120000 : "header"
[    0.990486] 0x000000120000-0x000000320000 : "kernel"
[    0.996633] 0x000000320000-0x000001000000 : "rootfs"
[    1.002267] mtd: device 7 (rootfs) set to be root filesystem
[    1.008112] 1 squashfs-split partitions found on MTD device rootfs
[    1.014385] 0x0000005f0000-0x000001000000 : "rootfs_data"
[    1.021914] 0x000000120000-0x000001000000 : "firmware"
...

2. Setting

# cat /etc/fw_env.config 
# MTD device name	Device offset	Env. size	Flash sector size	Number of sectors
/dev/mtd1		0x30000		0x10000

But I have no idea if this is correct! fw_printenv works even if I specify a different value in the "Device offset".

3. Printing test U-boot environment

# fw_printenv 
baudrate=115200
ipaddr=192.168.1.1
serverip=192.168.1.33
uboot_env_ver=1.5
img_prefix=nbg6616-
loadaddr=80400000
readonly=ro
setmtdparts=setenv mtdparts mtdparts=spi0.0:${ldr_psize}(u-boot)${readonly},${env_psize}(env)${readonly},${rfdat_psize}(RFdata)${readonly},${rfsdat_psize}(rootfs_data),${romd_psize}(romd),${hdr_psize}(header),${rfs_psize}(rootfs)
flashargs=setenv bootargs board=NBG6616 root=/dev/mtdblock6 rootfstype=jffs2 noinitrd ${bootmode} ${zld_ver}
addtty=setenv bootargs ${bootargs} console=ttyS0,${baudrate}
addmtd=setenv bootargs ${bootargs} ${mtdparts}
boot_flash=run setmtdparts flashargs addtty addmtd;fsload ${loadaddr} /boot/vmlinux.lzma.uImage;bootm ${loadaddr}
bootcmd=run boot_flash
ldr_paddr=0x9f000000
ldr_psize=0x30000
env_paddr=0x9f030000
env_psize=0x10000
rfdat_paddr=0x9f040000
rfdat_psize=0x10000
rfsdat_paddr=0x9f050000
rfsdat_psize=0x60000
romd_paddr=0x9f0b0000
romd_psize=0x60000
hdr_paddr=0x9f110000
hdr_psize=0x10000
rfs_paddr=0x9f120000
rfs_psize=0xee0000
lu=tftp ${loadaddr} ${dir}u-boot.bin;zflash erase ${ldr_paddr} ${ldr_psize};zflash write ${fileaddr} ${ldr_paddr} ${filesize}
lf=tftp ${loadaddr} ${dir}${img_prefix}rootfs.jffs2;nand erase ${rfs_paddr} ${rootfs_psize};nand write ${fileaddr} ${rfs_paddr} ${filesize}
hostname=NBG6616
serialnum=S............
countrycode=E1
ethaddr=.................

Now it should follow:

# fw_setenv boot_openwrt bootm 0x9F120000
# fw_setenv bootcmd run boot_openwrt

And if /dev/mtd1 is writable, it should be configurable. Unfortunately I'm worried - I'm not sure about the /etc/fw_env.config setting and if it goes wrong I won't start again. If a daredevil is found, I'll be glad to know how it went.

[mcow99]

It still occurs to me to take some precautions before running "fw_setnev":

md5sum /dev/mtd1 > /tmp/mtd1.bin.md5
md5sum /dev/mtd0 > /tmp/mtd0.bin.md5
cat /dev/mtd1 > /tmp/mtd1.bin
cat /dev/mtd0 > /tmp/mtd0.bin

(it may be good to add more partitions)

And if "fw_printenv" doesn't show that the desired change has occurred and the system is up and running to restore:

mtd write /tmp/mtd1.bin /dev/mtd1
mtd write /tmp/mtd0.bin /dev/mtd0

[achterin]

you can just try the first fw_setenv command. this will only add a new uboot env var, only the second command will change the bootcmd to the new loadaddress.
if the first one works than the second will as well. after that you need to flash the new image without keeping anything.
if anything goes wrong, just get a serial adapter as the pins are already soldered on if i remember correctly.

[mcow99]

My problem is that as I gradually updated OpenWrt (until 19.07.10) the file "/etc/fw_env.config" did not exist for me. I think it is important to set it up so that the "fw_setenv" does not damage the U-Boot environment partition or even any other one altogether.

I found out that the ZyXEL NBG6616 website (https://openwrt.org/toh/zyxel/nbg6616) was recently updated by "ernax" and added some very important information. Thank you "ernax"! However, its instructions were not quite accurate for me as I did not dare to use "fw_setenv" as I did not have the file "/etc/fw_env.config".

I reset to factory default (I went the way of pushing the reset button to more than 5s). And found that the file "/etc/fw_env.config" after the reset is available!!!:

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

You can see that its content is different from what I originally arrived at (I'm quoting somewhere above). Maybe my settings would not work and something would be damaged.

Then I went on following the instructions from "ernax" ("fw_setenv boot_openwrt bootm 0x9F120000" ...). I was just nervous after starting "sysupgrade" as it will end right away on the console, but nothing happens on the router for a minute (the LEDs glow for a long time normally as if nothing is happening) - you have to wait. Even the first boot takes longer.

It all worked out, I'm at 22.03.2. Thank you for the advice and information!

Before the update my NBG6616 I borrowed one more NBG6616, where there was still a factory ZyXEL firmware. Here I applied first 19.07.10 (..-factory.bin) via "mtd -r /tmp/firmware.bin /dev/mtd6", but ended up with a booloop. The solution was TFTP ras.bin (as a copy of 19.07.10 ..-factory.bin). Here I just found out that "/etc/fw_env.config" exists after a clean installation. Then I followed the instructions from "ernax" and successfully switched to 22.03.2.