1. 16 Nov, 2019 3 commits
  2. 09 Nov, 2019 2 commits
  3. 29 Sep, 2019 1 commit
  4. 26 Sep, 2019 5 commits
  5. 23 Sep, 2019 1 commit
  6. 21 Sep, 2019 2 commits
  7. 16 Feb, 2019 2 commits
  8. 17 Jan, 2019 1 commit
  9. 10 Oct, 2018 2 commits
  10. 06 Oct, 2018 1 commit
    • Tony Lindgren's avatar
      Help needed: Trying to find out the cause of the freezes. · 40a38c35
      Tony Lindgren authored
      Well for the idle freezing issue, curiously the old
      "disable internal dll" trick seems to work. At least for
      me the system keeps running just fine idling for several
      hours.
      
      Also, looks like we have SDRAM_CONFIG ROWSIZE bits [9:7] set
      to 15 while it should be 16 for 8Gb memory. But I think
      that is just cosmetic, not sure if that is actually used.
      
      Anyways, care to test with the following hack with internal
      dll disabled and ROWSIZE fixed?
      
      If that works for the idle system problem, then we probably
      have some DLL timing related value misconfigured.
      
      Regards,
      
      Tony
      40a38c35
  11. 21 Sep, 2018 2 commits
  12. 08 Aug, 2018 2 commits
  13. 22 Jul, 2018 4 commits
    • Nishanth Menon's avatar
      ARM: OMAP5: Enable support for AVS0 for OMAP5 production devices · 21d5cc02
      Nishanth Menon authored
      OMAP5432 did go into production with AVS class0 registers which were
      mutually exclusive from AVS Class 1.5 registers.
      
      Most OMAP5-uEVM boards use the pre-production Class1.5 which has
      production efuse registers set to 0. However on production devices,
      these are set to valid data.
      
      scale_vcore logic is already smart enough to detect this and use the
      "Nominal voltage" on devices that do not have efuse registers populated.
      
      On a test production device populated as follows:
      MPU OPP_NOM:
      => md.l 0x04A0021C4 1
      4a0021c4: 03a003e9                               ....
      (0x3e9 = 1.01v) vs nom voltage of 1.06v
      MPU OPP_HIGH:
      => md.l 0x04A0021C8 1
      4a0021c8: 03400485                               ..@.
      
      MM OPP_NOM:
      => md.l 0x04A0021A4 1
      4a0021a4: 038003d4                               ....
      (0x3d4 = 980mV) vs nom voltage of 1.025v
      MM OPP_OD:
      => md.l 0x04A0021A8 1
      4a0021a8: 03600403                               ..`.
      
      CORE OPP_NOM:
      => md.l 0x04A0021D8 1
      4a0021d8: 000003cf                               ....
      (0x3cf = 975mV) vs nom voltage of 1.040v
      
      Since the efuse values are'nt currently used, we do not regress on
      existing pre-production samples (they continue to use nominal voltage).
      
      But on boards that do have production samples populated, we can leverage
      the optimal voltages necessary for proper operation.
      
      Tested on:
      a) 720-2644-001 OMAP5UEVM with production sample.
      b) 750-2628-222(A) UEVM5432G-02 with pre-production sample.
      
      Data based on OMAP5432 Technical reference Manual SWPU282AF (May
      2012-Revised Aug 2016)
      
      NOTE: All collaterals on OMAP5432 silicon itself seems to have been
      removed from ti.com, though EVM details are still available:
      http://www.ti.com/tool/OMAP5432-EVMSigned-off-by: default avatarNishanth Menon <nm@ti.com>
      21d5cc02
    • Nishanth Menon's avatar
      ARM: OMAP5: Remove OPP_LOW Definitions for ES2.0 · 7f7a98d8
      Nishanth Menon authored
      ES2.0 descopes OPP_LOW definition. So remove it from macros defined.
      Signed-off-by: default avatarNishanth Menon <nm@ti.com>
      Reviewed-by: default avatarLokesh Vutla <lokeshvutla@ti.com>
      7f7a98d8
    • Matthijs van Duin's avatar
      arm: omap-common: Fix typo in CONFIG_OMAP54XX guard · 41ef538c
      Matthijs van Duin authored
      Some initialization was unintentionally being skipped on omap5.
      
      Fixes: f5af0827 ("arm: omap-common: Guard some parts of the code with CONFIG_OMAP44XX/OMAP54XX")
      Signed-off-by: Matthijs van Duin's avatarMatthijs van Duin <matthijsvanduin@gmail.com>
      Reviewed-by: default avatarTom Rini <trini@konsulko.com>
      41ef538c
    • H. Nikolaus Schaller's avatar
  14. 21 Jul, 2018 7 commits
  15. 01 Jul, 2018 3 commits
  16. 27 Jun, 2018 1 commit
  17. 29 May, 2018 1 commit
    • Tony Lindgren's avatar
      LC15: Increase T_RFC to fix 4GB kernel memory errors · 2b143578
      Tony Lindgren authored
      With u-boot related memory errors out of the way fixed with patch
      "LC15: Fix flakey ddr3 detection with ref_ctrl and ref_ctrl_final",
      we can now narrow down the kernel related errors easily.
      
      Playing with timing changes I narrowed down the kernel hangs to register
      sdram_tim3 where we need to increase the time for T_RFC. This is for
      "Minimum number of DDR clock cycles from Refresh or Load Mode to Refresh
      or Activate, minus one" according to omap5432 TRM.
      
      Maxing out the value for bits 12:4 made the new 4GB pyra's C02 and C03
      boot reliably. And then looking at the timings again, the T_RFC value
      should be 187 - 1 (0xBA) and not 139 - 1 (0x8A). Note the Upper case
      B vs 8 :)
      
      Value 187 - 1 (0xBA) matches Samsung K4B8G1646D-MYK0 datasheet
      "[ Table 34 ] Timing used for IDD and IDDQ Measured - Loop Patterns"
      for DDR3-1066 8Gb memory. We are currently using 4Gb value 139 - 1
      (0x8A).
      
      It is possible that this was caused by B vs 8 typo initially and then
      was not noticed because of the u-boot memory errors and getting confused
      with the memory datasheet for 4Gb vs 4GB while we have four 8Gb memory
      chips.
      
      However I also noticed that value 187 - 1 (0xBA) still won't work
      reliably with new board C05. And new C21 and my older revision board
      C50 still did not work at all. However, using value of 191 - 1 (0xBE)
      makes all of them boot reliably for me. So let's use value 191 - 1
      (0xBE) for now, and adjust it if needed based on testing with more
      pyras.
      
      Note that we still can have pyra hang running two instances of
      memtester 1500M for about 10 minutes on bare CPU boards with no heat
      sink connected. The boards now boot reliably after that though,
      so presumably the pyra heat sink will solve this issue.
      Signed-off-by: default avatarTony Lindgren <tony@atomide.com>
      2b143578