Driver model currently only operates after relocation is complete. In this
state U-Boot typically has a small amount of memory available. In adding
support for driver model prior to relocation we must try to use as little
memory as possible.
In addition, on some machines the memory has not be inited and/or the CPU
is not running at full speed or the data cache is off. These can reduce
execution performance, so the less initialisation that is done before
relocation the better.
An immediately-obvious improvement is to only initialise drivers which are
actually going to be used before relocation. On many boards the only such
driver is a serial UART, so this provides a very large potential benefit.
Allow drivers to mark themselves as 'pre-reloc' which means that they will
be initialised prior to relocation. This can be done either with a driver
flag or with a 'dm,pre-reloc' device tree property.
To support this, the various dm scanning function now take a 'pre_reloc_only'
parameter which indicates that only drivers marked pre-reloc should be
bound.
Signed-off-by: Simon Glass <sjg@chromium.org>
If we are to have driver model before relocation we need to support some
way of calling memory allocation routines.
The standard malloc() is pretty complicated:
1. It uses some BSS memory for its state, and BSS is not available before
relocation
2. It supports algorithms for reducing memory fragmentation and improving
performace of free(). Before relocation we could happily just not support
free().
3. It includes about 4KB of code (Thumb 2) and 1KB of data. However since
this has been loaded anyway this is not really a problem.
The simplest way to support pre-relocation malloc() is to reserve an area
of memory and allocate it in increasing blocks as needed. This
implementation does this.
To enable it, you need to define the size of the malloc() pool as described
in the README. It will be located above the pre-relocation stack on
supported architectures.
Note that this implementation is only useful on machines which have some
memory available before dram_init() is called - this includes those that
do no DRAM init (like tegra) and those that do it in SPL (quite a few
boards). Enabling driver model preior to relocation for the rest of the
boards is left for a later exercise.
Signed-off-by: Simon Glass <sjg@chromium.org>
This has been disabled for ARM in initr_scsi since that function was
introduced. However it works fine for me on Cubieboard and Cubietruck (with the
upcoming AHCI glue patch).
I also tested on two random ARM platforms which seem to define CONFIG_CMD_SCSI:
- highbank worked fine (on midway hardware)
- omap5_uevm built OK and I confirmed using objdump that things were as
expected (i.e. the default weak scsi_init nop was used).
While there remove the mismatched comment from the #endif (omitting the comment
seems to be the prevailing style in this file).
Signed-off-by: Ian Campbell <ijc@hellion.org.uk>
Acked-by: Simon Glass <sjg@chromium.org>
This code seems unnecessarily complex. We really just need to check the
global_data. Now that is it all in one place, and not arch-specific, this
is pretty easy.
Signed-off-by: Simon Glass <sjg@chromium.org>
The show_model_r function should return an int but didn't. Return 0 to
indicate inevitable success and avoid the following if it is used:
common/board_r.c: In function 'show_model_r':
common/board_r.c:531:1: warning: no return statement in function returning non-void [-Wreturn-type]
}
^
Cc: Simon Glass <sjg@chromium.org>
Signed-off-by: Paul Burton <paul.burton@imgtec.com>
Acked-by: Simon Glass <sjg@chromium.org>
Make driver model available after relocation, by setting up data structures
and scanning for devices using compiled-in platform_data and (when available)
the device tree.
Signed-off-by: Simon Glass <sjg@chromium.org>
Remove the last uses of symbol offsets in ARM U-Boot.
Remove some needless uses of _TEXT_BASE.
Remove all _TEXT_BASE definitions.
Signed-off-by: Albert ARIBAUD <albert.u.boot@aribaud.net>
This is only required for "PIC" relocation and doesn't apply to modern
"PIE" relocation which does data relocation as well as code.
"init_sequence_r" is just an array that consists of compile-time
adresses of init functions. Since this is basically an array of integers
(pointers to "void" to be more precise) it won't be modified during
relocation - it will be just copied to new location as it is.
As a consequence on execution after relocation "initcall_run_list" will
be jumping to pre-relocation addresses. As long as we don't overwrite
pre-relocation memory area init calls are executed correctly. But still
it is dangerous because after relocation we don't expect initially used
memory to stay untouched.
Cc: Tom Rini <trini@ti.com>
Cc: Masahiro Yamada <yamada.m@jp.panasonic.com>
Cc: Doug Anderson <dianders@chromium.org>
Cc: Thomas Langer <thomas.langer@lantiq.com>
Cc: Albert ARIBAUD <albert.u.boot@aribaud.net>
Acked-by: Simon Glass <sjg@chromium.org>
Signed-off-by: Alexey Brodkin <abrodkin@synopsys.com>
Add hooks for tracing to generic board, including:
- allow early tracing to start early as possible in U-Boot
- reserve memory for trace buffer
- copy early trace buffer to main trace buffer after relocation
- setup full tracing support after relocation
Signed-off-by: Simon Glass <sjg@chromium.org>
This commit refactors common/board_f.c and common/board_r.c
in order to delete the dest_addr and dest_addr_sp from
gd_t struct.
As mentioned as follows in include/asm-generic/global_data.h,
/* TODO: is this the same as relocaddr, or something else? */
unsigned long dest_addr; /* Post-relocation address of U-Boot */
dest_addr is the same as relocaddr.
Likewise, dest_addr_sp is the same as start_addr_sp.
It seemed dest_addr/dest_addr_sp was used only as a scratch variable
to calculate relocaddr/start_addr_sp, respectively.
With a little refactoring, we can delete dest_addr and dest_addr_sp.
Signed-off-by: Masahiro Yamada <yamada.m@jp.panasonic.com>
Cc: Simon Glass <sjg@chromium.org>
In a previous CL we added the bootstage_relocate(), which should be
called after malloc is initted. Now we call it on generic board.
Signed-off-by: Doug Anderson <dianders@chromium.org>
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Simon Glass <sjg@chromium.org>
Add generic board support for sandbox. and remove the old board init code.
Select CONFIG_SYS_GENERIC_BOARD for sandbox now that this is supported.
Signed-off-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Tom Rini <trini@ti.com>
Currently x86 has its own means of managing the global data and board data
(bd_t), and this code resides in start.S. With generic board, we need to
ensure that we leave this alone - i.e. don't clear it as we do on other
archs.
This fixes a problem where the memory init data is cleared which causes
the video driver to operate very slowly.
Signed-off-by: Simon Glass <sjg@chromium.org>
For x86 the global_data is managed entirely by the start.S code so we do
not need to touch it. However, we do have some more initcalls to add.
Signed-off-by: Simon Glass <sjg@chromium.org>
