The usual error

seems to be the driver, not a thing we can overlay device tree? Id for xt25f128b is implemented.

Zitat

 

unrecognized JEDEC id 0

 

meson-spifc ffd14000.spi: registered host spi0
spi spi0.0: setup mode 0, 8 bits/w, 1000000 Hz max --> 0
spi-nor spi0.0: supply vcc not found, using dummy regulator
spi-nor spi0.0: error -95 reading JEDEC ID
spi-nor spi0.0: probe with driver spi-nor failed with error -95
meson-spifc ffd14000.spi: registered child spi0.0

Images tested:

Armbian_25.5.1_Odroidhc4_bookworm_current_6.12.28_minimal.img

Armbian_25.5.1_Odroidhc4_noble_current_6.12.28.img

Kernel versions tested: multiple (6.6.x, 6.7.x, 6.12.x) through armbian-config

Issues observed:

1. No USB keyboard at boot

I have tested with three different USB keyboards (all working fine on Debian/Ubuntu official images).

2. SATA not initialized → NAS functionality is broken

Always get:

ata1: SATA max UDMA/133 ata1: SATA link down (SStatus 0 SControl 300) ata2: SATA max UDMA/133 ata2: SATA link down (SStatus 0 SControl 300)

Disks are never detected.

This makes Armbian unusable on HC4 as a NAS (which is the main purpose of the board).

3. Petitboot incompatibility and restore procedure

Armbian does not boot correctly with Petitboot (the default bootloader shipped by Hardkernel).

The Armbian documentation recommends removing Petitboot, which prevents using other distributions afterwards.

The official Armbian forum threads redirect to Hardkernel forum.

The tools to restore Petitboot are hosted on ppa.linuxfactory.or.kr, which has been offline for over a week !...

This effectively leaves users stuck without a working bootloader or system.

 

Expected behavior

SATA disks should be detected and initialized (as with Hardkernel’s Debian/Ubuntu 5.15 LTS images).

USB keyboards should work at boot.

Armbian should either work with Petitboot, or provide a reliable documented way to restore it.

At the moment, Armbian on ODROID-HC4 is unusable as a NAS due to SATA not working and Petitboot being broken.
The only working setup is using Hardkernel’s old Debian/Ubuntu images with kernel 5.15.
 

Could you please clarify:

Is HC4 still officially supported by Armbian? Do you test your releases ?

If yes, which kernel/branch should be used for stable SATA support?...

Will there be fixes for USB keyboard and Petitboot compatibility?

Thanks a lot !

I wanted to run a fresh, plain Armbian and install dietpi. 

But there is a well documented flaw where Armbian cannot exit boot in some cases. In my case, it happens only when SATA drives are attached. I have two WD Red drives that it can't boot with those attached.

It seems like the bootloader code was changed over time, which let prior builds boot but not current builds.

Admittedly, these drives fail SMART, so they could be reporting bad data.

Errors:

Scanning bus for devices...
[SATA stuff]
timeout exit!
fs_devread read error - block
[SATA stuff - size is off by about 10x - says 700 GB, actually 6 TB]
Device 0: [SATA stuff]
... is now current device
timeout exit!
timeout exit!
timeout exit!
[etc.]

I tried setting the code in /boot to only attempt to boot from emmc0 and emmc1.

The farthest I got was this, but I think updating to trixie via armbian-config again broke the boot code:

installed old armbian minimal

apt install armbian-config

# the keys are old and fail with the sha1 ban recently implemented. this fixes that
wget https://apt.armbian.com/armbian.key
gpg --dearmor < armbian.key | sudo tee /usr/share/keyrings/armbian.gpg > /dev/null

armbian-config: disable firmware update (also disables kernel updates)

distro full upgrade from armbian-config

got:

Description:    Armbian 26.5.1 trixie
Release:        13

https://dietpi.com/docs/hardware/#make-your-own-distribution

noticed this in the install script running, i'm worried it will wipe the good old firmware and replace with new bad:

0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
[  OK  ] DietPi-Installer | APT install linux-image-current-meson64 linux-u-boot-odroidhc4-current
[  OK  ] DietPi-Installer | rm -f /boot/uImage /boot/uInitrd /boot/uInitrd-6.18.34-current-meson64
[  OK  ] DietPi-Installer | rm /boot/.next
[  OK  ] DietPi-Installer | rm /boot/armbianEnv.txt
[  OK  ] DietPi-Installer | mkimage -C none -A arm64 -T script -d /boot/boot.cmd /boot/boot.scr
[ SUB1 ] DietPi-Set_hardware > flash-u-boot-mmc (/dev/mmcblk0)
442+0 records in
442+0 records out
442 bytes copied, 0.00430629 s, 103 kB/s
2626+1 records in
2626+1 records out
1344880 bytes (1.3 MB, 1.3 MiB) copied, 0.162507 s, 8.3 MB/s
[  OK  ] flash-u-boot-mmc (/dev/mmcblk0) | Completed
[ INFO ] DietPi-Installer | Preventing needless kernel and initramfs symlink generation
[  OK  ] DietPi-Installer | eval echo 'do_symlinks=0' > /etc/kernel-img.conf
[  OK  ] DietPi-Installer | rm -f /initrd.img /initrd.img.old /vmlinuz /vmlinuz.old
[ INFO ] DietPi-Installer | Generating list of minimal packages, required for DietPi installation
[  OK  ] DietPi-Installer | Marking required packages as manually installed
[  OK  ] DietPi-Installer | Unhold all packages
[ INFO ] DietPi-Installer | APT autopurge gawk original-awk, please wait...
Reading package lists...
 

Ideas:

- try booting with just one SATA

- try another SATA drive

- try with petitboot (older / manufacturer boot code) instead of uboot

- compare working /boot folder on working microsd with failed /boot folder (I did this, far too many differences to list). I did try copying key differences and recompiling the boot, didn't seem to fix it.

- hotswap / hot install the drives after boot (apparently works)

related:

https://dietpi.com/forum/t/error-on-updating-ombi/25096

https://dietpi.com/forum/t/dietpi-os-apt-update-warnings/24923/31?page=2

https://forum.openmediavault.org/index.php?thread/43298-install-omv-on-odroid-hc4-some-questions-from-a-newbie/

https://dietpi.com/forum/t/odroid-hc4-sata-drives-not-recognized/4795

https://dietpi.com/forum/t/odroid-c2-doesnt-boot-up/6489/14

https://dietpi.com/forum/t/orange-pi-5-boot-from-sata-m-2-ssd/17884/51?page=2

https://github.com/MichaIng/DietPi/issues/7601

I currently have the issue of a non working usb port on my odroidhc4. 

dmesg output:

[  133.464610] usb usb1-port2: connect-debounce failed

The port does not show up when lsusb is entered.

uname -a:

Linux odroidhc4 6.12.56-current-meson64 #1 SMP PREEMPT Wed Oct 29 13:09:02 UTC 2025 aarch64 GNU/Linux

I solved this temporairly a while ago by booting an older kernel (linux-image-6.12.43+deb12-arm64) like mentioned here: 

Are there any progresses on how to fix this reliably? Because I think still running kernel 6.6.63 is not save.

Thanks for your answer in advance, if you need more information I am happy to deliver.

I was do the following to test and validate the issue:

• I have disable the fancontrol service and manually written to hwmon2/pwm1 to set the PWM. Which was possible on the healthy HC4, but on the unhealthy HC4 would it only be full speed or no speed.
• I have tried the latest version of Armbian Noble and Trixie the hwmon2/pwm1 is exposed but doesn't allow me to modify the speed of the fan.
• I have tried the official os image from Hardkernel and here does the fan work as expected.

I installed Armbian_community_26.2.0-trunk.151_Odroidhc4_trixie_current_6.18.2_minimal.img

Trying to build zfs-dkms I discovered that I was missing the linux-headers for this kernel version
and there is no package containing it. At least apt-cache didn't find anything.

Any idea where to find it?

Thanks,
Chris

Hopefully this will fix at least one issue people have been reporting, where some HDDs (or other devices) do not react well to rapid power double-tap during boot.

https://github.com/armbian/build/blob/main/patch/kernel/archive/meson64-6.19/board-odroid-sm1-regulators-boot-on.patch

It will also be released (and likely backported) upstream in next Linux kernel release and/or fixes.

Also, something else people have been reporting is the HC4 struggling to spin up two large HDDs at the same time.  If you have an HDD with a "Power Up In Standby" (PUIS) setting, such as the Seagate IronWolf, then you can configure all non-system (non-boot) drives in this manner, and then mount and access them sequentially after the system has booted.  Depending on how much power the HDDs use in regular operation, this might work to get both spun up and running.  Theoretically, you could also access just one drive at a time and then place it back in standby before using the other drive. YMMV.

OS: Armbian (current version)

Kernel: 6.12.44-current-meson64

Use case: Production NAS with critical data

Problem Description
During apt upgrade, the following critical warnings appear:

dpkg: warning: This system uses merged-usr-via-aliased-dirs, going behind dpkg's
dpkg: warning: back, breaking its core assumptions. This can cause silent file
dpkg: warning: overwrites and disappearances

System state analysis reveals:

/bin, /sbin, /lib are correct symlinks to /usr/*

BUT: Files exist in duplicate (/bin/bash and /usr/bin/bash identical)

DKMS cannot build kernel modules (missing headers)

systemd cannot set journal flags (symlink to SD card)

NAS Configuration (Critical Infrastructure)
Storage Setup:

RAID1 with mdadm (two HDDs) + LUKS encryption
/var/log relocated to SD card

Filesystem:
/dev/mmcblk0p1: LABEL="armbi_root" TYPE="ext4"
/dev/sda: TYPE="crypto_LUKS"
/dev/sdb: TYPE="crypto_LUKS"
/dev/mapper/sda_luks: TYPE="linux_raid_member"
/dev/mapper/sdb_luks: TYPE="linux_raid_member"
/dev/md0: TYPE="ext4"

Reproduction

$ ls -la /bin /sbin /lib
lrwxrwxrwx 1 root root 7 Apr 22  2024 /bin -> usr/bin
lrwxrwxrwx 1 root root 7 Apr 22  2024 /lib -> usr/lib
lrwxrwxrwx 1 root root 8 Apr 22  2024 /sbin -> usr/sbin

$ ls -la /usr/bin/bash /bin/bash
-rwxr-xr-x 1 root root 1543048 Mar 31  2024 /bin/bash
-rwxr-xr-x 1 root root 1543048 Mar 31  2024 /usr/bin/bash  # DUPLICATE!

Urgent Questions
1. Root Cause Analysis
Has anyone experienced this specific issue with Armbian on ODROID HC4?

Is this a known upgrade problem with a particular Armbian version?

2. Solution Paths
Which approach do you recommend for a production NAS?

A) System repair tool (is there an Armbian-specific one?)

Manual cleanup - any experiences with this?

C) Migration to new image - best method with LUKS+RAID?

D) Install kernel headers first despite warnings?

3. Migration Strategy with LUKS
How to safely migrate:

LUKS configuration (keys, passphrases)

mdadm RAID1 setup

Samba/NFS shares and ACLs

WireGuard configuration

Risk Assessment

Current risk:

Silent data corruption possible

Kernel updates may break filesystem modules

System might not boot after next reboot

Time pressure:
NAS must remain available, but security is top priority.

System Details

# dpkg --version
Debian 'dpkg' package management program version 1.22.6 (arm64).

# uname -a
Linux odroidhc4 6.12.44-current-meson64 #3 SMP PREEMPT Thu Aug 28 14:31:16 UTC 2025 aarch64 aarch64 aarch64 GNU/Linux

# cat /etc/armbian-image-release
BOARD=odroidhc4
BOARD_NAME="Odroid HC4"
VERSION=25.2.1
REVISION=25.2.1
IMAGE_UUID=54c1127b-9e70-4d3f-bedd-3faf1f5e58fa
BUILD_REPOSITORY_COMMIT=1f6972065

Request for assistance with:
Immediate actions to stabilize the system

Proven migration method for Armbian+ODROID+LUKS

Experiences with this specific bug

1:/ you'll need a USB-card-reader-adapter.

2:/ no matter how your USB-reader card reader sees your emmc, microSD card, ..., it'll most likely be mounted on a /dev/sda1 partition.

3:/ sudo dd bs=4M if=/dev/sda of=~/tmp/armbian_odroidc4_11_01_2025.img
(you don't dd the partition, you dd the drive).

4:/ (optionally) sudo xz -v armbian_odroidc4_11_01_2025.img  
(this will take some time).

...and that's it, ... and you know the rest.

I have an Odroid C4 with petitboot on sd for booting os's.  I have a couple usb3>sata cases with 120g ssd's installed.  Blazing fast and about $25usd 🙂

I can then download images and write them to the drives.  Dietpi 9.11 and using the netboot function builtin to petiboot a few different flavors of other os's including debian 12.

I have Armbian on SD as well.  My problem is that it is incredibly slow running from sd on my c4.   It runs VERY WELL though and detects audio properly on my tv through hdmi (shows as unknown display).

Where Debian 12 and Dietpi DONT. I get NO SOUND from them.  I just shutdown, swap usb and each boots nicely from petitboot.

Is there a way to make Armbian like dietpi where its disk format is recognized by petitiboot?  Then you would no longer have to do any u-boot configuration.

I searched the forums and saw a post about using armbian-config to install to usb and did that.  But petitboot does not see the drive so will not boot from it. I booted from the armbian sd and it appears to be using the usb drive but upon upgrade (of 37 pkgs) from 12.9>12.10 It fails with many file size/hash sum mismatch.  It mentions mirror-sync in progress so I will try again later.

And now that I am using usb storage on Armbian there is NO SOUND.  So it appears that my sound problem on the C4 is usb related.

I unplugged the usb and thought it would launch Armbian from sd but apparently uboot was changed so that fails.

I will start hunting for odroid usb/sata sound issues and see if i have any luck.

Just wondered if you have any ideas on this?  Thanks.

I have an overlay available for Odroid C4 (Kernel 6.6.51), which needs some testing in the field.

It supports 12MHz operation max on the pins 19, 21, 23 and 24 on the GPIO header.

In case you have a test case for that, let me know, and I can provide things to you.

Michael

after a long time I started up my C4 and tried both the standard download kernel as well as a home compiled one.

I need SPI on the C4, so I changed the device tree to meson-sm1-odroid-c4-spidev.dtb, and see spidev kernel modul loaded, but no driver, and I don't get any signals on the corresponding pins.

Any help is appreciated - would be great to have SPI working again...

See you, Michael

I found https://wiki.odroid.com/odroid-c4/os_images/ubuntu/minimal/20200526#opencl_configuration but the package mali-fbdev isn't available on armbian.

Closest I've got is :

$ curl -L http://deb.odroid.in/c4/pool/main/m/mali-midgard-driver/mali-fbdev_0.1-2ubuntu4_arm64.deb -o mali-fbdev_0.1-2ubuntu4_arm64.deb
$ ar -xv mali-fbdev_*
$ tar --use-compress-program=unzstd -xvf data.tar.zst
$ sudo cp -r usr/* /usr/
$ mkdir -p /etc/OpenCL/vendors/
$ echo /usr/share/mali-odroid-c4/libmali.so | sudo tee /etc/OpenCL/vendors/mali.icd

But then clinfo fails with :

$ clinfo
Number of platforms                               1
  Platform Name                                   ARM Platform
  Platform Vendor                                 ARM
  Platform Version                                OpenCL 2.0 git.c8adbf9.ad00b04c1b60847de257177231dc1a53
  Platform Profile                                FULL_PROFILE
  Platform Extensions                             cl_khr_global_int32_base_atomics cl_khr_global_int32_extended_atomics cl_khr_local_int32_base_atomics cl_khr_local_int32_extended_atomics cl_khr_byte_addressable_store cl_khr_3d_image_writes cl_khr_int64_base_atomics cl_khr_int64_extended_atomics cl_khr_fp16 cl_khr_icd cl_khr_egl_image cl_khr_image2d_from_buffer cl_khr_depth_images cl_khr_create_command_queue cl_arm_core_id cl_arm_printf cl_arm_thread_limit_hint cl_arm_non_uniform_work_group_size cl_arm_import_memory cl_arm_shared_virtual_memory
  Platform Extensions function suffix             ARM

  Platform Name                                   ARM Platform
Number of devices                                 1
Failed creating base context during opening of kernel driver.

So, presumably, there is a kernel module to be installed as well.

I also found https://developer.arm.com/downloads/-/mali-drivers/user-space ... but doesn't indicate support for the C4.

Any hints to get further ?  Thanks.