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

Simon Goldschmidt simon.k.r.goldschmidt at gmail.com
Tue Aug 11 16:29:46 CEST 2020


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...

Regards,
Simon




More information about the U-Boot mailing list