Derek Basehore [Tue, 31 Jan 2017 08:20:19 +0000 (00:20 -0800)]
rockchip: rk3399: Save and restore RX_CAL_DQS values
We were getting far off values on resume for the RX_CAL_DQS values.
This saves and restores the values for suspend/resume until the root
of the problem is figured out
Julius Werner [Tue, 31 Jan 2017 02:26:07 +0000 (18:26 -0800)]
rockchip: Add MIN() and MAX() macros back to M0 code
These macros were accidentally deleted in a previous cleanup. This
slipped through because the code using them is currently unused, but
that may change in the future.
Signed-off-by: Julius Werner <jwerner@chromium.org>
Julius Werner [Tue, 31 Jan 2017 00:13:21 +0000 (16:13 -0800)]
rockchip: Clean up M0 Makefile, clarify float-abi
This patch shuffles the M0 Makefile flags around a bit trying to make
their purpose clearer and remove duplication. Since all three build
steps (compiling, assembling, linking) actually call GCC, remove the
misleading aliases $(AS) and $(LD) to avoid confusion that those tools
might be called directly. Split flags into a common group that has
meaning for all three steps and separate variables specific to each
step. Remove -nostartfiles which is a strict subset of -nostdlib.
Also add explicit parameters for -mfloat-abi=soft, -fomit-frame-pointer
and -fno-common. If omitted these settings depend on the toolchain's
built-in default and cause various problems if they resolve to
unexpected values.
Signed-off-by: Julius Werner <jwerner@chromium.org>
Xing Zheng [Thu, 22 Dec 2016 10:34:14 +0000 (18:34 +0800)]
rockchip: rk3399: sperate the BL31 parameters for sharing
Maybe the coreboot will reference the BL31 parameters (e.g the TZRAM_BASE
and TZRAM_SIZE for DDR secure regions), we can split them and don't have
to hardcode the range in two places.
Xing Zheng [Fri, 24 Feb 2017 06:47:51 +0000 (14:47 +0800)]
rockchip: rk3399: configure the DDR secure region for BL31 image
Move the BL31 loaded base address 0x10000 to 0x1000, and configure
the the memory range 0~1MB is secure, the goal is that make sure
the BL31 image will be not modified.
Xing Zheng [Fri, 24 Feb 2017 08:26:11 +0000 (16:26 +0800)]
rockchip: Clean up header and referenced files
So far, there are more and more features are supported on the RK3399,
meanwhile, these features are increasingly being defined and intertwined.
It's time to clean up and make them clearer.
Derek Basehore [Mon, 9 Jan 2017 23:38:57 +0000 (15:38 -0800)]
rockchip: rk3399: Don't wait for vblank in M0 for ddrfreq
This removes waiting for vblank on the M0 during ddrfreq transitions.
That will now be done in the kernel to allow scheduling to be done on
the CPU core that changes the ddr frequency. Waiting for vblank in
the M0 would have the CPU core that waits on the M0 spin looping for
up to 16ms (1 frame for the display).
As rk3399 TRM1.1 document show, when set PMU_CRU_GATEDIS_CON0/1
register, it need set the write_mask bit (bit16 ~ bit31), but as
we test, it not need it. So need to correct the setting way, otherwise
it will set wrong value to this register.
Xing Zheng [Tue, 20 Dec 2016 12:44:41 +0000 (20:44 +0800)]
FIXUP: rockchip: rk3399: fix the incorrect bit during m0_init
We found that the DUT will be hanged if we don't set the bit_1 of the
PMUCRU_GATEDIS_CON0. But, from the TRM, there is weird that the bit_1
is set the clk_center1_gating_dis, not clk_pmum0_gating_dis. Is the
TRM incorrect? We need to check it with the IC team and re-clean the
commit message and explain it tomorrow.
Lin Huang [Mon, 12 Dec 2016 07:18:08 +0000 (15:18 +0800)]
rockchip: rk3399: improve the m0 enable flow
This patch do following things:
1. Request hresetn_cm0s_pmu_req first then request
poresetn_cm0s_pmu_req during M0 enable.
2. Do not diable M0 clock for ddr dvfs.
3. Correct the clk_pmum0_gating_dis bit, it is BIT0 not BIT1
4. do not set/clear hclk_noc_pmu_en in M0 code, it does not relate
to the M0 clock.
Signed-off-by: Lin Huang <hl@rock-chips.com> Signed-off-by: Derek Basehore <dbasehore@chromium.org>
Lin Huang [Thu, 1 Dec 2016 08:55:05 +0000 (16:55 +0800)]
rockchip: rk3399: check vop status when we wait dma finish flag
When vop is disabled and we read the vop register the system will
hang, so check vop status when we wait for the DMA finish flag to
avoid this sitiuation. This is done by checking for standby, DMA stop
mode, and disabled window states. Any one of these will prevent the
DMA finish flag from triggering.
Signed-off-by: Lin Huang <hl@rock-chips.com> Signed-off-by: Derek Basehore <dbasehore@chromium.org>
Derek Basehore [Fri, 24 Feb 2017 06:33:03 +0000 (14:33 +0800)]
rockchip: rk3399: fix hang in ddr set rate
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.
Derek Basehore [Thu, 10 Nov 2016 02:28:19 +0000 (18:28 -0800)]
rockchip: rk3399: Enable per CS training at 666MHz
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.
Derek Basehore [Fri, 24 Feb 2017 06:31:36 +0000 (14:31 +0800)]
rockchip: rk3399: add support for ddrfreq suspend/resume
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.
Xing Zheng [Wed, 26 Oct 2016 13:25:26 +0000 (21:25 +0800)]
rk3399: dram: use PMU M0 to do ddr frequency scaling
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>
Xing Zheng [Mon, 24 Oct 2016 13:06:25 +0000 (21:06 +0800)]
rockchip: update the raw read/write APIs for M0
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>
Derek Basehore [Fri, 21 Oct 2016 03:46:43 +0000 (20:46 -0700)]
rockchip: rk3399: dram: remove dram_init and dts_timing_receive function
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.
- 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
Douglas Raillard [Mon, 16 Jan 2017 11:32:28 +0000 (11:32 +0000)]
Add -fno-builtin to CFLAGS
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>
Masahiro Yamada [Sun, 25 Dec 2016 04:52:22 +0000 (13:52 +0900)]
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.
Masahiro Yamada [Thu, 26 Jan 2017 18:56:58 +0000 (03:56 +0900)]
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.
Masahiro Yamada [Fri, 27 Jan 2017 02:57:54 +0000 (11:57 +0900)]
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.
Masahiro Yamada [Sun, 25 Dec 2016 03:41:41 +0000 (12:41 +0900)]
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.
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.
David Cunado [Thu, 19 Jan 2017 10:26:16 +0000 (10:26 +0000)]
Resolve build errors flagged by GCC 6.2
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.
Fixes ARM-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:
https://github.com/freebsd/freebsd/blob/6253393ad8df55730481bf2aafd76bdd6182e2f5/lib/libc/string/strnlen.c
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.
Masahiro Yamada [Thu, 12 Jan 2017 01:48:22 +0000 (10:48 +0900)]
Build: Fix parallel building
Soren reports build fails if -j option is given:
$ make -j16 CROSS_COMPILE=aarch64-linux-gnu-
Building fvp
make: *** No rule to make target 'build/fvp/release/bl1/',
needed by 'build/fvp/release/bl1/bl1.ld'. Stop.
make: *** Waiting for unfinished jobs....
The cause of the failure is that $(dir ) leaves a trailing / on the
directory names. It must be ripped off to let Make create the
directory.
There are some ways to fix the issue. Here, I chose to make MAKE_LD
look like MAKE_C and MAKE_S because bl*_dirs seems the central place
of making directories.
In mbedtls_x509_parser.c there are some static arrays that are filled
during the integrity check and then read whenever an authentication
parameter is requested. However, they aren't cleared in case of an
integrity check failure, which can be problematic from a security
point of view. This patch clears these arrays in the case of failure.
Change-Id: I9d48f5bc71fa13e5a75d6c45b5e34796ef13aaa2 Signed-off-by: Antonio Nino Diaz <antonio.ninodiaz@arm.com>
Masahiro Yamada [Tue, 17 Jan 2017 17:10:08 +0000 (02:10 +0900)]
Use *_END instead of *_LIMIT for linker derived end addresses
The usage of _LIMIT seems odd here, so rename as follows:
BL_CODE_LIMIT --> BL_CODE_END
BL_RO_DATA_LIMIT --> BL_RO_DATA_END
BL1_CODE_LIMIT --> BL1_CODE_END
BL1_RO_DATA_LIMIT --> BL1_RO_DATA_END
Basically, we want to use _LIMIT and _END properly as follows:
*_SIZE + *_MAX_SIZE = *_LIMIT
*_SIZE + *_SIZE = *_END
The _LIMIT is generally defined by platform_def.h to indicate the
platform-dependent memory constraint. So, its typical usage is
ASSERT(. <= BL31_LIMIT, "BL31 image has exceeded its limit.")
in a linker script.
On the other hand, _END is used to indicate the end address of the
compiled image, i.e. we do not know it until the image is linked.
Here, all of these macros belong to the latter, so should be
suffixed with _END.
When generating the list of files to check by checkpatch.pl, the list
generated by `git ls-files` is filtered by a regular expression with
grep. Due to a malformed regex, the dot of `.md` was considered a
wildcard instead of a dot. This patch fixes this so that it matches
only dots, thus allowing the two following files to be checked:
Masahiro Yamada [Sat, 14 Jan 2017 14:22:02 +0000 (23:22 +0900)]
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:
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:
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>
Soren Brinkmann [Fri, 6 Jan 2017 19:07:00 +0000 (11:07 -0800)]
zynqmp: Migrate to new address space macros
Commit 0029624fe2d4c327ac885d04d5933f82f38e7071 ("Add
PLAT_xxx_ADDR_SPACE_SIZE definition") deprecates 'ADDR_SPACE_SIZE' in
favor of PLAT_(PHY|VIRT)_ADDRESS_SPACE_SIZE. Migrate the zynqmp platform
to use the new interface.
Masahiro Yamada [Thu, 22 Dec 2016 05:02:27 +0000 (14:02 +0900)]
Build: generate .d file at the same time as object is created
Currently, .d files are generated before any objects are built.
So, IS_ANYTHING_TO_BUILD flag is needed to avoid such processing for
non-build targets.
There is a cleverer way; just create a .d file simultaneously when
the corresponding object is created. No need to have separate rules
for .d files.
This commit will also fix a bug; -D$(IMAGE) is defined for $(OBJ),
but not for $(PREREQUISITES). So, .d files are generated with
different macro sets from those for .o files, then wrong .d files
are generated.
For example, in lib/cpus/aarch64/cpu_helpers.S
#if IMAGE_BL31
#include <cpu_data.h>
#endif
<cpu_data.h> is parsed for the object when built for BL31, but the
.d file does not pick up that dependency.
With this commit, the compiler will generate .o and .d at the same
time, guaranteeing they are generated under the same circumstances.
dp-arm [Fri, 30 Dec 2016 09:55:48 +0000 (09:55 +0000)]
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.