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
