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?
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.
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
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 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.
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 Amazon.de 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 board and I'm trying to build u-boot image with toolchain from mips.
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.
No, i have open source code for both routers but it is dated. There is a possible mismatch between u-boot 2009 and mkimage 2019 which makes it impossible to load the flattened image tree uimage I'd like to load. There's a chance that I could come up with 2016 u-boot loader which is Kconfig style. Failing that the dts based ath79 style is something to concentrate on, maybe it's just a question of copying ap152 board. All these are unlikely candidates for merge because you will need console access to update firmware, no support for factory images. Latest version of u-boot that I've got is the worst ever, doesn't even know any commands.
I think this is it, no way to make progress. I'll put out a warning or remove the repo. The router does boot but does nothing and doesn't accept any commands. No way to update because jtag no longer goes into init stage. If you comment out board_nbg6616 it won't reach that stage.
Not a hardware problem because I tried this with nbg6716 too. I bodged the jtag header soldering on that board so that's it too. I tried to desolder the mount points but they lifted off the board. The code has some chunks bypassed by zyxel and then streamlined by codeaurora back in 2017. There's very little explanation why these changes are made and none has been merged to ath79.
board and I'm trying to build u-boot image with toolchain from mips.