See doc/arch/sandbox/sandbox.rst for more details.
-
-Board Initialisation Flow:
---------------------------
-
-This is the intended start-up flow for boards. This should apply for both
-SPL and U-Boot proper (i.e. they both follow the same rules).
-
-Note: "SPL" stands for "Secondary Program Loader," which is explained in
-more detail later in this file.
-
-At present, SPL mostly uses a separate code path, but the function names
-and roles of each function are the same. Some boards or architectures
-may not conform to this. At least most ARM boards which use
-CONFIG_SPL_FRAMEWORK conform to this.
-
-Execution typically starts with an architecture-specific (and possibly
-CPU-specific) start.S file, such as:
-
- - arch/arm/cpu/armv7/start.S
- - arch/powerpc/cpu/mpc83xx/start.S
- - arch/mips/cpu/start.S
-
-and so on. From there, three functions are called; the purpose and
-limitations of each of these functions are described below.
-
-lowlevel_init():
- - purpose: essential init to permit execution to reach board_init_f()
- - no global_data or BSS
- - there is no stack (ARMv7 may have one but it will soon be removed)
- - must not set up SDRAM or use console
- - must only do the bare minimum to allow execution to continue to
- board_init_f()
- - this is almost never needed
- - return normally from this function
-
-board_init_f():
- - purpose: set up the machine ready for running board_init_r():
- i.e. SDRAM and serial UART
- - global_data is available
- - stack is in SRAM
- - BSS is not available, so you cannot use global/static variables,
- only stack variables and global_data
-
- Non-SPL-specific notes:
- - dram_init() is called to set up DRAM. If already done in SPL this
- can do nothing
-
- SPL-specific notes:
- - you can override the entire board_init_f() function with your own
- version as needed.
- - preloader_console_init() can be called here in extremis
- - should set up SDRAM, and anything needed to make the UART work
- - there is no need to clear BSS, it will be done by crt0.S
- - for specific scenarios on certain architectures an early BSS *can*
- be made available (via CONFIG_SPL_EARLY_BSS by moving the clearing
- of BSS prior to entering board_init_f()) but doing so is discouraged.
- Instead it is strongly recommended to architect any code changes
- or additions such to not depend on the availability of BSS during
- board_init_f() as indicated in other sections of this README to
- maintain compatibility and consistency across the entire code base.
- - must return normally from this function (don't call board_init_r()
- directly)
-
-Here the BSS is cleared. For SPL, if CONFIG_SPL_STACK_R is defined, then at
-this point the stack and global_data are relocated to below
-CONFIG_SPL_STACK_R_ADDR. For non-SPL, U-Boot is relocated to run at the top of
-memory.
-
-board_init_r():
- - purpose: main execution, common code
- - global_data is available
- - SDRAM is available
- - BSS is available, all static/global variables can be used
- - execution eventually continues to main_loop()
-
- Non-SPL-specific notes:
- - U-Boot is relocated to the top of memory and is now running from
- there.
-
- SPL-specific notes:
- - stack is optionally in SDRAM, if CONFIG_SPL_STACK_R is defined and
- CONFIG_SYS_FSL_HAS_CCI400
-
- Defined For SoC that has cache coherent interconnect
- CCN-400
-
- CONFIG_SYS_FSL_HAS_CCN504
-
- Defined for SoC that has cache coherent interconnect CCN-504
-
The following options need to be configured:
- CPU Type: Define exactly one, e.g. CONFIG_MPC85XX.
CFG_SYS_NUM_I2C_BUSES
Hold the number of i2c buses you want to use.
- CFG_SYS_I2C_DIRECT_BUS
- define this, if you don't use i2c muxes on your hardware.
- if CFG_SYS_I2C_MAX_HOPS is not defined or == 0 you can
- omit this define.
-
- CFG_SYS_I2C_MAX_HOPS
- define how many muxes are maximal consecutively connected
- on one i2c bus. If you not use i2c muxes, omit this
- define.
-
CFG_SYS_I2C_BUSES
- hold a list of buses you want to use, only used if
- CFG_SYS_I2C_DIRECT_BUS is not defined, for example
- a board with CFG_SYS_I2C_MAX_HOPS = 1 and
- CFG_SYS_NUM_I2C_BUSES = 9:
+ hold a list of buses you want to use
CFG_SYS_I2C_BUSES {{0, {I2C_NULL_HOP}}, \
{0, {{I2C_MUX_PCA9547, 0x70, 1}}}, \
You should define these to the GPIO value as given directly to
the generic GPIO functions.
- CFG_I2C_MULTI_BUS
-
- This option allows the use of multiple I2C buses, each of which
- must have a controller. At any point in time, only one bus is
- active. To switch to a different bus, use the 'i2c dev' command.
- Note that bus numbering is zero-based.
-
CFG_SYS_I2C_NOPROBES
This option specifies a list of I2C devices that will be skipped
will skip addresses 0x50 and 0x68 on a board with one I2C bus
- CFG_SYS_RTC_BUS_NUM
-
- If defined, then this indicates the I2C bus number for the RTC.
- If not defined, then U-Boot assumes that RTC is on I2C bus 0.
-
CONFIG_SOFT_I2C_READ_REPEATED_START
defining this will force the i2c_read() function in
Configuration Settings:
-----------------------
-- MEM_SUPPORT_64BIT_DATA: Defined automatically if compiled as 64-bit.
- Optionally it can be defined to support 64-bit memory commands.
-
- CONFIG_SYS_LONGHELP: Defined when you want long help messages included;
undefine this when you're short of memory.
This only takes effect if the memory commands are activated
globally (CONFIG_CMD_MEMORY).
-- CONFIG_SPL_BUILD
+- CONFIG_XPL_BUILD
Set when the currently running compilation is for an artifact
that will end up in one of the 'xPL' builds, i.e. SPL, TPL or
VPL. Code that needs phase-specific behaviour can check this,
- or (where possible) use spl_phase() instead.
+ or (where possible) use xpl_phase() instead.
- Note that CONFIG_SPL_BUILD *is* always defined when either
+ Note that CONFIG_XPL_BUILD *is* always defined when either
of CONFIG_TPL_BUILD / CONFIG_VPL_BUILD is defined. This can be
counter-intuitive and should perhaps be changed.
Set when the currently running compilation is for an artifact
that will end up in the TPL build (as opposed to SPL, VPL or
U-Boot proper). Code that needs phase-specific behaviour can
- check this, or (where possible) use spl_phase() instead.
+ check this, or (where possible) use xpl_phase() instead.
- CONFIG_VPL_BUILD
Set when the currently running compilation is for an artifact
that will end up in the VPL build (as opposed to the SPL, TPL
or U-Boot proper). Code that needs phase-specific behaviour can
- check this, or (where possible) use spl_phase() instead.
+ check this, or (where possible) use xpl_phase() instead.
- CONFIG_ARCH_MAP_SYSMEM
Generally U-Boot (and in particular the md command) uses
- "u-boot" is an image in ELF binary format
- "u-boot.srec" is in Motorola S-Record format
-By default the build is performed locally and the objects are saved
-in the source directory. One of the two methods can be used to change
-this behavior and build U-Boot to some external directory:
-
-1. Add O= to the make command line invocations:
-
- make O=/tmp/build distclean
- make O=/tmp/build NAME_defconfig
- make O=/tmp/build all
-
-2. Set environment variable KBUILD_OUTPUT to point to the desired location:
-
- export KBUILD_OUTPUT=/tmp/build
- make distclean
- make NAME_defconfig
- make all
-
-Note that the command line "O=" setting overrides the KBUILD_OUTPUT environment
-variable.
-
User specific CPPFLAGS, AFLAGS and CFLAGS can be passed to the compiler by
setting the according environment variables KCPPFLAGS, KAFLAGS and KCFLAGS.
For example to treat all compiler warnings as errors:
==> U-Boot will use gp to hold a pointer to the global data
-Memory Management:
-------------------
-
-U-Boot runs in system state and uses physical addresses, i.e. the
-MMU is not used either for address mapping nor for memory protection.
-
-The available memory is mapped to fixed addresses using the memory
-controller. In this process, a contiguous block is formed for each
-memory type (Flash, SDRAM, SRAM), even when it consists of several
-physical memory banks.
-
-U-Boot is installed in the first 128 kB of the first Flash bank (on
-TQM8xxL modules this is the range 0x40000000 ... 0x4001FFFF). After
-booting and sizing and initializing DRAM, the code relocates itself
-to the upper end of DRAM. Immediately below the U-Boot code some
-memory is reserved for use by malloc() [see CONFIG_SYS_MALLOC_LEN
-configuration setting]. Below that, a structure with global Board
-Info data is placed, followed by the stack (growing downward).
-
-Additionally, some exception handler code is copied to the low 8 kB
-of DRAM (0x00000000 ... 0x00001FFF).
-
-So a typical memory configuration with 16 MB of DRAM could look like
-this:
-
- 0x0000 0000 Exception Vector code
- :
- 0x0000 1FFF
- 0x0000 2000 Free for Application Use
- :
- :
-
- :
- :
- 0x00FB FF20 Monitor Stack (Growing downward)
- 0x00FB FFAC Board Info Data and permanent copy of global data
- 0x00FC 0000 Malloc Arena
- :
- 0x00FD FFFF
- 0x00FE 0000 RAM Copy of Monitor Code
- ... eventually: LCD or video framebuffer
- ... eventually: pRAM (Protected RAM - unchanged by reset)
- 0x00FF FFFF [End of RAM]
-
-
System Initialization:
----------------------
projects / J-u-boot.git / blobdiff