| Age | Commit message (Collapse) | Author |
|---|
|
This concerns only debug builds. In BL2, we now pass a special value
to BL3-1 through x1. In BL3-1, we check that we receive the correct
value. This ensures that any platform set value is correctly passed
from BL2 to BL3-1.
Change-Id: Icb94d0e99ca445dcbe574a7d5e291659bba2209e
|
|
Change-Id: I0837d787837a40a724a8b7f2e3abd82287f403f3
|
|
Change-Id: Id1cd218baf4e35ad2e82e413b030ac96763a8104
|
|
On Juno, BL3-1 arguments used to sit at the beginning of the normal
DRAM. This patch moves them in trusted RAM. BL2 now allocates them
as a platform-specific static variable. BL3-1 then copies them
internally before the MMU is enabled.
Change-Id: I5cf526edfab5b49925b685092ff78506a5882f49
|
|
The BL3-0 gets loaded by BL2 but it will never be executed by the AP.
Therefore we don't care about the entry point information returned
by load_image() function.
Change-Id: I9bf7e04fa41a205b7595f58f0c3484a2507141fc
|
|
Change-Id: I734bf8a268d45a748dc2d1671656385212cdd465
|
|
The interface to load an image has changed so load_bl30() function
needs to be modified accordingly.
Change-Id: I7ff3f808579f6dcd4ddab7aa17f18932152ea33f
|
|
Propagate FVP changes introduced by these 3 commits:
- 29fb905d5f Rework handover interface between BL stages
- 4112bfa0c2 Populate BL31 input parameters as per new spec
- 6871c5d3a2 Rework memory information passing to BL3-x images
Change-Id: If024f575782d9c74db4cf929a2ab40563921dedd
|
|
Instead of having a single version of the MMU setup functions for all
bootloader images that can execute either in EL3 or in EL1, provide
separate functions for EL1 and EL3. Each bootloader image can then
call the appropriate version of these functions. The aim is to reduce
the amount of code compiled in each BL image by embedding only what's
needed (e.g. BL1 to embed only EL3 variants).
Change-Id: Ie3f6fb58f7d9ea4e4085b5069e27d6b9dceaa286
|
|
This patch implements the TSP on Juno. It executes from Secure RAM.
Also, the other bootloader images (i.e. BL1 R/W, BL2 and BL3-1) have
been moved around. The reason is, although there was enough space
overall to store the TSP in SRAM, there was no contiguous free chunk
of SRAM big enough to hold it.
This patch keeps the overall memory layout (i.e. keeping BL1 R/W at
the bottom, BL2 at the top and BL3-1 in between) but moves the base
addresses of all the bootloader images in such a way that:
- memory fragmentation is reduced enough to fit BL3-2 in;
- new base addresses are suitable for release builds as well as debug
ones;
- each image has a few extra kilobytes for future growth.
BL3-1 and BL3-2 are the images which received the biggest slice
of the cake since they will most probably grow the most.
A few useful numbers for reference (valid at the time of this patch):
|-----------------------|-------------------------------
| image size (debug) | extra space for the future
--------|-----------------------|-------------------------------
BL1 R/W | 28 KB | 4 KB
BL2 | 48 KB | 4 KB
BL3-1 | 96 KB | 8 KB
BL3-2 | 56 KB | 8 KB
--------|-----------------------|-------------------------------
Total | 228 KB | 24 KB = 252 KB
--------|-----------------------|-------------------------------
Note: On Juno, although the Secure RAM is 256 KB, the first 4KB
are reserved for the AP/SCP mailboxes.
Change-Id: I999ec39589c45beabe1ecd772641623e58569a6e
|
|
This is a miscellaneous commit that fixes all build
errors introduced by the rebase of the Juno codebase
on the latest trusted firmware.
- Make codebase consistent in its use of #include "" syntax
for user includes and #include <> syntax for system includes.
- Sort header files alphabetically
- Use tag names for structure types.
Replace instances of the former io_handle and io_dev_handle
types with uintptr_t.
- Review the .c and .S files for which header files really need
including and reorder the #include statements alphabetically.
Change-Id: I1d409fafb6dc257a38992ee15b22b0e890d040b0
|
|
Ensure that each bootloader stage initializes the UART console
independently. As a result, both BL3-1 and BL2 platform code now
calls console_init() instead of relying on BL1 to perform console
setup.
Also perform the console initialisation earlier in BL1 because
it must be done before it is used e.g. through a printf() call
in an assert() statement.
Change-Id: I8bb58cf1f0e42a71a01abf65da30bfa4ae533665
|
|
Signed-off-by: Ryan Harkin <ryan.harkin@linaro.org>
|
|
|
|
|
|
Juno doesn't have TZDRAM as FVP does, and there is real reason why we
need a special memory region for bl31_args anyway, assuming we take care
to copy it in BL31 before BL2's memory is reused.
Signed-off-by: Jon Medhurst <tixy@linaro.org>
|
|
Signed-off-by: Jon Medhurst <tixy@linaro.org>
|
