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 <[email protected]> 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_zcCq44DLGmPZQFPbYHOC6nzPowaL0XmRk0/edit?ts=5edf6e58# > > > > 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. > > > > ================================================================================ > -- François-Frédéric Ozog | *Director Linaro Edge & Fog Computing Group* T: +33.67221.6485 [email protected] | Skype: ffozog _______________________________________________ boot-architecture mailing list [email protected] https://lists.linaro.org/mailman/listinfo/boot-architecture
