1. 03 3月, 2021 9 次提交
    • P
      arm: cp15: update DACR value to activate access control · 503eea45
      Patrick Delaunay 提交于
      Update the initial value of Domain Access Control Register (DACR)
      and set by default the access permission to client (DACR_Dn_CLIENT = 1U)
      for each of the 16 domains and no more to all-supervisor
      (DACR_Dn_MANAGER = 3U).
      
      This patch allows to activate the domain checking in MMU against the
      permission bits in the translation tables and avoids prefetching issue
      on ARMv7 [1].
      
      Today it was already done for OMAP2 architecture
      ./arch/arm/mach-omap2/omap-cache.c::arm_init_domains
      introduced by commit de63ac27 ("ARM: mmu: Set domain permissions
      to client access") which fixes lot of speculative prefetch aborts seen
      on OMAP5 secure devices.
      
      [1] https://developer.arm.com/documentation/ddi0406/b/System-Level-Architecture/Virtual-Memory-System-Architecture--VMSA-/Memory-access-control/The-Execute-Never--XN--attribute-and-instruction-prefetchingSigned-off-by: NPatrick Delaunay <patrick.delaunay@st.com>
      Reported-by: NArd Biesheuvel <ardb@kernel.org>
      Signed-off-by: NPatrick Delaunay <patrick.delaunay@foss.st.com>
      503eea45
    • P
      arm: cosmetic: align TTB_SECT define value · 9b39d249
      Patrick Delaunay 提交于
      Align TTB_SECT define value with previous value.
      Signed-off-by: NPatrick Delaunay <patrick.delaunay@foss.st.com>
      9b39d249
    • P
      arm: remove TTB_SECT_XN_MASK in DCACHE_WRITETHROUGH · 342e1abd
      Patrick Delaunay 提交于
      The normal memory (other that DCACHE_OFF) should be executable by default,
      only the device memory (DCACHE_OFF) used for peripheral access should have
      the bit execute never (TTB_SECT_XN_MASK).
      Signed-off-by: NPatrick Delaunay <patrick.delaunay@foss.st.com>
      342e1abd
    • P
      stm32mp: update the mmu configuration for SPL and prereloc · aad84147
      Patrick Delaunay 提交于
      Overidde the weak function dram_bank_mmu_setup() to set the DDR
      (preloc case) or the SYSRAM (in SPL case) executable before to enable
      the MMU and configure DACR.
      
      This weak function is called in dcache_enable/mmu_setup.
      
      This patchs avoids a permission access issue when the DDR is marked
      executable (by calling mmu_set_region_dcache_behaviour with
      DCACHE_DEFAULT_OPTION) after MMU setup and domain access permission
      activation with DACR in dcache_enable.
      Signed-off-by: NPatrick Delaunay <patrick.delaunay@foss.st.com>
      aad84147
    • P
      stm32mp: update MMU config before the relocation · 1419e5b5
      Patrick Delaunay 提交于
      Mark the top of ram, used for relocated U-Boot as a normal memory
      (cacheable and executable) to avoid permission access issue when
      U-Boot jumps to this relocated code.
      
      When MMU is activated in pre-reloc stage; only the beginning of
      DDR is marked executable.
      
      This patch avoids access issue when DACR is correctly managed.
      Signed-off-by: NPatrick Delaunay <patrick.delaunay@foss.st.com>
      1419e5b5
    • H
      reset: Remove addr parameter from reset_cpu() · 35b65dd8
      Harald Seiler 提交于
      Historically, the reset_cpu() function had an `addr` parameter which was
      meant to pass in an address of the reset vector location, where the CPU
      should reset to.  This feature is no longer used anywhere in U-Boot as
      all reset_cpu() implementations now ignore the passed value.  Generic
      code has been added which always calls reset_cpu() with `0` which means
      this feature can no longer be used easily anyway.
      
      Over time, many implementations seem to have "misunderstood" the
      existence of this parameter as a way to customize/parameterize the reset
      (e.g.  COLD vs WARM resets).  As this is not properly supported, the
      code will almost always not do what it is intended to (because all
      call-sites just call reset_cpu() with 0).
      
      To avoid confusion and to clean up the codebase from unused left-overs
      of the past, remove the `addr` parameter entirely.  Code which intends
      to support different kinds of resets should be rewritten as a sysreset
      driver instead.
      
      This transformation was done with the following coccinelle patch:
      
          @@
          expression argvalue;
          @@
          - reset_cpu(argvalue)
          + reset_cpu()
      
          @@
          identifier argname;
          type argtype;
          @@
          - reset_cpu(argtype argname)
          + reset_cpu(void)
          { ... }
      Signed-off-by: NHarald Seiler <hws@denx.de>
      Reviewed-by: NSimon Glass <sjg@chromium.org>
      35b65dd8
    • H
      Revert "lpc32xx: cpu: add support for soft reset" · 3394f398
      Harald Seiler 提交于
      This reverts commit 576007ae.
      
      The parameter passed to reset_cpu() no longer holds a meaning as all
      call-sites now pass the value 0.  Thus, branching on it is essentially
      dead code and will just confuse future readers.
      
      Revert soft-reset support and just always perform a hard-reset for now.
      This is a preparation for removal of the reset_cpu() parameter across
      the entire tree in a later patch.
      
      Fixes: 576007ae ("lpc32xx: cpu: add support for soft reset")
      Cc: Sylvain Lemieux <slemieux@tycoint.com>
      Signed-off-by: NHarald Seiler <hws@denx.de>
      3394f398
    • H
      board: ns3: Remove superfluous reset logic · 10b86ef9
      Harald Seiler 提交于
      The current implementation of reset_cpu() in the ns3 board code does not
      archieve what it is supposed to (according to the comments), due to
      a number of reasons:
      
       1. The argument to reset_cpu() is _not_ actually passed from the
          `reset` command, but is set to 0 in all call-sites (in this
          specific case, see arch/arm/lib/reset.c).  Thus, performing
          different kinds of resets based on its value will not work as
          expected.
      
       2. Contrary to its documentation, the passed argument is not
          interpreted, but a static `L3_RESET` define is used.  The other
          comment properly notes that this will always perform a L3 reset,
          though.
      
       3. The "parsing" of the static `L3_RESET` value is not even using the
          upper and lower nibble as stated in the comment, but uses the last
          two decimal digits of the value.
      
      This is currently one of the only implementations left in U-Boot, which
      make "use" of the value passed to reset_cpu().  As this is done under
      false assumption (the value does not have any meaning anymore), it makes
      sense to bring it into line with the rest and start ignoring the
      parameter.
      
      This is a preparation for removal of the reset_cpu() parameter across
      the entire tree in a later patch.
      
      Fixes: b5a152e7 ("board: ns3: default reset type to L3")
      Cc: Bharat Gooty <bharat.gooty@broadcom.com>
      Cc: Rayagonda Kokatanur <rayagonda.kokatanur@broadcom.com>
      Signed-off-by: NHarald Seiler <hws@denx.de>
      Reviewed-by: NSimon Glass <sjg@chromium.org>
      10b86ef9
    • H
      nds32: Remove dead reset_cpu() implementation · 5075bf28
      Harald Seiler 提交于
      nds32 is one of the only architectures which still have a reset_cpu()
      implementation that makes use of the `addr` parameter.  The rest of
      U-Boot now ignores it and passes 0 everywhere.  It turns out that even
      here, reset_cpu() is no longer referenced anywhere; reset is either not
      implemented (e.g. ae3xx) or realized using a WDT (e.g. ag101).
      
      Remove this left-over implementation in preparation for the removal of
      the `addr` parameter in the entire tree.
      
      Cc: Rick Chen <rick@andestech.com>
      Signed-off-by: NHarald Seiler <hws@denx.de>
      Reviewed-by: NSimon Glass <sjg@chromium.org>
      Reviewed-by: NRick Chen <rick@andestech.com>
      5075bf28
  2. 02 3月, 2021 1 次提交
  3. 01 3月, 2021 4 次提交
  4. 27 2月, 2021 4 次提交
  5. 26 2月, 2021 22 次提交