From mboxrd@z Thu Jan 1 00:00:00 1970 From: Mike Looijmans Date: Thu, 4 Apr 2019 10:05:21 +0000 Subject: [U-Boot] [RFC v2 2/2] arm64: zynqmp: spl: install a PMU firmware config object at runtime In-Reply-To: <642167a3-7160-0781-3439-61f0880dd8ef@xilinx.com> References: <20190321154857.29892-1-luca@lucaceresoli.net> <20190321154857.29892-3-luca@lucaceresoli.net> <55a5e990-737e-35e0-8f37-c953c9962d8a@lucaceresoli.net> <5bbdd18b-1e19-523f-1406-16a7f9d60a03@lucaceresoli.net> <47d3c08a-1188-095e-da3e-425e90d6e9aa@topic.nl> <7fa2f917-7b8e-a6ee-3629-0405b9e0bef9@xilinx.com> <642167a3-7160-0781-3439-61f0880dd8ef@xilinx.com> Message-ID: <88aa6fc8-d2c0-56f0-81c2-c3a382adb281@topic.nl> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de 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.