On 11/6/22 11:50 PM, Ulf Samuelsson wrote:
I do think Livius has a point.
I see there confusion and no diagnostics when the system is not working the way
the user is intending. This is a bug I need to fix. I need to identify this
case, and tell the user. (In my mind this is similar to the
"packagegroup.bbclass". If you don't set your package_arch BEFORE inherting the
class, it hard resets everything to "all", which may not be intended.)
I have a similar problem with U-Boot.
If you want to add a defconfig to a U-Boot recipe, the ”Yocto” way is to create
a bbappend which adds
SRC_URI += ”file://defconfig”
which then is used to configure U-Boot
Your recipe check if UBOOT_MACHINE (IIRC) is defined, and if so, you delete the
defconfig.
Then You go ahead and define UBOOT_MACHINE.
UBOOT_MACHINE is always defined and thus the defconfig is always deleted.
You thus remove a key functionality in the U-Bboot recipe.
I think the solution is that UBOOT_MACHINE should not be defined in your recipe.
It should only be defined in MACHINE.conf files.
You should have an error message if no defconfig is defined.
I would agree with this. UBOOT_MACHINE defined in the machine .conf file seems
like the right way to do it. Then it can point to whatever SRC_URI defconfig
has been added.
Calling a new defconfig simply "defconfig" is likely incorrect, as it means that
bbappend can never work with another machine .conf file.. but..
(u-boot-xlnx_%.bbappend)
SRC_URI += "file://my-board_defconfig"
and then UBOOT_MACHINE = "my-board_defconfig"
should work. (I don't do much with u-boot, so if it doesn't, I can hunt this
down further... but I believe that is what is intended.)
While I don't recommend it, I've also seen people do:
SRC_URI:append:pn-u-boot-xlnx = " file://my-board_defconfig"
(as well as adding the path to the file in a similar way via the
FILESEXTRAPATHS...)
--Mark
Best Regards
Ulf Samuelsson
+46 722 427 437
7 nov. 2022 kl. 02:15 skrev Livius <[email protected]>:
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"
<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.
If you make a generic machine.conf it must be a real "generic", it means it
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
<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.
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 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.
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.
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
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 (#5082):
https://lists.yoctoproject.org/g/meta-xilinx/message/5082
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]]
-=-=-=-=-=-=-=-=-=-=-=-
