Re: [RFC] [PATCH] Device Tree on ARM platform

[Jon Smirl]

On Wed, May 27, 2009 at 5:05 PM, Grant Likely <grant.likely@xxxxxxxxxxxx> wrote:
> On Wed, May 27, 2009 at 2:52 PM, Mark Brown
> <broonie@xxxxxxxxxxxxxxxxxxxxxxxxxxx> wrote:
>> On Wed, May 27, 2009 at 08:29:10PM +0100, Russell King wrote:
>>> On Wed, May 27, 2009 at 02:08:42PM -0500, Scott Wood wrote:
>>
>>> > I'm not talking about platform specific code, I'm talking about code to
>>> > retrieve information about a device from the device tree.  There would
>>> > not be separate instances of this for "platforms X, Y and Z", just one
>>> > of_platform binding in each driver.  It's no different than having a
>>> > platform bus binding, except in the data structures used.
>>
>>> I really don't see what OF buys us then, apart from additional dependencies
>>> that have to be correct for the kernel to work.  I can only see disadvantages
>>> if all OF is, is a way to pass some file to the kernel to (effectively) tell
>>> it which drivers to use.
>>
>> The main selling points of the device tree AFAICT are that some
>> platforms have to use it it anyway due to the native OS and firmware for
>> the platform use it, the possibility of using the same device tree with
>> more than one OS (modulo unrepresentable holes) and the fact that some
>> people find it more convenient to use than straight data tables
>> (personally I find the two approaches to be much of a muchness there).
>> Perhaps I'm missing something, though?
>
> Here are some that I've find useful:
>
> There is the advantage that it decouples the machine description from
> the kernel code, which in turn seems to encourage code reuse.  There
> has been a significant decrease in the amount of platform specific
> code in powerpc since the switch to FDT booting.

I agree with this. I have observed the same thing.

>
> There is the advantage of easy multiplatform support.  I regularly
> build a single kernel image which boots on all my MPC5200 boards, and
> on my MPC83xx boards.  Because the machine description is a separate
> image blob, and not hard compiled into the kernel, the kernel doesn't
> have to be explicitly told what boards it may possibly be booted on
> (other than turning on the appropriate drivers; handled with modules,
> just like on x86).  It may not be much of an advantage for current
> deployed systems, but it is a huge win during development and
> testing....

I am routinely booting four different mpc5200 systems off from the
same NFS tree and the same kernel image. These four mpc5200 system
have quite different capabilities. There are different audio codecs,
PCI/no-PCI, ATA/no-ATA, SD cards, RAM, flash (some 8b others 16b),
they don't even have the console on the same serial port. I build a
single kernel and test it on all four of these systems. The device
tree customizes each kernel at boot time to support the right
hardware.

We want to use this capability in the field. A single update can
services multiple versions of the hardware.

> That being said, I've been told that Motorola has shipped phones with
> FDT support in the kernel for exactly the reason of booting a single
> kernel image on multiple versions of the device.
>
> g.
>
> --
> Grant Likely, B.Sc., P.Eng.
> Secret Lab Technologies Ltd.
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@xxxxxxxxxxxxxxx
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
>



-- 
Jon Smirl
jonsmirl@xxxxxxxxx
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/