Skip to content

GitLab

Switch branch/tag
  1. 24 Jul, 2018 3 commits
  3. 18 Jul, 2018 6 commits
  5. 03 Jul, 2018 1 commit
    • Yann Gautier's avatar
      Add MMC framework · ad71d45e
      Yann Gautier authored 
      

This change is largely based on existing eMMC framework by Haojian Zhuang
(@hzhuang1).

The MMC framework supports both eMMC and SD card devices. It was
written as a new framework since breaking few eMMC framework APIs.

At card probe and after the reset to idle command (CMD0), a Send
Interface Condition Command is sent (CMD8) to distinguish between
eMMC and SD card devices. eMMC devices go through the same
sequence as in the former eMMC framework. Else the framework
uses commands dedicated to SD-cards for init or frequency switch.

A structure is created to share info with the driver. It stores:
- the MMC type (eMMC, SD or SD HC)
- the device size
- the max frequency supported by the device
- the block size: 512 for eMMC and SD-HC and read from CSD
 structure for older SD-cards

Restriction to align buffers on block size has been removed.
Cache maintenance was removed and is expected to be done in the platform
or device driver.

The MMC framework includes some MISRA compliance coding style
maybe not yet ported in the existing eMMC framework.

Fixes ARM-software/tf-issues#597
Signed-off-by: default avatarYann Gautier <yann.gautier@st.com>
      ad71d45e
  7. 19 Jun, 2018 1 commit
    • Antonio Nino Diaz's avatar
      plat/arm: Migrate AArch64 port to the multi console driver · 88a0523e
      Antonio Nino Diaz authored 
      

The old API is deprecated and will eventually be removed.

Arm platforms now use the multi console driver for boot and runtime
consoles. However, the crash console uses the direct console API because
it doesn't need any memory access to work. This makes it more robust
during crashes.

The AArch32 port of the Trusted Firmware doesn't support this new API
yet, so it is only enabled in AArch64 builds. Because of this, the
common code must maintain compatibility with both systems. SP_MIN
doesn't have to be updated because it's only used in AArch32 builds.
The TSP is only used in AArch64, so it only needs to support the new
API without keeping support for the old one.

Special care must be taken because of PSCI_SYSTEM_SUSPEND. In Juno, this
causes the UARTs to reset (except for the one used by the TSP). This
means that they must be unregistered when suspending and re-registered
when resuming. This wasn't a problem with the old driver because it just
restarted the UART, and there were no problems associated with
registering and unregistering consoles.

The size reserved for BL2 has been increased.

Change-Id: Icefd117dd1eb9c498921181a21318c2d2435c441
Signed-off-by: default avatarAntonio Nino Diaz <antonio.ninodiaz@arm.com>
      88a0523e
  9. 11 Jun, 2018 1 commit
  11. 17 May, 2018 1 commit
    • Daniel Boulby's avatar
      Ensure read and write of flags are 32 bit · 8abcdf92
      Daniel Boulby authored 
      

In 'console_set_scope' and when registering a console, field 'flags' of
'console_t' is assigned a 32-bit value. However, when it is actually
used, the functions perform 64-bit reads to access its value. This patch
changes all 64-bit reads to 32-bit reads.

Change-Id: I181349371409e60065335f078857946fa3c32dc1
Signed-off-by: default avatarDaniel Boulby <daniel.boulby@arm.com>
      8abcdf92
  13. 15 May, 2018 1 commit
  15. 11 May, 2018 2 commits
    • Antonio Nino Diaz's avatar
      plat/arm: Migrate AArch64 port to the multi console driver · 2f18aa1f
      Antonio Nino Diaz authored 
      

The old API is deprecated and will eventually be removed.

Arm platforms now use the multi console driver for boot and runtime
consoles. However, the crash console uses the direct console API because
it doesn't need any memory access to work. This makes it more robust
during crashes.

The AArch32 port of the Trusted Firmware doesn't support this new API
yet, so it is only enabled in AArch64 builds. Because of this, the
common code must maintain compatibility with both systems. SP_MIN
doesn't have to be updated because it's only used in AArch32 builds.
The TSP is only used in AArch64, so it only needs to support the new
API without keeping support for the old one.

Special care must be taken because of PSCI_SYSTEM_SUSPEND. In Juno, this
causes the UARTs to reset (except for the one used by the TSP). This
means that they must be unregistered when suspending and re-registered
when resuming. This wasn't a problem with the old driver because it just
restarted the UART, and there were no problems associated with
registering and unregistering consoles.

The size of BL31 has been increased in builds with SPM.

Change-Id: Icefd117dd1eb9c498921181a21318c2d2435c441
Signed-off-by: default avatarAntonio Nino Diaz <antonio.ninodiaz@arm.com>
      2f18aa1f
    • Antonio Nino Diaz's avatar
      multi console: Assert that consoles aren't registered twice · c2e05bb7
      Antonio Nino Diaz authored 
      

In the multi console driver, allowing to register the same console more
than once may result in an infinte loop when putc is called.

If, for example, a boot message is trying to be printed, but the
consoles in the loop in the linked list are runtime consoles, putc will
iterate forever looking for a console that can print boot messages (or
a NULL pointer that will never come).

This loop in the linked list can occur after restoring the system from a
system suspend. The boot console is registered during the cold boot in
BL31, but the runtime console is registered even in the warm boot path.
Consoles are always added to the start of the linked list when they are
registered, so this it what should happen if they were actually
different structures:

   console_list -> NULL
   console_list -> BOOT -> NULL
   console_list -> RUNTIME -> BOOT -> NULL
   console_list -> RUNTIME -> RUNTIME -> BOOT -> NULL

In practice, the two runtime consoles are the same one, so they create
this loop:

   console_list -> RUNTIME -.    X -> BOOT -> NULL
                       ^    |
                       `----'

This patch adds an assertion to detect this problem. The assertion will
fail whenever the same structure tries to be registered while being on
the list.

In order to assert this, console_is_registered() has been implemented.
It returns 1 if the specified console is registered, 0 if not.

Change-Id: I922485e743775ca9bd1af9cbd491ddd360526a6d
Signed-off-by: default avatarAntonio Nino Diaz <antonio.ninodiaz@arm.com>
      c2e05bb7
  17. 13 Apr, 2018 2 commits
    • Roberto Vargas's avatar
      Fix MISRA rule 8.4 Part 4 · 3b94189a
      Roberto Vargas authored 
      

Rule 8.4: A compatible declaration shall be visible when
          an object or function with external linkage is defined

Fixed for:
	make DEBUG=1 PLAT=fvp SPD=tspd TRUSTED_BOARD_BOOT=1 \
	     GENERATE_COT=1 ARM_ROTPK_LOCATION=devel_rsa \
	     ROT_KEY=arm_rotprivk_rsa.pem MBEDTLS_DIR=mbedtls all

Change-Id: Ie4cd6011b3e4fdcdd94ccb97a7e941f3b5b7aeb8
Signed-off-by: default avatarRoberto Vargas <roberto.vargas@arm.com>
      3b94189a
    • Roberto Vargas's avatar
      Fix MISRA rule 8.3 Part 4 · 735181b6
      Roberto Vargas authored 
      

Rule 8.3: All declarations of an object or function shall
          use the same names and type qualifiers

Fixed for:
	make DEBUG=1 PLAT=fvp SPD=tspd TRUSTED_BOARD_BOOT=1 \
	     GENERATE_COT=1 ARM_ROTPK_LOCATION=devel_rsa \
	     ROT_KEY=arm_rotprivk_rsa.pem MBEDTLS_DIR=mbedtls all

Change-Id: Ia34fe1ae1f142e89c9a6c19831e3daf4d28f5831
Signed-off-by: default avatarRoberto Vargas <roberto.vargas@arm.com>
      735181b6
  19. 09 Apr, 2018 1 commit
  21. 31 Mar, 2018 1 commit
    • Michalis Pappas's avatar
      qemu: don't use C functions for the crash console callbacks · 0e24ea81
      Michalis Pappas authored 
      

Use the console_pl011_core_* functions directly in the crash console
callbacks.

This bypasses the MULTI_CONSOLE_API for the crash console (UART1), but
allows using the crash console before the C runtime has been initialized
(eg to call ASM_ASSERT). This retains backwards compatibility with respect
to functionality when the old API is used.

Use the MULTI_CONSOLE_API to register UART0 as the boot and runtime
console.

Fixes ARM-software/tf-issues#572
Signed-off-by: default avatarMichalis Pappas <mpappas@fastmail.fm>
      0e24ea81
  23. 26 Mar, 2018 1 commit
  25. 24 Mar, 2018 1 commit
  27. 01 Mar, 2018 2 commits
    • Dan Handley's avatar
      Emit warnings when using deprecated GIC init · dcf01a0a
      Dan Handley authored 
      

Emit runtime warnings when intializing the GIC drivers using the
deprecated method of defining integer interrupt arrays in the GIC driver
data structures; interrupt_prop_t arrays should be used instead. This
helps platforms detect that they have migration work to do. Previously,
no warning was emitted in this case. This affects both the GICv2 and GICv3
drivers.

Also use the __deprecated attribute to emit a build time warning if these
deprecated fields are used. These warnings are suppressed in the GIC
driver compatibility functions but will be visible if platforms use them.

Change-Id: I6b6b8f6c3b4920c448b6dcb82fc18442cfdf6c7a
Signed-off-by: default avatarDan Handley <dan.handley@arm.com>
      dcf01a0a
    • Dan Handley's avatar
      Improve MULTI_CONSOLE_API deprecation warnings · bc1a03c7
      Dan Handley authored 
      

For platforms that have not migrated to MULTI_CONSOLE_API == 1, there
are a lot of confusing deprecated declaration warnings relating to
use of console_init() and console_uninit(). Some of these relate to use
by the generic code, not the platform code. These functions are not really
deprecated but *removed* when MULTI_CONSOLE_API == 1.

This patch consolidates these warnings into a single preprocessor warning.
The __deprecated attribute is removed from the console_init() and
console_uninit() declarations.

For preprocessor warnings like this to not cause fatal build errors,
this patch adds -Wno-error=cpp to the build flags when
ERROR_DEPRECATED == 0.
This option (and -Wno-error=deprecated-declarations) is now added to
CPPFLAGS instead of TF_CFLAGS to ensure the build flags are used in the
assembler as well as the compiler.

This patch also disentangles the MULTI_CONSOLE_API and ERROR_DEPRECATED
build flags by defaulting MULTI_CONSOLE_API to 0 instead of
ERROR_DEPRECATED. This allows platforms that have not migrated to
MULTI_CONSOLE_API to use ERROR_DEPRECATED == 1 to emit a more meaningful
build error.

Finally, this patch bans use of MULTI_CONSOLE_API == 1 and AARCH32, since
the AArch32 console implementation does not support
MULTI_CONSOLE_API == 1.

Change-Id: If762165ddcb90c28aa7a4951aba70cb15c2b709c
Signed-off-by: default avatarDan Handley <dan.handley@arm.com>
      bc1a03c7
  29. 28 Feb, 2018 2 commits
  31. 24 Feb, 2018 1 commit
  33. 19 Jan, 2018 4 commits
  35. 17 Jan, 2018 1 commit
  37. 12 Dec, 2017 1 commit
    • Julius Werner's avatar
      Add new function-pointer-based console API · 9536bae6
      Julius Werner authored 
      

This patch overhauls the console API to allow for multiple console
instances of different drivers that are active at the same time. Instead
of binding to well-known function names (like console_core_init),
consoles now provide a register function (e.g. console_16550_register())
that will hook them into the list of active consoles. All console
operations will be dispatched to all consoles currently in the list.

The new API will be selected by the build-time option MULTI_CONSOLE_API,
which defaults to ${ERROR_DEPRECATED} for now. The old console API code
will be retained to stay backwards-compatible to older platforms, but
should no longer be used for any newly added platforms and can hopefully
be removed at some point in the future.

The new console API is intended to be used for both normal (bootup) and
crash use cases, freeing platforms of the need to set up the crash
console separately. Consoles can be individually configured to be active
active at boot (until first handoff to EL2), at runtime (after first
handoff to EL2), and/or after a crash. Console drivers should set a sane
default upon registration that can be overridden with the
console_set_scope() call. Code to hook up the crash reporting mechanism
to this framework will be added with a later patch.

This patch only affects AArch64, but the new API could easily be ported
to AArch32 as well if desired.

Change-Id: I35c5aa2cb3f719cfddd15565eb13c7cde4162549
Signed-off-by: default avatarJulius Werner <jwerner@chromium.org>
      9536bae6
  39. 21 Nov, 2017 1 commit
  41. 13 Nov, 2017 2 commits
    • Jeenu Viswambharan's avatar
      BL31: Program Priority Mask for SMC handling · 3d732e23
      Jeenu Viswambharan authored 
      

On GICv3 systems, as a side effect of adding provision to handle EL3
interrupts (unconditionally routing FIQs to EL3), pending Non-secure
interrupts (signalled as FIQs) may preempt execution in lower Secure ELs
[1]. This will inadvertently disrupt the semantics of Fast SMC
(previously called Atomic SMC) calls.

To retain semantics of Fast SMCs, the GIC PMR must be programmed to
prevent Non-secure interrupts from preempting Secure execution. To that
effect, two new functions in the Exception Handling Framework subscribe
to events introduced in an earlier commit:

  - Upon 'cm_exited_normal_world', the Non-secure PMR is stashed, and
    the PMR is programmed to the highest Non-secure interrupt priority.

  - Upon 'cm_entering_normal_world', the previously stashed Non-secure
    PMR is restored.

The above sequence however prevents Yielding SMCs from being preempted
by Non-secure interrupts as intended. To facilitate this, the public API
exc_allow_ns_preemption() is introduced that programs the PMR to the
original Non-secure PMR value. Another API
exc_is_ns_preemption_allowed() is also introduced to check if
exc_allow_ns_preemption() had been called previously.

API documentation to follow.

[1] On GICv2 systems, this isn't a problem as, unlike GICv3, pending NS
    IRQs during Secure execution are signalled as IRQs, which aren't
    routed to EL3.

Change-Id: Ief96b162b0067179b1012332cd991ee1b3051dd0
Signed-off-by: default avatarJeenu Viswambharan <jeenu.viswambharan@arm.com>
      3d732e23
    • Jeenu Viswambharan's avatar
      GIC: Introduce API to get interrupt ID · 4ee8d0be
      Jeenu Viswambharan authored 
      

Acknowledging interrupt shall return a raw value from the interrupt
controller in which the actual interrupt ID may be encoded. Add a
platform API to extract the actual interrupt ID from the raw value
obtained from interrupt controller.

Document the new function. Also clarify the semantics of interrupt
acknowledge.

Change-Id: I818dad7be47661658b16f9807877d259eb127405
Signed-off-by: default avatarJeenu Viswambharan <jeenu.viswambharan@arm.com>
      4ee8d0be
  43. 08 Nov, 2017 1 commit
    • Etienne Carriere's avatar
      ARMv7: GICv2 driver can manage GICv1 with security extension · 64deed19
      Etienne Carriere authored 
      

Some SoCs integrate a GIC in version 1 that is currently not supported
by the trusted firmware. This change hijacks GICv2 driver to handle the
GICv1 as GICv1 is compatible enough with GICv2 as far as the platform
does not attempt to play with virtualization support or some GICv2
specific power features.

Note that current trusted firmware does not use these GICv2 features
that are not available in GICv1 Security Extension.

Change-Id: Ic2cb3055f1319a83455571d6d918661da583f179
Signed-off-by: default avatarEtienne Carriere <etienne.carriere@linaro.org>
      64deed19
  45. 25 Oct, 2017 1 commit
  47. 16 Oct, 2017 2 commits
    • Jeenu Viswambharan's avatar
      GIC: Allow specifying interrupt properties · c639e8eb
      Jeenu Viswambharan authored 
      

The GIC driver initialization currently allows an array of interrupts to
be configured as secure. Future use cases would require more interrupt
configuration other than just security, such as priority.

This patch introduces a new interrupt property array as part of both
GICv2 and GICv3 driver data. The platform can populate the array with
interrupt numbers and respective properties. The corresponding driver
initialization iterates through the array, and applies interrupt
configuration as required.

This capability, and the current way of supplying array (or arrays, in
case of GICv3) of secure interrupts, are however mutually exclusive.
Henceforth, the platform should supply either:

  - A list of interrupts to be mapped as secure (the current way).
    Platforms that do this will continue working as they were. With this
    patch, this scheme is deprecated.

  - A list of interrupt properties (properties include interrupt group).
    Individual interrupt properties are specified via. descriptors of
    type 'interrupt_prop_desc_t', which can be populated with the macro
    INTR_PROP_DESC().

A run time assert checks that the platform doesn't specify both.

Henceforth the old scheme of providing list of secure interrupts is
deprecated. When built with ERROR_DEPRECATED=1, GIC drivers will require
that the interrupt properties are supplied instead of an array of secure
interrupts.

Add a section to firmware design about configuring secure interrupts.

Fixes ARM-software/tf-issues#262

Change-Id: I8eec29e72eb69dbb6bce77879febf32c95376942
Signed-off-by: default avatarJeenu Viswambharan <jeenu.viswambharan@arm.com>
      c639e8eb
    • Jeenu Viswambharan's avatar
      GIC: Add helpers to set interrupt configuration · 22966106
      Jeenu Viswambharan authored 
      

The helpers perform read-modify-write on GIC*_ICFGR registers, but don't
serialise callers. Any serialisation must be taken care of by the
callers.

Change-Id: I71995f82ff2c7f70d37af0ede30d6ee18682fd3f
Signed-off-by: default avatarJeenu Viswambharan <jeenu.viswambharan@arm.com>
      22966106