On 2/13/20 11:24 AM, Frank Rowand wrote: > On 2/13/20 8:50 AM, Steve McIntyre 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) > > That matches my memory of wanting to update the DTB format before allowing > overlay sources into the kernel tree. BUT, it has been two years (I > think) of small bursts of discussion about DTB format with little > forward progress. I had hoped to revive the DTB format discussion in > December or January, but now it is already February. Maybe I will get > to it this month. > > The biggest change since then is that overlays can be applied by the > bootloader (at least I think that was implemented after my objection). > That alone is enough to change my opinion. But on top of that, the > long delay on DTB format update also changes my opinion. > >> 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? > > There are a couple of issues that I think are relatively easily > resolved with the "new" overlay source format (now years old). > > One issue is the duplication of source in both a system .dts and > an overlay .dts. A second issue is being able to validate > overlay source. > > An example of a .dtsi that can be included from either a > system .dts or an overlay .dts is: > > ---------- system .dts ------------------------------- > > /dts-v1/; > > / { > soc { > intc: interrupt_ctrl { > }; > fpga_region: base_fpga_region { > }; > }; > }; > > /include/ "fpga_plugin_or_dtsi.dtsi" > > > ---------- overlay .dts ---------------------------------- > > /dts-v1/; > /plugin/; > > /include/ "fpga_plugin_or_dtsi.dtsi" > > > ---------- fpga_plugin_or_dtsi.dtsi ---------------------------------- > > &fpga_region { > ranges = <0x00000000 0x00000000 0xc0000000 0x00040000>, > <0x00000001 0x00000000 0xff200000 0x00001000>; > > external-fpga-config; > > #address-cells = <2>; > #size-cells = <1>; > > fpga_pr_region0 { > compatible = "fpga-region"; > fpga-bridges = <&freeze_controller_0>; > ranges; > }; > > freeze_controller_0: freeze_controller@100000450 { > compatible = "altr,freeze-bridge-controller"; > reg = <0x00000001 0x00000450 0x00000010>; > interrupt-parent = <&intc>; > interrupts = <0 21 4>; > }; > }; > > > In a similar manner, an overlay can be validated in the context of > a system .dts - a small wrapper .dts can be created to include > both the system .dts and the overlay .dts, and then the wrapper > .dts is validated: > $ cat wrapper.dts > /include/ "system_base.dts" > /include/ "overlay.dts" I oversimplified the validation example. The overlay dts would be just a wrapper just like the previous "overlay .dts" example, and the wrapper.dts would instead be something like: $ cat wrapper.dts /include/ "system_base.dts" /include/ "fpga_plugin_or_dtsi.dtsi" -Frank > > >> >> 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, >> > >
