Hi Frank

Many thanks for preparing this. I feel I’ll learn a lot today.

During the call could you concentrate on the use cases that the technology serves ? Looks like it is used to deal with Beaglebone so it may be related to capes and such... let’s dig into the meta data semantics first before going into the formats or code.

Cheers

FF

Le mer. 24 juin 2020 à 07:33, Frank Rowand frowand.list@gmail.com a écrit :

On 2020-06-12 12:13, François Ozog wrote:

...

Hi,

I have updated the document to reflect what I heard from the remainder of the last call. Please have a look and comment.

https://docs.google.com/document/d/1CLkhLRaz_zcCq44DLGmPZQFPbYHOC6nzPowaL0Xm...

...

If you volunteer to edit content, please ask me and I'll give you edit rights on the document.

Shall we make a github backed document? If so, any volunteer to make it

happen?

...

Agenda for June 24th:

• DT Overlay status presentation by Frank Rowand.
• Document review and trying to close all comments.

Cordially

No pretty slides for my presentation. Here is the outline that I will use. It is mostly based on the information that is contained at the elinux.org links, but the pages at the links have more information.

-Frank

================================================================================

June 24, 2020

Status of devicetree overlay support

================================================================================ https://elinux.org/Device_Tree_Reference#Overlays

Run time overlay apply and run time overlay remove from user space are not supported in the mainline kernel.

There are out of tree patches to implement this feature via an overlay manager.

When making Linux kernel changes that I expect might impact the overlay manager, I make sure to keep the maintainer in the loop, and ensure that the timing of my changes do not cause him problems.

U-Boot has supported overlay apply to the devicetree that will be provided to the kernel.

The model currently used by the Beagleboard project uses U-Boot scripting and a U-Boot text configuration file to manage the overlay loading.

I have been told that this process is difficult to use and error prone.

In the early days of implementing overlays, the overlay metadata was hand coded in the .dts source file.

The dtc compiler was then modified to properly create the overlay metadata.

The Beagleboard project recently updated the oldest version of dtc that is in the project to one that has the overlay support.

Devicetree source files should no longer contain any hand coded metadata.

================================================================================ https://elinux.org/Frank%27s_Evolving_Overlay_Thoughts

Frank's Evolving Overlay Thoughts

This wiki page contains a list of issues that need to be resolved before run time overlay apply and run time overlay remove from user space can be supported.

Even if fully implemented, run time overlay apply is likely to be more fragile than pre-boot overlay apply.

As overlay related items are completed, I try to note them in the "completed" section at the bottom of the page.

----- what has been completed (see the elinux.org URL)

----- some important items to implement

Should the kernel provide an overlay apply feature that occurs in conjunction with unpacking the FDT, so that each boot loader does not have to be overlay aware?

Note that overlay support is not an "all or nothing" proposition.

As various issues get resolved, levels of support that are not dependent on further issues may be phased in. For example, memory leaks are primarily an overlay removal issue. It might be possible to support overlay applies without first resolving the memory leak issues.

Architecture documentation, eg

• overlay semantics
• how to properly use overlays
• restrictions on overlay use
  • for example, ordering rules for removing overlays
• etc

Memory leaks

Locking

Connector architecture and implementation

Validation of subsystem support for overlays

Validation of specific driver support for overlays

Process to Validate overlay source against binding schemas

Process to Validate overlay source in the context of base devicetrees

New FDT / DTB format

================================================================================

What I personally hope to be working on that is overlay related this year

===== 1 =====

The connector model to allow an add-on board overlay to be "position independent". If a board can be plugged into a standardized connector then the each connector on the motherboard can be described by the board's devicetree and a generic overlay FDT can be provided to the overlay apply code, with an additional parameter to specify which motherboard connector will be used.

An example of a standard connector is the mikroBUS connector. This is a connector that some of the Beagle boards provide.

The mikroBUS connector contains signals for - an I2C bus - a SPI bus - a serial (rs-232) "bus" - an interrupt line - reset - 3.3 volt - 5 vold - ground - pwm

The mikroBUS "connector" is actual two physical connectors, with a standardized distance between the connectors.

PocketBeagle has two mikroBUS connectors Beaglebone mikroBUS cape provides four mikroBUS connectors

Another example of a standard connector are the SEEED Grove connectors

There are four Grove connectors - digital - analog - uart - I2C

===== 2 =====

The next version of the DTB / FDT format.

There are several different projects interested in driving forward with a new DTB / FDT format and there has been discussion and talk of one for several years.

My plan was to document the previous discussions and the various proposals with the intent to restart the discussions, without each person involved needing to track down the history.

I intendeded to have this document completed early this year, so I am at least four months behind schedule. No promises on when I will have this ready.

================================================================================