Hi folks!
I'm sharing the notes from our regular meeting that was held
yesterday. We had updates around several of our initiatives, and
discussion about trying to organise a DT sprint in the next few
weeks/months.
ADMIN: I forgot to mention yesterday, but I'll be away on vacation for
the week of the next call (26th Feb). Obviously the call can happen
without me if desired, but somebody else will need to deal with taking
notes etc.
More details about the meeting etc. at the end.
Attendees
=========
SteveM - Arm
GrantL - Arm
RobH - Arm
BenjaminG - ST
EricF - ST
LoïcP - ST
BillM - TI
TomiV - TI
TomasE - Xilinx
BruceA - Xilinx
StefanoS - Xilinx
ArndB - Linaro
MathieuP - Linaro
BillF - Linaro
KumarG - Linaro
VincentG - Linaro
TrilokS - Qualcomm
Notes
=====
1. Trying to arrange a sprint around System DT
a. Came from discussions at the Linux on Arm summit last week, more
on the lists
1. Became apparent that we need a few more people (Stefano,
Tomas, others) around a white board for a few days. Quite
slow back-and-forth by email.
b. Favourite option numerically is week after Connect BUD20, but
key people are not available
1. March 30-April 3rd. Rob and Stefano can’t make it. No point
if can’t get right people. Might end up pushing into May. Have
had several offers to host (Xilinx, ST, Arm/Linaro).
2. Please mail Steve with availability if haven’t already.
3. BM: Is this a System Devicetree sprint or Devicetree sprint?
4. SM: System Devicetree …
5. GL: Should be scope to talk about more than System Device Tree.
6. SM: Attendee split is c.50/50 Europe and US (Iceland??)
2. Bootloader applied overlays
a. https://github.com/wmamills/dt-overlays
1. BM: Good discussion on the list. Is this a new agreement on
accepting overlays in the kernel? Is there still a laundry
list of issues?
2. RH: Whilst we agree it’s the right place last time it was
submitted I gave feedback and it was never acted on. If
splitting to base and overlays need a way to get back to what
you previously had.
3. BM: Do you want to mash base and overlays together. I think
we tried to upstream that and it was rejected.
4. RH: Just need to change DTB format first … (Frank)
5. BM: Need to decide which way to pursue.
6. RH: Think there are a few hurdles IMO. Can’t speak to
Frank. Make it a separate repo but a submodule. Maybe lower
hurdle for that.
7. GL: Most comprehensive use of overlays is RPi and those
aren’t upstream. Maybe they have their own repos for that
8. RH: Assumption some people have combined base and overlays
and sent upstream because overlays were rejected.
9. TV: In TI kernel don’t think we have changed base DTBs. Just
have overlays that are not upstream. Have DTBs that contain
things that should be in overlays.
10. BM: Rob raised good point. Things that worked upstream
before should continue to work.
11. RH: Any cases where an overlay is dependent on another
overlay applied
12. TV: Yes we have that
13. RH: Maybe avoid that initially. Need some may to know what
overlays are applied to.
14. TV: How to improve that?
15. RH: Maybe build rules.
16. TV: Still a problem for U-Boot or the user?
17. RH: Saying kernel builds should be able to validate them
18. TV: Was thinking about using them. Optimally U-Boot will
know what to apply. Unfortunately have some cases where
can’t detect HW and then it’s up to the user.
19. RH: Easy to have typo in overlay. Want to catch that at
build time.
20. BM: Can be tons of combinations - don’t want them laying
around. Keep any version that is the back compatibility
version
21. RH: Right.
22. TE: We are using overlays. Just as a general thing.
23. RH: Generating overlay - not wanting to check in
24. TE: Yes.
25. RH: Arm32 stuff has everything in one directory. Would be
good to split this before adding overlays. Need to agree on
vendor names. Have script
26. AB: When discussed moving years ago - discussed to put in
separate directories out of tree. As long as still plan on
moving them out. Don’t want to move them twice. If around
the same time would do them together. First want to get
agreement on overlays. Takes half a year. how many files?
27. BM: think github is fairly complete or at least a good
estimate. Covers only the boards we actively support.
28. AB: RPi tree has around 300 overlays.
29. RH: For TI is 12.
30. BM: Beaglebone capes are not overlays. If a customer of TI
invents own overlays - vendor should be “Customer X”, not
TI. Is that aligned with your thinking?
31. RH: Would align by SoC.
32. BM: If there’s a strong standard for a subset could be its
own vendor.
33. SM: If 100s of new files, do we want in kernel or in a flat
tree?
34. BM: Let’s start with new files
35. RH: Not against it being in the kernel but doesn’t have to
be in the kernel.
36. BM: U-boot specific source, MCU DTs. If had a separate repo,
could be useful for U-boot and the kernel.
37. RH: U-boot and kernel are same but rebased at random
times. Did a diff on DTs in U-boot and kernel and a lot
hadn’t been synchronised.
38. BM: Single repo seems a “boil the ocean” problem.
39. SM: Is it a good time to start with that repo and put
overlays in. Can’t be the only vendor struggling to make it
work.
40. RH: Creatng a DT repo doesn’t mean that U-boot will use it.
41. SM: Is all work ad hoc by vendor?
42. BM: What is our ask of U-boot?
43. SM: Do we want U-boot people to take patches to use an
external DT repo rather than pulling in from kernel ad hoc.
44. SM: Might be able to find an engineer in Arm to put n
this. Will take an action. If can start showing progress
would that help?
3. DTE-18 - DTB runtime ID
a. Alexandre still hacking on this
b. Found some issues with what was suggested in the first round of
discussion
c. Follow up on the list
4. DTE-17: Arnd's prototype work for external DT repo
a. left the meeting already - next time?
Background information about DTE
================================
Linaro engineers are working on a range of initiatives in the DT
space, collected together as a project called Device Tree Evolution
(DTE). We hold a discussion call every second Wednesday at
1700 GMT / 1200 EST / 0900 PST. If you would like to be invited, please
ask me (Steve McIntyre).
This is a summary of the notes from the most recent meeting. I aim to
tidy up and post the meeting notes shortly after each meeting. The raw
notes are published at
https://docs.google.com/document/d/e/2PACX-1vRVDrVFWjIOascqZFCO--T8pIqyFB_MDh9cvgyoqhI6Y0tqaA9TcCcvQhcmxi5IY7CG44JfIrCdAUDL/pub
For more information about DTE, see:
* https://www.linaro.org/engineering/core/devicetree-evolution/
* https://www.linaro.org/assets/pdf/Linaro-White-Paper--Device-Tree-Evolution.pdf
Cheers,
--
Steve McIntyre steve.mcintyre@xxxxxxxxxx
<http://www.linaro.org/> Linaro.org | Open source software for ARM SoCs
