Eric Lee / smarc-uboot

27 Jul, 2017

1 commit

  • f1896c45c   spl: make SPL and normal u-boot stage use independent SYS_MALLOC_F_LEN ... Browse Code »
    20

    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
     

21 Jan, 2017

2 commits

  • c67c8c604   board_init.c: Always use memset() ... Browse Code »
    20

    We can make the code read more easily here by simply using memset()
    always as when we don't have an optimized version of the function we
    will still have a version of this function around anyhow.

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

    Tom Rini
     
  • 40d5534cf   ARM: Default to using optimized memset and memcpy routines ... Browse Code »

    We have long had available optimized versions of the memset and memcpy
    functions that are borrowed from the Linux kernel. We should use these
    in normal conditions as the speed wins in many workflows outweigh the
    relatively minor size increase. However, we have a number of places
    where we're simply too close to size limits in SPL and must be able to
    make the size vs performance trade-off in those cases.

    Cc: Philippe Reynes
    Cc: Eric Jarrige
    Cc: Heiko Schocher
    Cc: Magnus Lilja
    Cc: Lokesh Vutla
    Cc: Chander Kashyap
    Cc: Akshay Saraswat
    Cc: Simon Glass
    Cc: Stefan Roese
    Signed-off-by: Tom Rini
    Acked-by: Stefan Roese
    Reviewed-by: Simon Glass

    Tom Rini
     

10 Jun, 2016

1 commit

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 »
    88

    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 »
    63

    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 »
    34

    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