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

[Luca Ceresoli]

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.

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.

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?

Thanks,
-- 
Luca