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

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/

Relevant Pages

  • Re: [RFC] [PATCH] Device Tree on ARM platform
    ... But mach-type could not handle variants well and it doesn't tell the kernel about info about attached peripherals. ... The device-tree used by powerpc and sparc could simplifiy board ports, less platform specific code and simplify device driver code. ... Please reference to Grant Likely and Josh Boyer's paper, A Symphony of Flavours: Using the device tree to describe embedded hardware, for the detail of device tree. ... The FDT format is all in network-byte-order, ...
    (Linux-Kernel)
  • Re: [RFC] [PATCH] Device Tree on ARM platform
    ... not be separate instances of this for "platforms X, Y and Z", just one ... platform bus binding, except in the data structures used. ... that have to be correct for the kernel to work. ... The main selling points of the device tree AFAICT are that some ...
    (Linux-Kernel)
  • Re: [RFC] [PATCH] Device Tree on ARM platform
    ... This is a MPC5200 is the posterchild for device tree wreckage; ... an FPGA with all the devices instantiated in the FPGA fabric. ... changes from the kernel image. ...  abstraction for arbitrary hardware in the kernel: platform devices. ...
    (Linux-Kernel)
  • Re: [PATCH 1/4] Blackfin: arch patch for 2.6.18
    ... to the kernel from the mtd medium, ... architecture if that means that you have to leave holes like setup. ... You seem to have lots of these machine specfic header files in include/asm. ... probably be either 'subarchitecture' or 'platform' in your code. ...
    (Linux-Kernel)
  • Re: [RFC] [PATCH] Device Tree on ARM platform
    ... That is not necessarily an advantage of a device tree. ... also build a kernel which runs on 20+ PXA platforms at the same time. ... different in subtle details which can not be probed or enumerated by ... variant turns out to be the long term favourite solution. ...
    (Linux-Kernel)