Zynq MPSoC Dynamic DDR DIMM Configuration support

[Jorge Ramirez-Ortiz, Foundries]

On 13/05/21, 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.  
> 
> > 
> > 
> > > 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?
> 
> > 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).  
> 
> 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?

this is the current code on fsbl_init

so if we dont do this change, there will be more designs encountering
the same issue that we had. IMO it should be addressed in SPL.


#ifdef XFSBL_PS_DDR
#ifdef XPAR_DYNAMIC_DDR_ENABLED
	/*
	 * This function is used for all the ZynqMP boards.
	 * This function initialize the DDR by fetching the SPD data from
	 * EEPROM. This function will determine the type of the DDR and decode
	 * the SPD structure accordingly. The SPD data is used to calculate the
	 * register values of DDR controller and DDR PHY.
	 */
	Status = XFsbl_DdrInit();
	if (XFSBL_SUCCESS != Status) {
		XFsbl_Printf(DEBUG_GENERAL,"XFSBL_DDR_INIT_FAILED\n\r");
		goto END;
	}
#endif
#endif


> 
> > 
> > Thanks,
> > Michal
> >