Eric Lee / smarc-uboot

15 Jan, 2016

1 commit

  • af7a55514   x86: Fix board init breakage ... Browse Code »

    Commit ecc30663 ("Fix board init code to respect the C runtime environment")
    breaks x86. This was mentioned on https://patchwork.ozlabs.org/patch/548644
    but not addressed. Correct it so that x86 boards boot again.

    Signed-off-by: Simon Glass
    Reviewed-by: Tom Rini

    Simon Glass
     

14 Jan, 2016

2 commits

  • adc421e4c   arm: move gd handling outside of C code ... Browse Code »
    91

    As of gcc 5.2.1 for Thumb-1, it is not possible any
    more to assign gd from C code, as gd is mapped to r9,
    and r9 may now be saved in the prolog sequence, and
    restored in the epilog sequence, of any C functions.

    Therefore arch_setup_gd(), which is supposed to set
    r9, may actually have no effect, causing U-Boot to
    use a bad address to access GD.

    Fix this by never calling arch_setup_gd() for ARM,
    and instead setting r9 in arch/arm/lib/crt0.S, to
    the value returned by board_init_f_alloc_reserve().

    Signed-off-by: Albert ARIBAUD
    Reviewed-by: Simon Glass

    Albert ARIBAUD
     
  • ecc306639   Fix board init code to respect the C runtime environment ... Browse Code »
    65

    board_init_f_mem() alters the C runtime environment's
    stack it is actually already using. This is not a valid
    behaviour within a C runtime environment.

    Split board_init_f_mem into C functions which do not alter
    their own stack and always behave properly with respect to
    their C runtime environment.

    Signed-off-by: Albert ARIBAUD
    Acked-by: Thomas Chou

    Albert ARIBAUD
     

13 Nov, 2015

1 commit

  • 9ac4fc820   board_init: Change the logic to setup malloc_base ... Browse Code »
    35

    Prior to commit 5ba534d247d418 ("arm: Switch 32-bit ARM to using generic
    global_data setup") we used to have assembly code that configured the
    malloc_base address.

    Since this commit we use the board_init_f_mem() function in C to setup
    malloc_base address.

    In board_init_f_mem() there was a deliberate choice to support only
    early malloc() or full malloc() in SPL, but not both.

    Adapt this logic to allow both to be used, one after the other, in SPL.

    This issue has been observed in a Congatec board, where we need to
    retrieve the manufacturing information from the SPI NOR (the SPI API
    calls malloc) prior to configuring the DRAM. In this case as malloc_base
    was not configured we always see malloc to fail.

    With this change we are able to use malloc in SPL prior to DRAM gets
    initialized.

    Also update the CONFIG_SYS_SPL_MALLOC_START entry in the README file.

    Signed-off-by: Fabio Estevam
    Reviewed-by: Simon Glass

    Fabio Estevam
     

25 Oct, 2015

3 commits