mirrors/u-boot
0
0
Fork 0
mirror of https://github.com/u-boot/u-boot.git synced 2024-11-26 13:44:29 +08:00
Code Issues Packages Projects Releases Wiki Activity

SPL: Add README.omap3

Browse Source 
This document describes the SPL process for OMAP3 (and related) boards
as well as a partial memory map and how to verify certain aspects
outside of running on the target.

Signed-off-by: Tom Rini <trini@ti.com>
This commit is contained in:
Tom Rini 2012-02-20 13:27:43 +00:00 committed by Albert ARIBAUD
parent 95579793b1
commit 71e6840279
1 changed files with 74 additions and 0 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

74
doc/SPL/README.omap3 Normal file
View File

@ -0,0 +1,74 @@
Overview of SPL on OMAP3 devices
================================
Introduction
------------
This document provides an overview of how SPL functions on OMAP3 (and related
such as am35x and am37x) processors.
Methodology
-----------
On these platforms the ROM supports trying a sequence of boot devices. Once
one has been used successfully to load SPL this information is stored in memory
and the location stored in a register. We will read this to determine where to
read U-Boot from in turn.
Memory Map
----------
This is an example of a typical setup. See top-level README for documentation
of which CONFIG variables control these values. For a given board and the
amount of DRAM available to it different values may need to be used.
Note that the size of the SPL text rodata and data is enforced with a CONFIG
option and growing over that size results in a link error. The SPL stack
starts at the top of SRAM (which is configurable) and grows downward. The
space between the top of SRAM and the enforced upper bound on the size of the
SPL text, data and rodata is considered the safe stack area. Details on
confirming this behavior are shown below.
A portion of the system memory map looks as follows:
SRAM: 0x40200000 - 0x4020FFFF
DDR1: 0x80000000 - 0xBFFFFFFF
Option 1 (SPL only):
0x40200800 - 0x4020BBFF: Area for SPL text, data and rodata
0x4020BC00 - 0x4020FFFC: Area for the SPL stack.
0x80000000 - 0x8007FFFF: Area for the SPL BSS.
0x80100000: CONFIG_SYS_TEXT_BASE of U-Boot
0x80208000 - 0x80307FFF: malloc() pool available to SPL.
Option 2 (SPL or X-Loader):
0x40200800 - 0x4020BBFF: Area for SPL text, data and rodata
0x4020BC00 - 0x4020FFFC: Area for the SPL stack.
0x80008000: CONFIG_SYS_TEXT_BASE of U-Boot
0x87000000 - 0x8707FFFF: Area for the SPL BSS.
0x87080000 - 0x870FFFFF: malloc() pool available to SPL.
For the areas that reside within DDR1 they must not be used prior to s_init()
completing. Note that CONFIG_SYS_TEXT_BASE must be clear of the areas that SPL
uses while running. This is why we have two versions of the memory map that
only vary in where the BSS and malloc pool reside.
Estimating stack usage
----------------------
With gcc 4.6 (and later) and the use of GNU cflow it is possible to estimate
stack usage at various points in run sequence of SPL. The -fstack-usage option
to gcc will produce '.su' files (such as arch/arm/cpu/armv7/syslib.su) that
will give stack usage information and cflow can construct program flow.
Must have gcc 4.6 or later, which supports -fstack-usage
1) Build normally
2) Perform the following shell command to generate a list of C files used in
SPL:
$ find spl -name '*.su' | sed -e 's:^spl/::' -e 's:[.]su$:.c:' > used-spl.list
3) Execute cflow:
$ cflow --main=board_init_r `cat used-spl.list` 2>&1 | $PAGER
cflow will spit out a number of warnings as it does not parse
the config files and picks functions based on #ifdef. Parsing the '.i'
files instead introduces another set of headaches. These warnings are
not usually important to understanding the flow, however.