I have 2 Opi 3B boards, v1.1 and v2.1. I tried both with the latest firmware and I noted that it’s DietPi version v10.0.-1 (dev).
So there’s some problems with this version:
On boards v1.1 and v2.1, the default kernel is the ‘current’ and the governor is always ‘ondemand’ after reboot… this happens with ‘current’ and ‘edge’ kernels. With vendor kernel, the governor is what you chose in the dietpi-config menu.
Also, board v1.1 wifi does not work on boot, only after you type “modprobe sprdwl_ng”
No comments? Any admin could move this thread to the troubleshooting session?
@MichaIng can you have a look?
Here is some background:
The WiFi driver needed for Orange Pi 3B v1.1 and Orange Pi 3/3 LTS (but not Orange Pi 3B v2.1) crashes the system if it loads before the CPUFreq driver (at least this is how I interpret latest info). So I pushed new images which do not load this driver on first boot, and add it on the v1.1 revision only. Also, since the device tree for the v1.1 revision contains some nodes which look like they might pull in the driver automatically, I was hoping to remove the static driver loading for the v1.1 revision as well, but obviously loading the driver explicitly is still needed.
However, when enabling WiFi on v1.1, it should actually add the /etc/modules-load.d/dietpi-enable_wifi.conf to load the driver. Does this not exist in your case? If not, can you please check the following:
read -r model < /proc/device-tree/model
echo "$model"
[[ $model == *'v1.1' ]] && echo yes
I don’t know yet why the CPUFreq driver is loaded so late in some cases. It loads (respectively udev handles it) after our script which intends to adjust the CPU governor, which hence fails: Bug Report: CPU performance config not applied after reboot · Issue #7804 · MichaIng/DietPi · GitHub
A dedicated issue, which we’ll probably solve in a later release, splitting the dietpi-preboot service into two services, so the part which sets the CPU governor can run any time later without delaying anything else in the boot schedule. A dedicated issue, but it seems to trigger these more recently popping up crashes with this crappy sprdwl_ng WiFi driver as well. I can only hope Xonlong never implements any such UNISOC/Spreadtrum WiFi chip without mainline Linux support again …
SOrry for the late response I was in a business trip without access to the board.
It was a fresh install. The first echo command returns “Rockchip RK366 OPi 3B” and the second one, the last line, returns nothing.
If you want more tests let me know.