KV1

TL;DR: fsck /dev/sdb1 Looks like something corrupted the drive filesystem. I was able fsck repair the drive, and re-apply the image via armbian-imager. The fact that armbian-imager 'validated' the flashed contents multiple times is where things went sideways. Once i tried to manually delete the contents of the drive, and that failed, it became apparent that the drive had been corrupted. I'm not sure what the 'validation' that armbian-imager does is, though.

Armbian-imager is just.. not doing anything useful... I manually deleted the 'kernel' on the device... which was really an apt packages list somehow... rebuilt & 'flashed'... 14:03:51 ● custom_image: Board detection completed successfully 14:03:51 ● frontend::app: Detected board from filename: Espressobin (espressobin) 14:03:52 ● board_queries: Device(s) added: ["/dev/sda", "/dev/sdb", "/dev/nvme0n1"] 14:03:55 ● operations: Requesting write authorization for device: /dev/sdb 14:03:55 ● flash::linux::privileges: Authorization will be requested via polkit when accessing: /dev/sdb 14:03:55 ● operations: Authorization granted for /dev/sdb 14:03:55 ● custom_image: Check decompression for /srv/development/espressobin-ultra/armbian-build/build/output/images/Armbian-unofficial_26.05.0-trunk_Espressobin_trixie_edge_6.18.21.img: false 14:03:55 ● operations: Starting flash: /srv/development/espressobin-ultra/armbian-build/build/output/images/Armbian-unofficial_26.05.0-trunk_Espressobin_trixie_edge_6.18.21.img -> /dev/sdb (verify: true) 14:03:55 ● flash::linux::writer: Starting flash: /srv/development/espressobin-ultra/armbian-build/build/output/images/Armbian-unofficial_26.05.0-trunk_Espressobin_trixie_edge_6.18.21.img -> /dev/sdb 14:03:55 ● flash::linux::writer: Image size: 2139095040 bytes (1.99 GB) 14:03:55 ● flash::linux::writer: Unmounting device partitions... 14:03:55 ● flash::linux::writer: Writing image... 14:04:01 ● flash::linux::writer: Write complete: 2040.0 MB in 5.5s (avg 373.2 MB/s) 14:04:01 ● flash::linux::writer: Starting verification... 14:04:01 ● flash::verify: Starting verification of 2139095040 bytes (1.99 GB) 14:04:05 ● flash::verify: Verify complete: 2040.0 MB in 4.6s (avg 441.9 MB/s) 14:04:05 ● flash::linux::writer: Flash complete! 14:04:05 ● operations: Flash completed successfully 14:04:05 ● custom_image: Deleting decompressed custom image: /srv/development/espressobin-ultra/armbian-build/build/output/images/Armbian-unofficial_26.05.0-trunk_Espressobin_trixie_edge_6.18.21.img 14:04:05 ● custom_image: Attempted to delete file outside custom-decompress cache: /srv/development/espressobin-ultra/armbian-build/build/output/images/Armbian-unofficial_26.05.0-trunk_Espressobin_trixie_edge_6.18.21.img > sudo mount /dev/sdb1 /mnt/ > ls /mnt bin boot/ dev/ etc/ home/ initrd.img initrd.img.old lib lost+found/ media/ mnt/ opt/ proc/ root/ run/ sbin selinux/ srv/ sys/ tmp/ usr/ var/ vmlinuz vmlinuz.old > ls -ltr /mnt/ total 80 drwxr-xr-x 2 root root 4096 Mar 2 16:50 sys/ lrwxrwxrwx 1 root root 8 Mar 2 16:50 sbin -> usr/sbin/ drwxr-xr-x 2 root root 4096 Mar 2 16:50 proc/ lrwxrwxrwx 1 root root 7 Mar 2 16:50 lib -> usr/lib/ drwxr-xr-x 2 root root 4096 Mar 2 16:50 home/ drwxr-xr-x 2 root root 4096 Mar 2 16:50 dev/ lrwxrwxrwx 1 root root 7 Mar 2 16:50 bin -> usr/bin/ drwxr-xr-x 2 root root 4096 Mar 31 22:57 mnt/ drwxr-xr-x 2 root root 4096 Mar 31 22:57 srv/ drwxr-xr-x 2 root root 4096 Mar 31 22:57 opt/ drwxr-xr-x 2 root root 4096 Mar 31 22:57 media/ drwxr-xr-x 11 root root 4096 Mar 31 22:57 usr/ drwxrwxrwt 2 root root 4096 Mar 31 22:57 tmp/ drwxr-xr-x 12 root root 4096 Apr 7 16:47 var/ drwxrwxr-x 2 root root 4096 Apr 7 16:47 selinux/ lrwxrwxrwx 1 root root 33 Apr 7 16:48 vmlinuz.old -> boot/vmlinux-6.18.21-edge-mvebu64 lrwxrwxrwx 1 root root 33 Apr 7 16:48 vmlinuz -> boot/vmlinux-6.18.21-edge-mvebu64 lrwxrwxrwx 1 root root 36 Apr 7 16:48 initrd.img.old -> boot/initrd.img-6.18.21-edge-mvebu64 lrwxrwxrwx 1 root root 36 Apr 7 16:48 initrd.img -> boot/initrd.img-6.18.21-edge-mvebu64 drwx------ 3 root root 4096 Apr 7 16:48 root/ drwx------ 2 root root 16384 Apr 7 16:49 lost+found/ drwxr-xr-x 91 root root 4096 Apr 7 16:49 etc/ drwxr-xr-x 3 root root 4096 Apr 7 16:49 run/ drwxr-xr-x 3 root root 4096 Apr 8 13:35 boot/ > ls -ltr /mnt/boot/ total 59328 -rw-rw-r-- 1 root root 1592 Apr 3 18:14 boot.cmd -rw-r--r-- 1 root root 5318624 Apr 3 18:36 System.map-6.18.21-edge-mvebu64 -rw-r--r-- 1 root root 224205 Apr 3 18:36 config-6.18.21-edge-mvebu64 lrwxrwxrwx 1 root root 28 Apr 7 16:48 Image -> vmlinux-6.18.21-edge-mvebu64 drwxr-xr-x 3 root root 4096 Apr 7 16:48 dtb-6.18.21-edge-mvebu64/ lrwxrwxrwx 1 root root 24 Apr 7 16:48 dtb -> dtb-6.18.21-edge-mvebu64/ -rw-rw-r-- 1 root root 38518 Apr 7 16:48 boot.bmp -rw-rw-r-- 1 root root 95 Apr 7 16:49 armbianEnv.txt -rw-rw-r-- 1 root root 1664 Apr 7 16:49 boot.scr -rw-r--r-- 1 root root 18372350 Apr 7 16:49 initrd.img-6.18.21-edge-mvebu64 -rw-r--r-- 1 root root 18372414 Apr 7 16:49 uInitrd-6.18.21-edge-mvebu64 lrwxrwxrwx 1 root root 28 Apr 7 16:49 uInitrd -> uInitrd-6.18.21-edge-mvebu64 -rw-r--r-- 1 root root 18398788 Apr 7 16:49 espressobin.itb > ls -ltr /srv/development/espressobin-ultra/armbian-build/build/output/images/Armbian-unofficial_26.05.0-trunk_Espressobin_trixie_edge_6.18.21.img -rw-rw-r-- 1 root root 2139095040 Apr 8 14:02 /srv/development/espressobin-ultra/armbian-build/build/output/images/Armbian-unofficial_26.05.0-trunk_Espressobin_trixie_edge_6.18.21.img > > ls -ltr /mnt/boot/Image lrwxrwxrwx 1 root root 28 Apr 7 16:48 /mnt/boot/Image -> vmlinux-6.18.21-edge-mvebu64 > ls -ltr /mnt/boot/vmlinux-6.18.21-edge-mvebu64 ls: cannot access '/mnt/boot/vmlinux-6.18.21-edge-mvebu64': No such file or directory > so... why is armbian-imager not pushing the kernel files from a custom image?

Even more confusing the file on the disk, written with armbian-imager is a text file, looks like an apt sources file: > file /mnt/boot/vmlinux-6.18.21-edge-mvebu64 /mnt/boot/vmlinux-6.18.21-edge-mvebu64: ASCII text, with very long lines (1483) > head /mnt/boot/vmlinux-6.18.21-edge-mvebu64 com/daniel-casanueva/haskell/graphviz Description-md5: bd02d2c14f791ffca367313e1957b329 Ghc-Package: graphviz-2999.20.2.0-JKUYtUkvYwE3GbOspxTTfB Section: haskell Priority: optional Filename: pool/main/h/haskell-graphviz/libghc-graphviz-dev_2999.20.2.0-1+b1_arm64.deb Size: 3696512 MD5sum: 36c93a1f30f0234eadffbf9ae0d2336b SHA256: 5b95053c25c02020e9eca717df070591259432e5c125435f5514761417bc8879 The built file looks fine: 1348921 717100 -rw-rw-r-- 1 root root 734305912 Apr 7 17:45 ./cache/sources/linux-kernel-worktree/6.18__mvebu64__arm64/vmlinux.o > file ./cache/sources/linux-kernel-worktree/6.18__mvebu64__arm64/vmlinux.o ./cache/sources/linux-kernel-worktree/6.18__mvebu64__arm64/vmlinux.o: ELF 64-bit LSB relocatable, ARM aarch64, version 1 (SYSV), with debug_info, not stripped

When trying to rebuild the kernel, the image is not taking the updated kernel image: ./compile.sh BOARD=espressobin CLEAN_LEVEL=make-kernel RELEASE=trixie ..... -rwxrwxr-x 1 root root 296665952 Apr 7 16:47 vmlinux.unstripped -rw-rw-r-- 1 root root 220926 Apr 7 16:47 modules.builtin.modinfo -rw-rw-r-- 1 root root 16667 Apr 7 16:47 modules.builtin -rwxrwxr-x 1 root root 296215160 Apr 7 16:47 vmlinux drwxrwxr-x 23 root root 12288 Apr 7 16:47 kernel/ drwxrwxr-x 79 root root 12288 Apr 7 16:47 fs/ drwxrwxr-x 5 root root 36864 Apr 7 16:47 crypto/ drwxrwxr-x 22 root root 20480 Apr 7 16:47 lib/ drwxrwxr-x 27 root root 4096 Apr 7 16:47 sound/ drwxrwxr-x 23 root root 12288 Apr 7 16:47 scripts/ $ armbian-imager # installed the new image... 16:55:21 ● custom_image: Check decompression for /srv/development/espressobin-ultra/armbian-build/build/output/images/Armbian-unofficial_26.05.0-trunk_Espressobin_trixie_edge_6.18.21.img: false 16:55:21 ● operations: Starting flash: /srv/development/espressobin-ultra/armbian-build/build/output/images/Armbian-unofficial_26.05.0-trunk_Espressobin_trixie_edge_6.18.21.img -> /dev/sdb (verify: true) 16:55:21 ● flash::linux::writer: Starting flash: /srv/development/espressobin-ultra/armbian-build/build/output/images/Armbian-unofficial_26.05.0-trunk_Espressobin_trixie_edge_6.18.21.img -> /dev/sdb 16:55:21 ● flash::linux::writer: Image size: 2252341248 bytes (2.10 GB) 16:55:21 ● flash::linux::writer: Unmounting device partitions... 16:55:21 ● flash::linux::writer: Writing image... 16:55:27 ● flash::linux::writer: Write complete: 2148.0 MB in 5.4s (avg 398.9 MB/s) 16:55:27 ● flash::linux::writer: Starting verification... 16:55:27 ● flash::verify: Starting verification of 2252341248 bytes (2.10 GB) 16:55:32 ● flash::verify: Verify complete: 2148.0 MB in 4.9s (avg 441.9 MB/s) 16:55:32 ● flash::linux::writer: Flash complete! 16:55:32 ● operations: Flash completed successfully 16:55:32 ● custom_image: Deleting decompressed custom image: /srv/development/espressobin-ultra/armbian-build/build/output/images/Armbian-unofficial_26.05.0-trunk_Espressobin_trixie_edge_6.18.21.img 16:55:32 ● custom_image: Attempted to delete file outside custom-decompress cache: /srv/development/espressobin-ultra/armbian-build/build/output/images/Armbian-unofficial_26.05.0-trunk_Espressobin_trixie_edge_6.18.21.img $ sudo mount /dev/sdb1 /mnt/ $> ls -ltr /mnt/boot/vmlinux-6.18.21-edge-mvebu64 -rw-r--r-- 1 root root 36108800 Apr 3 18:36 /mnt/boot/vmlinux-6.18.21-edge-mvebu64 When booting: [ 0.000000] Booting Linux on physical CPU 0x0000000000 [0x410fd034] [ 0.000000] Linux version 6.18.21-edge-mvebu64 (build@armbian) (aarch64-linux-gnu-gcc (Debian 14.2.0-19) 14.2.0, GNU ld (GNU Binutils for Debian) 2.44) #1 SMP PREEMPT Thu Apr 2 07:23:33 EDT 2026 [ 0.000000] KASLR enabled

I tried using the 'bootflow scan -b` after getting the armbian efi build installed on the SATA, Grub came up fine, but it never made it past initrd loading... nothing further ever. Using mox-imager and pushing your release image gave me a lot of stability for the standard eMMC install... Re-flashed that image, but didn't help... still panicing all the time -- different places -- with the 6.x kernels (6.12, 6.18, 6.19) on the Armbian install. I've seen some comments about power draw / PSU issues in other threads, but i'm just using the stock PSU provided. You're not doing anything special with Device Tree / Overlays are you?

Moreso the timing of the boot sequence and device enablement. The fact that i got the Debian-on-SATA to load ONE TIME strikes me as very odd. The fact that i get kernel panics on the stock eMMC now and then, also strikes me as very odd. I've tried using the different uboot clock-timing builds for DDR offered by armbian ( ), but they all show the same thing... so i don't think it's the cpu/ddr timings.. i think its the bootup timings, or power configs or something introduced around pcie/sata since 4.x. But clearly i'm shooting into the wind at this point.

Correct -- GTI ships it with Ubuntu. Installing either of the Armbian supported models (Debian Trixie or Ubuntu Noble) on the SATA causes bootup issues. The stock Ubuntu/eMMC boots up fine -- MOST of the time. i do get kernel panics sometimes even then. -- On the stock install via eMMC: root@ccpe10c1a5:~# w 04:41:40 up 8:24, 1 user, load average: 0.00, 0.00, 0.00 root@ccpe10c1a5:~# lsb_release -d Description: Ubuntu 18.04 LTS root@ccpe10c1a5:~# uname -a Linux ccpe10c1a5 4.19.62-00036-gbc6a6e31fe72 #1 SMP PREEMPT Tue Jun 16 15:39:07 CST 2020 aarch64 aarch64 aarch64 GNU/Linux root@ccpe10c1a5:~# cat /proc/cmdline console=ttyMV0,115200 earlycon=ar3700_uart,0xd0012000 root=/dev/mmcblk0p1 rw rootwait net.ifnames=0 biosdevname=0 On the stock install, I was able to run a memtester test, 10 cycles, no errors. The only thing i got was these xenon-sdhi errors every now and then during the test (below); not sure if it was relevant or not. Although i have seen this when booting, before locking up: [ 3.650635] xenon-sdhci d00d8000.mmc: Timing issue might occur in DDR mode So i'm thinking the hardware is actually OK. It's got to be more a timing issue, or an overlap issue. I restructured the booti components, so there should be no overlaps, though... leaving me with a boot timing issue. Since the stock Ubuntu install fails via kernel panic at times, that's what I'm leaning towards. I guess it could still be configuration in the device tree... i'm not familiar with how to tune those, so looks like I'm going to have to keep digging. I'll have to look closer at what you're doing in ebu-bootloader... maybe it'll work around my issues somehow. Thanks again for all the engagement! -- E.g., Loop 10/10: Stuck Address : ok Random Value : ok Compare XOR : ok Compare SUB : ok Compare MUL : ok Compare DIV : ok Compare OR : ok Compare AND : ok Sequential Increment: ok Solid Bits : ok Block Sequential : setting 5[20847.635300] xenon-sdhci d00d8000.sdhci: eMMC PHY init cannot complete after 1 us setting 91[20966.319305] xenon-sdhci d00d8000.sdhci: eMMC PHY init cannot complete after 1 us setting 108[20989.955374] xenon-sdhci d00d8000.sdhci: eMMC PHY init cannot complete after 1 us setting 160[21061.452841] xenon-sdhci d00d8000.sdhci: eMMC PHY init cannot complete after 1 us ok Checkerboard : ok Bit Spread : ok Bit Flip : setting 199[21753.608246] xenon-sdhci d00d8000.sdhci: eMMC PHY init cannot complete after 1 us setting 256[21832.440524] xenon-sdhci d00d8000.sdhci: eMMC PHY init cannot complete after 1 us ok Walking Ones : ok Walking Zeroes : ok 8-bit Writes : ok 16-bit Writes : ok Done. -- espressobin-ultra> grep sdhci Errors.txt Block Sequential : setting 44[ 1160.445415] xenon-sdhci d00d8000.sdhci: eMMC PHY init cannot complete after 1 us setting 104[ 1243.071074] xenon-sdhci d00d8000.sdhci: eMMC PHY init cannot complete after 1 us Bit Flip : setting 207[ 2022.270265] xenon-sdhci d00d8000.sdhci: eMMC PHY init cannot complete after 1 us setting 493[ 2419.709372] xenon-sdhci d00d8000.sdhci: eMMC PHY init cannot complete after 1 us Block Sequential : setting 51[ 5613.205850] xenon-sdhci d00d8000.sdhci: eMMC PHY init cannot complete after 1 us Block Sequential : setting 86[ 7831.212692] xenon-sdhci d00d8000.sdhci: eMMC PHY init cannot complete after 1 us setting 114[ 7869.815417] xenon-sdhci d00d8000.sdhci: eMMC PHY init cannot complete after 1 us setting 139[ 7904.632847] xenon-sdhci d00d8000.sdhci: eMMC PHY init cannot complete after 1 us Bit Flip : setting 252[ 8698.620476] xenon-sdhci d00d8000.sdhci: eMMC PHY init cannot complete after 1 us Bit Flip : setting 345[11019.588593] xenon-sdhci d00d8000.sdhci: eMMC PHY init cannot complete after 1 us Block Sequential : setting 128[12258.573632] xenon-sdhci d00d8000.sdhci: eMMC PHY init cannot complete after 1 us Bit Flip : tesetting 328[13172.479247] xenon-sdhci d00d8000.sdhci: eMMC PHY init cannot complete after 1 us Walking Zeroes : setting 121[13773.551198] xenon-sdhci d00d8000.sdhci: eMMC PHY init cannot complete after 1 us Block Sequential : setting 94[14421.542088] xenon-sdhci d00d8000.sdhci: eMMC PHY init cannot complete after 1 us setting 241[14624.491234] xenon-sdhci d00d8000.sdhci: eMMC PHY init cannot complete after 1 us Solid Bits : setting 33[16456.854416] xenon-sdhci d00d8000.sdhci: eMMC PHY init cannot complete after 1 us Block Sequential : setting 7[16509.517668] xenon-sdhci d00d8000.sdhci: eMMC PHY init cannot complete after 1 us setting 216[16797.761210] xenon-sdhci d00d8000.sdhci: eMMC PHY init cannot complete after 1 us Walking Ones : setting 44[17908.735026] xenon-sdhci d00d8000.sdhci: eMMC PHY init cannot complete after 1 us Walking Zeroes : setting 14[18044.789017] xenon-sdhci d00d8000.sdhci: eMMC PHY init cannot complete after 1 us Block Sequential : setting 154[18905.444761] xenon-sdhci d00d8000.sdhci: eMMC PHY init cannot complete after 1 us [18905.451549] xenon-sdhci d00d8000.sdhci: eMMC PHY init cannot complete after 1 us setting 228[19007.479627] xenon-sdhci d00d8000.sdhci: eMMC PHY init cannot complete after 1 us [19007.486828] xenon-sdhci d00d8000.sdhci: eMMC PHY init cannot complete after 1 us Bit Flip : setting 14[19347.751784] xenon-sdhci d00d8000.sdhci: eMMC PHY init cannot complete after 1 us setting 164[19556.154518] xenon-sdhci d00d8000.sdhci: eMMC PHY init cannot complete after 1 us Block Sequential : setting 5[20847.635300] xenon-sdhci d00d8000.sdhci: eMMC PHY init cannot complete after 1 us setting 91[20966.319305] xenon-sdhci d00d8000.sdhci: eMMC PHY init cannot complete after 1 us setting 108[20989.955374] xenon-sdhci d00d8000.sdhci: eMMC PHY init cannot complete after 1 us setting 160[21061.452841] xenon-sdhci d00d8000.sdhci: eMMC PHY init cannot complete after 1 us Bit Flip : setting 199[21753.608246] xenon-sdhci d00d8000.sdhci: eMMC PHY init cannot complete after 1 us setting 256[21832.440524] xenon-sdhci d00d8000.sdhci: eMMC PHY init cannot complete after 1 us

Haha - yes, I did eventually `saveenv'... just being super-cautious, and not sure what was going to work, given all the Kernel Panics. Also, in case some other poor guy comes by later and looks for some examples... If i boot the stock kernel/OS from eMMC, it loads (most of the time) and runs fine. I've had a few kernel panics, but usually it loads. If i boot fresh to the eMMC, it also seems to do better. There are some statements around the web that indicate uBoot might be 'hiding' errors prior to the booti, which causes people (like me) to tear their hair out looking in the wrong place -- i.e., register data is already bad before control is even transferred to the kernel. I did pull down armbian build and build out the latest kernel - 6.18, to see if that might make a difference, but no luck. If anything it caused more issues. I WAS able to get all the way booted up into Armbian one time -- adding the pcie power config switches (I thought), and it was stable for a while -- until i tried to `apt update', at which point it locked up. Haven't been able to get all the way up again. My current guesses to look into are: 1. make sure i'm not, as you said, overwriting myself during booti 2. continue to look for kernel config / versions that have better luck with SATA + mvebu64/power config. I'm guessing since I can boot the pre-installed OS that my hardware is actually OK. If you could provide your relevant ext4load (or similar) that you're using for SATA load, i'd appreciate it. I do get these bad rx status issues, and the networking isn't really coming up on the stock. -- Base install: [ 11.352864] mvneta d0030000.ethernet eth0: bad rx status 0cc10000 (crc error), size=75 [ 13.352762] mvneta d0030000.ethernet eth0: bad rx status 0cc10000 (crc error), size=75 root@ccpe10c1a5:~# cat /proc/cmdline console=ttyMV0,115200 earlycon=ar3700_uart,0xd0012000 root=/dev/mmcblk0p1 rw rootwait net.ifnames=0 biosdevname=0 root@ccpe10c1a5:~# uname -a Linux ccpe10c1a5 4.19.62-00036-gbc6a6e31fe72 #1 SMP PREEMPT Tue Jun 16 15:39:07 CST 2020 aarch64 aarch64 aarch64 GNU/Linux root@ccpe10c1a5:~# free -m total used free shared buff/cache available Mem: 993 59 793 2 140 867 Swap: 0 0 0 root@ccpe10c1a5:/media/disk0# dmesg | grep -i panic root@ccpe10c1a5:/media/disk0# w 18:17:28 up 19 min, 1 user, load average: 0.05, 0.03, 0.04

@bschnei - Yep.. it was modules, via uInitrd. Sadly the legacy config says the kernel bootarg param is 'initrd', so that lost me a good chunk of my life i'll never get back. using RAMDISK_START as the boot arg helped. This did, indeed, load the sata modules, which raised the disk. [EDIT: lol. RAMDISK_START apparently isn't even relevant? grep 'Unknown kernel command line parameters' *.log EspressoBin_Ultra-Bootlog.2026-04-03_001.log:[ 0.000000] Unknown kernel command line parameters "RAMDISK_START=0xa00000 biosdevname=0", will be passed to user space. EspressoBin_Ultra-Bootlog.2026-04-03_003.log:[ 0.000000] Unknown kernel command line parameters "RAMDISK_START=0xa00000 biosdevname=0", will be passed to user space. EspressoBin_Ultra-Bootlog.2026-04-03_004.log:[ 0.000000] Unknown kernel command line parameters "RAMDISK_START=0xa00000 biosdevname=0", will be passed to user space. Not sure why it's working now... ] In case this might help someone later, here's the uboot init config I used for the EspressoBin-Ultra to boot from NVMe / SATA / sda1 / SCSI: => setenv scsi_rootfs "UUID=8045e72d-9d9e-465c-a9ee-95cad5513ec8" => setenv scsi_boot_init 'scsi scan; scsi dev 0' => => setenv scsi_kernel_addr_r '0x7000000' => setenv scsi_kernel_name '/boot/Image' => setenv scsi_kernel_load "ext4load scsi 0:1 $scsi_kernel_addr_r $scsi_kernel_name" => setenv scsi_initrd_name '/boot/uInitrd' => setenv scsi_initrd_addr 0xa00000 => setenv scsi_initrd_load "ext4load scsi 0:1 $scsi_initrd_addr $scsi_initrd_name" => setenv scsi_fdt_name '/boot/dtb/marvell/armada-3720-espressobin-ultra.dtb' => setenv scsi_fdt_addr_r '0x6f00000' => setenv scsi_fdt_load "ext4load scsi 0:1 $fdt_addr_r $scsi_fdt_name" => setenv scsi_setbootargs "setenv bootargs $console root=$scsi_rootfs rw rootwait RAMDISK_START=$scsi_initrd_addr net.ifnames=0 biosdevname=0" => setenv scsi_booti "booti $kernel_addr_r $scsi_initrd_addr $fdt_addr_r" => setenv scsi_boot "$scsi_boot_init; $scsi_kernel_load; $scsi_initrd_load; $scsi_fdt_load; $scsi_setbootargs; $scsi_booti" => printenv scsi_boot scsi_boot=scsi scan; scsi dev 0; ext4load scsi 0:1 0x7000000 /boot/Image; ext4load scsi 0:1 0xa00000 /boot/uInitrd; ext4load scsi 0:1 0x6f00000 /boot/dtb/marvell/armada-3720-espressobin-ultra.dtb; setenv bootargs console=ttyMV0,115200 earlycon=ar3700_uart,0xd0012000 root=UUID=8045e72d-9d9e-465c-a9ee-95cad5513ec8 rw rootwait RAMDISK_START=0xa00000 net.ifnames=0 biosdevname=0; booti 0x7000000 0xa00000 0x6f00000 => run scsi_boot And there we go: [ 3.783163] ata1: SATA link up 6.0 Gbps (SStatus 133 SControl 300) [ 3.790704] ata1.00: ATA-11: ORICO, Y0908A0, max UDMA/133 [ 3.796101] ata1.00: 2000409264 sectors, multi 1: LBA48 NCQ (depth 32) [ 3.824725] ata1.00: configured for UDMA/133 [ 3.829607] scsi 0:0:0:0: Direct-Access ATA ORICO 8A0 PQ: 0 ANSI: 5 [ 3.839402] sd 0:0:0:0: [sda] 2000409264 512-byte logical blocks: (1.02 TB/954 GiB) [ 3.847435] sd 0:0:0:0: [sda] Write Protect is off [ 3.852470] sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA [ 3.861614] sd 0:0:0:0: [sda] Preferred minimum I/O size 512 bytes [ 3.883685] sda: sda1 [ 3.886538] sd 0:0:0:0: [sda] Attached SCSI disk Sadly, the kernel is still panicing, during load.... which is basically where I started way back when using 2018 uboot version.... below is the summary, but attached are various boot logs. _001 and _004 are probably the only useful ones though. [ 6.518199] systemd[1]: Starting keyboard-setup.service - Set the console keyboard layout... [ 6.537048] SError Interrupt on CPU0, code 0x00000000bf000001 -- SError [ 6.537084] CPU: 0 UID: 0 PID: 171 Comm: 9 Tainted: G M 6.12.68-current-mvebu64 #5 [ 6.537096] Tainted: [M]=MACHINE_CHECK [ 6.537099] Hardware name: Globalscale Marvell ESPRESSOBin Ultra Board (DT) [ 6.537104] pstate: 20000000 (nzCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) [ 6.537111] pc : 0000ffff9bb2be30 [ 6.537114] lr : 0000ffff9bb2d268 [ 6.537117] sp : 0000ffffea848f80 [ 6.537119] x29: 0000ffffea848f80 x28: 0000ffff9bb51540 x27: 0000ffff9a95b8c8 [ 6.537134] x26: 0000ffff9a880000 x25: 0000ffff9bb5eb70 x24: 0000000000000000 [ 6.537144] x23: 0000000000000000 x22: 0000000000000000 x21: 0000ffff9a9771e0 [ 6.537154] x20: 0000ffff9bb51540 x19: 0000000000000000 x18: 0000000000000fff [ 6.537163] x17: 0000000000000000 x16: 00000000ffffffff x15: 00000000000a6de8 [ 6.537173] x14: 0000000000000000 x13: 0000ffffea849080 x12: 0000ffff9bb4e000 [ 6.537183] x11: 0000000000000000 x10: 0000000000000000 x9 : 0000ffff9a88ae50 [ 6.537192] x8 : 000000000001169a x7 : 0000ffff9a9771e0 x6 : 0000ffff9bb5e000 [ 6.537202] x5 : 0000ffffea849080 x4 : 0000000000000000 x3 : 0000000000000000 [ 6.537211] x2 : 0000000000601588 x1 : 0000ffff9ae62860 x0 : 0000ffff9a95a8c0 [ 6.537223] Kernel panic - not syncing: Asynchronous SError Interrupt [ 6.537228] CPU: 0 UID: 0 PID: 171 Comm: 9 Tainted: G M 6.12.68-current-mvebu64 #5 [ 6.537236] Tainted: [M]=MACHINE_CHECK [ 6.537239] Hardware name: Globalscale Marvell ESPRESSOBin Ultra Board (DT) [ 6.537243] Call trace: [ 6.537248] dump_backtrace+0x98/0xf8 [ 6.537265] show_stack+0x20/0x38 [ 6.537272] dump_stack_lvl+0x34/0x90 [ 6.537283] dump_stack+0x18/0x28 [ 6.537290] panic+0x3a8/0x410 [ 6.537299] nmi_panic+0x48/0xa0 [ 6.537306] arm64_serror_panic+0x78/0x90 [ 6.537313] do_serror+0x44/0x80 [ 6.537320] __el0_error_handler_common+0x3c/0xa0 [ 6.537330] el0t_64_error_handler+0x10/0x20 [ 6.537340] el0t_64_error+0x190/0x198 [ 6.537350] SMP: stopping secondary CPUs [ 6.537373] Kernel Offset: 0x237629600000 from 0xffff800080000000 [ 6.537377] PHYS_OFFSET: 0xffffacdfc0000000 [ 6.537380] CPU features: 0x00,00000090,00200000,4200421b [ 6.537386] Memory Limit: none [ 6.742429] ---[ end Kernel panic - not syncing: Asynchronous SError Interrupt ]--- EspressoBin_Ultra-Bootlog.2026-04-03_001.log EspressoBin_Ultra-Bootlog.2026-04-03_002.log EspressoBin_Ultra-Bootlog.2026-04-03_003.log EspressoBin_Ultra-Bootlog.2026-04-03_004.log

Sorry if i wasn't clear - that's two separate boot profiles... one with a USB drive plugged in, but just left it in after `bubt'ing. The real drive I'm trying to boot from is the SATA nVME 2280 (M+B Key). Once i take the USB drive out, no SDA devices are identified by the kernel. The 6.12.x kernel is on the 2280 drive (SATA/SCSI)... basically `uboot' is able to ext4load the kernel, but once the kernel drops in, it must not be initializing scsi/SATA support, only USB support. Thus, it can't find rootfs, because it hasn't initialized it... but i'm not sure why it hasn't initialized support. All the discussions / AI results suggest it's either a power issue -- which doesn't make sense if it *booted* from the drive itself already?! -- or a device tree issue. I don't know enough about device trees to know, but the above snippet looked like it had support. I reflashed/updated the NVMe via armbian-imager -- looks like a monthly release update, but no change. Are you booting from the emmc or USB then? You're not using the internal SATA/NVMe 2280 connector for boot? Presumably i COULD put root/boot fs on the emmc, but i like to have the fallback option if something goes wrong. This is what i did with my old one -- a DreamPlug, where i just have an SD Card drive everything. If i screw something up, I just take the SD Card out, and it boots off the good-but-old emmc.

OK, I'm getting somewhere, I think -- with your help. I went ahead and flashed the image, which took fine: TIM-1.0 mv_ddr-devel-g4a3dc09 DDR4 16b 1GB 1CS WTMI-devel-18.12.1-a3e1c67 WTMI: system early-init SVC REV: 5, CPU VDD voltage: 1.213V Setting clocks: CPU 1200 MHz, DDR 750 MHz CZ.NIC's Armada 3720 Secure Firmware 14f39dd (Feb 24 2026 19:59:06) Running on ESPRESSObin Ultra NOTICE: Booting Trusted Firmware NOTICE: BL1: v2.14.0(release):1d5aa93 NOTICE: BL1: Built : 19:59:08, Feb 24 2026 NOTICE: BL1: Booting BL2 NOTICE: BL2: v2.14.0(release):1d5aa93 NOTICE: BL2: Built : 19:59:11, Feb 24 2026 NOTICE: BL1: Booting BL31 NOTICE: BL31: v2.14.0(release):1d5aa93 NOTICE: BL31: Built : 19:59:12, Feb 24 2026 U-Boot 2026.01-g127a42c7257a (Feb 24 2026 - 19:57:59 +0000) DRAM: 1 GiB Core: 59 devices, 27 uclasses, devicetree: separate WDT: Not starting watchdog@8300 Comphy chip #0: Comphy-0: USB3_HOST0 5 Gbps Comphy-1: PEX0 5 Gbps Comphy-2: SATA0 6 Gbps Target spinup took 0 ms. AHCI 0001.0300 32 slots 1 ports 6 Gbps 0x1 impl SATA mode flags: ncq led only pmp fbss pio slum part sxs PCIe: Link up MMC: mmc@d8000: 0 Loading Environment from SPIFlash... SF: Detected mx25u3235f with page size 256 Bytes, erase size 4 KiB, total 4 MiB OK Model: Globalscale Marvell ESPRESSOBin Ultra Board MMC Device 1 not found Net: eth0: ethernet@30000 [PRIME] Hit any key to stop autoboot: 0 My attempt to target the drive for boot was using scsi via so: => scsi scan scanning bus for devices... Device 0: (0:0) Vendor: ATA Prod.: ORICO Rev: Y090 Type: Hard Disk Capacity: 976762.3 MB = 953.8 GB (2000409265 x 512) => setenv scsi_fdt_name "/boot/dtb/marvell/armada-3720-espressobin-ultra.dtb" => setenv scsiboot "scsi dev 0; ext4load scsi 0:1 $kernel_addr_r $image_name;ext4load scsi 0:1 $fdt_addr_r $scsi_fdt_name;setenv bootargs $console root=/dev/sda1 rw rootwait net.ifn" => scsi info Device 0: (0:0) Vendor: ATA Prod.: ORICO Rev: Y090 Type: Hard Disk Capacity: 976762.3 MB = 953.8 GB (2000409265 x 512) => run scsiboot Device 0: (0:0) Vendor: ATA Prod.: ORICO Rev: Y090 Type: Hard Disk Capacity: 976762.3 MB = 953.8 GB (2000409265 x 512) ... is now current device 36991488 bytes read in 580 ms (60.8 MiB/s) 13472 bytes read in 6 ms (2.1 MiB/s) ## Flattened Device Tree blob at 06f00000 Booting using the fdt blob at 0x6f00000 Working FDT set to 6f00000 Using Device Tree in place at 0000000006f00000, end 0000000006f0649f Working FDT set to 6f00000 Starting kernel ... [ 0.000000] Booting Linux on physical CPU 0x0000000000 [0x410fd034] [ 0.000000] Linux version 6.12.68-current-mvebu64 (build@armbian) (aarch64-linux-gnu-gcc (Ubuntu 13.3.0-6ubuntu2~24.04) 13.3.0, GNU ld (GNU Binutils for Ubuntu) 2.42) #5 SMP PREE6 [ 0.000000] KASLR enabled Trying again to load from the SATA M/B-key drive, via SCSI, perhaps I'm confusing myself or the SATA is not properly initializing? It looks as if we get pretty far -- if i leave the USB drive plugged in.. but i'm assuming that is taking /dev/sda1, which is why we're not finding a rootfs... but i'm obviously missing how to engage and/or reference the SATA drive, then? [ 3.098515] usb-storage 1-1.1:1.0: USB Mass Storage device detected [ 3.105468] scsi host0: usb-storage 1-1.1:1.0 [ 4.132658] scsi 0:0:0:0: Direct-Access Generic- SD/MMC 1.00 PQ: 0 ANSI: 0 CCS [ 4.484329] sd 0:0:0:0: [sda] 3907584 512-byte logical blocks: (2.00 GB/1.86 GiB) [ 4.492568] sd 0:0:0:0: [sda] Write Protect is off [ 4.498058] sd 0:0:0:0: [sda] No Caching mode page found [ 4.503387] sd 0:0:0:0: [sda] Assuming drive cache: write through [ 4.532225] sda: sda1 [ 4.535092] sd 0:0:0:0: [sda] Attached SCSI removable disk [ 4.549528] FAT-fs (sda1): IO charset iso8859-1 not found [ 4.564748] FAT-fs (sda1): IO charset iso8859-1 not found [ 4.572867] List of all partitions: [ 4.576509] 0100 48000 ram0 [ 4.576522] (driver?) [ 4.582715] 1f00 3968 mtdblock0 [ 4.582724] (driver?) [ 4.589256] 1f01 64 mtdblock1 [ 4.589262] (driver?) [ 4.595906] 1f02 64 mtdblock2 [ 4.595912] (driver?) [ 4.602444] b300 7636800 mmcblk0 [ 4.602450] driver: mmcblk [ 4.609231] b301 7635776 mmcblk0p1 89708921-01 [ 4.609238] [ 4.616022] b308 4096 mmcblk0boot0 [ 4.616027] (driver?) [ 4.622811] b310 4096 mmcblk0boot1 [ 4.622817] (driver?) [ 4.629596] 0800 1953792 sda [ 4.629602] driver: sd [ 4.635695] 0801 1953761 sda1 169d3094-01 [ 4.635701] [ 4.642048] No filesystem could mount root, tried: [ 4.642051] ext3 [ 4.646922] ext4 [ 4.648837] ext2 [ 4.650757] vfat [ 4.652672] xfs [ 4.654592] [ 4.657900] Kernel panic - not syncing: VFS: Unable to mount root fs on "/dev/sda1" or unknown-block(8,1) Pulling the DTB from the drive, and decompiling, i do see SATA references: dtc -I dtb -O dts armada-3720-espressobin-ultra.dtb > armada-3720-espressobin-ultra.dts ... phy@18300 { compatible = "marvell,comphy-a3700"; reg = <0x18300 0x300 0x1f000 0x400 0x5c000 0x400 0xe0178 0x08>; reg-names = "comphy", "lane1_pcie_gbe", "lane0_usb3_gbe", "lane2_sata_usb3"; #address-cells = <0x01>; #size-cells = <0x00>; clocks = <0x04>; clock-names = "xtal"; ... sata@e0000 { compatible = "marvell,armada-3700-ahci"; reg = <0xe0000 0x178>; interrupts = <0x00 0x1b 0x04>; clocks = <0x02 0x01>; phys = <0x1e 0x00>; phy-names = "sata-phy"; status = "okay"; }; But i don't know enough to know why it's not initializing. the 2GB SDA above is clearly the USB drive.

Thanks @bschnei! Yes, using the prebuilt image from your release worked -- the base mmc installation boots fine. And i do have the Espressobin-Ultra model. I still end up stuck in the Armbian (from SATA) build at: [ 1.580359] PM: genpd: Disabling unused power domains [ 1.585946] Waiting for root device /dev/sda1... [ 1.606664] usb 1-1: New USB device found, idVendor=1a40, idProduct=0101, bcdDevice= 1.11 [ 1.614861] usb 1-1: New USB device strings: Mfr=0, Product=1, SerialNumber=0 [ 1.621998] usb 1-1: Product: USB 2.0 Hub [ 1.626711] hub 1-1:1.0: USB hub found [ 1.630668] hub 1-1:1.0: 4 ports detected [ 11.622348] platform d0070000.pcie: deferred probe pending: platform: wait for supplier /soc/internal-regs@d0000000/phy@18300/phy@1 [ 11.634188] platform d00e0000.sata: deferred probe pending: platform: wait for supplier /soc/internal-regs@d0000000/phy@18300/phy@2 [ 11.645998] platform d0058000.usb: deferred probe pending: platform: wait for supplier /soc/internal-regs@d0000000/phy@18300/phy@0 However, putting it together, i'm guessing this is back to your mention of needing 6.15 or later kernel. Which Debian/Armbian hasn't folded in yet? I'll have to look into whether i can fork the Armbian, back-port the kernel patch. The fact that my build environment ended up with the initial issue makes me wonder if that's going to run into similar issues though. Either way, really appreciate all the work you've done in this space, and the help you're providing!

Thanks @bschnei. I tried for a while to figure out what to do, but couldn't really understand.. not sure if i should be trying to set it to thumb or arm mode at that point, even. I did fallback to earlier binutils, and the build went fine. However, trying to boot from the flash-image.bin with mox-imager results in incomplete load and reset back to mmc/spinor ... any ideas? -- /mox-imager/mox-imager -D /dev/ttyUSB0 -t -E /srv/development/espressobin-ultra/2026-03-bschnei/built-on-old-bb/flash-image-20260401-bb.bin TIM version 3.6.00, issue date 2026-04-01, non-trusted, 3 images, 0 keys, boot flash sign SPI NOR Reserved area packages: CRV2 (size 20) CIDP (size 32) Consumer TBRI, packages: GPP1 GPP2 DDR3 GPP1 (size 852) Ignore timeouts in instructions: 0 GPP2 (size 456) Ignore timeouts in instructions: 0 DDR3 (size 2024) Initialize DDR memory: 1 Term (size 8) Found TIMH, hash sha-256, encryption none, size 3780, load 0x20006000, flash 0x00000000 Found WTMI, hash sha-256, encryption none, size 24336, load 0x1fff0000, flash 0x00004000 Found OBMI, hash sha-256, encryption none, size 1140712, load 0x64100000, flash 0x00015000 Going to send images to the device Sending escape sequence, please power up the device Received sync reply Sending escape sequence with delay Detected BootROM command prompt Sending wtp sequence Received ack reply Sending clearbuf sequence Initialized UART download mode GetVersion response: version 3.4.01, date 2016-05-15, CPU ARMA Sending image type TIMH 100% sent in 00:00 TIM-1.0 mv_ddr-devel-g7bcb9dc DDR4 16b 1GB 1CS Sending image type WTMI 100% sent in 00:02 Sending image type OBMI 100% sent in 01:40 [Type Ctrl-\ + c to quit] WTMI-devel-18.12.1-a3e1c67 WTMI: system early-init SVC REV: 5, CPU VDD voltage: 1.213V Setting clocks: CPU 1200 MHz, DDR 750 MHz CZ.NIC's Armada 3720 Secure Firmware v2024.04.15-6-gd6d9646 (Apr 1 2026 16:32:36) Running on ESPRESSObin Ultra NOTICE: Booting Trusted Firmware NOTICE: BL1: v2.14.0(release):sandbox/v2.14-774-g8dae0862c NOTICE: BL1: Built : 16:32:41, Apr 1 2026 NOTICE: BL1: Booting BL2 NOTICE: BL2: v2.14.0(release):sandbox/v2.14-774-g8dae0862c NOTICE: BL2: Built : 16:32:51, Apr 1 2026 NOTICE: BL1: Booting BL31 NOTICE: BL31: v2.14.0(release):sandbox/v2.14-774-g8dae0862c NOTICE: BL31: Built : 16:32:56, Apr 1 2026 U-Boot 2026.04-rc5-00019-gc704af3c8b0f (Apr 01 2026 - 17:08:14 -0400) DRAM: 1 GiB "Synchronous Abort" handler, esr 0x96000044, far 0xd5380000aa1e03fd elr: 0000000000036a08 lr : 0000000000036a64 (reloc) elr: 000000003ff4aa08 lr : 000000003ff4aa64 x0 : 0000000000000098 x1 : d5380000aa1e03fd x2 : 0000000000000000 x3 : 000000003fb07b00 x4 : 0000000000000000 x5 : 0000000000000000 x6 : 0000000000000000 x7 : 000000003fb07b20 x8 : 000000003faff64c x9 : 000000003fb00034 x10: 0000000000000000 x11: 0000000000000600 x12: 000000003faff70c x13: 000000003faff9b0 x14: 000000003faff9b0 x15: 0000000000000000 x16: 0000000000000000 x17: 0000000000000000 x18: 000000003fb03e10 x19: 0000000000000000 x20: 000000003fb07780 x21: 000000003fb077a0 x22: 0000000000000000 x23: 0000000000000000 x24: 0000000000000000 x25: 0000000000000000 x26: 0000000000000000 x27: 0000000000000000 x28: 0000000000000000 x29: 000000003faff7a0 Code: f9405261 f9005274 f81e02a0 f9000681 (f9000034) Resetting CPU ... resetting ... TIM-1.0 WTMI-devel-18.12.1-1a13f2f WTMI: system early-init SVC REV: 5, CPU VDD voltage: 1.213V NOTICE: Booting Trusted Firmware NOTICE: BL1: v1.5(release):e65dc63 (Marvell-devel-18.12.2) NOTICE: BL1: Built : 22:43:22, Mar 4 2026 NOTICE: BL1: Booting BL2 NOTICE: BL2: v1.5(release):e65dc63 (Marvell-devel-18.12.2) NOTICE: BL2: Built : 22:43:25, Mar 4 2026 NOTICE: BL1: Booting BL31 NOTICE: BL31: v1.5(release):e65dc63 (Marvell-devel-18.12.2) NOTICE: BL31: Built : 22 U-Boot 2020.10-6.0.0-g29a6ea5c-dirty (Mar 28 2026 - 21:49:54 -0400) Model: gti cellular cpe board DRAM: 1 GiB Comphy chip #0: Comphy-0: USB3_HOST0 Comphy-1: PEX0 2.5 Gbps Comphy-2: SATA0 6 Gbps Target spinup took 0 ms. AHCI 0001.0300 32 slots 1 ports 6 Gbps 0x1 impl SATA mode flags: ncq led only pmp fbss pio slum part sxs PCIE-0: Link up MMC: sdhci@d8000: 0 Loading Environment from SPIFlash... unrecognized JEDEC id bytes: 61, 12, 9b *** Warning - spi_flash_probe_bus_cs() failed, using default environment Net: Error: neta@30000 address not set. mdio_register: non unique device name 'neta@30000' No ethernet found. starting USB... Bus usb@58000: Register 2000104 NbrPorts 2 Starting the controller USB XHCI 1.00 Bus usb@5e000: USB EHCI 1.00 scanning bus usb@58000 for devices... 1 USB Device(s) found scanning bus usb@5e000 for devices... 2 USB Device(s) found scanning usb for storage devices... 0 Storage Device(s) found Hit any key to stop autoboot: 0 Marvell>>

Hi @bschnei - i'm late to the party, tried using the standard instructions from GTI... Thanks for putting all this together! I'm running into an issue building the A3700, with an error about relocation. dangerous relocation: unsupported relocation Could be related to having LSB set to 1 for safely identifying the relocation target?... based on searches Any hints what I'm missing? -- Built /srv/development/espressobin-ultra/2026-03-bschnei/ebu-bootloader/trusted-firmware-a/build/a3700/release/boot-image.bin successfully make -C wtmi LOCAL_VERSION_STRING=-devel-18.12.1 cp -f ../../mox-boot-builder/wtmi_app.bin build/wtmi_app_pad.bin truncate -s %16 build/wtmi_app_pad.bin make -C sys_init LOAD_OFFSET=15360 COMMON_PATH=/srv/development/espressobin-ultra/2026-03-bschnei/ebu-bootloader/A3700-utils-marvell/wtmi/common CROSS_CM3=arm-linux-gnueabi- CHK autoconf.h UPD autoconf.h AS start.S CC apctl.c CC avs.c CC clock.c CC main.c CC printf.c CC uart.c CC ddr/ddr.c CC ddr/ddrcore.c CC ddr/ddr_support.c CC ddr/dll_tuning.c CC ddr/new_qs_gating.c CC ddr/vref_training.c CC /srv/development/espressobin-ultra/2026-03-bschnei/ebu-bootloader/A3700-utils-marvell/wtmi/common/delay.c CC -nostdlib -T sys_init.ld -Xlinker --build-id=none start.o apctl.o avs.o clock.o main.o printf.o uart.o ddr/ddr.o ddr/ddrcore.o ddr/ddr_support.o ddr/dll_tuning.o ddr/new_qs_gating.o ddr/vref_training.o /srv/development/espressobin-ultra/2026-03-bschnei/ebu-bootloader/A3700-utils-marvell/wtmi/common/delay.o -o build/sys_init.elf /usr/lib/gcc-cross/arm-linux-gnueabi/14/../../../../arm-linux-gnueabi/bin/ld: warning: build/sys_init.elf has a LOAD segment with RWX permissions /usr/lib/gcc-cross/arm-linux-gnueabi/14/../../../../arm-linux-gnueabi/bin/ld: (*ABS*0x1fff0000): Unknown destination type (ARM/Thumb) in main.o main.o: in function `main': /srv/development/espressobin-ultra/2026-03-bschnei/ebu-bootloader/A3700-utils-marvell/wtmi/sys_init/main.c:349:(.text.startup+0x38): dangerous relocation: unsupported relocation collect2: error: ld returned 1 exit status make[4]: *** [Makefile:149: build/sys_init.elf] Error 1 make[3]: *** [Makefile:42: sys_init/build/sys_init.bin] Error 2 make[2]: *** [Makefile:36: WTMI] Error 2 make[1]: *** [plat/marvell/armada/a3k/common/a3700_common.mk:158: /srv/development/espressobin-ultra/2026-03-bschnei/ebu-bootloader/./A3700-utils-marvell/wtmi/build/wtmi.bin] Error 2 make[1]: Leaving directory '/srv/development/espressobin-ultra/2026-03-bschnei/ebu-bootloader/trusted-firmware-a' make: *** [Makefile:28: /srv/development/espressobin-ultra/2026-03-bschnei/ebu-bootloader/./trusted-firmware-a/build/a3700/release/flash-image.bin] Error 2

Did anyone ever figure this out? looks like i have the same problem. GS clarified that NVMe isn't actually supported. I didn't understand but it turns out the formfactor supports many different types of drives. Also the M-Key vs B-Key are so close you can inadvertently install the drive upside down, and it sorta fits. I ended up getting a B+M Key 2280 SATA only drive, and the device worked fine (be sure to install it the correct way!).