OF boot and kernel devices

OF boot and kernel devices

[Benjamin Herrenschmidt]

Hi !

I'm working on an OF bootloader (mostly made from quik and poof code with
a slice of Darwin's SecondaryLoader) that will do everything we have ever
wanted from an OF bootloader. (My goal is to be able to definitely get
rid of BootX for newworld machines so that the kernel can rely on the
phandle values of the device tree and RTAS).

In order for such a bootloader to work as transparently as possible, the
kernel should be able to correctly configure various OF device path (so
that, after installation, there's no need to go to OF user interface and
edit the path by hand which is a real pain).

This involves several things for which I'd like your points of view:

 - We need to be able to match a given Linux block device with it's Open
Firmware device-tree full path and unit number (when possible). I'm still
wondering what is the best way to do that. I can't think of a solution
that would work without adding a bit of code to every driver, but it
could be a single function call in most cases.
I'm still wondering if we can have the driver somewhat add those infos to
the device tree (we can add a few slots in the device_node structure or
simply add properties, which is probably better). We should then provide
a helper function for ordinary PCI devices that just takes the pci_dev
and major/minor as parameters and which will do the device-tree lookup to
find the device node automatically.
We can also maintain a separate table, and we can have a /proc like
inteface to drivers (seems more complex).
We may also have a separate table in the form of new nodes added the the
kenrel's device tree (may be easier for devices with several units).
We need to retreive those infos from userland, that's why I think adding
things to the device tree.

 - We need to fix the devices names when booting from BootX so that the
device tree contains the full names with the @xxxxxxxx address appended,
like it does with OF.
This is important since the current implementation does weird things when
several devices have the same name. (iBooks for example have 3 "pci"
nodes). I didn't yet find the info about how to build this name
extension, I think it's done from the reg property but there are a few
things to take into account in order to do it right, I would appreciate
some advice.

 - The bootloader will probably have to reside on an HFS partition (at
least for PowerMacs). This would be a small bootstrap partition,
invisible to MacOS, like MacOS X/Darwin uses. The kernel, of course, can
be on an ext2 volume (and I'm also thinking about iso for CD booting).
I'm thinking about putting also the booter config file there, this would
probably be more coherent since the booter won't rely on a specific linux
installation (you can have several roots and choose which one to boot).
Kernel HFS support may have trouble in the near future (2.3.x) but hfs
utils still work fine, don't they ?
Also, I'm thinking about an algorith similar to the one used by Darwin's
bootloader that could scan available devices for bootable partitions. I
still have to experiment a bit with this however.

I'm waiting for your advice, I have done some rought experiments for now,
I'll start real coding on this by this week end.


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: OF boot and kernel devices

[Michel Lanners]

Hi Ben,

On  17 Nov, this message from Benjamin Herrenschmidt echoed through cyberspace:
> I'm working on an OF bootloader (mostly made from quik and poof code with
> a slice of Darwin's SecondaryLoader) that will do everything we have ever
> wanted from an OF bootloader. (My goal is to be able to definitely get
> rid of BootX for newworld machines so that the kernel can rely on the
> phandle values of the device tree and RTAS).

Great! Speaking of quik, the original quik doesn't run on my
G3-upgraded 7600, because of the way BAT registers are set. Paul, did
you ever get around to checking this out? Maybe using the recent
discussion here between David Edelsohn and others?

> In order for such a bootloader to work as transparently as possible, the
> kernel should be able to correctly configure various OF device path (so
> that, after installation, there's no need to go to OF user interface and
> edit the path by hand which is a real pain).

Is this really needed in the kernel? How about running the bootloader
_installer_ in order to configure OF? Once you get to the bootloader
itself from OF, and if you include filesystem code in it, there's no
need to configure anything else than a simple loader config file (à la
quik).

[snip]
>  - The bootloader will probably have to reside on an HFS partition (at
> least for PowerMacs). This would be a small bootstrap partition,
> invisible to MacOS, like MacOS X/Darwin uses. The kernel, of course, can
> be on an ext2 volume (and I'm also thinking about iso for CD booting).
> I'm thinking about putting also the booter config file there, this would
> probably be more coherent since the booter won't rely on a specific linux
> installation (you can have several roots and choose which one to boot).

Yeah, that would make the HFS booter partition acceptable. I guess it
will always be a major pain to get to an HFS partition from Linux, so
make whatever needs to be there as static as possible (no kernels, no
config files).

> Also, I'm thinking about an algorith similar to the one used by Darwin's
> bootloader that could scan available devices for bootable partitions. I
> still have to experiment a bit with this however.

If I remeber correctly, OF 1.05 in the first PC Macs is unable to load
from a specific partition, but rather loads from the first bootable
partition on the specified disk. Therefore, I think that partition
browsing is a must for the bootloader, or you're limited to as much
boot partitions as you have disks.... Which doesn't make booting
various installs easier (think R4/R5, LinuxPPC/YellowDog, maybe
MkLinux...)

> I'm waiting for your advice, I have done some rought experiments for now,
> I'll start real coding on this by this week end.

Happy coding and good luck then!

Michel

-------------------------------------------------------------------------
Michel Lanners                 |  " Read Philosophy.  Study Art.
23, Rue Paul Henkes            |    Ask Questions.  Make Mistakes.
L-1710 Luxembourg              |
email   mlan@cpu.lu            |
http://www.cpu.lu/~mlan        |                     Learn Always. "


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: OF boot and kernel devices

[Benjamin Herrenschmidt]

On Wed, Nov 17, 1999, Michel Lanners <mlan@cpu.lu> wrote:

>Is this really needed in the kernel? How about running the bootloader
>_installer_ in order to configure OF? Once you get to the bootloader
>itself from OF, and if you include filesystem code in it, there's no
>need to configure anything else than a simple loader config file (à la
>quik).

I would prefer avoiding filesystem writes from the bootloader. I'm not
100% sure they work fine in OF (I learned not to rely on OF
functionalities that Apple doesn't use) and, in some cases, the
bootloader will have only readonly fs support (iso, maybe others). 

>Yeah, that would make the HFS booter partition acceptable. I guess it
>will always be a major pain to get to an HFS partition from Linux, so
>make whatever needs to be there as static as possible (no kernels, no
>config files).

As Ethan suggested, we can have to booter config file in /boot, and have
a simple script based on the hfsutils that will copy this to the
bootstrap partition. Not very much different from re-launching quik or
lilo when you change your config anyway.

>If I remeber correctly, OF 1.05 in the first PC Macs is unable to load
>from a specific partition, but rather loads from the first bootable
>partition on the specified disk. Therefore, I think that partition
>browsing is a must for the bootloader, or you're limited to as much
>boot partitions as you have disks.... Which doesn't make booting
>various installs easier (think R4/R5, LinuxPPC/YellowDog, maybe
>MkLinux...)

At first, I'm limiting myself to OF 3.x (newworld machines). Then, I'll
look into back-porting to previous OF versions.


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/