Hi Manjukumar,
On 28/12/18 20:47, Manjukumar Harthikote Matha wrote:
> Hi Luca,
>
>> -----Original Message-----
>> From: Luca Ceresoli [mailto:l...@lucaceresoli.net]
>> Sent: Thursday, December 20, 2018 2:44 AM
>> To: Manjukumar Harthikote Matha <manju...@xilinx.com>; Alejandro Enedino
>> Hernandez Samaniego <aleja...@xilinx.com>; meta-xilinx@yoctoproject.org
>> Cc: Mike Looijmans <mike.looijm...@topic.nl>
>> Subject: Re: [meta-xilinx] [PATCH 3/9] meta-xilinx-standalone: Create layer,
>> distro
>> and machine to build standalone components
>>
>> Hi Manjukumar, Alejandro,
>>
>> On 19/12/18 04:28, Manjukumar Harthikote Matha wrote:
>>> Hi Luca,
>>>
>>>> -----Original Message-----
>>>> From: Luca Ceresoli [mailto:l...@lucaceresoli.net]
>>>> Sent: Tuesday, December 18, 2018 7:26 AM
>>>> To: Alejandro Enedino Hernandez Samaniego <aleja...@xilinx.com>; meta-
>>>> xil...@yoctoproject.org
>>>> Cc: Mike Looijmans <mike.looijm...@topic.nl>; Manjukumar Harthikote Matha
>>>> <manju...@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
>>>>>>> <aleja...@xilinx.com>
>>>>>>> Signed-off-by: Manjukumar Matha
>>>>>>> <manjukumar.harthikote-ma...@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.
>>
>
> Even in this setup, how are you passing the pmu_cfg_obj to pmu-firmware
> build?
> I am assuming you are patching it using
> https://github.com/topic-embedded-products/meta-topic/blob/master/recipes-bsp/pmu-firmware/pmu-firmware_2017.%25.bbappend#L14
Yes, I'm using Mike's trick.
>> 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.
>>
>
> If the patching is done similar way then pmu-firmware create in one build
> will correspond to that particular machine build.
> Agreed that you cannot deploy different pmu-firmware because config objects
> are different per board.
> One work-around is to have pmutmp different per board during multiconfig
> build or have different pmu machines (not the generic zynqmp).
Yes, I think this could work.
> Or We could also extend the do_deploy function in pmu-firmware to include the
> machine name(zcu102,zcu106) in the deployed image
How would you do that? When building pmu-firmware, the MACHINE is always
"zynqmp-pmu". Adding some extra variable in local/multiconfig/pmu.conf?
However that's not much relevant to me anymore as in the end I ditched
the whole multiconfig setup and I'm now using the second way from [0]
("Build each distro independently"). Besides the issues mentioned in
this thread multiconfig is overly slow, has additional complexity and
breaks some existing tools ('bitbake-layers show-recipes -i').
[0]
https://lists.yoctoproject.org/pipermail/meta-xilinx/2018-November/004087.html
Thanks,
--
Luca
--
_______________________________________________
meta-xilinx mailing list
meta-xilinx@yoctoproject.org
https://lists.yoctoproject.org/listinfo/meta-xilinx
