From mboxrd@z Thu Jan 1 00:00:00 1970 From: Benjamin Herrenschmidt Date: Fri, 20 May 2005 15:04:10 +1000 Subject: [U-Boot-Users] Re: RFC: Booting the Linux/ppc64 kernel without Open Firmware HOWTO (#2) In-Reply-To: <2806b111f694b5dff9ae70aefc8f9029@penguinppc.org> References: <1116400151.918.10.camel@gaston> <1116478614.918.75.camel@gaston> <2806b111f694b5dff9ae70aefc8f9029@penguinppc.org> Message-ID: <1116565451.5153.95.camel@gaston> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de 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.