[U-Boot] [PATCH 1/7] spl: pbl: Add new SPL image for pblimage tool

Huan Wang
2014-09-25T06:33:13Z

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