23 Jan, 2020

1 commit


10 Jan, 2020

1 commit

  • Most platforms do not set up gd->start_addr_sp in SPL. Since this is
    required for CONFIG_SPL_SYS_REPORT_SACK_F_USAGE to work correctly, set
    up gd->start_addr_sp in SPL to the value passed to
    board_init_f_init_reserve if it is not set yet.

    Fixes: d8c0332031 ("spl: implement stack usage check")
    Signed-off-by: Simon Goldschmidt

    Simon Goldschmidt
     

12 Aug, 2019

1 commit

  • This implements a stack usage check in SPL.

    Many boards start up SPL to run code + data from one common, rather small
    SRAM. To implement a sophisticated SPL binary size limit on such boards,
    the stack size (as well as malloc size and global data size) must be
    subtracted from this SRAM size.

    However, to do that properly, the stack size first needs to be known.

    This patch adds a new Kconfig option:
    - SPL_SYS_REPORT_STACK_F_USAGE: memset(0xaa) the whole area of the stack
    very early and check stack usage based on this constant later before the
    stack is switched to DRAM

    Initializing the stack and checking it is implemented in weak functions,
    in case a board does not use the stack as saved in gd->start_addr_sp.

    Signed-off-by: Simon Goldschmidt

    Simon Goldschmidt
     

26 Nov, 2018

1 commit

  • There is some basic informaton that SPL normally wants to pass through to
    U-Boot, such as the SDRAM size and bank information.

    Mkae use of the new bloblist structure for this. Add a new 'handoff' blob
    which is set up in SPL and passed to U-Boot proper. Also adda test for
    sandbox_spl that checks that this works correctly and a new 'sb' command
    to show the information passed from SPL.

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

    Simon Glass
     

07 May, 2018

1 commit

  • When U-Boot started using SPDX tags we were among the early adopters and
    there weren't a lot of other examples to borrow from. So we picked the
    area of the file that usually had a full license text and replaced it
    with an appropriate SPDX-License-Identifier: entry. Since then, the
    Linux Kernel has adopted SPDX tags and they place it as the very first
    line in a file (except where shebangs are used, then it's second line)
    and with slightly different comment styles than us.

    In part due to community overlap, in part due to better tag visibility
    and in part for other minor reasons, switch over to that style.

    This commit changes all instances where we have a single declared
    license in the tag as both the before and after are identical in tag
    contents. There's also a few places where I found we did not have a tag
    and have introduced one.

    Signed-off-by: Tom Rini

    Tom Rini
     

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
     

21 Jan, 2017

2 commits

  • 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
     
  • 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

  • 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

  • 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
     
  • 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

  • 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