| Message ID | 1411019239-12360-2-git-send-email-b18965@freescale.com |
|---|---|
| State | Changes Requested |
| Delegated to: | Albert ARIBAUD |
| Headers | show |
Hi Alison, On Thu, 18 Sep 2014 13:47:13 +0800, Alison Wang <b18965@freescale.com> wrote: > For the pblimage tool, the SPL image is splitted into 64 byte chunks, > and PBL needs a command for each piece. In current pblimage structure, > the size of the SPL image should be a fixed value. Well, for LS102xA > and some other ARM platforms, the size of the SPL image is changeable. > So a new image spl/u-boot-spl-pbl-pad.bin is built, and the size of > it is a fixed value "CONFIG_SPL_MAX_SIZE". Use it instead of > spl/u-boot-spl.bin for LS102xA. > > CONFIG_SPL_PBL_PAD is used to enable this function. > > Signed-off-by: Alison Wang <alison.wang@freescale.com> > --- There is already a CONFIG_SPL_PAD_TO (see ./README). Can you not use this? Amicalement,
Hi, Albert, > On Thu, 18 Sep 2014 13:47:13 +0800, Alison Wang <b18965@freescale.com> > wrote: > > > For the pblimage tool, the SPL image is splitted into 64 byte chunks, > > and PBL needs a command for each piece. In current pblimage structure, > > the size of the SPL image should be a fixed value. Well, for LS102xA > > and some other ARM platforms, the size of the SPL image is changeable. > > So a new image spl/u-boot-spl-pbl-pad.bin is built, and the size of > it > > is a fixed value "CONFIG_SPL_MAX_SIZE". Use it instead of > > spl/u-boot-spl.bin for LS102xA. > > > > CONFIG_SPL_PBL_PAD is used to enable this function. > > > > Signed-off-by: Alison Wang <alison.wang@freescale.com> > > --- > > There is already a CONFIG_SPL_PAD_TO (see ./README). Can you not use > this? > [Alison Wang] I have already used CONFIG_SPL_PAD_TO to determine the offset to which u-boot-spl.pbl should be padded when generating u-boot-with-spl-pbl.bin. Well, I used CONFIG_SPL_MAX_SIZE to determine the size of u-boot-spl-pbl-pad.bin. u-boot-spl-pbl-pad.bin is generated by padding u-boot-spl.bin to CONFIG_SPL_MAX_SIZE. Best Regards, Alison Wang
Hi Huan, On Fri, 19 Sep 2014 05:07:05 +0000, Huan Wang <alison.wang@freescale.com> wrote: > Hi, Albert, > > > On Thu, 18 Sep 2014 13:47:13 +0800, Alison Wang <b18965@freescale.com> > > wrote: > > > > > For the pblimage tool, the SPL image is splitted into 64 byte chunks, > > > and PBL needs a command for each piece. In current pblimage structure, > > > the size of the SPL image should be a fixed value. Well, for LS102xA > > > and some other ARM platforms, the size of the SPL image is changeable. > > > So a new image spl/u-boot-spl-pbl-pad.bin is built, and the size of > > it > > > is a fixed value "CONFIG_SPL_MAX_SIZE". Use it instead of > > > spl/u-boot-spl.bin for LS102xA. > > > > > > CONFIG_SPL_PBL_PAD is used to enable this function. > > > > > > Signed-off-by: Alison Wang <alison.wang@freescale.com> > > > --- > > > > There is already a CONFIG_SPL_PAD_TO (see ./README). Can you not use > > this? (BTW, thanks for fixing the way your mailer quotes. That's much more readable to me.) > [Alison Wang] I have already used CONFIG_SPL_PAD_TO to determine the offset to which u-boot-spl.pbl should be padded when generating u-boot-with-spl-pbl.bin. Well, I used CONFIG_SPL_MAX_SIZE to determine the size of u-boot-spl-pbl-pad.bin. u-boot-spl-pbl-pad.bin is generated by padding u-boot-spl.bin to CONFIG_SPL_MAX_SIZE. I'm still lost. Can you summarize the sequence of operations performed, starting from the u-boot SPL elf file, and on each step indicate which file is produced and which config option(s) from CONFIG_SPL_[PBL_]{PAD_TO,MAX_SIZE} is(are) involved and why? Also, in any case, if CONFIG_SPL_PBL_PAD is needed then it must be added to README with its description. > Best Regards, > Alison Wang Amicalement,
Hi, Albert, > > > On Thu, 18 Sep 2014 13:47:13 +0800, Alison Wang > > > <b18965@freescale.com> > > > wrote: > > > > > > > For the pblimage tool, the SPL image is splitted into 64 byte > > > > chunks, and PBL needs a command for each piece. In current > > > > pblimage structure, the size of the SPL image should be a fixed > > > > value. Well, for LS102xA and some other ARM platforms, the size > of the SPL image is changeable. > > > > So a new image spl/u-boot-spl-pbl-pad.bin is built, and the size > > > > of > > > it > > > > is a fixed value "CONFIG_SPL_MAX_SIZE". Use it instead of > > > > spl/u-boot-spl.bin for LS102xA. > > > > > > > > CONFIG_SPL_PBL_PAD is used to enable this function. > > > > > > > > Signed-off-by: Alison Wang <alison.wang@freescale.com> > > > > --- > > > > > > There is already a CONFIG_SPL_PAD_TO (see ./README). Can you not > use > > > this? > > (BTW, thanks for fixing the way your mailer quotes. That's much more > readable to me.) [Alison Wang] You are welcome. :) > > > [Alison Wang] I have already used CONFIG_SPL_PAD_TO to determine the > offset to which u-boot-spl.pbl should be padded when generating u-boot- > with-spl-pbl.bin. Well, I used CONFIG_SPL_MAX_SIZE to determine the > size of u-boot-spl-pbl-pad.bin. u-boot-spl-pbl-pad.bin is generated by > padding u-boot-spl.bin to CONFIG_SPL_MAX_SIZE. > > I'm still lost. Can you summarize the sequence of operations performed, > starting from the u-boot SPL elf file, and on each step indicate which > file is produced and which config option(s) from > CONFIG_SPL_[PBL_]{PAD_TO,MAX_SIZE} is(are) involved and why? [Alison Wang] Let me explain the sequence. 1. u-boot-spl.bin is produced. The size of it is not a fixed value. 2. u-boot-spl-pbl-pad.bin is produced. The size of it is defined by CONFIG_SPL_MAX_SIZE. For detail, u-boot-spl-pbl-pad.bin is generated by padding u-boot-spl.bin to the size of CONFIG_SPL_MAX_SIZE. The following is the reason for using u-boot-spl-pbl-pad.bin. First of all, the SPL part need to be reorganized for the recognition of PBL through the pblimage tool. For the pblimage tool, the SPL image is splitted into 64 byte chunks, and PBL needs a command for each piece. In current pblimage tool, the size of the SPL image(u-boot-spl.bin) should be a fixed value like PowerPC. Well, for LS102xA and some other ARM platforms, the size of the SPL image (u-boot-spl.bin) is changeable. So a new image spl/u-boot-spl-pbl-pad.bin is produced, and the size of it is a fixed value "CONFIG_SPL_MAX_SIZE". Then use u-boot-spl-pbl-pad.bin instead of spl/u-boot-spl.bin to generate spl/u-boot-spl.pbl. 3. spl/u-boot-spl.pbl is produced through pblimage tool. As CONFIG_SPL_PBL_PAD is enabled, spl/u-boot-spl-pbl-pad.bin is used as the source file instead of spl/u-boot-spl.bin. 4. u-boot-with-spl-pbl.bin is produced. For detail, u-boot-with-spl-pbl.bin is generated by padding spl/u-boot-spl.pbl to the offset of CONFIG_SPL_PAD_TO and adding u-boot.img. As the size of spl/u-boot-spl.pbl is not a fixed value, we pad it to the offset of CONFIG_SPL_PAD_TO. So it is convenient for us to determine the location of u-boot.img in SD card. > > Also, in any case, if CONFIG_SPL_PBL_PAD is needed then it must be > added to README with its description. > [Alison Wang] Yes, I will add it in v2. Thanks. Best Regards, Alison Wang
On 09/21/2014 11:17 PM, Wang Huan-B18965 wrote: > > [Alison Wang] Let me explain the sequence. > > 1. u-boot-spl.bin is produced. The size of it is not a fixed value. > > 2. u-boot-spl-pbl-pad.bin is produced. The size of it is defined by > CONFIG_SPL_MAX_SIZE. For detail, u-boot-spl-pbl-pad.bin is generated > by padding u-boot-spl.bin to the size of CONFIG_SPL_MAX_SIZE. > > The following is the reason for using u-boot-spl-pbl-pad.bin. > > First of all, the SPL part need to be reorganized for the recognition > of PBL through the pblimage tool. > > For the pblimage tool, the SPL image is splitted into 64 byte chunks, > and PBL needs a command for each piece. In current pblimage tool, > the size of the SPL image(u-boot-spl.bin) should be a fixed value > like PowerPC. Well, for LS102xA and some other ARM platforms, the size > of the SPL image (u-boot-spl.bin) is changeable. So a new image > spl/u-boot-spl-pbl-pad.bin is produced, and the size of it is a fixed > value "CONFIG_SPL_MAX_SIZE". Then use u-boot-spl-pbl-pad.bin instead > of spl/u-boot-spl.bin to generate spl/u-boot-spl.pbl. > > 3. spl/u-boot-spl.pbl is produced through pblimage tool. As > CONFIG_SPL_PBL_PAD is enabled, spl/u-boot-spl-pbl-pad.bin is used as > the source file instead of spl/u-boot-spl.bin. > > 4. u-boot-with-spl-pbl.bin is produced. For detail, u-boot-with-spl-pbl.bin > is generated by padding spl/u-boot-spl.pbl to the offset of CONFIG_SPL_PAD_TO > and adding u-boot.img. > > As the size of spl/u-boot-spl.pbl is not a fixed value, we pad it to > the offset of CONFIG_SPL_PAD_TO. So it is convenient for us to determine > the location of u-boot.img in SD card. > Sorry for the late respond. I was away for an urgent project. If I understand you correctly, you define a CONFIG_SPL_MAX_SIZE and pad the final binary file to this size. How do you determine the size? I understand PBL loading mechanism. Would it be possible to pad to 64 byte boundary (or any practical size since it is adjustable) and avoid the definition of CONFIG_SPL_MAX_SIZE? York
Hi, York, > On 09/21/2014 11:17 PM, Wang Huan-B18965 wrote: > > > > [Alison Wang] Let me explain the sequence. > > > > 1. u-boot-spl.bin is produced. The size of it is not a fixed value. > > > > 2. u-boot-spl-pbl-pad.bin is produced. The size of it is defined by > > CONFIG_SPL_MAX_SIZE. For detail, u-boot-spl-pbl-pad.bin is generated > > by padding u-boot-spl.bin to the size of CONFIG_SPL_MAX_SIZE. > > > > The following is the reason for using u-boot-spl-pbl-pad.bin. > > > > First of all, the SPL part need to be reorganized for the recognition > > of PBL through the pblimage tool. > > > > For the pblimage tool, the SPL image is splitted into 64 byte chunks, > > and PBL needs a command for each piece. In current pblimage tool, the > > size of the SPL image(u-boot-spl.bin) should be a fixed value like > > PowerPC. Well, for LS102xA and some other ARM platforms, the size of > > the SPL image (u-boot-spl.bin) is changeable. So a new image > > spl/u-boot-spl-pbl-pad.bin is produced, and the size of it is a fixed > > value "CONFIG_SPL_MAX_SIZE". Then use u-boot-spl-pbl-pad.bin instead > > of spl/u-boot-spl.bin to generate spl/u-boot-spl.pbl. > > > > 3. spl/u-boot-spl.pbl is produced through pblimage tool. As > > CONFIG_SPL_PBL_PAD is enabled, spl/u-boot-spl-pbl-pad.bin is used as > > the source file instead of spl/u-boot-spl.bin. > > > > 4. u-boot-with-spl-pbl.bin is produced. For detail, > > u-boot-with-spl-pbl.bin is generated by padding spl/u-boot-spl.pbl to > > the offset of CONFIG_SPL_PAD_TO and adding u-boot.img. > > > > As the size of spl/u-boot-spl.pbl is not a fixed value, we pad it to > > the offset of CONFIG_SPL_PAD_TO. So it is convenient for us to > > determine the location of u-boot.img in SD card. > > > > Sorry for the late respond. I was away for an urgent project. > > If I understand you correctly, you define a CONFIG_SPL_MAX_SIZE and pad > the final binary file to this size. How do you determine the size? I > understand PBL loading mechanism. Would it be possible to pad to 64 > byte boundary (or any practical size since it is adjustable) and avoid > the definition of CONFIG_SPL_MAX_SIZE? [Alison Wang] I checked the size of spl/u-boot-spl.bin, then determined CONFIG_SPL_MAX_SIZE which is larger than the size of spl/u-boot-spl.bin. For Pblimage tool, the size of SPL image need to be a fixed value. For example, for PowerPC, no matter how the SPL code is changed, the size of spl/u-boot-spl.bin is always 0x28000 (so the "pbl_cmd_initaddr" is always 0x82000000). But for LS1, the size of spl/u-boot-spl.bin is not a fixed size. When the SPL code is changed, the size of spl/u-boot-spl.bin is changed, so "pbl_cmd_initaddr" is changed too. It's unacceptable for pblimage tool("pbl_cmd_initaddr" need to be a fixed value). To fix this issue, I use CONFIG_SPL_MAX_SIZE. Do you mean there is some approach to pad spl/u-boot-spl.bin to any practical size and avoid the definition of CONFIG_SPL_MAX_SIZE? Best Regards, Alison Wang
Alison, On 9/22/14 7:43 PM, "Wang Huan-B18965" <alison.wang@freescale.com> wrote: >Hi, York, > >> On 09/21/2014 11:17 PM, Wang Huan-B18965 wrote: >> > >> > [Alison Wang] Let me explain the sequence. >> > >> > 1. u-boot-spl.bin is produced. The size of it is not a fixed value. >> > >> > 2. u-boot-spl-pbl-pad.bin is produced. The size of it is defined by >> > CONFIG_SPL_MAX_SIZE. For detail, u-boot-spl-pbl-pad.bin is generated >> > by padding u-boot-spl.bin to the size of CONFIG_SPL_MAX_SIZE. >> > >> > The following is the reason for using u-boot-spl-pbl-pad.bin. >> > >> > First of all, the SPL part need to be reorganized for the recognition >> > of PBL through the pblimage tool. >> > >> > For the pblimage tool, the SPL image is splitted into 64 byte chunks, >> > and PBL needs a command for each piece. In current pblimage tool, the >> > size of the SPL image(u-boot-spl.bin) should be a fixed value like >> > PowerPC. Well, for LS102xA and some other ARM platforms, the size of >> > the SPL image (u-boot-spl.bin) is changeable. So a new image >> > spl/u-boot-spl-pbl-pad.bin is produced, and the size of it is a fixed >> > value "CONFIG_SPL_MAX_SIZE". Then use u-boot-spl-pbl-pad.bin instead >> > of spl/u-boot-spl.bin to generate spl/u-boot-spl.pbl. >> > >> > 3. spl/u-boot-spl.pbl is produced through pblimage tool. As >> > CONFIG_SPL_PBL_PAD is enabled, spl/u-boot-spl-pbl-pad.bin is used as >> > the source file instead of spl/u-boot-spl.bin. >> > >> > 4. u-boot-with-spl-pbl.bin is produced. For detail, >> > u-boot-with-spl-pbl.bin is generated by padding spl/u-boot-spl.pbl to >> > the offset of CONFIG_SPL_PAD_TO and adding u-boot.img. >> > >> > As the size of spl/u-boot-spl.pbl is not a fixed value, we pad it to >> > the offset of CONFIG_SPL_PAD_TO. So it is convenient for us to >> > determine the location of u-boot.img in SD card. >> > >> >> Sorry for the late respond. I was away for an urgent project. >> >> If I understand you correctly, you define a CONFIG_SPL_MAX_SIZE and pad >> the final binary file to this size. How do you determine the size? I >> understand PBL loading mechanism. Would it be possible to pad to 64 >> byte boundary (or any practical size since it is adjustable) and avoid >> the definition of CONFIG_SPL_MAX_SIZE? > >[Alison Wang] I checked the size of spl/u-boot-spl.bin, then determined >CONFIG_SPL_MAX_SIZE which is larger than the size of spl/u-boot-spl.bin. >For Pblimage tool, the size of SPL image need to be a fixed value. >For example, for PowerPC, no matter how the SPL code is changed, the >size of spl/u-boot-spl.bin is always 0x28000 (so the "pbl_cmd_initaddr" >is always 0x82000000). But for LS1, the size of spl/u-boot-spl.bin is not >a fixed size. When the SPL code is changed, the size of spl/u-boot-spl.bin >is changed, so "pbl_cmd_initaddr" is changed too. It's unacceptable for >pblimage >tool("pbl_cmd_initaddr" need to be a fixed value). To fix this issue, I >use >CONFIG_SPL_MAX_SIZE. > >Do you mean there is some approach to pad spl/u-boot-spl.bin to any >practical size and avoid the definition of CONFIG_SPL_MAX_SIZE? PBL image is created this way A) Create the RCW header B) Determine u-boot image size C) Subtract the size from top of 24-bit space, that's what you see 0x82000000-size. The magic number 0x82000000 is used to make the result as 0x81xxxxxx. The highest of 0x8 is ACS=1, the lowest bit of 0x81 is CONTINUE=1, the xxxxxx is the 24-bit offset. By changing the offset, you can load the data into memory, up to 64 byte a time. By making a lot of 0x81xxxxxx, you make a sequence of commands to load 64 byte a time, until all image is loaded. Given the above mechanism, do you still think the image has to be a fixed size? I think you need to adjust pblimage.c to deal with the variable size, and pad the last chunk to be aligned with 2^n byte. York
Hi, York, > On 9/22/14 7:43 PM, "Wang Huan-B18965" <alison.wang@freescale.com> > wrote: > > >Hi, York, > > > >> On 09/21/2014 11:17 PM, Wang Huan-B18965 wrote: > >> > > >> > [Alison Wang] Let me explain the sequence. > >> > > >> > 1. u-boot-spl.bin is produced. The size of it is not a fixed value. > >> > > >> > 2. u-boot-spl-pbl-pad.bin is produced. The size of it is defined > by > >> > CONFIG_SPL_MAX_SIZE. For detail, u-boot-spl-pbl-pad.bin is > >> > generated by padding u-boot-spl.bin to the size of > CONFIG_SPL_MAX_SIZE. > >> > > >> > The following is the reason for using u-boot-spl-pbl-pad.bin. > >> > > >> > First of all, the SPL part need to be reorganized for the > >> > recognition of PBL through the pblimage tool. > >> > > >> > For the pblimage tool, the SPL image is splitted into 64 byte > >> > chunks, and PBL needs a command for each piece. In current > pblimage > >> > tool, the size of the SPL image(u-boot-spl.bin) should be a fixed > >> > value like PowerPC. Well, for LS102xA and some other ARM platforms, > >> > the size of the SPL image (u-boot-spl.bin) is changeable. So a new > >> > image spl/u-boot-spl-pbl-pad.bin is produced, and the size of it > is > >> > a fixed value "CONFIG_SPL_MAX_SIZE". Then use > >> > u-boot-spl-pbl-pad.bin instead of spl/u-boot-spl.bin to generate > spl/u-boot-spl.pbl. > >> > > >> > 3. spl/u-boot-spl.pbl is produced through pblimage tool. As > >> > CONFIG_SPL_PBL_PAD is enabled, spl/u-boot-spl-pbl-pad.bin is used > >> > as the source file instead of spl/u-boot-spl.bin. > >> > > >> > 4. u-boot-with-spl-pbl.bin is produced. For detail, > >> > u-boot-with-spl-pbl.bin is generated by padding spl/u-boot-spl.pbl > >> > to the offset of CONFIG_SPL_PAD_TO and adding u-boot.img. > >> > > >> > As the size of spl/u-boot-spl.pbl is not a fixed value, we pad it > >> > to the offset of CONFIG_SPL_PAD_TO. So it is convenient for us to > >> > determine the location of u-boot.img in SD card. > >> > > >> > >> Sorry for the late respond. I was away for an urgent project. > >> > >> If I understand you correctly, you define a CONFIG_SPL_MAX_SIZE and > >> pad the final binary file to this size. How do you determine the > >> size? I understand PBL loading mechanism. Would it be possible to > pad > >> to 64 byte boundary (or any practical size since it is adjustable) > >> and avoid the definition of CONFIG_SPL_MAX_SIZE? > > > >[Alison Wang] I checked the size of spl/u-boot-spl.bin, then > determined > >CONFIG_SPL_MAX_SIZE which is larger than the size of spl/u-boot- > spl.bin. > >For Pblimage tool, the size of SPL image need to be a fixed value. > >For example, for PowerPC, no matter how the SPL code is changed, the > >size of spl/u-boot-spl.bin is always 0x28000 (so the > "pbl_cmd_initaddr" > >is always 0x82000000). But for LS1, the size of spl/u-boot-spl.bin is > >not a fixed size. When the SPL code is changed, the size of > >spl/u-boot-spl.bin is changed, so "pbl_cmd_initaddr" is changed too. > >It's unacceptable for pblimage tool("pbl_cmd_initaddr" need to be a > >fixed value). To fix this issue, I use CONFIG_SPL_MAX_SIZE. > > > >Do you mean there is some approach to pad spl/u-boot-spl.bin to any > >practical size and avoid the definition of CONFIG_SPL_MAX_SIZE? > > PBL image is created this way > > A) Create the RCW header > B) Determine u-boot image size > C) Subtract the size from top of 24-bit space, that's what you see > 0x82000000-size. The magic number 0x82000000 is used to make the result > as 0x81xxxxxx. The highest of 0x8 is ACS=1, the lowest bit of 0x81 is > CONTINUE=1, the xxxxxx is the 24-bit offset. By changing the offset, > you can load the data into memory, up to 64 byte a time. By making a > lot of 0x81xxxxxx, you make a sequence of commands to load 64 byte a > time, until all image is loaded. > > Given the above mechanism, do you still think the image has to be a > fixed size? I think you need to adjust pblimage.c to deal with the > variable size, and pad the last chunk to be aligned with 2^n byte. > [Alison Wang] Yes, you are right. I will adjust pblimage.c to deal with the variable size in v2. The old approach to make it as a fixed size is not a good one. Thanks. Best Regards, Alison Wang
diff --git a/Makefile b/Makefile index 1fccd0b..6af424e 100644 --- a/Makefile +++ b/Makefile @@ -730,6 +730,7 @@ ALL-y += u-boot.srec u-boot.bin System.map binary_size_check ALL-$(CONFIG_ONENAND_U_BOOT) += u-boot-onenand.bin ifeq ($(CONFIG_SPL_FSL_PBL),y) ALL-$(CONFIG_RAMBOOT_PBL) += u-boot-with-spl-pbl.bin +ALL-$(CONFIG_SPL_PBL_PAD) += spl/u-boot-spl-pbl-pad.bin else ALL-$(CONFIG_RAMBOOT_PBL) += u-boot.pbl endif @@ -774,6 +775,8 @@ cmd_cat = cat $(filter-out $(PHONY), $^) > $@ append = cat $(filter-out $< $(PHONY), $^) >> $@ +cmd_pad = $(cmd_objcopy) + quiet_cmd_pad_cat = CAT $@ cmd_pad_cat = $(cmd_objcopy) && $(append) || rm -f $@ @@ -962,15 +965,27 @@ endif u-boot-img.bin: spl/u-boot-spl.bin u-boot.img FORCE $(call if_changed,cat) +ifdef CONFIG_SPL_PBL_PAD +SPLPBL_BINLOAD := spl/u-boot-spl-pbl-pad.bin +else +SPLPBL_BINLOAD := spl/u-boot-spl.bin +endif + #Add a target to create boot binary having SPL binary in PBI format #concatenated with u-boot binary. It is need by PowerPC SoC having #internal SRAM <= 512KB. MKIMAGEFLAGS_u-boot-spl.pbl = -n $(srctree)/$(CONFIG_SYS_FSL_PBL_RCW:"%"=%) \ -R $(srctree)/$(CONFIG_SYS_FSL_PBL_PBI:"%"=%) -T pblimage -spl/u-boot-spl.pbl: spl/u-boot-spl.bin FORCE +spl/u-boot-spl.pbl: $(SPLPBL_BINLOAD) FORCE $(call if_changed,mkimage) +OBJCOPYFLAGS_u-boot-spl-pbl-pad.bin = -I binary -O binary --pad-to=$(CONFIG_SPL_MAX_SIZE) \ + --gap-fill=0xff + +spl/u-boot-spl-pbl-pad.bin: spl/u-boot-spl.bin FORCE + $(call if_changed,pad) + OBJCOPYFLAGS_u-boot-with-spl-pbl.bin = -I binary -O binary --pad-to=$(CONFIG_SPL_PAD_TO) \ --gap-fill=0xff
For the pblimage tool, the SPL image is splitted into 64 byte chunks, and PBL needs a command for each piece. In current pblimage structure, the size of the SPL image should be a fixed value. Well, for LS102xA and some other ARM platforms, the size of the SPL image is changeable. So a new image spl/u-boot-spl-pbl-pad.bin is built, and the size of it is a fixed value "CONFIG_SPL_MAX_SIZE". Use it instead of spl/u-boot-spl.bin for LS102xA. CONFIG_SPL_PBL_PAD is used to enable this function. Signed-off-by: Alison Wang <alison.wang@freescale.com> --- Makefile | 17 ++++++++++++++++- 1 file changed, 16 insertions(+), 1 deletion(-)