@y52 very cool!

Hello to regular contributors and everybody who are interested in this issue! I am late to the thread, as I had to decommission my production setup based on Espressobin V5 before trying everything out. Finally I've completed Physical-to-Virtual migration using QEMU and made board available for this new experience. @bschnei made a great job and his developments are community available. It was also worth for me making my findings accessible for general public thus improving Espressobin support. I forked @bschnei repo https://github.com/bschnei/ebu-bootloader to my Github https://github.com/quiseleve/espressobin-bootloader and made several changes to build bootloaders for Espressobin V5 and V7. Here are the final changes brought to @bschnei repo : root@nanopi-r5s:/mnt/nvmep2/espressobin/ebu-bootloader# git remote add upstream https://github.com/bschnei/ebu-bootloader.git root@nanopi-r5s:/mnt/nvmep2/espressobin/ebu-bootloader# git fetch upstream From https://github.com/bschnei/ebu-bootloader * [new branch] main -> upstream/main root@nanopi-r5s:/mnt/nvmep2/espressobin/ebu-bootloader# git diff --stat upstream/main...main .github/workflows/build.yml | 92 ++++++++++++++++++++++++++++++++++++++++++--------------------------------- Makefile | 2 ++ patches/0001-fix-tfa-fip-build-behavior.patch | 36 +++++++++++++++++++++++++++++ 3 files changed, 90 insertions(+), 40 deletions(-) This allowed building bootload firmware directly in Github's Workflow and trying them out over UART 1st before flashing it to onboard SPi. ./mox-imager -D /dev/ttyUSB0 -b 3000000 -E flash-image-v5_2GB.CPU_1000_DDR_800.bin Although Workflow run builds both v5 and v7 variants, I tested 2Gb RAM v5 board, as my 1Gb v7 is currently in production, but there is a high confidence level, that v7 works as well. DDR_TOPOLOGY variable used for my specific v5 motherboard : Memory Type: DDR3 Total Capacity: 2 GB Bus Width: 16-bit Chip Selects (CS): 2 (Dual CS) It is worth saying that I built initially the 1.2GHz bootloader, but it appeared worthless, as my physical silicon turned out to be limited to 1GHz only. I found it by retrieving a 32-bit hex string for v5 board : => md 0xd0012604 1 d0012604: 19896301 .c.. => This hex string gives us the definitive answers we need. In the Marvell Armada 3720 architecture, this specific register reads from the factory OTP (One-Time Programmable) fuses. The lower bits define the chip's official Speed Bin Index: 0 = 800 MHz Maximum 1 = 1000 MHz (1.0 GHz) Maximum 2 = 1200 MHz (1.2 GHz) Maximum Because my board register ends in 01, my specific SoC is officially rated by the factory for a maximum clock speed of 1000 MHz (1.0 GHz). This completely explains why the WTMI secure firmware threw the invalid voltage error when I forced a 1.2 GHz build. The chip physically lacks the factory-fused voltage calibration profile for the 1.2 GHz tier because it wasn't born as a 1.2 GHz chip. Thus I decided changing the Build Target to 1.0 GHz. More discussions could be found here as well : I've also built Armbian-unofficial 26.5.2 sid image to assess overall compatibility. Here is an excerpt from initial boot logs directly from the bootloader initiation : TIM-1.0 mv_ddr-devel-g7bcb9dc DDR3 16b 2GB 2CS WTMI-devel-18.12.1-f423ac6 WTMI: system early-init SVC REV: 3, CPU VDD voltage: 1.155V Setting clocks: CPU 1000 MHz, DDR 800 MHz CZ.NIC's Armada 3720 Secure Firmware v2024.04.15 (Jul 9 2026 20:33:31) Running on ESPRESSObin NOTICE: Booting Trusted Firmware NOTICE: BL1: v2.14.0(release):sandbox/v2.14 NOTICE: BL1: Built : 20:33:33, Jul 9 2026 NOTICE: BL1: Booting BL2 NOTICE: BL2: v2.14.0(release):sandbox/v2.14 NOTICE: BL2: Built : 20:33:35, Jul 9 2026 NOTICE: BL1: Booting BL31 NOTICE: BL31: v2.14.0(release):sandbox/v2.14 NOTICE: BL31: Built : 20:33:36, Jul 9 2026 U-Boot 2026.04-dirty (Jul 09 2026 - 20:32:03 +0000) DRAM: 2 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 SATA link 0 timeout. 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 w25q32dw with page size 256 Bytes, erase size 4 KiB, total 4 MiB OK Model: Globalscale Marvell ESPRESSOBin Board Net: eth0: ethernet@30000 Hit any key to stop autoboot: 0 MMC Device 1 not found no mmc device at slot 1 switch to partitions #0, OK mmc0 is current device Scanning mmc 0:1... Found U-Boot script /boot/boot.scr 1664 bytes read in 25 ms (64.5 KiB/s) ## Executing script at 06d00000 144 bytes read in 19 ms (6.8 KiB/s) 28134196 bytes read in 1702 ms (15.8 MiB/s) Wrong Image Type for bootm command ERROR -91: can't get kernel image! 37059072 bytes read in 2231 ms (15.8 MiB/s) 18537158 bytes read in 1121 ms (15.8 MiB/s) 12062 bytes read in 35 ms (335.9 KiB/s) ## Loading init Ramdisk from Legacy Image at 0a000000 ... Image Name: uInitrd Image Type: AArch64 Linux RAMDisk Image (gzip compressed) Data Size: 18537094 Bytes = 17.7 MiB Load Address: 00000000 Entry Point: 00000000 Verifying Checksum ... OK ## Flattened Device Tree blob at 06f00000 Booting using the fdt blob at 0x6f00000 Working FDT set to 6f00000 Loading Ramdisk to 7d940000, end 7eaeda86 ... OK Loading Device Tree to 000000007d93a000, end 000000007d93ff1d ... OK Working FDT set to 7d93a000 Starting kernel ... Loading, please wait... Starting systemd-udevd version 261.1-2 Begin: Loading essential drivers ... done. Begin: Running /scripts/init-premount ... done. Begin: Mounting root file system ... Begin: Running /scripts/local-top ... done. Begin: Running /scripts/local-premount ... Scanning for Btrfs filesystems done. Begin: Will now check root file system ... fsck from util-linux 2.42.2 [/sbin/fsck.ext4 (1) -- /dev/mmcblk0p1] fsck.ext4 -a -C0 /dev/mmcblk0p1 armbi_root: clean, 28918/949664 files, 425190/3849216 blocks done. done. Begin: Running /scripts/local-bottom ... done. Begin: Running /scripts/init-bottom ... done. Welcome to Armbian-unofficial 26.5.2 sid! [ OK ] Created slice system-getty.slice - Slice /system/getty. [ OK ] Created slice system-modprobe.slice - Slice /system/modprobe. [ OK ] Created slice system-serial\x2dgetty.slice - Slice /system/serial-getty. [ OK ] Created slice user.slice - User and Session Slice. [ OK ] Started systemd-ask-password-console.path - Dispatch Password Requests to Console Directory Watch. [ OK ] Started systemd-ask-password-wall.path - Forward Password Requests to Wall Directory Watch. [ OK ] Set up automount proc-sys-fs-binfmt_misc.automount - Arbitrary Executable File Formats File System Automount Point. Expecting device dev-ttyMV0.device - /dev/ttyMV0... [ OK ] Reached target imports.target - Image Downloads. [ OK ] Reached target remote-fs.target - Remote File Systems. [ OK ] Reached target slices.target - Slice Units. [ OK ] Reached target swap.target - Swaps. [ OK ] Listening on syslog.socket - Syslog Socket. [ OK ] Listening on systemd-ask-password.socket - Query the User Interactively for a Password. [ OK ] Listening on systemd-creds.socket - Credential Encryption/Decryption. [ OK ] Listening on systemd-factory-reset.socket - Factory Reset Management. [ OK ] Listening on systemd-hostnamed.socket - Hostname Service Socket. -- Boot 3e598d120dc346829e12f836344429a1 -- Jul 11 00:11:05 espressobin kernel: Booting Linux on physical CPU 0x0000000000 [0x410fd034] Jul 11 00:11:05 espressobin kernel: Linux version 6.12.95-current-mvebu64 (build@armbian) (aarch64-linux-gnu-gcc (Ubuntu 13.3.0> Jul 11 00:11:05 espressobin kernel: 5:185m5:185mKASLR disabled due to lack of seed Jul 11 00:11:05 espressobin kernel: Machine model: Globalscale Marvell ESPRESSOBin Board Jul 11 00:11:05 espressobin kernel: efi: UEFI not found. .. Jul 11 00:11:05 espressobin kernel: armada_37xx_wdt d0008300.watchdog: Initial timeout 120 sec Jul 11 00:11:05 espressobin kernel: advk-pcie d0070000.pcie: host bridge /soc/pcie@d0070000 ranges: Jul 11 00:11:05 espressobin kernel: advk-pcie d0070000.pcie: MEM 0x00e8000000..0x00efefffff -> 0x00e8000000 Jul 11 00:11:05 espressobin kernel: advk-pcie d0070000.pcie: IO 0x00efff0000..0x00efffffff -> 0x0000000000 Jul 11 00:11:05 espressobin kernel: advk-pcie d0070000.pcie: issuing PERST via reset GPIO for 10ms Jul 11 00:11:05 espressobin kernel: mvneta d0030000.ethernet end0: renamed from eth0 .... This bootloader seems to deliver many if not all of its promises to name few of them: cpu frequency scaling is operational : root@espressobin:~# cpupower frequency-info analyzing CPU 1: driver: cpufreq-dt CPUs which run at the same hardware frequency: 0 1 CPUs which need to have their frequency coordinated by software: 0 1 maximum transition latency: 1000 us hardware limits: 200 MHz - 1000 MHz available frequency steps: 200 MHz, 250 MHz, 500 MHz, 1000 MHz available cpufreq governors: conservative ondemand userspace powersave performance schedutil current policy: frequency should be within 200 MHz and 1000 MHz. The governor "ondemand" may decide which speed to use within this range. current CPU frequency: 250 MHz (asserted by call to kernel) Entropy and random number generation (RNG) issue seems to have been resolved as bschnei's ebu-bootloader fork explicitly includes patches to fix this. The ebu-bootloader patches bypass the OS entirely and tackle the problem before Linux even starts. When Linux kernel boots, it immediately detects this perfect cryptographic seed provided by U-Boot and uses it to instantly initialize the OS-level Cryptographic Random Number Generator (CRNG). Here are my kernel ring buffer timestamps: root@espressobin:~# dmesg | grep -E "crng|random" [ 11.785705] systemd[1]: Starting systemd-random-seed.service - Load/Save OS Random Seed... [ 13.071384] random: crng init done [ 13.398576] systemd[1]: Finished systemd-random-seed.service - Load/Save OS Random Seed. The bootloader and kernel working together fixed the entropy pool in exactly 13.07 seconds from the moment the Linux kernel started executing. Because crng init done happened before the systemd service even finished writing to the disk, it proves the kernel didn't just rely on slow user-space disk jitter. The hardware security engine initialized almost immediately. Because the ebu-bootloader fork compiled correctly patches, the underlying Trusted Firmware-A (TF-A) and the secure processor (WTMI-devel), the hardware crypto mailboxes are wide open and working perfectly the moment Linux asks for them. You don't even need haveged or any software workarounds. Your hardware is resolving its own entropy natively in just over a second from user-space initialization! U-Boot UEFI Support is out of the box as well. I am booting seemlessly both legacy OS (from my old production setup) as well as a new OS build which I used for this testbed root@espressobin:~# cat /etc/debian_version forky/sid root@espressobin:~# uname -a Linux espressobinv5 6.12.95-current-mvebu64 #1 SMP PREEMPT Sat Jul 4 11:43:36 UTC 2026 aarch64 GNU/Linux

hello, for s905w2 is this rom working?

this post started 2023 & some engineers told that armbian does not support S905W2 . its 2026. ... did someone try ? for s905w2 does this rom well work? please tell me "YES" bc i need a armbian for S905w2 @SteeMan @Devmfc

hello. i read top post & ....S905w2... I need a armbian for s905w2 can i use this rom ? link