Device Tree Evolution Project - call notes - 12th February

Device Tree Evolution Project - call notes - 12th February

[Steve McIntyre]

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

Re: Device Tree Evolution Project - call notes - 12th February

[Francois Ozog]

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-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org> 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-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org
> <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-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org | Skype: ffozog

Re: Device Tree Evolution Project - call notes - 12th February

[Frank Rowand]

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"


> 
> 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,
> 

Re: Device Tree Evolution Project - call notes - 12th February

[Frank Rowand]

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,
>>
> 
> 

Re: Device Tree Evolution Project - call notes - 12th February

[Steve McIntyre]

Hi Francois!

On Thu, Feb 13, 2020 at 04:23:35PM +0100, Francois Ozog wrote:
>On Thu, 13 Feb 2020 at 15:51, Steve McIntyre <steve.mcintyre-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org> wrote:

...

>>       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" ?

Sorry, I'm not following you here. Maybe the notes aren't clear
enough, and my addled brain is struggling to remember exactly what was
said here. :-/

Cheers,
-- 
Steve McIntyre                                steve.mcintyre-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org
<http://www.linaro.org/> Linaro.org | Open source software for ARM SoCs

Re: Device Tree Evolution Project - call notes - 12th February

[Steve McIntyre]

Hey Frank,

On Thu, Feb 13, 2020 at 11:24:59AM -0600, Frank Rowand wrote:
>On 2/13/20 8:50 AM, Steve McIntyre wrote:

...

>> 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.

Do you have any pointers to previous discussions about the format
update please? The only relevant things I can find are in the thread
"DTBO magic and dtbo format options" but that's back in the middle of
2016.

Cheers,
-- 
Steve McIntyre                                steve.mcintyre-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org
<http://www.linaro.org/> Linaro.org | Open source software for ARM SoCs

Re: Device Tree Evolution Project - call notes - 12th February

[Steve McIntyre]

Hi!

On Thu, Feb 13, 2020 at 02:50:33PM +0000, 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.

Reminder: I'm not around next week (26th Feb); if people still want to
have the call, is anybody willing to take notes and post them?

Cheers,
-- 
Steve McIntyre                                steve.mcintyre-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org
<http://www.linaro.org/> Linaro.org | Open source software for ARM SoCs

Re: Device Tree Evolution Project - call notes - 12th February

[Frank Rowand]

On 2/19/20 12:05 PM, Steve McIntyre wrote:
> Hey Frank,
> 
> On Thu, Feb 13, 2020 at 11:24:59AM -0600, Frank Rowand wrote:
>> On 2/13/20 8:50 AM, Steve McIntyre wrote:
> 
> ...
> 
>>> 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.
> 
> Do you have any pointers to previous discussions about the format
> update please? The only relevant things I can find are in the thread
> "DTBO magic and dtbo format options" but that's back in the middle of
> 2016.

Documenting all the previous proposals in one place is the next item
on my todo list after finishing my "why I don't want .dts to move out
of the kernel tree" document.  Once the format discussion history
document exists then I intend to restart the discussion on the mail
lists.

-Frank

> 
> Cheers,
> 

Re: Device Tree Evolution Project - call notes - 12th February

[Steve McIntyre]

On Wed, Feb 19, 2020 at 12:26:54PM -0600, Frank Rowand wrote:
>On 2/19/20 12:05 PM, Steve McIntyre wrote:
>> 
>> Do you have any pointers to previous discussions about the format
>> update please? The only relevant things I can find are in the thread
>> "DTBO magic and dtbo format options" but that's back in the middle of
>> 2016.
>
>Documenting all the previous proposals in one place is the next item
>on my todo list after finishing my "why I don't want .dts to move out
>of the kernel tree" document.  Once the format discussion history
>document exists then I intend to restart the discussion on the mail
>lists.

ACK. It's taking a while to get there - is there anything we can do to
help?

Cheers,
-- 
Steve McIntyre                                steve.mcintyre-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org
<http://www.linaro.org/> Linaro.org | Open source software for ARM SoCs