[Skiboot] OPAL Spec and conformance

Nathan Whitehorn nwhitehorn at freebsd.org
Thu Jun 11 14:12:36 AEST 2015

On 06/10/15 16:58, Stewart Smith wrote:
> Nathan Whitehorn <nwhitehorn at freebsd.org> writes:
>> On 06/10/15 15:43, Stewart Smith wrote:
>>> Hi all,
>>> This is something I'm sending both to the System Software Workgroup at
>>> OpenPower fonudation and the skiboot list as it's relevant to both
>>> audiences.
>>> SYSSW people: note that the skiboot list is *public* to the world.
>>> There is a need to have an OPAL Specification as part of the OpenPower
>>> effort along with a conformance test suite.
>>> Goal:
>>> - OPAL API specification (including device-tree)
>>>     - i.e. what host OS interacts with
>>> - spec for petitboot environment
>>>     - i.e. how you can boot an OS, what filesystems/device drivers are
>>>     supported.
>> [...]
>>> - come up with a plan to document and standardize petitboot environment
>>>     - (i.e. what can you boot from. XFS? ext4?)
>> One thing that would be *extremely* helpful here is an environment to
>> run a second-stage loader. We need this for FreeBSD for a variety of
>> reasons, mostly that the boot loader is responsible for loading kernel
>> modules according to scripts rather than having a prefab initrd.
>> On petitboot systems, the way this works now is that we ship a Linux ELF
>> executable on a FAT32 filesystem that does all the right things and then
>> calls kexec itself. This works fine except that you have to exit to a
>> shell and run it by hand since there is no way to put something in the
>> petitboot menu that does not get kexec'ed.
> This is all useful to know... is it basically a "load all modules into
> memory locations and then jump somewhere?"

It does a couple of things. The main thing it does is to load all 
modules and the kernel somewhere, then construct a metadata blob with 
(a) device information on where the root filesystem lives, (b) where all 
the modules ended up, and (c) boot arguments to the kernel. It also 
loads some scripts from the root filesystem to provide an interactive 
environment and can do TCP/IP and NFS and such for netbooting. The root 
filesystem it loads things from is typically either UFS or ZFS.

> I have to admit a fair bit of ignorance on how freebsd boots from, say
> GRUB or OpenFirmware (on x86 or power).

The usual way the kernel loads is from the boot loader described above, 
which typically uses various firmware runtime services (OF client 
interface, BIOS calls, U-boot API, UEFI runtime interface, etc.) to prod 
at devices. The Petitboot/OPAL stack doesn't provide any similar API, so 
the loader there is a userland Linux program that speaks Linux syscalls 
and then calls kexec_load() and reboot() instead of just jumping into 
the kernel.

For people who choose to use GRUB, GRUB has some special purpose code 
that does the same things the FreeBSD loader does. On most platforms, 
including Open Firmware, you can also load the kernel directly without 
the loader, but you then have to specify the root file system 
interactively at boot and can't rely on modules to get to the root 
filesystem, so it provides a poorer user experience. Usually, this only 
happens for embedded systems.

More information about the Skiboot mailing list