RFC: Booting the Linux/ppc64 kernel without Open Firmware HOWTO (#2)

[Benjamin Herrenschmidt]

On Thu, 2005-05-19 at 23:26 -0500, Hollis Blanchard wrote:
> On May 18, 2005, at 11:56 PM, Benjamin Herrenschmidt wrote:
> >
> >     - name has to be "chosen"
> >     - linux,platform : This is your platform number as assigned by the
> >       architecture maintainers
> 
> Given the seemingly endless embedded boards not developed by "core 
> community" folks, wouldn't it be better for firmware to identify itself 
> with a distributed namespace like "vendor.model" and let the kernel 
> figure out whatever unique number that should be?

This is something I've been thinking about

> Requiring everyone to request a special number from kernel maintainers 
> seems unnecessary. Or perhaps you're trying to enforce tighter 
> development interaction...?

Nope. The platform number is an existing thing, and the kernel isn't yet
completely ready for getting rid of it, though I'd like to. It would be
nice indeed rely only on /model and /compatible (or whatever other
properties).

In fact, the kernel already iterates through ppc_md board structures and
calls a probe() function to select which one to use ! However, all of
them current just test the platform number :)

The reason for that is part historical. We have some code, including low
level assembly code, that tests the platform number for things like LPAR
interaction with an HyperVisor. We also have a bit of platform specific
code that runs very early in things like the parsing of the interrupt
tree or processor node that needs to differenciate between powermac and
pseries due to difference in the way those lay things out.

However, it would definitely make sense to define a single platform
number "PLATFORM_GENERIC" for every new board that doesn't need such low
level interactions (I would expect something like a Xen port to require
a new platform number for the sake of the low level assembly stuff but
not every new embedded board) and fix the remaining places where we
actually test it for things like detecting the northbridge type.

I'll see what can be done after I finish version 3 of the proposal which
already contains a lot of changes and associated kernel patches :)

Ben.