Skip to content

U
U-Boot.Mirror

OS / U-Boot.Mirror

通知 1
Star 0
Fork 0
U
U-Boot.Mirror

体验新版 GitCode，发现更多精彩内容 >>

切换分支/标签
  1. 29 3月, 2015 1 次提交
    • A
      common/board_f: move board_init_f_mem() from #else CONFIG_X86 · 5bcd19aa
      由 Alexey Brodkin 提交于 
      Purpose of this change is to make it possible to re-use code currently
used on X86 solely for other architectures. For example:
 * init_sequence_f_r
 * board_init_f_r

Even though board_init_f_mem() has nothing to do with any particular
architecture it won't work (at least in current implementation) for X86.

This is because on X86 "gd" is an alias to function get_fs_gd_ptr(),
thus we cannot assign anything to it.

So this change separates selection of board_init_f_mem() from X86 while
keeping it disabled for X86 still.
Signed-off-by: NAlexey Brodkin <abrodkin@synopsys.com>
Cc: Simon Glass <sjg@chromium.org>
Cc: Tom Rini <trini@konsulko.com>
      5bcd19aa
  3. 13 3月, 2015 1 次提交
  5. 06 3月, 2015 3 次提交
  7. 05 3月, 2015 1 次提交
    • S
      common: board: support systems with where RAM ends beyond 4GB · 1e4d11a5
      由 Stephen Warren 提交于 
      Some systems have so much RAM that the end of RAM is beyond 4GB. An
example would be a Tegra124 system (where RAM starts at 2GB physical)
that has more than 2GB of RAM.

In this case, we can gd->ram_size to represent the actual RAM size, so
that the actual RAM size is passed to the OS. This is useful if the OS
implements LPAE, and can actually use the "extra" RAM.

However, U-Boot does not implement LPAE and so must deal with 32-bit
physical addresses. To this end, we enhance board_get_usable_ram_top() to
detect the "over-sized" case, and limit the relocation addres so that it
fits into 32-bits of physical address space.
Signed-off-by: NStephen Warren <swarren@nvidia.com>
Reviewed-by: NSimon Glass <sjg@chromium.org>
Signed-off-by: NTom Warren <twarren@nvidia.com>
      1e4d11a5
  9. 18 2月, 2015 2 次提交
  11. 13 2月, 2015 1 次提交
    • S
      Introduce board_init_f_mem() to handle early memory layout · 74d01867
      由 Simon Glass 提交于 
      At present on some architectures we set up the following before calling
board_init_f():

   - global_data
   - stack
   - early malloc memory

Adding the code to support early malloc and global data setup to every
arch's assembler start-up is a pain. Also this code is not actually
architecture-specific. We can use common code for all architectures and
with a bit of care we can write this code in C.

Add a new function to deal with this. It should be called after memory
is available, with a pointer to the top of the area that should be used
before relocation. The function will set things up and return the lowest
memory address that it allocated/used. That can then be set as the top
of the stack.

Note that on some archs this function will use the stack, so the stack
pointer should be set to same value as is pased to board_init_f_mem().
A margin of 128 bytes will be left for this stack, so that it is not
overwritten. This means that 64 bytes is wasted by this early call.
This is not strictly necessary on several more modern archs, so we could
remove this at the cost of some arch-dependent code.

With this function there is no-longer any need for the assembler code to
zero global_data or set up the early malloc pointers.
Signed-off-by: NSimon Glass <sjg@chromium.org>
      74d01867
  13. 09 2月, 2015 1 次提交
  15. 08 2月, 2015 1 次提交
  17. 30 1月, 2015 1 次提交
  19. 24 1月, 2015 1 次提交
  21. 13 1月, 2015 1 次提交
  23. 30 12月, 2014 1 次提交
  25. 25 11月, 2014 1 次提交
  27. 23 11月, 2014 3 次提交
  29. 21 11月, 2014 4 次提交
  31. 25 10月, 2014 1 次提交
  33. 17 9月, 2014 2 次提交
  35. 11 9月, 2014 1 次提交
  37. 24 8月, 2014 1 次提交
  39. 20 8月, 2014 1 次提交
  41. 07 8月, 2014 1 次提交
  43. 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
  45. 19 7月, 2014 1 次提交
  47. 13 5月, 2014 3 次提交
  49. 20 4月, 2014 2 次提交
  51. 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
  53. 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