[U-Boot] [RFC v2 2/2] arm64: zynqmp: spl: install a PMU firmware config object at runtime

[Michal Simek]

On 04. 04. 19 9:52, Luca Ceresoli wrote:
> Hi Mike, Michal,
> 
> On 04/04/19 08:49, Michal Simek wrote:
> [...]
>>>>>>>> +#ifdef ZYNQMP_LOAD_PM_CFG_OBJ
>>>>>>>> +#include CONFIG_ZYNQMP_LOAD_PM_CFG_OBJ_FILE
>>>>>>>> +#endif
>>>>>>>> +
>>>>>>>>    int board_early_init_f(void)
>>>>>>>>    {
>>>>>>>>    	int ret = 0;
>>>>>>>> @@ -332,6 +338,11 @@ int board_early_init_f(void)
>>>>>>>>    
>>>>>>>>    int board_init(void)
>>>>>>>>    {
>>>>>>>> +#if defined(CONFIG_SPL_BUILD) && defined(ZYNQMP_LOAD_PM_CFG_OBJ)
>>>>>>>> +	zynqmp_pmufw_load_config_object(XPm_ConfigObject,
>>>>>>>> +					sizeof(XPm_ConfigObject));
>>>>>>>> +#endif
>>>>>>>
>>>>>>> As we discussed over IRC. I think that this should be simply bin
>>>>>>> firmware file compare to C built by u-boot.
>>>>>>
>>>>>> Sure. I have a working prototype that uses a binary blob. It still needs
>>>>>> a decent way to produce a blob and to be updated according to your review.
>>>>>
>>>>> It should be doable to write a Python script to parse the C file and create an
>>>>> equivalent binary (using "struct" module) which is just an array of integers
>>>>> in the end. That avoids the need for a microblaze C compiler...
>>>>
>>>> There's no need for a microblaze compiler. pm_cfg_obj.c is simply
>>>> declaring a u32 array and some #defines, any C compiler is enough.
>>>>
>>>> That said, my current solution (a trivial main.c that compiles the u32
>>>> array and outputs it to a binary file) is not nice at all, and it
>>>> requires a pm_defs.h file.
>>>>
>>>> The python script you mention looks way better from a user perspective,
>>>> although the parsing might be a bit fragile. I'll consider it, thanks
>>>> for the suggestion.
>>>>
>>>> In the past I even prototyped a python script that parses the Vivado
>>>> .xpr project file and produces a pm_cfg_obj.c. It avoided the need to
>>>> run the Xilinx XSDK just to generate pm_cfg_obj.c. It might also be
>>>> extended to produce a .bin directly, or a self-standing .c file that
>>>> doesn't need pm_defs.h, thus removing any licensing issue. But it never
>>>> grew complete to handle all cases. Obvious, since *I* don't even know
>>>> all of the cases. :)
>>>
>>>
>>> Another approach would be to simply create and include a "god mode" config 
>>> object that just allows access to all periferals. As far as I can see, such a 
>>> config object would just work on all boards. There's nothing really board 
>>> specific in the config object, and it's rather lame anyway to have to go and 
>>> compile a new bootloader just because you want to use a SPI controller...
>>>
>>> The config object I compile into the pmu firmware is of that type anyway.
> 
> Oh, that's interesting, but read below.
> 
>> Most of that stuff should be the same for all boards. But there are some
>> stuff which can be just board specific.
> 
> Mike, I think Michal refers to boards like Ultra96 which need special
> GPIO handling for their boot sequence, whose pm_cfg_obj.c have a final
> section similar to this:
> 
> 	/* GPO SECTION */
> 	PM_CONFIG_GPO_SECTION_ID,		/* GPO Section ID */
> 	PM_CONFIG_GPO1_BIT_2_MASK |
> 	PM_CONFIG_GPO1_MIO_PIN_34_MAP |
> 	0,					/* State of GPO pins */
> 
> I suspect a "god mode" config cannot handle such cases.

That's ultra96 is one of that exception but it depends on your MIO
configs too. It means you simply not assigned that gpo pins to PMU. You
loose functionality but you should be able to fix it differently later
in boot.

M