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

[Hiroyuki Machida]

Hi Ben,
I've switch to Gmail account.

2007/1/11, Benjamin Herrenschmidt <benh at kernel.crashing.org>:
>
> >  - 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.

>From the Linux Live DVD/Install DVD developer's view, it's better to
have a single common format, independent from back ends.
If we have various config formats, Linux Live DVD/Install DVD need to
have all corresponding config files on one DVD.

Is there any objection? If anyone doesn't have. We'll  move to discuss
what is desirable for "common" config file, such as, "kboot.conf is a
good for common coifig file?/Grub config is better?".

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

This would be covered by Geoff's E-mail.

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

>From the Linux Live DVD/Install DVD developer's view, it's better to have
common minimal environments. For instance, suppose that someone makes
Live Linux on USB flash, the developer expect to boot loader has capable
to boot it.

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

We'll bring it up inside in Sony.
- 引用テキストを表示しない -

> 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.
>
>
> _______________________________________________
> cbe-oss-dev mailing list
> cbe-oss-dev at ozlabs.org
> https://ozlabs.org/mailman/listinfo/cbe-oss-dev
>