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.
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.
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.
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.
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.
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.