History log of /openbmc/u-boot/common/init/board_init.c (Results 1 – 14 of 14)
Revision (<<< Hide revision tags) (Show revision tags >>>) Date Author Comments
Revision tags: v00.04.15, v00.04.14, v00.04.13, v00.04.12, v00.04.11, v00.04.10, v00.04.09, v00.04.08, v00.04.07, v00.04.06, v00.04.05, v00.04.04, v00.04.03, v00.04.02, v00.04.01, v00.04.00, v2021.04, v00.03.03, v2021.01, v2020.10, v2020.07, v00.02.13, v2020.04, v2020.01, v2019.10, v00.02.05, v00.02.04, v00.02.03, v00.02.02, v00.02.01, v2019.07, v00.02.00, v2019.04, v2018.07
# 83d290c5 06-May-2018 Tom Rini <trini@konsulko.com>

SPDX: Convert all of our single license tags to Linux Kernel style

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

SPDX: Convert all of our single license tags to Linux Kernel style

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 <trini@konsulko.com>

show more ...


Revision tags: v2018.03, v2018.01, v2017.11
# f1896c45 24-Jul-2017 Andy Yan <andy.yan@rock-chips.com>

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 reloc

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>

show more ...


# c67c8c60 12-Jan-2017 Tom Rini <trini@konsulko.com>

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 o

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>

show more ...


# 40d5534c 12-Jan-2017 Tom Rini <trini@konsulko.com>

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 th

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>

show more ...


Revision tags: v2016.07, openbmc-20160624-1
# dc557e9a 18-Jun-2016 Stefano Babic <sbabic@denx.de>

Merge branch 'master' of git://git.denx.de/u-boot

Signed-off-by: Stefano Babic <sbabic@denx.de>


# 496c5483 07-Jun-2016 Heiko Schocher <hs@denx.de>

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>


# af7a5551 15-Jan-2016 Simon Glass <sjg@chromium.org>

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 addresse

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>

show more ...


# adc421e4 25-Nov-2015 Albert ARIBAUD <albert.u.boot@aribaud.net>

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

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>

show more ...


# ecc30663 25-Nov-2015 Albert ARIBAUD <albert.u.boot@aribaud.net>

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 en

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>

show more ...


Revision tags: v2016.01-rc1
# 9ac4fc82 12-Nov-2015 Fabio Estevam <fabio.estevam@freescale.com>

board_init: Change the logic to setup malloc_base

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

board_init: Change the logic to setup malloc_base

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 <fabio.estevam@freescale.com>
Reviewed-by: Simon Glass <sjg@chromium.org>

show more ...


# e573bdb3 30-Oct-2015 Stefano Babic <sbabic@denx.de>

Merge branch 'master' of git://git.denx.de/u-boot


Revision tags: v2015.10
# 518f0bcc 19-Oct-2015 Simon Glass <sjg@chromium.org>

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

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>

show more ...


# 12360982 19-Oct-2015 Simon Glass <sjg@chromium.org>

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>


# af6bbd4d 19-Oct-2015 Simon Glass <sjg@chromium.org>

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

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>

show more ...