1. 23 Aug, 2012 2 commits
    • Scott Wood's avatar
      powerpc/fsl-corenet: work around erratum A004510 · 33eee330
      Scott Wood authored
      Erratum A004510 says that under certain load conditions, modified
      cache lines can be discarded, causing data corruption.
      To work around this, several CCSR and DCSR register updates need to be
      made in a careful manner, so that there is no other transaction in
      corenet when the update is made.
      The update is made from a locked cacheline, with a delay before to flush
      any previous activity, and a delay after to flush the CCSR/DCSR update.
      We can't use a readback because that would be another corenet
      transaction, which is not allowed.
      We lock the subsequent cacheline to prevent it from being fetched while
      we're executing the previous cacheline.  It is filled with nops so that a
      branch doesn't cause us to fetch another cacheline.
      Ordinarily we are running in a cache-inhibited mapping at this point, so
      we temporarily change that.  We make it guarded so that we should never
      see a speculative load, and we never do an explicit load.  Thus, only the
      I-cache should ever fill from this mapping, and we flush/unlock it
      afterward.  Thus we should avoid problems from any potential cache
      aliasing between inhibited and non-inhibited mappings.
      NOTE that if PAMU is used with this patch, it will need to use a
      dedicated LAW as described in the erratum.  This is the responsibility
      of the OS that sets up PAMU.
      Signed-off-by: default avatarScott Wood <scottwood@freescale.com>
      Signed-off-by: default avatarAndy Fleming <afleming@freescale.com>
    • York Sun's avatar
      powerpc/mpc85xx: Make NMG_CPU_A011 workaround conditional · 57125f22
      York Sun authored
      This erratum applies to the following SoCs:
      P4080 rev 1.0, 2.0, fixed in rev 3.0
      P2041 rev 1.0, 1.1, fixed in rev 2.0
      P3041 rev 1.0, 1.1, fixed in rev 2.0.
      Workaround for erratum NMG_CPU_A011 is enabled by default. This workaround
      may degrade performance. P4080 erratum CPU22 shares the same workaround.
      So it is always enabled for P4080. For other SoCs, it can be disabled by
      hwconfig with syntax:
      Signed-off-by: default avatarYork Sun <yorksun@freescale.com>
      Signed-off-by: default avatarAndy Fleming <afleming@freescale.com>
  2. 06 Jul, 2012 3 commits
  3. 29 Nov, 2011 1 commit
    • Kumar Gala's avatar
      powerpc/85xx: Add workaround for erratum CPU-A003999 · 43f082bb
      Kumar Gala authored
      Erratum A-003999: Running Floating Point instructions requires special
      Floating point arithmetic operations may result in an incorrect value.
      Perform a read modify write to set bit 7 to a 1 in SPR 977 before
      executing any floating point arithmetic operation. This bit can be set
      when setting MSR[FP], and can be cleared when clearing MSR[FP].
      Alternatively, the bit can be set once at boot time, and never cleared.
      There will be no performance degradation due to setting this bit.
      Signed-off-by: default avatarKumar Gala <galak@kernel.crashing.org>
  4. 29 Jul, 2011 1 commit
  5. 26 Oct, 2010 1 commit
    • Wolfgang Denk's avatar
      Replace CONFIG_SYS_GBL_DATA_SIZE by auto-generated value · 25ddd1fb
      Wolfgang Denk authored
      CONFIG_SYS_GBL_DATA_SIZE has always been just a bad workarond for not
      being able to use "sizeof(struct global_data)" in assembler files.
      Recent experience has shown that manual synchronization is not
      reliable enough.  This patch renames CONFIG_SYS_GBL_DATA_SIZE into
      GENERATED_GBL_DATA_SIZE which gets automatically generated by the
      asm-offsets tool.  In the result, all definitions of this value can be
      deleted from the board config files.  We have to make sure that all
      files that reference such data include the new <asm-offsets.h> file.
      No other changes have been done yet, but it is obvious that similar
      changes / simplifications can be done for other, related macro
      definitions as well.
      Signed-off-by: default avatarWolfgang Denk <wd@denx.de>
      Acked-by: default avatarKumar Gala <galak@kernel.crashing.org>
  6. 26 Jul, 2010 1 commit
  7. 21 Apr, 2010 1 commit
  8. 13 Apr, 2010 1 commit
  9. 07 Apr, 2010 2 commits
  10. 30 Mar, 2010 1 commit
  11. 05 Jan, 2010 2 commits
  12. 31 Oct, 2009 1 commit
  13. 27 Oct, 2009 1 commit
    • Peter Tyser's avatar
      85xx: MP Boot Page Translation update · 5ccd29c3
      Peter Tyser authored
      This change has 3 goals:
      - Have secondary cores be released into spin loops at their 'true'
        address in SDRAM.  Previously, secondary cores were put into spin
        loops in the 0xfffffxxx address range which required that boot page
        translation was always enabled while cores were in their spin loops.
      - Allow the TLB window that the primary core uses to access the
        secondary cores boot page to be placed at any address.  Previously, a
        TLB window at 0xfffff000 was always used to access the seconary cores'
        boot page.  This TLB address requirement overlapped with other
        peripherals on some boards (eg XPedite5370).  By default, the boot
        page TLB will still use the 0xfffffxxx address range, but this can be
        overridden on a board-by-board basis by defining a custom
        CONFIG_BPTR_VIRT_ADDR.  Note that the TLB used to map the boot page
        remains in use while U-Boot executes.  Previously it was only
        temporarily used, then restored to its initial value.
      - Allow Boot Page Translation to be disabled on bootup.  Previously,
        Boot Page Translation was always left enabled after secondary cores
        were brought out of reset.  This caused the 0xfffffxxx address range
        to somewhat "magically" be translated to an address in SDRAM.  Some
        boards may not want this oddity in their memory map, so defining
        CONFIG_MPC8xxx_DISABLE_BPTR will turn off Boot Page Translation after
        the secondary cores are initialized.
      These changes are only applicable to 85xx boards with CONFIG_MP defined.
      Signed-off-by: default avatarPeter Tyser <ptyser@xes-inc.com>
      Signed-off-by: default avatarKumar Gala <galak@kernel.crashing.org>
  14. 03 Oct, 2009 2 commits
  15. 24 Sep, 2009 1 commit
  16. 08 Sep, 2009 1 commit
    • Kumar Gala's avatar
      85xx: Add support for setting IVORs to fixed offset defaults · 26f4cdba
      Kumar Gala authored
      In future Book-E implementations IVORs will most likely go away and be
      replaced with fixed offsets.  The IVPR will continue to exist to allow
      for relocation of the interrupt vectors.
      This code adds support to setup the IVORs as their fixed offset values
      per the ISA 2.06 spec when we transition from u-boot to another OS
      either via 'bootm' or a cpu release.
      Signed-off-by: default avatarKumar Gala <galak@kernel.crashing.org>
  17. 28 Aug, 2009 1 commit
  18. 30 Mar, 2009 1 commit
  19. 20 Dec, 2008 1 commit
    • Haiying Wang's avatar
      Set IVPR to kenrel entry point in second core boot page · 181a3650
      Haiying Wang authored
      Assuming the OSes exception vectors start from the base of kernel address, and
      the kernel physical starting address can be relocated to an non-zero address.
      This patch enables the second core to have a valid IVPR for debugger before
      kernel setting IVPR in CAMP mode. Otherwise, IVPR is 0x0 and it is not a valid
      value for second core which runs kernel at different physical address other
      than 0x0.
      Signed-off-by: default avatarHaiying Wang <Haiying.Wang@freescale.com>
  20. 24 Oct, 2008 1 commit
  21. 09 Sep, 2008 1 commit
  22. 11 Aug, 2008 1 commit
  23. 29 Apr, 2008 1 commit
    • Kumar Gala's avatar
      85xx: Additional fixes and cleanup of MP code · cf6cc014
      Kumar Gala authored
      * adjust __spin_table alignment to match ePAPR v0.94 spec
      * loop over all cpus when determing who is up.  This fixes an issue if
        the "boot cpu" isn't core0.  The "boot cpu" will already be in the
        cpu_up_mask so there is no harm
      * Added some protection in the code to ensure proper behavior.  These
        changes are explicitly needed but don't hurt:
        - Added eieio to ensure the "hot word" of the table is written after
          all other table updates have occurred.
        - Added isync to ensure we don't prefetch loading of table entries
          until we a released
      These issues we raised by Dave Liu.
      Signed-off-by: default avatarKumar Gala <galak@kernel.crashing.org>
  24. 26 Mar, 2008 2 commits