Dt3 #62
Dt3 #62
Conversation
schemas/options/u-boot,config.yaml
Outdated
| examples: | ||
| - | | ||
| options { | ||
| u-boot,config { |
There was a problem hiding this comment.
I think this should be just 'u-boot' for the node name. You get 1 node in the hierarchy for your component.
Whatever we decide, please define as a '$nodename' property.
| # Based on the precedent set by IEEE 1275-1994 IEEE Standard for Boot | ||
| # (Initialization Configuration) Firmware: Core Requirements and Practices | ||
| # https://www.openfirmware.info/data/docs/of1275.pdf | ||
|
|
There was a problem hiding this comment.
This is worth being in the description, not a comment. Someday we might generate documentation from this.
schemas/options.yaml
Outdated
| production firmware which does not happen on developer firmware, because they | ||
| are completely different builds. | ||
|
|
||
| The options node provides useful functionality for this. It allows the |
There was a problem hiding this comment.
And probably should be '/options'
schemas/options.yaml
Outdated
|
|
||
| "#address-cells": true | ||
| "#size-cells": true | ||
| ranges: true |
There was a problem hiding this comment.
How would these properties be used? Do you expect to have translatable addresses in child nodes? If so, then only 1,2 are valid.
There was a problem hiding this comment.
Possibly, but I am not sure yet.
I dropped ranges, hope that is what you mean.
schemas/options.yaml
Outdated
| "#size-cells": true | ||
| ranges: true | ||
|
|
||
| additionalProperties: false |
There was a problem hiding this comment.
This won't work. From a schema perspective, nodes are also json-schema properties. You need to say only other thing allowed is child nodes:
additionalProperties:
type: object
The descriptions are based on chosen.yaml with some additional notes to explain the purpose. Signed-off-by: Simon Glass <sjg@chromium.org>
U-Boot makes use of the devicetree for its driver model. Devices are bound based on the hardware description in the devicetree. Since U-Boot is not an operating system, it has no command line or user space to provide configuration and policy information. This must be made available in some other way. Therefore U-Boot uses devicetree for configuration and run-time control and has done for approximately 9 years. This works extremely well in the project and is very flexible. However the bindings have never been incorporated in the devicetree bindings in the Linux tree. This could be a good time to start this work as we try to create standard bindings for communicating between firmware components. Add an initial binding for this node, covering just the config node, which is the main requirement. It is similar in concept to the chosen node, but used for passing information between firmware components, instead of from firmware to the operating system. Signed-off-by: Simon Glass <sjg@chromium.org>
The Python 2 version does not exist on some newer distributions, such as Ubuntu 20.04 Signed-off-by: Simon Glass <sjg@chromium.org>
Show these in a different style to make them stand out more. Signed-off-by: Simon Glass <sjg@chromium.org>
This is version 3 of the binding initially proposed here:
https://lkml.org/lkml/2021/10/3/185
Changes are based on the feedback and what seems to be a resolution of this issue.
Also includes a few README tweaks that might be useful.