There is system timer in m0, we can use it to implement a set of
stopwatch functions for measuring timeouts.
Signed-off-by: Lin Huang <hl@rock-chips.com>
Signed-off-by: Derek Basehore <dbasehore@chromium.org>
The phy pll needs to get 2X frequency to the DDR, so set the
pll_postdiv to 0.
Signed-off-by: Lin Huang <hl@rock-chips.com>
Signed-off-by: Derek Basehore <dbasehore@chromium.org>
This fixes a hang with setting the DRAM rate based on a race condition
with the M0 which sets the DRAM rate. The AP can also starve the M0,
so this also delays the AP reads to the DONE parameter for the M0.
Signed-off-by: Derek Basehore <dbasehore@chromium.org>
This enables per CS training at 666MHz and above for ddrfreq per
vendor recommendation. Since the threshold was used for latency was
the same value, this also adds a new value for that.
Signed-off-by: Derek Basehore <dbasehore@chromium.org>
This patch sets the frequency configuration of the next DRAM DFS index
to the configuration of the current index. This does not perform a
frequency transition. It just configures registers so the training on
resume for both indices will be correct.
Signed-off-by: Derek Basehore <dbasehore@chromium.org>
Signed-off-by: Xing Zheng <zhengxing@rock-chips.com>
We used dcf do ddr frequency scaling, but we just include a dcf
binary, it hard to maintain later, we have M0 compile flow in ATF,
and M0 can also work for ddr frequency scaling, so let's use it.
Signed-off-by: Lin Huang <hl@rock-chips.com>
Signed-off-by: Xing Zheng <zhengxing@rock-chips.com>
Since the ATF project, we usually use the mmio_read_32 and
mmio_write_32. And the mmio_write_32, the firse parameter
is ADDR, the second is VALUE. In order to style consistency:
1/ rename readl/writel to mmio_read_32/mmio_write_32
2/ for keeping the same with mmio_write_32 in the ATF project,
swap the order of the parameters for M0 mmio_write_32
Signed-off-by: Xing Zheng <zhengxing@rock-chips.com>
Signed-off-by: Lin Huang <hl@rock-chips.com>
when dram frequency below 260MHz, phy master dll may unlock, so
let phy master dll working at dll bypass mode when frequency is
below 260MHz.
Signed-off-by: Lin Huang <hl@rock-chips.com>
we can reuse the dram config from loader, so we can remove dram_init()
and dts_timing_receive() funciton in dram.c, add the dram_set_odt_pd()
function to get the odt and auto power down parameter from kernel.
This also removes the dcf_code_init function to allow the system to
actually boot.
Signed-off-by: Lin Huang <hl@rock-chips.com>
Signed-off-by: Derek Basehore <dbasehore@chromium.org>
Signed-off-by: Xing Zheng <zhengxing@rock-chips.com>
The errata reporting policy is as follows:
- If an errata workaround is enabled:
- If it applies (i.e. the CPU is affected by the errata), an INFO
message is printed, confirming that the errata workaround has been
applied.
- If it does not apply, a VERBOSE message is printed, confirming
that the errata workaround has been skipped.
- If an errata workaround is not enabled, but would have applied had
it been, a WARN message is printed, alerting that errata workaround
is missing.
The CPU errata messages are printed by both BL1 (primary CPU only) and
runtime firmware on debug builds, once for each CPU/errata combination.
Relevant output from Juno r1 console when ARM Trusted Firmware is built
with PLAT=juno LOG_LEVEL=50 DEBUG=1:
VERBOSE: BL1: cortex_a57: errata workaround for 806969 was not applied
VERBOSE: BL1: cortex_a57: errata workaround for 813420 was not applied
INFO: BL1: cortex_a57: errata workaround for disable_ldnp_overread was applied
WARNING: BL1: cortex_a57: errata workaround for 826974 was missing!
WARNING: BL1: cortex_a57: errata workaround for 826977 was missing!
WARNING: BL1: cortex_a57: errata workaround for 828024 was missing!
WARNING: BL1: cortex_a57: errata workaround for 829520 was missing!
WARNING: BL1: cortex_a57: errata workaround for 833471 was missing!
...
VERBOSE: BL31: cortex_a57: errata workaround for 806969 was not applied
VERBOSE: BL31: cortex_a57: errata workaround for 813420 was not applied
INFO: BL31: cortex_a57: errata workaround for disable_ldnp_overread was applied
WARNING: BL31: cortex_a57: errata workaround for 826974 was missing!
WARNING: BL31: cortex_a57: errata workaround for 826977 was missing!
WARNING: BL31: cortex_a57: errata workaround for 828024 was missing!
WARNING: BL31: cortex_a57: errata workaround for 829520 was missing!
WARNING: BL31: cortex_a57: errata workaround for 833471 was missing!
...
VERBOSE: BL31: cortex_a53: errata workaround for 826319 was not applied
INFO: BL31: cortex_a53: errata workaround for disable_non_temporal_hint was applied
Also update documentation.
Change-Id: Iccf059d3348adb876ca121cdf5207bdbbacf2aba
Signed-off-by: Jeenu Viswambharan <jeenu.viswambharan@arm.com>
At present, spin locks can only defined from C files. Add some macros
such that they can be defined from assembly files too.
Change-Id: I64f0c214062f5c15b3c8b412c7f25c908e87d970
Signed-off-by: Jeenu Viswambharan <jeenu.viswambharan@arm.com>
Disable the automatic substitution of functions with builtins. The
existing -ffreestanding option should already do this but explicitly
adding -fno-builtin reduces the risk of compiler variation. With this
option, GCC is not supposed to be able to make assumptions on what the
function does, which could otherwise lead to security-sensitive code
removal.
This can lead to potentially less efficient code but improves
predictability of what code is actually compiled into the binary.
Change-Id: I06ad151c61318bd1b00d84976f051d2d94314acc
Signed-off-by: Douglas Raillard <douglas.raillard@arm.com>
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>
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>
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>
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>
Commit e0f083a09b ("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>
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>
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>
The current user guide mentions that Foundation model doesn't support
debugger interface. Clarify that all FVPs support --cadi-server option
such that a CADI-compliant debugger can connect to and control model
execution.
Also fix broken URL to FVP home page.
Change-Id: Ia14d618a4e0abb4b228eb1616040f9b51fb3f6f9
Signed-off-by: Jeenu Viswambharan <jeenu.viswambharan@arm.com>
With GCC 6.2 compiler, more C undefined behaviour is being flagged as
warnings, which result in build errors in ARM TF build.
The specific issue that this patch resolves is the use of (1 << 31),
which is predominantly used in case statements, where 1 is represented
as a signed int. When shifted to msb the behaviour is undefined.
The resolution is to specify 1 as an unsigned int using a convenience
macro ULL(). A duplicate macro MAKE_ULL() is replaced.
FixesARM-software/tf-issues#438
Change-Id: I08e3053bbcf4c022ee2be33a75bd0056da4073e1
Signed-off-by: David Cunado <david.cunado@arm.com>
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>
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>
This code has been imported and slightly adapted from FreeBSD:
6253393ad8/lib/libc/string/strnlen.c
Change-Id: Ie5ef5f92e6e904adb88f8628077fdf1d27470eb3
Signed-off-by: Sandrine Bailleux <sandrine.bailleux@arm.com>
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>
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>
Lin Huang
Derek Basehore
Xing Zheng
danh-arm
dp-arm
Jeenu Viswambharan
Douglas Raillard
Masahiro Yamada
David Cunado
Antonio Nino Diaz
Sandrine Bailleux
Koan-Sin Tan
Haojian Zhuang