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

[York Sun <yorksun@freescale.com>]

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