Ath79: NBG6616

@achterin I noticed that two of your contributions were committed.

ar71xx: change u-boot-env to read-write for ZyXEL NBG6616 and uboot-envtools: ar71xx: add ZyXEL NBG6616 uboot env support

Great stuff, thanks so much for working on this!

Your patch has landed and is compiling well, great!

Do you mean that it's currently not possible to upgrade from ar71xx v19.07.3 to ath79 snapshot or v20.x unless a patch lands in 19.07.4?

Once v20.x is out with support for the NBG6616 under ath79, will we need to rewrite the installation instructions on the device page?

You can use kmod-mtd-rw package to make the partition writeable, but I don't know whether you need something beyond that.

1 Like

users need to upgrade to the upcoming 19.07 service release in order to change the u-boot environment variables. furthermore they can install the kernel module adrian suggested. either way, the uboot vars need to be changed in order to avoid a device stuck in bootloop. but even than, recovery is always possible via tftp to a previous openwrt release.
i guess you dont need to wait for 20.xx to add the documentation to the device page, as the images are already available as snapshot builds. just add a ar71xx -> ath79 transition section to the page. installation via tftp is still possible as long as the bootcmd is set correctly. i havent checked if installation via ssh is possible and also if the vendor firmware supports uboot-env access.

1 Like

OK, I’ll work on updating the instructions. Just to get this straight, can either @achterin or @adrianschmutzler confirm that all the following are true?

  1. The instructions to install OpenWrt 20.x from the original ZyXEL firmware are unchanged.

  2. It is certain that 19.7.4 will contain the required change to make the boot partition writable.

  3. Users upgrading from an older version than OpenWrt 19.07.4 should install 19.07.4 first before upgrading to OpenWrt 20.x

  4. Users upgrading from OpenWrt 19.07.4 to OpenWrt 20 can use a ‘sysupgrade’ version in LuCI to upgrade, no other upgrade action is required.

  5. On upgrading from older OpenWrt versions to 20.x users MUST NOT use ‘save settings’ or restore settings from a backup.

  1. 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.
  2. Yes, even 18.06.9 will include the required changes.
  3. Partially true. Users need to upgrade to either 18.06.9 or 19.07.4 before updating to 20.xx.
  4. 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 necessary.
    Users need to make sure they have uboot-envtools installed. This package includes the necessary commands to edit the uboot-env variables.
fw_setenv boot_openwrt bootm 0x9F120000
fw_setenv bootcmd run boot_openwrt

The first command will add a new variable called "boot_openwrt" which will load the kernel from its new location.
The second command will change the existing bootcmd to the newly added one.
The third command will save these changes to flash.
After that the user can use sysupgrade to flash the new image.
5) The be honest, i haven't tried to preserve the old config but it shouldn't work as the flash layout changes. So I guess we should advice people to back up their config and to do a clean install anyway.

If users want to switch back to the vendor firmware or a pre 20.xx openwrt release they need to change the bootcmd back or the device will be stuck in a bootloop.

fw_setenv bootcmd run boot_flash

If a user forgot to change the bootcmd and the device is therefore stuck in a bootloop the user can recover the device by flashing the last firmware used via tftp.

1 Like

I wonder whether we could exploit the new compat-version feature for this ...

Thanks for the extensive response @achterin!

I am a bit worried that this bootcmd stuff is all very complex for the average user and with lots of things that can go wrong.

Considering switching from one target to another is very unusual, could something be done with using the factory.img instead of sysupgrade.img? Treating devices that are still on ar71xx as if they are stock firmware that warrant a special treatment?

By the way, with most major upgrades it is advised to not 'keep settings' and in this case I can picture issues with device enumeration being completely different between ar71xx and ath79 so people who keep their settings from a different target might have phantom network devices hanging around while the actual devices are not recognised. That compat-version could help there too, I suppose.

You're welcome :slight_smile:
You might be right about the bootcmd changes but thats the way it is now. As I said before, without changing the bootcmd uboot wont find the new kernel location as zyxel decided to use a pretty strange bootcmd. If the flash layout wasnt changed, the new kernel doesnt fit inside the partition. Changing the size of the partition didnt help either because the zyxel loading mechanism overwrote the unpacked kernel because of the size restriction.
If someone doesnt feel comfortable enough to change the uboot bootcmd, I'm sorry but then they should stick to 19.07.
Besides that, an inexperienced user can just copy & paste the commands from the wiki/commit and update the device. And even if they forgot to execute one step, they will always have the chance to revert to the last installed version via tftp and retry again. Furthermore, if someone screwed up really bad, the device has preinstalled uart pins - no soldering required :wink:

I cannot find a precompiled version of the comming 19.04 with your patches included. Is it available for download?

After applying that firmware, I would like to perform:

and then test the new ath97-build from (i guess snapshots is from the 20.x branch?)

we have service release , something changed?

Mine's still bricked.

Success - I am now running snapshot of v20.
I did upgrade to 19.07.04 .
I ran

fw_setenv boot_openwrt bootm 0x9F120000
fw_setenv bootcmd run boot_openwrt



does not exist.
I tried rebooting the deivice, but it never came up. I guess, that the changes was saved with fw_setenv, even without fw_saveenv
So I continued installing the snapshot with tftp using recovery method.
My NBG6616 is not running snapshot of version 20

I have tried opkg update;opkg install luci, but it fails because rpcd_2020-05-26-078bb57e-1_mips_24kc.ipk was missing in the repository.

I added

src/gz snt_base

to /etc/opkg/customfeeds.conf
Then opkg update;opkg install luci
was working

I have working bootloader again. I followed someone's great instructions at openwrt site ( but had to use program command (script?) with preverify and verify switches to get it right. Problem is I can't halt the bootloader via UART - I can see what's going on but my commands are not getting through. The ras.bin is no longer found or searched due to zloader not being there anymore, but it should be possible to load the nbg6616-rootfs.jffs2 you can extract from the factory image or is it systemupgrade? And you can update u-boot.bin via tftp as well. But not without halting the bootloader. My bootm line has loadaddr - fdtaddr and it seems to work but hangs very early just after loading a driver for serial port(?). U-boot is based on 2009.11 but has about 20 patches to compile.

I can interrupt boot again and experiment with tftpboot and loading firmware via tftp. So far no success. There seems to be a bug with zyxel open source uboot where it tries to erase the spi nor flash chip with nand erase command. The uboot env on a separate partition that is accessible from openwrt with the fw_ commands is maybe just a backup copy. I flashed a modified env to this partition (i hope) but still needed to edit the working uboot environment with mac serial and country. Bootm means boot an application image from memory so you need to load kernel first with fsload (load bin from jffs2). 9F000000 = flashstart according to the board specs. Device tree is appended to kernel image so I will change my bootm variable. zloader used that high bootm 9f020000, maybe I try that.

tools/mkimage doesn't seem to do anything anymore. There's the tools-only target in the u-boot 2019.07 Makefile but I think you need some config to actually build anything. Patching the Makefile doesn't seem to help. I'm trying to build ath79 u-boot for NBG6616 because the zyxel u-boot is hopeless, you can make it load images from server and use nfs based rootfs but that's about it really, I think. My router just doesn't load anything through the eth ports.

Could someone with address in Germany maybe buy one of the last nbg6716's and then sell it to me? They have those on sale on but refuse shipping abroad. I live in Finland. I think this u-boot would work very well on that router and it has a bit better specs.
There's something odd with the openwrt toolchain because these both have the Scorpion cpu which is mips32 74kc and the toolchain is for 24kc which has lower clock frequency. The only 74kc openwrt has is Mipsel which is little endian when scorpion is big endian.
I found the Linux foundation version of the source package specific to the ap135 :scorpion: board and I'm trying to build u-boot image with toolchain from mips.

You could try services like or Of course there are many more similar, I've just named random two.

Thanks for the tip. Zyxel agreed to send me one of those second hand units they still have so maybe I can get a working router after all. Looks like I need to make a little change to kernel configuration too as now it ends up as MIPS release 1. maybe it's just enabling the built in FPU emulation. The external toolchain I cant get to operation and it's already pretty old. Python is still missing from staging_dir but I can make it appear elsewhere maybe that will work out. wireless-regdb needs it I think.

@paulivil What is it you're trying to do? Are you trying to create a better u-boot loader for the NBG6616 using the one that ships with the NBG6716?