09 Oct, 2017

1 commit

  • the new GD address is calculated via board data BD currently
    it require the new GD area locates below BD tightly, so a strict
    constraint is imposed on memory layout which maybe make special
    platform unpleasant.

    fix it by getting new GD address from gd->new_gd directly.

    Signed-off-by: zijun_hu
    Reviewed-by: Simon Glass

    zijun_hu
     

27 Jul, 2017

1 commit

  • Some platforms have very limited SRAM to run SPL code, so there may
    not be the same amount space for a malloc pool before relocation in
    the SPL stage as the normal U-Boot stage.

    Make SPL and (the full) U-Boot stage use independent SYS_MALLOC_F_LEN,
    so the size of pre-relocation malloc pool can be configured memory
    space independently.

    Signed-off-by: Andy Yan
    Reviewed-by: Tom Rini
    Acked-by: Philipp Tomsich
    Reviewed-by: Philipp Tomsich
    [fixed up commit-message:]
    Signed-off-by: Philipp Tomsich

    Andy Yan
     

06 Mar, 2015

1 commit


14 Dec, 2014

1 commit

  • Move GD_BIST from lib/asm-offsets.c to arch/x86/lib/asm-offsets.c
    as it is x86 arch specific stuff. Also remove GENERATED_GD_RELOC_OFF
    which is not referenced anymore.

    Signed-off-by: Bin Meng
    Acked-by: Simon Glass

    Bin Meng
     

21 Nov, 2014

1 commit

  • The built in self test value is available in register eax on start-up. Save
    it so that it can be accessed later. Unfortunately we must wait until the
    global_data is available before we can do this, so there is a little bit of
    shuffling to keep it around.

    Signed-off-by: Simon Glass
    Reviewed-by: Bin Meng

    Simon Glass
     

23 Jul, 2014

1 commit

  • 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: Simon Glass

    Simon Glass
     

24 Jul, 2013

1 commit


09 Jan, 2013

1 commit

  • Move all the C runtime setup code from every start.S
    in arch/arm into arch/arm/lib/crt0.S. This covers
    the code sequence from setting up the initial stack
    to calling into board_init_r().

    Also, rewrite the C runtime setup and make functions
    board_init_*() and relocate_code() behave according to
    normal C semantics (no jumping across the C stack any
    more, etc).

    Some SPL targets had to be touched because they use
    start.S explicitly or for some reason; the relevant
    maintainers and custodians are cc:ed.

    Signed-off-by: Albert ARIBAUD

    Albert ARIBAUD
     

18 Jan, 2011

1 commit


10 Jan, 2011

1 commit


27 Oct, 2010

2 commits

  • CONFIG_SYS_GBL_DATA_SIZE has always been just a bad workarond for not
    being able to use "sizeof(struct global_data)" in assembler files.
    Recent experience has shown that manual synchronization is not
    reliable enough. This patch renames CONFIG_SYS_GBL_DATA_SIZE into
    GENERATED_GBL_DATA_SIZE which gets automatically generated by the
    asm-offsets tool. In the result, all definitions of this value can be
    deleted from the board config files. We have to make sure that all
    files that reference such data include the new file.

    No other changes have been done yet, but it is obvious that similar
    changes / simplifications can be done for other, related macro
    definitions as well.

    Signed-off-by: Wolfgang Denk
    Acked-by: Kumar Gala

    Wolfgang Denk
     
  • A recurrent issue is that certain C level constructs like sizeof() or
    offsetof() cannot be used in assembler files, which is inconvenient
    when such constructs are used in the definition of macro names etc.

    To avoid duplication of such definitions (and thus another cause of
    problems), we adapt the Linux way to automatically generate the
    respective definitions from the respective C header files.

    In Linux, this is implemented in include/linux/kbuild.h, Kbuild, and
    arch/*/kernel/asm-offsets.c; we adapt the code from the Linux v2.6.36
    kernel tree.

    We also copy the concept of the include/generated/ directory which can
    be used to hold other automatically generated files as well.

    We start with an architecture-independent lib/asm-offsets.c which
    generates include/generated/generic-asm-offsets.h (included by
    include/asm-offsets.h, which is what will be referred to in the actual
    source code). Later this may be extended by architecture-specific
    arch/*/lib/asm-offsets.c files that will generate a
    include/generated/asm-offsets.h.

    Signed-off-by: Wolfgang Denk
    Acked-by: Kumar Gala

    Wolfgang Denk