All Activity

You can find patches for A523/A527 here. Just need to port them over to Armbian. https://github.com/warpme/minimyth2/tree/master/script/bootloaders/board-t527.orangepi_4a/files https://github.com/warpme/minimyth2/tree/master/script/kernel/linux-6.12/files https://github.com/warpme/minimyth2/blob/master/script/kernel/linux-6.12/files/1172-arm64-dts-allwinner-t527-add-orangepi-4a-dts.patch

It's definitely not a power issue in my case. I'm using a Penta Hat with my 4A and it has its own barrel jack and 12V/5A power supply that powers both the board and the drives. In any case, I let my system boot from the original configuration and took a picture of the messages before all of the BOOTP messages ran them off of the screen. I saw that it was failing to load a bunch of files, so I booted off of the SD again, this time using a version of Armbian with the 6.6.63 kernel. I saw then that several of the symbolic links the boot process needs were broken, so I fixed them, copying over files as needed (the kernel itself, specifically). Now I'm back in action, exactly as I was before the kernel update. I've left the current version pinned in armbian-configure and will wait for a version using a 6.13 series kernel before updating again.

I ran into the same problem today w/ Bookworm 😕

Had a very same issue just recently. Guess there is no check in armbian-config whether package was downloaded before removing an old one and in case of multiple packages this is done one by one package rather than downloading all required before processing further. Failure to download might relate to mirror availability - seems that every new download might be from a different mirror- in my case dtbs were installed, but kernel only removed. Ad-hoc solution- keep bootable usb or sd to chroot and fix.

I don't have backups, but anything of any importance should be on the SSDs connected via NVMe (a copy of which is also on an external drive in case of an emergency), so if I have to rebuild what's on the eMMC, that won't be the end of the world. I will start taking backups though, to make this whole recovery process easier in the future. I think that I should have been able to do this with armbian-config, but it wasn't working properly. I have a theory that this was because I "pinned" the current kernel before attempting to rollback to an older one, but I can't test my theory anymore because something that I did has rendered my system unbootable, even with the SSD drives disconnected. This is what I am going to attempt to do. I have successfully booted a much older image from an SD card, and I have been able to mount the eMMC, so if I can figure out what I need to replace in order to get the system to boot again on its own, I'll do that. If that's unsuccessful, I will just reinstall to the eMMC and add back the applications that I was using. I get that this is what bootstraps the board, but that is the entire extent of my knowledge of it. I'd like to better understand the boot process, but I haven't been able to find any basic explanation of it. To complicate matters, my 4A has an onboard SPI, which I believe can also contain the bootstrap code, but I have no idea if that would be a better way to go or not. Thanks for your comments!

From what I'm seeing with the latest rk35xx vendor kernel, SATA is mostly broken once again (the SATA controller PCIe device is not detected and thus no drives attached to it). It seems to be a timing issue as occasionally they have showed up though. Also, zfs-dkms results in an actually broken system when used with this kernel; kernel oops on boot. I of course don't blame Armbian for this, but the rk35xx vendor kernel branch seems to be a hot mess. Too bad it's effectively required to use the VPU...

I switched armbian repo to stable via armbian-config 24.11.2. The first thing it did, judging by /var/log/apt/history.log, was purging linux-image*: Start-Date: 2025-01-04 22:47:25 Commandline: apt-get -o APT::Status-Fd=4 -o APT::Keep-Fds::=5 -o APT::Keep-Fds::=6 -y purge linux-image* Requested-By: user (1000) Purge: linux-image-current-sunxi64:arm64 (24.11.1) End-Date: 2025-01-04 22:47:27 Then it proceeded to purge and reinstall dtb and armbian-firmware, but not linux-image: Start-Date: 2025-01-04 22:48:34 Commandline: apt-get -o APT::Status-Fd=4 -o APT::Keep-Fds::=5 -o APT::Keep-Fds::=6 -y purge linux-dtb* Requested-By: user (1000) Purge: linux-dtb-current-sunxi64:arm64 (24.11.1) End-Date: 2025-01-04 22:48:35 Start-Date: 2025-01-04 22:48:54 Commandline: apt-get -o APT::Status-Fd=4 -o APT::Keep-Fds::=5 -o APT::Keep-Fds::=6 --allow-downgrades -y install linux-dtb-current-sunxi64 Requested-By: user (1000) Install: linux-dtb-current-sunxi64:arm64 (24.11.1) End-Date: 2025-01-04 22:48:55 Start-Date: 2025-01-04 22:49:18 Commandline: apt-get -o APT::Status-Fd=4 -o APT::Keep-Fds::=5 -o APT::Keep-Fds::=6 -y purge armbian-firmware* Requested-By: user (1000) Purge: armbian-firmware:arm64 (24.11.2) End-Date: 2025-01-04 22:49:19 Start-Date: 2025-01-04 22:49:47 Commandline: apt-get -o APT::Status-Fd=4 -o APT::Keep-Fds::=5 -o APT::Keep-Fds::=6 --allow-downgrades -y install armbian-firmware Requested-By: user (1000) Install: armbian-firmware:arm64 (24.11.2) End-Date: 2025-01-04 22:50:01 I don't know if this is an error in the script, or in package dependencies, but getting an unbootable system was very unpleasant

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.

@Werner Thanks for the attention and advice. I've read plenty of your posts in the past and your contributions are really appreciated! Does Armbian have a support path back upstream to Radxa for their vendor kernel? It always takes at least two parties to have an incompatibility so I'm not sure where the ultimate fault lies between ZFS and RK35xx here, but perhaps Radxa could help some here. I know this is the community supported Rockchip forum, but the Rock 5 ITX board is actually in the platinum support category (my fault for misfiling this but I assume it effects all rk35xx boards) which I assume means there's some linkage back to the vendor (but maybe I misunderstand what platinum support really means). In this case, I'm booting and running my root filesystem off of emmc which is soldered onto the board. I'm flashing Armbian to it over USB using rkdeveloptool via maskrom - which means I can't pull the storage and read it on another system unfortunately. I guess I could reinstall to an SD card (or move my root FS to removable storage for a future install) but I'm not there right now. @Turbodid If you have any luck or even just a different experience with this or other approaches, please make sure to update this thread.

Hi I'm trying to enable GPU on my custom kernel. I have applied a patch from Nick's repository, But when I allow `gpu` node in the Transpeed device tree, the kernel freezes here: [ 9.931994] sun50i-h616-codec 5096000.codec: Failed to register against DMAEngine [ 9.933237] sun8i-ce 1904000.crypto: will run requests pump with realtime priority [ 9.947692] sun8i-ce 1904000.crypto: will run requests pump with realtime priority [ 9.955742] sun8i-ce 1904000.crypto: will run requests pump with realtime priority [ 9.964193] sun8i-ce 1904000.crypto: will run requests pump with realtime priority [ 9.972000] sun8i-ce 1904000.crypto: Register cbc(aes) [ 9.977448] sun8i-ce 1904000.crypto: Register ecb(aes) [ 9.982650] sun8i-ce 1904000.crypto: Register cbc(des3_ede) [ 9.988522] sun8i-ce 1904000.crypto: Register ecb(des3_ede) [ 9.994324] sun8i-ce 1904000.crypto: CryptoEngine Die ID 0 [ 10.054128] sun8i-mixer 1100000.mixer: Adding to iommu group 0 [ 10.150367] ahub_dam-snd-soc-dummy-dai: substream ahub_dam-snd-soc-dummy-dai has no playback, no capture [ 10.160265] sunxi-snd-mach soc:ahub_dam_mach: ASoC: can't create pcm ahub_dam-snd-soc-dummy-dai :-22 [ 10.176581] sunxi-snd-mach soc:ahub_dam_mach: probe with driver sunxi-snd-mach failed with error -22 [ 10.355412] videodev: Linux video capture interface: v2.00 [ OK ] Reached target sound.target - Sound Card. [ 10.394078] Registered IR keymap rc-empty [ 10.398320] rc rc0: sunxi-ir as /devices/platform/soc/7040000.ir/rc/rc0 [ 10.405141] input: sunxi-ir as /devices/platform/soc/7040000.ir/rc/rc0/input4 [ 10.413088] sunxi-ir 7040000.ir: initialized sunXi IR driver [ 10.475252] panfrost 1800000.gpu: clock rate = 432000000 [ 10.480726] panfrost 1800000.gpu: bus_clock rate = 200000000 When I disable the `gpu` node. The Xserver comes up. However, the videos are playing slowly and the CPU usage is 100%. Any idea what could be the problem?

In dts RK809 node for that device needed configuration for SD card 3v3 regulator and 1v8 regulator - than theoretically SD card will work fine.

Ty. I picked up a cheap sda1115 ADC which uses I2C. Will i2c on the Rock-S0 need an overlay or is it already enabled by default in armbian. Haven't figured out how to test for that yet. NM - it "just works", I didn't have to change anything or add an overlay! 🙂

Install KODI to Gnome (wayland)

Thank you for quick reply. Haven't even thought it's not supported. PS: I wanted to thank the developers for such build / config tool! It worked like a charm as I decided to upgrade from Ubuntu xenial.

If your board in unstable, it hangs, kernel panics with Unable to handle kernel paging request at virtual address ffff7fffbef91008 Or MicroSD read errors, and you use Wi-Fi, Put Wi-Fi antenna outside of the board! Apparently EMI from the Wi-Fi module is so high it influence RAM and/or MicroSD if the antenna is in closest proximity. I've tested it on tens of Zero 3's, and could reliably reproduce the issue.

With U-Boot in SPI: U-Boot SPL 2024.10-armbian-2024.10-Sf919-Pe8a7-H29de-Vf307-Bb703-R448a (Jan 06 2025 - 02:00:45 +0000): - I can confirm that there is no NVMe when kernel 6.12.9-current-rockchip64 (I did take out a Samsung 970 EVO 500G from another computer temporarily) - it works with 6.12.6-edge-rockchip64, 6.6.67-current-rockchip64, 6.13.0-rc5-edge-rockchip64 Another issue is that when overlay rock-3a-sata.dtbo is used, the SATA HDD is available, but the NVMe is not there then. It looks like mixing up of PCIe entities (in general), that is my guess.

Reading the A20 SoC documentation? tl;dr; That is not possible on this hardware as boot from NAND is not supported on modern U-boot / Linux.

If your board in unstable, it hangs, kernel panics with Unable to handle kernel paging request at virtual address ffff7fffbef91008 Or MicroSD read errors, and you use Wi-Fi, Put Wi-Fi antenna outside of the board! Apparently EMI from the Wi-Fi module is so high it influence RAM and/or MicroSD if the antenna is in closest proximity. I've tested it on tens of Zero 3's, and could reliably reproduce the issue.

Hello! After installing Debian stable (bookworm) v25.2 on my Cubietruck from SD card to SSD using armbian-install and then moving boot to SSD using armbian-config: Install/Update the bootloader on (/dev/sda/) i'm trying to boot with SD card removed and ending up in this strange android GUI. My /etc/fstab is looking like this: # <file system> <mount point> <type> <options> <dump> <pass> tmpfs /tmp tmpfs defaults,nosuid 0 0 UUID=723a49f7-ffc6-4d66-8198-07d4ac71688f /media/mmcboot ext4 defaults,noatime,commit=120,errors=remount-ro,x-gvfs-hide 0 1 /media/mmcboot/boot /boot none bind 0 0 UUID=7e00bf90-f9ea-4755-95f7-96d37a2d9642 / ext4 defaults,noatime,commit=120,errors=remount-ro,x-gvfs-hide 0 1 I would like to boot from internal SSD without having SD card inserted. What am I missing?

I’m hoping someone might be able to help. I have been using an Odroid N2 with a 32Gb SD card for some years with Open Media Vault (OMV) and Logitech Media Server (LMS). Two months ago I started getting system messages which I couldn’t resolve and after a few days the system stopped working. I decided to upgrade to Bookworm and have tried to install Armbian 24.11.1 Bookworm Minimal from here: https://www.armbian.com/odroid-n2/ This has been a struggle as I variously get messages telling me “the root file system requires a manual fsck“. Or, after switching off and on again, I get through to the auto log-in and try apt-get update and get responses which include: If I try apt-get upgrade, I get messages which include: I have re-cut the SD card umpteen times and get the same issues. I have also tried the image on the same page which included OMV ((Debian 12 (Bookworm) – OpenMediaVault) and got the same issues. Does anyone have an idea how to resolve these issues, per chance?

May be a small step: This is the overlay I use on both, H3 and H5 systems: /dts-v1/; /plugin/; / { compatible = "allwinner,sun8i-h3", "allwinner,sun50i-h5"; fragment@0 { target-path = "/"; __overlay__ { soc { usb@1c19000 { dr_mode = "host"; }; }; usb0-vbus { #status = "okay"; status = "disabled"; }; }; }; }; For H3, I have set status for usb0-vbus to okay, for H5 to disabled. If its okay for the H5, power is on after boot, device (SD card) is usable (see below) but I cannot control power. Now, when disabled, I see following on the H5 system: The proper GPIO 354 file is seen in /sys/class/gpio/. I know that this is the old legacy way of controlling GPIO's on the new kernels. But it works perfectly well on the H3 with the same kernel revision, just 32 bit instead of 64 bit on the H5 I can export it and then echo 1 or 0 to it which actually toggles power (can see that on the blue light of the micro SD adapter for the micro USB port) But, usb0-vbus=disabled seems to disable the whole system USB, as for example lsusb shows nothing anymore and therefore lsblk does not show the device So, nice try, but not successful. I'll continue research the next days. The good thing is, that the H5 is a pure test device 😉

But I'm grateful that it also works for me with pure U-boot:

Hello brentr, I downloaded the image from the official website, right from Rock Pi S: https://www.armbian.com/rockpi-s/ Initially and in the most stable version possible I had the noble server CLI version installed, but as it failed and I couldn't get it to boot again, I performed clean installations of both systems, both Debian Bookworm and Ubuntu Noble and in both cases the same failure occurs, after performing an apt upgrade from a clean installation and executing a reboot, it bricks and doesn't boot. From the desperation of these days... I even tried Trixie and Oracular thinking that a more recent version could solve the problem, and directly these images don't work, they didn't boot either. Thinking it might be a problem with the recent u-boot tool updates, I repeated this whole process, installing it on the eMMC, with the same result. The feeling is that some base package has been touched, corrupting the installation. I'd like to provide the logs for further help, but as I mentioned, I don't have a TTL serial cable handy to debug, so I'll have to have one. So I found myself in a loop with no way out, so I appreciate the quick response to solve this problem. Thanks.

Here is a change to support 32k osc on H616/H618 by using the new driver clk/sunxi-ng/ccu-sun6i-rtc.c instead of retrofitting the code into drivers/rtc/rtc-sun6i.c ccu-sun6i-rtc.c needs to be compiled into the kernel instead of being a module. Additionally it need to announce "osc32k-out" instead of "osc32k". There is a diff file that changes the kernel config and the patches to perform and the patch file that changes the driver to place in patch/kernel/archive/sunxi-6.7/patches.armbian/ Move_32k_osc_diff.patch drv-clk-sunxi-ng-use-osc32k-out.patch

It looks like some more generic issue with PCIe/NVMe as Rock4A is Rk3399, not RK35xx. On my RK3588S NVMe works OK with 6.12.9 and 6.13.0-rc5 (2024.10 U-Boot loader in eMMC). I hope you have backups, so then there is always tricks to copy 6.6.x kernel+DTB+modules from there and get it to boot again. You will need spare/temporary SD-card I think. I do rather crazy things with SBC Linux installs, so I have my methods to flip to an older/other kernel (Btrfs snapshots). SBC/embedded Linux does not have GRUB bootmanager by default, otherwise that would be the way to select older kernel. You can always download and older image (from archives) and use that (for manually extracting older kernel). Same as my earlier comment for Rock3C, I think newer U-Boot is needed. It also might be a power stability issue. I know with my Rock3A I needed even to look in schematics before I got some trust in the board. The 6.12.9 kernel might initialize things in a different way/sequence, but all pure guessing. I do not know the power architecture of the Rock3C nor Rock4A. For my Rock3A, I soldered a 12V wire pair to a USB-C DIY connector, so the board uses its own 5V 8A DC/DC convertor. That works fine.