1. 08 2月, 2015 1 次提交
  2. 30 1月, 2015 1 次提交
  3. 24 1月, 2015 1 次提交
  4. 13 1月, 2015 1 次提交
  5. 30 12月, 2014 1 次提交
  6. 25 11月, 2014 1 次提交
  7. 23 11月, 2014 3 次提交
  8. 21 11月, 2014 4 次提交
  9. 25 10月, 2014 1 次提交
  10. 17 9月, 2014 2 次提交
  11. 11 9月, 2014 1 次提交
  12. 24 8月, 2014 1 次提交
  13. 20 8月, 2014 1 次提交
  14. 07 8月, 2014 1 次提交
  15. 23 7月, 2014 2 次提交
    • S
      dm: Support driver model prior to relocation · ab7cd627
      Simon Glass 提交于
      Initialise devices marked 'pre-reloc' and make them available prior to
      relocation. Note that this requires pre-reloc malloc() to be available.
      Signed-off-by: NSimon Glass <sjg@chromium.org>
      ab7cd627
    • S
      Add a simple malloc() implementation for pre-relocation · d59476b6
      Simon Glass 提交于
      If we are to have driver model before relocation we need to support some
      way of calling memory allocation routines.
      
      The standard malloc() is pretty complicated:
      
      1. It uses some BSS memory for its state, and BSS is not available before
      relocation
      
      2. It supports algorithms for reducing memory fragmentation and improving
      performace of free(). Before relocation we could happily just not support
      free().
      
      3. It includes about 4KB of code (Thumb 2) and 1KB of data. However since
      this has been loaded anyway this is not really a problem.
      
      The simplest way to support pre-relocation malloc() is to reserve an area
      of memory and allocate it in increasing blocks as needed. This
      implementation does this.
      
      To enable it, you need to define the size of the malloc() pool as described
      in the README. It will be located above the pre-relocation stack on
      supported architectures.
      
      Note that this implementation is only useful on machines which have some
      memory available before dram_init() is called - this includes those that
      do no DRAM init (like tegra) and those that do it in SPL (quite a few
      boards). Enabling driver model preior to relocation for the rest of the
      boards is left for a later exercise.
      Signed-off-by: NSimon Glass <sjg@chromium.org>
      d59476b6
  16. 19 7月, 2014 1 次提交
  17. 13 5月, 2014 3 次提交
  18. 20 4月, 2014 2 次提交
  19. 18 3月, 2014 1 次提交
    • S
      sandbox: Use os functions to read host device tree · 95fac6ab
      Simon Glass 提交于
      At present we use U-Boot's filesystem layer to read the sandbox device tree,
      but this is problematic since it relies on a temporary feauture added
      there. Since we plan to implement proper block layer support for sandbox,
      change this code to use the os layer functions instead. Also use the new
      fdt_create_empty_tree() instead of our own code.
      Signed-off-by: NSimon Glass <sjg@chromium.org>
      95fac6ab
  20. 07 3月, 2014 1 次提交
    • M
      powerpc: mpc8260: consolidate CONFIG_MPC8260 and CONFIG_8260 · 58dac327
      Masahiro Yamada 提交于
      Before this commit, CONFIG_MPC8260 and CONFIG_8260
      were used mixed-up.
      
      All boards with mpc8260 cpu defined both of them:
        - CONFIG_MPC8260 was defined in board config headers
            and include/common.h
        - CONFIG_8260 was defined arch/powerpc/cpu/mpc8260/config.mk
      
      We do not need to have both of them.
      This commit keeps only CONFIG_MPC8260.
      
      This commit does:
       - Delete CONFIG_8260 and CONFIG_MPC8260 definition
         in config headers and include/common.h
       - Rename CONFIG_8260 to CONFIG_MPC8260
          in arch/powerpc/cpu/mpc8260/config.mk.
       - Rename #ifdef CONFIG_8260 to #ifdef CONFIG_MPC8260
      Signed-off-by: NMasahiro Yamada <yamada.m@jp.panasonic.com>
      Cc: Wolfgang Denk <wd@denx.de>
      58dac327
  21. 27 2月, 2014 1 次提交
  22. 22 2月, 2014 1 次提交
  23. 20 2月, 2014 2 次提交
  24. 09 1月, 2014 3 次提交
  25. 13 12月, 2013 1 次提交
    • A
      board_f: explicitly disable console on early boot · 9aed5a27
      Alexey Brodkin 提交于
      If U-Boot build with DEBUG enabled/defined the first call of "debug"
      function (that dumps data to any available console) will happen before
      zeroing of initial "gd" in init call "zero_global_data" in
      "init_sequence_f".
      
      And if stack was not filled with zeros chances are high that
      "gd->have_console" won't be 0. In its turn it will cause attempt to
      output things to non-initialized yet serial console.
      
      So for safety and predictability we set "gd->have_console = 0".
      Signed-off-by: NAlexey Brodkin <abrodkin@synopsys.com>
      
      Cc: Mischa Jonker <mjonker@synopsys.com>
      Cc: Wolfgang Denk <wd@denx.de>
      Cc: Simon Glass <sjg@chromium.org>
      Acked-by: NSimon Glass <sjg@chromium.org>
      9aed5a27
  26. 17 10月, 2013 1 次提交
    • T
      i2c: fix init on generic board · 815a76f2
      trem 提交于
      On generic board, the i2c init initialize only
      one bus. But the new i2c subsystem allow to
      manage severals i2c bus. So in the case, instead
      of initializing a bus, we just set the current
      i2c bus. The initialization will be done in
      the i2c command.
      Signed-off-by: NPhilippe Reynes <tremyfr@yahoo.fr>
      815a76f2
  27. 24 7月, 2013 1 次提交