Thank you Steve for those notes as I always have conflicting calls... Questions below. FF On Thu, 13 Feb 2020 at 15:51, Steve McIntyre <steve.mcintyre@xxxxxxxxxx> wrote: > > 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? If we take the "responsibility" out of the picture, I would have thought those are overlays. Or shall we name them something like "composable DTBs" ? > 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 > > -- François-Frédéric Ozog | Director Linaro Edge & Fog Computing Group T: +33.67221.6485 francois.ozog@xxxxxxxxxx | Skype: ffozog
