specs

@dantes "You might need sudo" generally means "if you regularly use a serial console or maskrom connection you will want to configure user permissions for /dev/ttyusbX" (i.e. adding the user to the "dialout" group). Back when modems were still frequently used adding a user to dialout might have been a serious problem. I think nowadays using sudo for pretty much anything is the greater risk.

Is it possible to change the default homepage option in /etc/armbian/firefox.conf? root@rock-5b:/etc/armbian# cat firefox.conf // // set default home page //pref("browser.startup.homepage","https://www.armbian.com"); pref("browser.shell.checkDefaultBrowser", false); One could argue why big companies are fined for a "call home" and armbian just fixes the homepage to something I don't want. According to the law it might even be illegal in Europe. Note: when the homepage is set to armbian.com and the user can freely alter it to something he'd rather have in the usual way, I don't think it is a problem.

It seems there is an issue with the "lspci -vvv" in particular. # lspci -vvv|grep -E "L1,ASPM" pcilib: sysfs_read_vpd: read failed: No such device Continuing without the grep part I do see the nvme and aspm (Linux rock-5b 6.10.7-current-rockchip-rk3588): # lspci -vvv ... 0000:01:00.0 Non-Volatile memory controller: Shenzhen Longsys Electronics Co., Ltd. Lexar NM790 NVME SSD (DRAM-less) (rev 01) (prog-if 02 [NVM Express]) ... Capabilities: [180 v1] L1 PM Substates L1SubCap: PCI-PM_L1.2+ PCI-PM_L1.1+ ASPM_L1.2+ ASPM_L1.1+ L1_PM_Substates+ PortCommonModeRestoreTime=10us PortTPowerOnTime=10us L1SubCtl1: PCI-PM_L1.2- PCI-PM_L1.1- ASPM_L1.2- ASPM_L1.1- T_CommonMode=30us LTR1.2_Threshold=54272ns L1SubCtl2: T_PwrOn=18us Capabilities: [190 v1] Vendor Specific Information: ID=0002 Rev=4 Len=100 <?> For the Rock5B (with the power is set to 12V fixed) it means: 2.0W when running on eMMC (with network 1Gbps and monitor, without wifi) 5.3W with nvme/performane 4,3W with nvme/powersave. 2.5W when running on eMMC (with wifi and monitor, without ethernet) With other boards (RK3568) adding an nvme costs less extra power. I recently replaced a Kingston nvme for the Lexar (they are both not fast but, also not very powerhungry) but it did not yield positive results. I will try the Kingston with a 6.1-vendor kernel again, before switching the rock5 for different hardware.

I know the list, and that's why I asked the question. According to the list PCIE3 and M2 M are supported, but I can't find anything about ASPM. I would assume that when it is ready ASPM should also work. The PCIE3 and M2 M options have been added somewhere by the 6.7-kernels, so it should be working at least in the basics. When I am getting an error that could mean my system is broken or the complete rk3588 support is still not ready. If it is just my system it can help to ask if others see the same error. What I see in the responses is that nobody seems uses the system anymore.

Since your platform seems to be an rk3568 and very recent at that, could it be it runs Wayland instead of X11 by default? That could explain some of the VNC troubles (search "rpi5 and vnc" or basically "bookworm and vnc")... And could the RDP troubles be based on the same problem (Wayland)?

When using my (intel) laptop I get when I check my nvme (as root): # lspci -vvvs 01:00|grep -E "ASPM|L1" DevCap: MaxPayload 512 bytes, PhantFunc 0, Latency L0s <1us, L1 unlimited LnkCap: Port #0, Speed 16GT/s, Width x4, ASPM L1, Exit Latency L1 <8us ClockPM- Surprise- LLActRep- BwNot- ASPMOptComp+ LnkCtl: ASPM L1 Enabled; RCB 64 bytes, Disabled- CommClk+ Capabilities: [900 v1] L1 PM Substates L1SubCap: PCI-PM_L1.2+ PCI-PM_L1.1+ ASPM_L1.2+ ASPM_L1.1- L1_PM_Substates+ L1SubCtl1: PCI-PM_L1.2- PCI-PM_L1.1- ASPM_L1.2- ASPM_L1.1- L1SubCtl2: T_PwrOn=500us With the 6.1-vendor kernel I got the same on my rock05b and I did see others writing similar results (for example with the FriendlyElec Nanopi R6). With the 6.10-kernel I get: # lspci -vvvs 01:00|grep -E "L1,ASPM" <no output> Further searching yields "Unknown header type 7f". Is this typical for the 6.10-kernel or is this a bug in the armbian-kernel specific? The other problem with the 6.10-armbian kernel is that if I change a tiny option in the kernel config it yields a non-booting kernel (without changing the config the kernel does not compile, but is downloaded instead). This means I have the choice between a kernel I cannot compile myself and a vendor kernel without GPU acceleration (which I can compile). The 6.10-kernel should be more open, but without being able to boot a selfcompiled kernel I find it very closed. Is there any hint to get a selcompiled kernel booting?

Of course they should for the orangepi. If you are looking for the name look at the currently installed linux-image package, replace "legacy" with "vendor", etc.. apt search linux-image.*vendor apt search orangepi5 Just don't forget to install the dtb and u-boot next to the linux-image, if you switch kernels the u-boot package.

Don't use armbian-config for that purpose. Update the kernel using apt. But update dtb, bsp-cli and linux-image together. Optionally you might include the kernel-headers and the libc-dev-vendor-package. Something like this: apt -d install armbian-bsp-cli-rock-5b-vendor linux-dtb-vendor-rockchip-rk3588 linux-image-vendor-rockchip-rk3588 linux-u-boot-rock-5b-vendor With the -d option, you download first before installing. Also, with the above command the sytem only installs packages it can find. Perhaps you need apt search vendor To search the exact package names. The other options for the kernel are 5.10 (legacy), 6.8/6.9 and 6.10-rcX (edge).

Last week mesa 24.1.0 was released and friday 24.1.0-2 reached sid. This means that with sid + the armbian-edge kernels making panthor work on the rock-5b is pretty easy. Hope the AX210 follows soon. I've seen comments that it currently iis working on the Orange Pi 5. Can't wait until mesa 24.1 hits trixie.

Currently I can switch between kernels using: apt -d install armbian-bsp-cli-rock-5b-collabora linux-image-collabora-rockchip-rk3588 linux-dtb-collabora-rockchip-rk3588 linux-headers-collabora-rockchip-rk3588 Followed by a "dpkg -i --force /var/cache/apt/archive/*collabora*... The advantages, I get a 6.9.0-kernel with the collabora patches. Disadvantages: - the devfreq for the gpu is implemented in 6.8.x and not in the collabora kernel. - PCI for AX210 is only implemented in 6.1.43 (vendor). Lack of advantages: mesa 24.1 is available in experimental, but not yet in bookworm. Using a kernel with a panthor driver is a little pointless that way. Also, there is a clash between armbian-bsp-cli and armbian-firmware-full, meaning above command cannot be executed without the "force" command. I'll wait for the 6.9.3 or the 6.9.4 kernel...

In my opinion setting up internet without tools is less work than setting up either networkd or network manager, because that would mean downloading all packages by hand and transfer them to the SBC (and probably add missing packages as you go). The after getting the network up you can install anything you want using apt. Look up on setting up ethernet from the commandline. I would suggest starting with wired ethernet if available. ip link set eth0 up ip route add default via 192.168.1.2 dev eth0 rm /etc/resolv.conf echo nameserver 192.168.1.1 > /etc/resolv.conf (Assuming your route is 192.168.1.1 and eth0 is set up with DHCP). There is probably enough to comment on this. But it gives you a general direction as it points to setup the ethernet adapter with IP address, route and DNS lookup. The order of "ip addr" and "ip link" is something you should find by trial. You probably use it only once before you switch to network manager. PS https://access.redhat.com/sites/default/files/attachments/rh_ip_command_cheatsheet_1214_jcs_print.pdf

Currently networking in Armbian is possible in different ways: 1 - networkd 2 - network-manager 3 - netplan, using either networkd or network-manager 4 - /etc/network/interfaces (which is absolutely outdated) 5 - armbian-config (which uses networkmanager via a script) Have you considered using 5? Perhaps you need to install armbian-config first on a minimal image. The timeout for systemd can omitted by disabling systemd-networkd-wait-online.service with systemctl. The second place to look is the "optional: true" parameter if you use netplan (which only works for ethernet).

Just saw the "mark as solution" tab. Basically when posted this issue was already solved. If it is not against policy I do like to post if only to document.

Finally found the problem: Since the kernel was half installed, the kernel and the modules did not match. This means all the modules did not work. Manually remounting the /boot partition and reinstalling the kernel did the trick. There is still some detail that the "uname -a" and "cat /proc/version" are not updated, although the kernel was replaced.

Current kernel: Linux rock-5b 6.1.43-vendor-rk35xx #1 SMP Mon Mar 18 05:06:52 UTC 2024 aarch64 GNU/Linux Symptoms: $ lspci .. 0002:20:00.0 PCI bridge: Rockchip Electronics Co., Ltd RK3588 (rev 01) 0002:21:00.0 Network controller: Intel Corporation Wi-Fi 6 AX210/AX211/AX411 160MHz (rev 1a) 0004:40:00.0 PCI bridge: Rockchip Electronics Co., Ltd RK3588 (rev 01) 0004:41:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8125 2.5GbE Controller (rev 05) And after a reboot I find with dmesg: # modprobe iwlwifi modprobe: ERROR: could not insert 'iwlwifi': Exec format error root@rock-5b:~# dmesg|grep -E -A 3 -B 3 "intel|iwl" [ 6.285747] input_leds: disagrees about version of symbol module_layout [ 6.288159] joydev: disagrees about version of symbol module_layout [ 6.309378] gpu_sched: disagrees about version of symbol module_layout [ 6.314006] btintel: disagrees about version of symbol module_layout [ 6.314148] btintel: disagrees about version of symbol module_layout [ 6.314693] btintel: disagrees about version of symbol module_layout [ 6.314751] btintel: disagrees about version of symbol module_layout [ 6.368536] iwlwifi: disagrees about version of symbol module_layout [ 6.377085] systemd[1]: Starting modprobe@dm_mod.service - Load Kernel Module dm_mod... [ 6.378547] systemd[1]: Starting modprobe@fuse.service - Load Kernel Module fuse... [ 6.380075] systemd[1]: Starting modprobe@loop.service - Load Kernel Module loop... [ 6.380564] btintel: disagrees about version of symbol module_layout [ 6.381271] systemd[1]: systemd-fsck-root.service - File System Check on Root Device was skipped because of an unmet condition check (ConditionPathExists=!/run/initramfs/fsck-root). [ 6.383701] systemd[1]: systemd-fsck-root.service - File System Check on Root Device was skipped because of an unmet condition check (ConditionPathExists=!/run/initramfs/fsck-root). [ 6.384399] dm_mod: disagrees about version of symbol module_layout -- [ 217.993684] [drm:vop2_plane_atomic_check] *ERROR* Invalid size: 64x1->64x1, min size is 4x4 [ 218.001798] [drm:vop2_plane_atomic_check] *ERROR* Invalid size: 64x1->64x1, min size is 4x4 [ 218.009720] [drm:vop2_plane_atomic_check] *ERROR* Invalid size: 64x1->64x1, min size is 4x4 [ 439.786500] iwlwifi: disagrees about version of symbol module_layout [ 445.011474] iwlwifi: disagrees about version of symbol module_layout [ 476.290795] iwlwifi: disagrees about version of symbol module_layout Manually installing the iwlwifi driver yields: # modprobe iwlwifi modprobe: ERROR: could not insert 'iwlwifi': Exec format error Perhaps more people ran into the same problem? Of course I ran into this problem while quickly trying to access some server, only finding that the wifi adapter was not working anymore ("it used to work"). The quick & dirty solution was finding a cable bypassing wifi.