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>

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>

fiptool: add xfwrite() helper ...

We have same patterns for fwrite().

Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>

fiptool: fix the global option in usage ...

The global option --verbose should come after the "fiptool".

Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>

fiptool: simplify the top line of command usage ...

We need not mention like [--force], [--out <path>] because they are
included in [opts].

Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>

fiptool: refactor remove_image() ...

We need not handle the image_head as a special case.  Just use
a double-pointer to simplify the traverse.

Signed-off-by: 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: 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; 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>

fiptool: remove always true conditional ...

The conditional

  if (desc != NULL)
          ...

is always true here because we assert it 6 lines above:

  assert(desc != NULL);

Remove the if-conditional and concatenate the printf() calls.

Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>

fiptool: fix existence check of FIP input file for update command ...

This line should check the existence of the input file, but it is
actually checking the output file.  When -o option is given to the
"update" command, the outfile is unlikely to exist, then parse_fip()
is skipped and an empty FIP file is output.  This is wrong behavior.

Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>

Merge pull request #814 from freedomtan/patches-for-8173-crbook-osi-0110 ...

Patches for 8173 crbook

Merge pull request #817 from antonio-nino-diaz-arm/an/timingsafe ...

Import constant-time bcmp() and use it where necessary

tbbr: Use constant-time bcmp() to compare hashes ...

To avoid timing side-channel attacks, it is needed to use a constant
time memory comparison function when comparing hashes. The affected
code only cheks for equality so it isn't needed to use any variant of
memcmp(), bcmp() is enough.

Also, timingsafe_bcmp() is as fast as memcmp() when the two compared
regions are equal, so this change incurrs no performance hit in said
case. In case they are unequal, the boot sequence wouldn't continue as
normal, so performance is not an issue.

Change-Id: I1c7c70ddfa4438e6031c8814411fef79fd3bb4df
Signed-off-by: Antonio Nino Diaz <antonio.ninodiaz@arm.com>

stdlib: Import timingsafe_bcmp() from FreeBSD ...

Some side-channel attacks involve an attacker inferring something from
the time taken for a memory compare operation to complete, for example
when comparing hashes during image authentication. To mitigate this,
timingsafe_bcmp() must be used for such operations instead of the
standard memcmp().

This function executes in constant time and so doesn't leak any timing
information to the caller.

Change-Id: I470a723dc3626a0ee6d5e3f7fd48d0a57b8aa5fd
Signed-off-by: dp-arm <dimitris.papastamos@arm.com>
Signed-off-by: Antonio Nino Diaz <antonio.ninodiaz@arm.com>

Merge pull request #818 from sandrine-bailleux-arm/sb/strnlen ...

Add strnlen() to local C library

Add strnlen() to local C library ...

This code has been imported and slightly adapted from FreeBSD:
https://github.com/freebsd/freebsd/blob/6253393ad8df55730481bf2aafd76bdd6182e2f5/lib/libc/string/strnlen.c

Change-Id: Ie5ef5f92e6e904adb88f8628077fdf1d27470eb3
Signed-off-by: Sandrine Bailleux <sandrine.bailleux@arm.com>

Remove use of all deprecated APIs ...

Now it's possbile to build BL31 for MT8173 with ERROR_DEPRECATED=1.

Signed-off-by: Koan-Sin Tan <koansin.tan@gmail.com>

Get rid of use of old GIC APIs ...

Signed-off-by: Koan-Sin Tan <koansin.tan@gmail.com>

Add support of PSCI_EXTENDED_STATE_ID to MT8173 ...

Signed-off-by: Koan-Sin Tan <koansin.tan@gmail.com>

Get rid of use of compatibility API ...

make 'make ARCH=aarch64 CROSS_COMPILE=aarch64-linux-gnu- PLAT=mt8173
ENABLE_PLAT_COMPAT=0' work.

Change-Id: I13f35d8aef23dfa0e65883fa0be43f1513c9fef5
Signed-off-by: Koan-Sin Tan <koansin.tan@gmail.com>

Merge pull request #800 from masahir0y/ifdef ...

Correct preprocessor conditionals

Merge pull request #815 from hzhuang1/dwmmc_v3.9 ...

drivers: add designware emmc driver

Use #ifdef for AARCH32 instead of #if ...

One nasty part of ATF is some of boolean macros are always defined
as 1 or 0, and the rest of them are only defined under certain
conditions.

For the former group, "#if FOO" or "#if !FOO" must be used because
"#ifdef FOO" is always true.  (Options passed by $(call add_define,)
are the cases.)

For the latter, "#ifdef FOO" or "#ifndef FOO" should be used because
checking the value of an undefined macro is strange.

For AARCH32/AARCH64, these macros are defined in the top-level
Makefile as follows:

ifeq (${ARCH},aarch32)
        $(eval $(call add_define,AARCH32))
else
        $(eval $(call add_define,AARCH64))
endif

This means only one of the two is defined.  So, AARCH32/AARCH64
belongs to the latter group where we should use #ifdef or #ifndef.
The conditionals are mostly coded correctly, but I see some mistakes.

Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>

Use #ifdef for IMAGE_BL* instead of #if ...

One nasty part of ATF is some of boolean macros are always defined
as 1 or 0, and the rest of them are only defined under certain
conditions.

For the former group, "#if FOO" or "#if !FOO" must be used because
"#ifdef FOO" is always true.  (Options passed by $(call add_define,)
are the cases.)

For the latter, "#ifdef FOO" or "#ifndef FOO" should be used because
checking the value of an undefined macro is strange.

Here, IMAGE_BL* is handled by make_helpers/build_macro.mk like
follows:

  $(eval IMAGE := IMAGE_BL$(call uppercase,$(3)))

  $(OBJ): $(2)
          @echo "  CC      $$<"
          $$(Q)$$(CC) $$(TF_CFLAGS) $$(CFLAGS) -D$(IMAGE) -c $$< -o $$@

This means, IMAGE_BL* is defined when building the corresponding
image, but *undefined* for the other images.

So, IMAGE_BL* belongs to the latter group where we should use #ifdef
or #ifndef.

Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>

Merge pull request #808 from masahir0y/build_fix ...

Fix parallel building

drivers: add designware emmc driver ...

Support Designware eMMC driver. It's based on both IO block
and eMMC driver.

Signed-off-by: Haojian Zhuang <haojian.zhuang@linaro.org>

Merge pull request #810 from masahir0y/fiptool_fix ...

Fix fiptool bug introduced by recent rework

Merge pull request #813 from antonio-nino-diaz-arm/an/libfdt ...

Update libfdt to version 1.4.2

Merge pull request #812 from antonio-nino-diaz-arm/an/clear-static-vars ...

Clear static variables in X509 parser on error

Build: strip trailing slashes from directory paths more simply ...

Append . then strip /. seems clumsy.  Just use $(patsubst %/,%, ).

Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>