ESPRESSObin Firmware/Bootloader

[bschnei]

In case it is useful to anyone in this community, I have been working on updating the bootloader for the ESPRESSObin Ultra which ships from Globalscale with old, buggy, and unmaintained firmware.

https://github.com/bschnei/ebu-bootloader

I believe with some small modifications, it is possible to also build an up-to-date bootloader for other Globalscale devices that also use the Armada 37XX SoC, for example the ESPRESSObin V7 which is listed as a supported device for Arch Linux ARM.

One of the key issues that has been fixed is EFI booting from U-Boot. Fixing this means we can use U-Boot Standard Boot (bootflow scan) to load user-friendly EFI apps like systemd-boot, GRUB, etc. which can then be configured by the distribution instead of requiring users to manually configure U-Boot.

[khaledez]

Thank you for this work.

[Sergeanter]

I have successfully compiled and flashed uboot to Espressobin V7 following instructions on Trusted Firmware here: [url]https://github.com/ARM-software/arm-trusted-firmware/blob/master/docs/plat/marvell/armada/build.rst[/url]
The current version is 2024.07. There were two packages missing on my Debian laptop that I had to install from repository to fix build errors: libncurses-dev and libtinfo-dev.

I just manually applied this patch by Bodhi to address slow spin-up of WD drive in USB3 enclosure:
[url]https://forum.doozan.com/read.php?3,35295,35322#msg-35322[/url] .The file to edit is ~/u-boot/common/usb-storage.c
It was originally for Kirkwood but I guess it would help any ARM platform with Uboot to cope with slow external USB drives.
After increasing delay to re-try, the drive gets detected in USB2 port but in USB3 port I still get a message "Disk usb_mass_storage.lun0 not ready". I have tried to trace it in source code and it may show up because the drive I connect is not for EFI booting, just a regular ext4 10TB drive for backup.
Can you guys put instructions how to switch from linux-espressobin to linux-aarch64 here? Either EFI or regular image.
I thought my problem with wrong image format was due to old Uboot but I am not completely sure.

[bschnei]

Hi Sergeanter, that's great you were able to build a working bootloader from source--it is not a small undertaking.

Regarding kernel packages, I only tried to use linux-aarch64 once many months back on my ESPRESSObin Ultra, and it didn't work out-of-the-box for me. That package is going to conflict with linux-espressobin because of the way both packages want to install the kernel to /boot/Image. Because I wanted the capability to install multiple kernels, neither of these packages was going to work for me.

Beyond just using pacman to install one or the other package, you will need to check your U-Boot configuration since that will determine what kernel, initramfs, and device tree are loaded at boot. If you paste your configuration, I might be able to help you. Note that there is a package here that is meant to help configure u-boot: uboot-espressobin, but I wouldn't recommend using it. I would recommend adjusting the configuration stored to NVRAM.

FWIW, I package my own kernel for this device:make_clickable_callback(MAGIC_URL_FULL, ' ', 'https://github.com/bschnei/linux-a3700', '', ' class="postlink"') While I use it for the Ultra variant of the device I believe it will work just fine for the V7. This package will only modify your /boot partition if you are using systemd-boot to manage your boot partition. IOW, if you don't use systemd-boot my package should not conflict with other kernel packages here. It will install the kernel image to /usr/lib/modules/Image and leave it up to you to configure how you want U-Boot to load it.

My personal setup is to use systemd-boot to manage a boot partition that is FAT formatted and set as the EFI System Partition. U-Boot then only needs to be configured to chainload systemd-boot from that partition (which it can do using U-Boot's bootflow scan command which requires no configuration). Then I never have to modify U-Boot configuration when I upgrade kernels. U-Boot always loads systemd-boot and systemd-boot is configured from linux userspace (i.e. not u-boot over serial console) and the filesystem.

[Sergeanter]

Hi bschnei,
I have tried to install mainline kernel. Pacman uninstalled linux-espressobin , replaced Image and put new initramfs-linux.img while removing initramfs-linux.uimg.
The box did not boot and I figured I only needed to change ramdisk name in uboot environment . However it did not boot the 2nd time either , saying that image had wrong format. At that point I thought either uboot was too old ( it was 17.10) or the whole boot procedure must have changed ( to use boot.scr) . I had a glimpse of how they boot Macchiatobin and it is using boot.scr instead of uEnv.txt.
Since I use the box as a NAS at home I have restored mmc backup and put this on hold.
The reason I want to try a newer kernel is to run bcache with mdadm RAID5 (dont ask why) I had for years that became too slow for 4K video.
linux-espressobin was having problems with nvme SSD that someone reported working with espressobin.

[bschnei]

I think your problem might be that u-boot wants the ramfs to be formatted by mkimage which is part of the u-boot-tools package.

The following pacman hook is responsible for creating that .uimg file for the linux-espressobin package:make_clickable_callback(MAGIC_URL_FULL, '
', 'https://github.com/archlinuxarm/PKGBUILDs/blob/master/core/linux-espressobin/91-linux.hook', '', ' class="postlink"')

You'll see the command takes the initramfs generated by mkinitcpio at /boot/initramfs-linux.img and generates /boot/initramfs-linux.uimg. Your ramfs location in u-boot needs to point to the .uimg file--not the .img file.

See the Arch ARM u-boot configuration for this device here for reference:make_clickable_callback(MAGIC_URL_FULL, ' ', 'https://github.com/archlinuxarm/PKGBUILDs/blob/master/alarm/uboot-espressobin/uEnv.txt#L6', '', ' class="postlink"')

Yes, you could configure boot.scr too but then you'll have a configuration file that isn't part of an Arch Linux ARM package.

Given that you have updated the bootloader with a recent version of u-boot, EFI booting should work for you, and I recommend using it because you are much more likely to continue to find some community support for this device because it will be easier to support as part of the Arch Linux Ports project:make_clickable_callback(MAGIC_URL_FULL, ' ', 'https://rfc.archlinux.page/0032-arch-linux-ports/', '', ' class="postlink"')

[Sergeanter]

I am not having much luck with linux-aarch64. It looks like after installing linux-aarch64 what mkinitcpio does is quite different . It does not generate initramfs-linux.uimg but generates initramfs-linux-fallback.img , which is what is to be used with boot.scr. I could not quite figure what directory the hook that you shared would go to in order to fix this . Would it be /etc/initcpio/install or /etc/initcpio/post for example?
I have generated initramfs-linux.uimg manually using mkimage command from the file you pointed to. After adding this file uboot did not complain about uimg anymore but did not use it either. Then the error message was
** Reading file would overwrite reserved memory.
Failed to load ''/boot/Image'
When I tried booti manually, the message was
Bad Linux ARM64 Image magic!

I am guessing addresses in environment need to be updated but how does one calculate the offsets?

[bschnei]

pacman hooks are installed here: /usr/share/libalpm/hooks/ permake_clickable_callback(MAGIC_URL_FULL, ' ', 'https://wiki.archlinux.org/title/pacman#Hooks', '', ' class="postlink"')

The linux-espressobin package is installing it's own custom pacman hooks that trigger mkinitpio to run to generate initramfs-linux.img and then mkimage to generate initramfs-linux.uimg. That is these files:
make_clickable_callback(MAGIC_URL_FULL, '
', 'https://github.com/archlinuxarm/PKGBUILDs/blob/master/core/linux-espressobin/90-linux.hook', '', ' class="postlink"')make_clickable_callback(MAGIC_URL_FULL, '
', 'https://github.com/archlinuxarm/PKGBUILDs/blob/master/core/linux-espressobin/91-linux.hook', '', ' class="postlink"')

In contrast, linux-aarch64 uses the pacman hook that gets installed as part of mkinitcpio per this comment:make_clickable_callback(MAGIC_URL_FULL, '
', 'https://github.com/archlinuxarm/PKGBUILDs/blob/master/core/linux-aarch64/PKGBUILD#L101-L102', '', ' class="postlink"')

You'll find that hook (90-mkinitcpio-install.hook) in the same hooks directory. As you've already discovered, that hook will not build the .uimg file for you so if you want to switch to linux-aarch64 you will have to customize your configuration (e.g. by writing your own hooks). You are basically going down the same rabbit hole I did which is why I ultimately built my own kernel package.

As to what mkinitcpio generates, that is controlled by "presets". In the case of linux-aarch64 that is this file:make_clickable_callback(MAGIC_URL_FULL, ' ', 'https://github.com/archlinuxarm/PKGBUILDs/blob/master/core/linux-aarch64/linux.preset', '', ' class="postlink"')

So when you install linux-aarch64, mkinitcpio should generate *both* /boot/initramfs-linux.img and /boot/initramfs-linux-fallback.img. The fallback image is just a larger initramfs that doesn't try to autodetect which modules you have loaded. As a result it is larger in size. More info on that here:make_clickable_callback(MAGIC_URL_FULL, ' ', 'https://wiki.archlinux.org/title/Mkinitcpio#Automated_generation', '', ' class="postlink"')

But it will not generate the .uimg version of those ramdisks which is the format u-boot is expecting. So regardless of which initramfs you want to use (you are probably safe using the non-fallback version), you will have to always run mkimage to build the version formatted for u-boot on every kernel upgrade and/or upgrade to mkinitcpio.

IMHO, mkinitcpio packaged for ARM is a clunky version of mkinitcpio for x64. The way it's patched, it doesn't elegantly support multiple kernel installs. If you poke around on these forums you'll see quite a few threads reporting issues. If you are wiling to move to EFI booting, you may be able to eliminate the initramfs entirely, unless you need to use features like full disk encryption. This is yet another reason I packaged my own kernel.

So if you used the larger -fallback version of the initramfs then, yes, it's entirely possibly you've loaded the initramfs to a location in memory that would cause it to overwrite other things in memory. The simplest thing may be to use the non-fallback version, but the linux-aarch64 kernel is also a general kernel that is likely compiled to support a larger number of devices which will mean a much larger kernel and initramfs. So yes, you will want to check that your load addresses for the kernel, device tree, and initramfs give them all enough space to not run over each other.

The address values in u-boot configuration are in hexadecimal form so you want to convert them to decimal to interpret where in addressable memory space they are. You can use an online calculator or spreadsheet functions. So if we use the example here:make_clickable_callback(MAGIC_URL_FULL, ' ', 'https://github.com/archlinuxarm/PKGBUILDs/blob/master/alarm/uboot-espressobin/uEnv.txt', '', ' class="postlink"')

kernel_addr=0x2000000
ramdisk_addr=0x1100000
fdt_addr=0x1000000

Those values map to 32MB (33554432 bytes), 17MB (17825792 bytes) and 16MB (16777216 bytes) respectively. This is a terrible layout because it only leaves 32-17 = 15MB for your initramfs. If your initramfs is larger than that (which it almost certainly is if you use the -fallback version) then you will overwrite the spot in memory where the kernel was loaded. Most likely that is what is going on. This headache is yet another issue that is solved by moving to EFI booting.

[Sergeanter]

Thanks a lot for your time writing this. I will give it another shot. I probably need to clear environment and load default and then uEnv.txt as too much lint accumulated.