Page MenuHomeFreeBSD

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

Authored by mmel on Jan 11 2018, 2:57 PM.
Tags
None
Referenced Files
Unknown Object (File)
Fri, Dec 6, 1:43 AM
Unknown Object (File)
Oct 24 2024, 9:56 PM
Unknown Object (File)
Oct 18 2024, 10:16 AM
Unknown Object (File)
Oct 12 2024, 3:24 PM
Unknown Object (File)
Sep 20 2024, 4:28 PM
Unknown Object (File)
Aug 31 2024, 7:33 AM
Unknown Object (File)
Aug 18 2024, 5:24 AM
Unknown Object (File)
Aug 18 2024, 5:24 AM

Details

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.

Diff Detail

Repository
rS FreeBSD src repository - subversion
Lint
Lint Skipped
Unit
Tests Skipped

Event Timeline

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

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.

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.

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'.

Rebased to current, renamed UBOOT_BOOT_API to LINUX_BOOT_API

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?

This revision was not accepted when it landed; it landed in state Needs Review.Dec 7 2019, 4:14 PM
This revision was automatically updated to reflect the committed changes.