From mboxrd@z Thu Jan 1 00:00:00 1970 From: Huan Wang Date: Thu, 25 Sep 2014 06:33:13 +0000 Subject: [U-Boot] [PATCH 1/7] spl: pbl: Add new SPL image for pblimage tool In-Reply-To: References: <1411019239-12360-1-git-send-email-b18965@freescale.com> <1411019239-12360-2-git-send-email-b18965@freescale.com> <8785cda4654347988ff9668c88c45db7@BN1PR0301MB0689.namprd03.prod.outlook.com> <46bb82b9bc1f494a8992918ce100b341@BN1PR0301MB0689.namprd03.prod.outlook.com> <54204522.6080707@freescale.com> Message-ID: <4b2d7b5f888f4651b476a3bfc2beeb5b@BN1PR0301MB0689.namprd03.prod.outlook.com> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de Hi, York, > On 9/22/14 7:43 PM, "Wang Huan-B18965" > 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