- 04 Jun, 2014 29 commits
-
-
Sandrine Bailleux authored
It is easier to have all platform constants in the same place.
-
Sandrine Bailleux authored
As for FVP platforms, Juno provides some LEDs that we can use to report exceptions during the early boot code.
-
Sandrine Bailleux authored
Signed-off-by:
Ryan Harkin <ryan.harkin@linaro.org>
-
Ryan Harkin authored
Removing semihosting from the plat_io_storage code copied from FVP. Signed-off-by:
Ryan Harkin <ryan.harkin@linaro.org>
-
Ryan Harkin authored
Juno has a "taped out" BL1. To run your own BL1 on the board, you have to place it in a "ROM bypass" address and configure the platform to boot from there. The agreed bypass address is an offset of 0x03EC0000 from the start of NOR flash (0x08000000), which equates to 0x0BEC0000. To run the model using a BL1 in bypass mode, you should use a parameter set something like this: <path to>/FVP_CSS_Juno3 \ -C css.aon.scp.ROMloader.fname=<SCP ROM filename> \ --data css.cluster1.cpu0=bl1.bin@0x0BEC0000 \ -C soc.scc.apps_alt_boot=0x0BEC0000 To build BL1 as a ROM located at address zero, you can over-ride the default value for TZROM_BASE by passing parameters to make, eg: ASFLAGS="-D TZROM_BASE=0x00000000" \ CFLAGS="-D TZROM_BASE=0x00000000" \ CROSS_COMPILE=aarch64-linux-gnu- \ make PLAT=juno DEBUG=1 all Then you can launch the model using a command such as: <path to>/FVP_CSS_Juno3 \ -C css.aon.scp.ROMloader.fname=<SCP ROM filename> \ -C css.trustedBootROMloader.fname=<path to>/bl1.bin \ Signed-off-by:
Ryan Harkin <ryan.harkin@linaro.org>
-
Jon Medhurst authored
Currently UEFI and Linux are using SMC calls in the 'ARM Architecture' Owning Entity range so lets implement these to get things working. UEFI probably doesn't actually need to issue the ID_PRESENCE and ID_UID calls it does, and the device-tree used by Linux could specify the PSCI identifiers instead. After those changes, this patch isn't required. Signed-off-by:
Jon Medhurst <tixy@linaro.org>
-
Jon Medhurst authored
This is a temporary solution for issue #20 Signed-off-by:
Jon Medhurst <tixy@linaro.org>
-
Jon Medhurst authored
Signed-off-by:
Jon Medhurst <tixy@linaro.org>
-
Jon Medhurst authored
Signed-off-by:
Jon Medhurst <tixy@linaro.org>
-
Jon Medhurst authored
Signed-off-by:
Jon Medhurst <tixy@linaro.org>
-
Jon Medhurst authored
Signed-off-by:
Jon Medhurst <tixy@linaro.org>
-
Jon Medhurst authored
The SCP Ready command is sent by the SCP to indicate that the BL3-0 RAM Firmware image is successfully up and running. Signed-off-by:
Jon Medhurst <tixy@linaro.org>
-
Jon Medhurst authored
Signed-off-by:
Jon Medhurst <tixy@linaro.org>
-
Jon Medhurst authored
Signed-off-by:
Jon Medhurst <tixy@linaro.org>
-
Jon Medhurst authored
Signed-off-by:
Jon Medhurst <tixy@linaro.org>
-
Jon Medhurst authored
Signed-off-by:
Jon Medhurst <tixy@linaro.org>
-
Jon Medhurst authored
Signed-off-by:
Jon Medhurst <tixy@linaro.org>
-
Jon Medhurst authored
Signed-off-by:
Jon Medhurst <tixy@linaro.org>
-
Jon Medhurst authored
Signed-off-by:
Jon Medhurst <tixy@linaro.org>
-
Jon Medhurst authored
Note, on Juno mailboxes are 16 bytes because any bigger and they would overlap the memory used for MHU payload data for SCP->AP transfers. Signed-off-by:
Jon Medhurst <tixy@linaro.org>
-
Jon Medhurst authored
Signed-off-by:
Jon Medhurst <tixy@linaro.org>
-
Jon Medhurst authored
Signed-off-by:
Jon Medhurst <tixy@linaro.org>
-
Jon Medhurst authored
Signed-off-by:
Jon Medhurst <tixy@linaro.org>
-
Sandrine Bailleux authored
-
Sandrine Bailleux authored
-
Sandrine Bailleux authored
-
Jon Medhurst authored
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>
-
Jon Medhurst authored
-
Jon Medhurst authored
Signed-off-by:
Jon Medhurst <tixy@linaro.org>
-
- 29 May, 2014 1 commit
-
-
Andrew Thoelke authored
bl2_main() was overwriting any platform set X1 parameter for BL3-1 with the value zero. This patch ensure that any platform set value is correctly passed to BL3-1. The FVP port adds a check to verify this parameter is being passed correctly. Fixes ARM-software/tf-issues#173 Change-Id: Ifbcda73d3d41d2b04a4baf5614e9d2d21f1717c8
-
- 27 May, 2014 1 commit
-
-
Dan Handley authored
Rename the ic_* platform porting functions to plat_ic_* to be consistent with the other functions in platform.h. Also rename bl31_get_next_image_info() to bl31_plat_get_next_image_ep_info() and remove the duplicate declaration in bl31.h. Change-Id: I4851842069d3cff14c0a468daacc0a891a7ede84
-
- 23 May, 2014 9 commits
-
-
Dan Handley authored
Previously, the enable_mmu_elX() functions were implicitly part of the platform porting layer since they were included by generic code. These functions have been placed behind 2 new platform functions, bl31_plat_enable_mmu() and bl32_plat_enable_mmu(). These are weakly defined so that they can be optionally overridden by platform ports. Also, the enable_mmu_elX() functions have been moved to lib/aarch64/xlat_tables.c for optional re-use by platform ports. These functions are tightly coupled with the translation table initialization code. Fixes ARM-software/tf-issues#152 Change-Id: I0a2251ce76acfa3c27541f832a9efaa49135cc1c
-
Dan Handley authored
FVP specific files and functions containing the word "plat" have been renamed to use the word "fvp" to distinguish them from the common platform functionality and porting functions. Change-Id: I39f9673dab3ee9c74bd18b3e62b7c21027232f7d
-
Dan Handley authored
Some platform porting functions were in BL specific header files. These have been moved to platform.h so that all porting functions are in the same place. The functions are now grouped by BL. Obsolete BL headers files have been removed. Also, the weak declaration of the init_bl2_mem_layout() function has been moved out the header file and into the source file (bl_common.c) using the more succinct #pragma syntax. This mitigates the risk of 2 weak definitions being created and the wrong one being picked up by the compiler. Change-Id: Ib19934939fd755f3e5a5a5bceec88da684308a83
-
Dan Handley authored
Previously, platform.h contained many declarations and definitions used for different purposes. This file has been split so that: * Platform definitions used by common code that must be defined by the platform are now in platform_def.h. The exact include path is exported through $PLAT_INCLUDES in the platform makefile. * Platform definitions specific to the FVP platform are now in /plat/fvp/fvp_def.h. * Platform API declarations specific to the FVP platform are now in /plat/fvp/fvp_private.h. * The remaining platform API declarations that must be ported by each platform are still in platform.h but this file has been moved to /include/plat/common since this can be shared by all platforms. Change-Id: Ieb3bb22fbab3ee8027413c6b39a783534aee474a
-
Dan Handley authored
Some data variables were declared but not used. These have been removed. Change-Id: I038632af3c32d88984cd25b886c43ff763269bf9
-
Dan Handley authored
Function declarations implicitly have external linkage so do not need the extern keyword. Change-Id: Ia0549786796d8bf5956487e8996450a0b3d79f32
-
Sandrine Bailleux authored
Currently the platform code gets to define the base address of each boot loader image. However, the linker scripts couteract this flexibility by enforcing a fixed overall layout of the different images. For example, they require that the BL3-1 image sits below the BL2 image. Choosing BL3-1 and BL2 base addresses in such a way that it violates this constraint makes the build fail at link-time. This patch requires the platform code to now define a limit address for each image. The linker scripts check that the image fits within these bounds so they don't rely anymore on the position of a given image in regard to the others. Fixes ARM-software/tf-issues#163 Change-Id: I8c108646825da19a6a8dfb091b613e1dd4ae133c
-
Sandrine Bailleux authored
BL1 RO and RW base address used to be fixed, respectively to the first address of the Trusted ROM and the first address of the Trusted RAM. Introduce new platform defines to configure the BL1 RO and RW base addresses. Change-Id: If26616513a47798593a4bb845a4b0fb37c867cd6
-
Andrew Thoelke authored
At present BL3-1 has access to all of the SRAM, including regions that are mapped as read-only and non-cacheable by other firmware images. This patch restricts BL3-1 to only be able to read/write from memory used for its own data sections Change-Id: I26cda1b9ba803d91a9eacda768f3ce7032c6db94 Conflicts: plat/fvp/bl31_plat_setup.c
-