HW of ubiquiti nanostation m5 has changed


I have a Ubiquity Nano Station M5 with FW version XW.v6.1.7. (HW rev. 1901K)
I tried several methods to downgrade the stock FW so that I'm able to install openWRT, but I failed.
Any FW older then v6.1.4 are giving me the error code A12. Root cause seems to be the fact that Ubiquiti has changed the HW for newer Nano Stations M5. It seems this has changes since HW revision 1847G [1].

Together with @guifipedro I was able to start to compare the dmesg of an 'old' device with openWRT and a 'new' device with v6.1.4 FW. Up to now our findings are, that the flash chip has changed, which seems to be ath-nor0 now.

I'm writing this to raise awareness that:

  1. you are not able to downgrade the AirOS FW to a point where you can install openWRT via the web console or tftp
  2. It's highly possible that the actual openWRT image for the NanoStation M5 is not bootable with the newer HW revisions.

Next steps will be to open the box to access the serial console (who needs warranty of a useless device, if you can't install openWRT anyway...) and try to see if I can overwrite the kernel with an openWRT one via the serial console and u-boot. If anyone is working on something similar or wants the help, please let me know.

[1] https://community.ui.com/questions/How-to-downgrade-FW-to-6-0-6-beta-Nanostation-M5/2d393c9a-2bd2-4d11-90ad-287db52ea430


Have you tried install using this procedure? https://openwrt.org/toh/ubiquiti/litebeam_5ac_gen2

That's for the new AC models and AirOS 8. Would not apply to non-AC hardware.

I think there was a process to manually initiate TFTP with some options from the bootloader command prompt (requires opening the case to attach serial). This will allow flashing an old AirOS, but it will only install the kernel / rootfs. Then boot that AirOs and use the web interface to again flash the old AirOS. That replaces the bootloader with the old one. Finally you can install the "factory" OpenWrt.

For a one time run you don't have to solder pins on the serial port, just put a row of square pins in the holes and tilt them to the side so they make contact.

Did you try it already? If the upgrade procedure is identical across all airOS versions then it should work, of course you flash image for your device instead of the one in wiki.

Well the problem is, that older AirOS version does not support the HW, as, at least, the flash chip has changed. That's the problem. You don't get a running AirOS because, I suppose, the kernel is not able to read the rootfs. So no way to update through the web interface neither.

Well yes I just tried it. It didn't work, u-boot resets now with:

Booting image at 9f050000 ...

Bad Header Checksum
Boot failed: resetting...

Now I have to find out how I can get back to a working state.

That indicates you have been able to write to flash and the same procedure is valid on airos 6.

Boot failure is likely caused by wrong/incomplete firmware, or flashing error. Maybe even u-boot that checks for fw signature, but even u-boot can be replaced if found problematic.

Important thing is that it's possible to do it without device opening.

For the recovery, use tftp client and reset button. Google for howtos.

1 Like

Well that was easier as I thought. There is a command:
urescue - start TFTP server and wait for firmware

Which allows you to put a FW at

Anybody interested in the latest u-boot code, should have a look here:

Up to know having had a look on the u-boot source code ubiquiti provides me, I don't think that u-boot checks a special signature. I started to have a look on the kernel header with hexdump, and what I found out:
/dev/mtd3 is only 1MB big but openWRT kernel is 1.313 MB. That's why crc32 checksum in u-boot fails.

So I have to find out, how to reduce the size of the kernel. If you have any hints, that would be appreciated as my knowledge of the openWRT build system is pretty much rudimentary...

There is no need for fullquotes. Just use the Reply button below the posting you want to reply to, and the forum software will automatically link your posting to the one you reply to.

Therefore, no need to completely quote the posting you are replying to.
Thanks for your understanding.

mtd2 or mtd3? run cat /proc/mtd to display partitions

on litebeam kernel size is also 1.4MB but it loaded fine.while experimenting with flashing of first unit, i did flash only kernel partition, then dumped it back into ram and ran md5sum to verify that it was properly written - you can try that to see if there are any problems.

flashing second unit suceeded right on first attempt but openwrt displayed many jffs2 eraseblock messages in kernel - only conclusion i could made is that these messages appeared because flash was not erased prior to writing image, which i did on first unit by writing empty file first

XW.v6.1.4# cat /proc/mtd 
dev:    size   erasesize  name
mtd0: 00040000 00010000 "u-boot"
mtd1: 00010000 00010000 "u-boot-env"
mtd2: 00100000 00010000 "kernel"
mtd3: 00660000 00010000 "rootfs"
mtd4: 00040000 00010000 "cfg"
mtd5: 00010000 00010000 "EEPROM"

I was able to build a small kernel which I now try to put on the board, but I find my self that dd'ing somehow changes some bits:

XW.v6.1.6# hexdump -C uImage.lzma    | head -n 4
00000000  27 05 19 56 b6 25 12 8a  5d 10 9c 8f 00 06 82 dc  |'..V.%..].......|
00000010  80 06 00 00 80 15 45 d0  c4 fd 20 8c 05 05 02 03  |......E... .....|
00000020  4c 69 6e 75 78 2d 35 2e  31 2e 30 2d 6e 65 78 74  |Linux-5.1.0-next|
00000030  2d 32 30 31 39 30 35 31  30 2b 00 00 00 00 00 00  |-20190510+......|

XW.v6.1.6# dd if=uImage.lzma of=/dev/mtd2 bs=64K count=16
6+1 records in
6+1 records out
426780 bytes (416.8KB) copied, 1.420927 seconds, 293.3KB/s

XW.v6.1.6# hexdump -C /dev/mtd2    | head -n 4
00000000  27 05 19 56 b0 20 00 8a  58 10 98 8a 00 06 82 d8  |'..V. ..X.......|
00000010  80 00 00 00 80 00 00 00  80 84 20 84 05 05 02 03  |.......... .....|
00000020  4c 49 40 51 20 05 20 28  31 24 20 24 68 20 48 60  |LI@Q . (1$ $h H`|
00000030  2c 30 30 21 30 20 34 20  30 22 00 00 00 00 00 00  |,00!0 4 0"......|

@guifipedro @psyborg any idea what that could be?

Ok, that should be:

XW.v6.1.6# dd if=uImage.lzma of=/dev/mtdblock2 bs=64K count=16

The flash block was not erased first. NOR flash lets you change a 1 bit to a 0 with a single write, but to change any 0 to a 1 the whole block needs to be erased. This is usually done by running mtd write which includes an erase routine.

Good news, I was able to boot a totally striped down openWRT 4.14 kernel, which of course wasn't able to reach userspace. But that confirms, that:
a) we can write the mtd partition via ssh
b) u-boot does not check any special kernel signature

Now I'll need to find out how to build a kernel small enough to fit the device.

1 Like

enable preinit, when kernel loads, hit reset button to enter failsafe, flash full-featured image from there

I don't know how you proceed in these cases, but while this is not solved we should warn future users in the openwrt wiki site for this device [1] that at the moment new versions are not working. That there is a "work in progress" and link to this topic (I don't know if there are other opened)

@tmomas what do you think?

[1] https://openwrt.org/toh/ubiquiti/nanostationm5

Good idea! Can you please edit the devicepage?

Yes, finally https://openwrt.org/toh/ubiquiti/nanostationm5