Nanobeam AC Gen 2?

Thanks for testing! I believe this will affect every device with mx25l12805d flash.

Did u try going from 4.X Kernel to 5.4 without doing a "-n"? So erasing of the flash?

Guys...I think im in the same boat as you guys...what should i do now?

I did not use -n. The saved settings were initially present but it would not reboot properly (the top signal light just flashing indefinitely), so I had to TFTP recover and start over.

Could u please open the device again and look at the flash chip which model it is? And maybe make some good photos?

Or maybe this is enough: https://fccid.io/SWX-NBE5ACG2W/Internal-Photos/Internal-Photos-3546294

It is a mx25l12835f (16-pin package).

I glued the Nanobeam AC Gen2 back together and deployed it in my home network, so that one is off the table. Mostly because I was tired of looking at it taken apart.

However I do have a Nanostation AC loco which is the same "XW" platform and the same MX25l12835F flash chip, so I tested it with today's snapshot (for that model). It has the same problem. There are errors "newly erased block contains" and the overlay fs is not persistent. So I would say there's a major problem here with support for that whole platform.

Unlike the Nanobeam AC the Nanostation AC loco is very easy to open the case and connect serial.

1 Like

Just to be sure, is the flash chip also a 16-pin package? I've put an MX25L12835F chip in my TP-Link device and I don't have any issues at all. But I've used the 8-pin version. Other devices with this chip also don't appear to experience any issues, even the ones added with a recent kernel.

Yes it's a 16 pin chip.
All the markings on the top of the chip are:

(MXIC logo) X182459
MX25L12835FMI-10G
18A00406

Edit: It looks like the hardware write protect of the flash chip is controlled by something on the board, most likely a GPIO. There is a transistor driving pin 9 of the chip. Since the transistor inverts the logic, the GPIO needs to be low to allow writing. If it is in input mode a resistor pulls it high so writing is not allowed.

I'm going to try to find out which GPIO it is.

Did some more testing on the Nanostation AC Loco and a snapshot build. It looks like the write protect circuit really isn't an issue since the GPIO stays low thus hardware write protection is inactive. I defeated the circuit by grounding out the transistor base so the chip should stay unprotected all the time.

There are still problems with jffs. Installing a package is not persistent. The only error that is apparent is there are "dead" and "orphaned" blocks. This same message occurs the same way on repeated reboots without having written anything to the filesystem.
[ 9.456629] jffs2: notice: (533) jffs2_build_xattr_subsystem: complete building xattr subsystem, 20 of xdatum (14 unchecked, 6 orphan) and 30 of xref (4 dead, 6 orphan) found.

For what it's worth, I see these dead/orphan xattr notices on my flash chips (SOP-8, TP-Link devices) too. No issues with persistence on any of them.

[    0.296639] spi-nor spi0.0: mx25l12805d (16384 Kbytes)
[   15.146007] jffs2: notice: (516) jffs2_build_xattr_subsystem: complete building xattr subsystem, 12 of xdatum (0 unchecked, 3 orphan) and 15 of xref (3 dead, 0 orphan) found.
[    0.300177] spi-nor spi0.0: gd25q128 (16384 Kbytes)
[   15.202175] jffs2: notice: (517) jffs2_build_xattr_subsystem: complete building xattr subsystem, 36 of xdatum (31 unchecked, 3 orphan) and 60 of xref (3 dead, 0 orphan) found.
[    0.307247] spi-nor spi0.0: w25q128 (16384 Kbytes)
[   10.022240] jffs2: notice: (532) jffs2_build_xattr_subsystem: complete building xattr subsystem, 16 of xdatum (9 unchecked, 1 orphan) and 23 of xref (1 dead, 0 orphan) found.