specs

On the danger of sounding very stupid: I downloaded the image Armbian_23.02.3_Rock-5b_sid_edge_6.3.0 and Armbian_23.04_Rock-5b_sid_legacy_5.10.110. With the edge-image I got no display, so that seems a dead end for me. With the legacy-image I could start and I could use armbian-install to update the firmware (the powersupply is 12V fixed voltage) Now I have a booting image on SD and I wonder how I can install the image on NVMe. The only install-option I see is "7 install mtd block" (which I did). After that I expected a need to reboot and choose option 3 or something like that, but the only available option is option 7. I can see the nvme-drive and I can make volumes on the nvme using fdisk, but I don't know how to install the system. The other thing I tried is dd-ing the image to the nvme-drive, but then both nvme and SD-card failed to boot and I found myself rewriting the image on the SD-card. How can I install Armbian on NVMe using the 23.04-image?

if you still have access to a prompt I'd suggest you login and remove the iujianfeng1994-ubuntu-panfork-mesa-kinetic.list from /etc/apt/sources.list.d/ What I did: run "dpkg --get-selections > installed-pkgs" remove everything which includes panfork in the name with dpkg, manually remove the liujianfeng ppa run "apt clean" run "apt update" reinstall the desktop reinstall all the pkgs removed when removing the panfork packages (I used ""dpkg --get-selections > installed2" and diff) reboot and the desktop reappears The sunny side is, removing panfork means some weird bug where the pointer disappears after the screensaver kicks in disappeared. The dark side is, you lose hardware GPU acceleration. Alternative solution (untested): update mesa23.0~panfork~csf to git221210.120202c6757~j+1 JianFeng Liu (10 hours ago) <= wasn't there this weekend. Note that some developpers ban the panfork project, since I had the same issue (and the above bug) I dumped it for now. I'll wait to see what mesa driver gets adopted in the official armbian distribution.

I tried to boot my system to NVMe and the result of my trying was: - powered with constant 12v1.5W (i.e. PD problems are ruled out) - bootable SD-card and NVMe or - bootable eMMC and NVMe If there is no problem with the power (PD problems should be ruled out since you use the Radxa SPI image) the bootable NVMe overrules the SD or eMMC. This means the system won't start if the partitions was not setup correctly. I think you can only try this method with an NVMe which has no boot partition already. Which means the "dd if=/dev/zero of=/dev/nvme0n1 count=100" might have to be executed with an USB-NVMe drive or something. Without bootable NVMe partition, the system might start correctly. Since my eMMC is only 32GB I will have to try to boot from NVMe, so I will try to boot the NVMe. If I have to use an USB-NVMe module I would prefer to setup the NVMe without SD or eMMC. I'll try if that works. Edit: I did see you used the method mentioned in the Radxa Wiki, this is where you probabbly found the link for the SPI image. If the SPI image fails there is allways the rkdeveloptool-option.

I think the power supply might deserve it's own topic. Like balbes mentioned PD is meant for devices with internal battery. There it saves the battery during fast charging by preventing overcharging. The Rock 5B is further 'borked' since the negotiation starts after the system starts. The advantage is it can be open source (more or less), but the big disadvantage it is so slow most PD chargers stop negotiating during system start in the meantime. If you realise that the power supply in the Rock 5B (IP2315) is just a step-down converter with some logic and a PD car-adapter adds an step-up adapter to the equation you might realise it makes no sence to operate the power input at 20V. While the resistance in the cable might be minimized the power loss in the step-down and the step-up converters are maximized. Most power supplies can achieve 95% efficiency, but cheap step-up/step-down converters can only achieve that when V_in is almost equal to V_out. Normal PD-adapter should work more efficient than 12V car-adapters, but even then if they very efficiently produce 20V which the R5B very inefficiently transformes to 3.3-5V does that make sense? A 20W PD car-adapter adds roughly 0.5W to the power consumption. With a 65W/20V PD car-adapter the adapter might add more, but the step-down converter in the R5B will definitely work more inefficient than at 9V.

Does not work for the Rock5B. $ cvt 2560 1440 30 # 2560x1440 29.94 Hz (CVT) hsync: 43.95 kHz; pclk: 146.25 MHz Modeline "2560x1440_30.00" 146.25 2560 2680 2944 3328 1440 1443 1448 1468 -hsync +vsync $ xrandr --newmode "2560x1440_30.00" 146.25 2560 2680 2944 3328 1440 1443 1448 1468 -hsync +vsync $ xrandr --addmode HDMI-1 "2560x1440_30.00" $ xrandr --output HDMI-1 --mode 2560x1440_30.00 xrandr: Configure crtc 0 failed # dmesg <cut irrelevant messages> [527761.070776] rockchip-vop2 fdd90000.vop: [drm:vop2_crtc_atomic_disable] Crtc atomic disable vp0 [527761.140128] dwhdmi-rockchip fde80000.hdmi: use tmds mode [527761.140179] rockchip-vop2 fdd90000.vop: [drm:vop2_crtc_atomic_enable] Update mode to 1920x1080p60, type: 11(if:800) for vp0 dclk: 148500000 [527761.140714] rockchip-vop2 fdd90000.vop: [drm:vop2_crtc_atomic_enable] dclk_out0 div: 0 dclk_core0 div: 2 [527761.140730] rockchip-vop2 fdd90000.vop: [drm:vop2_crtc_atomic_enable] set dclk_vop0 to 148500000, get 148500000 [527761.157566] rockchip-hdptx-phy-hdmi fed60000.hdmiphy: hdptx_ropll_cmn_config bus_width:16a8c8 rate:1485000 [527761.157865] rockchip-hdptx-phy-hdmi fed60000.hdmiphy: hdptx phy pll locked! [527761.157898] dwhdmi-rockchip fde80000.hdmi: final tmdsclk = 148500000 [527761.161610] dwhdmi-rockchip fde80000.hdmi: don't use dsc mode [527761.161618] dwhdmi-rockchip fde80000.hdmi: dw hdmi qp use tmds mode [527761.161628] rockchip-hdptx-phy-hdmi fed60000.hdmiphy: bus_width:0x16a8c8,bit_rate:1485000 [527761.161835] rockchip-hdptx-phy-hdmi fed60000.hdmiphy: hdptx phy lane locked! [527761.240961] dwhdmi-rockchip fde80000.hdmi: use tmds mode I think you have a better change by adding a screen resolution in the DTS. On the radxa forum someone has tried it (8's post): https://forum.radxa.com/t/ubuntu-image-with-x11-and-resolution-2560x1440/12553 I had no change to test it yet.

The U-boot from hardkernel does not boot from USB when in skip_spiboot mode. An SD-card with the hardkernel image boots fine with the wifi adapter attached, even with skip_spiboot. Therefore tripping over the cd-device during boot is a very specific Armbian problem. The problem probably starts with the pre-release bootstrap, after the initial boot phase and before switching to nvme partition. A wifi adapter which identifies itself as a cd-device is a problem in itself, of course. With a working spiboot for the M1, it should be managable though.

Small update: the 5B (8821cu) is at boot recognized as cdrom, which prevents the M1 from booting. Can the M1 somehow be configured to ignore an USB cdrom?

Thanks for the referance. I did not get the Odroid Wifi 5A working, but the 5B did work (after an usb-modeswitch, so I still have to add an udev-rule).

Just for the record: I used a PD+QC3.0 12V adapter for cars behind a programmable power supply (5-20V/3A). Findings (lot's of open doors): - get the smallest PD adapter you can find, since a 65W PD adapter uses more power than a 30W PD adapter (the 65W adapter provides 20V, where the 30V generatesonly 9V, the difference is almost 1W continously). - Since you don't need the battery saving function from PD using QC acts like a constant voltage connector. - With QC and a cheap cable the only data from the power supply is "1.5A". - A direct power connection depends on the cable used, with 5V and a cheap cable expect the cable to be recognized as 1,5A! - The Raspberry power supply probably is detected as 5V with 3A cable. The obvious conclusion is that starting with 20V instead of 9V burns more energy, since the internal step-down convertor just generates more heat. With a lab power supply, expect 9V/1,5A or 12V/1.5A with a cheap cable. You might want to cut up a 3A cable if you want something better. The direct power with cheap cable (5V/1.5A) is unstable, while the Raspberry power supply works (limit in the Rock5B?). My current settings: $ cat /sys/class/typec/port0/power_operation_mode usb_power_delivery $ sensors|grep -A3 tcpm tcpm_source_psy_4_0022-i2c-4-22 Adapter: rk3x-i2c in0: 9.00 V (min = +9.00 V, max = +9.00 V) curr1: 2.22 A (max = +2.22 A) Direct power with 9V/1.5A or 12V/1.5A is usable for a quick start. A 3A cable is something you should really want (like I said, open doors). Testing with eMMC, without NVMe, the small PD adapter gives a stable power, without wasting too much.

If you see the device with lsusb, it is just that (the device is plugged in). Do you see the modules needed to use the device? The third step might making a link from the usb-device to /dev/dvb I would suggest testing lsmod on the RPI with the DVB plugged in. Then a "ls -ali /dev/" with the DVB plugged in (the "-al" should be obvious, the "i", checking the inodes, is especially important for devices). If the plugins are not available, it is probably not going to work with the vendor kernel. If the /dev/dvb is the only part missing it probably can be fixed with some udev rules.

Normally I'd say it is either ubuntu-desktop or ubuntu-minimal, but here my first choice would be removing xfdekstop4. When in doubt, try "dpkg -l | grep desktop" and remove whatever you'd find, like "apt remove xfdesktop4". Then you follow with an "apt autoremove". In this stage read carefully what is to be removed!

I ran into a similar problem wit the Rock5B. # apt update Get:11 http://armbian.hosthatch.com/apt kinetic InRelease [29.4 kB] Err:11 http://armbian.hosthatch.com/apt kinetic InRelease The following signatures couldn't be verified because the public key is not available: NO_PUBKEY 93D6889F9F0E78D5 Reading package lists... Done W: GPG error: http://armbian.hosthatch.com/apt kinetic InRelease: The following signatures couldn't be verified because the public key is not available: NO_PUBKEY 93D6889F9F0E78D5 My solution was posted earlier, using the ubuntu keyserver (dexrock's reply) as the quick & dirty solution. Looks to me like the solution above (the one references in the github lines) downloads a different key.

Don't set locales on location. Choose "no" when asked at boot. And select the locales you want. I'm from Belgium but want English. So I choose. No, 47, 7, 6, 1 Or change locales with "sudo armbian-config" I found the culprit: Some applicaton put LC_ALL and nl_NL.UTF* in the ~/.xsessionrc, after removing that file the language was restored to english. The armbian-config does the same thing as "dpkg-reconfigure locales", so it did not help me. No idea why you have armhf packages. Did you install box86 or something else that use armhf? Exactly my opinion! Why would Armbian ship armhf binaries with the Rock5 image? And why would Armbian not exclude armhf repositories by default? (Removing CONFIG_COMPAT from the kernel configuration might be a bridge too far for now, though I'd appreciate it.) Probably some of the reasons this image is still "work in progress". PS like others above I needed to install using a RPI 5V 3A power supply. After installation I could switch to a USB PD power supply.

First real experience with Armbian here. Rock5B with eMMC So far: the locales settings is really hell (I set the timezone somewhere in Europe and the system wants to set the language to local as well, even after 5 attempts I still some messages not in english and some LC_ALL error). The display, I changed the sources.list for the mesa files like mentioned above: #deb [signed-by=/usr/share/keyrings/oibaf.gpg] http://ppa.launchpadcontent.net/oibaf/graphics-drivers/ubuntu/ jammy main deb https://ppa.launchpadcontent.net/liujianfeng1994/panfork-mesa/ubuntu/ jammy main In the /etc/apt/sources.list itself some changes to prevent armhf libraries from installing: deb [arch=arm64] http://ports.ubuntu.com/ kinetic main restricted universe multiverse And finally after removing most armhf libraries I get a system dependency on lybcrypt1:armhf. root@rock-5b:~# apt remove libcrypt1:armhf .. The following packages will be REMOVED: libc6:armhf libcrypt1:armhf libgcc-s1:armhf libidn2-0:armhf libunistring2:armhf WARNING: The following essential packages will be removed. This should NOT be done unless you know exactly what you are doing! libcrypt1:armhf libc6:armhf (due to libcrypt1:armhf) 0 upgraded, 0 newly installed, 5 to remove and 0 not upgraded. After this operation, 25.2 MB disk space will be freed. E: Removing essential system-critical packages is not permitted. This might break the system. Very annoying, but for a not-yet-supported-system I think it is promising. I did get X working and the network (both eth0 and the RTL8192, the 8811 and 8821 unfortunately not yet due to dkms problems with the installed kernel). It would be helpfull if I knew how to set the locales to english. The armhf system-dependency looks like some garbage that needs to be removed before the official release.