[meta-xilinx] Clarification on pmu_cfg_obj handling for zynqmp boards

[Manjukumar Harthikote Matha]

Hi Luca,

> -----Original Message-----
> From: Luca Ceresoli [mailto:luca at lucaceresoli.net]
> Sent: Wednesday, January 23, 2019 7:13 AM
> To: Scott Ellis <scott at jumpnowtek.com>; Manjukumar Harthikote Matha
> <MANJUKUM at xilinx.com>; meta-xilinx at 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