mediatek: filogic: convert ASUS device to use NVMEM-on-UBI #14676
Conversation
github-actions
bot
added
the
target/mediatek
| }; | ||
| }; | ||
| }; | ||
| }; | ||
|
|
||
| &ubi_factory { |
There was a problem hiding this comment.
I know we used to do that a lot in OpenWrt but I have no idea why and I think recently we do less of such referencing.
If ubi_factory is in the same file (just few lines above) why not put nvmem-layout directly there? I think that would help reading DTS fle.
There was a problem hiding this comment.
Only makes sense to do with dts files that reference dtsi definitions.
There was a problem hiding this comment.
I used to agree but was criticized for that and told that references are ok also if they reduce the level of indentation (which is why I applied this here). I don't mind either way, my screen is big enough and my text editor smart enough for me not to care.
There was a problem hiding this comment.
My 2 cents when the nvmem conversion was done all the reference were done as it was easier to handle them with a script. But the normal way would be that if the node is in the same dts then the node should be changed directly.
dangowrt
force-pushed
the
filogic-asus-nvmem-on-ubi
branch
from
9dbd6ac
to
7c93252
Compare
|
Could we iterate MAC addresses for rest of the eth ports? |
|
@patrykk The idea is to always assign MAC addresses exactly like the stock firmware does. You can of course divert from that in your configuration and assign custom MAC addresses to each port. |
also ASUS RT-AC58U (ipq4018) |
|
ASUS TUF-AX4200 Made a quick build with this PR included and after the flash it went into a boot loop. Was running 6.1 without issues. I'll see what the serial output says when I get time. |
|
|
@Gingernut1978 Fix: #14546 (comment) |
Doesn't the mediatek/filogic platform have the patch already? |
|
@dangowrt , Why did you break everything? |
dangowrt
force-pushed
the
filogic-asus-nvmem-on-ubi
branch
from
7c93252
to
43cf6bf
Compare
Because I don't actually have the board and any knowledge about the stock bootloader and the cmdline options it passes to the kernel 🤷 This is exactly why I wanted people who actually own the hardware to test this. And turns out bootloader passes Please try again with that and let me know if that works now. |
I wonder where that diff --git a/target/linux/mediatek/dts/mt7986a-asus-tuf-ax4200.dts b/target/linux/mediatek/dts/mt7986a-asus-tuf-ax4200.dts
index adaaae11ed..ad1406c93d 100644
--- a/target/linux/mediatek/dts/mt7986a-asus-tuf-ax4200.dts
+++ b/target/linux/mediatek/dts/mt7986a-asus-tuf-ax4200.dts
@@ -218,7 +218,7 @@
spi-tx-bus-width = <4>;
spi-rx-bus-width = <4>;
- partitions: partitions {
+ partitions {
compatible = "fixed-partitions";
#address-cells = <1>;
#size-cells = <1>;
@@ -241,6 +241,9 @@
};
};
};
+
+ partitions: dummy {
+ };
};
};Edit: I found this comment in |
dangowrt
force-pushed
the
filogic-asus-nvmem-on-ubi
branch
from
43cf6bf
to
0cfff3f
Compare
Asus programmers love to do this. Here's a recent example: https://forum.openwrt.org/t/add-support-for-asus-rt-ax89x-ax6000/137003/328 From u-boot sources: https://github.com/u-boot/u-boot/blob/83cdab8b2c6ea0fc0860f8444d083353b47f1d5c/common/fdt_support.c#L995-L1009 From IDA disasm uboot AX4200: All 3 devices (AX59U/AX4200/AX6000) automatically support NAND flash drives in 2 sizes: 128MiB and 256MiB |
|
Not booting on latest changes. |
|
@dangowrt All 4 devices (AX52/AX59U/AX4200/AX6000) automatically support NAND flash drives in 2 sizes: 128MiB and 256MiB |
Strange. Despite kernel cmdline being flushed and labels removed from device tree the bootloader still manages to completely replace the content of the And all that for something as useless as adjusting the size -- just always having 256 MiB in DTS will be ok, Linux will warn and truncate the final partition (UBI) to the flash size on 128 MiB, but that's absolutely ok and actually what we want in this case. PS: I thought ASUS was better than others because they were smart enough to use UBI. Turns out they are over-smarting things so much that in the end it makes it worse. |
This is where they outdid themselves:
|
Another workaround in AX3600.dtsi to workaround Xiaomi U-Boot smartness! 🙄 |
dangowrt
force-pushed
the
filogic-asus-nvmem-on-ubi
branch
from
0cfff3f
to
81de20c
Compare
|
I've added some (guessed) work-around for those borked bootloaders.
How do they pick pointer to OF node @Gingernut1978 Can you give it another try please? |
|
|
dangowrt
force-pushed
the
filogic-asus-nvmem-on-ubi
branch
from
81de20c
to
5e36515
Compare
|
Not sure if this is going to work, but my hope is that U-Boot will now replace a dummy bait node instead of the actual flash partition definitions... |
|
@Gingernut1978 can you give it another shot please? |
|
@dangowrt definitely, just need to find the time. |
bootlog: https://pastebin.com/4at7ayAX Looking good. With latest changes you nailed it. All MACs are correct and wireless radios working. Anything you would like me to try or check? Nice job. |
The bootloader was successfully deceived |
|
Works on AX59U! [ 0.795263] 2 fixed-partitions partitions found on MTD device spi0.0 ... |
You turned out to be absolutely right! |
Serial console bootlog including bootloader would be interesting, but just out of curiosity, not worth stealing your time just for that. @remittor You reckon it's safe to assume that if it works on AX4200 it will work on AX6000 in the same way? |
Yes. I looked at the bootloaders from both devices in disasm and did not see any differences at all (except for the names of TRX images). |
|
@dangowrt sorry for offtopic. Can we use such method (NVMEM) if WiFi EEPROM data and MAC address are the files in Ubifs volume? |
|
@csharper2005 while this is of course theoretically possible, it would kinda open a can of worms to have the kernel read NVMEM content from (any) filesystem... I'd prefer to keep that in userspace. |
Use newly added support for NVMEM-on-UBI instead of extracting MAC address and WiFi EEPROM data in userspace. Signed-off-by: Daniel Golle <daniel@makrotopia.org>
Use newly added support for NVMEM-on-UBI instead of extracting MAC address and WiFi EEPROM data in userspace. Signed-off-by: Daniel Golle <daniel@makrotopia.org>
Use newly added support for NVMEM-on-UBI instead of extracting MAC address and WiFi EEPROM data in userspace. Signed-off-by: Daniel Golle <daniel@makrotopia.org>
dangowrt
force-pushed
the
filogic-asus-nvmem-on-ubi
branch
from
5e36515
to
1794309
Compare
Some recent ASUS devices started storing their factory data inside a UBI volume. Instead of extracting WiFi EEPROM data and MAC addresses in userspace, use the now available new way to reference the NVMEM bits in device tree.
Lacking the hardware no runtime testing has been done on my end, hence I rely on users to give feedback if the works as intended.
User tested and confirmed MAC addresses and WiFi EEPROM: