This looks like they are using gluebi, which emulates MTD devices on top of UBI volumes... To see the real MTD flash layout of the stock firmware dmesg will be better, /proc/mtd is not a good source to find the layout.
Hmm, you think so?
Was gluebi a thing in 2016 (when this firmware was made)? dmesg reveals nothing which suggests something other than what I wrote in the first post. I checked and dmesg only shows what the bootlog does.
The bootlog shows basically the same things as what the uboot commands and proc/mtd reveal. 
For people who are using legacy software and yet want to make use of NAND flash in a way which includes wear-leveling and all that, yes. As in this case they are even storing wifi calibration data inside an UBI volume (a very uncommon decision...), I guess using gluebi is actually the natural choice in this case if one doesn't want to modify the vendor driver which is made to read this data from MTD...
Not quite. dmesg reveals the start offset of MTD partitions, while /proc/mtd only exposes length and block size, also lacking any trace of the underlying device.
Sounds right. Could you briefly review the captured bootlogs and see if you find anything more interesting regarding the mtd? I don't think I see anything well described. I see memory offsets for some things, but those are once loaded into memory, no?
The erase-size of these (fake) MTD partitions is also a clear indicator that gluebi (or a similar vendor-specific MTD emulation on top of UBI) is being used. Only the MTD partitions listed in dmesg are actually real and should go to DTS:
0x000000000000-0x000000080000 : "U-Boot"
0x000000080000-0x000008000000 : "ubi"
That matches also with what you posted on github:
The only slightly strange thing here is that caldata is stored inside a UBI volume, hence we will need to extract it in userspace and supply it via owl-loader to ath10k driver (which should be fine and easy to do).
The more problematic issue are the MAC addresses assigned to the board which are stored in the Environment UBI volume. Here it will be needed to either assign them (a bit late) in userspace as well, or implement nvmem-cells on top of UBI, which will need dt-bindings for UBI and all that. @rmilecki may know what are the plans for that, if any...
Thank you @daniel - It's less of a rabbit hole now.
The MAC addrs in the OEM firmware are mounted to a text file, which is just a char device to read the MTD. But the MACs are stored in one of the MTD partitions. So those are also available via the same mechanism you described.
The wifi may also load its MACs in a similar way, by pointing to a memory offset, if I recall correctly.
Are there any openwrt examples in the wild you could point to?
Also, do you think the erase sizes are actually in line with being not a physical block size, but a logical one? (slightly less than the 131k, but 129k)
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?