Nanobeam AC Gen 2?

Yes both radios work. Realize that though the 2.4 radio is fully supported in software, its hardware has only a single tiny antenna so it is only suitable for close range.

I'm not seeing any problems with the jffs like you were. It looks like the flash chip is readable, but not responding to erase or write requests.

Did u try 5.4 kernel? Since that is the problematic kernel version for me.

I added a bug report: https://bugs.openwrt.org/index.php?do=details&task_id=3272

I can confirm that the 5.4 build of today's snapshot for Nanostation AC does not work on my Nanobeam AC Gen 2. The same failure to erase / write to the flash occurs. 19.07.3 ath79 builds work properly.

What isn't clear is whether this build would also crash on a Nanostation AC, or is there a real difference between the Nanobeam AC Gen2 and Nanostation AC. I don't have a Nanostation AC to test on.

1 Like

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.

Ping @robimarko
I saw you did changes to the mx25l12805d. Are u experience similar jffs2 issues with that chip?

I have that one on another board and we dont use jffs2 at all.
We just need small blocks for a custom purpose in Linux and U-boot.

So thats the reason.

1 Like

So probably it is not the spi nor driver? I should have a look at the jffs2?

Honestly, I really don't know.
I don't use ath79 HW at all and have some really old AR9k leftovers maybe.

I would suggest look at git log of changes between 5.4 and 5.9.
There could potentially already be a fix upstream

1 Like

I will try some commits. Sadly, I can not just apply the mtd stuff from 5.9 kernel. :confused: When I would know if it is fixed upstream.

I insterted the spi-nor.c and spi-nor.h from 4.19 kernel in the 5.4. Same issue. :open_mouth:

I will try exchanging now jffs2 filesystem... xD Let's see what will happen.

Function is missing?

extern struct dentry *mount_mtd(struct file_system_type *fs_type, int flags,
		      const char *dev_name, void *data,
		      int (*fill_super)(struct super_block *, void *, int));