Hey folks,
I'm sharing the notes from our regular meeting that was held today. We
continued discussion around our two main topics: System DT and how to
work with a new/shared repo for DT data.
More details about the meeting etc. at the end.
Attendees
=========
SteveM - Arm
ArndB - Linaro
KumarG - Linaro
LoicP - ST
MarkB - Arm
MathieuP - Linaro
RobH - Arm
SaravanaK - Google
StefanoS - Xilinx
TomasE - Xilinx
TrikokS - Qualcomm
VincentG - Linaro
WarnerL - FreeBSD
DonH - Linaro
Frank Rowand - ???
Notes
=====
* Steve will check into opening up the docs a bit
* Arnd spoke to people at ELC-E, particularly with Frank who seems
unhappy to change the status quo.
* We should push some more public discussion about System DT
+ Stefano has bindings etc. ready to send out in the next couple of days
* Need to respond more to discussions on moving the DT data
+ More discussion from other projects to support this, and describe
how they use things will help
+ Push the stability idea
+ Better for U-Boot and FreeBSD devs too, of course
+ We want people to complain more when things change and cause
breakages - share the pain
+ Do the FreeBSD people have some CI that can help to identify
breakage? Some limited stuff here, they want to automate more
going forwards
- Need more backwards-and-forwards testing to identify regressions in Linux too
- FreeBSD people also using DT for other arches like powerpc and
mips, but arm/arm64 are the main targets
+ Why is a hardware description being kept in with the Linux kernel
(only)? This was meant to be a short-term stopgap until firmware
provided DTs...
* Engineer assignments from ST
+ Benjamin to contribute to system DT
+ Alexander to work on DT identifcation at runtime
- Set up meeting with him, RH, GL, SM to discuss details. Anybody else?
Wider discussion about moving things out
----------------------------------------
* FreeBSD people have had breakages come from Linux, but unhelpful
responses when they report issues
* Other projects add extra interfaces in DT - Android, etc.
* What about DT on hardware that would never run Linux? Where should
that be managed? Bindings have been taken in the past in Linux even
without drivers.
* Can we find a model that works here for everybody without causing
too much extra grief for the Linux development model?
* Olof has suggested a split - just a core set of DT in Linux, with
lots of boards / variants externally
* Keeping DTS, headers, bindings together matters (as already
discussed previously)
* Rob and Grant have mentioned a patch to build DTBs from the kernel
using DTSs from an external repo
+ Effort seems to have died out
* Can we organise a sprint to work on stuff and generate a prototype?
+ Maybe a good way to drive the discussion forward
+ Demonstrate working ideas?
+ Maybe, but time and travel are awkward.
* Need to open up discussion more to the normal lists
+ include more community people, definitely
* What are the blockers to progress here? A few options to think
about; any others?
+ Can we demonstrate an external DTS repo being used for various
projects? Rebasing tree (ijc) is an example
+ External repo with DT stuff that the kernel can pull from directly
at build time?
+ External repo, sync things into the kernel
periodically. Automation to help
+ Git submodule?
* Headers are already a source of pain with separation - different
maintainers. Driver/header/DTS need to be in sync. Would also be a
problem with external repo
* Would Olof's tool for generating DTs help? Not so much - still a
sync problem
* How often are platform folks shipping working DT with the firmware?
+ Depends a lot on the market - some do, some don't
+ Things like Android phones are mixed - some data from the
firmware, then some applied on top. Move to mainline kernels is
part of this.
+ On powerpc, almost all platforms ship with DTB in the firmware
+ RISC-V plan is to always have DTB in the firmware too
+ Do we have example of platforms shipping DTBs where newer kernels
stop working due to incompatibilities? Yes - Apple powermac, some
IBM machines
+ With ACPI, firmware can cause problems and people end up shipping
workarounds. Firmware updates are rare
* Are wasting time talking about stability here maybe? Compatibility
is something people spend a lot of time on.
+ FreeBSD people have sometimes added overlays to override bugs in
the provided DT
+ While bringing up DT support on a platform, compat is basically
ignored. Only start worrying about compat when something is
considered "stable", or maybe to stick with what's shipped by
firmware.
* Let's look at the actions from the chat at SAN19
* Warner definitely interested in a meetup etc. if we have one
* Add a pointer to the devicetree-spec posting on the mail dt list
+ also send to U-Boot folks
+ FreeBSD? Zephyr? anybody else?
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@xxxxxxxxxx
<http://www.linaro.org/> Linaro.org | Open source software for ARM SoCs
