Skip to content
Snippets Groups Projects
  1. Mar 15, 2015
  2. Mar 06, 2015
  3. Mar 05, 2015
  4. Feb 28, 2015
  5. Feb 25, 2015
  6. Feb 06, 2015
  7. Jan 30, 2015
  8. Jan 24, 2015
  9. Jan 14, 2015
  10. Jan 13, 2015
  11. Dec 29, 2014
    • Alexey Brodkin's avatar
      initcall: add explicit hint if initcall was relocated · e38d1cb2
      Alexey Brodkin authored
      
      Commit "initcall: Improve debugging support" makes sense and indeed
      simplifies process of matching initcalls executed with static
      disassembly.
      
      Until you are debugging relocation functionality.
      
      Existign output may make you think that at some point execution somehow
      returned back to non-relocated area. And there're many reasons/problems
      that may provoke this behavior.
      
      In order to make things clear let's add explicit mention in case initall
      was actually relocated like this:
      --->---
      initcall: 810015f8
      Relocation Offset is: 0efcf000
      Relocating to 8ffcf000, new gd at 8fdced3c, sp at 8fdced20
      initcall: 810015b8
      initcall: 8ffd093c
      initcall: 8ffd0a14
      initcall: 81001940 (relocated to 8ffd0940)
      initcall: 81001958 (relocated to 8ffd0958)
      --->---
      
      Note "unexpected" jump from 0x8f... area to 0x81... area.
      Without explanation this raises many questions: execution jumped in
      relocated area right as expected and then for some reason returned back?
      
      But I hope comment in brackets will save some time for those curious
      developers who are careful enough to catch "unexpected jump to pre-reloc
      area" or those unlucky ones who'll have to deal with relocation
      debugging.
      
      Signed-off-by: default avatarAlexey Brodkin <abrodkin@synopsys.com>
      Cc: Simon Glass <sjg@chromium.org>
      Cc: Minkyu Kang <mk7.kang@samsung.com>
      e38d1cb2
  12. Dec 18, 2014
  13. Dec 14, 2014
  14. Dec 11, 2014
  15. Dec 08, 2014
  16. Nov 27, 2014
  17. Nov 25, 2014
  18. Nov 23, 2014
  19. Nov 22, 2014
  20. Nov 21, 2014
    • Simon Glass's avatar
      x86: ivybridge: Implement SDRAM init · 65dd74a6
      Simon Glass authored
      
      Implement SDRAM init using the Memory Reference Code (mrc.bin) provided in
      the board directory and the SDRAM SPD information in the device tree. This
      also needs the Intel Management Engine (me.bin) to work. Binary blobs
      everywhere: so far we have MRC, ME and microcode.
      
      SDRAM init works by setting up various parameters and calling the MRC. This
      in turn does some sort of magic to work out how much memory there is and
      the timing parameters to use. It also sets up the DRAM controllers. When
      the MRC returns, we use the information it provides to map out the
      available memory in U-Boot.
      
      U-Boot normally moves itself to the top of RAM. On x86 the RAM is not
      generally contiguous, and anyway some RAM may be above 4GB which doesn't
      work in 32-bit mode. So we relocate to the top of the largest block of
      RAM we can find below 4GB. Memory above 4GB is accessible with special
      functions (see physmem).
      
      It would be possible to build U-Boot in 64-bit mode but this wouldn't
      necessarily provide any more memory, since the largest block is often below
      4GB. Anyway U-Boot doesn't need huge amounts of memory - even a very large
      ramdisk seldom exceeds 100-200MB. U-Boot has support for booting 64-bit
      kernels directly so this does not pose a limitation in that area. Also there
      are probably parts of U-Boot that will not work correctly in 64-bit mode.
      The MRC is one.
      
      There is some work remaining in this area. Since memory init is very slow
      (over 500ms) it is possible to save the parameters in SPI flash to speed it
      up next time. Suspend/resume support is not fully implemented, or at least
      it is not efficient.
      
      With this patch, link boots to a prompt.
      
      Signed-off-by: default avatarSimon Glass <sjg@chromium.org>
      65dd74a6
Loading