[meta-xilinx] [PATCH 3/9] meta-xilinx-standalone: Create layer, distro and machine to build standalone components

Tue Dec 18 19:28:12 PST 2018

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.
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)

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

<..>

Thanks,
Manju