Jump to content

Search the Community

Showing results for tags 'orangepi5'.

  • Search By Tags

    Type tags separated by commas.

  • Search By Author

Content Type


Forums

  • Armbian
    • Armbian project administration
  • Community
    • Announcements
    • SBC News
    • Framework and userspace feature requests
    • Off-topic
  • Using Armbian
    • Beginners
    • Software, Applications, Userspace
    • Advanced users - Development
  • Standard support
    • Amlogic meson
    • Allwinner sunxi
    • Rockchip
    • Other families
  • Community maintained / Staging
    • TV boxes
    • Amlogic meson
    • Allwinner sunxi
    • Marvell mvebu
    • Rockchip
    • Other families
  • Support

Categories

  • Volunteering opportunities
  • Part time jobs

Categories

  • Official giveaways
  • Community giveaways
  • Raffles

Find results in...

Find results that contain...


Date Created

  • Start

    End

Last Updated

  • Start

    End

Filter by number of...

Joined

  • Start

    End

Group

Matrix

Mastodon

IRC

Website URL

XMPP/Jabber

Skype

Github

Discord

Location

Interests

Found 220 results

  1. SmoothCriminal75
    I recently bought a used OrangePi 5, when it arrived it had a working Ubuntu image on an SD card. I decided to format the card and put my own image of Armbian on the card using the Armbian imager. when installed the card would no longer boot. lights on board but black screen no HDMI output. I tried several different SD cards and different images all with the same result (A1 Sandisk cards) Eventually I tried a hail mary and put an Armbian image on a really old USB thumb stick and it immediately booted and worked just fine. I tried putting the OrangePi os on one of my SD cards for kicks and it gets HDMI output but is just stuck on the OrangePi splash screen When I insert the SD card while running on the USB thumb drive image I can view the partitions and see that the OS image is correctly installed on the SD. I can't figure out where I'm going wrong, am I having a bootloader compatability issue with armbian?
  2. SmoothCriminal75
    Has anyone successfully set up a MIPI screen with their LCD ribbon connectors on Armbian? Any wisdom from someone who has done this would be appreciated.
  3. Straconis
    I've been trying to configure the HDMI screen I purchased for the orange pi 5. It's listed to work with the raspberry pi so I figured it should work with the orange pi 5 as well. When I connect the screen, the screen just turns white. These instructions were included in the manual to configure the usage of the screen with the raspberry pi, but I am not familiar with how to translate the configuration into armbian. Write the image to the TF card, then modify the following configuration in config.txt: # uncomment to force a specific HDMI mode (this will force VGA) hdmi_group=2 hdmi_mode=87 hdmi_cvt 1024 600 60 6 0 0 0 # uncomment to force a HDMI mode rather than DVI. This can make audio work in # DMT (computer monitor) modes hdmi_drive=1 as I've been trying to troubleshoot I see that it does get information from the screen cat /sys/class/drm/card0-HDMI-A-1/status = connected cat /sys/class/drm/card0-HDMI-A-1/enabled = enabled cat /sys/class/drm/card0-HDMI-A-1/modes 1024x600 1024x600 640x480 640x480 640x480
  4. KhanhDTP
    What? Sharing various gaming experiences with RK3588 (Orange Pi 5) on Armbian. Why? Because RK3588 is a capable gaming chipset, Armbian is a good OS; Vulkan on RK3588 is getting better over time (PanVk) How? Posting your gaming results here (preferably with setup and screenshots/videos) so people can learn more.
  5. ScottN
    Hello all. Trying to get PCIe/NVMe working (even to show on microSD boot, let alone boot NVMe) on a custom compile on my Orange Pi 5 SBC version 1.3.2, because the official images aren't working either for me. No idea where to go from here and need some assistance as NVMe is required for my purpose. Here is what I did during compile.sh > Show kernel config > Board: orangepi5 > Kernel: current > Target: jammy > Image with desktop > Gnome desktop > Base configuration > Tick: Browsers > Device Drivers > PCI support > (default values) > Device Drivers > NVME Support > (default values) I used "SHARE_LOG=yes" but got below error at the end so I'm guessing it did not upload. I'm attaching it instead. SHARE_LOG=yes, uploading log [ uploading logs ] Log uploaded, share URL: [ <!DOCTYPE html> <html lang=en> <head> <meta charset=utf-8> <title>Error</title> </head> <body> <pre>Cannot POST /log</pre> </body> </html> ] Repeat build options Repeat Build Options [ ./compile.sh build BOARD=orangepi5 BRANCH=current BUILD_DESKTOP=yes BUILD_MINIMAL=no DESKTOP_APPGROUPS_SELECTED=browsers DESKTOP_ENVIRONMENT=gnome DESKTOP_ENVIRONMENT_CONFIG_NAME=config_base KERNEL_CONFIGURE=yes RELEASE=jammy SHARE_LOG=yes ] Side notes: I've tested with Joshua-Riek's ubuntu-rockchip builds here https://github.com/Joshua-Riek/ubuntu-rockchip/releases After writing the 22.04 version 3 to the microSD card, then boot to the microSD card on the SBC, doing lsblk lists the NVMe drive just fine. I use the tools this provides to copy the current configuration to the NVMe, update the bootloader, shutdown and only attempt to boot from NVMe and it does not work. So that is working a bit more than Armbian, but still not dedicated NVMe boot. I found this issue that talked about some Armbian changes to the DTS files for the arm64 boot on linux-rockchip, that seems to be the NVMe is not enabled? Here is that link: https://github.com/Joshua-Riek/ubuntu-rockchip/issues/709 One person was able to re-compile the DTS to DTB and manually update and dmesg output seems to work. This is where I'm lost as I've never compiled the device tree before. Assistance is greatly appreciated! Thanks! log-build-7d071dfd-1b54-45cf-8488-2bc8b5e62079.zip
  6. PajPaj
    Hi Ive just installed the latest version of Armbian (Ubuntu Noble+KDE) and everything works fine except it looks like it is not detecting my TV resolution correctly. I can choose 1920x1080@120hz but if I try yo go to 4K I can only select 24Hz I attach armbian monitor logs url, modetest and kscreendoctor My cable is HDMI 2.1 Any help would be appreciated modetest -c trying to open device '/dev/dri/card1'... is not a KMS device trying to open device '/dev/dri/card0'... done opened device `RockChip Soc DRM` on driver `rockchip` (version 1.0.0 at 0) Connectors: id encoder status name size (mm) modes encoders 83 82 connected HDMI-A-1 1880x1060 35 82 modes: index name refresh (Hz) hdisp hss hse htot vdisp vss vse vtot #0 4096x2160 24.00 4096 5116 5204 5500 2160 2168 2178 2250 297000 flags: phsync, pvsync; type: driver #1 4096x2160 23.98 4096 5116 5204 5500 2160 2168 2178 2250 296703 flags: phsync, pvsync; type: driver #2 3840x2160 30.00 3840 4016 4104 4400 2160 2168 2178 2250 297000 flags: phsync, pvsync; type: driver #3 3840x2160 29.97 3840 4016 4104 4400 2160 2168 2178 2250 296703 flags: phsync, pvsync; type: driver #4 3840x2160 25.00 3840 4896 4984 5280 2160 2168 2178 2250 297000 flags: phsync, pvsync; type: driver #5 3840x2160 24.00 3840 5116 5204 5500 2160 2168 2178 2250 297000 flags: phsync, pvsync; type: driver #6 3840x2160 23.98 3840 5116 5204 5500 2160 2168 2178 2250 296703 flags: phsync, pvsync; type: driver #7 1920x1080 120.00 1920 2008 2052 2200 1080 1084 1089 1125 297000 flags: phsync, pvsync; type: driver #8 1920x1080 119.88 1920 2008 2052 2200 1080 1084 1089 1125 296703 flags: phsync, pvsync; type: driver #9 1920x1080 100.00 1920 2448 2492 2640 1080 1084 1089 1125 297000 flags: phsync, pvsync; type: driver #10 1920x1080 60.00 1920 2008 2052 2200 1080 1084 1089 1125 148500 flags: phsync, pvsync; type: driver #11 1920x1080 59.94 1920 2008 2052 2200 1080 1084 1089 1125 148352 flags: phsync, pvsync; type: driver #12 1920x1080 50.00 1920 2448 2492 2640 1080 1084 1089 1125 148500 flags: phsync, pvsync; type: driver #13 1920x1080 30.00 1920 2008 2052 2200 1080 1084 1089 1125 74250 flags: phsync, pvsync; type: driver #14 1920x1080 29.97 1920 2008 2052 2200 1080 1084 1089 1125 74176 flags: phsync, pvsync; type: driver #15 1920x1080 24.00 1920 2558 2602 2750 1080 1084 1089 1125 74250 flags: phsync, pvsync; type: driver #16 1920x1080 23.98 1920 2558 2602 2750 1080 1084 1089 1125 74176 flags: phsync, pvsync; type: driver #17 1680x1050 59.88 1680 1728 1760 1840 1050 1053 1059 1080 119000 flags: phsync, nvsync; type: driver #18 1600x900 60.00 1600 1624 1704 1800 900 901 904 1000 108000 flags: phsync, pvsync; type: driver #19 1280x1024 60.02 1280 1328 1440 1688 1024 1025 1028 1066 108000 flags: phsync, pvsync; type: driver #20 1152x864 75.00 1152 1216 1344 1600 864 865 868 900 108000 flags: phsync, pvsync; type: driver #21 1280x720 60.00 1280 1390 1430 1650 720 725 730 750 74250 flags: phsync, pvsync; type: driver #22 1280x720 59.94 1280 1390 1430 1650 720 725 730 750 74176 flags: phsync, pvsync; type: driver #23 1280x720 50.00 1280 1720 1760 1980 720 725 730 750 74250 flags: phsync, pvsync; type: driver #24 1280x720 30.00 1280 3040 3080 3300 720 725 730 750 74250 flags: phsync, pvsync; type: driver #25 1280x720 29.97 1280 3040 3080 3300 720 725 730 750 74176 flags: phsync, pvsync; type: driver #26 1280x720 24.00 1280 3040 3080 3300 720 725 730 750 59400 flags: phsync, pvsync; type: driver #27 1280x720 23.98 1280 3040 3080 3300 720 725 730 750 59341 flags: phsync, pvsync; type: driver #28 1024x768 60.00 1024 1048 1184 1344 768 771 777 806 65000 flags: nhsync, nvsync; type: driver #29 800x600 60.32 800 840 968 1056 600 601 605 628 40000 flags: phsync, pvsync; type: driver #30 720x576 50.00 720 732 796 864 576 581 586 625 27000 flags: nhsync, nvsync; type: driver #31 720x480 60.00 720 736 798 858 480 489 495 525 27027 flags: nhsync, nvsync; type: driver #32 720x480 59.94 720 736 798 858 480 489 495 525 27000 flags: nhsync, nvsync; type: driver #33 640x480 60.00 640 656 752 800 480 490 492 525 25200 flags: nhsync, nvsync; type: driver #34 640x480 59.94 640 656 752 800 480 490 492 525 25175 flags: nhsync, nvsync; type: driver props: 1 EDID: flags: immutable blob blobs: value: 00ffffffffffff004dd9057901010101 011e010380bc6a780a0dc9a057479827 12484c2108008180a9c0714fb3000101 01010101010108e80030f2705a80b058 8a005a227400001e023a801871382d40 582c45005a227400001e000000fc0053 4f4e5920545620202a33300a000000fd 0017790e883c000a20202020202001bf 020367f05861605d5e5f621f10140513 0420223c3e1203110265663f402f0d7f 071507503d07bc570601670403830f00 006e030c004000b8442b008001020304 67d85dc401788003eb0146d000480382 88627697e200cbe305df01e40f030030 e6060d018aac10011d007251d01e206e 2855005a227400001e000000000000a3 2 DPMS: flags: enum enums: On=0 Standby=1 Suspend=2 Off=3 value: 0 5 link-status: flags: enum enums: Good=0 Bad=1 value: 0 6 non-desktop: flags: immutable range values: 0 1 value: 0 4 TILE: flags: immutable blob blobs: value: 84 max bpc: flags: range values: 8 8 value: 8 kscreen-doctor -o Output: 1 HDMI-A-1 ea40cb77-73bf-4175-8970-22f84927f147 enabled connected priority 1 HDMI replication source:0 Modes: 1:4096x2160@24.00*! 2:4096x2160@23.98 3:3840x2160@30.00 4:3840x2160@29.97 5:3840x2160@25.00 6:3840x2160@24.00 7:3840x2160@23.98 8:1920x1080@120.00 9:1920x1080@119.88 10:1920x1080@100.00 11:1920x1080@60.00 12:1920x1080@60.00 13:1920x1080@59.94 14:1920x1080@50.00 15:1920x1080@30.00 16:1920x1080@29.97 17:1920x1080@24.00 18:1920x1080@23.98 19:1680x1050@59.88 20:1600x900@60.00 21:1280x1024@60.02 22:1152x864@75.00 23:1280x720@60.00 24:1280x720@60.00 25:1280x720@59.94 26:1280x720@50.00 27:1280x720@30.00 28:1280x720@29.97 29:1280x720@24.00 30:1280x720@23.98 31:1024x768@60.00 32:800x600@60.32 33:720x576@50.00 34:720x576@50.00 35:720x480@60.00 36:720x480@60.00 37:720x480@59.94 38:720x480@59.94 39:640x480@60.00 40:640x480@59.94 Custom modes: None Geometry: 0,0 1821x960 Scale: 2.25 Rotation: 1 Overscan: 0 Vrr: incapable RgbRange: unknown HDR: incapable Wide Color Gamut: incapable ICC profile: none Color profile source: sRGB Color power preference: prefer efficiency and performance Brightness control: supported, set to 100% and dimming to 100% Color resolution: automatic (10), range: [8; 8] bits per color Allow EDR: unsupported Sharpness control: unsupported Automatic brightness: unsupported Thank you
  7. Rocksheep
    Hi. According to this patch Orange pi 5 Pro DTS (which BTW i use for my successful Orange Pi 5 Pro edge build) there will be a split of DTSI files. Most of the code in rk3588s-orangepi-5.dtsi will be transferred to new rk3588s-orangepi-5-5b.dtsi. In my current build for Orange Pi 5 and 5 Pro I have: rk3588s-orangepi-5-5b.dtsi rk3588s-orangepi-5b.dts rk3588s-orangepi-5.dts rk3588s-orangepi-5.dtsi rk3588s-orangepi-5-pro.dts. Please note I have Orange Pi 5 Pro with SPI chip soldered on so for Orange Pi 5 Pro build with EMMC (99.99% of cases) in rk3588s-orangepi-5-pro.dts set: /* SFC */ &sfc { status = "disabled"; }; and &sdhci { status = "okay"; }; rk3588s-orangepi-5-pro.dts rk3588s-orangepi-5b.dts rk3588s-orangepi-5-5b.dtsi rk3588s-orangepi-5.dtsi rk3588s-orangepi-5.dts
  8. Alec Leamas
    Has anyone found a working gpiolib implementation for Armbian on Orange Pi 5? I'm aware of wiringPi and it sort of works. However, being able to use the "real stuff" so to speak would make my life easier.
  9. Rocksheep
    Hello. For the past month, I have been working on fixing, updating, and rewriting the hardware crypto patch for RK3588. I've done so much work on it that I'm considering submitting it for review to be added to mainline kernel. I needed hardware cryptographic acceleration for a small project running on my Kubernetes ARM cluster. I noticed that Armbian is still using rk35xx-montjoie-crypto-v2-rk35xx.patch, so I decided to give it a try, but unfortunately the results were quite buggy. I took a closer look at rk35xx-montjoie-crypto-v2-rk35xx.patch and discovered a fairly large number of bugs and potential improvements. I then spent the past month rewriting and updating the original Montjoie code. I probably would have finished earlier, but I was determined to make Multi-Channel Scatter-Gather (Multi-SG) Linked List Items (LLI) in Direct Memory Access (DMA) work — and it now looks like that simply cannot be done. Bit of explanation: A cryptographic hash like SHA-256 takes a file of any size and boils it down to a fixed-length digest. Because files can be big, the math is done in chunks. The very last chunk of the file must be formatted in a specific way. It requires a special "padding" to be attached to the end, which includes a "1" bit, a bunch of "0" bits, and the exact total length of the original file. When a file is loaded into RAM, the kernel memory manager and DMA mapping layer may place its data across multiple non-contiguous memory regions instead of one large continuous block. When the CPU asks the Rockchip crypto hardware to hash this data, it provides a Scatter-Gather (SG) list — essentially a map that says: Read 4KB here, then read 8KB over there, then 2KB over here. The hardware reads the list and jumps around memory automatically. The Rockchip V2 hardware has a built-in feature to automatically add that cryptographic "padding" to the end of a message. However I suspect that the hardware has a design flaw in how it tracks its progress when jumping between scattered memory chunks. When the hardware reaches the boundary between one chunk and the next in a Multi-SG list, its internal byte/block counter loses track of the exact byte count across the gaps in memory. The result is a completely wrong digest. Because I couldn't figure out hardware internal math (and believe me I was trying hard for around 3 weeks trying everything I could under the sun), the only logical mainline fix was to check the Scatter-Gather list and if it's only one chunk send it to Rockchip hardware engine and if the map has more than one chunk (Multi-SG) it's intercepted bypassing the Rockchip hardware and sent to the CPU's standard software (fallback) crypto driver, which knows how to deal with it correctly. The (most likely) hardware bug is causing descriptor-chain state continuation failure and that could involve, for instance: byte counter resets, partial block FIFO resets, hash state reloads incorrectly, descriptor parser wrongly treats entries as independent jobs therfore HW_PAD cannot correctly track block boundaries across chained LLI descriptors. Moreover Rockchip documentation is a bit suspicious in that RK3588 TRM advertises “LLI DMA” and “HW padding”, but never explicitly mentions that hash operations may span multiple linked descriptors. Below is the list of fixes, updates and changes: 1. Documentation/devicetree/bindings/crypto/rockchip,rk3588-crypto.yaml Clock names corrected. Original had "a" and "h" as clock-names items. v3 corrects them to "core", "aclk", "hclk" matching the actual clock signal names in the hardware and passing make dt_binding_check. YAML example reg size fixed. Original example said 0x4000 (16KB). v3 corrects to 0x2000 (8KB) to match both DTS nodes and the actual hardware register map. 2. drivers/crypto/Makefile Root Makefile hook added. v3 adds obj-$(CONFIG_CRYPTO_DEV_ROCKCHIP2) += rockchip/ to the root crypto Makefile. Without this, if CONFIG_CRYPTO_DEV_ROCKCHIP (the V1 driver) is disabled, the build system never descends into drivers/crypto/rockchip/ and the V2 driver silently doesn't build regardless of Kconfig selection. 3. rk2_crypto.h dbgfs_info field added to struct rockchip_ip. Original was missing it, causing register_debugfs to overwrite dbgfs_stats with the info file pointer. v3 adds struct dentry *dbgfs_info as the third debugfs member. #include <linux/reset.h> added. Moved from rk2_crypto.c so that rk2_crypto_ahash.c and rk2_crypto_skcipher.c can call reset_control_assert/deassert directly in their DMA error recovery paths. fallback_req ordering documented. Added // keep at the end comment on struct skcipher_request fallback_req in rk2_cipher_rctx. Same ordering maintained in rk2_ahash_rctx with struct ahash_request fallback_req as last member — required for the flexible array __ctx placement to work correctly. 4. rk2_crypto.c pm_init return value fixed. Original returned err at the end, which after pm_runtime_enable would always be 0 but was misleading. v3 explicitly return 0. IRQ handler fires complete() only on LISTDONE or hard error. Original called complete() on any non-zero DMA_INT_ST. Intermediate SRC_INT per-LLI-entry interrupts would prematurely wake the hash path before all data was processed, producing wrong digests. v3 only signals completion for RK2_CRYPTO_DMA_INT_LISTDONE (BIT(0)) or error bits (0xF8). Consistent spin_lock_bh throughout. get_rk2_crypto(), probe, and remove all use spin_lock_bh/spin_unlock_bh. Original used plain spin_lock in get_rk2_crypto() and probe, risking deadlock if a crypto engine callback ran on the same CPU. Debugfs overwrite bug fixed. Original register_debugfs wrote to rocklist.dbgfs_stats twice — the second write (info file) overwrote the stats file pointer. v3 correctly uses rocklist.dbgfs_info for the second file. pm_runtime_resume_and_get return value checked in probe. Original ignored this return value. v3 checks it and jumps to err_pm on failure. PM reference count balanced on probe success. Original left usage count at 1 after successful registration, pinning the device ON forever. v3 calls pm_runtime_mark_last_busy + pm_runtime_put_autosuspend after successful registration. Separate err_register_alg label with list_del + pm_runtime_put_sync. Original jumped to err_pm on registration failure, which skipped both the list cleanup and the PM put. v3 has a dedicated label that removes the device from the list and decrements the PM count before falling through to rk2_crypto_pm_exit. crypto_engine_exit called before rk2_crypto_pm_exit in remove. Original order was reversed — clocks disabled before engine drained. v3 exits the engine first to flush all in-flight requests, then disables PM. algt->dev handoff on multi-device remove. When the registering device is removed while a second device survives, v3 iterates all algorithm templates and updates algt->dev to the surviving device, preventing use-after-free in tfm_init/tfm_exit logging. dma_free_coherent added to rk2_crypto_remove. The LLI table is a non-managed allocation. Original never freed it on normal remove, leaking it on every rmmod. v3 frees it at the end of remove. pm_resume does full assert/udelay/deassert cycle. Ensures hardware is cleanly initialised with clocks running on every PM wakeup, not just deassert. 5. rk2_crypto_ahash.c Multi-SG hardware fallback. Added if (sg_nents(areq->src) > 1) check at the top of rk2_ahash_need_fallback. The RK3568/3588 hardware padding engine (HW_PAD) loses block-count state across LLI descriptor boundaries, producing wrong digests for any multi-SG request. Single-SG requests continue to use hardware; multi-SG routes to software fallback and increments stat_fb_sgdiff. Explicit payload length for hardware padding. Added writel(areq->nbytes, rkc->reg + RK2_CRYPTO_CH0_PC_LEN_0) before starting DMA. The HW_PAD bit requires the total message length to be programmed in advance so the hardware knows where to apply the Merkle–Damgård padding. Without this, single-SG hardware hashes would also produce wrong results. INT_EN write-enable mask fixed. Original wrote RK2_CRYPTO_DMA_INT_LISTDONE | 0x7F with no upper bits, which is silently discarded by the HIWORD_UPDATE register pattern. v3 first clears stale pending interrupts (writel(0x7F, DMA_INT_ST)), then writes 0x007F007F so enable bits and their write-enable mask are both set. LIST_INT added to last LLI descriptor. LISTDONE (BIT(0)) is only set in DMA_INT_ST when the last LLI entry has RK2_LLI_DMA_CTRL_LIST_INT (BIT(8)) set in dma_ctrl. Without it, DMA completes silently, no interrupt fires, 2-second timeout every request. v3 adds RK2_LLI_DMA_CTRL_LIST_INT | RK2_LLI_DMA_CTRL_SRC_INT to the last descriptor. Uninterruptible completion wait. Changed from wait_for_completion_interruptible_timeout to wait_for_completion_timeout. The interruptible variant can return early on SIGTERM/SIGKILL while DMA is still writing to memory, causing data corruption or use-after-free. timeout return value captured and checked. Original discarded the return value, making timeout undetectable. v3 stores the return in unsigned long timeout and checks !timeout for ETIMEDOUT, then separately checks !rkc->status for EIO. rctx->nrsgs = 0 initialised before dma_map_sg. Ensures rk2_hash_unprepare never calls dma_unmap_sg on an uninitialised count. Safe dma_unmap_sg in unprepare. Added if (rctx->nrsgs) guard before dma_unmap_sg, preventing a kernel panic if dma_map_sg failed in the prepare step. MAX_LLI overflow check. Added if (ddi >= MAX_LLI) at the top of the LLI build loop with dev_err and -EINVAL. Prevents overflowing the DMA-coherent LLI table with a scatter-list longer than 20 entries. readl_poll_timeout_atomic return value checked. Original discarded the return, allowing wrong digest output if HASH_VALID never set. v3 assigns to err and jumps to theend on timeout. be32_to_cpu in digest readback. Hardware outputs all digest words (SHA1, SHA256, SHA384, SHA512, SM3, MD5) in big-endian register format. readl() on LE ARM64 gives a byte-swapped value; be32_to_cpu corrects it before put_unaligned_le32. pm_runtime_mark_last_busy before put_autosuspend. Refreshes the autosuspend timer on each request completion so the device doesn't suspend between back-to-back requests. DMA error hardware reset. On !rkc->status (DMA error interrupt), v3 performs reset_control_assert/udelay(10)/reset_control_deassert to recover the DMA engine from a stuck state before returning -EIO. crypto_ahash_set_statesize promotion in rk2_hash_init_tfm. After allocating the fallback, v3 queries its statesize and promotes the template's statesize if the fallback needs more space. Fixes -EOVERFLOW on export()/import() when ARM Crypto Extensions drivers (sha1-ce, sha256-ce) advertise a larger statesize than the raw hash state. 6. rk2_crypto_skcipher.c rk2_print gated with #ifdef CONFIG_CRYPTO_DEV_ROCKCHIP2_DEBUG. Register dumps on every DMA error flood production logs. v3 wraps the entire function and its callsite with the debug config guard. OTP KEY VALID bit corrected. Original checked BIT(2) for both HASH BUSY and OTP KEY VALID (copy-paste error). v3 uses BIT(3) for OTP KEY VALID. Multi-bit switch statements corrected. All field switches now use (v >> N) & mask before comparing case values, fixing cases that could never match after masking. dd->dma_ctrl = assignment not |=. The LLI table persists across requests. Using |= accumulates stale flag bits from previous requests. v3 uses = for the initial value. RK2_CRYPTO_DMA_CTL_START << 16 not literal 1 << 16. Ensures the write-enable mask is always correct regardless of the constant value. get_rk2_crypto() with null check for cipher. Original used algt->dev (always first device) for all cipher requests, bypassing load balancing. v3 uses get_rk2_crypto() matching the hash path, with if (!rkc) return -ENODEV. DMA unmap moved before timeout/error checks. Original goto theend on timeout bypassed dma_unmap_sg, permanently leaking the mapping. v3 unmaps unconditionally before checking results. wait_for_completion_timeout (uninterruptible). Same fix as hash — prevents signal interruption while DMA is active. Separate timeout/error errnos. ETIMEDOUT for timeout, EIO for DMA error with rk2_print debug dump. INT_EN write-enable mask + stale clear. Same fix as hash path: writel(0x7F, DMA_INT_ST) then writel(0x007F007F, DMA_INT_EN). LIST_INT added to cipher descriptor. RK2_LLI_DMA_CTRL_LIST_INT added to dd->dma_ctrl so LISTDONE fires in DMA_INT_ST. pm_runtime_mark_last_busy before put_autosuspend. DMA error hardware reset. Same reset_control_assert/deassert recovery as hash. Fallback log changed to dev_dbg. Original dev_info in rk2_cipher_tfm_init flooded logs during PM stress testing (hundreds of TFM allocations per second). v3 uses dev_dbg. Stricter XTS fallback check. Changed sg_nents(areq->src) > 1 to != 1 for the XTS-specific SG check. XTS requires exactly one contiguous buffer — more than one SG is wrong but so is zero. 7. include/dt-bindings/reset/rockchip,rk3588-cru.h Patch correctly uses mainline SCMI for RK3588. mainline Linux kernel Commit 849d9db form Feb 22, 2025 "dt-bindings: reset: Add SCMI reset IDs for RK3588" so there is no reason to modify this file as entries exist already. Please note the patch still removes the entire RK3588_SECURECRU_RESET_OFFSET macro and all its entries as keeping them in rst-rk3588.c alongside SCMI would be redundant and potentially dangerous. rk35xx-crypto-v3.patch
  10. mitu
    Hello, I have installed the Armbian 26.2 minimal IOT image based on Debian 13 Trixie - with the 6.18.x kernel - and I noticed the USB2 port (the single, vertical port next to the Ethernet port) is not working. Is this a limitation of the mainstream kernel (6.18.x) - i.e. does this work only with the vendor kernel (6.1.x) ? NB: I upgraded to 6.19 using the 'edge' kernel, but I'm seeing the same behavior. Here's the armbianmonitor outpur - https://paste.armbian.com/raw/udefojuxuk
  11. BOFFBOY
    Hi all, Testing this OP5, got a standard M2 NVMe SSD (this works on my OP5Plus) I have formatted to exFAT with windows, inserted on the OP5, loaded ArmbianOS on MicroSD, it boots fine but I cant get it to show the nvme drive using fdisk -l or lsblk It seem like its not detecting the m2 nvme ssd at all.. little help please ?
  12. XXXBold
    Hello everyone Just would like to start a discussion about the current state of video acceleration (decoding only, h.265/h.264/av1). The soc (rk3588) recently got mainline support for these features in 7.0: https://gitlab.collabora.com/hardware-enablement/rockchip-3588/notes-for-rockchip-3588/-/blob/main/mainline-status.md Has anyone tested this on a OPI5 already, especially using Kodi? Does this work ootb there now? Regards, XXXBold
  13. zjd
    I updated to Armbian 26.2.1 on OPi5, and it can't boot from MTD (rootfs at NVMe), and I have to use SD card to boot to NVMe as workaround. After looking into this issue, I found rkspi_loader.img is no longer available for current (6.18.8 kernel) u-boot pkg and armbian-config flashes u-boot-rockchip-spi.bin ( or similar sata version) to /dev/mtdblock0 and I think this is wrong image for MTD bootloader. If I use older vendor image, which u-boot pkg has rkspi_loader.img, system can boot to NVMe rootfs and I notice that /dev/mtdblock0 has several gpt partitions including u-boot one, and flashing u-boot-rockchip-spi.bin erases partitions in SPI flash. I noticed that several related changes were introduced since 25.11, such as https://github.com/armbian/build/commit/e5b845f9432abb0408287599bba5889a86e6d068 , but I couldn't do quick fix to bring back working rkspi_loader.img because I am not familiar with whole armbian build. One thing to note that if board was flashed with old rkspi_loader.img and not updated with 26.2 MTD image, it still boots to NVMe rootfs, but I have other issues such as video playback not working with 6.18 kernel likely due to mismatch u-boot and kernel version leading to wrong HW initialization. BTW, I checked 26.2 u-boot pkg for Rock 5B (similar rk3588 board), and rkspi_loader.img is still included.
  14. snow
    Greetings, I have an Orange Pi 5 with the edk2 1.1 UEFI bios on the SPI, and an NVMe installed. The BIOS has been set to "Mainline" in the device tree option I tried visiting here https://armbian.com/boards/uefi-arm64 and burning the minimal current6.18.8 CLI image to my USB stick. The Orange Pi 5 displays the graphical grub menu with no problems, complete with penguin in the background etc, but once I choose the boot Armbian option, it displays a few lines of terminal output and then the monitor goes black as if the GPU is initializing and a desktop or graphic would be about to show - when instead, the monitor just reports no signal instead. The system isn't frozen, the perhiperals are on and I can alt+ctrl+del to reboot it. It's just attached to a very basic 1080p ASUS monitor that only does 60hz so I'm not sure what could be wrong Thanks for any advice
  15. smurfx
    Hi everyone, I just installed Armbian on my OrangePi 5, but I can't get it to recognize the NVMe drive. I've tried the official OrangePi Ubuntu distro, and it detects the NVMe without any issues. However, when using Armbian, it simply doesn't show up. I'm not sure what to do at this point. I would really like to use Armbian, but it seems unable to detect the NVMe on this particular device. Interestingly, I have another OrangePi 5 Pro where I installed Armbian, and it recognizes the NVMe and works perfectly fine — but not on the standard OrangePi 5. Does anyone know how to fix this issue, or can you recommend a good alternative? Thank you in advance.
  16. Gullik
    Since I am interested in the connection ability, I figured the info we gather should go into ONE thread. I have tried to build new kernels, but can only see USB controllers and devices two ports. I have seen a lot of work by Sebasitian Reichel @ Collabora, and his patches, but these do not seem to have the desired result on my test board. Orange PI 5. There seems to be an issue with the port mux, FUSB302, that either connects the last USB to the "vertical" port or to the "USB C" connector. I will comment my findings and attempts to correct this in this thread, and think we could find out where we are if you add your findings, successes and failures, rather than cluttering everywhere Regards, Gullik
  17. mitu
    Hello, I have installed the minimal Trixie based image for Orange Pi5 (the image named Armbian_26.2.1_Orangepi5_trixie_current_6.18.8_minimal) and then attempted to build an out-of-tree kernel module. Having installed dkms and build-essentials, plus the kernel headers through armbian-config, I found the headers package hasn't been fully set-up, the build symlink in /lib/modules/<KVER> is missing and dkms complains that the kernel headers for the kernel are not installed. The kernel headers are installed though, but it looks like they're from a previous release (25.11.2 instead of 26.2.1). # dpkg -l | grep rockchip ii linux-dtb-current-rockchip64 26.2.1 arm64 Armbian Linux current DTBs in /boot/dtb-6.18.8-current-rockchip64 ii linux-headers-current-rockchip64 25.11.2 arm64 Armbian Linux current headers 6.12.58-current-rockchip64 ii linux-image-current-rockchip64 26.2.1 arm64 Armbian Linux current kernel image 6.18.8-current-rockchip64 It the headers package still pending packaging ? Shouldn't armbian-config provide an error in this case and not install the old kernel headers ? EDIT: armbianmonitor ouput - https://paste.armbian.com/oliyalebeq
  18. jondowd
    My first post here - I'm new to SBCs and stoked I got my home webserver up and running on a Orange Pi 5 which boots from an NVMe (pats-self-on-back : -) It runs great, pages are up, and it's all SO COOL, but it fails to do a restart... I can do a shutdown -h now, count to three and power it back up and all is well, but if I do a shutdown -r now it will go down, start back up, all the way to the login prompt but then barfs a long Oops message. God please... don't make me start over !
  19. aosos
    I tried installing the OS using SD card and EMMC, but both failed. Orange Pi OS (Arch) on the official website ran normally. However, I installed focal_desktop_xfce or jammy_desktop_gnome from Ubuntu Image, but they all failed. After inserting the image into the SD card, the symptom is a black screen and no booting. Does it only support SSD? Because it is entered through a translator, there may be unnatural sentences. If you reply about that, I will get back to you.
  20. jng98908
    I originally posted this on reddit after seeing a lot of posts trying to use a SATA M.2 SSD and saying it wouldn't boot with replies telling them to go buy a NVME M.2 SSD which isn't necessary when the board does support SATA M.2 with flashing the correct bootloader. This guide has 3 different sections, 1 being booting with Orange pi OS and 2 being with Armbian OS Orange Pi OS Instructions Download Orange Pi OS Ubuntu or Debian from their website http://www.orangepi.org/html/hardWare/computerAndMicrocontrollers/service-and-support/Orange-pi-5.html unzip the 7z file to get the .img file and flash it to your sd card with your preferred flasher i.e balenaetcher. Once flashed put it into orange pi 5 and boot from sd card first once booted, the rest will be done in a terminal. go ahead and do your usual update sudo apt update sudo apt upgrade -y 3. then make sure to wipe your SPI of any previous bootloader (give it time to complete, you'll know it's done when you get your cursor back in terminal) sudo dd if=/dev/zero of=/dev/mtdblock0 bs=1M count=1 4. Write sata bootloader to SPI sudo dd if=/usr/share/orangepi5/rkspi_loader_sata.img of=/dev/mtdblock0 && sudo sync 5. Edit boot file on sd card to recognize sata by adding overlays line to the bottom, save then reboot sudo nano /boot/orangepiEnv.txt overlays=ssd-sata sudo reboot 6. On reboot you will still boot into SD card but now you should see "sda" (your sata SSD) show up on your list of devices when typing: lsblk 7. Put the same Orange Pi OS image you used in step 1 in any directory on your orange pi making sure it is unzipped and is in .img format. I just used the web browser in orange pi os to redownload from the website which for me put it in directory /home/orangepi/Downloads 8. Flash your downloaded .img to your sata ssd with this command (substitute with your directory to .img) sudo dd bs=1M if=/path/your/orangepi.img of=/dev/sda status=progress && sudo sync 9. Mount your ssd so you can edit the ssd’s boot file to support sata and reboot sudo mount /dev/sda1 /mnt/ sudo nano /mnt/boot/orangepiEnv.txt overlays=ssd-sata sudo umount /mnt/ && sudo sync sudo poweroff 10. Remove SDcard, turn on orange pi and it should boot orange pi OS from your M.2 sata ssd now Armbian OS Instructions Relatively same instructions with different file names write armbian .img file to your sd card with balenaetcher, I chose to use the more up to date imags from their github here https://github.com/armbian/build/releases/ make sure to unzip boot armbian from sd card, wipe spi sudo dd if=/dev/zero of=/dev/mtdblock0 bs=1M count=1 3 Download sata spi bootloader from orange github, place it on your sd card (mine is in downloads directory) and write to spi https://github.com/orangepi-xunlong/orangepi-build/blob/next/external/packages/bsp/rk3588/usr/share/orangepi5/rkspi_loader_sata.img sudo dd if=/home/pi/Downloads/rkspi_loader_sata.img of=/dev/mtdblock0 status=progress && sudo sync 4. Edit boot file to recognize sata then reboot sudo nano /boot/armbianEnv.txt overlays=opi5-sata sudo reboot 5. Once rebooted you can check sda shows up with command: lsblk 6. download the same armbian.img you used for step 1 to your orange pi making sure it's unzipped in .img format, then flash it to your ssd sudo dd bs=1M if=/path/your/armbian.img of=/dev/sda status=progress && sudo sync 7. Mount /boot/ of ssd so you can edit the ssd’s boot file to support sata and reboot sudo mount /dev/sda1 /mnt/ sudo nano /mnt/boot/armbianEnv.txt overlays=opi5-sata sudo umount /mnt/ && sudo sync sudo poweroff 8. Remove SDcard and start SBC, resize filesystem to use all available space sudo systemctl enable armbian-resize-filesystem
  21. Matt W.
    System Information Distribution: Debian (armbian) Kernel Version: 6.1.115-vendor-rk35xx OpenZFS Version: 2.3.5 The kernel module does load. # zfs -V zfs-2.3.5-2~bpo13+1 zfs-kmod-2.3.5-2~bpo13+1 # zfs version Failed to initialize the libzfs library. Note: To keep this post short, I only pasted the errors from the trace below. # strace zfs version prctl(PR_CAPBSET_READ, 0x30 /* CAP_??? */) = -1 EINVAL (Invalid argument) prctl(PR_CAPBSET_READ, CAP_CHECKPOINT_RESTORE) = 1 prctl(PR_CAPBSET_READ, 0x2c /* CAP_??? */) = -1 EINVAL (Invalid argument) prctl(PR_CAPBSET_READ, 0x2a /* CAP_??? */) = -1 EINVAL (Invalid argument) prctl(PR_CAPBSET_READ, 0x29 /* CAP_??? */) = -1 EINVAL (Invalid argument) openat(AT_FDCWD, "/dev/zfs", O_RDWR|O_EXCL|O_CLOEXEC) = -1 ENODEV (No such device) openat(AT_FDCWD, "/usr/share/locale/en_US.UTF-8/LC_MESSAGES/zfs-linux-user.mo", O_RDONLY) = -1 ENOENT (No such file or directory) openat(AT_FDCWD, "/usr/share/locale/en_US.utf8/LC_MESSAGES/zfs-linux-user.mo", O_RDONLY) = -1 ENOENT (No such file or directory) openat(AT_FDCWD, "/usr/share/locale/en_US/LC_MESSAGES/zfs-linux-user.mo", O_RDONLY) = -1 ENOENT (No such file or directory) openat(AT_FDCWD, "/usr/share/locale/en.UTF-8/LC_MESSAGES/zfs-linux-user.mo", O_RDONLY) = -1 ENOENT (No such file or directory) openat(AT_FDCWD, "/usr/share/locale/en.utf8/LC_MESSAGES/zfs-linux-user.mo", O_RDONLY) = -1 ENOENT (No such file or directory) openat(AT_FDCWD, "/usr/share/locale/en/LC_MESSAGES/zfs-linux-user.mo", O_RDONLY) = -1 ENOENT (No such file or directory) write(2, "Failed to initialize the libzfs "..., 41Failed to initialize the libzfs library. ) = 41 exit_group(1) = ? +++ exited with 1 +++ The /dev/zfs file does exist # ll /dev/zfs crw-rw-rw- 1 root root 10, 249 Jan 9 16:48 /dev/zfs In addition the trace also contains the following, confirming the existence of the file faccessat(AT_FDCWD, "/dev/zfs", F_OK) = 0 zpool also has the same issue.
  22. pazzoide
    Hello, I installed lm-sensors on my Opi5 and I'm able to check temperatures, however I don't know how to make the little fan spin when the temperature rise. I know the temperature is not going to rise till critical levels, but I live in very hot country and I just don't want my device to become too hot. And do you know how to make the fan start at certain temperature rise? Also I'm not sure which pins I should connect the fan to.. One pin should be the 3.3V to get the power, what about the other one? I'm running Armbian 23.02.2 with kernel 5.10.110-rockchip-rk3588 Thanks in advance
  23. Last Man
    Hi Guys, It seems that I can't boot latest Armbian image from SD-card - system always boots into "inintramfs". See the screenshot. SD-card is 100% working (all sectors tested). The image - 25.11.1_noble_6.12.58_gnome_desktop (downloaded from front page of OrangePi5). Checksum is OK. Please note - I've already tested 3 different prorgams for images: USB-imager, Rufus, Win32diskimager. Nothing helped))). I also re-wrote MTD flash (not sata) by "armbian-install" and got nothing (!) I use my main Armbian-server installed on nvme, but I would prefer to run SD-images as well... Unfortunately, as I see, this became very difficult task lately(((. P.S. I don't want to erase mtd0 and boot from SD as I will probably lose my perfectly working boot from nvme if SD-boot fails again. Not sure what to do... Any ideas? Thanks.
  24. Renoria
    Hi guys, First post here, I successfully managed to flash and boot Armbian 25.8.2 (Bookworm Minimal) from an SD card. Everything was working great, HDMI output and network included. I then ran “sudo armbian-install” and selected Option 4 to move the system to my NVMe SSD and make it boot from there. The process itself completed without errors. However, after shutting down and removing the SD card and powering on again the system doesn’t boot. I have the red LED turned on however the green LED that was previously flickering doesn’t turn on. There’s also no HDMI output and the board doesn’t connect to the network. I tried inserting the SD card and the system does boot from that just fine. Where did I screw up? Appreciate the help!
  25. XFer012
    Hello, my Orange Pi 5 works well with the stock OS (1.22, Ubuntu Jammy, BSP kernel 6.1.99), using the SD as a boot device. It also works ok with Armbian Minimal-IoT / Debian 13 / 6.1: v25.8.2 for Orange Pi 5 running Armbian Linux 6.1.115-vendor-rk35xx But I prefer Ubuntu and wanted to try 6.12, so I downloaded 25.8.2 / Ubuntu Server / 6.12. Wrote to SD, hooked up the debug UART and powered on. The bootloader is fine, the kernel starts, but at a certain point it panics: [ OK ] Reached target sockets.target - Socket Units. Starting armbian-hardware-monitor.…ce - Armbian hardware monitoring... Starting armbian-hardware-optimize… - Armbian hardware optimization... Starting armbian-led-state.service - Armbian leds state... Starting armbian-resize-filesystem…vice - Armbian filesystem resize... armbian-hardware-monitor.service [ OK ] Finished armbian-hardware-monitor.…vice - Armbian hardware monitoring. [ OK ] Finished armbian-led-state.service - Armbian leds state. armbian-led-state.service [ OK ] Finished armbian-hardware-optimize…ce - Armbian hardware optimization. armbian-hardware-optimize.service [ OK ] Finished console-setup.service - Set console font and keymap. console-setup.service sys-kernel-debug-tracing.mount [ 158.363359] rockchip-pm-domain fd8d8000.power-management:power-controller: failed to get ack on domain 'gpu', val=0xa9fff [ 158.364324] SError Interrupt on CPU7, code 0x00000000be000411 -- SError [ 158.364327] CPU: 7 UID: 0 PID: 462 Comm: (udev-worker) Tainted: G M C 6.12.49-current-rockchip64 #1 [ 158.364332] Tainted: [M]=MACHINE_CHECK, [C]=CRAP [ 158.364333] Hardware name: Xunlong Orange Pi 5 (DT) [ 158.364334] pstate: 404000c9 (nZcv daIF +PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 158.364336] pc : _raw_spin_lock_irqsave+0x38/0x8c [ 158.364342] lr : regmap_lock_spinlock+0x18/0x2c [ 158.364347] sp : ffff800083f03660 [ 158.364348] x29: ffff800083f03660 x28: 0000000000000000 x27: ffff800083f03c60 [ 158.364351] x26: 0000000000000000 x25: ffff710bf0c4c080 x24: ffff710bf0f64098 [ 158.364354] x23: 0000000000000000 x22: 0000000000000001 x21: 0000000000000000 [ 158.364356] x20: 000000000000000c x19: 0000000000000000 x18: ffffffffffffffff [ 158.364358] x17: 66203a72656c6c6f x16: 72746e6f632d7265 x15: 776f703a746e656d [ 158.364361] x14: 6567616e616d2d72 x13: 00000000000002ac x12: 00000000ffffffea [ 158.364363] x11: 0000000000000001 x10: 0000000000000001 x9 : ffffc80dcfdf9250 [ 158.364365] x8 : 000000000002ffe8 x7 : c0000000ffffdfff x6 : 00000000000affa8 [ 158.364368] x5 : ffffc80dce6c1b54 x4 : 0000000000000008 x3 : ffffc80dce6c15c8 [ 158.364370] x2 : 0000000000000001 x1 : 0000000000000000 x0 : ffff710bf0f65c00 [ 158.364373] Kernel panic - not syncing: Asynchronous SError Interrupt [ 158.364374] CPU: 7 UID: 0 PID: 462 Comm: (udev-worker) Tainted: G M C 6.12.49-current-rockchip64 #1 [ 158.364377] Tainted: [M]=MACHINE_CHECK, [C]=CRAP [ 158.364378] Hardware name: Xunlong Orange Pi 5 (DT) [ 158.364379] Call trace: [ 158.364380] dump_backtrace+0x94/0x114 [ 158.364383] show_stack+0x18/0x24 [ 158.364385] dump_stack_lvl+0x38/0x90 [ 158.364387] dump_stack+0x18/0x24 [ 158.364389] panic+0x39c/0x3f4 [ 158.364392] nmi_panic+0x40/0x8c [ 158.364394] arm64_serror_panic+0x70/0x80 [ 158.364396] do_serror+0x3c/0x78 [ 158.364398] el1h_64_error_handler+0x30/0x48 [ 158.364401] el1h_64_error+0x64/0x68 [ 158.364402] _raw_spin_lock_irqsave+0x38/0x8c [ 158.364404] regmap_lock_spinlock+0x18/0x2c [ 158.364407] regmap_write+0x3c/0x78 [ 158.364409] rockchip_pd_power+0xf8/0x5e8 [ 158.364414] rockchip_pd_power_on+0x14/0x20 [ 158.364417] _genpd_power_on+0x94/0x188 [ 158.364418] genpd_power_on.part.0+0xa4/0x1ac [ 158.364421] __genpd_dev_pm_attach+0x144/0x2dc [ 158.364423] genpd_dev_pm_attach+0x60/0x70 [ 158.364425] dev_pm_domain_attach+0x20/0x34 [ 158.364429] platform_probe+0x50/0xdc [ 158.364431] really_probe+0xc0/0x38c [ 158.364434] __driver_probe_device+0x7c/0x15c [ 158.364437] driver_probe_device+0x40/0x114 [ 158.364440] __driver_attach+0xf4/0x1fc [ 158.364443] bus_for_each_dev+0x74/0xd4 [ 158.364445] driver_attach+0x24/0x30 [ 158.364448] bus_add_driver+0x110/0x234 [ 158.364451] driver_register+0x60/0x128 [ 158.364453] __platform_driver_register+0x24/0x30 [ 158.364455] panthor_init+0x64/0x1000 [panthor] [ 158.364467] do_one_initcall+0x44/0x2a8 [ 158.364470] do_init_module+0x58/0x20c [ 158.364472] load_module+0x1e4c/0x1f3c [ 158.364474] init_module_from_file+0x84/0xc4 [ 158.364476] __arm64_sys_finit_module+0x1f4/0x2f0 [ 158.364478] invoke_syscall+0x48/0x110 [ 158.364481] el0_svc_common.constprop.0+0xc8/0xe8 [ 158.364484] do_el0_svc+0x20/0x2c [ 158.364487] el0_svc+0x30/0xfc [ 158.364488] el0t_64_sync_handler+0x13c/0x158 [ 158.364491] el0t_64_sync+0x190/0x194 [ 158.364492] SMP: stopping secondary CPUs [ 158.364557] Kernel Offset: 0x480d4dc00000 from 0xffff800080000000 [ 158.364558] PHYS_OFFSET: 0xffff8ef600000000 [ 158.364559] CPU features: 0x1c,00000017,00280928,4200720b [ 158.364561] Memory Limit: none [ 158.393407] ---[ end Kernel panic - not syncing: Asynchronous SError Interrupt ]--- Power brick is a solid 5V/4A and as I said works OK with the stock OS (7zip benchmark and all) and Armbian Minimal Any suggestion? Thanks a lot Fernando
×
×
  • Create New...

Important Information

Terms of Use - Privacy Policy - Guidelines

  I accept