Image | Radxa ROCK 3B #7327
Labels
Milestone
Comments
|
That Radxa package sudo mkdir -p /usr/share/sddm/themes/breeze
sudo touch /usr/share/sddm/themes/breeze/Main.qml
sudo apt purge radxa-sddm-theme
sudo rmdir -p /usr/share/sddm/themes/breeze |
|
I did as requested, with slight changes: root@rock-3b:/tmp/DietPi-Installer# sudo mkdir -p /usr/share/sddm/themes/breeze Afterwards the install is successful but I lose my two onboard NICs, the wlan is still ok, but I get some errors on the bluetooth side.. I've got the dmseg output linked. I tried to install the audio, but failed also. |
|
I know that, the board is in the kernel https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/arch/arm64/boot/dts/rockchip/rk3568-rock-3b.dts since v6.10... If yes which binary should I use ? |
|
Why did you use a vendor image, and not our ROCK 3A image? While it can work with any pre-image, there is not guarantee, as especially these vendor images are pretty messy and kinda malformed often. The Radxa package which tries to remove a non-existing file and even fails to uninstall completely, if that file does not exist, is a prefect example. Please try our image first, before we start to debug an issue which might be entirely related to the vendor pre-image, like faulty firmware placed into the filesystem without APT package reference and such stuff. |
|
I used the vendor image because the Rock 3B is not supported nor proposed to be downloaded, only the Rock 3A. They do share the same CPU but the 3B has two NICs instead of one. Also there's the fact that for instance , there's a difference of implementation of the DRAM on the Rock 4 and Rock 4SE, I figured that I should choose the generic device road to be sure. I'll try the Rock 3A firmware on it and will give you the feedback. |
|
Ah right, I missed the little important difference 3A and 3B 😉. Hmm, based on your logs, I guess the Debian Bookworm firmware packages cause the issue, as the Radxa image contains However, I'd try something different, as you recognised, mainline Linux supports this SBC already. Do you have a WiFi adapter at hand, to establish Internet access with that one temporarily? If so:
If this works, we can add some preliminary support to DietPi. If upstream U-Boot supports it as well, we can add support to our Armbian fork natively. |
|
It happens 😄 |
|
Okay, kernel build has finished, hence this could be tried now. |
|
Using the Rock 3A image is fine as far as:
|
|
Did you upgrade the kernel first, and does it contain the expected device tree? ls -l /boot/dtb/rockchip/rk3568-rock-3b.dtbAh shit, my mistake, I built the ... build running: https://github.com/MichaIng/DietPi/actions/runs/12547993860 |
|
Its partially ok now :
Thi here's the journactl : |
|
|
|
@Joulinar : I wasn't aware of that, my bad. Report: Below I've got the two NICs plugged to my router, only eth0 aka eth2 physically is up. Even with a fresh restart eth1 aka eth1 physically stays down. |
|
Here's more info : lsmod : from the vendor image : journalctl : |
|
For the second adapter, you could define in a own config, like: cat << '_EOF_' > /etc/network/interfaces.d/eth1.conf
allow-hotplug eth1
iface eth1 inet static
address 192.168.1.100/24
_EOF_
systemctl daemon-reload
ifup eth1depending on what you aim to do with it. |
|
I plan to either use it as a WAN or LAN port for a firewall, or with eth0 as a part of a etherchannel / LACP port, not quite sure yet... |
|
Yeah, above just an example. |
|
I tried your solution, the adapter won't show up, only eth0 & the wlan are available |
|
after a check, I discovered that : I manually modified the last line to fdtfile=rockchip/rk3568-rockb-3.dtb , now I've got my two NICs present, but only one up, despite both cables plugged. I tried to use nmcli to turn on the NICs to no avail : |
|
Great. So we can add support for the SBC in general, using ROCK 3A bootloader and adjusting the device tree only. Of course a ROCK 3B bootloader would be better, for network boot capabilities, but a rare use case. |
|
Is there some benchmark or or test or procedure that I can do, for you to validate the support of the board ? |
|
Not really needed. If it boots and those hardware features which differ from the ROCK 3A work, then all is good. |
|
So it's 99.9% OK as I can't use both NICs at the same time yet... |
|
But both do now show up in |
|
Yes they do. I tried the method you provided / tried with nmcli / mntui , they do both appear when I use Those are when only eth1 is plugged : Also when I try to activate eth1 with nmtui it fails |
Will test it when I get back. |
you meant
image and dtb are inverted ;) |
So I loose the wlan this time. Only one NIC ok, always the same. |
|
journalctl : |
This doesn't matter. Okay, does the ROCK 3B also use this |
|
I did a new build, with Armbian patches re-applied + another patch which changes the PHY mode and applies RX/TX delays in the MAC. This is true as well in the vendor kernel. Let's see whether it is the part which fixes the 2nd Ethernet port. Same procedure to apply: cd /tmp
wget https://dietpi.com/downloads/binaries/testing/linux-{dtb,image}-current-rockchip64.deb
dpkg -i linux-{dtb,image}-current-rockchip64.deb
reboot |
Hello, will try at lunch break 😉 |
|
Still the same : |
|
I forgot, wifi is still broken. |
|
Thanks for testing. Very weird with the WiFi, as Armbian patches are all back in. The 6.12.7 kernel you used before I uploaded the one with removed patches, had WiFi, right? 🤔 No related patch changes at Armbian: https://github.com/armbian/build/commits/main/patch/kernel/archive/rockchip64-6.12 ... ah, I see now in case of ROCK 3B it is an Intel WiFi chip with modprobe iwlwifi
ip l |
|
Next build ready to test, this time with the clock rate explicitly defined like in vendor kernel: MichaIng/build@59f048 To test, as always: cd /tmp
wget https://dietpi.com/downloads/binaries/testing/linux-{dtb,image}-current-rockchip64.deb
dpkg -i linux-{dtb,image}-current-rockchip64.deb
reboot |
|
Use mainline U-Boot on any board with rtl8211f Ethernet PHYs for mainline Linux, also make sure you use a build for your board or you will have Ethernet issue in Linux, i.e use an ROCK 3A image for 3B and you will only have one Ethernet port working, or use vendor U-Boot on Orange Pi 3B and you may have Ethernet PHY issue in Linux. Please see https://patchwork.kernel.org/project/linux-rockchip/patch/[email protected]/#26173827 for some details on the rtl8211f phy issue.
|
v6.1.123, v6.6.69 and v6.12.8 picked up a patch that broke some PCIe, SATA and USB on Rockchip RK356x, see https://lore.kernel.org/all/[email protected]/ EDIT: the patch was backported to v6.12.8 not v6.12.9 |
|
Hey @Kwiboo thanks for chiming in. a) Mainline U-Boot is used already, so that alone does not seem to help. Though it is a U-Boot for ROCK 3A, so probably it does not reset the 2nd adapter. In that case, it seems we need to properly add ROCK 3B support to the Armbian build system. However, we have the very same issue on an Orange Pi 3B with a very different Ethernet adapter, and a matching U-Boot build. It broke just after switching from a patched in vendor device tree to new mainline device tree, where RX/TX delays and resets have been moved to the PHY/mdio node. b) Sounds like another good attempt, which however would not work on the Orange Pi 3B. c) Switching to "deprecated" snps,reset is what I wanted to test as well, if other things fail. d) This is how mainline Linux does it already: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/arch/arm64/boot/dts/rockchip/rk3568-rock-3b.dts#n525
Maybe this broke onboard WiFi as well then. EDIT: I read through the comments of the patch request, and it is indeed very educating:
So we know that the RX/TX and most likely @MidG971 @Kwiboo |
Always in the mood to help , do not hesitate 😎 |
Correct, because the device tree used by U-Boot in such case does not have information about the 2nd adapter, the 2nd phy is never reset and Linux will not be able to find it, unless one of the mentioned workarounds is applied.
This issue is probably because part of the vendor U-Boot still exists in SPI flash or eMMC and is being used to load mainline U-Boot proper, when the vendor U-Boot SPL part is used to load mainline U-Boot proper, it will load the default FIT configuration that does not have any Ethernet PHY nodes enabled, when mainline U-Boot SPL is used the full revision detection code should work and
As mentioned above, as long as mainline U-Boot SPL was used to load mainline U-Boot proper it should work. Output from serial when booting affected boards would be helpful to see if there is any other issue on boards in the wild.
Using the deprecated
I mainlined both the Orange Pi 3B and ROCK 3B to Linux and U-Boot. Have both opi3b (v1.1.1 and v2.1) and rock-3b (commercial and industrial) boards that I tested booting into Linux on. Ethernet was working when I tested everything during mainlining process using pure mainline U-Boot and mainline linux-next at the time.
Most likely, error messages should be seen in
For the ROCK 3B, changing the phy compatible from
To correctly describe the hardware the |
Still the same, wifi broken |
|
here's some info I found, it might be useful |
Our images are full drive images, which includes the bootloader bits. And it is booting from eMMC, hence should not use the SPI bootloader. But I asked the user to flash the SPI bootloader, just to be sure. Downside is, that I cannot test the resets from kernel anymore then, which I want to have in place as well, to not depend booting from MMC or mainline SPI bootloader.
Does it need to be the deprecated method in the GMAC? Does it work differently when using the same reset delays in the PHY/mdio node?
In mainline Linux, the dessert delay is 50ms. Maybe too short in at least some individual cases?
It is above, but I do not even see an attempt for the driver to be loader ( @MidG971 dmesg -l 0,1,2,3and
Oh you are right I was not aware of that, as a different WiFi driver is used. Then it makes even more sense that this two boards suffer from the same issue. And indeed switching to
Interesting indeed. I would usually trust the values found in mainline or even vendor kernels more than test results from a particular board (which I do not even own in this case), but at least we know now how they are/can be derived 🙂. |
|
Build with the compatible PHY adjusted to Once done, it can be found again in the testing dir. |
That's before your latest build : |
|
Update: On the Orange Pi 3B, indeed the SPI bootloader was used, even that the eMMC contained one. Erasing the SPI flash fixed Ethernet there. However, if the changed compatible PHY fixes it on ROCK 3B even without proper mainline U-Boot, I'll keep that change as well. @MidG971 |
in a minute i'll test the build + plug my serial cable |
|
Weird. As if it was the wrong driver. But it was definitely used before: #7327 (comment) Are there other messages from this driver? dmesg | grep iwlwifi
Wait before https://github.com/MichaIng/DietPi/actions/runs/12779430484 is done, to test with the changed compatible PHY directly. |
|
Okay, build is done now. |
|
Here we go , for now I cant make my serial cable work, I'll keep you posted about that. So : |
|
This is with the kernel build from just now, hence For WiFi, I think about hardcoding Linux source to 6.12.8, until this has been fixed. |
Yes WiFi still broken |
Rockchip BootROM will typically load first stage (TPL + SPL) from SPI/NAND > eMMC > SD > USB (maskrom). Mainline U-Boot SPL will try to load next stage (TF-A, OP-TEE and U-Boot proper) from same boot media as first stage, however vendor U-Boot SPL may try to load next stage from eMMC/SD before falling back to same boot media. U-Boot proper will typically follow the
Please see my summary at https://lore.kernel.org/r/[email protected]/ the driver will handle reseting the phy at different times during the driver probe depending on where the props are defined. However, defining them at phy node will reflect the hardware more closely and DT should describe the hardware not be configuration for software.
As described in the link above the how the Linux phy driver do gpio reset is likely not correct, at least not during the time of writing 2023, so it does not really matter for Linux. And for U-Boot there will still be more than 50ms until registers are read after a reset, so 50ms should be enough for most cases. I should however post a Linux patch to adjust and use 80ms instead of 50ms to be on safe side.
Without fully working PCIe or USB the wifi/bt adapter is probably not being detected.
The offending patch was added in v6.1.123+, v6.6.69+ and v6.12.8+ (not in v6.12.9 as I mentioned earlier).
Keep in mind that use of |
I will try the same for a next build.
Jep I thought the same, that it is just related to this issue. Hence for now will downgrade to Linux 6.12.7 until we see a fix.
I guessed so, this the first build with 6.12.8 had WiFi broken, I just thought it was related to the fact that the driver for Orange Pi 3B onboard WiFi is a out-of-tree driver, added by Armbian patches, which I removed (although not the WiFi driver patches, only the kernel family specific kernel patches) to test whether some incompatibility with them caused the Ethernet issue. But the fact that the ROCK 3B was suffering from the same problem, using a driver from mainline kernel, rendered this unlikely.
Though the patch applied for the v1.1 device tree only, and for gmac1 + mdio1 only, which have no hardware part on v2.1. So that patch simply had no effect on v2.1, even if that wrong device tree is used. However, since it did not help, I'll remove part anyway, having the diff as small as possible. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Details:
apt-get -y autopurge gawk original-awkLinux rock-3b 5.10.160-18-rk356x #425b07550 SMP Thu Oct 12 08:48:55 UTC 2023 aarch64 GNU/Linuxarm64Steps to reproduce:
Expected behaviour:
Actual behaviour:
Extra details:
Additional logs:
log_failed_install_Rock3B.txt
The text was updated successfully, but these errors were encountered: