No, as this is the first device to be seen in the wild which uses UBI to store calibration data and MAC addresses. As I said, in case of the calibration data there is an exsiting solution (owl-loader) which allows supplying it from userspace, so that can easily be used to supply data read from that UBI volume. However, MAC addresses will have to set in user-space for now as nvmem-cells cannot (yet) be used on top of UBI volumes.
Yes, the size exactly corresponds to UBI logical erase block size (0x1F800 if used on NAND flash with 0x20000 block size, which is the case here).
1 Like
Perhaps, considering its age, OEMs figured out that this wasn't a great idea and stopped doing it.
Well, I don't rely on this device, so I'm OK with frying it if you have any creative ideas to get it up and running.
The owl-loader seems useful for the Atheros parts, but the rest of the device is Lantiq. Would that matter?
Well, I kinda think the opposite: This was someone with a very progressive mindset designing this firmware. A bit too progressive maybe...
Generally, using UBI for everything is a very good idea. Using legacy hacks like gluebi is not very clean though, but from a OEM perspective it provides a viable shortcut.
Having proper support for reading MAC addresses and calibration data from UBI volumes in the Linux kernel would be nice, actually Linux kernel documentation lists it as possible thing to support in future:
The AR10 SoC family is not sufficiently supported by OpenWrt, so this will need to fiddling around. All I could find when searching for GRX390 is this other device:
Maybe @hauke knows more about what is still missing there?
Are both 2.4GHz and 5GHz wifi provided by QCA chips? Or is one of them Lantiq WAV300 or similar? (Lantiq/Intel Wifi is not supported at all due to lack of decent drivers)
In case of the QCA radio, owl-loader will need to be accompanied by a user-space script which extracts the calibration data from the UBI volume.
Dev wiki shows
PXB 4389 EL V2.17 (GRX389) - AnyWAN GRX330 Network Processor (SLLF6)
Bootlogs show for 5GHz:
mtlk mtlk.0: firmware: requesting ProgModel_BG_CB_ar10.bin
mtlk mtlk.0: firmware: requesting ProgModel_BG_CB_40_RevI_ar10.bin
Bootlogs show for 2.4GHz:
mtlk mtlk.0: firmware: requesting ProgModel_BG_nCB_ar10.bin
mtlk mtlk.0: firmware: requesting ProgModel_BG_nCB_40_RevI_ar10.bin
and the mtlk stuff sets up wifi. The rest of the LAN stuff is Lantiq (PXB 4389).
If I am not mistaken, some openwrt Fritz!Boxes use these chipsets, and I found the GPL source for the D-Link DWR-966 which has a very similar board, and a(n old) DTS.
So Lantiq: switch ports, WAN port
Ath: both wifi?
Edit: the hardware list has:
Chips (2.4GHz):
Lantiq PSB 82312 M
v1.2
XWAY tm WRX312
Fully integrated 11n 2x2 RF/PA chip
Chips (5GHz):
QCA9880-BR4A
FNSW920.U9
This still requires some work but it's a work in progress. First we need support for NVMEM layouts which is a matter of weeks. Meanwhile I'll try to get back to DT bindings for UBI volumes. Once we get those 2 things the rest should be simple.
Oh cool 
Does this mean one could simply use nvmem-cells in the above DTS, to describe the mtd partitions as found in /proc/mtd?
@rmilecki I've also started building bindings for UBI and also realized that UBI will have to be changed in the way it starts -- currently UBI is attached via late_initcall, and that's too late for other drivers to be using anything provided by UBI, such as nvmem-cells inside UBI volumes. Making UBI behave more like other MTD users improves that and allows to attach UBI volumes in parallel with other things happening during boot (my motivation here was mostly to reduce boot time, but I had the nvmem USE case in mind as well).
An earlier version of that patch is here, I've further improved it in the meantime and will post an updated version soon: https://patchwork.ozlabs.org/project/linux-mtd/patch/a547e14ac90af041e8135af5fed9272931dda463.1671738005.git.daniel@makrotopia.org/
1 Like
It's not that easy, because what you see there are not actually MTD partitions. Rather they are UBI volumes living on a UBI device which uses an actual MTD partition. New device-tree bindings will have to be introduced for that, both UBI device to MTD device (that's quite easy and @hauke has suggested that in the past and got rejected, I've also tried this more recently) and also UBI volumes (for which it will be even more tricky to convince upstream maintainers).
1 Like
Supporting 2.4 GHz WiFi will be hard if not impossible....
That spectrum is overcrowded and... well, don't advise it. But there are other routers out there that don't have 5GHz. I guess many would be OK without 2.4
How is this patch coming along? Patchworks shows it still as 'new' but I haven't followed any discussion. Is it available as a patch in openwrt during compile time?
ping. Wonder whether this made it in? Don't know how to interpret NA for State..
Just re-sent an updated version of the series, hoping that it will get more attention, see https://patchwork.ozlabs.org/project/linux-mtd/list/?series=366619
1 Like
Latest seems to be this one.
2024-03-27 Edit: currently this one (which hasn't been accepted yet). Otherwise currently accepted is from December.
One day we'll get UBI to provide NVMEM
Part of Linux v6.9 
And backported to OpenWrt Linux 6.1 and Linux 6.6.
1 Like
You absolute hero.
Is this patch series faithful to the initial intention? Or did you have to make some compromises along the way?
No major changes, functionality as intended and having DT-bindings for UBI is a nice side-product. Still working on providing MTD/UBI upstream folks with (QEMU-based) test-cases, so the new way of attaching UBI via DT can also be part of regular automated tests, which would of course be great.
Having DT-bindings for UBI at all is already great, and would now easily allow defining UBI-related properties (fastmap yes/no, min. number of spare blocks, ...) as well as selecting UBI volumes to be used as ubiblock devices in Device Tree (instead of using kernel cmdline parameters for all that).
Sadly (but somehow also expected) things for NVMEM-on-eMMC are more complicated and less promising at this point, see https://patchwork.kernel.org/project/linux-block/cover/cover.1711048433.git.daniel@makrotopia.org/
But that's another story...
1 Like