Hi Mark,
The problem is solved.
My custom machine was setting DEFAULTTUNE="cortex53" which was there in
order to address the issue of devtool with paths when dealing with
u-boot. I haven't checked if the devtool issue was solved, however,
removing the DEFALTTUNE allows me to progress with the
multi-configuration issue I reported in this thread.
Regards,
Adrian
On 16.08.2021 12:51, Adrian Fiergolski wrote:
> Hi Mark,
>
> Thank you for your prompt reply.
>
> Unfortunately, I haven't managed to make it run yet. Have you tested
> multiconfig with any Xilinx machine configuration (e.g.
> zcu102-zynqmp.conf)? Could you then share you configuration (used image,
> local.conf, command, etc.). I would have then a good reference point to
> look for differences between it and my custom machine and image.
>
> I am using meta-xilinx in version
> HEAD:21f495ec085cade7a28bd402f2acbbed7e550189 (I think it's the last and
> the only in the repo which actually supports hardknott), meta (poky) in
> version hardknott:3f9e8dfde19f62bfda2308437f18fca58d7363e9 and meta-oe
> in version hardknott:5a4b2ab29d38c02535f24d5308cc40615739f557.
>
> My intention (successful so far) is to not have any dependencies on
> Xilinx tools (thus I exclude the use of meta-xilinx-tools, etc.).
>
> Regards,
>
> Adrian
>
> On 13.08.2021 21:21, Mark Hatle wrote:
>>
>> On 8/13/21 1:27 PM, Adrian Fiergolski wrote:
>>> Hi Mark,
>>>
>>> I use U-Boot SPL, so the u-boot binary includes pmu-firmware. In my
>>> case, the U-Boot SPL injects also the PM configuration object. So far
>>> (gatesgarth), u-boot had multiconfig dependency:
>>>
>>> do_compile[mcdepends] = "multiconfig::pmu:pmu-firmware:do_deploy"
>> This is the standalone version of pmu-firmware. If you have the board
>> configuration data, xsa or similar. It's recommended you use the
>> meta-xilinx-tools version instead. This generated a pmu-firmware that
>> is specific to your board. (May be smaller or more feature rich then
>> the generic one.)
>>
>> BTW the format above is 'old' style. It might still work, but the
>> current recommended format is:
>>
>> mc::<config>:<recipe>:<task>
>>
>> (be sure to read to the end, as you may be able to skip all of this
>> complexity, but using pmufw instead.)
>>
>> Note, if you are using zynqmp-generic, or including soc-zynqmp.inc in
>> your custom BSP, there is an easier way to do this:
>>
>> do_compile[depends] += "${PMU_DEPENDS}"
>> do_compile[mcdepends] += "${PMU_MCDEPENDS}"
>>
>> Note, doing it like the above will ensure your code works for
>> pmu-firmware from BOTH meta-xilinx-tools, and the standalone version.
>> The build environments are different, thus the different dependency
>> models.
>>
>>> and thinks worked smoothly.
>>>
>>> I aligned the names and the local.conf with your new naming (according
>>> to meta-xilinx-standalone). So, the new dependency is:
>>>
>>> do_compile[mcdepends] =
>>> "multiconfig:microblaze-zynqmp-pmu:zynqmp-pmufw:pmu-firmware:do_deploy"
>> You need to add the multiconfig to your system, should be a basic
>> example:
>>
>> https://github.com/Xilinx/meta-xilinx/blob/master/meta-xilinx-standalone/README.md
>>
>>
>> Two pre-configured multiconfigs exist. zynqmp-pmufw and versal-fw.
>> You will need to activate the one that matches your confiuration:
>>
>> local.conf:
>>
>> BBMULTICONFIG += "zynqmp-pmufw"
>>
>>> However, after your work, I get an error when I try to build an image
>>> for zynqmp:
>>>
>>> NOTE: Resolving any missing task queue dependencies
>>> ERROR: Nothing PROVIDES 'pmu-firmware'
>>> pmu-firmware was skipped: incompatible with host aarch64-poky-linux (not
>>> in COMPATIBLE_HOST)
>>> pmu-firmware was skipped: incompatible with host aarch64-xilinx-elf (not
>>> in COMPATIBLE_HOST)
>>> pmu-firmware was skipped: incompatible with host aarch64-xilinx-elf (not
>>> in COMPATIBLE_HOST
>> You don't have something configured properly. The zynqmp-pmufw
>> multiconfig:
>>
>> https://github.com/Xilinx/meta-xilinx/blob/gatesgarth/meta-xilinx-standalone/conf/multiconfig/zynqmp-pmufw.conf
>>
>>
>> It sets your 'DISTRO' to xilinx-standalone, as well as the DEFAULTTUNE
>> to 'microblaze' (with some specific tuning options).
>>
>> The message above looks like both DISTRO was not set, as well as the
>> architecture was set to aarch64 instead. So it didn't load the
>> multiconfig.
>>
>> You should be able to verify using:
>>
>> bitbake mc:zynqmp-pmufw:pmu-firmware
>>
>> (yes this format is slightly different then the mcdepends format above.)
>>
>>> How should I address that?
>>>
>>> U-Boot is properly looking for
>>> ..tmp-microblaze-zynqmp-pmufw/deploy/images/falcon-zynqmp/pmu-firmware-zynqmp-pmu.bin
>>>
>>> which hasn't been built yet.
>> The file that u-boot should look for is captured by
>> "PMU_FIRMWARE_IMAGE_NAME", and the file exists in
>> PMU_FIRMWARE_DEPLOY_DIR -- if you are going to directly incorporate
>> the files from the multiconfig. OTHERWISE, if you instead depend on
>> the recipe 'pmufw' (in the regular non-multiconfig context). It will
>> handle everything I said above for you, and the output will end up the
>> regular deploy dir, under the PMU_FIRMWARE_IMAGE_NAME filename. This
>> is the recommended way to do it.
>>
>> So, my recommendation is:
>>
>> u-boot:
>>
>> DEPENDS += "pmufw"
>> do_compile[depends] += "pmufw:do_deploy"
>>
>> local.conf:
>> BBMULTICONFIG += "zynqmp-pmufw"
>>
>>
>> Doing the above, both meta-xilinx-standalone and meta-xilinx-tools
>> implementations will work, and be completely transparent to the rest
>> of the system.
>>
>> --Mark
>>
>>> Regards,
>>>
>>> Adrian
>>>
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#4906):
https://lists.yoctoproject.org/g/meta-xilinx/message/4906
Mute This Topic: https://lists.yoctoproject.org/mt/84870075/21656
Group Owner: [email protected]
Unsubscribe: https://lists.yoctoproject.org/g/meta-xilinx/unsub
[[email protected]]
-=-=-=-=-=-=-=-=-=-=-=-
