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

[Luca Ceresoli]

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.

-- 
Luca