Commit graph

11 commits

Author SHA1 Message Date
Andy Yan
f1896c45cb spl: make SPL and normal u-boot stage use independent SYS_MALLOC_F_LEN
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 <andy.yan@rock-chips.com>
Reviewed-by: Tom Rini <trini@konsulko.com>
Acked-by: Philipp Tomsich <philipp.tomsich@theobroma-systems.com>
Reviewed-by: Philipp Tomsich <philipp.tomsich@theobroma-systems.com>
[fixed up commit-message:]
Signed-off-by: Philipp Tomsich <philipp.tomsich@theobroma-systems.com>
2017-07-27 14:59:03 +02:00
Tom Rini
c67c8c604b board_init.c: Always use memset()
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 <sjg@chromium.org>
Signed-off-by: Tom Rini <trini@konsulko.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
2017-01-20 15:38:01 -05:00
Tom Rini
40d5534cff ARM: Default to using optimized memset and memcpy routines
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 <tremyfr@yahoo.fr>
Cc: Eric Jarrige <eric.jarrige@armadeus.org>
Cc: Heiko Schocher <hs@denx.de>
Cc: Magnus Lilja <lilja.magnus@gmail.com>
Cc: Lokesh Vutla <lokeshvutla@ti.com>
Cc: Chander Kashyap <k.chander@samsung.com>
Cc: Akshay Saraswat <akshay.s@samsung.com>
Cc: Simon Glass <sjg@chromium.org>
Cc: Stefan Roese <sr@denx.de>
Signed-off-by: Tom Rini <trini@konsulko.com>
Acked-by: Stefan Roese <sr@denx.de>
Reviewed-by: Simon Glass <sjg@chromium.org>
2017-01-20 15:38:01 -05:00
Heiko Schocher
496c5483e9 bootstage: call show_boot_progress also in SPL
show_boot_progress() is now called from SPL also.

Signed-off-by: Heiko Schocher <hs@denx.de>
2016-06-09 13:53:08 -04:00
Simon Glass
af7a55514a x86: Fix board init breakage
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 <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@konsulko.com>
2016-01-15 08:09:46 -05:00
Albert ARIBAUD
adc421e4ce arm: move gd handling outside of C code
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 <albert.u.boot@aribaud.net>
Reviewed-by: Simon Glass <sjg@chromium.org>
2016-01-13 21:05:18 -05:00
Albert ARIBAUD
ecc306639e Fix board init code to respect the C runtime environment
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 <albert.u.boot@aribaud.net>
Acked-by: Thomas Chou <thomas@wytron.com.tw>
2016-01-13 21:05:17 -05:00
Fabio Estevam
9ac4fc8207 board_init: Change the logic to setup malloc_base
Prior to commit 5ba534d247 ("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 <fabio.estevam@freescale.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
2015-11-12 20:34:07 -05:00
Simon Glass
518f0bccc4 board_init_f_mem(): Don't create an unused early malloc() area
Change the #ifdef so that the early malloc() area is not set up in SPL if
CONFIG_SYS_SPL_MALLOC_START is defined. In that case it would never actually
be used, and just chews up stack space.

Signed-off-by: Simon Glass <sjg@chromium.org>
Tested-by: Masahiro Yamada <yamada.masahiro@socionext.com>
2015-10-24 13:50:35 -04:00
Simon Glass
12360982fa board_init_f_mem(): Don't require memset()
Unfortunately memset() is not always available, so provide a substitute when
needed.

Signed-off-by: Simon Glass <sjg@chromium.org>
2015-10-24 13:50:35 -04:00
Simon Glass
af6bbd4dae Move board_init_f_mem() into a common location
This function will be used by both SPL and U-Boot proper. So move it into
a common place. Also change the #ifdef so that the early malloc() area is
not set up in SPL if CONFIG_SYS_SPL_MALLOC_START is defined. In that case
it would never actually be used, and just chews up stack space.

Signed-off-by: Simon Glass <sjg@chromium.org>
2015-10-24 13:50:34 -04:00