101

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

102

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

103

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

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

104

Thanks for your help. Will try and revert

105

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.

106

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.

1 Like
108

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?

109

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

110

Maybe you find something interesting in this
ipq5018.dtsi

1 Like
111

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 },
 };
1 Like
112

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

113

EDIT: I now see you asked @hzyitc :slight_smile:

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

114

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

115

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.

116

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

117

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

118

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

119

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.

120

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

121

ah cool, it would be great if we can add the ipq50xx target and get support for loads of devices. What device(s) are you testing with?