On 11/6/22 7:15 PM, Livius wrote:
You current generic.conf arhitect are wrong because of this predefined
HDF_MACHINE. For example if i have a custom ZynqMP board or i like to build an
image for ZCU104 why i need let it and get the HDF_MACHINE = "zcu102-zynqmp"
If you use meta-xilinx-tools to process the XSA (generate the device-tree, build
the firmware components) then you need to define the HDF_MACHINE to a valid
configuration _or_ override where the XSA is that you are going to use.
Doing changes in the local.conf (which is what most people keep trying to do) is
wrong. It's not as simple as setting HDF_MACHINE to a different value, but
instead you need to adjust that value, the value of various YAML configurations,
and possibly other settings -- otherwise what is generated won't be correct. So
looking at a simplified version of the configuration I mentioned:
conf/machine/my-bsp.conf:
# preamble
SOC_VARIANT = "ev"
require conf/machine/zynqmp-generic.conf
# Use my XSA, on my local disk in /home/me/my-bsp.xsa
HDF_MACHINE = "my-bsp"
HDF_BASE = "file://"
HDF_PATH = "/home/me/my-bsp.xsa"
UBOOT_MACHINE = "my_bsp_defconfig"
SERIAL_CONSOLES = "115200;ttyPS1"
# postamble
(preamble/postamble are designed to be able to re-use the stuff from the base
machine and allow others to inherit your machine.. thus I skipped for this.)
The above will ensure that you are building for a ZynqMP-EV (which enables
mali400 and vcu support.) Brings in ALL of the configuration settings for
zynqmp-generic as the starting point. And then you manually override everything
that isn't right from the zynqmp-generic for your particular configuration.
When you build you set MACHINE = "my-bsp". This will facilitate sstate-cache
re-use from other similar boards, as well as allow full control (overwrite) of
the values.
<https://github.com/Xilinx/meta-xilinx/blob/master/meta-xilinx-core/conf/machine/zynqmp-generic.conf#L47>
from zynqmp-generic.conf file? Every kind of issue comes from this predefined and
extraneous board machine definitions in HDF_MACHINE for example when i tried to use
your my-example.conf architect i got some random zcu102 dtsi files in my generated
devce-tree working directory, and surprisingly these was included to my top-system
dts. It caused a totaly corrupted custom board dtb thanks to that predefined
HDF_MACHINE from generic.conf files.
I don't understand what issues you are seeing from this statement. If you
overwrite the HDF_MACHINE (after the require line), then the original value
won't (and can't) be used for anything.
HDF_MACHINE itself is only used to make sure that we have the corresponding XSA
that you want to run the builds against. The end result of this is copying the
XSA, either from the hdf-examples repository, your own repository or your own
file, to tmp/deploy/images/<machine>/Xilinx-<machine>.xsa
MACHINE=my-bsp bitbake hdf-examples
You will see the output file there.... It SHOULD be the right one corresponding
to what you set as the input.
The name of the dtsi files and such are generated by 'dtgen' from the items in
meta-xilinx-tools/recipes-bsp/device-tree. 'dtgen' is invoked with the XSA file
that is located in your tmp/deploy/images directory, as well as the components
from: github.com/Xilinx/device-tree-xlnx.git
If you make a generic machine.conf it must be a real "generic", it means it
generic for meta-xilinx-core means it works with QEMU, and may or may not boot
on an ACTUAL physical board. It is also the "generic" definition for others to
start from, and in a situation where you may have multiple boards it also gives
you a point to share sstate-cache for re-use/binary distribution purposes.
never be allowed to store any machine specific feature like HDF_MACHINE =
"zcu102-zynqmp" and never be allowed to use it for any building (for QEMU, make
an other qemu-machine.conf just for QEMU build which requires an abstract
generic.conf), it must works like an abstract class in object oriented
languages. The best can be if you remove HDF_MACHINE totaly from every
generic.conf then let it to be defined in hdf recipe itself. Your
external-hdf.bb
There is nothing anywhere that says that.
https://github.com/Xilinx/hdf-examples/tree/xlnx_rel_v2022.2
I could very easily copy and rename zcu102-zynqmp/system.xsa to
"zynqmp-generic/system.xsa", but why? We still need the device tree generation,
we still need the firmware generations for QEMU -- and since there is no change
to the hardware XSA for the zcu102 we just use it. Whatever inherits (requires)
the generic machine is supposed to override the value and define their own value.
<https://github.com/Xilinx/meta-xilinx-tools/blob/master/recipes-bsp/hdf/external-hdf.bb>
has a nice and mature enough architect to override SRC_URI for a custom internal company"s
repo in a bbappend file, and in this own repo if i use the same folder structure based on my
machine names it works great, just need let and use HDF_MACHINE = ${MACHINE}
<https://github.com/Xilinx/meta-xilinx-tools/blob/master/recipes-bsp/hdf/external-hdf.bb#L90>
which is automaticaly assigned in hdf recipe if there was no any previouse HDF_MACHINE in the
global scope, but now your generic.conf files always spoils this good operation.
Storing XSAs in a git repository is a bad thing. They are binary blobs that
can't be compared to former or future versions. Most of the recent complaints I
have heard from people are exactly opposite. They do NOT want it in any sort of
a git repository, but instead as either a file (downloaded separately) or from a
local server (usually https, which makes me suspect it's artifactory based.)
This is why we have the HDF_BASE and HDF_PATH defined the way we do. We can't
dictate HOW you store your XSAs. But once loaded they get copied into the
tmp/deploy/image and used from there.
We plan to get away from using git for storing and distributing the XSA files.
Some boards are simply getting too large, and there are potentially enough
revisions during out development cycle that it is no longer feasible to store
them that way.
I absolutely not understand why you need a fake HDF_MACHINE pre-defenition like
HDF_MACHINE = "zcu102-zynqmp" in zynqmp-generic.conf file if you like to define
it again in my-example.conf for any different value. Both of them are defined in
We need HDF_MACHINE for any user of meta-xilinx-tools, because we need an XSA
that is compatible with the run-time environment. (For -generic this is
primarily QEMU.)
global scope and it is not predictable which and when will be active for any
further recipes. You must use any weak assigning like "?=" or "??=" if you must
to do it. Current "=" assigning is not a nice, it forbidden to do a variable
assigning twice in global scope of Yocto, do not be surprised if everybody has
any issue after that.
Where is this forbidden? The whole order of the require/include system is
defined. You include the default and you override the default with a new value.
As I've said, we've had significant support issues with people using the
"generic" machines, but simply overriding HDF_MACHINE and then not understanding
why it doesn't work. (with a weak or no assignment HDF_MACHINE.)
Maybe what is needed here is a check to see if you are not getting the
HDF_MACHINE you expect, and a stop and error situation. That I could implement
quite easily.
Because i totaly not understand why need it in generic.conf file, ok let stay
them here, but i did this patch to make a weak definition, which will be totaly
overridable in my-example.conf for HDF_MACHINE = ${MACHINE}, in my own way. Many
issue will be solved for which caused by the concurent variable assigning in
global scope.
bitbake -e will show the variable definition order. So in my example above,
MACHINE=my-bsp bitbake -e shows:
# $HDF_MACHINE [2 operations]
# set /scratch2/fray/git/xlnx/meta-xilinx/meta-xilinx-core/conf/machine/zynqmp
-generic.conf:47
# "zcu102-zynqmp"
# set /scratch2/fray/git/xlnx/build-honister/conf/machine/my-bsp.conf:8
# "my-bsp"
# pre-expansion value:
# "my-bsp"
HDF_MACHINE="my-bsp"
So it is defined exactly as I expect it to be.
In summarized the following scenarios does not work and can not produce a
working board image because of your HDF_MACHINE = "zcu102-zynqmp", so your
current my-example.conf is not usable in the user applications:
my-example.conf -> zynqmp-generic.conf
The above shows if the order is correct it will work. What is lacking is a
clear error message when the order is not specified properly and you don't get
what you are expecting.
I can implement a check that should be able to find this.. Something like
zynqmp-generic.conf:
HDF_MACHINE_PRIOR := "${HDF_MACHINE}"
(prior to it setting HDF_MACHINE)
then in a class:
python () {
prior = d.getVar("HDF_MACHINE_PRIOR")
final = d.getVar("HDF_MACHINE")
if prior and prior != final:
bb.error("HDF_MACHINE (%s) is not set to what you probably intended
(%s). It should be set after any include/requires in your machine .conf file.
See: meta-xilinx-core/conf/machine", (final, prior))
}
--Mark
Following works, not need any HDF_MACHINE assigning in my-example.conf, and some
further general variable need to be defined as was in generic.conf:
my-example.conf -> soc-zynqmp.inc, machine-xilinx-default.inc
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#5081):
https://lists.yoctoproject.org/g/meta-xilinx/message/5081
Mute This Topic: https://lists.yoctoproject.org/mt/94844586/21656
Group Owner: [email protected]
Unsubscribe: https://lists.yoctoproject.org/g/meta-xilinx/unsub
[[email protected]]
-=-=-=-=-=-=-=-=-=-=-=-
