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

arm: crt0: don't relocate vector if CONFIG_SKIP_RELOCATE_UBOOT is enabled

This patch fixes interrupt issue when uboot disable relocation.

fixes: 645a442d90864589c105abad1f8e582f59724d08
(common: su

arm: crt0: don't relocate vector if CONFIG_SKIP_RELOCATE_UBOOT is enabled

This patch fixes interrupt issue when uboot disable relocation.

fixes: 645a442d90864589c105abad1f8e582f59724d08
(common: support skip U-Boot relocation)

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

show more ...

common: support skip U-Boot relocation

Change-Id: I8640907204c82928c2fb07177835dc55a126aaf0
Signed-off-by: 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 ...

config: Add CONFIG_TINY_TPL to disable SPL framework at TPL

Some devices cann't use SPL framework at TPL stage, but the
CONFIG_SPL_FRAMEWORK is still defined at TPL stage, so need
to separate them w

config: Add CONFIG_TINY_TPL to disable SPL framework at TPL

Some devices cann't use SPL framework at TPL stage, but the
CONFIG_SPL_FRAMEWORK is still defined at TPL stage, so need
to separate them with CONFIG_TINY_TPL.

If the SPL framewrok was used both at TPL and SPL stage,
CONFIG_TINY_TPL is not defined.
If the SPL framewrok was used at SPL stage, but not use at
TPL, need to define CONFIG_TINY_TPL.

Change-Id: Iabb7e0377ee00311ca468cb8ff7544c96bd999d6
Signed-off-by: David Wu <david.wu@rock-chips.com>

show more ...

arm: add a separate stack for TPL

TPL stack may different from SPL and sys stack, add support for
separate one when the board defines it.

Change-Id: I4e962e2e3a2c983892dd41397b2ac0622e3c3dc7
Signed

arm: add a separate stack for TPL

TPL stack may different from SPL and sys stack, add support for
separate one when the board defines it.

Change-Id: I4e962e2e3a2c983892dd41397b2ac0622e3c3dc7
Signed-off-by: Kever Yang <kever.yang@rock-chips.com>

show more ...

arm: Migrate SYS_THUMB_BUILD to Kconfig, introduce SPL_SYS_THUMB_BUILD

Today, we have cases where we wish to build all of U-Boot in Thumb2 mode for
various reasons. We also have cases where we only

arm: Migrate SYS_THUMB_BUILD to Kconfig, introduce SPL_SYS_THUMB_BUILD

Today, we have cases where we wish to build all of U-Boot in Thumb2 mode for
various reasons. We also have cases where we only build SPL in Thumb2 mode due
to size constraints and wish to build the rest of the system in ARM mode. So
in this migration we introduce a new symbol as well, SPL_SYS_THUMB_BUILD to
control if we build everything or just SPL (or in theory, just U-Boot) in
Thumb2 mode.

Signed-off-by: Tom Rini <trini@konsulko.com>
Acked-by: Siarhei Siamashka <siarhei.siamashka@gmail.com>

show more ...

arm: use common instructions applicable to armv7m & other arm archs

This patch cleans the code by using instructions allowed for armv7m as well as
other Arm archs.

Signed-off-by: Vikas Manocha <vik

arm: use common instructions applicable to armv7m & other arm archs

This patch cleans the code by using instructions allowed for armv7m as well as
other Arm archs.

Signed-off-by: Vikas Manocha <vikas.manocha@st.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Heiko Schocher <hs@denx.de>

show more ...

arm: make sure board_init_r() is being called using the right mode (ARM / THUMB)

Signed-off-by: David Müller <d.mueller@elsoft.ch>

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

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

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

arm: Switch 32-bit ARM to using generic global_data setup

There is quite a bit of assembler code that can be removed if we use the
generic global_data setup. Less arch-specific code makes it easier

arm: Switch 32-bit ARM to using generic global_data setup

There is quite a bit of assembler code that can be removed if we use the
generic global_data setup. Less arch-specific code makes it easier to add
new features and maintain the start-up code.

Drop the unneeded code and adjust the hooks in board_f.c to cope.

Signed-off-by: Simon Glass <sjg@chromium.org>

show more ...

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

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

arm: Correct comments in crt0.S for the recent SPL improvements

The current comments need a bit of tweaking since we now support stack
and global_data relocation in SPL. Also add a reference to the

arm: Correct comments in crt0.S for the recent SPL improvements

The current comments need a bit of tweaking since we now support stack
and global_data relocation in SPL. Also add a reference to the README.

For AArch64 this is not implemented, so leave a TODO for this.

Signed-off-by: Simon Glass <sjg@chromium.org>
Reported-by: Tim Harvey <tharvey@gateworks.com>

show more ...

Merge branch 'u-boot/master' into 'u-boot-arm/master'

ARM: Add ARMv7-M support

Signed-off-by: Kamil Lulko <rev13@wp.pl>

arm: relocation: clear .bss section with arch memset if defined

For ARM architecture, enable the CONFIG_USE_ARCH_MEMSET/MEMCPY,
will highly increase the memset/memcpy performance. This is able
thank

arm: relocation: clear .bss section with arch memset if defined

For ARM architecture, enable the CONFIG_USE_ARCH_MEMSET/MEMCPY,
will highly increase the memset/memcpy performance. This is able
thanks to the ARM multiple register instructions.

Unfortunatelly the relocation is done without the cache enabled,
so it takes some time, but zeroing the BSS memory takes much more
longer, especially for the configs with big static buffers.

A quick test confirms, that the boot time improvement after using
the arch memcpy for relocation has no significant meaning.
The same test confirms that enable the memset for zeroing BSS,
reduces the boot time.

So this patch enables the arch memset for zeroing the BSS after
the relocation process. For ARM boards, this can be enabled
in board configs by defining: 'CONFIG_USE_ARCH_MEMSET'.

This was tested on Trats2.
A quick test with trace. Boot time from start to main_loop() entry:
- ~1384ms - before this change
- ~888ms - after this change

Signed-off-by: Przemyslaw Marczak <p.marczak@samsung.com>
Reviewed-by: Simon Glass <sjg@chromium.org>
Cc: Albert Aribaud <albert.u.boot@aribaud.net>
Cc: Tom Rini <trini@konsulko.com>

show more ...

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

arm: spl: Allow board_init_r() to run with a larger stack

At present SPL uses a single stack, either CONFIG_SPL_STACK or
CONFIG_SYS_INIT_SP_ADDR. Since some SPL features (such as MMC and
environment

arm: spl: Allow board_init_r() to run with a larger stack

At present SPL uses a single stack, either CONFIG_SPL_STACK or
CONFIG_SYS_INIT_SP_ADDR. Since some SPL features (such as MMC and
environment) require a lot of stack, some boards set CONFIG_SPL_STACK to
point into SDRAM. They then set up SDRAM very early, before board_init_f(),
so that the larger stack can be used.

This is an abuse of lowlevel_init(). That function should only be used for
essential start-up code which cannot be delayed. An example of a valid use is
when only part of the SPL code is visible/executable, and the SoC must be set
up so that board_init_f() can be reached. It should not be used for SDRAM
init, console init, etc.

Add a CONFIG_SPL_STACK_R option, which allows the stack to be moved to a new
address before board_init_r() is called in SPL.

The expected SPL flow (for CONFIG_SPL_FRAMEWORK) is documented in the README.

Signed-off-by: Simon Glass <sjg@chromium.org>
For version 1:
Acked-by: Albert ARIBAUD <albert.u.boot@aribaud.net>
Reviewed-by: Stefan Roese <sr@denx.de>
Tested-by: Bo Shen <voice.shen@atmel.com>
Acked-by: Bo Shen <voice.shen@atmel.com>
Acked-by: Heiko Schocher <hs@denx.de>
Tested-by: Heiko Schocher <hs@denx.de>

Signed-off-by: Tom Rini <trini@konsulko.com>

show more ...

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

Merge git://git.denx.de/u-boot-dm

Conflicts:
drivers/serial/serial-uclass.c

Signed-off-by: Tom Rini <trini@ti.com>

dm: arm: spl: Allow simple malloc() in SPL

For SPL it is sometimes useful to have a simple malloc() just to permit
driver model to work, in the cases where the full malloc() is not made
available by

dm: arm: spl: Allow simple malloc() in SPL

For SPL it is sometimes useful to have a simple malloc() just to permit
driver model to work, in the cases where the full malloc() is not made
available by the board config.

Signed-off-by: Simon Glass <sjg@chromium.org>

show more ...

imx: fix exception vectors relocation in imx27

Commit 3ff46cc4 fixed exception vectors setting in
the general ARM case, by either copying the exception
and indirect vector tables to normal (0x000000

imx: fix exception vectors relocation in imx27

Commit 3ff46cc4 fixed exception vectors setting in
the general ARM case, by either copying the exception
and indirect vector tables to normal (0x00000000) or
high (0xFFFF0000) vectors address, or setting VBAR to
U-Boot's base if applicable.

i.MX27 SoC is ARM926E-JS, thus has only normal and
high options, but does not provide RAM at 0xFFFF0000
and has only ROM at 0x00000000; it is therefore not
possible to move or change its exception vectors.

Besides, i.MX27 ROM code does provide an indirect
vectors table but at a non-standard address and with
the reset and reserved vectors missing.

Turn the current vector relocation code into a weak
routine called after relocate_code from crt0, and add
strong version for i.MX27.

Series-Cc: Heiko Schocher <hs@denx.de>

Signed-off-by: Albert ARIBAUD <albert.u.boot@aribaud.net>
Reviewed-by: Stefano Babic <sbabic@denx.de>
Tested-by: Stefano Babic <sbabic@denx.de>
Tested-by: Philippe Reynes <tremyfr@gmail.com>
Tested-by: Philippe Reynes <tremyfr@yahoo.fr>

show more ...