bschnei

The initrd might be missing needed drivers for you to continue getting console output. Kind of a pain to troubleshoot that. The kernel I linked above is configured so that it should actually boot with no initramfs at all (though that isn't recommended). It obviously can't hurt to try a different PSU if you have one. The device also will do PoE (on the WAN port I believe) which is a nice little feature so you could try that too. The device tree I use comes directly from the linux tree. It is built into U-Boot and then U-Boot provides it to the kernel via standard location as specified in UEFI. It is entirely possible that older kernels might be unhappy with a newer device tree but you really shouldn't be having any issues with 6.18 and newer but they do need to be configured to load the device tree from UEFI. I think that kernel config option is CONFIG_OF.

I see. Well I can confirm my bootloader is very stable. I have been running it on two devices for a couple years now without any issues. It cannot hurt to flash it again (to rule out random bitflips), but if you are getting sporadic crashing no matter the kernel/OS it does start to indicate a hardware issue. I have a laptop that crashes sporadically but it isn't so bad that I cannot use it. I've run memtest on it countless times without issue, tried replacing RAM, etc. some devices really are just cursed for whatever reason unfortunately. In case it is helpful, you can find the config for the kernel I run on my devices here: https://github.com/bschnei/linux-a3700

> Timing issue might occur in DDR mode I get every boot so that should indeed be ignored. What do you mean by timing issue? I could build you a bootloader clocked at 800Mhz instead of 1.2Ghz if that is what you are referring to?

I'm not sure I follow. You have the factory OS (debian IIRC) on EMMC still and it is stable?? But Armbian on M2 does not boot and/or is unstable? My setup has U-Boot loading systemd-boot via UEFI which then loads kernel. I also use Standard Boot so my entire bootcmd is simpy "bootflow scan -b". No complicated scripting. No loading things and calculating memory addresses. Moving away from all of that mess is really the primary motivation for building the firmware for this device in the first place. It is really nice--the only time I ever have to interact with u-boot is when I need to flash the firmware.

Hmm that doesn't look great. It looks like it is crashing at random places vs the same place every time. It makes you wonder if you have a true hardware problem (e.g. bad memory). Can you never make it to a login prompt? I would double check all your memory locations for the FDT, ramfs and kernel to make sure you aren't accidentally overlapping anywhere. And yes, I would avoid starting anything at 0. I actually found a kernel bug from doing that. You could also consider trying to load the kernel as an EFISTUB directly. I don't know if that's supported by armbian or not, but you could experiment. You do know you can save u-boot variables to the SPINOR storage so you don't have to type them in every time, right?

Oh I see now. I've had problems using root=/dev/sdX. I would try to use UUIDs which you should be able to query with blkid. But I doubt that is going to fix the above. I suspect the drivers needed to boot from NVME are probably not being loaded. That could mean they are not being compiled (either built in or as modules) OR if built as modules they are not being included in your initramfs. Actually...I don't see that you are loading an initramfs. Again, I'm not familiar with armbian but many distros rely on an initramfs to provide needed drivers for early userspace. I have one device with a NVME and one without. Booting from either MMC or NVME does work with the right config/initramfs. I would include your full u-boot config and all kernel boot messages. You can attach them instead of putting in the body of the post. There may be other subtle/cryptic warnings that indicate a driver is missing.

@KV1 nice! So I think the kernel is saying it can "see" /dev/sda1 but that whatever filesystem you've got on that partition it does not recognize and could not mount after trying fat, ext4, and xfs. Are you sure /dev/sda1 has been formatted/imaged correctly? That looks like it's a USB thumb drive, right? If so, I would plug it into another working host and check that it is properly formatted and does indeed contain the intended root file system you'd like to boot. Where is /boot? /dev/mmcblk0p1?

@KV1 I'm happy I'm able to help. I got a lot of help originally from @Pali and by the time we sorted out that the bootloader was the problem it seems that people have largely given up on these devices. It is a shame because they are actually quite good routers (except the wifi). You are actually the first person with an Ultra to reach out. OK, that's looking good. It means the bootloader image works for you and you should be safe to flash it if you want. The messages you posted above are indeed kernel output. To be clear, you don't have to have a more recent kernel to get the device to boot, but DVFS (frequency scaling) may not work without the patch to enable 1.2Ghz clock speed. If you run a kernel without that patch, everything will still work it will just run at full speed all the time which isn't very energy efficient. You are now at the stage where you have to consider how Armbian configures and packages the kernel for this device and ensure that your U-Boot configuration is using a supported boot flow. For example, U-Boot can support loading the kernel as an UEFI image directly (EFISTUB) among many other variations. The messages you posted above suggest that the device tree that is getting loaded may be incorrect/old and I would probably start by examining that. I don't know much about Armbian, but @Igor may also be able to point you in the right direction. Feel free to post your u-boot configuration here too as that could provide some insight into the boot process being used.

@KV1 nice work! Looks like it made it to U-Boot before it died. Instead of building your own, have you tried to see if it boots using a release image built with a github runner here: https://github.com/bschnei/ebu-bootloader/releases/tag/2026.02.24. Even if you want to eventually build it yourself, you could just test to see if the image built at github works. If it does, and you know the source code is the same (it looks like you are building an -rc of U-Boot) then you can narrow it down to the compiler tools you are using. Just to confirm: this is for an EspressoBIN Ultra right? Not the V7/V5 or some other variant?

Hi @KV1 looks like you are hitting this issue: https://github.com/MarvellEmbeddedProcessors/A3700-utils-marvell/issues/35 As you can see, Marvell is not very active in these repos. So you have two choices: 1) use older binutils/gcc (probably the easiest option), or 2) fix the issue with the source code. The fixes I'm seeing look simple enough to implement, and I will likely need to include them in the future when/if I update the github runners used to build releases. See also: https://community.arm.com/support-forums/f/compilers-and-libraries-forum/57077/binutils-2-44-and-gcc-15-1-0---dangerous-relocation-unsupported-relocation-error-when-trying-to-build-u-boot https://lists.denx.de/pipermail/u-boot/2025-May/589102.html

Hi @Anto, Igor has built that version if you look in his post above: https://forum.armbian.com/applications/core/interface/file/attachment.php?id=15377&key=f234d69d5a19f0081fdad46abb21cc36

I can confirm the above `flash-image-DDR4-1g_1cs_5-1200_750` image boots to U-Boot on the ESPRESSObin Ultra. I wasn't able to test past that because U-Boot isn't being built with Standard Boot enabled (which I use): WTMI-devel-18.12.1-a3e1c67 WTMI: system early-init SVC REV: 5, CPU VDD voltage: 1.260V Setting clocks: CPU 1200 MHz, DDR 750 MHz CZ.NIC's Armada 3720 Secure Firmware d6d9646-dirty (Nov 5 2025 09:00:30) Running on ESPRESSObin Ultra NOTICE: Booting Trusted Firmware NOTICE: BL1: v2.12.8(release):95bbf00da NOTICE: BL1: Built : 09:02:55, Nov 5 2025 NOTICE: BL1: Booting BL2 NOTICE: BL2: v2.12.8(release):95bbf00da NOTICE: BL2: Built : 09:02:56, Nov 5 2025 NOTICE: BL1: Booting BL31 NOTICE: BL31: v2.12.8(release):95bbf00da NOTICE: BL31: Built : 09:02:56, Nov 5 2025 serial_mvebu serial@12000: pinctrl_select_state_full: uclass_get_device_by_phandle_id: err=-19 U-Boot 2025.10_armbian-2025.10-Se50b-P3205-H05ce-V9535-Bbf55-R448a (Nov 05 2025 - 09:00:02 +0000) DRAM: 1 GiB Core: 48 devices, 24 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 down MMC: sdhci@d0000: 0, sdhci@d8000: 1 Loading Environment from SPIFlash... SF: Detected mx25u3235f with page size 256 Bytes, erase size 4 KiB, total 4 MiB OK Model: Globalscale Marvell ESPRESSOBin Board Net: eth0: ethernet@30000 [PRIME] Hit any key to stop autoboot: 0 Flags not supported: enable CONFIG_BOOTSTD_FULL bootflow - Boot flows Usage: bootflow scan - boot first available bootflow If you enable Standard Boot and want me to test again, happy to. Cheers!

Thank you! I'm still in the middle of a long build (chromium). I'll be able to check the flash-image-DDR4-1g_1cs_5-1200_750 image with the specific device I own with frequency scaling enabled and report if it is stable or not. It will crash pretty reliably if the firmware doesn't have the change I submitted here: https://github.com/MarvellEmbeddedProcessors/mv-ddr-marvell/commit/622677674cf34ef8fdf75b0c580d27efc8628ae8

Thanks @laibsch but, as I noted above, the mirror links there don't work for me. I can only offer to help with bootloader testing here. It's not clear to me how I would build only that component from https://github.com/armbian/build.

OK, where would we find the images that need testing?