1. 12 Jun, 2018 2 commits
    • Daniel Boulby's avatar
      Fix MISRA Rule 5.3 Part 2 · 896a5902
      Daniel Boulby authored
      
      
      Use a _ prefix for Macro arguments to prevent that argument from
      hiding variables of the same name in the outer scope
      
      Rule 5.3: An identifier declared in an inner scope shall not
                hide an identifier declared in an outer scope
      
      Fixed For:
          make LOG_LEVEL=50 PLAT=fvp
      
      Change-Id: I67b6b05cbad4aeca65ce52981b4679b340604708
      Signed-off-by: default avatarDaniel Boulby <daniel.boulby@arm.com>
      896a5902
    • Daniel Boulby's avatar
      Fix MISRA Rule 5.1 · 87d3aacc
      Daniel Boulby authored
      
      
      Rule 5.1: External identifiers shall be distinct
      
      Some of the identifier names in the GICv3 driver were so long that the
      first 31 characters were identical. This patch shortens these names to
      make sure they are different.
      
      Fixed for:
          LOG_LEVEL=50 PLAT=fvp
      
      Change-Id: Iecd551e3a015d144716b87b42c83dd3ab8c34d90
      Signed-off-by: default avatarDaniel Boulby <daniel.boulby@arm.com>
      87d3aacc
  2. 11 Jun, 2018 1 commit
  3. 18 May, 2018 1 commit
  4. 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
  5. 11 May, 2018 1 commit
    • 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
  6. 27 Apr, 2018 1 commit
  7. 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
  8. 09 Apr, 2018 1 commit
  9. 03 Apr, 2018 2 commits
    • Andre Przywara's avatar
      gicv3: Fix support for systems without secure interrupts · 205cf6e7
      Andre Przywara authored
      
      
      Accessing the interrupt_props array only happens inside a loop over
      interrupt_props_num, so the GICv3 driver can cope with no secure
      interrupts. This allows us to relax the asserts that insists on
      a non-NULL interrupt_props pointer and at least one secure interrupt.
      This enables GICv3 platforms which have no need for a secure interrupt.
      
      This only covers the non-deprecated code paths.
      
      Change-Id: I49db291906512f56af065772f69acb281dfbdcfb
      Signed-off-by: default avatarAndre Przywara <andre.przywara@arm.com>
      205cf6e7
    • Samuel Holland's avatar
      gicv2: Fix support for systems without secure interrupts · 9d6d800d
      Samuel Holland authored
      
      
      Accessing the interrupt_props array only happens inside a loop over
      interrupt_props_num, so the GICv2 driver can cope with no secure
      interrupts. As in fact we have already some asserts in place that
      respect that, lets change the final place where we insist on a non-NULL
      pointer to relax that.
      This enables GICv2 platforms which have no need for a secure interrupt.
      
      This only covers the non-deprecated code paths.
      
      Also we remove a now redundant assert().
      
      Change-Id: Id100ea978643d8558335ad28649d55743fe9bd4c
      Signed-off-by: default avatarSamuel Holland <samuel@sholland.org>
      Signed-off-by: default avatarAndre Przywara <andre.przywara@arm.com>
      9d6d800d
  10. 27 Mar, 2018 1 commit
    • Joel Hutton's avatar
      Clean usage of void pointers to access symbols · 9f85f9e3
      Joel Hutton authored
      
      
      Void pointers have been used to access linker symbols, by declaring an
      extern pointer, then taking the address of it. This limits symbols
      values to aligned pointer values. To remove this restriction an
      IMPORT_SYM macro has been introduced, which declares it as a char
      pointer and casts it to the required type.
      
      Change-Id: I89877fc3b13ed311817bb8ba79d4872b89bfd3b0
      Signed-off-by: default avatarJoel Hutton <Joel.Hutton@Arm.com>
      9f85f9e3
  11. 26 Mar, 2018 2 commits
  12. 22 Mar, 2018 1 commit
  13. 05 Mar, 2018 1 commit
  14. 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
  15. 28 Feb, 2018 3 commits
  16. 26 Feb, 2018 1 commit
  17. 24 Feb, 2018 1 commit
  18. 21 Feb, 2018 1 commit
  19. 14 Feb, 2018 1 commit
    • Antonio Nino Diaz's avatar
      Remove URLs from comments · fb1198b1
      Antonio Nino Diaz authored
      
      
      This fixes all defects according to MISRA Rule 3.1: "The character
      sequences /* and // shall not be used within a comment". This affects
      all URLs in comments, so they have been removed:
      
      - The link in `sdei_state.c` can also be found in the documentation file
        `docs/sdei.rst`.
      
      - The bug that the file `io_fip.c` talks about doesn't affect the
        currently supported version of GCC, so it doesn't make sense to keep
        the comment. Note that the version of GCC officially supported is the
        one that comes with Linaro Release 17.10, which is GCC 6.2.
      
      - The link in `tzc400.c` was broken, and it didn't correctly direct to
        the Technical Reference Manual it should. The link has been replaced
        by the title of the document, which is more convenient when looking
        for the document.
      
      Change-Id: I89f60c25f635fd4c008a5d3a14028f814c147bbe
      Signed-off-by: default avatarAntonio Nino Diaz <antonio.ninodiaz@arm.com>
      fb1198b1
  20. 25 Jan, 2018 1 commit
    • Julius Werner's avatar
      delay_timer: Guarantee that delay time can never be undershot · e2aec918
      Julius Werner authored
      
      
      Delay functions like udelay() are often used to ensure that the
      necessary time passed to allow some asynchronous event to finish, such
      as the stabilization delay for a power rail. For these use cases it is
      not very problematic if the delay is slightly longer than requested,
      but it is critical that the delay must never be shorter.
      
      The current udelay() implementation contains two hazards that may cause
      the delay to be slightly shorter than intended: Firstly, the amount of
      ticks to wait is calculated with an integer division, which may cut off
      the last fraction of ticks needed. Secondly, the delay may be short by a
      fraction of a tick because we do not know whether the initial ("start")
      sample of the timer was near the start or near the end of the current
      tick. Thus, if the code intends to wait for one tick, it might read the
      timer value close to the end of the current tick and then read it again
      right after the start of the next tick, concluding that the duration of
      a full tick has passed when it in fact was just a fraction of it.
      
      This patch rounds up the division and always adds one extra tick to
      counteract both problems and ensure that delays will always be larger
      but never smaller than requested.
      
      Change-Id: Ic5fe5f858b5cdf3c0dbf3e488d4d5702d9569433
      Signed-off-by: default avatarJulius Werner <jwerner@chromium.org>
      e2aec918
  21. 24 Jan, 2018 1 commit
  22. 19 Jan, 2018 4 commits
  23. 18 Jan, 2018 1 commit
  24. 17 Jan, 2018 1 commit
  25. 11 Jan, 2018 1 commit
  26. 13 Dec, 2017 1 commit
    • Roberto Vargas's avatar
      io: block: fix block_read/write may read/write overlap buffer · e19e40af
      Roberto Vargas authored
      
      
      The block operations were trying to optimize the number of memory
      copies, and it tried to use directly the buffer supplied by the user
      to them. This was a mistake because it created too many corner cases:
      
      	1- It was possible to generate unaligned
      	   operations to unaligned buffers. Drivers that were using
      	   DMA transfer failed in that case.
      
      	2- It was possible to generate read operations
      	   with sizes that weren't a multiple of the block size. Some
      	   low level drivers assumed that condition and they calculated
      	   the number of blocks dividing the number of bytes by the
      	   size of the block, without considering the remaining bytes.
      
      	3- The block_* operations didn't control the
      	   number of bytes actually copied to memory, because the
      	   low level drivers were writing directly to the user buffer.
      
      This patch rewrite block_read and block_write to use always the device
      buffer, which the platform ensures that has the correct aligment and
      the correct size.
      
      Change-Id: I5e479bb7bc137e6ec205a8573eb250acd5f40420
      Signed-off-by: default avatarQixiang Xu <qixiang.xu@arm.com>
      Signed-off-by: default avatarRoberto Vargas <roberto.vargas@arm.com>
      e19e40af
  27. 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
  28. 21 Nov, 2017 1 commit
  29. 13 Nov, 2017 2 commits
    • Jeenu Viswambharan's avatar
      GIC: Fix Group 0 enabling · 385f1dbb
      Jeenu Viswambharan authored
      
      
      At present, the GIC drivers enable Group 0 interrupts only if there are
      Secure SPIs listed in the interrupt properties/list. This means that,
      even if there are Group 0 SGIs/PPIs configured, the group remained
      disabled in the absence of a Group 0 SPI.
      
      Modify both GICv2 and GICv3 SGI/PPI configuration to enable Group 0 when
      corresponding SGIs/PPIs are present.
      
      Change-Id: Id123e8aaee0c22b476eebe3800340906d83bbc6d
      Signed-off-by: default avatarJeenu Viswambharan <jeenu.viswambharan@arm.com>
      385f1dbb
    • Jeenu Viswambharan's avatar
      GICv2: Fix populating PE target data · 058efeef
      Jeenu Viswambharan authored
      
      
      This patch brings in the following fixes:
      
        - The per-PE target data initialized during power up needs to be
          flushed so as to be visible to other PEs.
      
        - Setup per-PE target data for the primary PE as well. At present,
          this was only setup for secondary PEs when they were powered on.
      
      Change-Id: Ibe3a57c14864e37b2326dd7ab321a5c7bf80e8af
      Signed-off-by: default avatarJeenu Viswambharan <jeenu.viswambharan@arm.com>
      058efeef