1. 27 Feb, 2018 2 commits
    • Antonio Nino Diaz's avatar
      Invalidate TLB entries during warm boot · 26441030
      Antonio Nino Diaz authored
      
      
      During the warm boot sequence:
      
      1. The MMU is enabled with the data cache disabled. The MMU table walker
         is set up to access the translation tables as in cacheable memory,
         but its accesses are non-cacheable because SCTLR_EL3.C controls them
         as well.
      2. The interconnect is set up and the CPU enters coherency with the
         rest of the system.
      3. The data cache is enabled.
      
      If the support for dynamic translation tables is enabled and another CPU
      makes changes to a region, the changes may only be present in the data
      cache, not in RAM. The CPU that is booting isn't in coherency with the
      rest of the system, so the table walker of that CPU isn't either. This
      means that it may read old entries from RAM and it may have invalid TLB
      entries corresponding to the dynamic mappings.
      
      This is not a problem for the boot code because the mapping is 1:1 and
      the regions are static. However, the code that runs after the boot
      sequence may need to access the dynamically mapped regions.
      
      This patch invalidates all TLBs during warm boot when the dynamic
      translation tables support is enabled to prevent this problem.
      
      Change-Id: I80264802dc0aa1cb3edd77d0b66b91db6961af3d
      Signed-off-by: default avatarAntonio Nino Diaz <antonio.ninodiaz@arm.com>
      26441030
    • Antonio Nino Diaz's avatar
      Add comments about mismatched TCR_ELx and xlat tables · 883d1b5d
      Antonio Nino Diaz authored
      
      
      When the MMU is enabled and the translation tables are mapped, data
      read/writes to the translation tables are made using the attributes
      specified in the translation tables themselves. However, the MMU
      performs table walks with the attributes specified in TCR_ELx. They are
      completely independent, so special care has to be taken to make sure
      that they are the same.
      
      This has to be done manually because it is not practical to have a test
      in the code. Such a test would need to know the virtual memory region
      that contains the translation tables and check that for all of the
      tables the attributes match the ones in TCR_ELx. As the tables may not
      even be mapped at all, this isn't a test that can be made generic.
      
      The flags used by enable_mmu_xxx() have been moved to the same header
      where the functions are.
      
      Also, some comments in the linker scripts related to the translation
      tables have been fixed.
      
      Change-Id: I1754768bffdae75f53561b1c4a5baf043b45a304
      Signed-off-by: default avatarAntonio Nino Diaz <antonio.ninodiaz@arm.com>
      883d1b5d
  2. 26 Feb, 2018 1 commit
  3. 25 Feb, 2018 1 commit
  4. 24 Feb, 2018 2 commits
  5. 23 Feb, 2018 4 commits
  6. 22 Feb, 2018 5 commits
  7. 21 Feb, 2018 3 commits
  8. 20 Feb, 2018 1 commit
  9. 19 Feb, 2018 1 commit
  10. 17 Feb, 2018 4 commits
  11. 16 Feb, 2018 3 commits
  12. 15 Feb, 2018 1 commit
    • Antonio Nino Diaz's avatar
      Redefine SMC_UNK as -1 instead of 0xFFFFFFFF · 4abd7fa7
      Antonio Nino Diaz authored
      
      
      According to the SMC Calling Convention (ARM DEN0028B):
      
          The Unknown SMC Function Identifier is a sign-extended value of
          (-1) that is returned in R0, W0 or X0 register.
      
      The value wasn't sign-extended because it was defined as a 32-bit
      unsigned value (0xFFFFFFFF).
      
      SMC_PREEMPT has been redefined as -2 for the same reason.
      
      NOTE: This might be a compatibility break for some AArch64 platforms
      that don't follow the previous version of the SMCCC (ARM DEN0028A)
      correctly. That document specifies that only the bottom 32 bits of the
      returned value must be checked. If a platform relies on the top 32 bits
      of the result being 0 (so that SMC_UNK is 0x00000000FFFFFFFF), it will
      have to fix its code to comply with the SMCCC.
      
      Change-Id: I7f7b109f6b30c114fe570aa0ead3c335383cb54d
      Signed-off-by: default avatarAntonio Nino Diaz <antonio.ninodiaz@arm.com>
      4abd7fa7
  13. 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
  14. 12 Feb, 2018 3 commits
  15. 09 Feb, 2018 3 commits
  16. 08 Feb, 2018 3 commits
  17. 07 Feb, 2018 2 commits