[meta-xilinx] Warrior release 06/30

[Mike Looijmans]

On 07-06-19 04:33, Jean-Francois Dagenais wrote:
> Hi all,
> 
>> On Jun 5, 2019, at 12:11, Luca Ceresoli <luca at lucaceresoli.net> wrote:
>>
>> It's your choice. I think the differences are not many (way less than
>> for the kernel at least).
>>
>> What are the big pieces from xilinx/u-boot not yet upstreamed?
>>
>> AFAIK only Dual QSPI. But git diff is your friend.
>>
>>> * What do you guys do to get the pm_cfg_obj.c generated? Manually?
>>
>> Manually here. It's enough for my needs. BTW I'm not using
>> meta-xilinx-tools.
> 
> Thanks for that... I've hit a few rough patches trying to get the config object through fsbl. staging.bbclass was choking on this in my pmu-firmware bbappend:
> do_configure[mcdepends] = "multiconfig:pmu:mymachine:fsbl:do_deploy" it seems. Assumptions broken... made a simple fix but will have to inspect it further if this whole endeavour pans out.
> 

It's quicker and simpler to just skip the multiconfig and build just once for 
the "pmu" machine and then for the actual machine.

> Since I still use meta-xilinx-tools, I may just use pmu-firmware from that and ditch multiconfig and -standalone completely. It does make bitbake terribly longer to start. meta-xilinx-tools got much better since the introduction of xsct-tarball.bbclass. Cleaned up our huge docker image and made upgrades trivial compare to a manually tedious process before. Kudos on Xilinx for that.
> 
> from your linked in reply:
>> I never tried to use falcon mode on ZynqMP, but I suspect it's a no-go if you want to load your bitstream before Linux boots.
> 
> So I thought the SPL had support for fpga... I have CONFIG_SPL_FPGA_SUPPORT in my config, and yes I was hoping to get that done prior to jumping in linux. If I understand correctly, it is always the PMU that actually programs the FPGA bin file? Communicated through IPI? I was convinced this was done by SPL...
> 

The FPGA programming is actually done by a DMA transfer into a "keyhole". The 
PMU just hides away the registers that initiate the transfer, but isn't 
actively involved.

The FPGA can also be programmed from within Linux, and you can even reprogram 
the FPGA (or parts thereof) through the FPGA itself (which is actually faster 
than by CPU) once it has been programmed...

> FYI right now I am in very early stage of running my freshly made u-boot boot.bin with the SPL. I am reacquainting myself with the SPL execution and debugging techniques (been a while). Right now I need to get more verbosity from SPL, only what looks like DTS parsing prints are coming out. And my PMUFW (with my cfg object), which I know was on my u-boot mkimage cmdline, I'm not even sure it gets programmed by the CSU...
> 
> Anyway, making progress, but lots of things grinding the effort to an almost crawl... (not complaining, this is all just fun btw.)
> 
> Thanks for any heads up and pointers fellas.
> Cheers!
>