[PATCH v2] Makefile: socfpga: Generate spl/u-boot-splx4.sfp with 4 SPL images

[Tom Rini]

On Tue, Aug 11, 2020 at 04:29:46PM +0200, Simon Goldschmidt wrote:
> Am 11.08.2020 um 16:21 schrieb Tom Rini:
> > On Tue, Aug 11, 2020 at 03:14:39PM +0200, Marek Vasut wrote:
> >> On 8/11/20 3:06 PM, Tom Rini wrote:
> >>> On Tue, Aug 11, 2020 at 04:01:10PM +0800, Chee Hong Ang wrote:
> >>>
> >>>> Generate spl/u-boot-splx4.sfp which consist of 4 SPL images required
> >>>> for booting up Cyclone5/Arria10.
> >>>>
> >>>> For Cyclone5 using NAND flash image layout for 128 KB memory blocks,
> >>>> 'make u-boot-with-nand-spl.sfp' to generate spl/u-boot-nand-splx4.sfp
> >>>> which contains four 128KB SPL images (each 64KB SPL is followed by
> >>>> 64KB of zero-padding).
> >>>>
> >>>> Signed-off-by: Chee Hong Ang <chee.hong.ang at intel.com>
> >>>> ---
> >>>>  Makefile | 11 +++++++----
> >>>>  1 file changed, 7 insertions(+), 4 deletions(-)
> >>>>
> >>>> diff --git a/Makefile b/Makefile
> >>>> index 4483a9b..f4631f1 100644
> >>>> --- a/Makefile
> >>>> +++ b/Makefile
> >>>> @@ -1582,8 +1582,9 @@ u-boot.spr: spl/u-boot-spl.img u-boot.img FORCE
> >>>>  ifneq ($(CONFIG_ARCH_SOCFPGA),)
> >>>>  quiet_cmd_socboot = SOCBOOT $@
> >>>>  cmd_socboot = cat	spl/u-boot-spl.sfp spl/u-boot-spl.sfp	\
> >>>> -			spl/u-boot-spl.sfp spl/u-boot-spl.sfp	\
> >>>> -			u-boot.img > $@ || rm -f $@
> >>>> +			spl/u-boot-spl.sfp \
> >>>> +			spl/u-boot-spl.sfp > spl/u-boot-splx4.sfp ; \
> >>>> +	      cat	spl/u-boot-splx4.sfp u-boot.img > $@ || rm -f $@
> >>>>  u-boot-with-spl.sfp: spl/u-boot-spl.sfp u-boot.img FORCE
> >>>>  	$(call if_changed,socboot)
> >>>>  
> >>>> @@ -1592,8 +1593,10 @@ cmd_socnandboot =  dd if=/dev/zero of=spl/u-boot-spl.pad bs=64 count=1024 ; \
> >>>>  		   cat	spl/u-boot-spl.sfp spl/u-boot-spl.pad \
> >>>>  			spl/u-boot-spl.sfp spl/u-boot-spl.pad \
> >>>>  			spl/u-boot-spl.sfp spl/u-boot-spl.pad \
> >>>> -			spl/u-boot-spl.sfp spl/u-boot-spl.pad \
> >>>> -			u-boot.img > $@ || rm -f $@ spl/u-boot-spl.pad
> >>>> +			spl/u-boot-spl.sfp \
> >>>> +			spl/u-boot-spl.pad > spl/u-boot-nand-splx4.sfp ; \
> >>>> +		   cat	spl/u-boot-nand-splx4.sfp u-boot.img > $@ || \
> >>>> +		   rm	-f $@ spl/u-boot-spl.pad
> >>>>  u-boot-with-nand-spl.sfp: spl/u-boot-spl.sfp u-boot.img FORCE
> >>>>  	$(call if_changed,socnandboot)
> >>>
> >>> It's not immediately clear to me why we're doing this here, rather than
> >>> instructing the user to write the file 4 times when programming.  On TI
> >>> platforms, even on NAND, for forever there's been multiple locations the
> >>> ROM will check for the loader.  Is there a reason to not handle this at
> >>> that level?
> >>
> >> The u-boot-with-spl.sfp was there to have one U-Boot image including
> >> SPL, other platforms do that as well. Except for the NAND case, where
> >> the padding is different.
> > 
> > Right, it's a convenience file and handy in some cases.  But what's the
> > reason for doing the 4 copy case?  It makes sense to create
> > "u-boot-with-stuff-plus-header" when there's a header that has to cover
> > the whole load, or you're going to write it to an SD card or there's
> > some non-trivial mangling involved.  Is the problem that
> > "u-boot-spl.sfp" isn't ever expected to be seen by the user and so it
> > would be odd to tell them to write that in the 4 places and then write
> > u-boot.img in the correct place, so instead we have to pad everything
> > out and make a large file?
> 
> As U-Boot and SPL have to fit together, I think it's better to create
> just one file that has to be written to SD card or flash. And writing to
> NOR flash is, depending on how you do it, not too quick, so it's *very*
> convenient to have this "4x SPL plus U-Boot" single file (start the
> command, get a coffee and wait).
> 
> And yes, it *is* just a convenience thing. But I think it's a good thing
> to have as result from the build. Even if it's only for the "dumb
> standard user" not having to know the offset where U-Boot has to be put...

Alright, thanks.

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 659 bytes
Desc: not available
URL: <https://lists.denx.de/pipermail/u-boot/attachments/20200811/f0d75422/attachment.sig>