Benik3 Posted March 14 Posted March 14 (edited) Hi. I have RockPi E v1.21 and I found, that I'm not able to boot image with new kernel 6.12 (tried minimal images 25.2.1 and 24.11.1, USBImager and Balena Etcher, 3 SD cards, different power supplies). With image 24.8.3 it boots normally. Also I found, that after upgrading 24.8.3 to kernel 6.12 the RockPi boots, but Ethernet doesn't work (even LEDs are dead). Another thing which I notice is, that I didn't find any option to disable kernel upgrades, but what I googled, it should be present in armbian-config->system->kernel->Y203. But this Y203 option is missing. Here is successful boot log of 24.8.3: https://paste.armbian.com/ixuvimofis.sql here is boot log of 24.8.3 upgraded to 6.12: https://paste.armbian.com/ahezanixol.sql Here is failing boot of 25.2.1: https://paste.armbian.com/onuhumomob.yaml P.S. on the successful boot of 24.8.3 I didn't have ETH cable connected, that's why there is Network connection timeout!, but it works fine after connecting. What's weird, that both 24.8.3 boots says on the beginning Net: Could not get PHY for ethernet@ff540000: addr -1 No ethernet found. But I assume that's problem only of u-boot, because it's before kernel boot. Thanks! Edited March 14 by Benik3 0 Quote
Benik3 Posted March 18 Author Posted March 18 It looks like the problem with not working ethernet after upgrade is after 24.11.1 version, because I now noticed, that I have one device upgraded to 24.11.1 and ethernet is working... 0 Quote
Benik3 Posted March 30 Author Posted March 30 25.5.0-trunk.316_Rockpi-e_plucky_current_6.12.21_minimal boots, but the problem with ethernet persist. Bootlog with level 7: https://paste.armbian.com/bimosoyupi.yaml 0 Quote
Igor Posted March 31 Posted March 31 Confirmed, many thanks for reporting. 6.12.y has troubles with one of the NICs, but as regressions at major kernel upgrades are totally normal and expected in embedded Linux, we are providing you this: https://docs.armbian.com/User-Guide_Armbian-Config/System/#install-alternative-kernels Use older kernels: On 3/14/2025 at 4:56 PM, Benik3 said: Another thing which I notice is, that I didn't find any option to disable kernel upgrades, but what I googled, it should be present in armbian-config->system->kernel->Y203. But this Y203 option is missing. Make sure you update armbian-config package before doing that, then proceed with "Disable Armbian upgrades" https://docs.armbian.com/User-Guide_Armbian-Config/System/#enable-armbian-firmware-upgrades It was moved to armbian-config -> system -> updates Spoiler Spoiler Verify in CLI: igorp@rockpi-e:~$ sudo apt-mark showhold linux-dtb-current-rockchip64 linux-image-current-rockchip64 0 Quote
Benik3 Posted April 2 Author Posted April 2 Hi and thanks for reply. I tried to dig more into the ethernet problem. I found that there was already similar problem: https://forum.radxa.com/t/rock-pi-e-board-version-1-21-ethhernet-not-working-in-armbian/15061/4 There are 2 boards of RockPi-E 1.2 (using RTL8211E) and 1.21 (using RTL8211F). So I tested the provided dts and it really helped. After sme trial-tests I found, that the real thing which helps is the compatible = "ethernet-phy-id001c.c916"; So using dts: /dts-v1/; / { compatible = "rockchip,rk3328"; fragment@0 { target-path = "/ethernet@ff540000/mdio"; __overlay__ { ethernet-phy@1 { compatible = "ethernet-phy-id001c.c916"; }; }; }; }; ethernet 0 is working fine. Problem is, that with this dts the older RTL8211E will probably stop to work... Thanks for pointing to the System updates. On 25 Armbian I see it, but on 24.8.3 when I updated only armbian-config, the Updates option is missing: 0 Quote
Igor Posted April 2 Posted April 2 2 hours ago, Benik3 said: Problem is, that with this dts the older RTL8211E will probably stop to work... Probably. This can be solved by adding an overlay, so user can enable this at will, manually or via armbian-config. 2 hours ago, Benik3 said: On 25 Armbian I see it, but on 24.8.3 when I updated only armbian-config, the Updates option is missing: armbian-config lives in its own repository. Always make sure your packages are up2date / latest. Or at least armbian-config. 0 Quote
Kwiboo Posted April 3 Posted April 3 (edited) On 4/2/2025 at 3:37 PM, Benik3 said: Problem is, that with this dts the older RTL8211E will probably stop to work... Use of the RTL8211F phy-id in a compatible will stop it from properly being detected as a RTL8211E, so not a good idea. Mainline Linux will not always handle a reset of the RTL8211F Ethernet PHY, at least on Rockchip boards when reset- properties is defined in the PHY-node, so you will end up with a "Could not get PHY" error unless the RTL8211F PHY has been reset by the bootloader prior to Linux. Newer versions of U-Boot does this correctly, older versions like the U-Boot 2022.07-armbian-2022.07 version as seen in your logs does not even try to reset the Ethernet PHY. Upgrading to a newer (and safer) version of U-Boot should solve your issue (and similar issues when Rockchip and RTL8211F is involved for other boards). Using vanilla mainline U-Boot 2025.01 and vanilla mainline Linux 6.12 on a ROCK Pi E v1.21 does not have any issues to identify the Ethernet PHY: U-Boot 2025.01 (Apr 03 2025 - 06:04:07 +0000) Model: Radxa ROCK Pi E DRAM: 1 GiB (effective 1022 MiB) PMIC: RK805 (on=0x40, off=0x00) Core: 247 devices, 30 uclasses, devicetree: separate MMC: mmc@ff500000: 1, mmc@ff520000: 0 Loading Environment from MMC... Reading from MMC(1)... *** Warning - bad CRC, using default environment In: serial@ff130000 Out: serial@ff130000 Err: serial@ff130000 Model: Radxa ROCK Pi E Net: eth0: ethernet@ff540000 Hit any key to stop autoboot: 0 ~ # ip link set eth0 up [ 27.617316] rk_gmac-dwmac ff550000.ethernet eth0: Register MEM_TYPE_PAGE_POOL RxQ-0 [ 27.679150] rk_gmac-dwmac ff550000.ethernet eth0: PHY [stmmac-1:00] driver [Rockchip integrated EPHY] (irq=POLL) [ 27.690181] rk_gmac-dwmac ff550000.ethernet eth0: No Safety Features support found [ 27.690902] rk_gmac-dwmac ff550000.ethernet eth0: PTP not supported by HW [ 27.692259] rk_gmac-dwmac ff550000.ethernet eth0: configuring for phy/rmii link mode ~ # ip link set eth1 up [ 32.070210] rk_gmac-dwmac ff540000.ethernet eth1: Register MEM_TYPE_PAGE_POOL RxQ-0 [ 32.153078] rk_gmac-dwmac ff540000.ethernet eth1: PHY [stmmac-0:01] driver [RTL8211F Gigabit Ethernet] (irq=53) [ 32.165523] rk_gmac-dwmac ff540000.ethernet eth1: No Safety Features support found [ 32.166268] rk_gmac-dwmac ff540000.ethernet eth1: PTP not supported by HW [ 32.167621] rk_gmac-dwmac ff540000.ethernet eth1: configuring for phy/rgmii link mode Edited April 3 by Kwiboo 0 Quote
Benik3 Posted April 4 Author Posted April 4 Thanks for the reply. I noticed, that in u-boot the ethernet is not detected. So the solution to this problem should be updating the u-boot. 0 Quote
Benik3 Posted April 4 Author Posted April 4 BTW I found also another weird behavior. I have more of the RockPi E boards. All are 1.21 version and bought in one batch. I have SD card with the trunk 316 Pluck Armbian, and on one board the ethernet doesn't work, but on another 2 yes... Also even more weird thing, on the working board when I install 24.8.3 and the do full-upgrade, it also doesn't work... So maybe it's also some time race of the reset? 0 Quote
Benik3 Posted April 7 Author Posted April 7 I installed and updated the Armbian 25.2.1 Bookworm Minimal / IOT and I found that sometime the board doesn't reboot and hangs. But it looks like the system shutdown successfully: [ OK ] Finished systemd-reboot.service - System Reboot. [ OK ] Reached target reboot.target - System Reboot. [ 1889.239148] watchdog: watchdog0: watchdog did not stop! [ 1889.266560] systemd-shutdown[1]: Using hardware watchdog 'Synopsys DesignWare Watchdog', version 0, device /dev/watchdo0 [ 1889.267571] systemd-shutdown[1]: Watchdog running with a hardware timeout of 10min. [ 1889.341351] systemd-shutdown[1]: Syncing filesystems and block devices. [ 1889.474788] systemd-shutdown[1]: Sending SIGTERM to remaining processes... [ 1889.484569] systemd-journald[360]: Received SIGTERM from PID 1 (systemd-shutdow). [ 1889.492592] systemd-shutdown[1]: Sending SIGKILL to remaining processes... [ 1889.502260] systemd-shutdown[1]: Unmounting file systems. [ 1889.505128] (sd-remount)[1430]: Remounting '/' read-only with options 'errors=remount-ro,commit=120'. [ 1889.573116] EXT4-fs (mmcblk0p1): re-mounted 3f584b9a-965c-48cd-8e7c-7bd5320b177a ro. Quota mode: none. [ 1889.584110] systemd-shutdown[1]: All filesystems unmounted. [ 1889.584627] systemd-shutdown[1]: Deactivating swaps. [ 1889.585255] systemd-shutdown[1]: All swaps deactivated. [ 1889.585731] systemd-shutdown[1]: Detaching loop devices. [ 1889.588197] systemd-shutdown[1]: All loop devices detached. [ 1889.588707] systemd-shutdown[1]: Stopping MD devices. [ 1889.589507] systemd-shutdown[1]: All MD devices stopped. [ 1889.589991] systemd-shutdown[1]: Detaching DM devices. [ 1889.590669] systemd-shutdown[1]: All DM devices detached. [ 1889.591153] systemd-shutdown[1]: All filesystems, swaps, loop devices, MD devices and DM devices detached. [ 1889.592001] watchdog: watchdog0: watchdog did not stop! [ 1889.606252] systemd-shutdown[1]: Syncing filesystems and block devices. [ 1889.607708] systemd-shutdown[1]: Rebooting with argument 'now'. [ 1889.689457] kvm: exiting hardware virtualization [ 1889.690011] reboot: Restarting system with command 'now' INFO: PSCI Power Domain Map: INFO: Domain Node : Level 2, parent_node -1, State ON (0x0) INFO: Domain Node : Level 1, parent_node 0, State ON (0x0) INFO: Domain Node : Level 0, parent_node 0, State ON (0x0) INFO: Domain Node : Level 0, parent_node 0, State ON (0x0) INFO: CPU Node : MPID 0x0, parent_node 1, State ON (0x0) INFO: CPU Node : MPID 0x1, parent_node 1, State ON (0x0) INFO: CPU Node : MPID 0x2, parent_node 1, State ON (0x0) INFO: CPU Node : MPID 0x3, parent_node 1, State ON (0x0) DDR version 1.16 20190528 ID:0x805 N In SRX DDR3 333MHz Bus Width=32 Col=10 Bank=8 Row=15 CS=1 Die Bus-Width=16 Size=1024MB 0 Quote
Benik3 Posted April 9 Author Posted April 9 (edited) Another weird thing (on 24.8.3). Eth0 looks working fine (no error in dmesg). When I connect it to router, router shows it in DHCP server leases, but the RockPi doesn't "accept" the IP address (in ip a is no address leased). Eth1 is working fine. EDIT: It's probably some our HW problem. Anyway I tried to build u-boot 2025.04 from mainline, but the problem with ETH0 driver load still persist. so it's not the solution. Edited April 10 by Benik3 0 Quote
dgatwood Posted Monday at 05:40 PM Posted Monday at 05:40 PM I confirm that the current version of Armbian, as downloaded, is completely useless unless you have a serial console, because it doesn't do DHCP successfully on either interface, so you can't SSH into it to fix the network problems. And I can see errors in the logs that you can click to view to see that the release was "tested". A loopback test needs to be part of the standard test. Turn on both NICs, give them IP addresses, and verify that they can communicate with each other. As it currently stands, Armbian is shipping releases that claim to be "tested", but in practice, can't be used by the vast majority of people who will download them, and that's a rather serious quality control fail. Additionally, Armbian should do something like what the OctoPrint firmware does — have a small FAT32 volume that contains wpa_supplicant. That way, you could at least bring up the Wi-Fi network if Ethernet doesn't work. Without any USB or HDMI output, the Ethernet drivers are effectively a single point of failure in this distro, and that's a bad situation to be in, particularly when there's apparently zero testing of that critical driver before shipping a build. I'd file a bug, but the bug reporting form won't let me unless I have serial console hardware, even though the problem is entirely obvious without it. 🙄 Downloading an older build now. Ugh. 0 Quote
Werner Posted Monday at 05:55 PM Posted Monday at 05:55 PM Seems working nicely: https://paste.armbian.com/eniduhodih 0 Quote
Benik3 Posted Monday at 05:57 PM Author Posted Monday at 05:57 PM (edited) The problem is very weird. I tested like 5 RockPi and some worked without issue, some not. They were same HW version and from one batch. Maybe it's some time race... @dgatwood 100Mbit ethernet is still working fine, so you can use it to bring it alive. You can use custom device tree overlay to "force" the right driver to load. See my previous posts. Edited Monday at 06:00 PM by Benik3 0 Quote
dgatwood Posted Monday at 06:38 PM Posted Monday at 06:38 PM I tried *both* Ethernet ports and never got a DHCP request when using the May 15 build. No flashing blue light, either, so the problem might actually be worse than just Ethernet, but I don't have serial console hardware to say for sure. I also re-dd'ed the image just in case something miraculously went wrong the first time (which has never happened in all my years of doing this, but wanted to rule it out completely). I did not try re-downloading, but the sha256 checksum matches. In between those two attempts, I tried the out-of-support Ubuntu version that Rock Pi ships, and that worked as expected. I finally ended up downloading the November build of Armbian, which also worked as expected (both ports). The problem with trying to do custom device tree overlays is the same as the problem with bringing up Wi-Fi: the config files are on an ext4 volume, which can't be readily accessed from my Mac. Sure, I could hunt down an external SD card reader (I probably still have one somewhere) and a Raspberry Pi (I have more than a few somewhere, though only a couple of them aren't permanently installed inside something), booting that, SSHing to it, etc., but it's not worth the hassle when I can just downgrade to the November build. Sadly, my days of Linux kernel hacking are over, replaced long ago by having a hundred times more stuff to do than I have time for. 😁 I do have a proper serial adapter on its way from Amazon, and I'll try it next weekend to see what happens, assuming I remember and have time. 0 Quote
Benik3 Posted Monday at 07:33 PM Author Posted Monday at 07:33 PM Ah, that's the worse issue, that it doesn't boot at all. I don't know what cause this, on nightly builds it was working again... I stay with the 24.8 version... 0 Quote
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.