[meta-xilinx] [PATCH 3/9] meta-xilinx-standalone: Create layer, distro and machine to build standalone components
Manjukumar Harthikote Matha
MANJUKUM at xilinx.com
Fri Dec 28 11:47:38 PST 2018
Hi Luca,
> -----Original Message-----
> From: Luca Ceresoli [mailto:luca at lucaceresoli.net]
> Sent: Thursday, December 20, 2018 2:44 AM
> To: Manjukumar Harthikote Matha <MANJUKUM at xilinx.com>; Alejandro Enedino
> Hernandez Samaniego <alejandr at xilinx.com>; meta-xilinx at yoctoproject.org
> Cc: Mike Looijmans <mike.looijmans at topic.nl>
> 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:luca at lucaceresoli.net]
> >> Sent: Tuesday, December 18, 2018 7:26 AM
> >> To: Alejandro Enedino Hernandez Samaniego <alejandr at xilinx.com>; meta-
> >> xilinx at yoctoproject.org
> >> Cc: Mike Looijmans <mike.looijmans at topic.nl>; Manjukumar Harthikote Matha
> >> <MANJUKUM at xilinx.com>
> >> 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
> >>>>> <alejandr at xilinx.com>
> >>>>> Signed-off-by: Manjukumar Matha
> >>>>> <manjukumar.harthikote-matha at xilinx.com>
> >>>>> ---
> >>>>> 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
More information about the meta-xilinx
mailing list