| 96851114 | 25-May-2017 |
Evan Lloyd <evan.lloyd@arm.com> |
fiptool: Precursor changes for Visual Studio
In order to compile the source of Fiptool using Visual Studio a number of adjustments are required to the source. This commit modifies the source with c
fiptool: Precursor changes for Visual Studio
In order to compile the source of Fiptool using Visual Studio a number of adjustments are required to the source. This commit modifies the source with changes that will be required, but makes no functional modification. The intent is to allow confirmation that the GCC build is unaffected.
Change-Id: I4055bd941c646dd0a1aa2e24b940a1db3bf629ce Signed-off-by: Evan Lloyd <evan.lloyd@arm.com>
show more ...
|
| bb41eb7a | 22-May-2017 |
Masahiro Yamada <yamada.masahiro@socionext.com> |
cert: move platform_oid.h to include/tools_share for all platforms
Platforms aligned with TBBR are supposed to use their own OIDs, but defining the same macros with different OIDs does not provide a
cert: move platform_oid.h to include/tools_share for all platforms
Platforms aligned with TBBR are supposed to use their own OIDs, but defining the same macros with different OIDs does not provide any value (at least technically).
For easier use of TBBR, this commit allows platforms to reuse the OIDs obtained by ARM Ltd. This will be useful for non-ARM vendors that do not need their own extension fields in their certificate files.
The OIDs of ARM Ltd. have been moved to include/tools_share/tbbr_oid.h
Platforms can include <tbbr_oid.h> instead of <platform_oid.h> by defining USE_TBBR_DEFS as 1. USE_TBBR_DEFS is 0 by default to keep the backward compatibility.
For clarification, I inserted a blank line between headers from the include/ directory (#include <...>) and ones from a local directory (#include "..." ).
Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
show more ...
|
| 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 ...
|