1Overview of SPL on OMAP3 devices 2================================ 3 4Introduction 5------------ 6 7This document provides an overview of how SPL functions on OMAP3 (and related 8such as am35x and am37x) processors. 9 10Methodology 11----------- 12 13On these platforms the ROM supports trying a sequence of boot devices. Once 14one has been used successfully to load SPL this information is stored in memory 15and the location stored in a register. We will read this to determine where to 16read U-Boot from in turn. 17 18Memory Map 19---------- 20 21This is an example of a typical setup. See top-level README for documentation 22of which CONFIG variables control these values. For a given board and the 23amount of DRAM available to it different values may need to be used. 24Note that the size of the SPL text rodata and data is enforced with a CONFIG 25option and growing over that size results in a link error. The SPL stack 26starts at the top of SRAM (which is configurable) and grows downward. The 27space between the top of SRAM and the enforced upper bound on the size of the 28SPL text, data and rodata is considered the safe stack area. Details on 29confirming this behavior are shown below. 30 31A portion of the system memory map looks as follows: 32SRAM: 0x40200000 - 0x4020FFFF 33DDR1: 0x80000000 - 0xBFFFFFFF 34 35Option 1 (SPL only): 360x40200800 - 0x4020BBFF: Area for SPL text, data and rodata 370x4020E000 - 0x4020FFFC: Area for the SPL stack. 380x80000000 - 0x8007FFFF: Area for the SPL BSS. 390x80100000: CONFIG_SYS_TEXT_BASE of U-Boot 400x80208000 - 0x80307FFF: malloc() pool available to SPL. 41 42Option 2 (SPL or X-Loader): 430x40200800 - 0x4020BBFF: Area for SPL text, data and rodata 440x4020E000 - 0x4020FFFC: Area for the SPL stack. 450x80008000: CONFIG_SYS_TEXT_BASE of U-Boot 460x87000000 - 0x8707FFFF: Area for the SPL BSS. 470x87080000 - 0x870FFFFF: malloc() pool available to SPL. 48 49For the areas that reside within DDR1 they must not be used prior to s_init() 50completing. Note that CONFIG_SYS_TEXT_BASE must be clear of the areas that SPL 51uses while running. This is why we have two versions of the memory map that 52only vary in where the BSS and malloc pool reside. 53 54Estimating stack usage 55---------------------- 56 57With gcc 4.6 (and later) and the use of GNU cflow it is possible to estimate 58stack usage at various points in run sequence of SPL. The -fstack-usage option 59to gcc will produce '.su' files (such as arch/arm/cpu/armv7/syslib.su) that 60will give stack usage information and cflow can construct program flow. 61 62Must have gcc 4.6 or later, which supports -fstack-usage 63 641) Build normally 652) Perform the following shell command to generate a list of C files used in 66SPL: 67$ find spl -name '*.su' | sed -e 's:^spl/::' -e 's:[.]su$:.c:' > used-spl.list 683) Execute cflow: 69$ cflow --main=board_init_r `cat used-spl.list` 2>&1 | $PAGER 70 71cflow will spit out a number of warnings as it does not parse 72the config files and picks functions based on #ifdef. Parsing the '.i' 73files instead introduces another set of headaches. These warnings are 74not usually important to understanding the flow, however. 75