diff options
Diffstat (limited to 'doc')
| -rw-r--r-- | doc/README.fdt-control | 6 | ||||
| -rw-r--r-- | doc/README.fsl_iim | 48 | ||||
| -rw-r--r-- | doc/README.fuse | 67 | ||||
| -rw-r--r-- | doc/README.imx25 | 10 | ||||
| -rw-r--r-- | doc/README.imx27 | 10 | ||||
| -rw-r--r-- | doc/README.imx5 | 6 | ||||
| -rw-r--r-- | doc/README.imx6 | 10 | ||||
| -rw-r--r-- | doc/README.imximage | 18 | ||||
| -rw-r--r-- | doc/README.mxc_ocotp | 50 | ||||
| -rw-r--r-- | doc/README.p1010rdb | 199 | ||||
| -rw-r--r-- | doc/README.ramboot-ppc85xx | 102 | ||||
| -rw-r--r-- | doc/README.watchdog | 3 | ||||
| -rw-r--r-- | doc/feature-removal-schedule.txt | 19 | ||||
| -rw-r--r-- | doc/git-mailrc | 3 |
14 files changed, 537 insertions, 14 deletions
diff --git a/doc/README.fdt-control b/doc/README.fdt-control index 8352835ee9..5963f78e96 100644 --- a/doc/README.fdt-control +++ b/doc/README.fdt-control @@ -142,7 +142,11 @@ join the two: and then flash image.bin onto your board. -You cannot use both of these options at the same time. +If CONFIG_OF_HOSTFILE is defined, then it will be read from a file on +startup. This is only useful for sandbox. Use the -d flag to U-Boot to +specify the file to read. + +You cannot use more than one of these options at the same time. If you wish to put the fdt at a different address in memory, you can define the "fdtcontroladdr" environment variable. This is the hex diff --git a/doc/README.fsl_iim b/doc/README.fsl_iim new file mode 100644 index 0000000000..e087f5e0e4 --- /dev/null +++ b/doc/README.fsl_iim @@ -0,0 +1,48 @@ +Driver implementing the fuse API for Freescale's IC Identification Module (IIM) + +This IP can be found on the following SoCs: + - MPC512x, + - i.MX25, + - i.MX27, + - i.MX31, + - i.MX35, + - i.MX51, + - i.MX53. + +The section numbers in this file refer to the i.MX25 Reference Manual. + +A fuse word contains 8 fuse bit slots, as explained in 30.4.2.2.1. + +A bank contains 256 fuse word slots, as shown by the memory map in 30.3.1. + +Some fuse bit or word slots may not have the corresponding fuses actually +implemented in the fusebox. + +See the README files of the SoCs using this driver in order to know the +conventions used by U-Boot to store some specific data in the fuses, e.g. MAC +addresses. + +Fuse operations: + + Read + Read operations are implemented as read accesses to the shadow registers, + using "Word y of Bank x" from the register summary in 30.3.2. This is + explained in detail in 30.4.5.1. + + Sense + Sense operations are implemented as explained in 30.4.5.2. + + Program + Program operations are implemented as explained in 30.4.5.3. Following + this operation, the shadow registers are reloaded by the hardware (not + immediately, but this does not make any difference for a user reading + these registers). + + Override + Override operations are implemented as write accesses to the shadow + registers, as explained in 30.4.5.4. + +Configuration: + + CONFIG_FSL_IIM + Define this to enable the fsl_iim driver. diff --git a/doc/README.fuse b/doc/README.fuse new file mode 100644 index 0000000000..1bc91c44a6 --- /dev/null +++ b/doc/README.fuse @@ -0,0 +1,67 @@ +Fuse API functions and commands + +The fuse API allows to control a fusebox and how it is used by the upper +hardware layers. + +A fuse corresponds to a single non-volatile memory bit that can be programmed +(i.e. blown, set to 1) only once. The programming operation is irreversible. A +fuse that has not been programmed reads 0. + +Fuses can be used by SoCs to store various permanent configuration and data, +e.g. boot configuration, security configuration, MAC addresses, etc. + +A fuse word is the smallest group of fuses that can be read at once from the +fusebox control IP registers. This is limited to 32 bits with the current API. + +A fuse bank is the smallest group of fuse words having a common ID, as defined +by each SoC. + +Upon startup, the fusebox control IP reads the fuse values and stores them to a +volatile shadow cache. + +See the README files of the drivers implementing this API in order to know the +SoC- and implementation-specific details. + +Functions / commands: + + int fuse_read(u32 bank, u32 word, u32 *val); + fuse read <bank> <word> [<cnt>] + Read fuse words from the shadow cache. + + int fuse_sense(u32 bank, u32 word, u32 *val); + fuse sense <bank> <word> [<cnt>] + Sense - i.e. read directly from the fusebox, skipping the shadow cache - + fuse words. This operation does not update the shadow cache. + + This is useful to know the true value of fuses if an override has been + performed (see below). + + int fuse_prog(u32 bank, u32 word, u32 val); + fuse prog [-y] <bank> <word> <hexval> [<hexval>...] + Program fuse words. This operation directly affects the fusebox and is + irreversible. The shadow cache is updated accordingly or not, depending on + each IP. + + Only the bits to be programmed should be set in the input value (i.e. for + fuse bits that have already been programmed and hence should be left + unchanged by a further programming, it is preferable to clear the + corresponding bits in the input value in order not to perform a new + hardware programming operation on these fuse bits). + + int fuse_override(u32 bank, u32 word, u32 val); + fuse override <bank> <word> <hexval> [<hexval>...] + Override fuse words in the shadow cache. + + The fusebox is unaffected, so following this operation, the shadow cache + may differ from the fusebox values. Read or sense operations can then be + used to get the values from the shadow cache or from the fusebox. + + This is useful to change the behaviors linked to some cached fuse values, + either because this is needed only temporarily, or because some of the + fuses have already been programmed or are locked (if the SoC allows to + override a locked fuse). + +Configuration: + + CONFIG_CMD_FUSE + Define this to enable the fuse commands. diff --git a/doc/README.imx25 b/doc/README.imx25 new file mode 100644 index 0000000000..0ca21b6dfe --- /dev/null +++ b/doc/README.imx25 @@ -0,0 +1,10 @@ +U-Boot for Freescale i.MX25 + +This file contains information for the port of U-Boot to the Freescale i.MX25 +SoC. + +1. CONVENTIONS FOR FUSE ASSIGNMENTS +----------------------------------- + +1.1 MAC Address: It is stored in the words 26 to 31 of fuse bank 0, using the + natural MAC byte order (i.e. MSB first). diff --git a/doc/README.imx27 b/doc/README.imx27 new file mode 100644 index 0000000000..6f92cb47ce --- /dev/null +++ b/doc/README.imx27 @@ -0,0 +1,10 @@ +U-Boot for Freescale i.MX27 + +This file contains information for the port of U-Boot to the Freescale i.MX27 +SoC. + +1. CONVENTIONS FOR FUSE ASSIGNMENTS +----------------------------------- + +1.1 MAC Address: It is stored in the words 4 to 9 of fuse bank 0, using the + reversed MAC byte order (i.e. LSB first). diff --git a/doc/README.imx5 b/doc/README.imx5 index e08941e2ae..c5312b69d3 100644 --- a/doc/README.imx5 +++ b/doc/README.imx5 @@ -20,3 +20,9 @@ i.MX5x SoCs. This option should be enabled for boards having a SYS_ON_OFF_CTL signal connected to GPIO1[23] and triggering the MAIN_PWR_ON signal like in the reference designs. + +2. CONVENTIONS FOR FUSE ASSIGNMENTS +----------------------------------- + +2.1 MAC Address: It is stored in the words 9 to 14 of fuse bank 1, using the + natural MAC byte order (i.e. MSB first). diff --git a/doc/README.imx6 b/doc/README.imx6 new file mode 100644 index 0000000000..513a06ee86 --- /dev/null +++ b/doc/README.imx6 @@ -0,0 +1,10 @@ +U-Boot for Freescale i.MX6 + +This file contains information for the port of U-Boot to the Freescale i.MX6 +SoC. + +1. CONVENTIONS FOR FUSE ASSIGNMENTS +----------------------------------- + +1.1 MAC Address: It is stored in fuse bank 4, with the 32 lsbs in word 2 and the + 16 msbs in word 3. diff --git a/doc/README.imximage b/doc/README.imximage index 073e3fcb3c..802eb90f1d 100644 --- a/doc/README.imximage +++ b/doc/README.imximage @@ -65,9 +65,27 @@ Configuration command line syntax: This command need appear the fist before other valid commands in configuration file. + BOOT_OFFSET value + + This command is parallel to BOOT_FROM and + is preferred over BOOT_FROM. + + value: Offset of the image header, this + value shall be set to one of the + values found in the file: + arch/arm/include/asm/\ + imx-common/imximage.cfg + Example: + BOOT_OFFSET FLASH_OFFSET_STANDARD + BOOT_FROM nand/spi/sd/onenand/nor/sata + + This command is parallel to BOOT_OFFSET and + is to be deprecated in favor of BOOT_OFFSET. + Example: BOOT_FROM spi + DATA type address value type: word=4, halfword=2, byte=1 diff --git a/doc/README.mxc_ocotp b/doc/README.mxc_ocotp new file mode 100644 index 0000000000..9a5331153e --- /dev/null +++ b/doc/README.mxc_ocotp @@ -0,0 +1,50 @@ +Driver implementing the fuse API for Freescale's On-Chip OTP Controller (OCOTP) +on MXC + +This IP can be found on the following SoCs: + - i.MX6. + +Note that this IP is different from albeit similar to the IPs of the same name +that can be found on the following SoCs: + - i.MX23, + - i.MX28, + - i.MX50. + +The section numbers in this file refer to the i.MX6 Reference Manual. + +A fuse word contains 32 fuse bit slots, as explained in 46.2.1. + +A bank contains 8 fuse word slots, as explained in 46.2.1 and shown by the +memory map in 46.4. + +Some fuse bit or word slots may not have the corresponding fuses actually +implemented in the fusebox. + +See the README files of the SoCs using this driver in order to know the +conventions used by U-Boot to store some specific data in the fuses, e.g. MAC +addresses. + +Fuse operations: + + Read + Read operations are implemented as read accesses to the shadow registers, + using "Bankx Wordy" from the memory map in 46.4. This is explained in + detail by the first two paragraphs in 46.2.1.2. + + Sense + Sense operations are implemented as the direct fusebox read explained by + the steps in 46.2.1.2. + + Program + Program operations are implemented as explained by the steps in 46.2.1.3. + Following this operation, the shadow registers are not reloaded by the + hardware. + + Override + Override operations are implemented as write accesses to the shadow + registers, as explained by the first paragraph in 46.2.1.3. + +Configuration: + + CONFIG_MXC_OCOTP + Define this to enable the mxc_ocotp driver. diff --git a/doc/README.p1010rdb b/doc/README.p1010rdb new file mode 100644 index 0000000000..dee63d713a --- /dev/null +++ b/doc/README.p1010rdb @@ -0,0 +1,199 @@ +Overview +========= +The P1010RDB is a Freescale reference design board that hosts the P1010 SoC. + +The P1010 is a cost-effective, low-power, highly integrated host processor +based on a Power Architecture e500v2 core (maximum core frequency 800/1000 MHz), +that addresses the requirements of several routing, gateways, storage, consumer, +and industrial applications. Applications of interest include the main CPUs and +I/O processors in network attached storage (NAS), the voice over IP (VoIP) +router/gateway, and wireless LAN (WLAN) and industrial controllers. + +The P1010RDB board features are as follows: +Memory subsystem: + - 1Gbyte unbuffered DDR3 SDRAM discrete devices (32-bit bus) + - 32 Mbyte NOR flash single-chip memory + - 32 Mbyte NAND flash memory + - 256 Kbit M24256 I2C EEPROM + - 16 Mbyte SPI memory + - I2C Board EEPROM 128x8 bit memory + - SD/MMC connector to interface with the SD memory card +Interfaces: + - PCIe: + - Lane0: x1 mini-PCIe slot + - Lane1: x1 PCIe standard slot + - SATA: + - 1 internal SATA connector to 2.5" 160G SATA2 HDD + - 1 eSATA connector to rear panel + - 10/100/1000 BaseT Ethernet ports: + - eTSEC1, RGMII: one 10/100/1000 port using Vitesse VSC8641XKO + - eTSEC2, SGMII: one 10/100/1000 port using Vitesse VSC8221 + - eTSEC3, SGMII: one 10/100/1000 port using Vitesse VSC8221 + - USB 2.0 port: + - x1 USB2.0 port: via an ULPI PHY to micro-AB connector + - x1 USB2.0 poort via an internal PHY to micro-AB connector + - FlexCAN ports: + - x2 DB-9 female connectors for FlexCAN bus(revision 2.0B) + interface; + - DUART interface: + - DUART interface: supports two UARTs up to 115200 bps for + console display + - J45 connectors are used for these 2 UART ports. + - TDM + - 2 FXS ports connected via an external SLIC to the TDM + interface. SLIC is controllled via SPI. + - 1 FXO port connected via a relay to FXS for switchover to + POTS +Board connectors: + - Mini-ITX power supply connector + - JTAG/COP for debugging +IEEE Std. 1588 signals for test and measurement +Real-time clock on I2C bus +POR + - support critical POR setting changed via switch on board +PCB + - 6-layer routing (4-layer signals, 2-layer power and ground) + + +Serial Port Configuration on P1010RDB +===================================== +Configure the serial port of the attached computer with the following values: + -Data rate: 115200 bps + -Number of data bits: 8 + -Parity: None + -Number of Stop bits: 1 + -Flow Control: Hardware/None + + +Settings of DIP-switch +====================== + SW4[1:4]= 1111 and SW6[4]=0 for boot from 16bit NOR flash + SW4[1:4]= 1000 and SW6[4]=1 for boot from 8bit NAND flash + SW4[1:4]= 0110 and SW6[4]=0 for boot from SPI flash +Note: 1 stands for 'on', 0 stands for 'off' + + +Setting of hwconfig +=================== +If FlexCAN or TDM is needed, please set "fsl_p1010mux:tdm_can=can" or +"fsl_p1010mux:tdm_can=tdm" explicitly in u-booot prompt as below for example: +setenv hwconfig "fsl_p1010mux:tdm_can=tdm;usb1:dr_mode=host,phy_type=utmi" +By default, don't set fsl_p1010mux:tdm_can, in this case, spi chip selection +is set to spi-flash instead of to SLIC/TDM/DAC and tdm_can_sel is set to TDM +instead of to CAN/UART1. + + +Build and burn u-boot to NOR flash +================================== +1. Build u-boot.bin image + export ARCH=powerpc + export CROSS_COMPILE=/your_path/powerpc-linux-gnu- + make P1010RDB_NOR + +2. Burn u-boot.bin into NOR flash + => tftp $loadaddr $uboot + => protect off eff80000 +$filesize + => erase eff80000 +$filesize + => cp.b $loadaddr eff80000 $filesize + +3. Check SW4[1:4]= 1111 and SW6[4]=0, then power on. + + +Alternate NOR bank +============================ +1. Burn u-boot.bin into alternate NOR bank + => tftp $loadaddr $uboot + => protect off eef80000 +$filesize + => erase eef80000 +$filesize + => cp.b $loadaddr eef80000 $filesize + +2. Switch to alternate NOR bank + => mw.b ffb00009 1 + => reset + or set SW1[8]= ON + +SW1[8]= OFF: Upper bank used for booting start +SW1[8]= ON: Lower bank used for booting start +CPLD NOR bank selection register address 0xFFB00009 Bit[0]: +0 - boot from upper 4 sectors +1 - boot from lower 4 sectors + + +Build and burn u-boot to NAND flash +=================================== +1. Build u-boot.bin image + export ARCH=powerpc + export CROSS_COMPILE=/your_path/powerpc-linux-gnu- + make P1010RDB_NAND + +2. Burn u-boot-nand.bin into NAND flash + => tftp $loadaddr $uboot-nand + => nand erase 0 $filesize + => nand write $loadaddr 0 $filesize + +3. Check SW4[1:4]= 1000 and SW6[4]=1, then power on. + + + +Build and burn u-boot to SPI flash +================================== +1. Build u-boot-spi.bin image + make P1010RDB_SPIFLASH_config; make + Boot up kernel with rootfs.ext2.gz.uboot.p1010rdb + Download u-boot.bin to linux and you can find some config files + under /usr/share such as config_xx.dat. Do below command: + boot_format config_ddr3_1gb_p1010rdb_800M.dat u-boot.bin -spi \ + u-boot-spi.bin + to generate u-boot-spi.bin. + +2. Burn u-boot-spi.bin into SPI flash + => tftp $loadaddr $uboot-spi + => sf erase 0 100000 + => sf write $loadaddr 0 $filesize + +3. Check SW4[1:4]= 0110 and SW6[4]=0, then power on. + + + +CPLD POR setting registers +========================== +1. Set POR switch selection register (addr 0xFFB00011) to 0. +2. Write CPLD POR registers (BCSR0~BCSR3, addr 0xFFB00014~0xFFB00017) with + proper values. + If change boot ROM location to NOR or NAND flash, need write the IFC_CS0 + switch command by I2C. +3. Send reset command. + After reset, the new POR setting will be implemented. + +Two examples are given in below: +Switch from NOR to NAND boot with default frequency: + => i2c dev 0 + => i2c mw 18 1 f9 + => i2c mw 18 3 f0 + => mw.b ffb00011 0 + => mw.b ffb00017 1 + => reset +Switch from NAND to NOR boot with Core/CCB/DDR (800/400/667 MHz): + => i2c dev 0 + => i2c mw 18 1 f1 + => i2c mw 18 3 f0 + => mw.b ffb00011 0 + => mw.b ffb00014 2 + => mw.b ffb00015 5 + => mw.b ffb00016 3 + => mw.b ffb00017 f + => reset + + + +Boot Linux from network using TFTP on P1010RDB +============================================== +Place uImage, p1010rdb.dtb and rootfs files in the TFTP disk area. + => tftp 1000000 uImage + => tftp 2000000 p1010rdb.dtb + => tftp 3000000 rootfs.ext2.gz.uboot.p1010rdb + => bootm 1000000 3000000 2000000 + + +Please contact your local field applications engineer or sales representative +to obtain related documents, such as P1010-RDB User Guide for details. diff --git a/doc/README.ramboot-ppc85xx b/doc/README.ramboot-ppc85xx new file mode 100644 index 0000000000..8ed45fb46d --- /dev/null +++ b/doc/README.ramboot-ppc85xx @@ -0,0 +1,102 @@ + RAMBOOT for MPC85xx Platforms + ============================== + +RAMBOOT literally means boot from DDR. But since DDR is volatile memory some +pre-mechanism is required to load the DDR with the bootloader binary. +- In case of SD and SPI boot this is done by BootROM code inside the chip + itself. +- In case of NAND boot FCM supports loading initial 4K code from NAND flash + which can initialize the DDR and get the complete bootloader copied to DDR. + +In addition to the above there could be some more methods to initialize the DDR +and load it manually. +Two of them are described below.There is also an explanation as to where these +methods could be handy. +1. Load the RAM based bootloader onto DDR via JTAG/BDI interface. And then + execute the bootloader from DDR. + This may be handy in the following cases: + - In very early stage of platform bringup where other boot options are not + functional because of various reasons. + - In case the support to program the flashes on the board is not available. + +2. Load the RAM based bootloader onto DDR using already existing bootloader on + the board.And then execute the bootloader from DDR. + Some usecases where this may be used: + - While developing some new feature of u-boot, for example USB driver or + SPI driver. + Suppose the board already has a working bootloader on it. And you would + prefer to keep it intact, at the same time want to test your bootloader. + In this case you can get your test bootloader binary into DDR via tftp + for example. Then execute the test bootloader. + - Suppose a platform already has a propreitery bootloader which does not + support for example AMP boot. In this case also RAM boot loader can be + utilized. + + So basically when the original bootloader is required to be kept intact + RAM based bootloader can offer an updated bootloader on the system. + +Both the above Bootloaders are slight variants of SDcard or SPI Flash +bootloader or for that matter even NAND bootloader. +All of them define CONFIG_SYS_RAMBOOT. +The main difference among all of them is the way the pre-environment is getting +configured and who is doing that. +- In case of SD card and SPI flash bootloader this is done by On Chip BootROM inside the Si itself. +- In case of NAND boot SPL/TPL code does it with some support from Si itself. +- In case of the pure RAM based bootloaders we have to do it by JTAG manually or already existing bootloader. + +How to use them: +1. Using JTAG + Boot up in core hold off mode or stop the core after reset using JTAG + interface. + Preconfigure DDR/L2SRAM through JTAG interface. + - setup DDR controller registers. + - setup DDR LAWs + - setup DDR TLB + Load the RAM based boot loader to the proper location in DDR/L2SRAM. + set up IAR (Instruction counter properly) + Enable the core to execute. + +2. Using already existing bootloader. + get the rambased boot loader binary into DDR/L2SRAM via tftp. + execute the RAM based bootloader. + => tftp 11000000 u-boot-ram.bin + => go 1107f000 + +Please note that L2SRAM can also be used instead of DDR if the SOC has +sufficient size of L2SRAM. + +Necessary Code changes Required: +===================================== +Please note that below mentioned changes are for 85xx platforms. +They have been tested on P1020/P2020/P1010 RDB. + +The main difference between the above two methods from technical perspective is +that in 1st case SOC is just out of reset so it is in default configuration. +(CCSRBAR is at 0xff700000). +In the 2nd case bootloader has already re-located CCSRBAR to 0xffe00000 + +1. File name-> boards.cfg + There can be added specific Make options for RAMBoot. We can keep different + options for the two cases mentioned above. + for example + P1020RDB_JTAG_RAMBOOT and P1020RDB_GO_RAMBOOT. + +2. platform config file + for example include/configs/P1_P2_RDB.h + + #ifdef CONFIG_RAMBOOT + #define CONFIG_SDCARD + #endif + + This will finally use the CONFIG_SYS_RAMBOOT. + +3. File name-> arch/powerpc/include/asm/config_mpc85xx.h + In the section of the particular SOC, for example P1020, + + #if defined(CONFIG_GO) + #define CONFIG_SYS_CCSRBAR_DEFAULT 0xffe00000 + #else + #define CONFIG_SYS_CCSRBAR_DEFAULT 0xff700000 + #endif + +For JTAG RAMBOOT this is not required because CCSRBAR is at ff700000. diff --git a/doc/README.watchdog b/doc/README.watchdog index ee65008b4b..33f31c2140 100644 --- a/doc/README.watchdog +++ b/doc/README.watchdog @@ -27,3 +27,6 @@ CONFIG_IMX_WATCHDOG Available for i.mx31/35/5x/6x to service the watchdog. This is not automatically set because some boards (vision2) still need to define their own hw_watchdog_reset routine. + +CONFIG_XILINX_TB_WATCHDOG + Available for Xilinx Axi platforms to service timebase watchdog timer. diff --git a/doc/feature-removal-schedule.txt b/doc/feature-removal-schedule.txt index ce728612e3..1c79c14a3b 100644 --- a/doc/feature-removal-schedule.txt +++ b/doc/feature-removal-schedule.txt @@ -7,20 +7,15 @@ file. --------------------------- -What: Remove CONFIG_CMD_MEMTEST from default list -When: Release v2013.07 +What: Remove unused CONFIG_SYS_MEMTEST_START/END +When: Release v2013.10 -Why: The "mtest" command is of little practical use (if any), and - experience has shown that a large number of board configu- - rations define useless or even dangerous start and end - addresses. If not even the board maintainers are able to - figure out which memory range can be reliably tested, how can - we expect such from the end users? As this problem comes up - repeatedly, we rather do not enable this command by default, - so only people who know what they are doing will be confronted - with it. +Why: As the 'mtest' command is no longer default, a number of platforms + have not opted to turn the command back on and thus provide unused + defines (which are likely to be propogated to new platforms from + copy/paste). Remove these defines when unused. -Who: Wolfgang Denk <wd@denx.de> +Who: Tom Rini <trini@ti.com> --------------------------- diff --git a/doc/git-mailrc b/doc/git-mailrc index 0f23776041..e3a47c46f3 100644 --- a/doc/git-mailrc +++ b/doc/git-mailrc @@ -34,6 +34,7 @@ alias sjg Simon Glass <sjg@chromium.org> alias smcnutt Scott McNutt <smcnutt@psyent.com> alias sonic Sonic Zhang <sonic.adi@gmail.com> alias stroese Stefan Roese <sr@denx.de> +alias trini Tom Rini <trini@ti.com> alias vapier Mike Frysinger <vapier@gentoo.org> alias wd Wolfgang Denk <wd@denx.de> @@ -54,7 +55,7 @@ alias s5pc samsung alias samsung uboot, prom alias tegra uboot, sjg, Tom Warren <twarren@nvidia.com>, Stephen Warren <swarren@nvidia.com> alias tegra2 tegra -alias ti uboot, Tom Rini <trini@ti.com> +alias ti uboot, trini alias avr32 uboot, abiessmann |