I do think Livius has a point. 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. 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" 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 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} 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 (#5079): https://lists.yoctoproject.org/g/meta-xilinx/message/5079 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]] -=-=-=-=-=-=-=-=-=-=-=-
