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.
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
-- 
_______________________________________________
meta-xilinx mailing list
[email protected]
https://lists.yoctoproject.org/listinfo/meta-xilinx

Reply via email to