| 802b42a0 | 02-Feb-2017 |
Masahiro Yamada <yamada.masahiro@socionext.com> |
fiptool: stretch out printf strings for readability and grep'ability
We should follow the Linux coding style, which is clearly stated in
the docs/user-guide.mk:
When making changes to the source
fiptool: stretch out printf strings for readability and grep'ability
We should follow the Linux coding style, which is clearly stated in
the docs/user-guide.mk:
When making changes to the source for submission to the project,
the source must be in compliance with the Linux style guide
and Documentation/process/coding-style.rst of Linux Kernel says:
The limit on the length of lines is 80 columns and this is a
strongly preferred limit.
[ snip ]
However, never break user-visible strings such as printk messages,
because that breaks the ability to grep for them.
The strings for printf() are user-visible, and can exceed the 80
column limit.
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
show more ...
|
| 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 ...
|