Versioning:
===========
-U-Boot uses a 3 level version number containing a version, a
-sub-version, and a patchlevel: "U-Boot-2.34.5" means version "2",
-sub-version "34", and patchlevel "4".
+Starting with the release in October 2008, the names of the releases
+were changed from numerical release numbers without deeper meaning
+into a time stamp based numbering. Regular releases are identified by
+names consisting of the calendar year and month of the release date.
+Additional fields (if present) indicate release candidates or bug fix
+releases in "stable" maintenance trees.
-The patchlevel is used to indicate certain stages of development
-between released versions, i. e. officially released versions of
-U-Boot will always have a patchlevel of "0".
+Examples:
+ U-Boot v2009.11 - Release November 2009
+ U-Boot v2009.11.1 - Release 1 in version November 2009 stable tree
+ U-Boot v2010.09-rc1 - Release candiate 1 for September 2010 release
Directory Hierarchy:
/cpu CPU specific files
/arm720t Files specific to ARM 720 CPUs
/arm920t Files specific to ARM 920 CPUs
- /at91rm9200 Files specific to Atmel AT91RM9200 CPU
- /imx Files specific to Freescale MC9328 i.MX CPUs
- /s3c24x0 Files specific to Samsung S3C24X0 CPUs
+ /at91rm9200 Files specific to Atmel AT91RM9200 CPU
+ /imx Files specific to Freescale MC9328 i.MX CPUs
+ /s3c24x0 Files specific to Samsung S3C24X0 CPUs
/arm925t Files specific to ARM 925 CPUs
/arm926ejs Files specific to ARM 926 CPUs
/arm1136 Files specific to ARM 1136 CPUs
/mips Files generic to MIPS architecture
/cpu CPU specific files
/lib Architecture specific library files
- /nios Files generic to Altera NIOS architecture
- /cpu CPU specific files
- /lib Architecture specific library files
/nios2 Files generic to Altera NIOS2 architecture
/cpu CPU specific files
/lib Architecture specific library files
must be defined, to setup the maximum idle timeout for
the SMC.
-- Interrupt driven serial port input:
- CONFIG_SERIAL_SOFTWARE_FIFO
-
- PPC405GP only.
- Use an interrupt handler for receiving data on the
- serial port. It also enables using hardware handshake
- (RTS/CTS) and UART's built-in FIFO. Set the number of
- bytes the interrupt driven input buffer should have.
-
- Leave undefined to disable this feature, including
- disable the buffer and hardware handshake.
-
-- Console UART Number:
- CONFIG_UART1_CONSOLE
-
- AMCC PPC4xx only.
- If defined internal UART1 (and not UART0) is used
- as default U-Boot console.
-
- Boot Delay: CONFIG_BOOTDELAY - in seconds
Delay before automatically booting the default image;
set to -1 to disable autoboot.
#define I2C_DELAY udelay(2)
+ CONFIG_SOFT_I2C_GPIO_SCL / CONFIG_SOFT_I2C_GPIO_SDA
+
+ If your arch supports the generic GPIO framework (asm/gpio.h),
+ then you may alternatively define the two GPIOs that are to be
+ used as SCL / SDA. Any of the previous I2C_xxx macros will
+ have GPIO-based defaults assigned to them as appropriate.
+
+ You should define these to the GPIO value as given directly to
+ the generic GPIO functions.
+
CONFIG_SYS_I2C_INIT_BOARD
When a board is reset during an i2c bus transfer
ETX094, IVMS8, IVML24, SPD8xx, TQM8xxL,
HERMES, IP860, RPXlite, LWMON, LANTEC,
- PCU_E, FLAGADM, TQM8260
+ FLAGADM, TQM8260
- Error Recovery:
CONFIG_PANIC_HANG
- CONFIG_SYS_MONITOR_BASE:
Physical start address of boot monitor code (set by
make config files to be same as the text base address
- (TEXT_BASE) used when linking) - same as
+ (CONFIG_SYS_TEXT_BASE) used when linking) - same as
CONFIG_SYS_FLASH_BASE when booting from flash.
- CONFIG_SYS_MONITOR_LEN:
all data for the Linux kernel must be between "bootm_low"
and "bootm_low" + CONFIG_SYS_BOOTMAPSZ.
+- CONFIG_SYS_BOOT_RAMDISK_HIGH:
+ Enable initrd_high functionality. If defined then the
+ initrd_high feature is enabled and the bootm ramdisk subcommand
+ is enabled.
+
+- CONFIG_SYS_BOOT_GET_CMDLINE:
+ Enables allocating and saving kernel cmdline in space between
+ "bootm_low" and "bootm_low" + BOOTMAPSZ.
+
+- CONFIG_SYS_BOOT_GET_KBD:
+ Enables allocating and saving a kernel copy of the bd_info in
+ space between "bootm_low" and "bootm_low" + BOOTMAPSZ.
+
- CONFIG_SYS_MAX_FLASH_BANKS:
Max number of Flash memory banks
on high Ethernet traffic.
Defaults to 4 if not defined.
+- CONFIG_ENV_MAX_ENTRIES
+
+ Maximum number of entries in the hash table that is used
+ internally to store the environment settings. The default
+ setting is supposed to be generous and should work in most
+ cases. This setting can be used to tune behaviour; see
+ lib/hashtable.c for details.
+
The following definitions that deal with the placement and management
of environment data (variable area); in general, we support the
following configurations:
I2C muxes, you can define here, how to reach this
EEPROM. For example:
- #define CONFIG_I2C_ENV_EEPROM_BUS "pca9547:70:d\0"
+ #define CONFIG_I2C_ENV_EEPROM_BUS "pca9547:70:d\0"
EEPROM which holds the environment, is reached over
a pca9547 i2c mux with address 0x70, channel 3.
- CONFIG_ENV_SIZE:
These two #defines specify the offset and size of the environment
- area within the first NAND device.
+ area within the first NAND device. CONFIG_ENV_OFFSET must be
+ aligned to an erase block boundary.
- - CONFIG_ENV_OFFSET_REDUND
+ - CONFIG_ENV_OFFSET_REDUND (optional):
This setting describes a second storage area of CONFIG_ENV_SIZE
- size used to hold a redundant copy of the environment data,
- so that there is a valid backup copy in case there is a
- power failure during a "saveenv" operation.
+ size used to hold a redundant copy of the environment data, so
+ that there is a valid backup copy in case there is a power failure
+ during a "saveenv" operation. CONFIG_ENV_OFFSET_RENDUND must be
+ aligned to an erase block boundary.
+
+ - CONFIG_ENV_RANGE (optional):
+
+ Specifies the length of the region in which the environment
+ can be written. This should be a multiple of the NAND device's
+ block size. Specifying a range with more erase blocks than
+ are needed to hold CONFIG_ENV_SIZE allows bad blocks within
+ the range to be avoided.
- Note: CONFIG_ENV_OFFSET and CONFIG_ENV_OFFSET_REDUND must be aligned
- to a block boundary, and CONFIG_ENV_SIZE must be a multiple of
- the NAND devices block size.
+ - CONFIG_ENV_OFFSET_OOB (optional):
+
+ Enables support for dynamically retrieving the offset of the
+ environment from block zero's out-of-band data. The
+ "nand env.oob" command can be used to record this offset.
+ Currently, CONFIG_ENV_OFFSET_REDUND is not supported when
+ using CONFIG_ENV_OFFSET_OOB.
- CONFIG_NAND_ENV_DST
Please note that the environment is read-only until the monitor
has been relocated to RAM and a RAM copy of the environment has been
-created; also, when using EEPROM you will have to use getenv_r()
+created; also, when using EEPROM you will have to use getenv_f()
until then to read environment variables.
The environment is protected by a CRC32 checksum. Before the monitor
area defined by CONFIG_SYS_INIT_RAM_ADDR. Usually
CONFIG_SYS_GBL_DATA_OFFSET is chosen such that the initial
data is located at the end of the available space
- (sometimes written as (CONFIG_SYS_INIT_RAM_END -
+ (sometimes written as (CONFIG_SYS_INIT_RAM_SIZE -
CONFIG_SYS_INIT_DATA_SIZE), and the initial stack is just
below that area (growing from (CONFIG_SYS_INIT_RAM_ADDR +
CONFIG_SYS_GBL_DATA_OFFSET) downward.
globally (CONFIG_CMD_MEM).
- CONFIG_SKIP_LOWLEVEL_INIT
-- CONFIG_SKIP_RELOCATE_UBOOT
+ [ARM only] If this variable is defined, then certain
+ low level initializations (like setting up the memory
+ controller) are omitted and/or U-Boot does not
+ relocate itself into RAM.
- [ARM only] If these variables are defined, then
- certain low level initializations (like setting up
- the memory controller) are omitted and/or U-Boot does
- not relocate itself into RAM.
- Normally these variables MUST NOT be defined. The
- only exception is when U-Boot is loaded (to RAM) by
- some other boot loader or by a debugger which
- performs these initializations itself.
+ Normally this variable MUST NOT be defined. The only
+ exception is when U-Boot is loaded (to RAM) by some
+ other boot loader or by a debugger which performs
+ these initializations itself.
- CONFIG_PRELOADER
-
Modifies the behaviour of start.S when compiling a loader
that is executed before the actual U-Boot. E.g. when
compiling a NAND SPL.
interface is currently active. For example you
can do the following
- => setenv ethact FEC ETHERNET
- => ping 192.168.0.1 # traffic sent on FEC ETHERNET
- => setenv ethact SCC ETHERNET
- => ping 10.0.0.1 # traffic sent on SCC ETHERNET
+ => setenv ethact FEC
+ => ping 192.168.0.1 # traffic sent on FEC
+ => setenv ethact SCC
+ => ping 10.0.0.1 # traffic sent on SCC
ethrotate - When set to "no" U-Boot does not go through all
available network interfaces.
Currently supported: Linux, NetBSD, VxWorks, QNX, RTEMS, LynxOS,
INTEGRITY).
* Target CPU Architecture (Provisions for Alpha, ARM, AVR32, Intel x86,
- IA64, MIPS, NIOS, PowerPC, IBM S390, SuperH, Sparc, Sparc 64 Bit;
- Currently supported: ARM, AVR32, Intel x86, MIPS, NIOS, PowerPC).
+ IA64, MIPS, Nios II, PowerPC, IBM S390, SuperH, Sparc, Sparc 64 Bit;
+ Currently supported: ARM, AVR32, Intel x86, MIPS, Nios II, PowerPC).
* Compression Type (uncompressed, gzip, bzip2)
* Load Address
* Entry Point
==> U-Boot will use R8 to hold a pointer to the global data
+On Nios II, the ABI is documented here:
+ http://www.altera.com/literature/hb/nios2/n2cpu_nii51016.pdf
+
+ ==> U-Boot will use gp to hold a pointer to the global data
+
+ Note: on Nios II, we give "-G0" option to gcc and don't use gp
+ to access small data sections, so gp is free.
+
NOTE: DECLARE_GLOBAL_DATA_PTR must be used with file-global scope,
or current versions of GCC may "optimize" the code too much.
projects / karo-tx-uboot.git / blobdiff