Add checks to ensure that `zephyr,linker-region` property values are
always globally unique.
Signed-off-by: Jordan Yates <jordan.yates@data61.csiro.au>
Don't let a malformed devicetree escape as a DTError. Wrap it in an
EDTError instead, so callers can just rely on the edtlib APIs as is
generally expected.
Signed-off-by: Martí Bolívar <marti.bolivar@nordicsemi.no>
A GCC linemarker of the form:
# 1 "filename" 2 3 4
or so is not currently being handled, because the current regular
expression assumes the "flags" values (the numbers after "filename")
are limited to a single value. Tweak the regular expression to allow
for up to 4 flags, which is what GCC documents it may emit:
https://gcc.gnu.org/onlinedocs/gcc-10.2.0/cpp/Preprocessor-Output.html
Signed-off-by: Martí Bolívar <marti.bolivar@nordicsemi.no>
This enables cmake extensions that can look up the path for any
devicetree alias, or check if the alias is missing, etc.
Signed-off-by: Martí Bolívar <marti.bolivar@nordicsemi.no>
Using edt.chosen_nodes looks like a simple attribute lookup, but it's
actually calling a property that will create a new list of chosen
nodes every time. Apply a small optimization by only creating the list
once.
Signed-off-by: Martí Bolívar <marti.bolivar@nordicsemi.no>
As described in IEEE Std 1275-1994, the PCIe bindings uses the ranges
property to describe the PCI I/O and memory regions.
Write _RANGES_ defines that will be used to determines the I/O and
memory regions from PCIe Controller drivers.
Also exclude "ranges" & "dma-ranges" property's length generation
alogn "reg" and "interrupt".
Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
This adds some tests in test_edtlib.py and test.dts to check all
common possible combination of ranges property usage and handling
by edtlib.
Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
As described in IEEE Std 1275-1994, the PCIe bindings uses the ranges
property to describe the PCI I/O and memory regions.
Add parsing of this property in edtlib.
Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
Currently all the *-names and *-cells properties are derived from the
name of the base <name>s property. This is a limitation because:
- It forces the base property name to be plural ending in -s
- It doesn't allow the english exception of plural words ending in -es
With this patch we add one additional property 'specifier-space' that
can be used to explicitly specify the base property name.
Signed-off-by: Carlo Caione <ccaione@baylibre.com>
Suggested-by: Martí Bolívar <marti.bolivar@nordicsemi.no>
Node names are subject to the rules in table 2.1 of the devicetree
specification v0.3, while properties are subject to rules in table
2.2. These rules mean that some property names are invalid node names.
However, the same regular expression is being used to validate the
names of nodes and properties in dtlib. This leads to invalid node
names being allowed to pass. Fix this issue by moving the node name
handling code to the Node constructor and checking against the
characters in table 2.1.
The test cases claim that the existing behavior matches dtc. I can't
reproduce that. I get errors when I use invalid characters (like "?")
in a node name. For example:
foo.dts:3.8-11: ERROR (node_name_chars): /node?: Bad character '?' in
node name
Try to make the dtlib error message reminiscent of that.
Signed-off-by: Martí Bolívar <marti.bolivar@nordicsemi.no>
This is unused since the very beginning of the module's introduction.
It looks like it was abandoned in favor of the approach where each
token can have only one capturing group.
Signed-off-by: Martí Bolívar <marti.bolivar@nordicsemi.no>
This commit introduces devicetree API in CMake so that devicetree
properties and register block can be used in the CMake build system.
The script scripts/dts/gen_dts_cmake.py processes the edt.pickle and
generates a corresponding devicetree property map in a devicetree_target
that is then used in CMake.
The following devicetree API has been made available in Zephyr CMake:
- dt_nodelabel(<var> NODELABEL <label>)
- dt_node_exists(<var> PATH <path>)
- dt_node_has_status(<var> PATH <path> STATUS <status>)
- dt_prop(<var> PATH <path> PROPERTY <prop>)
- dt_prop(<var> PATH <path> INDEX <idx> PROPERTY <prop>)
- dt_num_regs(<var> PATH <path>)
- dt_reg_addr(<var> PATH <path> [INDEX <idx>])
- dt_reg_size(<var> PATH <path> [INDEX <idx>])
- dt_has_chosen(<var> PROPERTY <prop>)
- dt_chosen(<var> PROPERTY <prop>)
Signed-off-by: Martí Bolívar <marti.bolivar@nordicsemi.no>
Signed-off-by: Torsten Rasmussen <Torsten.Rasmussen@nordicsemi.no>
We need to be able to access pinctrl-<index> property contents by
name, convert names to indexes, convert indexes to names, and perform
existence checks by name and by index.
This is currently not possible because we don't track these properties
the same way we do other named properties. That in turn is because
they are different then the usual named properties.
The usual case looks like this, picking DMAs just for the sake of
example:
dmas = <&dma0 ...>, <&dma1 ...>;
dma-names = "tx", "rx";
So "tx" is the name for the <&dma0 ...> element, and "rx" is the name
for the <&dma1 ...> element, all in a single "dmas" property.
By contrast, pinctrl properties look like this:
pinctrl-0 = <&foo &bar ...>;
pinctrl-1 = <&baz &blub ...>;
pinctrl-names = "default", "sleep";
Here, "default" is the name for the entire pinctrl-0 property.
Similarly, "sleep" is the name of the pinctrl-1 property. It's a
strange situation where the node itself is kind of a container for an
array of pin control properties, which Zephyr's bindings language
can't really capture and has some special case handling in edtlib.
This is easiest to handle with ad-hoc code. Add special case macros
for pinctrls.
Signed-off-by: Martí Bolívar <marti.bolivar@nordicsemi.no>
Move the partition handling code into its own function and rework the
comment. This is prep work for adding additional generated macros to
this function.
Signed-off-by: Martí Bolívar <marti.bolivar@nordicsemi.no>
This became useless when _init_tokens() was refactored not to use
global variables (in "dtlib: use IntEnum for token IDs"), and the
linter is complaining about it now.
Signed-off-by: Martí Bolívar <marti.bolivar@nordicsemi.no>
Similarly to what was done for dtlib, use f-strings in places where it
improves readability. Some places, e.g. __repr__ methods that
construct a string using something like
"<SomeType, {}>".format(", ".join(...))
are better left off as-is.
Signed-off-by: Martí Bolívar <marti.bolivar@nordicsemi.no>
The library was originally developed before Python 3.6 was the minimum
supported version. Use f-strings now that we can do that, as they tend
to be easier to read.
There are a few places where str.format() makes sense to preserve,
specifically where the same argument is used multiple times; leave
those alone.
Signed-off-by: Martí Bolívar <marti.bolivar@nordicsemi.no>
Allowing multiple such files will let higher layers take inputs from
multiple DTS_ROOT directories. This in turn will allow out of tree
bindings to manage their own sets of prefixes without patching
upstream Zephyr's file or doing other similar hacks.
Parse each file into a dict, and merge those dicts into a single
dictionary for the EDT constructor.
Signed-off-by: Martí Bolívar <marti.bolivar@nordicsemi.no>
If the user passes None, set the internal attribute to an empty dict
instead. This lets us avoid some None checking and simplifies things
without changing semantics -- if the user *does* pass an empty dict,
the results are the same.
Signed-off-by: Martí Bolívar <marti.bolivar@nordicsemi.no>
This is a common extension for YAML files. We don't have to allow it
in upstream zephyr, but we should allow downstream DTS_ROOTs to have
this ability.
Signed-off-by: Martí Bolívar <marti.bolivar@nordicsemi.no>
Commit c4079e4be2
("scripts: rework edtlib warnings-turned-errors") was trying to abort
on unknown vendor prefix, but the error log is not fatal.
Fix it by using the same error handling function we use when aborting
due to deprecated property usage.
Signed-off-by: Martí Bolívar <marti.bolivar@nordicsemi.no>
There are way too many one-off vendor prefixes set up for individual
boards to bother tracking them in vendor-prefixes.txt. As a practical
matter, the compatible for the root node doesn't matter anyway. So
just relax our check for that node.
Signed-off-by: Martí Bolívar <marti.bolivar@nordicsemi.no>
