| title: | Re RFC PATCH Device Tree on ARM platform |
|
On Wed, May 27, 2009 at 10:20 AM, Robert Schwebel
<r.schwebel@xxxxxxxxxxxxxx wrote:
That being said, the problems we have had are the reason why it is
*not* recommended to hard link the device tree image into firmware.
We do commit to not breaking old trees, but the ability to update is
important; particularly for enabling new features/drivers.
Point taken.
We often have the situation that we have
- a SoC cpu from vendor A
- a module with the cpu+ram+peripherals from vendor B
- a baseboard from vendor C
- sometimes an extension board from vendor D
All that with non-introspectable busses, like chip select busses, SPI,
i2c, FPGA-internal busses etc. We recently tried to put oftree sniplets
into the devices (one into the module, one in the baseboard etc), let
u-boot collect these sniplets and build an oftree out of it. It doesnt
work. If you try this, youll quickly find out that you would have to
put the schematics into the oftree. A peripheral pin can be routed to a
ball, goes from a connector of the module to a baseboard, to the
extension board, come back and go to another unit on the SoC. This
cannot be described in the oftree. At one place, you need to *know*
about the whole hardware that you have and have a single "we have X" to
"Xs oftree" mapping.
Indeed, and it relies on encoding too much knowledge into the
firmware... code which may change.
In the end, having a single "X needs these platform data" kernel source
file is much, much cleaner and less error prone than what we currently
have with the oftree.
What about a single device tree blob for each particular
configuration? The .dtb isnt intended to solve the probing problem.
Its intended to solve the problem of describing your board design (or
board stack in your case).
- The oftree layering is fundamentally broken. We already have a sane
abstraction for arbitrary hardware in the kernel: platform devices.
Why not instanciate platform devices from a generic oftree core?
No; the oftree is a data structure. That is it, nothing more.
Unfortunately, it is an incomplete data structure regarding to what the
kernel needs.
I dont follow your argument. Its a data structure that uniquely
describes your hardware in a way which encourages the most code reuse
possible; but is still independent of kernel internal implementation.
ie. a FDT blob should be usable not just by Linux, but also by BSD or
any of the other OS options. It is not an attempt to eliminate
platform specific code; just to reduce it as much as possible. Weird,
harry, non-standard stuff probably still needs board specific code to
handle.
- Platform data makes it possible to store function pointers. There
is no equivalent to this concept in oftree-land.
But there is concept of platform specific code. In the majority of
cases platform specific function pointers arent needed at all. In
the cases where they are; platform devices can still be used.
In this case, they need an equivalent to a "machine number" information.
Yes. In the device tree weve been using the root nodes compatible
or model property.
oftree could be a great tool if these things would be resolved.
Currently they are not, and in result, ARM just works and is easy,
whereas on PowerPC systems people often spend more time working on
binding stuff than on the actual functionality.
Thats a rather polarizing statement and I dont think its fair. The
FDT is not a magic bullet. It makes aspects of platform independence,
code sharing, and board porting simpler, but it is also requires
forethought and has overhead associated with it. I dont think anyone
is proposing to require all ARM platforms to use the FDT approach.
Sorry, it was not meant to be offending, it just reflects a certain
level of frustration.
Dont take me wrong: I consider the *idea* behind oftree a good one. It
just has unsolved problems. If we manage to turn this discussion into
something that accelerates things into a good direction, Im all with
you.
:-)
Understood. So far I think things are going well, at least nobody has
yet suggested doing something biologically improbable. :-P
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
-------------------------------------------------------------------
List admin: rel="nofollow" lists.arm.linux.org.uk/mailman/listinfo/linux-arm-kernel lists.arm.linux.org.uk/mailman/listinfo/linux-arm-kernel
FAQ: rel="nofollow" www.arm.linux.org.uk/mailinglists/faq.php www.arm.linux.org.uk/mailinglists/faq.php
Etiquette: rel="nofollow" www.arm.linux.org.uk/mailinglists/etiquette.php www.arm.linux.org.uk/mailinglists/etiquette.php
|
