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 _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot