History log of /rk3399_rockchip-uboot/common/init/board_init.c (Results 1 – 15 of 15)
Revision Date Author Comments
# 034db995 27-Sep-2020 Joseph Chen <chenjh@rock-chips.com>

dm: serial: support always use uart debug mode

In this mode, uart debug is initialized depends on
configuration from pre-loader or CONFIG_UART_DEBUG_.

The serial is not care about dts "stdout-path"

dm: serial: support always use uart debug mode

In this mode, uart debug is initialized depends on
configuration from pre-loader or CONFIG_UART_DEBUG_.

The serial is not care about dts "stdout-path" and
not register into console framework any more. It's
nice to use pre-loader serial and make serial easy
to configure.

Signed-off-by: Joseph Chen <chenjh@rock-chips.com>
Change-Id: If4c68229d76b6f1710a35e3ef9a2a91cb306fa9c

show more ...


# 064eb493 09-Oct-2018 Joseph Chen <chenjh@rock-chips.com>

serial: ns16550: support using pre-loader serial

- pass pre-loader serial configure by rk atags;
- it depends on serial aliases to find uart port;
- enabled by CONFIG_ROCKCHIP_USING_PRELOADER_SERIAL

serial: ns16550: support using pre-loader serial

- pass pre-loader serial configure by rk atags;
- it depends on serial aliases to find uart port;
- enabled by CONFIG_ROCKCHIP_USING_PRELOADER_SERIAL;

Change-Id: I6723cccc5e1f3dac77203b4cc19cdac631f5133b
Signed-off-by: Joseph Chen <chenjh@rock-chips.com>

show more ...


# 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 ...


# 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 ...


# 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


# 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 ...