Re: [meta-xilinx] Clarification on pmu_cfg_obj handling for zynqmp boards
Hi Luca, > -Original Message- > From: Luca Ceresoli [mailto:l...@lucaceresoli.net] > Sent: Wednesday, January 23, 2019 7:13 AM > To: Scott Ellis ; Manjukumar Harthikote Matha > ; meta-xilinx@yoctoproject.org > Subject: Re: [meta-xilinx] Clarification on pmu_cfg_obj handling for zynqmp > boards > > Hi Scott, > > On 23/01/19 11:12, Scott Ellis wrote: > > Hi Manju, > > > > Thanks for answering. > > > > I will look at the meta-xilinx-tools layer. I think I finally > > understand what is required to boot. > > > > But I am still not clear on the meta-xilinx multiconfig... > > Just to make sure we are on the same page, there are mainly two workflows with > respect to booting on ZynqMP: using the Xilinx-specific bootloader (FSBL) and > tools > (meta-xilinx-tools layer), OR using U-Boot SPL and a more standard yocto > setup. A > few more details in section "Booting" here [0]. > > I suggest you first choose the workflow that is best for your needs. > > > The meta-xilinx-bsp/README.building.md has no mention that a patch is > > required to the pmu-firmware which is confusing. > > > > Is this just an omission? > > > > Is the pmu-firmware recipe useful without the patch? > > Short answer: only with the Xilinx workflow. > > Long answer: > > The pmufw needs a "configuration object" to know what it should do, and it > expects > to receive it at runtime. > > In the Xilinx workflow the FSBL has a file called pm_cfg_obj.c built into > itself. It is the > PMUFW configuration object, and FSBL passes it to PMUFW at runtime. > > With the U-Boot SPL workflow there's no FSBL, and there are two problems: > 1) passing a cfg obj to pmufw is just not implemented in U-Boot > 2) the pm_cfg_obj.c file is generated by the Xilinx XSDK and its > license is not compatible with the GPL license of U-Boot > > Clearly problem 2 prevents from fixing problem 1. :( > > To work around this problem a small patch has been developed so that > pm_cfg_obj.c > is linked into pmufw and loaded directly, without waiting for it from the > outside. Find > the original patch on the meta-topic layer [1] and the patch updated for pmufw > 2018.x here [2]. > > > Excuse the dumb questions. > > As you might guess from the reply, that was clearly not dumb at all! :) > > Hope it helps. > > [0] > https://archive.fosdem.org/2018/schedule/event/arm64_and_fpga/attachments/sli > des/2564/export/events/attachments/arm64_and_fpga/slides/2564/zynqmp_linux.p > df > > [1] > https://github.com/topic-embedded-products/meta-topic/blob/master/recipes- > bsp/pmu-firmware/pmu-firmware_2017.%25.bbappend > > [2] > https://github.com/lucaceresoli/zynqmp-pmufw-builder/blob/master/0001-Load- > XPm_ConfigObject-at-boot.patch > Thanks for the information. I will add this to README Did you happen to get ZCU106 booting with config object as zcu102? Thanks, Manju -- ___ meta-xilinx mailing list meta-xilinx@yoctoproject.org https://lists.yoctoproject.org/listinfo/meta-xilinx
Re: [meta-xilinx] Clarification on pmu_cfg_obj handling for zynqmp boards
Hi Scott, On 23/01/19 17:06, Scott Ellis wrote: > Hi Luca, > > What you describe is how I understand things. > > And I do have a booting system using the patch to the pmu-firmware and a > pm_cfg_obj.c the customer provided. > > And I have also used a boot.bin produced by the xilinx tools by the > customer with fsbl, pmu, etc... embedded. And that works fine too. > > I think I get the gist of things. > > What I am confused about is the usefulness of the meta-xilinx-standalone > layer and the pmu-firmware in particular without patches. > > I don't think the license on the xilinx tool generated pm_cfg_obj.c > matters too much. > > I wasn't suggesting the pm_cfg_obj.c be included in the layer since > every board probably needs it's own version anyway. > > I was just asking about the patch to pm_binding.c to load an internal > config object. Shouldn't this be included? > > I think it was you that suggested that the pmu-firmware recipe or > another new recipe could go out and fetch the pm_cfg_obj.c file from > somewhere else before the pmu-firmware compile step. Yes, this kind of workflow used to work fine before meta-xilinx-standalone was introduced. One could have a recipe in its own user layer providing a different pm_cfg_obj.c for each MACHINE plus a bbappend to tell pmu-firmware how to fetch that file. Now it is not quite possible anymore. This was discussed in this mailing list, in the end [0] Manjukumar proposed a workaround (one pmutmp per board/config) which might help somewhat. > That seemed like a reasonable idea to me. > > The pmu-firmware recipe as is doesn't seem too useful without these two > items. ...without those two items _or_ a runtime cfg_obj loading system. > But again I am new to these boards, maybe there is a bare-metal use for > the PMU firmware that does not require a config object. I don't think you can do anything with these SoCs without configuring the PMU. > But the multiconfig instructions imply that the layers should just work. I also think following a readme should lead to a booting image. But it doesn't seem to be the case here. > As for u-boot SPL unable to load a cfg object to the PMU, I started to > look at implementing that. SPL does already talk to the PMU, it > retrieves the PMU fw version for example. > > But I stopped since it seems silly. > > If I have the cfg object at build time, why not just build it into the > pmu-firmware as you do with the patch and skip the runtime loading at > every boot. I'm not advocating for any of the two methods, but also runtime loading has advantages, and doesn't perceivably increase boot time. [0] https://lists.yoctoproject.org/pipermail/meta-xilinx/2019-January/004182.html Regards, -- Luca -- ___ meta-xilinx mailing list meta-xilinx@yoctoproject.org https://lists.yoctoproject.org/listinfo/meta-xilinx
Re: [meta-xilinx] Clarification on pmu_cfg_obj handling for zynqmp boards
Hi Luca, What you describe is how I understand things. And I do have a booting system using the patch to the pmu-firmware and a pm_cfg_obj.c the customer provided. And I have also used a boot.bin produced by the xilinx tools by the customer with fsbl, pmu, etc... embedded. And that works fine too. I think I get the gist of things. What I am confused about is the usefulness of the meta-xilinx-standalone layer and the pmu-firmware in particular without patches. I don't think the license on the xilinx tool generated pm_cfg_obj.c matters too much. I wasn't suggesting the pm_cfg_obj.c be included in the layer since every board probably needs it's own version anyway. I was just asking about the patch to pm_binding.c to load an internal config object. Shouldn't this be included? I think it was you that suggested that the pmu-firmware recipe or another new recipe could go out and fetch the pm_cfg_obj.c file from somewhere else before the pmu-firmware compile step. That seemed like a reasonable idea to me. The pmu-firmware recipe as is doesn't seem too useful without these two items. But again I am new to these boards, maybe there is a bare-metal use for the PMU firmware that does not require a config object. But the multiconfig instructions imply that the layers should just work. As for u-boot SPL unable to load a cfg object to the PMU, I started to look at implementing that. SPL does already talk to the PMU, it retrieves the PMU fw version for example. But I stopped since it seems silly. If I have the cfg object at build time, why not just build it into the pmu-firmware as you do with the patch and skip the runtime loading at every boot. Regards, Scott -- ___ meta-xilinx mailing list meta-xilinx@yoctoproject.org https://lists.yoctoproject.org/listinfo/meta-xilinx
Re: [meta-xilinx] Clarification on pmu_cfg_obj handling for zynqmp boards
Hi Scott, On 23/01/19 11:12, Scott Ellis wrote: > Hi Manju, > > Thanks for answering. > > I will look at the meta-xilinx-tools layer. I think I finally understand > what is required to boot. > > But I am still not clear on the meta-xilinx multiconfig... Just to make sure we are on the same page, there are mainly two workflows with respect to booting on ZynqMP: using the Xilinx-specific bootloader (FSBL) and tools (meta-xilinx-tools layer), OR using U-Boot SPL and a more standard yocto setup. A few more details in section "Booting" here [0]. I suggest you first choose the workflow that is best for your needs. > The meta-xilinx-bsp/README.building.md has no mention that a patch is > required to the pmu-firmware which is confusing. > > Is this just an omission? > > Is the pmu-firmware recipe useful without the patch? Short answer: only with the Xilinx workflow. Long answer: The pmufw needs a "configuration object" to know what it should do, and it expects to receive it at runtime. In the Xilinx workflow the FSBL has a file called pm_cfg_obj.c built into itself. It is the PMUFW configuration object, and FSBL passes it to PMUFW at runtime. With the U-Boot SPL workflow there's no FSBL, and there are two problems: 1) passing a cfg obj to pmufw is just not implemented in U-Boot 2) the pm_cfg_obj.c file is generated by the Xilinx XSDK and its license is not compatible with the GPL license of U-Boot Clearly problem 2 prevents from fixing problem 1. :( To work around this problem a small patch has been developed so that pm_cfg_obj.c is linked into pmufw and loaded directly, without waiting for it from the outside. Find the original patch on the meta-topic layer [1] and the patch updated for pmufw 2018.x here [2]. > Excuse the dumb questions. As you might guess from the reply, that was clearly not dumb at all! :) Hope it helps. [0] https://archive.fosdem.org/2018/schedule/event/arm64_and_fpga/attachments/slides/2564/export/events/attachments/arm64_and_fpga/slides/2564/zynqmp_linux.pdf [1] https://github.com/topic-embedded-products/meta-topic/blob/master/recipes-bsp/pmu-firmware/pmu-firmware_2017.%25.bbappend [2] https://github.com/lucaceresoli/zynqmp-pmufw-builder/blob/master/0001-Load-XPm_ConfigObject-at-boot.patch -- Luca -- ___ meta-xilinx mailing list meta-xilinx@yoctoproject.org https://lists.yoctoproject.org/listinfo/meta-xilinx
Re: [meta-xilinx] Clarification on pmu_cfg_obj handling for zynqmp boards
Hi Manju, Thanks for answering. I will look at the meta-xilinx-tools layer. I think I finally understand what is required to boot. But I am still not clear on the meta-xilinx multiconfig... The meta-xilinx-bsp/README.building.md has no mention that a patch is required to the pmu-firmware which is confusing. Is this just an omission? Is the pmu-firmware recipe useful without the patch? Excuse the dumb questions. I am new to xilinx boards. Regards, Scott -- ___ meta-xilinx mailing list meta-xilinx@yoctoproject.org https://lists.yoctoproject.org/listinfo/meta-xilinx
Re: [meta-xilinx] Clarification on pmu_cfg_obj handling for zynqmp boards
Hi Scott, > -Original Message- > From: meta-xilinx-boun...@yoctoproject.org [mailto:meta-xilinx- > boun...@yoctoproject.org] On Behalf Of Scott Ellis > Sent: Saturday, January 19, 2019 6:09 AM > To: meta-xilinx@yoctoproject.org > Subject: [meta-xilinx] Clarification on pmu_cfg_obj handling for zynqmp boards > > Is there a way to use the thud branch meta-xilinx-bsp and > meta-xilinx-standalone > layers to build a bootable zynqmp system without having to use an external > patch to > the pmu-firmware recipe? > If following SPL you will need to patch the PMU firmware Otherwise you can grab meta-xilinx-tools layer (2018.3) which will build pmu firmware using Xilinx tools Thanks, Manju -- ___ meta-xilinx mailing list meta-xilinx@yoctoproject.org https://lists.yoctoproject.org/listinfo/meta-xilinx
