Hi, On 5/13/21 9:24 AM, Jorge Ramirez-Ortiz, Foundries wrote: > On 13/05/21, Michal Simek wrote: >> Hi Jorge, >> >> On 5/12/21 11:21 PM, Jorge Ramirez-Ortiz, Foundries wrote: >>> Hi Michal >>> >>> We are doing some work on an MPSoC UZ3EG platform part of which >>> requires us to replace FSBL with SPL. >> >> Just for curiosity what's the reason for this requirement that fsbl is >> not enough? > > we prefer to have a common boot strategy on all the boards we support > (whether it is from NXP, Xilinx, ST or TI); it just simplifies the OTA > process (including their firmwares); and of course our meta layers. > >> >>> >>> It seems the actual boot process is becoming an issue on these SoCs; >>> currently, 1) we embed the PMU firmware on SPL so the bootrom can >>> extract it and program it; >> >> Actually it is not working like this. PMU FW is own part of boot.bin and >> it is not embed in SPL. > > yes, absolutely (boot.bin is what we have been flashing), holding SPL and FW > >> >> >>> 2) then SPL configures the PMU using a >>> platform specific binary that gets built also with SPL; >> >> PMU cfg object. > > yep, pm_cfg_obj.c > >> >> >> and finally, >>> 3) SPL sets up the DDR using its psu_init_gpl.c settings (also board >>> specific, part of the XSA). >> >> yes. >> >>> >>> It is this final step in the boot sequence that is being broken by the >>> Dynamic DDR DIMM configuration feature [1] >>> >>> [1] https://www.xilinx.com/support/answers/75768.html >> >> This was developed for zcu102 and maybe others boards which have DIMM >> modules where origin part were EOL. > > right. > > but notice that there is also support on u-boot for > altera/imx/marvell/microchip; so just wondering if we should add > drivers/ddr/xilinx to this list.
Also SPD code is around too. >> >> >>> Are you aware of any work in progress to support this? Any thoughts on >>> how to work around it and train the DDR? will the functionality >>> required to implmenet Dynamic DDR DIMM configuration be added as a >>> separate file to the XSA tarball or will we need to do some native >>> implementation in SPL? >> >> I am not aware about any work on SPL side to support this. IIRC FSBL >> didn't have generic DDR configuration. It was only by reading SPD and >> aligned some parameters but it is quite a long time I have looked at it >> last time. > > ok > >> >> >>> Becase without a change in the last link in the process chain >>> described earlier (calls to psu_init()), DDR just wont be accessible >>> to U-BOOT or OP-TEE. >>> >>> In our case, we were able to boot from QSPI, boot SPL (in OCM), have >>> SPL unpack and validate the FIT image, execute TF-A(in OCM), but then >>> any jumps to OP-TEE or U-BOOT would obviously not progress since the >>> DDR wasnt properly trained/initialized. >>> >>> so, any thoughts or plans you can share? >> >> The question is why you need this feature to be there. It is not working >> for every DIMM module. And normally if you have custom boards you need >> just one DDR configuration (or limited number based on HW versions) and >> for that there is really no need to waste your boot up time on it. > > not sure what you mean. we need this feature because it adds the > expected flexibility to the bootloader. Sure, we can hardcode DDR > configurations but why should we when it can be resolved by > software. Am I missing your point? Ok. One is support for evaluation boards and the second for a product. In product you don't need this because I would say most of projects are not using DIMMs. If you want to support generic evaluations boards then of course it can be done. > >> You can add multiple configurations to psu_init_gpl() and based on any >> information (board rev/pins/etc) decided which one should be used. > > so what you are suggesting is that we customize psu_init_gpl() to the > target (ie, have an updated xsa file with whatever config we need for > this system). In products yes. > > what I fail to grasp is why we can't take a step forward and do what > we do for other architectures in u-boot. and what fsbl already does by > config. > > I mean, why not? do you foresee any integration issues with the > current bootflow? Not really if you are willing to write that code just go for it. I think it is definitely feasible to do so but I haven't seen any algorithm to do it in generic way even there must be one behind in xilinx tools. There are a lot of types of memories which you can configure in xilinx design tools but it won't be any problem to limit it to some. Thanks, Michal
