Image | Orange Pi 4 LTS

[MichaIng]

@mazieri was so kind to generate and publish Orange Pi 4 LTS DietPi images: https://gitlab.com/mazieri/orange/-/releases

RK3399, supported by Armbian, hence well known kernel (build) shared by a lot of other SBCs we support:

• http://www.orangepi.org/orangepiwiki/index.php/Orange_Pi_4_LTS
• http://www.orangepi.org/orangepiwiki/index.php/Orange_Pi_4

I first though, LTS and non-LTS should be covered by the same image, but indeed they use/required different kernel device trees, so either require a different U-Boot default environment (the case with Armbian's U-Boot packages) or an explicit fdtfile setting in boot config. Either way, two images would be required for LTS and non-LTS versions. They have different Ethernet and WiFi chips, and the LTS variant may come with "RK3399-T" SoC, which has lower CPU frequency (while I couldn't find official specs from Rockchip, just from Orange Pi and Radxa).

Would be great if others could test the image, see whether everything works as expected. Since I'm currently moving all image builds to GitHub actions workflow, I'm considering re-adding new vendors, starting with the most requested Orange Pi.

[eikaramba]

The orange pi 5 is also already at the front door :) http://www.orangepi.org/html/hardWare/computerAndMicrocontrollers/details/Orange-Pi-5.html super excited about the possibilities all these new devices

[Gibbz]

Why is OPI 4 LTS not getting updated builds on the dietpi site?
I have one I want to setup, but unsure of the support.

[MichaIng]

No guide so far. You just need to use the next free number as new G_HW_MODEL ID, which would be 105 at the moment, and add it analogue to the 99 used for the Orange Pi 3 in this commit. In dietpi-installer, take care to add it to the # Rockchip 64-bit section instead of the # Allwinner 64-bit one, and with kernel='rockchip64'. But otherwise it should be pretty much the same and work OOTB.

[Gibbz]

How does the script know where to get the device tree, drivers and boot for the device?
😳

Is there a guide on building so I can test changes?

[MichaIng]

The dietpi-build script can be used, passing -m 105 as arguments.

However, it requires the respective kernel and U-Boot packages to be present in an APT repository, or in our test build directory. Easiest is if you open a PR here. I'll trigger a U-Boot build, and create the respective component in our APT repository.

EDIT: Oh, it has the UNISOC/Spreadtrum WiFi chip 🙈. Requires some extra entries to assure it is loaded when WiFi is enabled, since this driver is not pulled in by the device tree automatically.

[Gibbz]

Ive setup a PR here. I haven't tested it... not sure where to start!

I worked off dev.... I should commit to dev then ops!

#8057

[Gibbz]

ok the image is booting!
Ethernet is not working..... Whats the best way to debug?

Edit: wifi crashes when trying to enable it. modprobe gets stuck, then it seemed to corrupt the sdcard after reset.

Edit2: redone the microsd, and now it wont boot, gets stuck at "WCN: start_marlin [MARLIN_WIFI]"

Edit3: after a few resets it seems to get past it and boot up. no ethernet. Possibly something similar to this issue with the wifi https://forum.armbian.com/topic/30953-orangepi3b-initial-startup-is-ok-wifi-fails-after-reboot/

Google gemini suggested:
Controller: The LTS model uses the Motorcomm YT8531C Ethernet PHY.
Note: The standard (non-LTS) Orange Pi 4 uses the Realtek RTL8211E. This is why some older OS images lack the proper drivers for the LTS version's ethernet.

[MichaIng]

The WiFi issue is unrelated, but yes: that driver is pure crap, caused crashes all over the place. But at the moment, all critical open issues around it are worked around.

To debug Ethernet:

ip l
ip a
ip r
dmesg | grep -E 'eth'
journalctl -u ifup@eth0

I see that board has no mainline support, but uses a custom device tree: https://github.com/armbian/build/blob/main/patch/kernel/archive/rockchip64-6.18/dt/rk3399-orangepi-4-lts.dts

The PHY should be generally supported, since the Orange Pi R1 Plus LTS uses the same: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/arch/arm64/boot/dts/rockchip/rk3328-orangepi-r1-plus-lts.dts

[Gibbz]

sorry for the pictures, no network means no ssh :|
I couldn't run dmesg | grep -E 'eth' as the keyboards not working right for some reason...
I recall i had this issue on manjaro previously, so then ended up having to use armbian.

Edit: tried a usb ethernet and that didnt work like it did with manjaro... Is the due to the scripts not supporting it?

Edit2: armbian ethernet works fine. wifi also seems to have no issues on that...

[MichaIng]

It does not detect any carrier signal, as if no cable was connected.

Edit: tried a usb ethernet and that didnt work like it did with manjaro... Is the due to the scripts not supporting it?

It does, but if you attached the USB Ethernet adapter after first boot, the network configuration needs to be adjusted to use the new eth1 interface (eth0 is onboard). It should work to disable and re-enable Ethernet in dietpi-config network options, or manually replace eth0 with eth1 in /etc/network/interfaces and run systemctl start ifup@eth1.

Edit2: armbian ethernet works fine.

That is surprising, since it uses the very same kernel and bootloader. And I see no custom image adjustments either. Or do you mean with the USB Ethernet adapter?

wifi also seems to have no issues on that...

Which WiFi issues you mean? Armbian suffers from the same UNISOC/Spreadtrum driver issues, but as said, currently the critical known ones are worked around, so it "works".

[Gibbz]

Armbian works with the onboard ethernet without any changes.

And doesn't have the wifi boot stall issue.

Are there possibly extra drivers or firmware? Or are they all part of the kernel?

Is there a way to preconfigured the keyboard locale so I can use the pipe symbol and test the dmesg command?

[MichaIng]

Is there a way to preconfigured the keyboard locale so I can use the pipe symbol and test the dmesg command?

In dietpi.txt set AUTO_SETUP_KEYBOARD_LAYOUT accordingly before first boot. But can be also done via dietpi-config offline, which can be also accessed from the error handler.

Are there possibly extra drivers or firmware? Or are they all part of the kernel?

It is the 3 packages linux-image-current-rockchip64, linux-dtb-current-rockchip64, and armbian-firmware, which is the same on DietPi. We do our own builds from a fork with some fixes, but nothing which affects the Orange Pi 4 LTS. Also the base Linux version should be almost the same. Is it possible that the Ethernet cable was not attached properly?

Maybe try to unplug and plug again. Then check

ip l l eth0

It must not contain NO-CARRIER, but LOWER_UP instead.

Also check for kernel errors:

dmesg -l 0,1,2,3

And doesn't have the wifi boot stall issue.

Ah, I missed that one. That it failed to be loaded via modprobe was the reason we pre-loaded it for first boot some time ago. But then #7728 happened, and I was not able to reproduce the modprobe issue anymore, hence I removed that pre-load in 1c0726a. If modprobe sprdwl_ng again (or on some SBCs, will retest on Orange Pi Zero 3) fails, we could re-add the pre-load, since in the meantime, cpufreq-dt is builtin instead of a module. When sprdwl_ng loads before cpufreq-dt is loaded, it crashes the system as well (#7728), but with cpufreq-dt builtin this cannot happen anymore.

Would be interesting which condition causes this modprobe sprdwl_ng crash. When it is pre-loaded via /etc/modprobe.d, the system does the same, just earlier at boot. So it causes a crash in other drivers when loaded too early, and causes a crash/stall when itself loaded too late 🤣. Honestly, it is probably best to use a USB WiFi adapter in production and keep that module blacklisted, since ... who knows what else it fucks up without showing symptoms 😅. Not entirely a joke, since a driver generally is a security-sensitive element running in kernel space. So it could compromise other things. That it can cause other totally unrelated drivers to crash on load is just a sign that it sets up/writes to areas it is absolutely not supposed to.

Anyway, I'll try to replicate on the Orange Pi Zero 3. In any case, I am actually not keen to preload this driver on first boot, as of above concerns. So not great but probably best solution then is to require a reboot when WiFi is enabled, on the affected Orange Pi SBCs.

[Gibbz]

I don't care about wifi. So keep it black listed. It's just the boot stall crash and ethernet that's the issues.
I'll do those extra tests when I get time 👍

[MichaIng]

But that crash happens only when WiFi is enabled, isn't it? At least it comes from the WiFi driver (as well), which should only be enabled when WiFi is enabled explicitly.

EDIT: Ah, I remembered the history to mitigate the cpufreq-dt crash falsely. Indeed the WiFi module is enabled on first boot via /etc/modprobe.d, otherwise enabling WiFi via dietpi.txt wouldn't work. So looks like there is a new issue why it can crash a system when loading at boot 😞.

EDIT2: Armbian does the same, but loads the module for onboard Bluetooth as well. I remember there were situations in the past where one did not work (or crash) without the other. If you have a change to access the ext4 partition, would be interesting whether adding sprdbt_tty before sprdwl_ng to /etc/modules-load.d/dietpi-enable_wifi.conf.

[Gibbz]

is there a way to disable the wifi for first boot? its tedious testing with this crash.... Heres a few photos. its slightly different each time.
I made the change to /etc/modules-load.d/dietpi-enable_wifi.conf with no difference.
Edit commented out the module-load file contents and it loads without wifi :D

Edit i noticed the blacklist contains that module. will that be an issue trying to use it then?

blacklist sprdbt_tty
blacklist hidp
blacklist rfcomm
blacklist btbcm
blacklist bnep
blacklist bluetooth

[Gibbz]

ok got it running. this error doesnt look good! It definitely has the cable plugged in firmly.

[MichaIng]

Good find, not sure whether a blacklist overrides an explicit /etc/modules-load.d or the other way round, so could be tested whether removing /etc/modprobe.d/dietpi-disable_bluetooth.conf makes a difference.

If it keeps crashing, remove /etc/modules-load.d/dietpi-enable_wifi.conf.

I am thinking about changing things the following way:

• Currently, dietpi-installer enables WiFi modules for first boot, which includes /etc/modules-load.d/dietpi-enable_wifi.conf as a special-handling for this particular driver. All other WiFi drivers are automatically loaded based on devices defined in the device tree, but this driver not. The dietpi-firstboot service disables WiFi (places the blacklists) again if it was not enabled in dietpi.txt.
• This behavior is needed for Raspberry Pi, where disabling (onboard) WiFi means to have a device tree overlay in place, which cannot be changed without a reboot. Hence to allow enabling WiFi on Raspberry Pi via dietpi.txt, without requiring an additional reboot, it is necessary to ship images with enabled WiFi, which means to remove blacklists and the device tree overlay on RPi.
• However, all other SBCs can load their onboard WiFi modules on demand, since no device tree overlay disables it. So we could invert things for all other SBCs: disable WiFi modules for first boot, and enable them in dietpi-firstboot only if requested via dietpi.txt, and of course it can always be done via dietpi-config later. It means additional conditionals for RPi vs non-RPi, but generally, it seems cleaner that way.

For Orange Pi 4 LTS we however need to find out how the sprdwl_ng can be loaded without crashing, since currently it crashes in both cases, when added to /etc/modules-load.d as well as when loaded via modprobe 😞. The only difference between our images and Armbian that I can see is that Armbian loads the Bluetooth module sprdbt_tty first and additionally via /etc/modules-load.d. And while you can add it to /etc/modules-load.d/dietpi-enable_wifi.conf as well (and remove the blacklist), it won't be loaded in the initramfs yet, while the sprdwl_ng module was loaded in initramfs already, hence first. To really test whether the order plays a role, I'll implement above change, and then we can test loading those modules via modprobe in respective order. And I can create another image with both loaded in defined order in initramfs, which should then match 100% the Armbian images.

EDIT: Saw your last comment just now. What did you change? The Bluetooth module seems to load, but fails. But probably unrelated, same as the other kernel errors. eth0 seems to have a carrier signal now, but it has not been configured. I assume dietpi-fs_partition_resize and dietpi-firstboot did both not really finish due to the WiFi module loading crashes. Please try to fix it this way:

systemctl enable dietpi-fs_partition_resize dietpi-firstboot
reboot

[Gibbz]

Ok! Any further ideas why the ethernet is not working?

[MichaIng]

As said, it was not configured as if it was not enabled at all in /etc/network/interfaces. dietpi-firstboot should do this, hence please run above two commands and see whether this fixes it.

[Gibbz]

still no luck with the ethernet.
I have tried your commands. It didnt work.
So i made a new image edited the blacklist and wifi conf to disable the wifi. Then it went through the full first boot process till it gets to networking and it gets stuck there. DHCP is being assigned the wrong ip address, and manual address doesnt work either...

[MichaIng]

Did you try to switch back to DHCP on DietPi?

Just to rule it out, I re-triggered the image build: https://github.com/MichaIng/DietPi/actions/runs/23698078927
The prior image was with dhcpcd as DHCP client, while we reverted to dhclient.

Armbian uses NetworkManager to setup the network instead of ifupdown. But when using a static IP, there is not really something those can do differently. On Armbian, default route, IP address, and DNS resolver were the same as on DietPi? Maybe the router accepts only IPs from a certain range or so. Also, very rare, but theoretically, it might not answer to ping/ICMP requests.

If software-wise (IP, routes, DNS) everything is identical, only kernel/driver or firmware could still cause a package loss, but those are identical between DietPi and Armbian 🤔.

[Gibbz]

i re-enabled dhcp and it went back to the wrong ip range as before. I'm trying the new image now.
Edit: new image has the same issue. Im going to reinstall armbian and see if i can notice any difference to the config files etc.

[Gibbz]

attached image of the ambian setup. working out of the box.
Is it possible disabling the wifi affects the networking? Armbian has wifi enabled and working by default.

[MichaIng]

Please check:

uname -a
lsmod

and compare this with the output on DietPi.

Is it possible disabling the wifi affects the networking?

When I find time.

[MichaIng]

Images are now shipped with WiFi modules disabled by default: 5cc81b5

An Orange Pi 4 LTS image build is running: https://github.com/MichaIng/DietPi/actions/runs/24567135430
So that should now boot without crash, and we have this out of the way when debugging Ethernet. It ships with dhclient instead of dhcpcd, just in case that might have had an effect.

EDIT: Image ready: https://dietpi.com/downloads/images/testing/