[Buildroot] [PATCH 1/2] configs/zynqmp_zcu106: Bump ATF/U-Boot/Linux to Xilinx 2022

[Luca Ceresoli]

Hi Neal,

apologies for the delay in replies. Too busy.

On 08/02/22 14:56, Neal Frager wrote:
[...]
>>>  Is this something that can easily be updated?  If not, perhaps it 
>>> makes sense to move forward with my patch set as is for now, and then 
>>> I can include a new update once the BR2_TARGET_UBOOT_ZYNQMP_PM_CFG 
>>> configuration accepts URL inputs.
>>>
>>> What are your thoughts on this?
>>
>> I think you should go with local patch honestly.
>> As the patch is now.
> 
>> I agree with Giulio, it's probably better to add the file to Buildroot.
> 
>> Here's the rationale.
> 
>> Downloading files instead of versioning them is not necessarily a bad idea. However pm_cfg_obj.c is unavoidably a configuration-dependent file, meaning each user making their _project_ (project = a specific configuration of a specific hardware) will have a different pm_cfg_obj.c. This is different from downloading a patch, or a pmufw.bin, which are reusable across several projects.
> 
>> Theoretically, it might make sense to have a repo hosting pm_cfg_obj.c only if that repo contains all project-specific material for the _project_ : schematics, FPGA design etc. But this is not the case here.
> 
>> BTW pm_cfg_obj.c is a 32 kB text file that compresses to 2 kB. Not a big deal.
> 
> I agree with your rationale.  However, not every FPGA design will have a new pm_cfg_obj.c.  While it is possible to do some customizations with this file, all of the Xilinx evaluation boards now use the same one.  I would expect most developers never even touch this file, to be honest.  So in a high percentage of cases, the pm_cfg_obj.c is really coming from a specific Xilinx embeddedsw release branch which developers should want to be the same release version as the PMU firmware binary.

Interesting, I'm curious how this works. The pm_cfg_obj.c at the URL you
provided, as well as in the patches you sent, has some peripherals
disabled: USB1, ETH0/1/2, both SPIs, NAND, CAN0, VCU and more. Do
current kernels implement enabling these at runtime, making appropriate
requests to PMUFW? This wasn't the case last time I looked into that, it
would be very interesting if it has happened in the meantime.

Otherwise one would need to provide a per-configuration pmu config or a
"wildcard" config, but I'm not sure whether it would cover all potential
use cases. Even though Buildroot has [almost] only defconfigs for
well-known evaluation boards, it is really meant to be used by custom
designs, thus we want to be able to use other configurations than those
useful for Xilinx boards.

-- 
Luca