- 24 Mar, 2021 1 commit
-
-
johpow01 authored
Add basic support for Makalu ELP processor core. Signed-off-by: John Powell <john.powell@arm.com> Change-Id: I7b1ddbb8dd43326ecb8ff188f6f8fcf239826a93
-
- 01 Mar, 2021 1 commit
-
-
johpow01 authored
Add basic support for Makalu CPU. Signed-off-by: John Powell <john.powell@arm.com> Change-Id: I4e85d425eedea499adf585eb8ab548931185043d
-
- 30 Nov, 2020 1 commit
-
-
Javier Almansa Sobrino authored
Enable basic support for Neoverse-N2 CPUs. Signed-off-by: Javier Almansa Sobrino <javier.almansasobrino@arm.com> Change-Id: I498adc2d9fc61ac6e1af8ece131039410872e8ad
-
- 05 Oct, 2020 2 commits
-
-
Jimmy Brisson authored
Change-Id: Ieb411e2f8092fa82062e619305b680673a8f184f Signed-off-by: Jimmy Brisson <jimmy.brisson@arm.com>
-
Jimmy Brisson authored
Change-Id: Ic0ca51a855660509264ff0d084c068e1421ad09a Signed-off-by: Jimmy Brisson <jimmy.brisson@arm.com>
-
- 29 Sep, 2020 5 commits
-
-
Andre Przywara authored
For the Arm Ltd. FPGAs to run, we need to load several payloads into the FPGA's memory: - Some trampoline code at address 0x0, to jump to BL31's entry point. - The actual BL31 binary at the beginning of DRAM. - The (generic) DTB image to describe the hardware. - The actual non-secure payloads (kernel, ramdisks, ...) The latter is application specific, but the first three blobs are rather generic. Since the uploader tool supports ELF binaries, it seems helpful to combine these three images into one .axf file, as this also simplifies the command line. Add a post-build linker script, that combines those three bits into one ELF file, together with their specific load addresses. Include a call to "ld" with this linker script in the platform Makefile, so it will be build automatically. The result will be called "bl31.axf". Change-Id: I4a90da16fa1e0e83b51d19e5b1daf61f5a0bbfca Signed-off-by: Andre Przywara <andre.przywara@arm.com>
-
Andre Przywara authored
The application cores of the FPGAs used in Arm Ltd. start execution at address 0x0. This is the location of some (emulated) ROM area (which can be written to by the uploading tool). Since the arm_fpga port is configured to run from DRAM, we load BL31 to the beginning of DRAM (mapped at 2GB). This requires some small trampoline code in the "ROM" to jump to the BL31 entry point. To avoid some extra magic binary, add a tiny assembly file with that trivial jump instruction to the tree, so this binary can be created alongside BL31. Change-Id: I9e4439fc0f093fa24dd49a8377c9edb030fbb477 Signed-off-by: Andre Przywara <andre.przywara@arm.com>
-
Andre Przywara authored
The FPGA images used in Arm Ltd. focus on CPU cores, so they share a common platform, with a minimal set of peripherals (interconnect, GIC, UART). This allows to support most platforms with a single devicetree file. The topology and number of CPU cores differ, but those will added at runtime, in BL31. Other adjustments (GICR size, SPE node, command line) are also done at this point. Add the common devicetree file to TF-A's build system, so it can be build together with BL31. At runtime, the resulting .dtb file should be uploaded to the address given with FPGA_PRELOADED_DTB_BASE at build time. Change-Id: I3206d6131059502ec96896e95329865452c9d83e Signed-off-by: Andre Przywara <andre.przywara@arm.com>
-
Andre Przywara authored
The Statistical Profiling Extension (SPE) is an architectural feature we can safely detect at runtime. However it still relies on one piece of platform-specific information: the interrupt line it is connected to. This requires SPE to be described in a devicetree node. Since SPE support varies with the CPU cores found on an FPGA image, we should detect the presence of SPE at runtime, and remove a potentially existing SPE PMU node from the DT. This allows to always have the SPE node in a generic devicetree file, without risking exposing it on a CPU without this feature. Change-Id: I73d83ea8509b03fe7bba20b9cce8d1335035fa31 Signed-off-by: Andre Przywara <andre.przywara@arm.com>
-
Andre Przywara authored
The size of a GICv3 redistributor region depends on the number of cores in the system. For the ARM FPGA port, we detect the topology at runtime, and adjust the CPU DT nodes accordingly. Now the size of the GICR region must also be adjusted, or Linux will fail to initialise the GICv3. Use the newly introduced function to overwrite the GICR size entry in the GICv3 reg property. We count the number of existing cores by iterating over the GICR frames until we find the LAST bit set in TYPER. Change-Id: Ib69565600859de9b1b15ceb8495172cd26d16fce Signed-off-by: Andre Przywara <andre.przywara@arm.com>
-
- 25 Sep, 2020 1 commit
-
-
Javier Almansa Sobrino authored
This patch allows the system to fallback to a default CPU library in case the MPID does not match with any of the supported ones. This feature can be enabled by setting SUPPORT_UNKNOWN_MPID build option to 1 (enabled by default only on arm_fpga platform). This feature can be very dangerous on a production image and therefore it MUST be disabled for Release images. Signed-off-by: Javier Almansa Sobrino <javier.almansasobrino@arm.com> Change-Id: I0df7ef2b012d7d60a4fd5de44dea1fbbb46881ba
-
- 02 Sep, 2020 1 commit
-
-
Javier Almansa Sobrino authored
At the moment BL31 dynamically discovers the CPU topology of an FPGA system at runtime, but does not export it to the non-secure world. Any BL33 user would typically looks at the devicetree to learn about existing CPUs. This patch exports a minimum /cpus node in a devicetree to satisfy the binding. This means that no cpumaps or caches are described. This could be added later if needed. An existing /cpus node in the DT will make the code bail out with a message. Signed-off-by: Javier Almansa Sobrino <javier.almansasobrino@arm.com> Change-Id: I589a2b3412411a3660134bdcef3a65e8200e1d7e
-
- 30 Jul, 2020 1 commit
-
-
Andre Przywara authored
The command line for BL33 payloads is typically taken from the DTB. On "normal" systems the bootloader will put the right version in there, but we typically don't use one on the FPGAs. To avoid editing (and possibly re-packaging) the DTB for every change in the command line, try to read it from some "magic" memory location instead. It can be easily placed there by the tool that uploads the other payloads to the FPGA's memory. BL31 will then replace the existing command line in the DTB with that new string. To avoid reading garbage, check the memory location for containing a magic value. This is conveniently chosen to be a simple ASCII string, so it can just preceed the actual command line in a text file: -------------------------------- CMD:console=ttyAMA0,38400n8 debug loglevel=8 -------------------------------- Change-Id: I5923a80332c9fac3b4afd1a6aaa321233d0f60da Signed-off-by: Andre Przywara <andre.przywara@arm.com>
-
- 24 Jul, 2020 1 commit
-
-
Javier Almansa Sobrino authored
As secondary cores show up, they populate an array to announce themselves so plat_core_pos_by_mpidr() can return an invalid COREID code for any non-existing MPIDR that it is queried about. The Power Domain Tree Description is populated with a topology based on the maximum harcoded values. Signed-off-by: Javier Almansa Sobrino <javier.almansasobrino@arm.com> Change-Id: I8fd64761a2296714ce0f37c46544f3e6f13b5f61
-
- 09 Jul, 2020 3 commits
-
-
Andre Przywara authored
The memory layout for the FPGA is fairly uniform for most of the FPGA images, and we already assume that DRAM starts at 2GB by default. Prepopulate PRELOADED_BL33_BASE and FPGA_PRELOADED_DTB_BASE to some sane default values, to simplify building some stock image. If people want to deviate from that, they can always override those addresses on the make command line. Change-Id: I2238fafb3f8253a01ad2d88d45827c141d9b29dd Signed-off-by: Andre Przywara <andre.przywara@arm.com>
-
Andre Przywara authored
To support FPGAs with those cores as well, as the respective cpulib files to the Makefile. Change-Id: I1a60867d5937be88b32b210c7817be4274554a76 Signed-off-by: Andre Przywara <andre.przywara@arm.com>
-
Andre Przywara authored
The maximum number of clusters is currently set to 2, which is quite limiting. As there are FPGA images with 4 clusters, let's increase the limit to 4. Change-Id: I9a85ca07ebbd2a018ad9668536d867ad6b75e537 Signed-off-by: Andre Przywara <andre.przywara@arm.com>
-
- 26 Jun, 2020 1 commit
-
-
Andre Przywara authored
The plat_core_pos_by_mpidr() implementation for the Arm FPGA port has some issues, which leads to problems when matching GICv3 redistributors with cores: - The power domain tree was not taking multithreading into account, so we ended up with the wrong mapping between MPIDRs and core IDs. - Before even considering an MPIDR, we try to make sure Aff2 is 0. Unfortunately this is the cluster ID when the MT bit is set. - We mask off the MT bit in MPIDR, before basing decisions on it. - When detecting the MT bit, we are properly calculating the thread ID, but don't account for the shift in the core and cluster ID checks. Those problems lead to early rejections of MPIDRs values, in particular when called from the GIC code. As a result, CPU_ON for secondary cores was failing for most of the cores. Fix this by properly handling the MT bit in plat_core_pos_by_mpidr(), also pulling in FPGA_MAX_PE_PER_CPU when populating the power domain tree. Change-Id: I71b2255fc0d27bfe5806511df479ab38e4e33fc4 Signed-off-by: Andre Przywara <andre.przywara@arm.com>
-
- 09 Jun, 2020 1 commit
-
-
Andre Przywara authored
The only difference between GIC-500 and GIC-600 relevant to TF-A is the differing power management sequence. A certain GIC implementation is detectable at runtime, for instance by checking the IIDR register. Let's add that test before initiating the GIC-600 specific sequence, so the code can be used on both GIC-600 and GIC-500 chips alike, without deciding on a GIC chip at compile time. This means that the GIC-500 "driver" is now redundant. To allow minimal platform support, add a switch to disable GIC-600 support. Change-Id: I17ea97d9fb05874772ebaa13e6678b4ba3415557 Signed-off-by: Andre Przywara <andre.przywara@arm.com>
-
- 01 Jun, 2020 1 commit
-
-
Jimmy Brisson authored
This should allow git to easily track file moves Signed-off-by: Jimmy Brisson <jimmy.brisson@arm.com> Change-Id: I1592cf39a4f94209c560dc6d1a8bc1bfb21d8327
-
- 05 May, 2020 4 commits
-
-
Andre Przywara authored
The arm_fpga port requires a DTB, to launch a BL33 payload. To make this port more flexible, we can also use the information in the DT to configure the console driver. For a start, find the DT node pointed to by the stdout-path property, and read the base address from there. This assumes for now that the stdout-path points to a PL011 UART. This allows to remove platform specific addresses from the image. We keep the original base address for the crash console. Change-Id: I46a990de2315f81cae4d7913ae99a07b0bec5cb1 Signed-off-by: Andre Przywara <andre.przywara@arm.com>
-
Andre Przywara authored
Since we use a DTB with all platform information to pass this on to a kernel loaded as BL33, we can as well make use of it for our own purposes. Every DT would contain a node for the GIC(v3) interrupt controller, so we can read the base address for the distributor and redistributors from there. This avoids hard coding this information in the code and allows for a more flexible binary. Change-Id: Ic530e223a21a45bc30a07a21048116d5af69e972 Signed-off-by: Andre Przywara <andre.przywara@arm.com>
-
Andre Przywara authored
The ARM Generic Timer DT binding describes an (optional) property to declare the counter frequency. Its usage is normally discouraged, as the value should be read from the CNTFRQ_EL0 system register. However in our case we can use it to program this register in the first place, which avoids us to hard code a counter frequency into the code. We keep some default value in, if the DT lacks that property for whatever reason. Change-Id: I5b71176db413f904f21eb16f3302fbb799cb0305 Signed-off-by: Andre Przywara <andre.przywara@arm.com>
-
Andre Przywara authored
The SCP firmware on the ARM FPGA initialises the UART already. This allows us to treat the PL011 as an SBSA Generic UART, which does not require any further setup. This in particular removes the need for any baudrate and base clock related settings to be hard coded into the BL31 image. Change-Id: I16fc943526267356b97166a7068459e06ff77f0f Signed-off-by: Andre Przywara <andre.przywara@arm.com>
-
- 09 Apr, 2020 1 commit
-
-
Andre Przywara authored
The arm_fpga platform code contains an dubious line to initialise some timer. On closer inspection this turn out to be bogus, as this was only needed on some special (older) FPGA board, and is actually not needed on the current model. Also the base address was wrong anyways. Remove the code entirely. Change-Id: I02e71aea645051b5addb42d972d7a79f04b81106 Signed-off-by: Andre Przywara <andre.przywara@arm.com>
-
- 03 Apr, 2020 1 commit
-
-
Manish Pandey authored
with commit a6ea06f5 , the way platform includes gicv3 files has been modified, this patch adapts to new method of including gicv3 files for arm_fpga platform. Signed-off-by: Manish Pandey <manish.pandey2@arm.com> Change-Id: Ic5ccae842b39b7db06d4f23c5738b174c42edf63
-
- 02 Apr, 2020 1 commit
-
-
Javier Almansa Sobrino authored
Signed-off-by: Javier Almansa Sobrino <javier.almansasobrino@arm.com> Change-Id: I397b642eff8a09b201f497f8d2ba39e2460c0dba
-
- 26 Mar, 2020 8 commits
-
-
Oliver Swede authored
This change is part of the goal of enabling the port to be compatible with multiple FPGA images. BL31 behaves differently depending on whether or not the CPUs in the system use cache coherency, and as a result any CPU libraries that are compiled together must serve processors that are consistent in this regard. This compiles a different set of CPU libraries depending on whether or not the HW_ASSISTED_COHERENCY is enabled at build-time to indicate the CPUs support hardware-level support for cache coherency. This build flag is used in the makefile in the same way as the Arm FVP port. Signed-off-by: Oliver Swede <oli.swede@arm.com> Change-Id: I18300b4443176b89767015e3688c0f315a91c27e
-
Oliver Swede authored
This allows the BL31 port to run with position-independent execution enabled so that it can be ran from any address in the system. This increases the flexibility of the image, allowing it to be ran from other locations rather than only its hardcoded absolute address (currently set to the typical DRAM base of 2GB). This may be useful for future images that describe system configurations with other memory layouts (e.g. where SRAM is included). It does this by setting ENABLE_PIE=1 and changing the absolute address to 0. The load address of bl31.bin can then be specified by the -l [load address] argument in the fpga-run command (additionally, this address is required by any preceding payloads that specify the start address. For ELF payloads this is usually extracted automatically by reading the entrypoint address in the header, however bl31.bin is a different file format so has this additional dependency). Signed-off-by: Oliver Swede <oli.swede@arm.com> Change-Id: Idd74787796ab0cf605fe2701163d9c4b3223a143
-
Oliver Swede authored
This change is part of the goal of enabling the port to be compatible with multiple FPGA images. The BL31 port that is uploaded as a payload to the FPGA with an image should cater for a wide variety of system configurations. This patch makes the necessary changes to enable it to function with images whose cluster configurations may be larger (either by utilizing more clusters, more CPUs per cluster, more threads in each CPU, or a combination) than the initial image being used for testing. As part of this, the hard-coded values that configure the size of the array describing the topology of the power domain tree are increased to max. 8 clusters, max. 8 cores per cluster & max 4 threads per core. This ensures the port works with cluster configurations up to these sizes. When there are too many entries for the number of available PEs, e.g. if there is a variable number of CPUs between clusters, then there will be empty entries in the array. This is permitted and the PSCI library will still function as expected. While this increases its size, this shouldn't be an issue in the context of the size of BL31, and is worth the trade-off for the extra compatibility. Signed-off-by: Oliver Swede <oli.swede@arm.com> Change-Id: I7d4ae1e20b2e99fdbac428d122a2cf9445394363
-
Oliver Swede authored
This initializes the GIC using the Arm GIC drivers in TF-A. The initial FPGA image uses a GIC600 implementation, and so that its power controller is enabled, this platform port calls the corresponding implementation-specific routines. Signed-off-by: Oliver Swede <oli.swede@arm.com> Change-Id: I88d5a073eead4b653b1ca73273182cd98a95e4c5
-
Oliver Swede authored
This sets the frequency of the system counter so that the Delay Timer driver programs the correct value to CNTCRL. This value depends on the FPGA image being used, and is 10MHz for the initial test image. Once configured, the BL31 platform setup sequence then enables the system counter. Signed-off-by: Oliver Swede <oli.swede@arm.com> Change-Id: Ieb036a36fd990f350b5953357424a255b8ac5d5a
-
Oliver Swede authored
This adds a basic PSCI implementation allow secondary CPUs to be released from an initial state and continue through to the warm boot entrypoint. Each secondary CPU is kept in a holding pen, whereby it polls the value representing its hold state, by reading this from an array that acts as a table for all the PEs. The hold states are initially set to 0 for all cores to indicate that the executing core should continue polling. To prevent the secondary CPUs from interfering with the platform's initialization, they are only updated by the primary CPU once the cold boot sequence has completed and fpga_pwr_domain_on(mpidr) is called. The polling target CPU will then read 1 (which indicates that it should branch to the warm reset entrypoint) and then jump to that address rather than continue polling. In addition to the initial polling behaviour of the secondary CPUs before their warm boot reset sequence, they are also placed in a low-power wfe() state at the end of each poll; accordingly, the PSCI fpga_pwr_domain_on(mpidr) function also signals an event to all cores (after updating the target CPU's hold entry) to wake them from this state, allowing any secondary CPUs that are still polling to check their hold state again. This method is in accordance with both the PSCI and Linux kernel recommendations, as the lessened overhead reduces the energy consumption associated with the busy-loop. The table of hold entries is implemented by a global array as shared SRAM (which is used by other platforms in similar implementations) is not available on the FPGA images. Signed-off-by: Oliver Swede <oli.swede@arm.com> Change-Id: I65cfd1892f8be1dfcb285f0e1e94e7a9870cdf5a
-
Oliver Swede authored
This makes use of the PRELOADED_BL33_BASE flag to indicate to BL31 that the BL33 payload (kernel) has already been loaded and resides in memory; BL31 will then jump to the non-secure address. For this port the BL33 payload is the Linux kernel, and in accordance with the pre-kernel setup requirements (as specified in the `Booting AArch64 Linux' documentation: https://www.kernel.org/doc/Documentation/arm64/booting.txt ), this change also sets up the primary CPU's registers x0-x3 so they are the expected values, which includes the address of the DTB at x0. An external linker script is currently required to combine BL31, the BL33 payload, and any other software images to create an ELF file that can be uploaded to the FPGA board along with the bit file. It therefore has dependencies on the value of PRELOADED_BL33_BASE (kernel base) and the DTB base (plus any other relevant base addresses used to distinguish the different ELF sections), both of which are set in this patch. Signed-off-by: Oliver Swede <oli.swede@arm.com> Change-Id: If7ae8ee82d1e09fb05f553f6077ae13680dbf66b
-
Oliver Swede authored
This adds the minimal functions and definitions to create a basic BL31 port for an initial FPGA image, in order for the port to be uploaded to one the FPGA boards operated by an internal group within Arm, such that BL31 runs as a payload for an image. Future changes will enable the port for a wide range of system configurations running on the FPGA boards to ensure compatibility with multiple FPGA images. It is expected that this will replace the FPGA fork of the Linux kernel bootwrapper by performing similar secure-world initialization and setup through the use of drivers and other well-established methods, before passing control to the kernel, which will act as the BL33 payload and run in EL2NS. This change introduces a basic, loadable port with the console initialized by setting the baud rate and base address of the UART as configured by the Zeus image. It is a BL31-only port, and RESET_TO_BL31 is enabled to reflect this. Signed-off-by: Oliver Swede <oli.swede@arm.com> Change-Id: I1817ad81be00afddcdbbda1ab70eb697203178e2
-