1. 30 Aug, 2018 3 commits
  2. 22 Aug, 2018 1 commit
  3. 20 Aug, 2018 1 commit
  4. 10 Aug, 2018 3 commits
  5. 30 Jul, 2018 2 commits
  6. 24 Jul, 2018 5 commits
  7. 18 Jul, 2018 6 commits
  8. 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
  9. 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
  10. 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
  12. 15 May, 2018 1 commit
  13. 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
  14. 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
  15. 09 Apr, 2018 1 commit
  16. 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
  17. 26 Mar, 2018 1 commit
  18. 24 Mar, 2018 1 commit
  19. 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
  20. 28 Feb, 2018 2 commits
  21. 24 Feb, 2018 1 commit
  22. 19 Jan, 2018 1 commit
    • Julius Werner's avatar
      coreboot: Add support for CBMEM console · 1c5f5031
      Julius Werner authored
      
      
      coreboot supports an in-memory console to store firmware logs even when
      no serial console is available. It is widely supported by
      coreboot-compatible bootloaders (including SeaBIOS and GRUB) and can be
      read by the Linux kernel.
      
      This patch allows BL31 to add its own log messages to this console. The
      driver will be registered automatically if coreboot support is compiled
      in and detects the presence of a console buffer in the coreboot tables.
      
      Change-Id: I31254dfa0c2fdeb7454634134b5707b4b4154907
      Signed-off-by: default avatarJulius Werner <jwerner@chromium.org>
      1c5f5031