Hi Lucas, On Thu, Jul 9, 2026 at 8:54 AM Lucas <[email protected]> wrote: > > I am trying to use the odroid HC4 with Armbian Linux and two 3.5 inch SATA > HDDs physically inserted. I believe I have traced a bug to uboot code at > the start of the boot process. > > The issue is documented here: > https://github.com/armbian/build/issues/9532 > > I have two versions of Armbian, one works and one doesn't: > Armbian_26.5.1_Odroidhc4_trixie_current_6.18.33_minimal.img.xz - fails > Armbian_25.8.1_Odroidhc4_bookworm_current_6.12.41_minimal.img.xz - works > > Both versions boot fine with no HDDs inserted. Some SATA devices boot fine. > These are powerful WD Red enterprise drives. When I interrupt boot by > pressing any key, I can run `scsi scan` and `boot` and have it boot > successfully on both versions. I also see HDMI visual artifacts during the > scsi scan sequence (the text becomes garbled on a few lines) that always > means the boot will be successful. > > I tried compiling edits to /boot/boot.cmd. These edits did persist (I saw > my echo commands) but did not fix the problem. There is part of the boot > sequence that happens before the compiled boot.cmd runs. > > I tried setting preboot flags without recompilation, but can't figure out > if this is supported on Armbian / HC4. > > I believe this preboot portion is controlled by uboot. > > I made some edits to the armbian code and ran a `compile.sh` command that > seems to create a new uboot. I wrote that to the SD card and the board no > longer boots with that card. > > In order to diagnose further, I could use some help confirming that this > portion of boot is controlled by uboot.
PCI-based SATA drives could be spinning up either during preboot or after, depending how u-boot is configured. It would be more helpful if you can post the following info: - Which version of u-boot, and whether Armbian has any downstream patch applied on top of the mainline u-boot source. If you're not sure, post the GitHub URL of the Armbian u-boot source. - The content of the defconfig file used in this u-boot, ie. ./configs/xxx_defconfig (where xxx is the board name). It probably can be found in some build shell scripts. - If possible, power up, interrupt u-boot countdown and list the following info. ver printenv For reference, here is the commit to fix this problem, but I have tested only with <= 4TB HDDs. https://github.com/u-boot/u-boot/commit/53cc4332b3b37218a7cdab8bdb953da57eec2668 All the best, Tony
