Device tree kernel summit 2017 etherpad

Revision as of 10:15, 26 October 2017 by Frowand (talk | contribs) (initial version. raw paste of .txt)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search

Top Device Tree page

Local cache of Linux Kernel Summit Devicetree Workshop etherpad notes

(as of Thu Oct 26 10:13:17 PDT 2017)

  • Devicetree Workshop Notes
  • Agenda

9:40 Encoding and Schema DT Yaml Encoding (Pantelis Antoniou) DT Schema (option 1) (Pantelis) DT Schema (option 2) (Grant Likely) Discussion

11:10 Break

11:50 Code Generation from DT (Kumar Gala)

12:30 Lunch

14:30 DT Maintenance - Overlay maintenance (Bill Mills) - Avoiding duplicate descriptions (Thomas Petazonni) - Criteria for accepting board files (TBD) - Location for maintaining bindings (Maxime Ripard) - Sharing Generic Bindings (Geert Uytterhoeven) - API Stabiliy (Lucas Stach)

16:00 Break

16:00 DT Health Check 16:20 update (Grant) 17:35 EBBR Discussion (Grant)

18:00 Closing

Backlog - Connectors (David Gibson) - Classes of embedded systems - ConfigFS interface - DT on servers?

  • YAML Format

Grant and Pantelis independently worked on this. Grant is looking at how to make DT work with existing tools and workflows

Why YAML Encoding: Grant: enables tooling. He looked at json schema, would be more work. YAML should allow us to work with existing tools Pantelis: without special tools, DTS is hard to parse The current schema is a lossless conversion, using tags in YAML Labels are supported

Grant: show of hands, who is familiar with YAML? (1/3), JSON? (1/2) - YAML is a superset of JSON - YAML is friendlier for humans - YAML supports labels and refs (anchor/alias) The native reference support in YAML breaks with a 1-to-1 mapping of DTS references JSON is really easy to parse, but for example number formats 0x are difficult to use in JSON JSON schema works on parsed JSON, works also on parsed YAML

Q: Is this a replacement for the C preprocessor Pantelis: No, it would be used as before


   What we have now:
       DTS → cpp → dtc → DTB/DTS/ASM
   Prototype for:
       all DTS → Pantelis' tool →YAML → validation tool (with additional binding schemas)
   The format of the schemas should go into the DT spec so that we can validate

Pantelis' tool can replace DTC

Grant: currently there is no DTS → YAML migration planned

Q: Why is human readability important? Grant: For this use-case, it is not important. Makes it easier to use for other tools.

Comment: Other projects may just use YAML and skip DTS Grant: So we want to have it specced out.

Q: Are there tools to convert indented (human readable) to braced YAML? Grant: Yes. All tools parse both.

Q: Can you summarise the alternatives? Grant: XML has been considered, but isn't nice to work with.

Comment: The YAML format is only needed for the bindings? Grant: The schemas are specific to the actual encoding to YAML.

Q: Are includes support in YAML? Pantelis: Not in YAML itself, but we would have it in our tools

Q: Does it support comments? Are they kept during parsing? Grant: Yes (#). Yes (ruaml in python)

Q: Is the DTB different? Pantelis: It should be exactly the same (in compatible mode)

Grant: Let's move on to where Pantelis is at, so we can talk about schemas.

Grant: We can't use native * references in YAML, would use $ and a DT sepecific resolution step after parsing

Q: Why to we need to quote "#address-cells"? Grant: # is comment David Gibson: #address-cells is the reason comments in DTS are the way they are

Grant: We are asking people to understand the YAML syntax to work with schema files.

Pantelis: The YAML files correspond to DTS files, are not deduplicated and node-deleted yet.

David Gibson: Would like to run validation on DTBs. That wouldn't work if the schema is fixed on the YAML format. Grant: Use the schemas to decode the DTB to have the correct type info. Only then do validation.

  • Pantelis' Schemas

Pantelis: Goes through his web page

Q: Can the constraint be C code? Pantelis: Yes. eBPF

Q: Can you show some more constraints? Pantelis: Examples from website and live demo of error detection (invalid value in property)

Grant: Can you reference other properties? Pantelis: Yes.

David: Each schema is for a node. You'd like to have separate schemas for nodes and properties to allow reuse.

  • Grant's Format

Who has looked at JSON schema? 3 persons a little bit At first discarded JSON schema, because he thought it didn't fit. After looking at YAML schema, it seems JSON schema does actually work.

Explains dt-schema-core.json file This would not be written by the schema writer. Would be similar but much more constrained. Have no examples for that. The dt-schema-core would be able to validate a set of standard properties (#*-cells, compatible, interrupt-controller/-parent, …) Parts of the schema can be reused in other schemas (size-spec, address-spec) Documentation can be in the JSON schema files. JSON schema validators have support for custom extensions, would allow adding eBPF constraints

Q: how do the errors look? A: Terrible. But there is context. Could be improved.

Q: Brings additional requirements to build the kernel. A: Python, ruamel, JSON schema. Could be moved to dtc. Validation would not be required for build, only useful for development. Should try to run validation during build if requirements are available.

David Gibson: Can the schema follow a phandle? Grant: Should be possible to implement as an extension.

Q: Can we validate busses? Grant: The bus schema could require that every child has the right format. Would be hooked up by the controller schema.

David: Validation has two parts: Triggering and Checking Triggering could be done by compabile or by a parent. Or we could start using device type Grant: We need this to work with existing trees.

Q: For a sensor connectable via SPI and I2C, do I need copies? Grant: No, this is supported by JSON schema. Properties can be required depending on the actual type?

Next steps for schema: Pantelis and Grant need to build a combined proposal.

Q: We need to have a page to read an up-to-date summary on what has been agreed A: Wiki page and discussion on the devicetree spec mailing list.

  • Zephyr usage of Device Tree

- Zephyr overview - Kconfig was used to describe HW properties, was a mess and didn't scale - DT is obvious solution - DTB is too big, but can generate code

DTS → cpp → dtc → DTB → dtc → DTS → python script → Kconfig definitions + C headers

Q: do you have helper macros? A: no

Want to move to structure generation soon

Support counting to size IRQ, DMA structures to the actual requirements Have I2C, Serial, some others, many still missing Only ARM, x86 supported. ARM completed.

?: At Xilinx, they are generating headers, and it's not going to work. You'd need another layer to select which instances to use and so on. The C code would get a lot more complex.

?: TI has a system called ritzy, which is not recommented. Maybe have a templating step to generate code.

Simon Glass: U-Boot has a tool to generate structures from DT

Mark Rutland: There are too many parsers for DTS/DTB, … we should have common libraries

?: RioT would possibly benefit from this as well

  • Device Tree in U-Boot SPL

Slides here:

Size contraints, ~32KiB Tools: ftdgrep, dtoc fdtgrep filters out parts that u-boot doesn't use (40K to 3K), based on libfdt+python dtoc: builds structs in header files and c files to fill them out. It's used together with fdtgrep

The same drivers in normal u-boot and SPL. The of-to-platdata code (which uses libfdt) gets replaced by simple assignments.

Whishlist: Smaller DTB format (shared propery value) Grant: I we'd do a new DTB revision, that would be on the table. David: Was designed to be compact for 2005 servers.

Grant: What would you need to generate the C structures? Kumar: Common Problems: how to generate names, how to handle busses/slaves, filtering of nodes

David: We can't generate C code well without schemas, so we have nicknames and type info.

Grant: If anyone is interested in working on this, talk to Simon and Kumar

  • Lunch 12:30-14:00
  • DeviceTreats (Arnd)
  • Device Tree Overlay Deploy (Bill Mills)

Bootloader applied is here: - Android will use it next year Android DT Overlay top level: DT Partition format: - TI will use it in Jan 2018

Android: SOC (base) + board (overlay) Upstream: board based TI: Interested in Board with options

Opinions on the source format? - Frank: in Rob Herring's branch, coming soon: the dtc can use a dtsi as an overlay (plugin directive) - Grant: two parts: technical capability and policy

Can the schema validation support the maintainance of the overlay sources?

Geert: Is using the old patch for the delete node support. Grant: We should reconsider merging that. Bill: And delete-property?

Ben: How do nested pluggable boards work?

Grant: There will be general usecases, we need to have guidance for that. Who will provide that?

Bill/Mark B: Android wants to distribute SoC and board parts separatly (SoC is responsibility of the silicon vendor)

David: The base should be the most specific thing, so the board.

  • Deployment


   - Append base to kernel or put it into its own partition
   - Overlay is a file in ODM partition or in its own partition
   - Android specifies a multi image format for DT partition


   - TI uses FIT images for everything for secure boot


   - DT should come with the board. Bundle into the UEFI binary?
   - Or in EFI partition?


   Originally, UEFI should provide a default, but OS can provide another one.
   We should make sure that we always have appended DT

Marc R: Appended DT doesn't exisit for ARM64


   In the ARM Trusted Firmware world, the necessary configuration for the TF parts may be passed via DT.


   The fit configurations refer which overlays to apply.


   Different models for U-Boot verified boot and UEFI secure boot, in the future U-Boot may support the UEFI model.


   Some ppl in debian would like verified boot on u-boot.

Bill: Would like to avoid many approaches to this.

  • Which DT Boards in the Kernel?

Q: Which DT boards would be rejected? A: Only for something extremely configurable like ARM fast models.

?: A DTS for a zynq board was rejected, there would be too many. We don't want to have DTS for configurable logic

?: Why fix the flat DTS directory in ARM32 Arnd: For example xilinx/vendor (if a vendor has 35 boards) We might have an external master (git repo) for a subdirectory Will need more to think about this topic for ARM32.

Grant: Should move this disussion to a whiteboard later.

  • Avoiding duplicate descriptions (Thomas Petazonni)

Marvell Armada 7k/8k:

   somewhat modular AP (CPU, simple IO) / CP (network, complex IO)
   currently AP806 dual/quad, CP110
   but can have multiple of each (4, potentially 8 AP)

cp110-master and cp110-slave are mostly identical, except of internal references, offsets)

possible solution C preprocessor to generate cpm_ or cps_ Grant: one big macro? Arnd: relative references?


   The idea of macros has been around for some time...
   There are mainline python bindings to libfdt


   The HW will be taped out in the near future (months)

Marc Rutland:

   we could generate this from a scripting language


   The decision is between cut&paste and CPP


   We are using the CPP approach in QEmu for generating HW descriptions


   We accept patches for string expressions for node names.


   Would be nice to handle the case of Thunder X of hundreds of CPUs.


   Complex CPP macros would worry him for YAML


   1. see if dtc can be changed to support relative references
   2. CPP macros or copy paste

  • How to handle DT foreign bindings (Maxime Ripard?)

"bindings defined by other projects" used by Zephyr, U-Boot, Barebox, OpenBSD, ...




   different ARM GIC compatbiles (fixed now), they try to align with linux

Marc R:

   u-boot,dm-pre-reloc have been rejected as an implementation detail


   We tried to push back on these, but if it's the best solution, we should accept it.
   Needs good justification

Marc R:

   Should be limited


   There are zephyr,*

Marc Brown:

   What's with projects forking the linux bindings? Using existing properties differently...


   U-Boot uses the regulator names which were intended to be only cosmetic in linux


   Seperate Core HW bindings and Linux (and other project) specific bindings in the docs?


   Where should we store the bindings? Close to the tools, to make it easy to use validation.

?: maybe use more


  Adding more projects to the Linux review won't increase the volume alot.
  Use the same release cadence as the kernel.
  Maybe similar to the separate firmware repo.


   Default stance: Bindings belong in the kernel. Accepting the binding together with the user.
   We are still the primary users.

Lucas Stach:

   A release is not needed to depend on it, applying it would be enough.


   Having an external tree would make it more explicit when it is accepted.


   Maybe generate spec documentation from the stable schema parts.
   Currently, the kernel tree is the canonical binding source.

  • Sharing Generic Bindings (Geert Uytterhoeven)

IP block gets reused, now there are explicit power, clock, resets

Platform Properties:


David: seems similar to interrupts


   should we define that in a generic binding?


   maybe in a device binding that is inherited by all device?
   have a category of properties which have the same meaning over the whole system?


   use a new compatible string for new integrations

Marc Rutland:

   the way they relate to the device is specific to that device


   The question is wether the integration of an IP should be reflected in the compatible
   This is also relevant in the validation case
   A consistent rule at the SoC level seems not possible

Marc Rutland:

   We want the common properties in the generic binding
   We also see integration relevant errata, so we need the string.


   How do we document policy? Mailinglist? Volunteers?


   Renesas already uses SoC-sepecific compatibles


   We have an interface (soc_device_match()) to even match against a specific version of the SoC, it's not widely known
  • 15:30-16:00 Group Photo + Break
  • API Stability (Lucas Stach)

Cares about backwards compatibility: use new kernel with older DT from the firmware

Infer as much as possible from compatible or actual hardware


   ACPI now can use DT properties
   needs a good taste decision on how much detail goes into a binding → need policy document
   deviations are possible, but they need to be justified


   Are we also trying to run old distro on new HW/FW?


   not as little or as much as possible, but the right amount
   the ideal case would be to also run old kernel on new FW, but old FW with new kernel is much more important


   We've become better at designing bindings (like graph bindings)
   If we break things, have a really good (documented) reason
   Enterprise ecosystem (HW&SW) has decided:
       UEFI, ACPI, Datacenter, Support model
   Distro support is important (debian)


   Use both original implementation and soc specific compatibles, allows fixing quirks in newer kernels

Maxime Ripard:

   Sometimes you don't have enough information in the begining for some socs


   It's also possible to rev the compatible


   Standard properties for version information?
   you could have soc, ip version, ip variants all in the compatible string?

Marc Rutland:

   originally there was model, which was the sepcific


   Use most and least specific, and required ones in between


   Is the compatible about features or bugs?


   Both. The specific hardware interface.


   For configurable HW blocks, it is better to have registers in the HW.


   To enable features that didn't work before, updating from a broken DT in FW is reasonable.


   Will write a docs patch


   We need a guidance document! Could sit at
  • DT Health Check (Ben)

- does DT help us in total? - media pipeline status?

Some vendors are lagging behind mainline devel He likes some things about the old board files.

A graphical tool based on the schematics?

Grant pain points?


   Power has some quirks that key of the board compatible


   ARM64 doesn't have those
   50% of ARM32 has those

Mark Rutland:

   We see board specific code as a last resort (drivers/soc)


   Leftover in ARM32: SMP and cpufreq, code to communicate with a onboard microcontroller which doesn't fit any subsystem


   Do we need to have some area to improve?


   Is distro support in our goals? Yes.
   Having everything on the generic boards to boot debian would be very good for the ecosystem.
   It should be a goal to be able ship DT with the firmware and boot debian from it.

Mark Rutland:

   In the far future he'd like a DT repo for all project using DT, but this is difficult for many reasons.

Simon Glass:

   We can't say that the DTs should be shipped with the Firmware when it's build from the kernel.


   Developing DTS and Linux in lockstep hides the real problems.


   So we should get the tooling in place to have a separate repo for DT. Like firmware.


   DT is not like firmware. We shouldn't decide this here.


   We need to support diffierent models. Keep DTS in kernel, get tooling in place which support a separate repo.


   Yes. Let's do that.
  • EBBR Discussion (Grant)

ARM wanted to build a spec on how to build more standard embedded systems. - UEFI - DT noch ACPI Not for all embedded systems What would you like? Contact Grant afterwards per Mail

  • (Grant)

A place for the specs Some people want to have assurances that DeviceTree is going to be "stable" Be a bridge Spec is on github, using sphinx Discussion on list Is a membership org with a steering commitee SC oversees the release process SC: IBM ARM Linaro ST NXP Membership 2500$

?: Should the schema work (and tooling) be done via github? Grant: Yes.

Grant: Restart spec process and get it up to the current state.

  • ConfigFS

It is a generic way to apply a DT at runtime.

What is the status of the patches?


   Needs a way to specifiy which nodes are allowed to be overlayed.
   Whitelist in the base tree would be configuration in DT.


   Can we constrain which parts of the tree are adjusted by the overlay?




   shows slides from bof
   there are people using overlays in the field
   there is breakage in mainline when applying overlays
   accepting overlays would commit us to fixing those


   Wants to clean up internal handling of overlay syntax in dtc


   We could start allowing appling limited overlays, maybe even with removals.


   Applying in the bootloader would work now.
  • Connectors (David)

You have the same problem with duplication as with the armada. You need to have an overlay for each slot where you can connect something.


   allows mapping for interrupt ids from local ids to global ones.
   have a compatible string
   can be available multiple times
   local names for things which are connected (as aliases)


   at the /plugin/ directive it declares into which socket it plugs
   has a toplevel compatible describing the actual device


   some FPGA ppl said this would work for them

Doesn't have to be hotplug, could also be used at boot time or in the bootloader

The connector plugin DTB could be untrusted


   We'd need specs for many subsystems (irq, clock, dma, gpio, …) to build the translator nodes


   We might need to have a driver for the connector for more complex cases, which can handle the enable/disable.


   Need support for pinmux


   Needs special translation nodes for SPI


   Difficult case will be a SoM connector with several soc vendors and board vendors.


   You don't want to use overlays to configure many pads on your soc.


   Partial reconfiguration has been around for years.


   To simplify: maybe have just a set of specific pinmux configs to select from for each connector.


   Could we constrain overlays enough that we would be fine with exposing that?
   Maybe with a platform specific driver?


   Platform, I2C and SPI could work.


   Xilinx has a 96Boards-like board which might be useful for referencing


   Important are FruitPis, Beaglebone, 96Boards
  • Feedback


   Discussing the agenda was useful.


   We need the key ppl. and subsystems present.


   Again in 6 months? (50%) 12 months? (50%)