X-Git-Url: https://git.kernelconcepts.de/?a=blobdiff_plain;f=README;h=68f5fb09180ec39b4f87306a75e9902347e48cec;hb=b920ee9db254786ee909705d904ef509758afbdc;hp=cdd81d4efe3efafd8e8e3653303eec1af2e599f5;hpb=9d62f20d0861ef87460d073dc189c851715b46ae;p=karo-tx-uboot.git diff --git a/README b/README index cdd81d4efe..68f5fb0918 100644 --- a/README +++ b/README @@ -126,13 +126,17 @@ the string "u_boot" or on "U_BOOT". Example: 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: @@ -143,9 +147,9 @@ 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 @@ -177,9 +181,6 @@ Directory Hierarchy: /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 @@ -535,25 +536,6 @@ The following options need to be configured: 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. @@ -1498,6 +1480,16 @@ The following options need to be configured: #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 @@ -1789,7 +1781,7 @@ The following options need to be configured: ETX094, IVMS8, IVML24, SPD8xx, TQM8xxL, HERMES, IP860, RPXlite, LWMON, LANTEC, - PCU_E, FLAGADM, TQM8260 + FLAGADM, TQM8260 - Error Recovery: CONFIG_PANIC_HANG @@ -2256,7 +2248,7 @@ Configuration Settings: - 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: @@ -2283,6 +2275,19 @@ Configuration Settings: 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 @@ -2357,6 +2362,14 @@ Configuration Settings: 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: @@ -2507,7 +2520,7 @@ to save the current settings. 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. @@ -2534,18 +2547,32 @@ to save the current settings. - 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 @@ -2565,7 +2592,7 @@ to save the current settings. 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 @@ -2659,7 +2686,7 @@ Low Level (hardware related) configuration options: 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. @@ -2809,19 +2836,17 @@ Low Level (hardware related) configuration options: 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. @@ -3151,10 +3176,10 @@ List of environment variables (most likely not complete): 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. @@ -3303,6 +3328,11 @@ o If both the SROM and the environment contain a MAC address, and the o If neither SROM nor the environment contain a MAC address, an error is raised. +If Ethernet drivers implement the 'write_hwaddr' function, valid MAC addresses +will be programmed into hardware as part of the initialization process. This +may be skipped by setting the appropriate 'ethmacskip' environment variable. +The naming convention is as follows: +"ethmacskip" (=>eth0), "eth1macskip" (=>eth1) etc. Image Formats: ============== @@ -3332,8 +3362,8 @@ details; basically, the header defines the following image properties: 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 @@ -4018,6 +4048,14 @@ On ARM, the following registers are used: ==> 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.