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

[Mike Looijmans]

On 04-04-19 09:56, Michal Simek wrote:
> 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.

I have no clue what those bits do. If it's something like setting a pinmux or 
gpio state, that'd be easy enough to do in u-boot or kernel, they both can 
send commands to the PMU anyway.