bschnei

@KV1 I've fixed the build issue above: https://github.com/MarvellEmbeddedProcessors/A3700-utils-marvell/pull/36. I don't think anyone at Marvell pays attention to this old repo anymore so I don't expect it will actually be merged.

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?

Hey @Igor, is there new bootloader firmware built as a result of your changes? I can probably do a quick test at some point (I've got a large build underway on one of my devices). This page is probably in need of work: https://www.armbian.com/espressobin/ the download links don't seem to work for me (they redirect to mirrors.aliyun.com)

@0jay the work I've done on the firmware is here: https://github.com/bschnei/ebu-bootloader. Looks like MOCHAbin is an Marvell Armada 88F7040. I believe with the correct changes to configuration, you can build firmware with my scripts. There is another user here with ESPRESSObin v7 and v5 devices that may try to build firmware using my scripts as well:

To build for other devices, you need to figure out the correct configuration and adjust these values accordingly: https://github.com/bschnei/ebu-bootloader/blob/main/Makefile#L15-L19 Reference for configuration options is here: https://trustedfirmware-a.readthedocs.io/en/latest/plat/marvell/armada/build.html So for V7 you probably want DDR_TOPOLOGY of 5 or 6 depending on RAM size; for V5 a value of 2. You'll have to look up your defconfig in u-boot. It's probably this one: https://github.com/u-boot/u-boot/blob/master/configs/mvebu_espressobin-88f3720_defconfig but note that I have added an ultra variant here: https://github.com/u-boot/u-boot/blob/master/configs/mvebu_espressobin_ultra-88f3720_defconfig which has settings required to provide HWRNG to the kernel at boot. So you may way want to start with the default if it is known to work and experiment with your own configuration file. You know how to test an image without flashing it to SPINOR, right? I have a guide at my repo above. Regarding Armbian and device support in general, there is another thread here where I had some back and forth a while back:

DVFS has been working well for me on two devices for over a year now. Linux accepted my patch to re-enable 1.2Ghz in 6.15. I build my own Arch packages, but I started with ALARM. I didn't like the way they packaged the kernel and it wasn't being maintained. There are a few of us working on bringing Arch to aarch64. You'll find us on IRC. Libera.chat #archlinux-ports The ALARM project is a completely independent project of Arch Linux (despite the confusing name). I have no issues with random number generation. It was actually fixed by this project: https://gitlab.nic.cz/turris/mox-boot-builder which builds one component of the bootloader. So I use that project (instead of Marvell) for that part of the bootloader.

@0jay I'm sorry I never got a notification for your response here for some reason. I have two ESPRESSObin Ultra devices humming along just fine with no issues, everything working as far as I can tell, no patches to U-Boot or Linux needed. I'm not familiar with the Mochabin. Did you experience issues with it as well out-of-box?

Hi @y52, I've been using the bootloader builds from my repo above on my ESPRESSObin Ultra for quite some time now. Not only do they have up-to-date U-boot, but frequency scaling works perfectly. I'm not very familiar with the V5 and V7 variants, but I think the V7 has the same CPU (possibly different memory). > hostnamectl Static hostname: espressobin-ultra Icon name: computer-embedded Chassis: embedded Machine ID: 2ba0ba22c6164c Boot ID: 514bc8387b7847 Operating System: Arch Linux Kernel: Linux 6.17.3-1-a3700 Architecture: arm64 Hardware Vendor: globalscale Hardware Model: Globalscale Marvell ESPRESSOBin Ultra Board Firmware Version: 2025.10-ge50b1e871501 Firmware Date: Wed 2025-10-01 Firmware Age: 1month

Suggests you don't have the 64-bit ARM cross compiler installed or the location of its executable is not on PATH.

Thanks for the taking the time to provide this additional context! If full device support (i.e. including bootloader) is the goal, that is indeed an ambitious one. I'll do what I can to offer bootloader related support where I can in the forums here, but my advice to everyone is generally going to be to move to UEFI/U-Boot Standard Boot (`bootflow scan`). Some of the U-Boot scripting I've seen to try and support all of the possible combinations of hardware and potential removable storage is just too clunky. When users show up with devices that won't boot, it's a true nightmare to try to support. As a result, any configuration where U-Boot loads additional configuration from a storage device (vs its dedicated SPINOR) is always going to problematic because they vary across devices in the same mvebu family and users may want to change them (e.g. boot partition on USB device vs EMMC or SATA). In short, U-Boot should ideally only chainload a userspace configurable bootloader (systemd-boot, GRUB, etc.) that can be more easily updated/packaged and supported.

No disagreement @Igor. I wouldn't recommend any distro attempt to maintain device-specific support for this family of devices. Especially because there is a pathway to UEFI booting which does allow these devices to be supported by generic kernel packages. I also feel that it shouldn't land on any Linux distribution to be expected to provide support for bootloaders. As a result, I was impressed by the amount of effort I saw around this device and sympathize with how you and the Armbian team must feel. I would, however, caution against letting that frustration spill over into resentment of your user base (or potential user base). I'm not familiar with Armbian's philosophy and what the expectations are between users and maintainers/developers. At Arch Linux the philosophy and expectation is extremely DIY/self-support oriented and those expectations are made very clear. However, that can come across as rude/off-putting to people who show up looking for help. And when you have a volunteer effort (which by definition means you are chronically under-resourced), that kind of philosophy/approach can scare away potential future volunteers/contributors. And obviously if a volunteer project can't attract/retain new contributors then it's just a matter of time before it's dead. Anyone considering Arch Linux ARM for this family of devices would be wise to read this thread: https://bbs.archlinux.org/viewtopic.php?id=290931 Personally, I throw most of the blame for the state of these devices on Globalscale and Marvell. The CPU frequency scaling debacle that seems to actually be related to an improperly configured bootloader all along seems to have burnt everyone out so people moved on to other devices. The one silver lining is the open source bootloader. With frequency scaling no longer an issue and UEFI supported, there really is no technical reason these devices can't be supported: ben@ebu-dev:~$ sudo hostnamectl Static hostname: ebu-dev Icon name: computer-embedded Chassis: embedded Operating System: Arch Linux ARM Kernel: Linux 6.9.9-1-a3700 Architecture: arm64 Hardware Vendor: globalscale Hardware Model: Globalscale Marvell ESPRESSOBin Ultra Board Firmware Version: 2024.04-dirty Firmware Date: Mon 2024-04-01 Firmware Age: 3month 2w 3d It is, as you correctly note, a question of time/effort. I'm not super familiar with this distribution and community and don't want to step on anyone's toes. If the generic kernel packages provided here are still being configured to support these devices and the only obstacle is how to fix/configure the bootloader, then that's where I am offering to share my experience. But anyone that wants to get Armbian running on their mvebu device is going to have to be willing to put in the work to at least get their hands dirty messing with U-Boot and potentially even building/flashing a more modern bootloader.