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