Skip to content

U
U-Boot.Mirror

OS / U-Boot.Mirror

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

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

切换分支/标签
  1. 19 4月, 2015 1 次提交
  3. 17 4月, 2015 1 次提交
  5. 03 4月, 2015 1 次提交
    • A
      arc: clean-up init procedure · 3fb80163
      由 Alexey Brodkin 提交于 
      Intention behind this work was elimination of as much assembly-written
code as it is possible.

In case of ARC we already have relocation fix-up implemented in C so why
don't we use C for U-Boot copying, .bss zeroing etc.

It turned out x86 uses pretty similar approach so we re-used parts of
code in "board_f.c" initially implemented for x86.

Now assembly usage during init is limited to stack- and frame-pointer
setup before and after relocation.
Signed-off-by: NAlexey Brodkin <abrodkin@synopsys.com>
Cc: Simon Glass <sjg@chromium.org>
      3fb80163
  7. 29 3月, 2015 2 次提交
    • A
      m68k: fix 3 broken boards · 944ab340
      由 angelo@sysam.it 提交于 
      Fix eb_cpu5282 and eb_cpu5282_internal unresolved external error.
These boards have video but don't need any ppc related
video_setmem().

Fix M53017EVB moving away embedded env to a different offset,
as in M52277EVB.
Signed-off-by: NAngelo Dureghello <angelo@sysam.it>
      944ab340
    • 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
  9. 13 3月, 2015 1 次提交
  11. 06 3月, 2015 3 次提交
  13. 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
  15. 18 2月, 2015 2 次提交
  17. 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
  19. 09 2月, 2015 1 次提交
  21. 08 2月, 2015 1 次提交
  23. 30 1月, 2015 1 次提交
  25. 24 1月, 2015 1 次提交
  27. 13 1月, 2015 1 次提交
  29. 30 12月, 2014 1 次提交
  31. 25 11月, 2014 1 次提交
  33. 23 11月, 2014 3 次提交
  35. 21 11月, 2014 4 次提交
  37. 25 10月, 2014 1 次提交
  39. 17 9月, 2014 2 次提交
  41. 11 9月, 2014 1 次提交
  43. 24 8月, 2014 1 次提交
  45. 20 8月, 2014 1 次提交
  47. 07 8月, 2014 1 次提交
  49. 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
  51. 19 7月, 2014 1 次提交
  53. 13 5月, 2014 3 次提交