Werner

Ah. I guess nobody ported the overlays from old bsp over yet. Well also nobody was asking for them yet either lol Anyway this may work with "modern" bsp too: /dts-v1/; /plugin/; / { fragment@0 { target = <&spi3>; __overlay__ { status = "okay"; spidev@0 { compatible = "rockchip,spidev"; status = "okay"; reg = <0>; spi-max-frequency = <50000000>; }; }; }; };

How do you connect a NVMe to this board? Never mind. Wrong prefix. Anyway you need boot loader present on either spi, emmc or sd. Direct boot from nvme isnt possible.

No clue, sorry. I never actually used i2c

Hm vendor seem lacking all rk356x overlays except rk3566-roc-pc-sata2.dtbo. Need to check current. Edit: current and edge only have a few more but also none spi related for rk3566. Odd...

rockchip bsp kernel has recently been bumped to 6.1.99. Maybe things run smoother using it. You can use the build framework to create a set of kernel package to install via dpkg. Or use armbian-config to switch to beta repo which should also have it.

Can you provide me with the output of code { font-family: Consolas,"courier new"; color: crimson; background-color: rgba(0, 0, 0, 0.2); padding: 2px; font-size: 105%; } ls /boot/dtb/rockchip/overlay ?

Check /boot/armbianEnv.txt overlays=i2c1 i2c2 rockchip-rk3399-i2c7 Try this instead: overlays=i2c1 i2c2 rk3399-i2c7

Armbian is evolving rapidly, now supporting an ever-growing list of single-board computers (SBCs) - each with unique hardware, kernels, and configurations. As the variety of supported boards expands, so does the complexity of troubleshooting and providing effective user assistance. To keep up with this demand, we’re raising 5,000 EUR to hire part-time support agents who can help manage this increasing workload and ensure high-quality support for the community. Read more: https://forum.armbian.com/crowdfunding/project/16-help-armbian-grow-support-join-our-team/

moved

My guess is that there is no npu driver upstreamed yet. Try vendor kernel

moved

moved

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

If you run from sdcard, put it into an existing system and make necessary adjustments. Easiest would be to use another arm64 based computer since you can simply chroot into your sdcard and use armbian-config to switch back to stable.

moved to userspace

Try these: https://fi.mirror.armbian.de/.testing/Armbian-unofficial_25.02.0-trunk_Orangepizero_bookworm_legacy_6.1.104_minimal.img.xz https://fi.mirror.armbian.de/.testing/Armbian-unofficial_25.02.0-trunk_Orangepizero_bookworm_edge_6.12.9_minimal.img.xz

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

Not for mainline. HDMI implementation is incomplete and still WIP. If you need other resolutions vendor kernel is the way to go for now.

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

Did you check that the overlay has been added properly to /boot/armbianEnv.txt after using armbian-config? In some situations this fails for a reason still to be determined. Also make sure to apt update&upgrade beforehand since this tool gets patches frequently.

If this works from terminal but not from within armbian-config I suggest to report here: https://github.com/armbian/configng/issues

It is. We made the best possible support from it. Each new sdk version brings fixes but also regressions. Though you actially have to give credit to rockchip for their rk35xx sdk. We had way worse in the past, not necessarily from rk but others like aml or aw. In comparison its surprisingly good Anyway it will take another few years until it is close to feature-complete in mainline. I think rk3399 still hasn't all its features mainlined but overall it is well matured now. You always have to keep in mind that some smart person have to sit down and write drivers for sometimes poorly, sometimes not at all, documented features of a soc. Either being paid to do so or being an enthusiast where latter are very very rare people and their efforts are often strongly under-appreciated.

Yes there is some communication happening but this is out of scope for me. I do community Well thats unfortunate...and fortunate the same time. Let me explain real quick. rockchip socs have a built-in fixed boot order which is something like SPI, eMMC, microSD, USB and so on. However u-boot should be configured in a way, even though present on SPI or eMMC, it will check for an OS on microsd and try to boot that. tl;dr: Just write a fresh Armbian image on a microsd, put it into the ITX and power it on. It should boot from microsd. This system then can be used to fix your OS on the soldered eMMC.

moved wrong board. use orangepi5-pro if you want an image for orangepi5-pro. orangei5 will only boot on orangepi5.

Hi, first would be to set verbosity to 7 in order to get full boot logs. Excerpts are often useless. Further two things I'd do: For once I'd try to recover by chrooting into the system of the ITX by shoving the microsd into another arm64 machine (x86 can work too but it is far more annoying) and uninstall zfs package to see if this fixes the boot. If it is beyond recovery I'd try a fresh system from sd with a different userspace if the issue persists. Also just for the heck of it you could try this zfs package: https://github.com/zabbly/zfs I personnaly never tried this but it states to support arm64 so....just go for it Mainline is not an option for jellyfin, yes. It is far from being feature-complete while the rockchip sdk got most stuff working but, as correctly noticed, is fragile.