On 12/9/24 7:39 PM, Chris Laplante via lists.yoctoproject.org wrote:
Hi Mark,
That is extremely helpful - thank you for the quick and comprehensive response
:). More comments below...
3) Add a device-tree.bbappend and add to the device-tree whatever value(s)
you need. If you want to use the Linux kernel sources for your device-tree, you
can "restore" the lines that were disabled in the devicetree class:
...
KERNEL_INCLUDE ??= " \
${STAGING_KERNEL_DIR}/arch/${ARCH}/boot/dts \
${STAGING_KERNEL_DIR}/arch/${ARCH}/boot/dts/* \
${STAGING_KERNEL_DIR}/scripts/dtc/include-prefixes \
"
(the python block runs AFTER the variables are processed, so the bbappend
approach works fine.)
Yep, this is exactly how I did it initially, but it felt dirty.
We set it up specifically to allow this, if needed.
In the end it comes down to:
Either the input to the Yocto Project build needs to be pre-processed (no
includes needed) or you need to add paths to the include files in the
device-tree recipe, either via the KERNEL_INCLUDE or there is a second variable
that just adds hard coded include paths without the side effect of bringing in
the kernel dependency, DT_FILES_PATH it appears.
For best results the files/directories referred to by DT_FILES_PATH should be
made available via a bbappend and be inside of the recipe WORKDIR.
But speaking more toward your specific example of the gpio stuff. There IS a
copy of the gpio.h file inside of the device-tree repository. (More on that
below)
I sort of get the impression that the DTS coming from
gen-machineconf/lopper are not intended to be hand edited? (they've
got phandles for some reason, which are just noise)
The workflow we designed is:
Vivado -> XSA
XSA -> SDTGen -> SDT artifacts
(SDT artifacts can modify them here)
SDT artifacts -> gen-machine-conf -> YP config & domain DTS
(YP config & domain DTS files can be modified here)
YP build
In the two places above where the artifacts can be modified, we highly
recommend NOT modifying things by hand. Instead write a script to do it in a
reproducible way. We expect that every time you regenerate your XSA you will
need to go through the process, including SDTGen and gen-machine-conf, so
being able to apply your customization in an automated approach really is what
you want.
I think I see. For example, if I am adding an I2C GPIO expander (which needs
some defines from the #include), then I could write a script which adds it to
the bus and feed that to gen-machine-conf? Assuming that's right, are there any
examples of such scripts? I can't find any arguments (in
https://github.com/Xilinx/gen-machine-conf/blob/main/gen-machineconf) where I
might pass them.
gen-machine-conf itself just gets the input of the SDT artifacts. So to add an
expander you would modify the artifacts between sdtgen and gen-machine-conf. (I
think this will work, I've not done it.)
Then when gen-machine-conf processes things, it should flatten (cpp) the files
as well as move the information to the right domain(s). What you need to look
out for is that the transformation stuff does infact move your added nodes to
the preprocessed domain files. If it doesn't then modifying AFTER
gen-machine-conf is the only way.
Regarding scripting the XSA -> SDT step, I suppose that the purpose there is
for transformations/modifications that are applicable to all domains (e.g. FSBL,
not just Linux)?
Yes, for ZynqMP (MPSoc) that would be FSBL, PMU, and any baremetal r5 (or
cortex-a) as well as Linux.
For our reference boards, we have a script that generates the design (XSA) and a
script that converts it to an SDT artifact. The scripts are then run via
automation based on new versions of Vivado, changes to the reference board
design or a manual timed process.
So if you need to customize (or synchronize?) the gpio.h with your
development, I think it can be done early as a patch to the SDTGen device-tree
repository that is being used, then everything "should" flow through the system
automatically. (Note, I've never done this, but it's my understanding of how
you can approach this.)
I won't need to modify gpio.h - rather, just utilize its #defines in my own
bindings.
If you use the gpio.h before gen-machine-conf flattens things, then all of the
parts and pieces can exist in the sdt artifacts, when lopper and cpp run the
dependency is removed, while the information is retained.
A little guidance would be appreciated.
Hopefully the above helps. I'm far from an expert on DTS files and how they
should be done. I tried to influence the overall workflow in a way that both
beginners and experts can find it useful. If you have suggestions, please let
us
know.
I think it helps a lot, so thanks again :)
One final note, we're also aware of some situations where you may need
multiple device-trees (at the same time) for different board revisions. At this
point I don't have good suggestions how to manage this. Best I can suggest is
run gen-machine-conf multiple times, manually copy out the device-trees you
want and then create a custom device-tree recipe that builds and packages
them all however you need them. (This is far from simply unfortunately.)
I'll need to do something like this internally soon - I'll let you know what I
decide on. To be honest, I might end up hijacking the device-tree recipe via
bbappend to apply some .dtsi overlays.
We've done something similar before as well. It all depends on how you are
managing your device-trees, the board revision specific changes, and how you
want this stuff to be applied....
i.e. You can play games in u-boot, embed into a fit image multiple device trees
and add device selection code to early u-boot so it loads the "right" device
tree based on a SPI or something.
or
If the bits u-boot needs are generic, you can just embed a single device tree,
and build dtbo's that capture the differences in the different revisions and
load those via a u-boot script.
In the former case, you have to do this if u-boot needs to either instantiate or
use the revision specific devices, in the later case it's easier to add more
revisions and such in the future -- but likely can't be used for i2c, DDR setup,
etc.
We've really not come up with, what I consider, a good way to do this. Just
there are different ways for different users, none are overly easy to manage.
Most of the work up to this point has focused on the 1 XSA -> 1 SDT -> 1 'boot
image'. Since that seems to be the majority of our customer needs. We know
there is a sizeable set of customers (including our internal SOM Kria) that
needs the multiple device-tree, and selection based on boot. So far every
implementation of this has been very very custom to the specific device and not
something we've been able to successfully generalize. (But we're working on it!)
--Mark
Thanks,
Chris
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#5506):
https://lists.yoctoproject.org/g/meta-xilinx/message/5506
Mute This Topic: https://lists.yoctoproject.org/mt/110007484/21656
Group Owner: [email protected]
Unsubscribe: https://lists.yoctoproject.org/g/meta-xilinx/unsub
[[email protected]]
-=-=-=-=-=-=-=-=-=-=-=-
