Werner

expected. HDMI implementation is not yet complete. 6.13.y will bring a few enhancements in that matter. have you explicitly apt update;apt upgrade before? There were issues in the past but have been fixed iirc.

While it is overpowered it would be ideal to power any SBC since the output voltage can be adjusted/raised to compensate for losses. I personally have something similar but with 35 amps output current Check my ramble here:

Hm even though that's probably an edge case it would be nice to know if the workaround of openwrt actually works and why for Armbian it does not....

You could try a more recent rockchip sdk kernel based image if the result differs: https://github.com/armbian/community/releases/download/25.2.0-trunk.293/Armbian_community_25.2.0-trunk.293_Orangepi5pro_noble_vendor_6.1.84_gnome_desktop.img.xz

Check with armbian-config if this is implemented already or https://www.google.com/search?client=firefox-b-e&q=debian+install+desktop+environment I won't recommend desktop with your unknown rk3588s device since hdmi and other related things are not fully implemented in mainline yet. Best desktop experience gives you vendor kernel.

I am pretty sure you have been warned before switching to beta that this might break things. Anyway, overall the only thing I can say about all of this is 'welcome to the world of cheap SBCs'. This is the kind of stuff we are dealing on daily basis where stuff randomly breaks and under-staffed to fix things in reasonable time and vendors flood the market with devices, some better, some worse, some downright ugly. We're both frustrated, you're not alone. If you want something on arm architecture that just works an behaves like x86 you have to spend a lot of money (Ampere Altra system for example or anything with proper UEFI implementation). But for cheap SBCs you pay for hw only, not for sw. Latter is left to hobbyists and projects like Armbian (which consists mostly of hobbyists) to take the burden of software maintenance. To get back to the actual problems. I think NVMe support broke at some point with vendor but should be good again with latest sdk. I have an opi5+ with that running from NVMe just fine. I built an image from the most recent sources here for you to try: https://fi.mirror.armbian.de/.testing/Armbian-unofficial_25.02.0-trunk_Rock-5b_bookworm_vendor_6.1.84_minimal.img.xz

https://github.com/armbian/linux-rockchip When comparing also keep in mind we're on rkr4.1 version of rockchip sdk while Joshua was on rkr3 before he quit. Yes, maybe. Maybe in both the dts exist in full in both sources so comparison is easy.

That's a good question. I would probably try things like comparing dmesg output after boot from the board with and without and check for differences. If you're lucky the name is right there. If so I'd try to extract the blob and place it manually where it would be if the firmware package would be installed and see if it works.

In short: yes In long: yes, but.... Here is a small explanation about following the development efforts of what we call vendor and edge: When and if Rockchip provides a new version of their bsp we may adapt it unless it severely breaks things. Also occasionally various developers contribute to this code to fix things. Kernel updates will be provided with such. Current will stick to 6.12.y since it is an LTS kernel release until a new LTS version is released upstream. There won't be new features but the usual LTS bug fixing. These fixes will be pushed every few versions unless there is a critical issue. Edge will follow mainline kernel which is 6.13.0-rc at this time. Kernel updates also here of course but breakage is much more likely in comparison to current and vendor. Bleeding edge to say Having a SoC well matured upstream takes years. So not sure how long you plan to wait but for now, if you want a nicely working desktop experience, vendor is a good choice.

Mainline kernel which is still under heavy development. HDMI sound might not be implemented yet. I suggest to try a vendor kernel (6.1.y) based image instead. This kernel is a customized variant of the rockchip sdk kernel which should be close to feature-complete. You can follow mainline efforts here: https://gitlab.collabora.com/hardware-enablement/rockchip-3588/notes-for-rockchip-3588/-/blob/main/mainline-status.md

This seems like a bug to me. The linux-*-vendor packages you mentioned should be frozen with this option as well. I forwarded this to the repo: https://github.com/armbian/configng/issues/368

No. You can build Armbian on any Linux machine if Docker is available. Check my workaround above. It just pulls the package from a random mirror (dotsrc in this case) and installs it via dpkg. Might be interesting to know which are necessary so they might get moved into standard firmware package to make this work oob.

Well rpi is partially proprietary and especially the boot process is handled completely different that other boards. However I found a workaround. No clue it if works, I don't have this board and probably never get one unless its a gift lol Main() { apt-get update apt-get -y install wget cd /root wget http://mirrors.dotsrc.org/armbian-apt/pool/main/a/armbian-firmware-full/armbian-firmware-full_24.11.2_all__1-SA8dbb-SM633e-B6c7f-R448a.deb dpkg -i *.deb } # Main Main "$@"

Confirmed. Well that's odd. Maybe bad luck to both of us having a bad mirror when attempting? Anyway have you checked if the armbian-firmware-full packages actually contains the necessary blobs you are looking for? Check github.com/armbian/firmware

Just checked and it seems like their Release file on the repo is still marked with ovm6 while the package you get when installing is omv7. Tried to build an image with omv pre-installed, but throw a bunch of errors, so no idea if it works. https://fi.mirror.armbian.de/.testing/Armbian-unofficial_25.02.0-trunk_Rockpro64_bookworm_current_6.12.9-omv.img.xz If not grab a standard rockpro image ( https://dl.armbian.com/rockpro64/Bookworm_current_minimal ) and proceed according omv docs: https://docs.openmediavault.org/en/stable/installation/on_debian.html Keep in mind that omv heavily messes with the system, so if anything breaks after installation (like network access or even boot) we cannot help. This is userspace.

If you want an arm64 board that behaves like and x86 this is possible, but you have to spend a lot of money. You get is what you pay for.

Ah you have set SHARE_LOG to yes which is good in general but in this particular case isn't You can either - set this to no so you will be provided with the curl command or - additionally set PASTE_URL="https://paste.armbian.de/log"

Feel free to build an image with edge branch which is 6.13-rc...5..ish? I don't remember. Anyway this should give you a good idea about what to expect when it becomes stable after rc7.

Hi At the end of the build process you will provided with a curl command to send logs to https://paste.armbian.com/logs simply copy&paste this command to get the URL you are looking for Tip: If upload fails try replacing paste.armbian.com/logs with paste.armbian.de/logs or paste.armbian.eu/logs

never heard of that one before. image name and source? Edit: Found. You are not using Armbian but a fork. We cannot support 3rd party images. Ask at the place where you got the image from for help.

Hi Providing logs with PASTE_SERVER_HOST=paste.armbian.de armbianmonitor -u helps with troubleshooting and significantly raises chances that issue gets addressed.

There isn't much to it. tl;dr: clone the repo using git and execute ./compile.sh. Rest is interactive. https://docs.armbian.com/Developer-Guide_Build-Preparation/ Yes it is possible to include omv6(!) while building the image but there is actually not much to it doing by hand. This is basically how an Armbian omv-preinstalled image is made: https://github.com/armbian/os/blob/3c2bf37c3544f2d16ac12e1c407e6976367ec4d0/userpatches/extensions/omv.sh#L15-L35 tl;dr: grab omv key, install omv key, apt update, apt install openmediavault You can do that manually after first boot.

Build your image with code { font-family: Consolas,"courier new"; color: crimson; background-color: rgba(0, 0, 0, 0.2); padding: 2px; font-size: 105%; } ENABLE_EXTENSIONS=mesa-vpu. This will address necessary packages for acceleration, depending on which kernel you choose. For desktop usage I recommend going for vendor branch (kernel 6.1.y to say) as mainline is still under heavy development.

I recreated the patch to include dts patch for the r6c. You can test this image which should include it: https://fi.mirror.armbian.de/.testing/Armbian-unofficial_25.02.0-trunk_Nanopi-r6c_bookworm_current_6.12.9_minimal.img.xz

We provide just a very small selection of images for each hw and even that eats a lot into our resources. See https://docs.armbian.com/User-Guide_FAQ/#why-is-there-no-image-for-board-with-bookwormjammynobletrixie-and-minimalclignomekdexfce-with-vendorlegacycurrentedge-kernel However the build framework makes it very easy to combine whatever you want together. Just like the image I provided you https://docs.armbian.com/Developer-Guide_Build-Preparation/