[U-Boot-Users] Pull request: u-boot-freebsd

[Rafal Jaworowski]

Haavard Skinnemoen wrote:
>> I fully realize that for developers who's focus is U-Boot, anything
>> that runs on top of U-Boot and that wants something from U-Boot is
>> a burden at times, but it is important to realize that U-Boot is
>> most of the time nothing more than the first step towards a useful
>> machine and that there can be more than 2 steps in getting on OS
>> to run. The ability to make use of the (hardware) knowledge that
>> U-Boot has, and at the same time its ability to abstract it for
>> the next steps, is in my opinion just as important as having its
>> own prompt.
> 
> I agree, but I thought exporting u-boot's hardware knowledge was the
> whole point of the Device Tree (libfdt) stuff?
> 

Well, not all U-Boot platforms use the device tree abstraction: it's only
PowerPC+Linux combination. MIPS, ARM and other archs don't use it, operating
systems other than Linux, to name only *BSD and VxWorks, similar.

> It's not that I'm really objecting to the new interface -- it does seem
> to be more well-designed than the old jumptable stuff -- but it's just
> that I don't understand why you need this functionality in the first
> place, just to be able to boot an OS. When you have a kernel image as
> well as possibly other related images loaded into memory, along with a
> device tree providing detailed information about the hardware, why do
> you need a syscall interface on top of everything?
> 

Let me try to summarize the FreeBSD booting approach:

1. FreeBSD has it's own last stage loader(8)

- it prepares the booting environment for kernel boostrap (the so called
metadata, which mainly inlude kernel env vars, boot flags like single user,
verbose mode and so on)

- it allows to load and unload dynamic kernel modules at this early stage
(even the kernel ELF is treated equally as a big dynamic module itself), set
certain tunables before bootup

- it lets you have menus, startup scripts and similar facilities

- it knows filesystems (UFS, ISO9660 etc.) to retrieve kernel and its modules from

- it's mainly architecture independent and relies on the underlying firmware
to do elementary operations on the console, networking (send and receive
frame), disk (read, write block) etc. In i386 world this is BIOS, on ia64 EFI,
on embedded PowerPC (us :) it is U-Boot and so on

- it provides uniform UI, behaviour and those above features accross all
architectures which FreeBSD supports


2. In order to provide full featured FreeBSD port we brought the loader(8) for
the embedded PowerPC: it runs as a standalone app on U-Boot, and in turn kicks
off the kernel, giving it all native FreeBSD environment described in p.1

Hope that helped explain the scenario a bit.

Rafal