IPQ5018: Support for Linksys MX2000 Atlas 6 & MX5500 Atlas 6 Pro

georgem83 · 2024-02-12T19:16:38.609Z

Do you have any guidance?
Is it as simple as using the upstream QCA board-2.bin?
Or, extracting the regdb.bin from the board file and then copy it to the ath11k/QCN9074/hw1.0/ directory? hw_params in core.c for QCN9074 states:
.supports_regdb = false,
Should I use the QCA Swiss Army knife to extract it?

robimarko · 2024-02-12T19:24:55.042Z

They only publish BDF-s for reference boards so we cannot use them

robimarko · 2024-02-12T19:25:38.869Z

Yes, just put it there, but you need the ath11-bdencoder to unpack the board-2.bin

And yes, .supports_regdb needs to be set to true

lytr · 2024-02-12T19:30:20.571Z

I meant regdb, not BDFs
Can we use them to replace in BDF files?

It looks like the binary format of external and internal (inside BDF) regdb is different...

georgem83 · 2024-02-13T02:34:11.377Z

Thanks for your help. Will try and revert

georgem83 · 2024-02-13T04:58:34.622Z

that worked, had to extract the regdb from the upstream board-2.bin file and embed it in the stock board file using ath11k-bdencoder AND setting .supports_regdb to true.
I also see the frequencies match the stock FW. Awesome and thanks for your help!

Now back to troubleshooting ipq5018 wifi.

georgem83 · 2024-02-23T08:26:51.778Z

Pushed the latest code to my repo on github,

On 23.05/5.15, I've got the switch working in the initramfs image, but when I flash the factory image, it doesn't.
Seems again a reset issue. In initramfs, when 'phy-reset-gpio' in the DTS is set in the mdio1 node which the qca8337 switch is under, the traffic flows and the switch works. When reset-gpios is set instead, the switch still initializes but traffic doesn't flow.
When flashing to nand, both methods don't work. The switch is probed, initializes, but there's no traffic.
Any help/guidance would be highly appreciated!

On main/6.1, the switch comes up and there's traffic briefly, until the device crashes. SSDK/NSS-DP use some old DMA APIs that apparently don't work under 6.1, so we'll rely on @hzyitc's ongoing efforts to complete the mainline drivers for the phy, uniphy, and stmmac.

On the MX5500, the QCN9074 wifi radio comes up and works, though I haven't thoroughly tested.
I'm still unable to bring up IPQ5018 (2.4G) radio, it still crashes.

Drivers for (PWM) LEDs, PCIE, USB2/USB3 all work on both 23.05/5.15 and main/6.1.

georgem83 · 2024-02-26T09:17:04.630Z

Could it be that when the image is loaded from RAM, the clocks are set by uboot and, hence, traffic is flowing between the ipq5018 and qca8337 switches over the uniphy?

I looked at the yaml bindings definition of the GCC, and found that the clocks for gephy and uniphy are explicitly set (and perhaps must be?):

  clocks:
    items:
      - description: Board XO source
      - description: Sleep clock source
      - description: PCIE20 PHY0 pipe clock source
      - description: PCIE20 PHY1 pipe clock source
      - description: USB3 PHY pipe clock source
      - description: GEPHY RX clock source
      - description: GEPHY TX clock source
      - description: UNIPHY RX clock source
      - description: UNIPHY TX clk source

<-- cut -->

 clock-controller@1800000 {
      compatible = "qcom,gcc-ipq5018";
      reg = <0x01800000 0x80000>;
      clocks = <&xo_board_clk>,
               <&sleep_clk>,
               <&pcie20_phy0_pipe_clk>,
               <&pcie20_phy1_pipe_clk>,
               <&usb3_phy0_pipe_clk>,
               <&gephy_rx_clk>,
               <&gephy_tx_clk>,
               <&uniphy_rx_clk>,
               <&uniphy_tx_clk>;

my current dtsi looks as follows and is missing the gephy and uniphy clocks:

gcc: clock-controller@1800000 {
			compatible = "qcom,gcc-ipq5018";
			reg = <0x01800000 0x80000>;
			clocks = <&xo_board_clk>,
				 <&sleep_clk>,
				 <&pcie_x2phy>,
				 <&pcie_x1phy>,
				 <&usbphy1>,
				 <0>,
				 <0>,
				 <0>,
				 <0>;
			#clock-cells = <1>;
			#reset-cells = <1>;
			#power-domain-cells = <1>;

the clocks set point to nodes in the dtsi, for ex, the usbphy1 is the phy node for USB3.
If they need to be set, where do I point them to? The ess-switch (as that's the one that refers to the gephy and uniphy clocks)?
Or can I point directly to clocks in the GCC driver? such as:

gcc: clock-controller@1800000 {
			compatible = "qcom,gcc-ipq5018";
			reg = <0x01800000 0x80000>;
			clocks = <&xo_board_clk>,
				 <&sleep_clk>,
				 <&pcie_x2phy>,
				 <&pcie_x1phy>,
				 <&usbphy1>,
				 <&gcc GCC_GEPHY_RX_CLK>,
				 <&gcc GCC_GEPHY_TX_CLK>,
				 <&gcc GCC_UNIPHY_RX_CLK>,
				 <&gcc GCC_UNIPHY_TX_CLK>;

@robimarko, @hzyitc, @kirdes: any clue?

robimarko · 2024-02-26T10:18:19.353Z

To me its only logical to include them in the ess-switch node, but look into whether SSDK is even parsing for them

kimocoder · 2024-03-02T16:48:28.021Z

Maybe you find something interesting in this
ipq5018.dtsi

hzyitc · 2024-03-04T15:46:19.815Z

These clocks are from uniphy (or the uniphy part of internal phy), please check https://lore.kernel.org/all/TYZPR01MB5556FA040B07F48AFE544680C9762@TYZPR01MB5556.apcprd01.prod.exchangelabs.com/

Unfortunately, qca-ssdk doesn't register them as clock providers for dts. So you need to patch the gcc driver.

diff --git a/drivers/clk/qcom/gcc-ipq5018.c b/drivers/clk/qcom/gcc-ipq5018.c
index 2db9ab191c81..cd59bd42f2d7 100644
--- a/drivers/clk/qcom/gcc-ipq5018.c
+++ b/drivers/clk/qcom/gcc-ipq5018.c
@@ -338,8 +338,8 @@ static const struct parent_map gcc_xo_gpll4_gpll0_gpll0_out_main_div2_map2[] = {
 
 static const struct clk_parent_data gcc_xo_gephy_gcc_rx_gephy_gcc_tx_ubi32_pll_gpll0[] = {
 	{ .index = DT_XO },
-	{ .index = DT_GEPHY_RX_CLK },
-	{ .index = DT_GEPHY_TX_CLK },
+	{ .name = "gephy_gcc_rx" },
+	{ .name = "gephy_gcc_tx" },
 	{ .hw = &ubi32_pll.clkr.hw },
 	{ .hw = &gpll0.clkr.hw },
 };
@@ -354,8 +354,8 @@ static const struct parent_map gcc_xo_gephy_gcc_rx_gephy_gcc_tx_ubi32_pll_gpll0_
 
 static const struct clk_parent_data gcc_xo_gephy_gcc_tx_gephy_gcc_rx_ubi32_pll_gpll0[] = {
 	{ .index = DT_XO },
-	{ .index = DT_GEPHY_TX_CLK },
-	{ .index = DT_GEPHY_RX_CLK },
+	{ .name = "gephy_gcc_tx" },
+	{ .name = "gephy_gcc_rx" },
 	{ .hw = &ubi32_pll.clkr.hw },
 	{ .hw = &gpll0.clkr.hw },
 };
@@ -370,8 +370,8 @@ static const struct parent_map gcc_xo_gephy_gcc_tx_gephy_gcc_rx_ubi32_pll_gpll0_
 
 static const struct clk_parent_data gcc_xo_uniphy_gcc_rx_uniphy_gcc_tx_ubi32_pll_gpll0[] = {
 	{ .index = DT_XO },
-	{ .index = DT_UNIPHY_RX_CLK },
-	{ .index = DT_UNIPHY_TX_CLK },
+	{ .name = "uniphy_gcc_rx" },
+	{ .name = "uniphy_gcc_tx" },
 	{ .hw = &ubi32_pll.clkr.hw },
 	{ .hw = &gpll0.clkr.hw },
 };
@@ -386,8 +386,8 @@ static const struct parent_map gcc_xo_uniphy_gcc_rx_uniphy_gcc_tx_ubi32_pll_gpll
 
 static const struct clk_parent_data gcc_xo_uniphy_gcc_tx_uniphy_gcc_rx_ubi32_pll_gpll0[] = {
 	{ .index = DT_XO },
-	{ .index = DT_UNIPHY_TX_CLK },
-	{ .index = DT_UNIPHY_RX_CLK },
+	{ .name = "uniphy_gcc_tx" },
+	{ .name = "uniphy_gcc_rx" },
 	{ .hw = &ubi32_pll.clkr.hw },
 	{ .hw = &gpll0.clkr.hw },
 };

dingo · 2024-03-06T13:12:59.033Z

question, what branch in your repo are you using... main doesnt build for these devices

georgem83 · 2024-03-06T13:36:35.447Z

EDIT: I now see you asked @hzyitc

checkout branch 23.05, that should compile and allow you to boot from RAM with networking support. Wifi doesn't work on MX2000, but the QCN9074 radio on MX5500 does.
Main is based on kernel 6.1 and that one doesn't work yet

dingo · 2024-03-06T13:39:04.136Z

whoops... yupp sorry, im tracking your ipq5018 work as i have a different 5018 device but saw you started some 5018 work already

dingo · 2024-03-06T15:04:56.980Z

welp seems my device boots pretty well on your firmware even... so another ipq5018 device can also be added after some DTS tweaking maybe gets me there.

stich86 · 2024-03-08T10:04:33.654Z

are you going to add NSS acceleration like was done on IPQ807X series? this will be a nice addition

georgem83 · 2024-03-11T13:20:22.572Z

We’re very far from that as we still need to get the switch and wifi to work properly.

dingo · 2024-03-11T13:26:13.586Z

do you plan to commit work to your repo? as you fix items? original and last commit was Date: Mon Feb 19 17:18:37 2024 +0400

georgem83 · 2024-03-18T13:12:12.130Z

I do, nothing much has changed though. Ethernet works when booting from tftp in uboot, but there's no traffic when directly booting from nand. When that's fixed, I'll upload the new code.

dingo · 2024-03-18T13:19:48.633Z

yes we used your image, modified dts a bit and ran bootm, we got 2 interfaces up... go dhcp, havent tried to flash anything yet