Add support for booting FreeBSD kernel directly from U_Boot using booti command.

[mmel]

Summary

In some cases, like is locked bootstrap or device's inability to boot from
removable media, we cannot use standard boot sequence and is necessary to
boot kernel directly from U-Boot.

[andrew]

Previously I've created a simple loader to create the module data & loaded the kernel as an initrd image.

[mmel]

Yep, I known. But my actual situation with Jetson TX1 board is more complicated.

• the TX1 firmware can only load U-Boot for eMMC.
• shipped U-Boot doesn't support EFI
• on OS start, U-Boot modifies DTB (it excludes memory used by secure monitor and PSCI,, it modifies the pinmux table so that it matches the current setting), it stored trained settings for DDR4 controller for various memory frequencies...)

So I think that I cannot solve this problems with your simple loader.

[andrew]

You didn't describe any reason it wouldn't work. Rather than the kernel as the first argument to booti, it would be the second, after either passing it through mkimage, or loading it as a raw file with a size.

An alternative is to use the kernel shim in loader to allow you to use the kernel device drivers to load the kernel from UFS/ZFS.

[mmel]

In D13861#290576, @andrew wrote:

You didn't describe any reason it wouldn't work. Rather than the kernel as the first argument to booti, it would be the second, after either passing it through mkimage, or loading it as a raw file with a size.

mkimage, imho, is not supported(or not preferred - it have bundled load address inside) on arm64, but this is not important yet.

Sure, I can wrote whole new "non-interactive, load from memory" loader, with all of pain of self-relocating code, but why?
Result will be less flexible (because you need more exact addresses) that this. Assuming that machdep_boot.c is clear candidate for inter-platform unification, the proposed change is pretty small and easy. We already can (even is this not a preferred way) to boot FreeBSD directly from U-Boot on arm, mips, risc-v and powerpc so why is this bad for arm64 ?
This change doesn't break the 'single kernel policy', same kernel can be used for 'standard' loader or for booti based boot.

Don't take me bad, I only don't want to repeat my fiasco with Jetson TK1 where I'm not able to provide bootable image for last 2 years. And booti based boot is probably most simple way how i can do it (on TX1) - simple FAT partition on SD card with containing kernel.bin, tegra DTB and extlinux.conf script solves all my issues. Moreover, it give me possibility to do similar boot flow on (TX1 based) Nvidia TV shield which uses fastboot/android bootloader without scripting.

An alternative is to use the kernel shim in loader to allow you to use the kernel device drivers to load the kernel from UFS/ZFS.

No, this is not a option. We cannot do single I/O operation directly from this 'simple loader'.

[manu]

Reading https://github.com/torvalds/linux/blob/master/Documentation/arm64/booting.txt it should be LINUX_BOOT_ABI and not UBOOT_BOOT_ABI

[mmel]

Rebased to current, renamed UBOOT_BOOT_API to LINUX_BOOT_API

[siddharthtuli_gmail.com]

This patch provides an important functionality to boot FreeBSD on arm64 platforms directly from U-Boot. Are there plans to commit this patch to upstream?