Device Tree Evolution Project - call notes - 12th February

[Steve McIntyre <steve.mcintyre-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>]

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-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org
<http://www.linaro.org/> Linaro.org | Open source software for ARM SoCs