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

[Luca Ceresoli]

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.

I still hope there is a solution and my understanding is just limited...


Can you suggest how to differentiate the binary pmu-firmware? Otherwise
how would you handle different boards with different pmu configs? And,
ultimately, how would you pass the pmu config to the pmufw with an
U-Boot SPL workflow?

Thanks.


[0]
https://github.com/topic-embedded-products/meta-topic/blob/706f74c9cd5fcf398ff24ee77962ebfe23340998/recipes-bsp/pmu-firmware/pmu-firmware_2017.1.bbappend

-- 
Luca