kernel 5.4, page says openwrt-redmi-ax3000, what's the interesting part ?
There is a mention of tp-link
I have a great desire to test the current build, even though it is not completely ready.
Yes, i used a patch from his sources for adding SGMII in rtl8367s.
The problem is that the rtl8367 s chip is connected via the SGMII interface. There is no SGMII support for it in the phy/net/phy/rtl8367b driver. You need to apply a patch for it. As a second option, you need to check the rtl8365mb file at the path /net/dsa/realtek. Link for a set of patches: net: dsa: realtek: rtl8365mb: Add SGMII and HSGMII support
And one more thing: as i see, this chip can load special fw fo it: "For (H)SGMII mode we have to load a firmware into some memory which gets
executed on the integrated 8051. The firmware binary was added as a
array into the driver with a GPL license notice on top.
" This uses the rtl8367s-sgmii.bin firmware file.
I'm new to all this and I don't have much time. Therefore, the process is slow. I have already redone and applied the patch for the rtl8367b driver. The chip is being detected, but there are bugs to fix
Wow This is something new and complicated, I applied patches only to the Android kernels lol I can’t even check because I don’t know how to flash the current build without disassembling the router, but I think Open AI should help us all
If it is not difficult for you, please provide instructions for flashing the current firmware build without disassembling the router, if possible, and the firmware file itself I will be very glad if you share this information.
At the current stage, a UART is needed because the firmware is uploaded to RAM for now. Command for the tftp firmware flashing in .itb format:
setenv serverip 192.168.0.xx
tftpboot <builded FW.itb>
setenv bootargs
bootm
1 Like
Would that mean that you managed to find RX on the board? If so, would it be possible to share the location or setup? Also I have been testing some possible network access points to UBoot, for example the built-in net console, using the preboot firmware env to activate it, but it does not seem to work exactly... I took the commands from here and here.
I also applied your above code through preboot and it didn't seem to work either. I don't know if the Ethernet interfaces are nuked in UBoot until you access the recovery environment (but if you managed to tftp boot that wouldn't make much sense), or if preboot has been nuked. I am also looking into this:
Basically they found a buffer overflow in the recovery web interface and inject UBoot commands through that, allowing tftp booting. Perhaps it could also work on the AX55? I will try to build a binary with the exploit and see what happens.
Yes, see the pic
1 Like
Latest log with initialized rtl8367s:
rtl8367b rtl8367: cannot find mdio bus from bus handle (yet)
[ 1.613758] i2c_dev: i2c /dev entries driver
[ 1.619593] cpufreq: cpufreq_online: CPU0: Running at unlisted initial frequency: 799999 KHz, changing to: 1008000 KHz
[ 1.621584] sdhci: Secure Digital Host Controller Interface driver
[ 1.629336] sdhci: Copyright(c) Pierre Ossman
[ 1.635425] sdhci-pltfm: SDHCI platform and OF driver helper
[ 1.645200] remoteproc remoteproc0: releasing cd00000.remoteproc
[ 1.648721] NET: Registered PF_INET6 protocol family
[ 1.653792] Segment Routing with IPv6
[ 1.656509] In-situ OAM (IOAM) with IPv6
[ 1.660101] NET: Registered PF_PACKET protocol family
[ 1.664558] 8021q: 802.1Q VLAN Support v1.8
[ 1.725182] rtl8367b rtl8367: switch phy addr=29
[ 1.725249] rtl8367b rtl8367: using MDIO bus 'ipq4019_mdio'
[ 1.729507] rtl8367b rtl8367: found chip num:6367 ver:00a0, mode:0000
[ 1.734324] rtl8367b rtl8367: RTL8367S chip found (num:6367 ver:00a0)
[ 3.349474] remoteproc remoteproc0: cd00000.remoteproc is available
[ 3.349734] qcom-q6-mpd cd00000.remoteproc: pd-1 node found
[ 3.356653] remoteproc remoteproc1: pd-1 is available
[ 3.360217] qcom-q6-mpd cd00000.remoteproc: pd-2 node found
[ 3.367041] remoteproc remoteproc2: pd-2 is available
▒[ 3.388111] Freeing unused kernel memory: 9664Kinside mtd15
[ 3.388283] Run /init as init process
[ 3.391463] with arguments:
[ 3.395341] /init
[ 3.398231] with environment:
[ 3.400488] HOME=/
[ 3.403456] TERM=linux
[ 4.077514] init: Console is alive
[ 4.077941] init: - watchdog -
[ 4.096770] kmodloader: loading kernel modules from /etc/modules-boot.d/*
[ 4.125024] gpio_button_hotplug: loading out-of-tree module taints kernel.
[ 4.138376] ssdk_dt_parse_mac_mode[299]:INFO:mac mode1 doesn't exit!
[ 4.138424] ssdk_dt_parse_mac_mode[307]:INFO:mac mode2 doesn't exit!
[ 4.144112] ssdk_dt_parse_port_bmp[1063]:INFO:port_bmp doesn't exist!
[ 4.150160] ssdk_dt_parse_interrupt[941]:INFO:intr-gpio does not exist
[ 5.751991] ssdk_mp_reset_init[1297]:INFO:MP reset successfully!
[ 6.113064] regi_init[2548]:INFO:Initializing SCOMPHY Done!!
[ 6.113269] regi_init[2574]:INFO:qca-ssdk module init succeeded!
[ 6.120908] dp1: ppe offload disabled: 0 for macid 1
[ 6.123867] dp1: Switch attached to macid 1 status: 0
[ 6.128838] nss-dp 39c00000.dp1 (unnamed net_device) (uninitialized): nss_dp_gmac: Registering netdev eth%d(qcom-id:1) with GMAC, mac_base: 0xffffffc082020000
[ 6.202409] Qualcomm IPQ5018 internal PHY 88000.mdio-1:07: attached PHY driver (mii_bus:phy_addr=88000.mdio-1:07, irq=POLL)
[ 6.270151] dp2: ppe offload disabled: 0 for macid 2
[ 6.270209] dp2: Switch attached to macid 2 status: 0
[ 6.274387] nss-dp 39d00000.dp2 (unnamed net_device) (uninitialized): nss_dp_gmac: Registering netdev eth%d(qcom-id:2) with GMAC, mac_base: 0xffffffc082050000
[ 6.280332] Generic PHY fixed-0:00: attached PHY driver (mii_bus:phy_addr=fixed-0:00, irq=POLL)
[ 6.295647] **********************************************************
[ 6.301822] * NSS Data Plane driver
[ 6.308477] **********************************************************
[ 6.333000] kmodloader: done loading kernel modules from /etc/modules-boot.d/*
[ 6.342883] init: - preinit -
[ 11.001974] random: crng init done
Press the [f] key and hit [enter] to enter failsafe mode
Press the [1], [2], [3] or [4] key and hit [enter] to select the debug level
[ 13.213888] procd: - early -
[ 13.214145] procd: - watchdog -
[ 13.836939] procd: - watchdog -
[ 13.837369] procd: - ubus -
[ 13.994544] procd: - init -
Please press Enter to activate this console.
[ 14.404862] kmodloader: loading kernel modules from /etc/modules.d/*
[ 14.591474] urngd: v1.0.2 started.
[ 14.690129] Loading modules backported from Linux version v6.11-0-g98f7e32f20d2
[ 14.690172] Backport generated by backports.git v6.1.110-1-31-g35e7a9061609
[ 14.758791] NET: Registered PF_QIPCRTR protocol family
[ 14.921233] PPP generic driver version 2.4.2
[ 14.942781] NET: Registered PF_PPPOX protocol family
[ 14.969533] kmodloader: done loading kernel modules from /etc/modules.d/*
[ 23.445314] br-lan: port 1(eth0) entered blocking state
[ 23.445382] br-lan: port 1(eth0) entered disabled state
[ 23.449620] nss-dp 39c00000.dp1 eth0: entered allmulticast mode
[ 23.462439] nss-dp 39c00000.dp1 eth0: entered promiscuous mode
[ 23.529686] nss-dp 39d00000.dp2 eth1: PHY Link up speed: 1000
[ 24.472243] adpt_mp_port_netdev_change_notify[1186]:ERROR:netdev change notify with incorrect port 0
[ 24.472317] ssdk_dev_event[2313]:ERROR:netdev change notify failed
now trying to find what this last error means...
Thank you for this, will do it in a bit and try booting. Just to confirm, bridge these points in the picture together? And then Green is TX so connect to RX, and blue is RX so connect to TX? Also is baud 115200? Thanks!
Yes, everything seems to be correct. in the process of searching, I rewired the jumpers many times, which is why everything is so sloppy. A user from the 4pda forum helped me find the RX pin.
1 Like
I don't understand how can it be, but i copy and list device DTB one more time to check and yes: there is no mention of the 8367s chip in all nodes, however, when loading the OEM firmware in the log, I see that it has been successfully initialized and uses reset-gpio 33. Moreover, the OEM dts has a node for qca8337 with three ports. (compatible = "qca,qca8337"). I'm no longer sure if I'm moving in the right direction..
send open ai
It looks like you're encountering an issue with the RTL8367B switch driver, which is failing to initialize properly in your system. The key message here is rtl8367b rtl8367: cannot find mdio bus from bus handle (yet). This indicates that the driver cannot find the MDIO bus, which is essential for communication with the switch.
Possible causes and steps to resolve the issue:
- MDIO Bus Configuration: Make sure that the MDIO bus (
ipq4019_mdio) is properly initialized in the kernel configuration. You may need to ensure that the bus and switch driver dependencies are correctly set up. - Device Tree Configuration: Check your device tree configuration to ensure that the MDIO bus and the switch are properly defined. You may need to explicitly specify the MDIO bus in your device tree source (DTS) file.
- Kernel Modules: Verify that the appropriate kernel modules for your device are loaded, especially for the network switch and MDIO bus driver. You might also need to check if the correct version of the kernel modules is being used.
- Hardware Initialization: Ensure that the switch chip (
RTL8367S) is correctly recognized and initialized by the system. This might involve checking firmware or driver updates. - Log Analysis: The logs show several other errors related to the
nss-dpdriver and network device initialization, which may also be contributing to the issue. You may want to look into fixing these errors as well.
can you give all logs where there are errors I will send them to chat gpt to make it easier for you to develop open wrt
You can ignore this error. SSDK expects a port_id (>0) to be passed which is in stock set in the DTS for each port of the qca8337 switch. Since we’re using the DSA driver and not the SSDK, the port_id is null (0) and it just complains about it but it doesn’t break anything.
1 Like
Ok, it's a good news.. Then I will focus on the "rtl8367b rtl8367: cannot find mdio bus from bus handle (yet)" error. I'm starting to think that in this configuration, the rtl8367s switch is unmanageable. The configuration of the ports is flashed in bootloader, and it connects to control via the CPU6 port. But in other side - on kernel 5.15 and SGMII patch this config was working..
rtl8367b {
compatible = "realtek,rtl8367s";
realtek,extif1 = <0 0 10 1 0 0 1 1 4>;
mii-bus = <&mdio1>;
cpu-port = <6>;
phy_id = <29>;
};
This question may be irrelevant, but I can see the following things (I am also new to this, mostly an idea dump...):
From grep rtl on the OpenWRT dmesg:
[ 4.417300] rtl8367b rtl8367b: using MDIO bus 'ipq4019_mdio'
[ 4.418675] rtl8367b rtl8367b: unknown chip (num:ffff ver:ffff)
[ 4.423966] rtl8367b rtl8367b: chip detection failed, err=-19
Why is it using the IPQ4019 MDIO bus? Is that part of the driver binary that it's loading, or is it something we can configure? Or are the two (the 4019 and ours) just compatible and it's fine (which doesn't make much sense to me)? Unless the driver is trying to get the MDIO from the DT but it's not linked properly, so it falls back to the 4019 as default?
From the Device Tree:
I can see that &mdio1 mentions the QCA8337 for the switch ports. While this seems to be the case indeed in the device tree on the original firmware, there is also the presence of QCA NSS (Qualcomm's Network Subsystem as far as I can tell), and maybe through binaries on the stock firmware, the Realtek switch gets mapped through the Network Processor to a "dummy" implementation similar to the QCA8337, which then is exposed to Linux? After all, from the stock dmesg, it does seem like the SSDK is handling the initialization of the Realtek switch. Perhaps if we tried to handle the device tree as if it has purely a Realtek switch and were to access it directly (is that something that even makes sense)?
I will try messing around with the device tree a little bit, but I don't know how far I'll manage to get...
I will update the repository today. Current repository does not work for the 8367s driver. ipq4019 and 5018 mdio should be compatible as far as I can see in the kernel
1 Like