barebox works great on NXP's i.MX platforms. While there is some support for Marvell's mvebu platform, it is not even near being complete. The main limitation is in my eyes that there is no code to initialize RAM settings on these machines.

On mvebu the native bootable image consists of (usually) two parts. A so-called binary header and a main image. The first one is responsible to setup RAM and after that the boot ROM copies the main image to RAM and jumps into it. Up to now (as of barebox 2019.06.0) you have to dissect a working "vendor image" (usually U-Boot), get the binary header from it and reuse this for barebox. This is ugly for several reasons: It complicates compilation and license conformance and so lacks all the nice properties of open source software.

During the annual Pengutronix Techweek I resolved to work on this shortcoming. My plan was to borrow the code to setup RAM from vanilla U-Boot to get my Turris Omnia run barebox. Back in 2017 I already worked on this machine and was able to chain load barebox from U-Boot which is a good condition to work on native booting.

In the end there were too many obstacles however and I ended up doing preparatory work only:

• debug and repair second stage booting (commit 1, commit 2)
• rewrite mvebu image tool to take all relevant parameters via the command line (commit)
• fix barebox' build system to rebuild the final image when the binary header changed (commit)
• some research why booting via UART is not as reliable as it should be.

Even when I come around to port the RAM init sequence to barebox there is still much to do to make barebox useful on Turris Omnia. Fixing networking, access to SATA and flash and adding support for btrfs (which is used in the vendor firmware) will keep me busy for some time.