[Cbe-oss-dev] PS3 Linux boot loader discussions

Benjamin Herrenschmidt benh at kernel.crashing.org
Thu Jan 11 10:43:22 EST 2007


>  - A bootloader for PS3 Linux needs to meet following conventions, if
>   it supports bootable media.
> 
>  1)  path name of boot config file
>    /etc/kboot.conf on media

For the graphical bootloader, we are thinking about having several
"backends" that detect and parse multiple known config file types. One
is kboot.conf, but it's too limitative for what we want.

We want the ability to have human readable titles & subtitles for boot
options with multiple languages support, we want the ability to provide
icons (.png only for now) for the various choice and for the bootable
media itself, etc...

It's not clear yet wether we'll implement this via a new config file
format, which I'd like to avoid, or by simply using the grub config file
format and adding fields for optional new features we have.
 
>  2) algorithm to detect bootable media
>    - A bootloader will recognize the media is bootable when
>    /etc/kboot.conf is found.

In our case, when any of the recognized config files is found.

>    - Priority of bootable media is up to boot loader implementation.

We also want to have some way to "remember" user choices (among other
things, we also want a way to setup the default video mode for example).
It's not clear yet how we'll uniquely identify bootable medias, we'll
probably use a mecanism that supports several methods (fs uuid if
available, fallback to fs label, maybe device uuid if it exists).

For that, we want to start defining a proper tagged format for the
content of the "nvram" flash, so that bootloader, linux, distro bits
etc... can all use that space without walking on each other toes. I
haven't had time to write a formal proposal for that yet though I do
have some ideas based on a list of { vendor,tag,size,data... } .
 
>  3) Bootloader config file format
>    - Bootloader config file format allows kboot.conf documents.
>    However shell specific rich functions like back quote are not be
>    supported for future possible kboot replacement.
> 
>  4) Bootable media type and it's format
>    - Supported bootable media types are up to boot loader implementation.
>    - When bootloader supports following media type, it needs to
>      support corresponding Std. format at least.

Anything that the kernel can mount in fact. Jeremy started experimenting
with a mecanism to hook on udev to get notifications of any new device
and send that to the front-end.

Another thing I want to do is modify the ps3 storage driver so it can be
configured to not wait, but instead, just dynamically register new disks
as they become available in the HV. I don't know if there's a way to get
notified via an interrupt of a device becoming available or being
removed, but if not, we'll do some simple polling of the lv1 registry
every second or so.

Most distro nowadays have initramfs that can perfectly "wait" for the
chosen root fs to be available, and thus we would significantly speed up
the boot process by using that.

Ben.





More information about the cbe-oss-dev mailing list