Port OpenWrt to ZyXEL NWA3560-N

eutampieri · October 21, 2022, 6:40am

Have you read https://mega.nz/file/TsxwSZwK#dq2f48TrtmNO9bqrIFE7lsLt7cY1L2zzxpwkA6gltCg?
It says (appendix C) how to load a firmware from serial.
It also liste both our models usi maybe they are the same cpu with different radios. Have you tried looking up yours using the FCC ID?

s_2 · October 21, 2022, 11:40am

Oh wow, it seems I did not smash the keyboard enough to somehow get into recovery mode, now it worked. The bootloader commands look somewhat familiar to NWA51xx, which are ath79 SoCs (same hardware as NWA11xx, but different bootloader, also using zldfs).The NWA51xx bootloader has tftp upload commands instead (ATNK, ATNR, ATNZ), but these did not work on the NWA3160; otherwise the bootloader still seems quite similar, I remember @CodeFetch was dealing with the zldfs image format for those devices (but they did not require a zip password).

In the recovery firmware header, the devices are called "nwa3kcn50", so NWA-3000 series, with the SoC Cavium Octeon CN50xx I would suppose. There is currently only one device in OpenWrt using a CN50xx, which is the Unify Security Gateway Lite:

github.com

openwrt/openwrt/blob/master/target/linux/octeon/files/arch/mips/boot/dts/cavium-octeon/cn5020_ubnt_usg.dts

// SPDX-License-Identifier: GPL-2.0-only
/*
 * Device tree source for Ubiquity UniFi Security Gateway.
 *
 * Written for EdgeRouter Lite by: Aaro Koskinen <aaro.koskinen@iki.fi>
 * Adapted for USG by: Clemens Hopfer <openwrt@wireloss.net>
 */

/include/ "octeon_3xxx.dtsi"
#include <dt-bindings/gpio/gpio.h>
#include <dt-bindings/input/input.h>

/ {
	compatible = "ubnt,usg";
	model = "Ubiquiti UniFi Security Gateway";

	soc@0 {
		smi0: mdio@1180000001800 {
			phy5: ethernet-phy@5 {
				reg = <5>;

This file has been truncated. show original

It includes the upstream octeon_3xxx.dtsi and adds a few peripherals; unfortunately the initramfs image is ~20MiB, so that's no fun to upload via xmodem. I guess we need a custom build with less packages, and then write the initramfs to flash via xmodem I won't have time for this over the weekend, but maybe by the end of next week.

It seems there will be no way to brick the device in any case, when we can still write the recovery image, which I guess goes to the SPI NOR, while the main image goes to the USB DOM?

eutampieri · October 21, 2022, 2:40pm

Actually that’s not the case: if I recall correctly only confirm files are stored on the DOM.

opennewcomer · October 31, 2022, 1:17pm

@eutampieri did you succeed downloading the content of the flash memory (on my case an MX 29LVxxxx) near the CPU (left side under the wifi module)? I think the bootloader is stored there, because I have 3 ZyXel NWA3560 that doesn't boot (stays on blinking SYS/Power LED) and doesn't show any output on serial console.
On my case, I think the flash memory is faulty on all 3 devices (more than 7 years old working 24/7) and I do not have any backup of the flash content so I could try changing the flash memory and flash a backup... I already tried to use the DOM from a working device and it didn't boot, so I think it can only be the flash memory that got faulty so there is no bootloader for booting the device.

eutampieri · November 2, 2022, 9:51am

Hi @opennewcomer !
I haven’t a flash dump of that chip. Maybe somebody else has. I don’t think I have the tools to do that

eutampieri · February 16, 2023, 10:27pm

Yes, sorry.
I knew that but I didn’t get that you thought that the device has an ath79 cpu.
According to WikiDevi it’s a CN5020, same as ER-lite.

Have you managed to do something? What are the main roadblocks? I didn’t understand wether we know how to build a (ram)bootable image or not…

s_2 · February 16, 2023, 10:31pm

I have not worked with the Cavium Octeon target before, but it's probably feasible to try, at least to build an initramfs. Unfortunately there are many devices piling up around here, that are mostly newer, so it's always hard to decide which to spend time on (currently looking at unofficial Realtek forks for example )
I'll try to keep this one on my list, but can't promise anything at the moment.

eutampieri · February 17, 2023, 7:08am

You’re absolutely right… if you could give me a few pointers (please don’t write 0xf4783a ) I could look into it I’m the following months.

s_2 · February 17, 2023, 9:15pm

You could have a look at e.g. target/linux/octeon/files/arch/mips/boot/dts/cavium-octeon/cn5020_ubnt_usg.dts (mentioned in post #22 as Discourse just let me know), and adapt this for the known values (mostly mtd partition layout seen from the bootlog). Then add the device to target/linux/octeon/image/Makefile, which should make it show up in make menuconfig. The build should give you an initramfs image, not sure which bootloader commands will actually boot it from memory only. It seems ATUK and ATUR will write the kernel / rootfs uploaded via tftp directly to flash. If this is the only way, you should try recovering the Zyxel OEM firmware with the ATUK / ATUR commands at first, if the image provides them separately (it's been a while since I looked at this device, can't really recall the image format )

You can use binwalk -v to analyze the kernel / rootfs partititons provided by Zyxel, it should be uImage and squashfs or something.

If recovery is possible, it should be safe to write an OpenWrt initramfs image to disk and try to get the wifi and ethernet working first, then later flash a "real" image that would use the rootfs partition for persistent storage of configuration etc. (initramfs comes up with default settings on every boot).

eutampieri · February 18, 2023, 8:18am

Thank you, that was really detailed. What about the encryption password?

s_2 · February 18, 2023, 10:38am

The zip password will only be needed later when everything is running and we want to build a factory image for people who don't want to mess with the console and tftp upload, but the bootloader does not need this. Initramfs is like booting from a USB drive, so the image consists only of a kernel image, that will extract its live filesystem to RAM. So only the ATUK command will be needed to write this, except if the image is bigger than the partition the router reserved for it. Then we could split it into kernel and rootfs, and flash the second part with ATUR, assuming it would be placed in flash directly after the "kernel", so it should boot fine again when reassembled in flash. But currently it seems we don't know the exact kernel partition size from the bootlog yet?