Skip to content
Snippets Groups Projects
  1. Jun 13, 2016
    • Alexey Brodkin's avatar
      arc: Update data accessors with use of memory barriers · 5bea2bec
      Alexey Brodkin authored
      
      Memory barriers are proven to be a requirement for both compiler and
      real hardware to properly serialize access to critical data.
      
      For example if CPU or data bus it uses may do reordering of data
      accesses absence of memory barriers might easily lead to very subtle and
      hard to debug data corruptions.
      
      This implementation was heavily borrowed from up to date Linux kernel.
      
      Signed-off-by: default avatarAlexey Brodkin <abrodkin@synopsys.com>
      5bea2bec
    • Alexey Brodkin's avatar
      arc/cache: Flush & invalidate all caches right before enabling IOC · a4a43fcf
      Alexey Brodkin authored
      
      According to ARC HS databook it is required to flush and disable
      caches prior programming IOC registers. Otherwise ongoing coherent
      memory operations may not observe the coherency protocols as
      expected.
      
      But since in ARC HS v2.1 there's no way to disable SLC (AKA L2 cache)
      we're doing our best flushing and invalidating it.
      
      Signed-off-by: default avatarAlexey Brodkin <abrodkin@synopsys.com>
      a4a43fcf
    • Alexey Brodkin's avatar
      arc/cache: really do invalidate_dcache_all() even if IOC exists · bd91508b
      Alexey Brodkin authored
      
      invalidate_dcache_all() could be used in different use-cases
      and what is especially important most of those cases won't be
      related to DMAed data to or from peripherals, i.e. we'll be doing
      invalidation of data used purely by CPU cores.
      
      Given that IOC engine only snoops data that goes through DMA
      we need to care ourselves about data used only by CPU cores
      and so remove dependency on IOC from invalidate_dcache_all()
      and always do real invalidation.
      
      Signed-off-by: default avatarAlexey Brodkin <abrodkin@synopsys.com>
      bd91508b
  2. Jun 12, 2016
  3. Jun 10, 2016
  4. Jun 09, 2016
  5. Jun 08, 2016
  6. Jun 07, 2016
  7. Jun 06, 2016
    • Andre Przywara's avatar
      arm/arm64: implement a boot header capability · cdaa633f
      Andre Przywara authored
      
      Some SPL loaders (like Allwinner's boot0, and Broadcom's boot0)
      require a header before the actual U-Boot binary to both check its
      validity and to find other data to load. Sometimes this header may
      only be a few bytes of information, and sometimes this might simply
      be space that needs to be reserved for a post-processing tool.
      
      Introduce a config option to allow assembler preprocessor commands
      to be inserted into the code at the appropriate location; typical
      assembler preprocessor commands might be:
        .space 1000
        .word 0x12345678
      
      Signed-off-by: default avatarAndre Przywara <andre.przywara@arm.com>
      Signed-off-by: default avatarSteve Rae <srae@broadcom.com>
      Commit Notes:
      Please note that the current code:
        start.S (arm64) and
        vectors.S (arm)
      already jumps over some portion of data already, so this option basically
      just increases the size of this region (and the resulting binary).
      
      For use with Allwinner's boot0 blob there is a tool called boot0img[1],
      which fills the header to allow booting A64 based boards.
      For the Pine64 we need a 1536 byte header (including the branch
      instruction) at the moment, so we add this to the defconfig.
      
      [1] https://github.com/apritzel/pine64/tree/master/tools
      
      
      END
      Reviewed-by: default avatarTom Rini <trini@konsulko.com>
      cdaa633f
Loading