schwar3kat

Nice video Werner!

Thanks Werner, I initially misread it. Corrected it already.

What Armbian image are you using and how did you burn it? Have you tried another image? Does the board work with one of the suppliers images? Armbian getting started instructions: https://docs.armbian.com/User-Guide_Getting-Started/ Armbian Opi5+ download page: https://www.armbian.com/orange-pi-5-plus/ Suppliers Wiki: http://www.orangepi.org/orangepiwiki/index.php/Orange_Pi_5_Plus

Hello again @Well I'm not seeing a lot of response to your question so I will make a suggestion. I'm guessing that you are using one of the Ubuntu based Armbian builds? Perhaps Jammy? I have not tried this, but this but these Ubuntu instructions may work. Please let us know if this works. https://tech.sadaalomma.com/ubuntu/how-to-remove-netplan-ubuntu-20-04/

Thanks Werner, this is great.

Are you logged in as root? Your overlay_prefix=rockchip in the built image, so the menu should be visible under System then Hardware and should show all rockchip dtbo's. This board is a work in progress, so probably there is stuff missing and not working. Look in /boot/dtb/overlay to find available overlays. Drop the overlay_prefix and the .dtbo if you add them manually into armbianEnv.txt Reboot to activate. Those beginning with rockchip may work but I suspect that rockchip-RK3568B2 may be different there are no guarantees for a WIP board. Perhaps the suppliers image has overlays that you could harvest.

Devices not installed on the board are generally enabled using device tree overlays. I don't have your board, but I did this some time ago with an Orange Pi Zero. Tutorial I used UART1 and PA7 From the tutorial: Add two lines to /boot/armbianEnv.txt to tell the Orange Pi Zero to use PA7 for PPS and uart1 for GPS NMEA messages overlays=uart1 pps-gpio param_pps_pin=PA7 You may not need to edit the file manually, you can add overlays from armbian-config, System, Hardware (you can see which overlays are available for your device). Overlays may have different names for different boards and families. If you can't find one for your board, it may be that nobody has created one yet.

What board is it? If you can find a similar board, that would be a good starting point otherwise this is not a simple undertaking. It's not just the CPU, it's the board and integrated devices. These must be defined in a device tree. Each of the devices has to have an appropriate driver compiled into the kernel.

Probably.

@InfernalWolf666 As you have provided no logs, I can't see what Armbian image you have used. Your board is very new and it is likely that things are still missing from the upstream Kernel and the legacy build . In such cases the legacy build is often more complete than the current build. Those are device tree overlay files that you have found, however they are from another source and another board and are not relevant. Hardware devices that are not included by default on the board are usually not included in the default device tree. They would normally be added as device tree overlays. They are not drivers, they just map the hardware addresses so that the devices can be addressed by software. Drivers are generally included in the Kernel if they exist in the mainline Kernel or have been added as patches into the Armbian build. Device tree overlays can be applied through armbian-config, System, Hardware. (possibly not relevant but included for your understanding) Screenshots of armbian-config from a legacy build: (From a console type armbian-config) There are a number of overlays available for Opi5+ but I don't see anything related to your issue use the arrow keys to scroll. I suspect that your device may not currently be supported by the build that you are using. EDIT: According to the download page, you need to enable orangepi-5-ap6275p overlay from Hardware menu of armbian-config and reboot.

I don't see this load to early issue on any of my boards, perhaps it is specific to your board. Please note that cpufrequtils is deprecated and has a number of issues with various boards that are unlikely to be addressed. (the other issue with cpufrequtils not being enabled by default for all boards has been addressed).

Good point about I wouldn't have noticed, because personally, I haven't seen a need to use this armbian-config functionality but people are apparently using it so what do I know? The main issue, as I understand it, is that an armbian-config function doesn't work as it could reasonably be expected to work. I will mull over and test an idea and perhaps I can come up with a simple way to control expectations based on the ENABLED state. Edit: AR-1883

I can confirm that in current images that I examined, in /etc/default/cpufrequtils, ENABLE is set to false. In older images that I examined ENABLE was set to true. This affects all boards. Without ENABLE being set, the armbian-config CPU speed governor settings simply don't work. Normally when cpufrequtils is installed, and a CPU driver exists, then the installer sets ENABLE to true. But cpufrequtils is pre-installed by Armbian build. Before logging a Jira issue I thought that I should investigate further to try and understand what had changed led me to this change tagged as [HIGHLY CONTENTIOUS CHANGE]. @rpardini do you have any insight into this change or advice?

What are you plugging into the USB3 ports? Is your power supply capable of supplying enough current? If you measure USB3 inline voltage does it drop when you plug in the device? I am running the same Kernel version on OPi 5+ and my USB3 ports work with externally powered HDD's. Kernel and firmware upgrades disabled on mine.

Because you are not using Armbian build for your u-boot, we can't know what might be wrong or missing. Armbian build documentation Have you tried to dd your entire SD card? You might need to shrink your image if not copying to an identical or larger SD card. Old instructions still work

I think that something like this should work (I've done similar in the past, but I'm working from memory, so I may have missed something): Flash the new SD card with the same OS image used for the original card (a similar image may also work if u-boot isn't too different). Boot the card and allow it to expand the partition (or expand the partition using gparted or similar to about 80-90% of the SD card). Back up /etc/fstab from the new SD card to a safe location (it's a good idea to backup the /boot directory as well). Mount the new SD card RW on a Linux computer. You will need to be root or sudo su for most of the following. Delete all directories and files except for the /boot directory and it's contents from the new SD card. The new SD card root file system should now only contain /boot and it's contents. Rename /boot to /boot-backup Copy all files retaining permissions and attributes including /boot directory from the original SD card to the new SD card. https://www.makeuseof.com/preserve-file-permissions-in-linux-while-copying-them/ Replace /etc/fstab on the new card with the fstab that you backed up. Or edit the /etc/fstab on the new SD card '/' to match the UUID in your backed up fstab (this method only required if your original has extra non standard fstab entries). Change the UUID in /boot/armbianEnv.txt to match the entry in /boot-backup/armbianEnv.txt. (something like rootdev=UUID=f0920bd6-7fea-42cb-a9cd-3db938a68382). It should also match the '/' UUID in /etc/fstab. Good luck and let us know how it goes.

Just started - and I can see it configured in the Makefile. "obj-$(CONFIG_BLK_DEV_RBD) += rbd.o" Halfway through - and it's built the module object. "rdb.o" Completed - and I can see the file "rdb.o" in the image in "/lib/modules/5.10.160-rk35xx/kernel/drivers/block" which is correct. (Do you have this in your image?). /boot/config-5.10.160-legacy-rk35xx contains "CONFIG_BLK_DEV_RBD=m" as expected. Looks okay as far as i understand, but I'm no expert. Did you save your new configuration after selection and exits? Your second build on the same clone should be faster because of caching.

I don't have your board, so I can't test, and I'm not familiar with Rados block device, but I will build it and see if I can see the module.

In the screenshot, you are not root, so all modprobe commands require sudo privileges. Try: sudo modprobe rbd

@Werner - Are there no more Armbian developers meeting videos? I was rather hoping that they might reappear. Maybe I missed some announcement. I see Developers Meetup in the calendar. I haven't been able to attend, but I had been watching these videos to catch up. I see a mention of Jitsi in the calendar event, but no link or instructions how to join the event if I could. I thought maybe the video might be attached to the Jitsi event (I don't know if Jitsi can do this).

I used https://mirror.yandex.ru/mirrors/armbian/archive/orangepi5-plus/archive/Armbian_23.5.4_Orangepi5-plus_jammy_legacy_5.10.160_xfce_desktop.img.xz but this is a different board. I guess any legacy Jammy 5.10.x should work. Look here for something suitable https://mirror.yandex.ru/mirrors/armbian/archive/orangepi5/archive/ Maybe: https://mirror.yandex.ru/mirrors/armbian/archive/orangepi5/archive/Armbian_22.11.3_Orangepi5_jammy_legacy_5.10.110_xfce_desktop.img.xz You can't use the official Kodi ppa version of Kodi. It doesn't include k35xx acceleration or a working widevine cdm for arm64. You must use amazingfate's ppa for Kodi and not the Kodi official ppa. When updating or installing the inputstream.adaptive plugin from that ppa or from any Kodi repository, it will prompt you to update widevine. cdm, The widevine cdm update that is installed doesn't currently work with arm64 Linux. At the bottom of my notes below, you can follow how to manually copy the right one, assuming that you have it installed in amazingfate's Chromium. If you have the wrong Kodi installed then remove it and remove the official ppa. My notes are a couple of months old, but if my notes are correct these are the steps to get Chromium widevine cdm and Kodi installed (use at your own risk) Good Luck: sudo add-apt-repository ppa:liujianfeng1994/panfork-mesa sudo add-apt-repository ppa:liujianfeng1994/rockchip-multimedia sudo apt update sudo apt full-upgrade sudo apt install libwidevinecdm I might specifically have installed or reinstalled Chromium, but I don't have it in my notes. It may have done it automatically with the upgrade. Some DRM streamers check the Chromium user agent on arm64 and won't work unless they find a ChromeOs user agent. Create a launcher for DRM-Chromium with the correct user agent for widevine (or just launch it like this from the command line): chromium-browser --user-agent="Mozilla/5.0 (X11; CrOS aarch64 15236.80.0) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/109.0.5414.125 Safari/537.36" Check widevine DRM works in Chromium with https://bitmovin.com/demos/drm sudo apt install ubuntu-desktop kodi Start Kodi and install your plugins. Try to run one DRM video and when it errors, do an apt install for inputstream.adaptive as recommended by the error message. Install widevine cdm as prompted. This will create the directory structure for widevine and install the non-working version. Copy libwidevinecdm.so from /lib/chromium-browser/WidevineCdm/_platform_specific/linux_arm64/ to /home/{username}/.kodi/cdm/ Restart Kodi.