Re: Question: Might loader.kboot use be appropriate for booting RPi5's without U-Boot? (as an example)

I totally misunderstood the loader.kboot build. It was probably wishful thinking, and I think maybe loader.kboot might not be the best way to get to a good official RPi5 FreeBSD binary distribution.

What I think I want is

RPI5 Firmware
\--> FreeBSD loader hiding in a bootable zipped Linux kernel image file
\--> FreeBSD.

What I think needs to be done is

- figuring out how to build a FreeBSD loader image that RPi5 Firmware will happily try to boot
- figuring out how to get that loader to find, and load the DT setup that RPi5 firmware provides, apply additional DT changes as needed
- fixing any remaining bugs from the memory map if that didn't solve Mark's kernel boot error
- working through remaining issues with FreeBSD FDT kernel until we can use critical path devices like USB and PCIe block devices and console (and probably also the thermal/fan) reliably
- fixing remaining FDT device driver issues for all the other drivers.

I think EDK2 stuff is cool, and it was certainly a critical enabler, but I suspect everyone would be happier with one less thing that can break. I think I want to try making loader do what's needed.
On Saturday, September 12th, 2026 at 6:38 PM, Warner Losh <imp@bsdimp.com> wrote:

> On Sat, Sep 12, 2026 at 4:23 PM Mark Millard <marklmi@yahoo.com> wrote:
>
>> On 9/11/26 10:21, Jeremy McMillan wrote:
>>>
>>>
>>> I was planning to crack this nut open this weekend with some research on the current state of loader.kboot and smoke testing the RPi5 boot targeting loader.kboot.
>>>
>>> I see this as a stepping stone to proper supportable FDT kernel on RPi5, and also ideas about how to best manage custom overlays. Eventually, I want to get to a point where I can plug an I2C ADC chip module into RPi5, put together an overlay, and get a usable audio input device when I boot FreeBSD, for example.
>>>
>>> So, if I may follow up Mark's question, what stumbling blocks am I likely to hit first, and is there any advice inuring from past struggles that might help me out?
>>
>> If I gather from Warner's reply to my note correctly, the
>> sequencing/flow issues would be something like (for example):
>>
>> RPi5 Firmware -> Host Linux Kernel -> loader.kboot -> FreeBSD kernel
>>
>> would not populate the information that the FreeBSD kernel needs.
>>
>> RPi5 Firmware -> EDK2 (UEFI/DeviceTree style) -> Host Linux Kernel ->
>> loader.kboot -> FreeBSD kernel
>>
>> It would populate the information but the FreeBSD kernel then has the
>> basically same problems it has for the original:
>>
>> RPi5 Firmware -> EDK2 (UEFI/DeviceTree style) -> FreeBSD kernel
>>
>> Thus, involving Host Linux Kernel -> loader.kboot is to no advantage for
>> this type of context.
>>
>> Also, there would be no point for inserting such into:
>>
>> RPi5 Firmware -> EDK2 (UEFI/ACPI style) -> FreeBSD kernel
>
> Yes. LinuxBoot is for when you only have a linux kernel to launch from,
> and the vast majority of those cases you have a tiny sliver of EDK2
> or similar that then loads the linux kernel as its first device driver
> and takes over from there (so the board integrator doesn't have to
> write two versions of board integration software, just one: Linux).
>
>> even if the insertion worked: no advantage to the insertion.
>
> I'm not seeing one for this use case, but who knows... If you really
> wanted, you would have to investigate whatever interface Linux uses
> to boot early and put that directly into the FreeBSD kernel, but then
> you lose all the /boot/loader functionality.
>
> Warner
>
>> (EDK2 could be an over specific example for the general structure.)
>>
>>> ---
>>> JTM
>>>
>>> -------- Original Message --------
>>> On Friday, 09/11/26 at 11:39 Mark Millard <marklmi@yahoo.com> wrote:
>>> Hello Warner,
>>>
>>> This is just an informational query for my background knowledge.
>>>
>>> Note: I'm not dealing here with the FreeBSD kernel having support for
>>> RPi5 DeviceTree content or the RP1 based structure or such.
>>>
>>> Context:
>>> Various Linux distributions boot the RPi* families that they support
>>> directly, no U-Boot or EDK2 or the like, including booting the RPi5 that
>>> way. For the RPi5, they support, for example, USB booting and such that
>>> U-Boot still does not support.
>>>
>>> That forms an example of a more general question of if loader.kboot and
>>> such a linux kernel would be a viable alternative to the normal FreeBSD
>>> U-Boot port style of support for aarch64?
>>>
>>> (As stands the RPi5 draft EDK2's provide a DeviceTree mode alternative
>>> to ACPI mode for Linux booting. The EDK2's are not as limited as U-Boot
>>> is for what is supported for booting [so far].)
>>>
>>> --
>>> ===
>>> Mark Millard
>>> marklmi at yahoo.com
>>>
>>>
>>>
>>>
>>>
>>
>> --
>> ===
>> Mark Millard
>> marklmi at yahoo.com