| 1c75d5df | 25-Dec-2016 |
Masahiro Yamada <yamada.masahiro@socionext.com> |
fiptool: support --align option to add desired alignment to image offset
The current fiptool packs all the images without any padding between them. So, the offset to each image has no alignment. T
fiptool: support --align option to add desired alignment to image offset
The current fiptool packs all the images without any padding between them. So, the offset to each image has no alignment. This is not efficient, for example, when the FIP is read from a block-oriented device.
For example, (e)MMC is accessed by block-addressing. The block size is 512 byte. So, the best case is each image is aligned by 512 byte since the DMA engine can transfer the whole of the image to its load address directly. The worst case is the offset does not have even DMA-capable alignment (this is where we stand now). In this case, we need to transfer every block to a bounce buffer, then do memcpy() from the bounce buffer to our final destination. At least, this should work with the abstraction by the block I/O layer, but the CPU-intervention for the whole data transfer makes it really slow.
This commit adds a new option --align to the fiptool. This option, if given, requests the tool to align each component in the FIP file by the specified byte. Also, add a new Make option FIP_ALIGN for easier access to this feature; users can give something like FIP_ALIGN=512 from the command line, or add "FIP_ALIGN := 512" to their platform.mk file.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
show more ...
|
| 65caa3d0 | 26-Jan-2017 |
Masahiro Yamada <yamada.masahiro@socionext.com> |
fiptool: embed fip_toc_entry in struct image
The struct image has "uuid" and "size" to memorize the field values they had in the TOC entry. So, parse_fip() copies them from struct fip_toc_entry to
fiptool: embed fip_toc_entry in struct image
The struct image has "uuid" and "size" to memorize the field values they had in the TOC entry. So, parse_fip() copies them from struct fip_toc_entry to struct image, then pack_images() copies them back to struct fip_toc_entry.
The next commit (support --align option) will require to save the "offset" field as well. This makes me realize that struct image can embed struct fip_toc_entry.
This commit will allow the "flags" field to persevere the "update" command. At this moment, the "flags" is not used in a useful way. (Yet, platforms can save their own parameters in the flags field.) It makes sense to save it unless users explicitly replace the image.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
show more ...
|
| e9e0d287 | 27-Jan-2017 |
Masahiro Yamada <yamada.masahiro@socionext.com> |
fiptool: simplify assert() for add_image(_desc)
lookup_image(_desc)_from_uuid() traverses the linked list, so it is not efficient. We just want to make sure *p points to NULL here.
Signed-off-by:
fiptool: simplify assert() for add_image(_desc)
lookup_image(_desc)_from_uuid() traverses the linked list, so it is not efficient. We just want to make sure *p points to NULL here.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
show more ...
|
| ea39d557 | 27-Jan-2017 |
Masahiro Yamada <yamada.masahiro@socionext.com> |
fiptool: revive replace_image() to keep the image order by update command
Commit e0f083a09b29 ("fiptool: Prepare ground for expanding the set of images at runtime") introduced another side effect; t
fiptool: revive replace_image() to keep the image order by update command
Commit e0f083a09b29 ("fiptool: Prepare ground for expanding the set of images at runtime") introduced another side effect; the "update" command now changes the image order in the FIP.
Let's say you have an FIP with BL2, BL31, BL32, BL33. If you update for example, BL32 with the "update" command, you will get a new FIP with BL2, BL31, BL33, BL32, in this order.
It happens like this; remove_image() removes the old image from the linked list, add_image() adds the new image at the tail of the list, then images are packed in the new order. Prior to that commit, images were updated by replace_image(), but it was deleted by the re-work. Revive replace_image() that is re-implemented to work with the linked list.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
show more ...
|
| 11c0a4ff | 14-Jan-2017 |
Masahiro Yamada <yamada.masahiro@socionext.com> |
fiptool: fix add_image() and add_image_desc() implementation
The "make fip" shows the content of the generated FIP at the end of the build. (This is shown by "fiptool info" command.)
Prior to comm
fiptool: fix add_image() and add_image_desc() implementation
The "make fip" shows the content of the generated FIP at the end of the build. (This is shown by "fiptool info" command.)
Prior to commit e0f083a09b29 ("fiptool: Prepare ground for expanding the set of images at runtime"), the last part of the build log of make CROSS_COMPILE=aarch64-linux-gnu- BL33=../u-boot/u-boot.bin fip was like follows:
Trusted Boot Firmware BL2: offset=0xB0, size=0x4188, cmdline="--tb-fw" EL3 Runtime Firmware BL31: offset=0x4238, size=0x6090, cmdline="--soc-fw" Non-Trusted Firmware BL33: offset=0xA2C8, size=0x58B51, cmdline="--nt-fw"
With that commit, now it is displayed like follows:
Non-Trusted Firmware BL33: offset=0xB0, size=0x58B51, cmdline="--nt-fw" EL3 Runtime Firmware BL31: offset=0x58C01, size=0x6090, cmdline="--soc-fw" Trusted Boot Firmware BL2: offset=0x5EC91, size=0x4188, cmdline="--tb-fw"
You will notice two differences: - the contents are displayed in BL33, BL31, BL2 order - the offset values are wrong
The latter is more serious, and means "fiptool info" is broken.
Another interesting change is "fiptool update" every time reverses the image order. For example, if you input FIP with BL2, BL31, BL33 in this order, the command will pack BL33, BL31, BL2 into FIP, in this order. Of course, the order of components is not a big deal except that users will have poor impression about this.
The root cause is in the implementation of add_image(); the image_head points to the last added image. For example, if you call add_image() for BL2, BL31, BL33 in this order, the resulted image chain is:
image_head -> BL33 -> BL31 -> BL2
Then, they are processed from the image_head in "for" loops:
for (image = image_head; image != NULL; image = image->next) {
This means images are handled in Last-In First-Out manner.
Interestingly, "fiptool create" is still correct because add_image_desc() also reverses the descriptor order and the command works as before due to the double reverse.
The implementation of add_image() is efficient, but it made the situation too complicated.
Let's make image_head point to the first added image. This will add_image() inefficient because every call of add_image() follows the ->next chain to get the tail. We can solve it by adopting a nicer linked list structure, but I am not doing as far as that because we handle only limited number of images anyway.
Do likewise for add_image_desc().
Fixes: e0f083a09b29 ("fiptool: Prepare ground for expanding the set of images at runtime") Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
show more ...
|
| d02fcebe | 30-Dec-2016 |
dp-arm <dimitris.papastamos@arm.com> |
fiptool: Factor out setting of image descriptor action
An image descriptor contains an action and an argument. The action indicates the intended operation, as requested by the user. It can be pack
fiptool: Factor out setting of image descriptor action
An image descriptor contains an action and an argument. The action indicates the intended operation, as requested by the user. It can be pack, unpack or remove. Factor out setting those fields to a separate function to minimize code duplication across the various commands that modify these fields.
Change-Id: I1682958e8e83c4884e435cff6d0833c67726461f Signed-off-by: dp-arm <dimitris.papastamos@arm.com>
show more ...
|
| fcab6bbe | 03-Nov-2016 |
dp-arm <dimitris.papastamos@arm.com> |
fiptool: Add support for operating on binary blobs using the UUID
Previously, fiptool only understood a fixed set of images as specified in tbbr_config.c. It preserved unknown images during the upd
fiptool: Add support for operating on binary blobs using the UUID
Previously, fiptool only understood a fixed set of images as specified in tbbr_config.c. It preserved unknown images during the update, unpack and remove operations but it was not possible to explicitly refer to one of those unknown images.
Add a new --blob option to create/update/unpack/remove images that are not known at compile time. This is accomplished by specifying the UUID and filename pair as shown below:
$ ./fiptool create --blob uuid=01234567-89ab-cdef-0123-456789abcdef,file=foo.bin fip.bin $ ./fiptool info fip.bin 01234567-89ab-cdef-0123-456789abcdef: offset=0x60, size=0x1AA68
Fixes ARM-software/tf-issues#420
Change-Id: Iaac2504b9a4252289c09e73d29645cbe240f3a82 Signed-off-by: dp-arm <dimitris.papastamos@arm.com>
show more ...
|