Hi Luca, > -----Original Message----- > From: Luca Ceresoli [mailto:[email protected]] > Sent: Thursday, December 20, 2018 2:44 AM > To: Manjukumar Harthikote Matha <[email protected]>; Alejandro Enedino > Hernandez Samaniego <[email protected]>; [email protected] > Cc: Mike Looijmans <[email protected]> > Subject: Re: [meta-xilinx] [PATCH 3/9] meta-xilinx-standalone: Create layer, > distro > and machine to build standalone components > > Hi Manjukumar, Alejandro, > > On 19/12/18 04:28, Manjukumar Harthikote Matha wrote: > > Hi Luca, > > > >> -----Original Message----- > >> From: Luca Ceresoli [mailto:[email protected]] > >> Sent: Tuesday, December 18, 2018 7:26 AM > >> To: Alejandro Enedino Hernandez Samaniego <[email protected]>; meta- > >> [email protected] > >> Cc: Mike Looijmans <[email protected]>; Manjukumar Harthikote Matha > >> <[email protected]> > >> Subject: Re: [meta-xilinx] [PATCH 3/9] meta-xilinx-standalone: Create > >> layer, > distro > >> and machine to build standalone components > >> > >> Hi Alejandro, Manju, > >> > >> On 11/12/18 23:16, Alejandro Enedino Hernandez Samaniego wrote: > >>> Hey Luca, > >>> > >>> > >>> On 12/11/2018 07:41 AM, Luca Ceresoli wrote: > >>>> Hi Alejandro, > >>>> > >>>> On 06/12/18 22:56, Alejandro Enedino Hernandez Samaniego wrote: > >>>>> This layer is meant to augment Yocto/OE functionality to provide a > >>>>> toolchain to build standalone components for Xilinx architectures. > >>>>> > >>>>> Signed-off-by: Alejandro Enedino Hernandez Samaniego > >>>>> <[email protected]> > >>>>> Signed-off-by: Manjukumar Matha > >>>>> <[email protected]> > >>>>> --- > >>>>> meta-xilinx-standalone/README.md | 56 > >>>>> ++++++++++++++++++++++ > >>>>> .../conf/distro/xilinx-standalone.conf | 12 +++++ > >>>>> meta-xilinx-standalone/conf/layer.conf | 14 ++++++ > >>>>> .../conf/machine/zynqmp-pmu.conf | 11 +++++ > >>>>> 4 files changed, 93 insertions(+) > >>>>> create mode 100644 meta-xilinx-standalone/README.md > >>>>> create mode 100644 > >>>>> meta-xilinx-standalone/conf/distro/xilinx-standalone.conf > >>>>> create mode 100644 meta-xilinx-standalone/conf/layer.conf > >>>>> create mode 100644 > >>>>> meta-xilinx-standalone/conf/machine/zynqmp-pmu.conf > >>>>> > >>>>> diff --git a/meta-xilinx-standalone/README.md > >>>>> b/meta-xilinx-standalone/README.md > >>>>> new file mode 100644 > >>>>> index 0000000..da7f4e1 > >>>>> --- /dev/null > >>>>> +++ b/meta-xilinx-standalone/README.md > >>>>> @@ -0,0 +1,56 @@ > >>>>> +meta-xilinx-standalone > >>>>> +===================== > >>>> Nitpick: there should be an extra '='. > >>>> > >>>> [...] > >>>>> +Dependencies > >>>>> +============ > >>>>> + > >>>>> +This layer depends on: > >>>>> + > >>>>> + URI: git://git.yoctoproject.org/poky > >>>>> + > >>>>> + URI: git://git.yoctoproject.org/meta-xilinx > >>>> That's the repo, not the layer. Maybe clarify as: > >>>> > >>>> URI: git://git.yoctoproject.org/meta-xilinx -> meta-xilinx-bsp > >>>> layer > >>> True > >>> > >>>> > >>>>> +Usage > >>>>> +===== > >>>>> + > >>>>> +1.- Clone this layer along with the specified layers > >>>>> + > >>>>> +2.- $ source oe-init-build-env > >>>>> + > >>>>> +3.- Add this layer to BBLAYERS on conf/bblayers.conf > >>>>> + > >>>>> +4.- Add the following to your conf/local.conf to build for the > >>>>> microblaze architecture: > >>>>> + > >>>>> +DISTRO="xilinx-standalone" > >>>>> + > >>>>> +MACHINE="zynqmp-pmu" > >>>> To the best of my knowledge, to use U-Boot SPL people link the > >>>> pm_cfg_obj.c file in the pmufw binary and then patch the pmufw code > >>>> to load that config object instead of getting it via smc calls [0]. > >>>> This makes pmufw binary machine-specfic. > >>>> > >>>> How do you think the same goal should be obtained with the new > >>>> "zynqmp-pmu" machine? > >>> Unless I'm not understanding this correctly, using MACHINEOVERRIDES > >>> should do it > >> > >> I don't think this can be done with MACHINEOVERRIDES. Let me explain better > what > >> I mean. > >> > >> In my current rocko setup, there are multiple machines defined in my > >> layer. Let's > call > >> then "foo" and "bar": > >> > >> $ ls meta-mylayer/conf/machine/ > >> foo-zynqmp.conf > >> bar-zynqmp.conf > >> $ > >> > >> Then there is a recipe (say my-hdl.bb) that copies pm_cfg_obj.c in the > >> sysroot. > The > >> copied file is different file for each MACHINE. This recipe has > >> PACKAGE_ARCH = > >> "${MACHINE_ARCH}", so different cfg objects go in different directories. > >> > >> Finally I have a pmu-firmware_%.bbappend that is similar to Mike's [0], > >> with the > >> difference that it takes the pm_cfg_obj.c file from staging where > >> my-hdl.bb has > >> copied it: > >> > >> do_configure[depends] = "my-hdl:do_populate_sysroot" > >> do_configure_append() { > >> sed > >> 's!"pm_defs.h"!"../../../sw_services/xilpm/src/common/pm_defs.h"!' \ > >> > >> > >> ${STAGING_DIR_TARGET}/usr/share/my-hdl/pm_cfg_obj.c \ > >> > pm_cfg_obj.c > >> > >> } > >> > >> > >> > >> This way a different pmufw is build for each MACHINE, each with a > >> hard-coded > >> pm_cfg_obj.c specific for that machine (note that pmu-firmware is also > >> PACKAGE_ARCH = "${MACHINE_ARCH}"). > >> > >> > >> With the new multiconfig setup, the pmu-firmware is always built for the > "zynqmp- > >> pmu" MACHINE. And since the applied MACHINEOVERRIDES depend on the > >> MACHINE, in the xilinx-standalone layer you can not differentiate foo and > >> bar > based > >> on the MACHINE. For the same reason PACKAGE_ARCH = "${MACHINE_ARCH}" > does > >> not help. > >> > >> I did some experiments adding to pmu-firmware_2018.3.bbappend the line: > >> > >> do_configure[mcdepends] = \ > >> "multiconfig:pmu:foo:my-hdl:do_populate_sysroot" > >> > >> And now pmu:pmu-firmware depends on my-hdl, but I'm still unable to get > different > >> pmu-firmwares built for e.g. foo and bar. > >> > > > > If your my-hdl recipe is machine specific meaning, my-hdl generates config > > based > on machine (like zcu102, zcu106, foo etc) it should work. I am not sure why > that > wouldn’t work. > > The my-hdl works correctly. > > > I am assuming that: my-hdl is machine specific config generator recipe and > > belongs > under meta-xilinx-bsp not meta-xilinx-standalone layer. The above multiconfig > dependency you have will enable pmu to depend on my-hdl and will also need > some > TMP wiring to fetch the config (since it will be under zcu102/106/foo tmp dir > which is > different from pmu tmp directory) > > Right: my-hdl is actually in my own top-level layer, but it is in the > "meta-xilinx-bsp domain", i.e. it has MACHINE like zcu102, zcu106 and > similar. It is not related to meta-xilinx-standalone or the zynqmp-pmu > MACHINE. > > > If you need the my-hdl recipe under meta-xilinx-standalone then you will > > need to > write a python snippet in my-hdl to figure out whether it is for zcu102 or > zcu106 or > foo machine and build the appropriate configs. You will not need any > multiconfig for > this approach, however you will need some image dependency on my-hdl for > zynqmp-pmu.conf > > Seems like my latest explanation using MACHINE and MACHINEOVERRIDES was > not good. Let me rephrase speaking about directories. > > In my rock setup I had, under the build directory: > > tmp/work/ > |-- zcu106_zynqmp-poky-linux/my-hdl/${PV}/sysroot-destdir/ > | `-- usr/share/my-hdl/pm_cfg_obj.c (A) > |-- zcu106_zynqmp-poky-linux/my-u-boot/${PV}/recipe-sysroot/ > | `-- usr/share/my-hdl/pm_cfg_obj.c (A) > |-- zcu106_zynqmp-poky-elf/zynqmp-pmu-pmu-firmware/${PV}/ > | `-- deploy-zynqmp-pmu-pmu-firmware/ > | `-- pmu-firmware--${PV}-zcu106-zynqmp-<TIME>.bin (A) > |-- zcu102_zynqmp-poky-linux/my-hdl/${PV}/sysroot-destdir/ > | `-- usr/share/my-hdl/pm_cfg_obj.c (B) > |-- zcu102_zynqmp-poky-linux/my-u-boot/${PV}/recipe-sysroot/ > | `-- usr/share/my-hdl/pm_cfg_obj.c (B) > `-- zcu102_zynqmp-poky-elf/zynqmp-pmu-pmu-firmware/${PV}/ > `-- deploy-zynqmp-pmu-pmu-firmware/ > `-- pmu-firmware--${PV}-zcu102-zynqmp-<TIME>.bin (B) > > Files marked with (A) are specific for zcu106, (B) for zcu102. For the > two boards there are different pm_cfg_obj.c and differenf pmufw binaries > in different directories. >
Even in this setup, how are you passing the pmu_cfg_obj to pmu-firmware build? I am assuming you are patching it using https://github.com/topic-embedded-products/meta-topic/blob/master/recipes-bsp/pmu-firmware/pmu-firmware_2017.%25.bbappend#L14 > With the xilinx-bsp + xilinx-standalone thud setup I would have: > > tmp/work/ > |-- zcu106_zynqmp-poky-linux/my-hdl/${PV}/sysroot-destdir/ > | `-- usr/share/my-hdl/pm_cfg_obj.c (A) > |-- zcu106_zynqmp-poky-linux/my-u-boot/${PV}/recipe-sysroot/ > | `-- usr/share/my-hdl/pm_cfg_obj.c (A) > |-- zcu102_zynqmp-poky-linux/my-hdl/${PV}/sysroot-destdir/ > | `-- usr/share/my-hdl/pm_cfg_obj.c (B) > |-- zcu102_zynqmp-poky-linux/my-u-boot/${PV}/recipe-sysroot/ > | `-- usr/share/my-hdl/pm_cfg_obj.c (B) > `-- microblazeel-v9.2-bs-cmp-xilinx-elf/pmu-firmware/ > `-- ${PV}/deploy-pmu-firmware/ > `-- pmu-firmware--${PV}-zynqmp-pmu-<TIME>.bin (?) > > (A) and (B) mark the different boards as before, and there are still two > different pm_cfg_obj.c files in two directories. But there is only one > pmufw binary. Which pm_cfg_obj.c does it have linked? Presumably it > depends on whether which board has been built first... or last...? But > definitely there cannot be two different pmufw binaries in only one > directory. > If the patching is done similar way then pmu-firmware create in one build will correspond to that particular machine build. Agreed that you cannot deploy different pmu-firmware because config objects are different per board. One work-around is to have pmutmp different per board during multiconfig build or have different pmu machines (not the generic zynqmp). Or We could also extend the do_deploy function in pmu-firmware to include the machine name(zcu102,zcu106) in the deployed image > I hope the problem it clear now. > > And the overall question is still: how do you think one should pass the > config object to the PMUFW when using the U-Boot SPL workflow? I use Mike's patch but don’t use different config objects. Thanks, Manju -- _______________________________________________ meta-xilinx mailing list [email protected] https://lists.yoctoproject.org/listinfo/meta-xilinx
