/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
+ /at91 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
/lib Architecture specific library files
/mips Files generic to MIPS architecture
/cpu CPU specific files
+ /mips32 Files specific to MIPS32 CPUs
/lib Architecture specific library files
/nios2 Files generic to Altera NIOS2 architecture
/cpu CPU specific files
2. The core frequency as calculated above is multiplied
by this value.
+- MIPS CPU options:
+ CONFIG_SYS_INIT_SP_OFFSET
+
+ Offset relative to CONFIG_SYS_SDRAM_BASE for initial stack
+ pointer. This is needed for the temporary stack before
+ relocation.
+
+ CONFIG_SYS_MIPS_CACHE_MODE
+
+ Cache operation mode for the MIPS CPU.
+ See also arch/mips/include/asm/mipsregs.h.
+ Possible values are:
+ CONF_CM_CACHABLE_NO_WA
+ CONF_CM_CACHABLE_WA
+ CONF_CM_UNCACHED
+ CONF_CM_CACHABLE_NONCOHERENT
+ CONF_CM_CACHABLE_CE
+ CONF_CM_CACHABLE_COW
+ CONF_CM_CACHABLE_CUW
+ CONF_CM_CACHABLE_ACCELERATED
+
+ CONFIG_SYS_XWAY_EBU_BOOTCFG
+
+ Special option for Lantiq XWAY SoCs for booting from NOR flash.
+ See also arch/mips/cpu/mips32/start.S.
+
+ CONFIG_XWAY_SWAP_BYTES
+
+ Enable compilation of tools/xway-swap-bytes needed for Lantiq
+ XWAY SoCs for booting from NOR flash. The U-Boot image needs to
+ be swapped if a flash programmer is used.
+
- Linux Kernel Interface:
CONFIG_CLOCKS_IN_MHZ
=>
If you now switch to the new I2C Bus 3 with "i2c dev 3"
- u-boot sends First the Commando to the mux@70 to enable
- channel 6, and then the Commando to the mux@71 to enable
+ u-boot first sends the command to the mux@70 to enable
+ channel 6, and then the command to the mux@71 to enable
the channel 4.
After that, you can use the "normal" i2c commands as
- usual, to communicate with your I2C devices behind
+ usual to communicate with your I2C devices behind
the 2 muxes.
This option is actually implemented for the bitbanging
Adds the MTD partitioning infrastructure from the Linux
kernel. Needed for UBI support.
+- SPL framework
+ CONFIG_SPL
+ Enable building of SPL globally.
+
+ CONFIG_SPL_TEXT_BASE
+ TEXT_BASE for linking the SPL binary.
+
+ CONFIG_SPL_LDSCRIPT
+ LDSCRIPT for linking the SPL binary.
+
+ CONFIG_SPL_LIBCOMMON_SUPPORT
+ Support for common/libcommon.o in SPL binary
+
+ CONFIG_SPL_LIBDISK_SUPPORT
+ Support for disk/libdisk.o in SPL binary
+
+ CONFIG_SPL_I2C_SUPPORT
+ Support for drivers/i2c/libi2c.o in SPL binary
+
+ CONFIG_SPL_GPIO_SUPPORT
+ Support for drivers/gpio/libgpio.o in SPL binary
+
+ CONFIG_SPL_MMC_SUPPORT
+ Support for drivers/mmc/libmmc.o in SPL binary
+
+ CONFIG_SPL_SERIAL_SUPPORT
+ Support for drivers/serial/libserial.o in SPL binary
+
+ CONFIG_SPL_SPI_FLASH_SUPPORT
+ Support for drivers/mtd/spi/libspi_flash.o in SPL binary
+
+ CONFIG_SPL_SPI_SUPPORT
+ Support for drivers/spi/libspi.o in SPL binary
+
+ CONFIG_SPL_FAT_SUPPORT
+ Support for fs/fat/libfat.o in SPL binary
+
+ CONFIG_SPL_LIBGENERIC_SUPPORT
+ Support for lib/libgeneric.o in SPL binary
Modem Support:
--------------
of environment data (variable area); in general, we support the
following configurations:
+- CONFIG_BUILD_ENVCRC:
+
+ Builds up envcrc with the target environment so that external utils
+ may easily extract it and embed it in final U-Boot images.
+
- CONFIG_ENV_IS_IN_FLASH:
Define this if the environment is in flash memory.
globally (CONFIG_CMD_MEM).
- CONFIG_SKIP_LOWLEVEL_INIT
- [ARM only] If this variable is defined, then certain
+ [ARM, MIPS 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.
other boot loader or by a debugger which performs
these initializations itself.
-- CONFIG_PRELOADER
+- CONFIG_SPL_BUILD
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.
All contributions to U-Boot should conform to the Linux kernel
coding style; see the file "Documentation/CodingStyle" and the script
-"scripts/Lindent" in your Linux kernel source directory. In sources
-originating from U-Boot a style corresponding to "Lindent -pcs" (adding
-spaces before parameters to function calls) is actually used.
+"scripts/Lindent" in your Linux kernel source directory.
Source files originating from a different project (for example the
MTD subsystem) are generally exempt from these guidelines and are not
Please also stick to the following formatting rules:
- remove any trailing white space
-- use TAB characters for indentation, not spaces
+- use TAB characters for indentation and vertical alignment, not spaces
- make sure NOT to use DOS '\r\n' line feeds
-- do not add more than 2 empty lines to source files
+- do not add more than 2 consecutive empty lines to source files
- do not add trailing empty lines to source files
Submissions which do not conform to the standards may be returned
* For major contributions, your entry to the CREDITS file
* When you add support for a new board, don't forget to add this
- board to the MAKEALL script, too.
+ board to the MAINTAINERS file, too.
* If your patch adds new configuration options, don't forget to
document these in the README file.
* The patch itself. If you are using git (which is *strongly*
recommended) you can easily generate the patch using the
- "git-format-patch". If you then use "git-send-email" to send it to
+ "git format-patch". If you then use "git send-email" to send it to
the U-Boot mailing list, you will avoid most of the common problems
with some other mail clients.