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 (#5078): https://lists.yoctoproject.org/g/meta-xilinx/message/5078 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]] -=-=-=-=-=-=-=-=-=-=-=-
