I have now my snaphot effort online at https://github.com/paulivil/openwrt. Made a pull request. Please take a look and comment, I'm running out of ideas. The router accepts both sysupgrade and factory images, but the only result is bootloop. Is the default uimage ok for this device ie. denx,uimage?
Hi, did you ever get anywhere with this?
I have a Zyxel NBG6616 and it would be a shame if it lost support in the next major update when the hardware is still more than capable of running OpenWRT very well.
I'm still working on it. The source code is on https://github.com/paulivil/openwrt you're welcome to try. My router was soft bricked so I need to unbrick it first to make any progress on the firmware. The zyxel bundle didn't come with their zloader but what i got i have put it back under packages so it can be built-in. Why? Well the original zloader/u-boot couldn't load the device tree and wanted the image size very small. Image can be slimmed but i think zloader has to go and u-boot needs still some patching. Unbricking didn't happen via the serial interface so I need to try jtag. Once i've finished my soldering i can hopefully get some results.
1 Like
Unfortunately coding or compiling from Github and trying this out is beyond my skill set.
Have you been in touch with user ‘achterin‘? He was working on this too some time last year.
I can tell you that I managed to connect to the NBG6616 using this TTL to USB converter. I had to use it to unbrick it. That would save you soldering.
sorry for being late to the party.
right now i have a pretty solid pull request ready, but it seems you need to change uboot boot-cmd to get it working properly as zyxel decided to use some pretty weird uboot setup.
update-wise this means either you are able to use a custom openwrt image that has an unlocked uboot-env partition or you need to use the uart way. maybe it is possible to make the uboot-env partition writeable in the upcoming 19.07 service release, i'll discuss this in the pr later.
if you want to test that stuff, here is the code: https://github.com/achterin/openwrt/tree/ath79-zyxel-nbg6616
everything you need to know should be listed in the commit message. if something is missing, please let me know.
i will create the pull request tomorrow.
3 Likes
@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?
-
The instructions to install OpenWrt 20.x from the original ZyXEL firmware are unchanged.
-
It is certain that 19.7.4 will contain the required change to make the boot partition writable.
-
Users upgrading from an older version than OpenWrt 19.07.4 should install 19.07.4 first before upgrading to OpenWrt 20.x
-
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.
-
On upgrading from older OpenWrt versions to 20.x users MUST NOT use ‘save settings’ or restore settings from a backup.
- 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 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
fw_saveenv
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
fw_saveenv
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 
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 
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 https://downloads.openwrt.org/snapshots/targets/ath79/generic/openwrt-ath79-generic-zyxel_nbg6616-squashfs-sysupgrade.bin (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
but
fw_saveenv
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 http://ftp.snt.utwente.nl/pub/software/lede/snapshots/packages/mipsel_24kc/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 (https://openwrt.org/docs/guide-user/hardware/debrick.ath79.using.jtag) 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.