Problem with AR9341 and 23.05.4

For Developers
1

Hi,
I'm trying to port OpenWRT to a new device based on AR9341, but I've encountered a problem. The kernel boots, however at some point it hangs. Below I paste the moment when this happens.

[    9.950560] procd: - ubus -
[   10.096354] random: ubusd: uninitialized urandom read (4 bytes read)
[   10.115216] random: ubusd: uninitialized urandom read (4 bytes read)
[   10.130055] random: ubusd: uninitialized urandom read (4 bytes read)
[   10.142911] procd: - init -
Please press Enter to activate this console.
[   11.312632] random: jshn: uninitialized urandom read (4 bytes read)
[   11.356051] random: ubusd: uninitialized urandom read (4 bytes read)
[   11.379251] random: ubus: uninitialized urandom read (4 bytes read)
[   11.561145] kmodloader: loading kernel modules from /etc/modules.d/*
[   12.189027] Loading modules backported from Linux version v6.1.97-0-g7753af06eebfb
[   12.196926] Backport generated by backports.git v6.1.97-1-0-g2431d56e
[   12.951615] PPP generic driver version 2.4.2
[   12.967926] NET: Registered PF_PPPOX protocol family

After about 30 seconds a reset occurs (probably by watchdog).
Has anyone encountered such a problem and knows how to solve it?

Additional information:

  1. I also tried to port OpenWRT to a new device based on QCA9533, in this case it succeeded for version 23.05.3 - OpenWRT worked fine. When I decided to upgrade to version .4, it also stopped working at the same point.
  2. In both cases I am using the latest stable U-Boot 2024.7, which I ported myself to make it work properly.
  3. Both devices have 16MB Flash and 64MB RAM.
2

Describe exact moodels, maybe you have your work visible on github? Maybe new topic for each?
ath9k is rock solid.

3

The model is MT02 no-name brand.
I wanted to post everything on my github, but only after I test everything and it works.
Also, this model (MT02) is common to QCA9533 and AR9341.
Externally they are no different, only after opening the case you can see the difference.
This is the cheapest repeater you can find on AliExpress, and since it has potential after modification (changing from 8MB to 16MB flash), I wanted to add support for it in OpenWRT.
I think I can further add that only the squashfs-sysupgrade image wants to boot, the initramfs-kernel version does not boot, there is only the error "lzma compressed: uncompress error 7".

4

You can open thread for each and solicit help. Like drop OEM art dump to find venndor mac address etc.

5

Err 7 means decoder started at wrong offset, ie not where lzma stream starts.

6

These repeaters are manufactured from recycled parts, making the ART rather random, i.e. it contains data from the device from which they obtained it.
I managed to find the MAC offsets, as I wrote for QCA9533 OpenWRT version 23.05.3 worked fine, but now it does not work.
It's probably best, though, if I upload everything to github and then maybe it will be easier to find the problem.

7

Ok, I uploaded all the changes I created to my repository. I hope it will be easier to solve the problem now. For the moment we are focusing on the version with AR9341.

8

I did some more testing and on the latest snapshot it also hangs at the same moment.
Since for two different versions the problem occurs at the same moment and manifests itself in the same way, maybe the cause lies in the configuration?

In the original firmware that ran on it from the factory (an old LEDE version), the events in the log for that moment are as follows:

[    8.633545] PPP generic driver version 2.4.2
[    8.641081] NET: Registered protocol family 24
[    8.717943] ieee80211 phy0: Atheros AR9340 Rev:1 mem=0xb8100000, irq=47
[    8.837468] kmodloader: done loading kernel modules from /etc/modules.d/*
9

It seems to me that the cause of the problem lies here:

[    0.934542] ag71xx 19000000.eth: Could not connect to PHY device. Deferring probe.
[    1.620109] ag71xx 1a000000.eth: connected to PHY at fixed-0:00 [uid=00000000, driver=Generic PHY]
[    1.630276] eth0: Atheros AG71xx at 0xba000000, irq 5, mode: gmii

It appears that GMAC1 is initialized and available as eth0, but GMAC0 is not working for some reason.
Does anyone know what could be the cause?

10

It would be helpful if someone with an AR9341-based device would try running version 23.05.4 or better yet a snapshot and let me know if it works and what the bootlog looks like.

11

Further insights:
If we disable eth0 in the DTS, then errors related to this interface do not appear, so it is admittedly not ideal, but in this case the WAN port is not physically accessible anyway.
So it seems that this is not the reason for the hanging.

After removing the PPP-related packages, the hanging continues, only the last line written out becomes:
[ 17.551501] Backport generated by backports.git v6.1.97-1-29-gf1d24a3683b2

Can someone help me identify the problem more precisely?

12

I managed to find a “solution” to the problem: in DTS you need to disable wmac, then booting will not crash.
Of course, a new problem arises - no WiFi. To fix this problem, you would have to check more carefully in the kernel and patches what can cause it, because it affects not only AR9341, but also QCA9533.
It is possible that this problem also affects other SoCs, but I have no way to check this.
I think this could be the reason for mass bricking of routers by OpenWRT in the future, so it's worth someone taking a deeper look into it. I, unfortunately, don't have any more time to do so.

13

the single ethernet port on a qca9531 device I have works as such:

&eth0 {
        status = "okay";

        phy-handle = <&swphy0>;

        nvmem-cells = <&macaddr_art_6>;
        nvmem-cell-names = "mac-address";

        gmac-config {
                device = <&gmac>;

                switch-phy-addr-swap = <1>;
                switch-phy-swap = <1>;
        };
};

&eth1 {
        compatible = "syscon", "simple-mfd";

        nvmem-cells = <&macaddr_art_0>;
        nvmem-cell-names = "mac-address";
};

Wifi crashing could be worked around with

&wmac {
        status = "okay";
        qca,no-eeprom;
};

sounds like ART is not where the calibration is.

14

Thank you for your suggestions, in the end it turned out that the culprit of all the problems was U-Boot, or rather bugs in the implementation of AR934x support in U-Boot. I managed to fix them and OpenWRT is now working properly.