Werner

I found some sample initramfs hooks that might give you some clues how to achieve your goal: https://github.com/simonschiele/initramfs-hooks

Opi0 and Opi0-3 have nothing in common besides the naming. It is not that easy.

Providing logs with armbianmonitor -u helps with troubleshooting and significantly raises chances that issue gets addressed.

If you need hdmi support use vendor or edge kernel. 6.12 was released with a bare minimum of support for rk3588 so nonworking hdmi is kind a expected.

I added a suggestion at the PR how to implement the driver while building to allow network oob.

try code { font-family: Consolas,"courier new"; color: crimson; background-color: rgba(0, 0, 0, 0.2); padding: 2px; font-size: 105%; } xrandr

There are unfortunately no detailed instructions how to add new boards or board families to the build framework yet. This is a very extensive topic. However there are a few existing pull requests that should give clues like https://github.com/armbian/build/pull/7902/files No, since it is community supported use Stating section for Rockchip devices in forums. I did a quick check on your work. - dts files which aren't upstreamed (yet) shall be added in full into the dt folder of the equivalent kernel patch directory (patch/kernel/archive/rockchip64-6.16/dt to say). You can use code { font-family: Consolas,"courier new"; color: crimson; background-color: rgba(0, 0, 0, 0.2); padding: 2px; font-size: 105%; } kernel-dtb build command to extract such a full tree. - this also avoids my 2nd concern which is modifying the existing orangepi-5.dtsi and disabling nodes which where later re-added with another patch. - if possible try to bump to latest mainline u-boot, so either v2025.04 or wait a bit longer for v2025.07 which is currently RC.

Personalized support: https://calendly.com/armbian/consultation

No need to manually adjust partitions. At first boot Armbian will expand rootfs automatically using all available space on sdcard. USBimager is known to work well on Win32 as well as Linux. Rufus is neither tested nor supported method.

https://forum.armbian.com/terms

Double-check what you are booting from and which image you use. The screenshot says kernel version 4.9.170 while the mentioned Armbian version is mainline with 6.12.y

Here are a few generic tips to consider: - Going to something industrial grade is always good. mean-well would be entry-level here - Phone chargers are not good for powering SBCs. They're designed to handle constant load while SBCs draw is variable depending on load. - Usually SBCs prefer slight overvoltage. So it is usually not an issue to feed them with an PSU that outputs 5.1 or 5.2 volts since this compensates for losses across wires, connectors and the PCB anyway. I personally have a mean well HRP-200-5 which powers all my sbcs but would be way too much for a single one. Official chargers from Raspberry or Orangepi would do too since they already come with slight overvoltage by design.

Cannot reproduce. Same board, same kernel: https://paste.armbian.com/difezakigu Try swapping PSU to another (better) one and check connectors and wiring. Undervoltage can cause all sorts of hard-to-explain trouble.

moved

Maybe this helps? https://forum.armbian.com/topic/29427-shrink-backup-a-tool-for-backing-up-sbcs/

Which you won't share since we all have second sights, right? Also code { font-family: Consolas,"courier new"; color: crimson; background-color: rgba(0, 0, 0, 0.2); padding: 2px; font-size: 105%; } armbianmonitor -u can be helpful. I have an Opi5 with nvme here and reboot works fine.

nope, just checked.

fwiw I was able to build a set of Armbian kernel packages based on 6.16-rc1 and this patchset: https://lore.kernel.org/all/20250619173007.3367034-1-wens@kernel.org/ If it works, no clue, don't have the hw. Just played around. https://github.com/armbian/build/pull/8330

Once we do the major bump to v5 we should focus on getting Github to work and - if reasonable - drop commercial proprietary logins like Facebook and so on. Less pain, more freedom

Providing logs with armbianmonitor -u helps with troubleshooting and significantly raises chances that issue gets addressed.

Okay, then you have to adjust the source to mitigate the issue. Also log excerpts are often useless. My random guess is that uboot is some old outdated version depending on python2 which has been deprecated years ago.

Ask where you got the source code from.

duplicate

https://debug.armbian.de