Hi Manjukumar, Alejandro,
On 19/12/18 04:28, Manjukumar Harthikote Matha wrote:
> 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.
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
--
_______________________________________________
meta-xilinx mailing list
[email protected]
https://lists.yoctoproject.org/listinfo/meta-xilinx
