Device Tree Evolution Project - call notes - 23rd October

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]



Hey folks,

I'm sharing the notes from our regular meeting that was held this
Wednesday. Olof joined us this week and we had a lively discussion
around our two main topics: System DT and a new/shared repo for DT
data.

Attendees
=========

SteveM - Arm
RobH - Arm
ArndB - Linaro
MathieuP - Linaro
VincentG - Linaro
VickyJ - Linaro
KumarG - Linaro
IliasA - Linaro
DonH - Linaro
BillF - Linaro
BruceA - Xilinx
StefanoS - Xilinx
TomasE - Xilinx
SaravanaK - Google
BillM - TI
TrilokS - Qualcomm
OlofJ  - FB

Notes
=====

Discussion ongoing on System DT
-------------------------------

SS: Grant had meetings with Stefano (Stabellini).

    All changes must stand on their own. Same with the bindings.
    Needs to be written in a way that it is consistent and works. Need
    to support a default e.g. using both cpu cluster and cpu node

    Might need a new bus definition other than a simple bus for things
    which do/do not go to the default node.

    Next step - writing down the bindings in a careful way (better
    than first draft) for cpu cluster and simple bus type. i.e. take
    all the configuration since that’s a separate discussion.

    Will send to system device tree and then after feedback send a v2
    to the spec.

    Nathalie setting up the list under OpenAMP. Need to start
    discussing on the list.

RH: Can we just use the Devicetree spec list - not a lot of traffic on
    it.

SS: Wanted initially to confirm that had actually understood. Was
    thinking only one revision would be sent to the spec list.

RH: Spec list is not just for adding to the spec.

OJ: purpose to describe system from different views (2 cores, FPGA)

SM: Yes

OJ: DT built around address space view. May e.g. be behind an IOMMU -
    how to do without tearing up DT

TE: Idea behind System Devicetree. Backward compatible way to handle
    different domains. Hard to have the discussion about complex cases
    on a general mailing list since have to keep re-explaining. A lot
    of people don’t care about heterogeneous processing. Hence to have
    initial discussion on the System DT list. Suggest to try to
    converge initially before.

OJ: Also document the assumptions so people can read up on the doc.

RH: This situation arose because Olof has joined and past discussion
    not captured.

TE: We should publish notes (was sent out in an email so far). Should
    have a place we can point people to. Grant is out unfortunately.

SM: Should be back next week (Tuesday)

TE: Will set up follow up meeting on System Devicetree.

SS: Last presentation at SAN19 Connect (video) would be a great
    starting point. OpenAMP landing page?

TE: Yes - I’ll talk to Nathalie.


Discussion ongoing about approaches for shared DT repo
------------------------------------------------------

SM: Know that there are concerns from Rob and Olof about workflows if
    we start pulling things out of the kernel.

OJ: Fundamental question - DTs are configuration files. Work on the
    problem of how the files are generated rather than where they are
    stored. Also trying to fix hand coded DTs. Then solve the problem
    for everyone.

TE: At Xilinx we have a DT checked in but people are not using
    that. Appreciate other people have a DT per board. We have to go
    through tooling to generate the DT. At the moment it’s
    proprietary.

OJ: Don’t need to make a more complex text format, just be able to
    instantiate multiple views in the simple format. See DT as
    assembly language. Think this would avoid having to persuade the
    kernel people to take the pain.

AB: Still would need to have a higher level representation. DTS format
    is obscure - adding more complexity to it may be a
    problem. Struggling to think of another source format that could
    replace it?

OJ: … Python ??? Have generators for the code and stubs that consume
    it.

OJ: Have the situation where the board is a minor DTS. A generator
    would pull it in as a dependency. Could do this in a high level
    tool. Would need a place to merge these descriptions. Do it in one
    place where everyone shares it.

SM: Still need a place where someone is in charge. Don’t see how it
    solves the problem. Still have the problem of how you describe the
    board/peripherals etc. Still needs to be encoded somehow. Same
    issues.

OJ: some of the same issues are still there. Start with 1 or 2 SoCs …
    bootstrapping. Dependencies - end up with a common library of
    devices and the binding is known - base addr/ interrupts etc

RH: Same questions as Arnd. Still need information stored and what do
    you add to it. Another part - how to separate user configurable
    stuff from fixed things.

OJ: Don’t think the tool wants to run on every machine …

RH: Look at what settings are tuned per board rather than fixed for an
    SoC.?

TE: From Xilinx point of view - all customers make their own
    boards. Tooling has 1 device tree with SoC architecture., board
    vendor creates a specification file for mapping SoC to board, and
    the vendors description of the board and then a separate file for
    what’s implemented in the FPGA fabric.

RH: Have this to some extent for everything.

OJ: Have in mind something similar to what Xilinx has but maybe not
    split up in different places. If changing a binding for a
    peripheral don’t want to patch 200 files where it’s used.

SM: People are keen on Overlays - suppose could do a similar thing
    with such a tool.

OJ: Could definitely but solves other problems of keeping details for
    boards etc. Shouldn’t hold it back.

AB: think the overlay problem can be solved in 2 ways. don’t need to
    limit ourselves to one approach.

OJ: Shouldn’t constrain the tool to being embeddable. Python seems
    suitable.

KG: Bindings give data definition - have yaml stuff - if there are
    areas where the bindings evolve - e.g. System DT trying to
    maintain binding capcity at DT level. At system level think of a
    model where the different views can be described and don’t keep
    the legacy. Not constraining the System DT view to be useable by
    Linux

OJ: People have solved with multiple device trees in one blob. 

KG: Constraint of maintaining compatibility of the bindings goes
    away. e..g. the only thing we support are extended interrupts and
    can generate out standard interrupts.

TE: Assumed that Linux and U-Boot get their standard device tree via
    lopper tool from the system view. Then was the discussion that
    Linux might want to own the system device tree. Need Grant on this
    as he has strong views that it should be one specification. Like
    the mental model to decouple the front end model with the tooling
    with a language. Still use Device Tree as the ‘assembly language’

KG: Some syntactical issues where a base address changes and several
    things have to change.

OJ: One comment - not sure if we should sit here and describe a new
    language. Don’t want to come up with a compiler. Could do it in an
    OO language. Just pick Python (or Go, …)

TE: Should it be a definition language or description. If you want an
    IDE want something that can be easily modified - description file.

OJ: Could have import from file, even if the skeleton is Python.

SM: Concerned about making it executable.

OJ: Not planning to run this everywhere. 

SM: For CI, would like to have a validation tool that knows the format
    without having to execute anything.

OJ: Need to define a new format. 

SM: Could you find some time to expand on these ideas to something
    that Grant/others could comment on.

OJ: Send it to …

RH: Device Tree spec list (as an RFC)

BM: See this has value but concerned that this will be put in the
    critical path. Solving some other problems could be back burnered
    like useability because they should be tackled at the generator
    level. there are still other things to be done.

OJ: Yes - e.g. overlays

SS: Backward compatibility form for System DT is a key point. If lift
    it - becomes a much easier discussion.

SM: A richer generating process will solve a lot of things but know
    that Grant will have opinions on this.

TE: Also Device Tree is a known thing

OJ: Don’t think we’re planning to change device tree. Just discussing
    how to get more elaborate systems into the format. If we pick a
    new tool, don’t do it in Device Tree format

AB: If we do that, it should replace all the processor macros

SM: Hoping we can come up with a quick prototype.

Engineer assignments
--------------------

ST folks - haven’t yet managed to agree what they’ll be working on
(due to ELC pressures).

Bruce and Stefano are signed up as member engineers.

Do we have other members who would like to have engineers involved and
be able to infuence how things are done?

Cheers,
-- 
Steve McIntyre                                steve.mcintyre@xxxxxxxxxx
<http://www.linaro.org/> Linaro.org | Open source software for ARM SoCs




[Index of Archives]     [Device Tree]     [Linux Driver Backports]     [Video for Linux]     [Linux USB Devel]     [Linux Audio Users]     [Photos]     [Yosemite Photos]     [Linux Kernel]     [Linux SCSI]     [XFree86]     [Yosemite Backpacking]

  Powered by Linux