Adding OpenWrt support for Xiaomi AX3600 (Part 1)

I tried another approach: Leave the wan interface as it is and add the wifi to the wan net. - but also no luck.

I probably can't adopt the config 1:1 for the time being, since the port names alone (eth0-eth3 vs. eth1-eth4) are different.

In menuconfig, did you select kmod-qca-nss-drv-bridge-mgr as 'module' (M) or built-in (*)?

If you selected (M) then it's built the kernel module as a package module you can install with opkg, which is why you don't see it with lsmod.

As well as kmod-qca-nss-drv-bridge-mgr, you'll need the nss-firmware, that's located in menuconfig under Firmware, nss-firmware-ipq8074. Again select this as built-in (*).

1 Like

built-in - but thx for the clarification because i was unsure at this step.

I didn't do that - so I will have to strain the little pi again.

Short question: When i exit menuconfig the config is saved for the next make or do i have to save it explicitly anyway?

I tried this, and in this case everything works well.
Connected WAN port of the AX3600 to the upstream router as a DHCP client, enabled the normal NAT LAN >WAN on AX3600, configured its own network and enabled DHCP on AX3600. And now on the laptop, when switching between networks (the main wifi network on the main router, and the wifi network on the AX3600), connectivity is not lost.

Moreover, I noticed that the problem is reproduced even without Wi-Fi, on LAN ports. How to reproduce:

Connecting the laptop with a cable to the main router - everything works.
Switching the laptop from the LAN port of the main router to LAN1 on AX3600, and LAN2 on AX3600 connect to the LAN port of the main router - no connectivity.
Switching the laptop back to the LAN port of the main router - the connectivity appears.

All this despite the fact that all LAN-ports of AX3600 is in bridge.

When you exit menuconfig. it prompts you to save changes (if you've changed something). Then make should pick up the changes, but depending on what's changed you may need to remove the tmp directory for make to pick up the changes.

I've tried building an image like you did (without nss-firmware-ipq8074 and I could still see kmod-qca-nss-drv-bridge-mgr with lsmod, so likely there's something else wrong with your build.

Can you run "./scripts/" in the build directory and post the output here?

Like I explained, the forwarding configuration for the switch is actually set in the DTS, quite literally hardcoded.
So even if you move the interface the switch itself won't forward the traffic due to shitty QCA drivers.

@robimarko is this set in the mistery option in that big table in the dts?

No, it's the lan_bmp and wan_bmp under the switch.
From what I gathered, those tables under the switch are finally used for some kind of QoS/QM in the switch.

Someone should thinker with that, there must be a logic there...

It's all a big mess of magic values and half-documented registers, it looks optional honestly.
The tricky part is the "UNIPHY", essentially a much more powerful version of PSGMII PHY HW block to which all of the PHY-s are connected.

God how much i would love to have a documentation of that mess...
It must be very messy yet so powerful

Yeah, me as well.
Then we could actually get it decently supported.

Would be really funny if under the hood it's just qca8k another time.... But i doubt... With all the nss interaction and interrupt stuff

Well, the 1G switching looks like copy/paste from IPQ40xx.
But I don't know whether 2.5G and 10G go through the switch as well or they are directly connected to the ethernet controller.

The specs mention 3 Ethernet SERDES, so it looks like they are connected to the Ethernet controller directly.
Only 1G ports should be switched again.

On recent version of OpenWRT and on other router, I saw that the switch/lan configuration is done differently: each LAN port is represented as a separate interface, and there is usual linux-bridge over all LAN-interfaces/ports. And there is no virtual switch device.
In our case, this can not be done?

This is done here as well, but again the forwarding config is hardcoded in the DTS meaning that the WAN port wont forward traffic directly to other ports, only to the CPu

does the ssdk provide some documentation with define or something like that?
Wonder if we can hack something to make the 1G switch work...

Yeah, there is a lot of stuff under HPPE and the UniPHY defines are under the header includes.
The issue is that we cant just hack a switch driver together as the NSS-DP Ethernet driver fetches stuff from SSDK directly using the "FAL" ops, this could probably be somehow ported to use standard stuff

Mhhh I need to check that... Anyway the complexity of the fal (and also the entire ssdk driver) is the massive use of helper and define to abstract everything. That makes everything complex to understand and not that linear...

I notice that by watching how LAG is implemented for qca8k in ssdk. Slim code but you have to check 4 source file to understand what even one line does.

Can't understand if they made all of that on purpose.

Yeah, the FAL complicates everything, even the stupidly simple stuff.

Its intentional as they use that as the API for all other networking parts to be able to poke/set/get whatever they want and have "standard" ops for the switching/PHY part