I just bought Ubiquity Nanostation M5 XW. Flash openwrt 15.05.1. Connect by telnet, set password. Then I connect thru ssh and setting some items. Reboot and can't connect thru ssh. Later I discover, that password still not set. So, I discover that this device is "system type             : Atheros AR9342 rev 2" with 64MB RAM and 32 flash. Previous version has 32/8MB.
Interesting lines from dmesg:

[    8.250000] mount_root: jffs2 not ready yet, using temporary tmpfs overlay
 ...
[   20.220000] jffs2_scan_eraseblock(): End of filesystem marker found at 0x0
[   20.220000] jffs2_build_filesystem(): unlocking the mtd device... done.
[   20.230000] jffs2_build_filesystem(): erasing all blocks after the end marker...
[   20.260000] jffs2: Newly-erased block contained word 0x19852003 at offset 0x00400000

I flash LEDE 17.01.2, but after reboot stil in openwrt 15.05.1 :-( So this device is not remember anything.
Maybe is problem only with more flash memory and filesystem is confused?

Apparently they are using a new type of flash chip which the OpenWrt spi driver cannot erase.  LEDE may be able to erase that chip.   Earlier in the log you should see the chip identified, just before the mtd blocks are created.

Since OpenWrt can't erase the chip, it can't flash LEDE.  But you could try a TFTP flash to LEDE through the bootloader.

The TFTP mode in the bootloader is activated by holding down the reset button while turning the power on, and keeping it held down during the boot until the signal LEDs start flashing back and forth.  At that point you can TFTP push a "factory" version of LEDE to the device at 192.168.1.20.

Beware of flashing any Ubiquiti stock firmware.  Newer stock firmwares contain locking features, and they may also replace the bootloader with a locked one.  OpenWrt or LEDE will not change your bootloader.

It would be a good idea before doing anything to use the running 15.05 to extract the bootloader and ART partitions and scp them to a safe place.  Those will be important to have if it comes down to directly programming or changing out the flash chip.

(Last edited by mk24 on 27 Sep 2017, 22:18)

Hello mk24, thanks for help. I found this in log:

[    0.490000] m25p80 spi0.0: found mx25l6405d, expected m25p80
[    0.500000] m25p80 spi0.0: mx25l6405d (8192 Kbytes)
[    0.500000] 5 cmdlinepart partitions found on MTD device spi0.0
[    0.510000] Creating 5 MTD partitions on "spi0.0":
[    0.510000] 0x000000000000-0x000000040000 : "u-boot"
[    0.520000] 0x000000040000-0x000000050000 : "u-boot-env"
[    0.530000] 0x000000050000-0x0000007b0000 : "firmware"
[    0.540000] 2 uimage-fw partitions found on MTD device firmware
[    0.550000] 0x000000050000-0x00000016f467 : "kernel"
[    0.560000] 0x00000016f467-0x0000007b0000 : "rootfs"
[    0.560000] mtd: device 4 (rootfs) set to be root filesystem
[    0.570000] 1 squashfs-split partitions found on MTD device rootfs
[    0.570000] 0x0000003a0000-0x0000007b0000 : "rootfs_data"
[    0.580000] 0x0000007b0000-0x0000007f0000 : "cfg"
[    0.590000] 0x0000007f0000-0x000000800000 : "EEPROM"

I expect that must save some of these devices?

root@OpenWrt:/tmp# cat /proc/mtd 
dev:    size   erasesize  name
mtd0: 00040000 00010000 "u-boot"
mtd1: 00010000 00010000 "u-boot-env"
mtd2: 00760000 00010000 "firmware"
mtd3: 0011f467 00010000 "kernel"
mtd4: 00640b99 00010000 "rootfs"
mtd5: 00410000 00010000 "rootfs_data"
mtd6: 00040000 00010000 "cfg"
mtd7: 00010000 00010000 "EEPROM"

mtd0 and mtd1 is probably bootloader. But not known which is ART.

It is an 8MB chip, and mtd7 is ART.

Yesterday I tried tftp flash lede-17.01.2-ar71xx-generic-ubnt-nano-m-xw-squashfs-factory.bin. But:

received ACK <block=7168>
sent DATA <block=7169, 412 bytes>
received ERROR <code=2, msg=Firmware check failed>
Error code 2: Firmware check failed

Hi, I have a idea: tftp flash some old version of stock ubiquity version and then try new LEDE thru Ubiquity web interface.

Bad idea?

Yesterday I went to place where is NSM5 and tftp flash XW.v5.6.8.29413.160715.1602.bin as decribed in https://wiki.openwrt.org/toh/ubiquiti/a … are_issues.

Upload seems OK (I tryed it twice):

received ACK <block=14400>
sent DATA <block=14401, 473 bytes>
received ACK <block=14401>
tftp> 

But device is not responding either 192.168.1.20 either 192.168.1.20. So no choice but climb onto the roof and bring device on table :-(