specs

@Eselarm, you are right. Compared to pcb antennas using monopoles is the ancient way to make an antenna. When protruding antennas are likely to be damaged I'd say pcb's should be preferred (especially inside a plastic casing). The monopoles are easier to make, but the connectors add to the costs. With a higher gain the production numbers might be more important then the structural efficiency. That makes the choice between pcb and monopole higly dependent on the application (costs vs efficiency vs robustness). Just to say, I'd still use monopoles. PS For the record: the holes can only be drilled at one end of the casing since the inside is free above the rear panel. Above the cpu the casing is only partly cut away and you still find a thick block of aluminium on top. When too close to the edge you will not be able to attach an antenna straight, though. That's why you need a stable drill. My M6 looks a little like the R5C with antennas although they could have been attached more straight.

The pre drilled holes in the M6 casing are too close to the connectors at the rear side to be of use. Just think how big the antennas are and you'll see they cannot be used without blocking the rear connectors. Modern connectors for wifi adapters are round (for MT7922, AX210 and RTL8822). Ancient small 2400Hz antennas are smaller and have one flat side. But they might not be suited for wifi6. Holes can be drilled in the sides of the casing, one left, one right. It will be a tight fit, but I managed to fit my wifi adapter with 2 antenna connectors with all connectors on the rear available.

It largely depends on the system. A simple "echo 0 > /sys/devices/platform/leds/leds/system-led/brightness" will kill the heartbeat on a T6. (The heartbeat itself is activated in the DTB.) The other leds should available along the same path (user_led, etc.). NB I have found no other way of restoring the heartbeat than rebooting.

Don't you have a computer with a free USB-C port? Then you just can use a standard USB-A to USB-C cable. Most recent laptops use USB-C for power (USB PD) which also can be used for a serial console (although for long session you might need a USB-C docking station). The T6 is a little easier than the R6C, since it provides both the serial console and the maskrom connection over USB-C, meaning either a USB-A to USB-C is needed or USB-C to USB-C. For EFI you could try: https://github.com/edk2-porting/edk2-rk3588 But my guess is that it a lot of work to provide a different way of booting from u-boot. It might be a improvement, but then again it might not.

@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.

Conclusion: the only kernels you can switch between with armbian-config are the 5.10 legacy and the 6.1 vendor kernels with the current setup. You did mention "Usually", but basically I guess the "armbian-config" and "exchanging kernels" route only is only recommended with "standard support". There is much which can go wrong and I did end up reinstalling (starting from SD is no guarantee your NVME is not ending screwed up).

It seems like the Radxa Rock5B has been downgraded from standard support to community support for the image downloads but not (yet) for the forum. Are the vendor images for the RK3588 and the 6.8.x images the same except for the kernel? (Can I expect to just replace the kernel to switch from the vendor image to the edge image.)

After installing Armbian_23.2.1_Rock-5b_bookworm_legacy_5.10.160_xfce_desktop.img I found a nagging error each start of Firefox. "Failed to read the configuration file. Please contact your system administrator." Looking at internet with Google I found hardly any link referring to linux or armbian, therefore I still don't know which configuration file was actually missing or damaged. The only link I found with armbian in it contained some very obscure editting of some configuration files (just like many proposed Windows solutions). The issue: where does it go wrong? The problem is some configuration clutter somewhere in /usr/lib/firefox-esr. And how to solve? A Windows video showed a user removing and reinstalling firefox. Reinstalling with a blank configuration really does solve this problem (try as root or use sudo): apt --purge remove firefox-esr rm -rf /usr/lib/firefox-esr apt install firefox-esr I guess only users who don't use a minimal image may encounter this problem.

Does the latest version include Andy Yan's HDMI/VOP2 patch? (I believe the downstream patch v1 was dated 14 november.)

PD has advantages when you use the cables at 2A for a long time. But that is typically for charging a phone or a laptop in a short time. With a PD-adapter the power consumption is pretty bad for the Rock5. With a constant Voltage power supply it is only bad in combination with NVMe and good in combination with eMMC. When powered of, without removing the power cable, the Rock5B still uses about 0,5W (slightly worse than a RPI4, which is already bad). When using eMMC the Rock5B uses about 1.8-2W in idle. When you are using a general 30-65W PD adapter make it 2.4-3W in idle (the DC-DC conversion from 20V to 5V is very inefficient, if you have a small and cheap PD adapter this adds to the inefficiency). When using an NVMe you could get the power consumption as low as 4W in idle, with a 12V constant voltage adapter. CPU 0-3: 1200 ( 600 Mhz - 1800 MHz / conservative) CPU 4-5: 816 ( 408 Mhz - 2400 MHz / conservative) CPU 6-7: 600 ( 408 Mhz - 2400 MHz / conservative) GPU : 300 ( 300 Mhz - 1000 MHz / simple_ondemand) DMC : 1560 ( 528 Mhz - 1560 MHz / dmc_ondemand) Here the pcie_aspm (NVMe connection) is set to powersupersave. With the pcie_aspm set to performance and all the cpu and gpu settings to max you get 6W in idle. CPU 0-3: 1800 (1800 Mhz - 1800 MHz / performance) CPU 4-5: 2400 (1000 Mhz - 2400 MHz / performance) CPU 6-7: 2400 (1000 Mhz - 2400 MHz / performance) GPU : 1000 ( 300 Mhz - 1000 MHz / performance) DMC : 2112 ( 528 Mhz - 2112 MHz / performance) The Kingston A2000 might not be the most energie-efficient NVMe, but other brands generally also focus on performance instead of efficiency. The above summary is made by parsing the settings from: /sys/devices/system/cpu/cpufreq/policyX/ /sys/devices/platform/fb000000.gpu/devfreq/fb000000.gpu/ /sys/devices/platform/dmc/devfreq/dmc/ /sys/module/pcie_aspm/parameters/ (You can also use the sys-tree to quickly change the settings with a script). Ondemand and conservative are generally similar for power consumption in idle mode. Earlier experiences that low power consumption and NVMe are a bad combination is true for the Rock5 as well. PowerSuperSave can not be considered a stable option for all NVMe drives. But still with lowpower solutions NVMe might be preferable to eMMC since it is slightly better protected against data loss. In performance mode, during a compilation, the consumption easily reaches 13W (with NVMe, without large USB users, without much GPU use). (I use a cheap power supply with monitoring to get the general idea of power consumption, not a calibrated solution). Finally you could use a constant power supply of 5V to lower the power consumption in idle. I would not recommend that , I think optimizing for 1.5A at peak performance is better, resulting in 9V or 12V for most cases. (Instead of PD, QC is probably cheaper and more power efficient).

Pressing escape to enter the UEFI, changing the boot order apparantly was the correct option. (Bypassing the armbian-config script). After changing the boot option I had to again issue a root password which probably means the installation is started from zero. Now I need to know if (using the 23.04-legacy image) I can change the kernel to the edge kernel. PS on the 2304 image: that probably can be counted as a success since I was (relatively easy) able to install the system on a NVMe starting with the Radxa SPi image. It would be easier to enable the 'normal' armbian-install script than just uploading and dd-ing the image to the nvme, but that's why it is still labelled as "WiP", I guess. What I want to do soon is decrease the partition size and install an edge image besides the 2304 image, including a recent 6.x-kernel. Any hints on the process are welcome! It seems that just booting the original SD card is not a working method. A new image booted from UEFI/EDK might be an option,