summaryrefslogtreecommitdiff
path: root/doc
diff options
context:
space:
mode:
Diffstat (limited to 'doc')
-rw-r--r--doc/README.clang4
-rw-r--r--doc/README.fsl-dpaa10
-rw-r--r--doc/README.kwbimage4
-rw-r--r--doc/README.mxsimage13
-rw-r--r--doc/README.odroid216
-rw-r--r--doc/README.scrapyard77
-rw-r--r--doc/README.video55
-rw-r--r--doc/README.x86177
-rw-r--r--doc/SPI/README.altera_spi6
-rw-r--r--doc/device-tree-bindings/ata/intel-sata.txt26
-rw-r--r--doc/device-tree-bindings/input/cros-ec-keyb.txt53
-rw-r--r--doc/device-tree-bindings/misc/intel-lpc.txt64
-rw-r--r--doc/device-tree-bindings/video/intel-gma.txt40
-rw-r--r--doc/driver-model/README.txt48
-rw-r--r--doc/git-mailrc15
-rw-r--r--doc/mkimage.18
16 files changed, 731 insertions, 85 deletions
diff --git a/doc/README.clang b/doc/README.clang
index 52495d3116..fe36909449 100644
--- a/doc/README.clang
+++ b/doc/README.clang
@@ -28,7 +28,7 @@ sudo apt-get install clang
To compile U-Boot with clang on linux without IAS use e.g.:
export TRIPLET=arm-linux-gnueabi && export CROSS_COMPILE="$TRIPLET-"
-make HOSTCC=clang CC="clang -target $TRIPLET -mllvm -arm-use-movt=0 -no-integrated-as" rpi_b_defconfig
+make HOSTCC=clang CC="clang -target $TRIPLET -mllvm -arm-use-movt=0 -no-integrated-as" rpi_defconfig
make HOSTCC=clang CC="clang -target $TRIPLET -mllvm -arm-use-movt=0 -no-integrated-as" all V=1 -j8
FreeBSD 11 (Current):
@@ -42,7 +42,7 @@ ln -s /usr/local/bin/arm-gnueabi-freebsd-as /usr/bin/arm-freebsd-eabi-as
# The following commands compile U-Boot using the clang xdev toolchain.
# NOTE: CROSS_COMPILE and target differ on purpose!
export CROSS_COMPILE=arm-gnueabi-freebsd-
-gmake CC="clang -target arm-freebsd-eabi --sysroot /usr/arm-freebsd -no-integrated-as -mllvm -arm-use-movt=0" rpi_b_defconfig
+gmake CC="clang -target arm-freebsd-eabi --sysroot /usr/arm-freebsd -no-integrated-as -mllvm -arm-use-movt=0" rpi_defconfig
gmake CC="clang -target arm-freebsd-eabi --sysroot /usr/arm-freebsd -no-integrated-as -mllvm -arm-use-movt=0" -j8
Given that u-boot will default to gcc, above commands can be
diff --git a/doc/README.fsl-dpaa b/doc/README.fsl-dpaa
new file mode 100644
index 0000000000..0d8d4f6efc
--- /dev/null
+++ b/doc/README.fsl-dpaa
@@ -0,0 +1,10 @@
+This file documents Freescale DPAA-specific options.
+
+FMan (Frame Manager)
+ - CONFIG_FSL_FM_10GEC_REGULAR_NOTATION
+ on SoCs earlier(e.g. T4240, T2080), the notation between 10GEC and MAC as below:
+ 10GEC1->MAC9, 10GEC2->MAC10, 10GEC3->MAC1, 10GEC4->MAC2
+ on SoCs later(e.g. T1024, etc), the notation between 10GEC and MAC as below:
+ 10GEC1->MAC1, 10GEC2->MAC2
+ so we introduce CONFIG_FSL_FM_10GEC_REGULAR_NOTATION to identify the new SoCs on
+ which 10GEC enumeration is consistent with MAC enumeration.
diff --git a/doc/README.kwbimage b/doc/README.kwbimage
index 13f6f92f68..762b2e3acb 100644
--- a/doc/README.kwbimage
+++ b/doc/README.kwbimage
@@ -30,10 +30,10 @@ kwbimage support available with mkimage utility will generate kirkwood boot
image that can be flashed on the board NAND/SPI flash. The make target
which uses mkimage to produce such an image is "u-boot.kwb". For example:
- export BUILD_DIR=/tmp/build
+ export KBUILD_OUTPUT=/tmp/build
make distclean
make yourboard_config
- make $BUILD_DIR/u-boot.kwb
+ make u-boot.kwb
Board specific configuration file specifications:
diff --git a/doc/README.mxsimage b/doc/README.mxsimage
index 0d31cba1fb..c3975ee5e6 100644
--- a/doc/README.mxsimage
+++ b/doc/README.mxsimage
@@ -27,7 +27,7 @@ These semantics and rules will be outlined now.
- Each line of the configuration file contains exactly one instruction.
- Every numeric value must be encoded in hexadecimal and in format 0xabcdef12 .
- The configuration file is a concatenation of blocks called "sections" and
- optionally "DCD blocks" (see below).
+ optionally "DCD blocks" (see below), and optional flags lines.
- Each "section" is started by the "SECTION" instruction.
- The "SECTION" instruction has the following semantics:
@@ -139,9 +139,14 @@ These semantics and rules will be outlined now.
NOOP
- This instruction does nothing.
-- If the verbose output from the BootROM is enabled, the BootROM will produce a
- letter on the Debug UART for each instruction it started processing. Here is a
- mapping between the above instructions and the BootROM verbose output:
+ - An optional flags lines can be one of the following:
+
+ DISPLAYPROGRESS
+ - Enable boot progress output form the BootROM.
+
+- If the boot progress output from the BootROM is enabled, the BootROM will
+ produce a letter on the Debug UART for each instruction it started processing.
+ Here is a mapping between the above instructions and the BootROM output:
H -- SB Image header loaded
T -- TAG instruction
diff --git a/doc/README.odroid b/doc/README.odroid
index 528bb95279..8a004ca6ba 100644
--- a/doc/README.odroid
+++ b/doc/README.odroid
@@ -1,28 +1,39 @@
- U-boot for Odroid X2/U3
+ U-boot for Odroid X2/U3/XU3
========================
1. Summary
==========
-This is a quick instruction for setup Odroid boards based on Exynos4412.
-Board config: odroid_config
+This is a quick instruction for setup Odroid boards.
+Board config: odroid_config for X2/U3
+Board config: odroid-xu3_config for XU3
2. Supported devices
====================
-This U-BOOT config can be used on two boards:
+This U-BOOT config can be used on three boards:
- Odroid U3
- Odroid X2
with CPU Exynos 4412 rev 2.0 and 2GB of RAM
+- Odroid XU3
+with CPU Exynos5422 and 2GB of RAM
3. Boot sequence
================
iROM->BL1->(BL2 + TrustZone)->U-BOOT
-This version of U-BOOT doesn't implement SPL but it is required(BL2)
-and can be found in "boot.tar.gz" from here:
+This version of U-BOOT doesn't implement SPL. So, BL1, BL2, and TrustZone
+binaries are needed to boot up.
+
+<< X2/U3 >>
+It can be found in "boot.tar.gz" from here:
http://dev.odroid.com/projects/4412boot/wiki/FrontPage?action=download&value=boot.tar.gz
or here:
http://odroid.in/guides/ubuntu-lfs/boot.tar.gz
+<< XU3 >>
+It can be downloaded from:
+https://github.com/hardkernel/u-boot/tree/odroidxu3-v2012.07/sd_fuse/hardkernel
+
+
4. Boot media layout
====================
The table below shows SD/eMMC cards layout for U-boot.
@@ -35,18 +46,20 @@ The block offset is starting from 0 and the block size is 512B.
| Bl2 | 31 | 30 | 1 (boot) |
| U-boot | 63 | 62 | 1 (boot) |
| Tzsw | 2111 | 2110 | 1 (boot) |
-| Uboot Env | 2500 | 2500 | 0 (user) |
+| Uboot Env | 2560 | 2560 | 0 (user) |
-------------------------------------
5. Prepare the SD boot card - with SD card reader
=================================================
To prepare bootable media you need boot binaries provided by hardkernel.
-File "boot.tar.gz" (link in point 3.) contains:
-- E4412_S.bl1.HardKernel.bin
-- E4412_S.tzsw.signed.bin
-- bl2.signed.bin
+From the downloaded files, You can find:
+- bl1.bin
+- tzsw.bin
+- bl2.bin
- sd_fusing.sh
- u-boot.bin
+(The file names can be slightly different, but you can distinguish what they are
+without problem)
This is all you need to boot this board. But if you want to use your custom
u-boot then you need to change u-boot.bin with your own u-boot binary*
@@ -56,7 +69,7 @@ and run the script "sd_fusing.sh" - this script is valid only for SD card.
The proper binary file of current U-boot is u-boot-dtb.bin.
quick steps for Linux:
-- extract boot.tar.gz
+- Download all files from the link at point 3 and extract it if needed.
- put any SD card into the SD reader
- check the device with "dmesg"
- run ./sd_fusing.sh /dev/sdX - where X is SD card device (but not a partition)
@@ -66,7 +79,7 @@ Check if Hardkernel U-boot is booting, and next do the same with your U-boot.
with a eMMC card reader (boot from eMMC card slot)
=====================================================
To boot the device from the eMMC slot you should use a special card reader
-which supports eMMC partiion switch. All of the boot binaries are stored
+which supports eMMC partition switch. All of the boot binaries are stored
on the eMMC boot partition which is normally hidden.
The "sd_fusing.sh" script can be used after updating offsets of binaries
@@ -81,8 +94,8 @@ But then the device can boot only from the SD card slot.
8. Prepare the boot media using Hardkernel U-boot
=================================================
-You can update the U-boot to the custom one if you have an working bootloader
-delivered with the board on a eMMC/SD card. Then follow the steps:
+You can update the U-boot to the custom one if you have a working bootloader
+delivered with the board on the eMMC/SD card. Then follow the steps:
- install the android fastboot tool
- connect a micro usb cable to the board
- on the U-boot prompt, run command: fastboot (as a root)
@@ -91,7 +104,7 @@ delivered with the board on a eMMC/SD card. Then follow the steps:
9. Partition layout
====================
-Default U-boot environment is setup for fixed partiion layout.
+Default U-boot environment is setup for fixed partition layout.
Partition table: MSDOS. Disk layout and files as listed in the table below.
----- ------ ------ ------ -------- ---------------------------------
@@ -106,6 +119,7 @@ Partition table: MSDOS. Disk layout and files as listed in the table below.
Supported fdt files are:
- exynos4412-odroidx2.dtb
- exynos4412-odroidu3.dtb
+- exynos5422-odroidxu3.dtb
Supported kernel files are:
- Image.itb
@@ -141,3 +155,173 @@ And the boot sequence is:
- boot_fit - if "Image.itb" exists
- boot_zimg - if "zImage" exists
- boot_uimg - if "uImage" exists
+
+11. USB host support
+====================
+NOTE: This section is only for Odroid X2/U3.
+
+The ethernet can be accessed after starting the USB subsystem in U-Boot.
+The adapter does not come with a preconfigured MAC address, and hence it needs
+to be set before starting USB.
+setenv usbethaddr 02:DE:AD:BE:EF:FF
+
+Note that in this example a locally managed MAC address is chosen. Care should
+be taken to make these MAC addresses unique within the same subnet.
+
+Start the USB subsystem:
+Odroid # setenv usbethaddr 02:DE:AD:BE:EF:FF
+Odroid # usb start
+(Re)start USB...
+USB0: USB EHCI 1.00
+scanning bus 0 for devices... 4 USB Device(s) found
+ scanning usb for storage devices... 1 Storage Device(s) found
+ scanning usb for ethernet devices... 1 Ethernet Device(s) found
+Odroid #
+
+Automatic IP assignment:
+------------------------
+If the ethernet is connected to a DHCP server (router maybe with DHCP enabled),
+then the below will automatically assign an ip address through DHCP.
+setenv autoload no
+dhcp
+
+Odroid # setenv autoload no
+Odroid # dhcp
+Waiting for Ethernet connection... done.
+BOOTP broadcast 1
+DHCP client bound to address 192.168.1.10 (524 ms)
+Odroid #
+
+Note that this automatically sets the many IP address related variables in
+U-Boot that is obtained from the DHCP server.
+
+Odroid # printenv ipaddr netmask gatewayip dnsip
+ipaddr=192.168.1.10
+netmask=255.255.255.0
+gatewayip=192.168.1.1
+dnsip=192.168.1.1
+
+Ping example:
+The ping command can be used a test to check connectivity. In this example,
+192.168.1.27 is a pingable server in the network.
+Odroid # ping 192.168.1.27
+Waiting for Ethernet connection... done.
+Using sms0 device
+host 192.168.1.27 is alive
+Odroid #
+
+Static IP assignment:
+---------------------
+In the case where there are no DHCP servers in the network, or you want to
+set the IP address statically, it can be done by:
+Odroid # setenv ipaddr 192.168.1.10
+Odroid # ping 192.168.1.27
+Waiting for Ethernet connection... done.
+Using sms0 device
+host 192.168.1.27 is alive
+
+TFTP booting:
+-------------
+Say there exists a tftp server in the network with address 192.168.1.27 and
+it serves a kernel image (zImage.3.17) and a DTB blob (exynos4412-odroidu3.dtb)
+that needs to be loaded and booted. It can be accomplished as below:
+(Assumes that you have setenv usbethaddr, and have not set autoload to no)
+
+Odroid # setenv serverip 192.168.1.27
+Odroid # tftpboot 0x40080000 zImage.3.17
+Waiting for Ethernet connection... done.
+Using sms0 device
+TFTP from server 192.168.1.27; our IP address is 192.168.1.10
+Filename 'zImage.3.17'.
+Load address: 0x40080000
+Loading: #################################################################
+ #################################################################
+ #################################################################
+ #######################
+ 52.7 KiB/s
+done
+Bytes transferred = 3194200 (30bd58 hex)
+Odroid # tftpboot 0x42000000 exynos4412-odroidu3.dtb
+Waiting for Ethernet connection... done.
+Using sms0 device
+TFTP from server 192.168.1.27; our IP address is 192.168.1.10
+Filename 'exynos4412-odroidu3.dtb'.
+Load address: 0x42000000
+Loading: ####
+ 40 KiB/s
+done
+Bytes transferred = 46935 (b757 hex)
+Odroid # printenv bootargs
+bootargs=Please use defined boot
+Odroid # setenv bootargs console=ttySAC1,115200n8 root=/dev/mmcblk0p2 rootwait
+Odroid # bootz 40080000 - 42000000
+Kernel image @ 0x40080000 [ 0x000000 - 0x30bd58 ]
+## Flattened Device Tree blob at 42000000
+ Booting using the fdt blob at 0x42000000
+ Loading Device Tree to 4fff1000, end 4ffff756 ... OK
+
+Starting kernel ...
+
+[ 0.000000] Booting Linux on physical CPU 0xa00
+... etc ...
+
+In the above example you can substitute 'dhcp' for 'tftpboot' as well.
+
+USB Storage booting:
+--------------------
+Similarly we can use the USB storage to load the kernel image/initrd/fdt etc
+and boot. For this example, there is a USB drive plugged in. It has a FAT
+1st partition and an EXT 2nd partition. Using the generic FS (ls/load) makes
+it even easier to work with FAT/EXT file systems.
+For this example the second EXT partition is used for booting and as rootfs.
+The boot files - kernel and the dtb are present in the /boot directory of the
+second partition.
+
+Odroid # usb start
+(Re)start USB...
+USB0: USB EHCI 1.00
+scanning bus 0 for devices... 4 USB Device(s) found
+ scanning usb for storage devices... 1 Storage Device(s) found
+ scanning usb for ethernet devices...
+Error: sms0 address not set. <----- Note the error as usbethaddr
+Warning: failed to set MAC address <----- is not set.
+1 Ethernet Device(s) found
+Odroid # usb part 0
+
+Partition Map for USB device 0 -- Partition Type: DOS
+
+Part Start Sector Num Sectors UUID Type
+ 1 3072 263168 000c4046-01 06
+ 2 266240 13457408 000c4046-02 83
+
+Odroid # ls usb 0:2 /boot
+<DIR> 4096 .
+<DIR> 4096 ..
+ 353 boot.scr
+ 281 boot.txt
+ 101420 config-3.8.13.23
+ 2127254 initrd.img-3.8.13.23
+ 2194825 uInitrd
+ 2194825 uInitrd-3.8.13.23
+ 2453112 zImage
+ 101448 config-3.8.13.26
+ 2127670 uInitrd-3.8.13.26
+ 2127606 initrd.img-3.8.13.26
+ 3194200 zImage.3.17 <--- Kernel
+ 46935 exynos4412-odroidu3.dtb <--- DTB
+Odroid # load usb 0:2 40080000 /boot/zImage.3.17
+3194200 bytes read in 471 ms (6.5 MiB/s)
+Odroid # load usb 0:2 42000000 /boot/exynos4412-odroidu3.dtb
+46935 bytes read in 233 ms (196.3 KiB/s)
+Odroid # setenv bootargs console=ttySAC1,115200n8 root=/dev/sda2 rootwait
+Odroid # bootz 40080000 - 42000000
+Kernel image @ 0x40080000 [ 0x000000 - 0x30bd58 ]
+## Flattened Device Tree blob at 42000000
+ Booting using the fdt blob at 0x42000000
+ Loading Device Tree to 4fff1000, end 4ffff756 ... OK
+
+Starting kernel ...
+
+[ 0.000000] Booting Linux on physical CPU 0xa00
+
+Please refer to README.usb for additional information.
diff --git a/doc/README.scrapyard b/doc/README.scrapyard
index bd4dd3c829..e1a81d3fd3 100644
--- a/doc/README.scrapyard
+++ b/doc/README.scrapyard
@@ -12,9 +12,80 @@ The list should be sorted in reverse chronological order.
Board Arch CPU Commit Removed Last known maintainer/contact
=================================================================================================
-TOP5200 powerpc mpc5200 - - Reinhard Meyer <reinhard.meyer@emk-elektronik.de>
-TOP860 powerpc mpc860 - - Reinhard Meyer <reinhard.meyer@emk-elektronik.de>
-TOP9000 arm at91sam9xeXXX - - Reinhard Meyer <reinhard.meyer@emk-elektronik.de>
+CPCI405 ppc4xx 405gp 5f1459dc 2015-01-13 Matthias Fuchs <matthias.fuchs@esd.eu>
+CPCI405DT ppc4xx 405gpr 5f1459dc 2015-01-13 Matthias Fuchs <matthias.fuchs@esd.eu>
+CPCI405AB ppc4xx 405gpr 5f1459dc 2015-01-13 Matthias Fuchs <matthias.fuchs@esd.eu>
+G2000 ppc4xx 405ep 5f8f6294 2015-01-13 Matthias Fuchs <matthias.fuchs@esd.eu>
+WUH405 ppc4xx 405ep fc88a5bf 2015-01-13 Matthias Fuchs <matthias.fuchs@esd.eu>
+VOH405 ppc4xx 405ep 807db88b 2015-01-13 Matthias Fuchs <matthias.fuchs@esd.eu>
+PMC405 ppc4xx 405gp d5263304 2015-01-13 Matthias Fuchs <matthias.fuchs@esd.eu>
+PCI405 ppc4xx 405gp dbe7bb0d 2015-01-13 Matthias Fuchs <matthias.fuchs@esd.eu>
+OCRTC ppc4xx 405gpr cc6e715f 2015-01-13 Matthias Fuchs <matthias.fuchs@esd.eu>
+HUB405 ppc4xx 405ep e434d5d7 2015-01-13 Matthias Fuchs <matthias.fuchs@esd.eu>
+HH405 ppc4xx 405ep 843125da 2015-01-13 Matthias Fuchs <matthias.fuchs@esd.eu>
+DU440 ppc4xx 440epx 7ac9d47a 2015-01-13 Matthias Fuchs <matthias.fuchs@esd.eu>
+DU405 ppc4xx 405gpr bc114076 2015-01-13 Matthias Fuchs <matthias.fuchs@esd.eu>
+DP405 ppc4xx 405ep 9a4018e0 2015-01-13 Matthias Fuchs <matthias.fuchs@esd.eu>
+CPCIISER4 ppc4xx 405gp 37057260 2015-01-13 Matthias Fuchs <matthias.fuchs@esd.eu>
+CMS700 ppc4xx 405ep 2404124c 2015-01-13 Matthias Fuchs <matthias.fuchs@esd.eu>
+ASH405 ppc4xx 405ep b5e7c84f 2015-01-13 Matthias Fuchs <matthias.fuchs@esd.eu>
+AR405 ppc4xx 405gpr 61b57c4a 2015-01-13 Matthias Fuchs <matthias.fuchs@esd.eu>
+APC405 ppc4xx 405gpr 2b8a04e5 2015-01-13 Matthias Fuchs <matthias.fuchs@esd.eu>
+TASREG m68k mcf52x2 cbdc662a 2015-01-13 Matthias Fuchs <matthias.fuchs@esd.eu>
+A3000 powerpc mpc824x d622ac39 2015-01-05
+CPC45 powerpc mpc824x d622ac39 2015-01-05 Josef Wagner <Wagner@Microsys.de>
+CU824 powerpc mpc824x d622ac39 2015-01-05 Wolfgang Denk <wd@denx.de>
+eXalion powerpc mpc824x d622ac39 2015-01-05 Torsten Demke <torsten.demke@fci.com>
+MVBLUE powerpc mpc824x d622ac39 2015-01-05
+MUSENKI powerpc mpc824x d622ac39 2015-01-05 Jim Thompson <jim@musenki.com>
+Sandpoint8240 powerpc mpc824x d622ac39 2015-01-05 Wolfgang Denk <wd@denx.de>
+Sandpoint8245 powerpc mpc824x d622ac39 2015-01-05 Jim Thompson <jim@musenki.com>
+utx8245 powerpc mpc824x d622ac39 2015-01-05 Greg Allen <gallen@arlut.utexas.edu>
+atc powerpc mpc8260 9067b300 2015-01-05 Wolfgang Denk <wd@denx.de>
+CPU86 powerpc mpc8260 f7e1af86 2015-01-05 Wolfgang Denk <wd@denx.de>
+CPU87 powerpc mpc8260 f7e1af86 2015-01-05
+ep82xxm powerpc mpc8260 e2b19629 2015-01-05
+gw8260 powerpc mpc8260 8eecbaf3 2015-01-05 Oliver Brown <obrown@adventnetworks.com>
+IPHASE4539 powerpc mpc8260 87882f57 2015-01-05 Wolfgang Grandegger <wg@denx.de>
+muas3001 powerpc mpc8260 d2fd1d66 2015-01-05 Heiko Schocher <hs@denx.de>
+PM825 powerpc mpc8260 dc0b2fb4 2015-01-05 Wolfgang Denk <wd@denx.de>
+PM826 powerpc mpc8260 dc0b2fb4 2015-01-05 Wolfgang Denk <wd@denx.de>
+PM828 powerpc mpc8260 dc0b2fb4 2015-01-05
+MPC8266ADS powerpc mpc8260 b3a2bbe1 2015-01-05 Rune Torgersen <runet@innovsys.com>
+VoVPN-GW powerpc mpc8260 cc90905f 2015-01-05
+ep8260 powerpc mpc8260 4ad015ba 2015-01-05 Frank Panno <fpanno@delphintech.com>
+ppmc8260 powerpc mpc8260 793116d2 2015-01-05 Brad Kemp <Brad.Kemp@seranoa.com>
+sacsng powerpc mpc8260 b35c0ad6 2015-01-05 Jerry Van Baren <gerald.vanbaren@smiths-aerospace.com>
+cogent_mpc8260 powerpc mpc8260 d19f6a60 2015-01-05 Murray Jensen <Murray.Jensen@csiro.au>
+cogent_8xx powerpc mpc8xx d19f6a60 2015-01-05 Murray Jensen <Murray.Jensen@csiro.au>
+ESTEEM192E powerpc mpc8xx af0e3514 2015-01-05 Conn Clark <clark@esteem.com>
+IP860 powerpc mpc8xx 5ec71100 2015-01-05 Wolfgang Denk <wd@denx.de>
+IVML24 powerpc mpc8xx ca620cd1 2015-01-05 Wolfgang Denk <wd@denx.de>
+IVMS8 powerpc mpc8xx ca620cd1 2015-01-05 Wolfgang Denk <wd@denx.de>
+lwmon powerpc mpc8xx acc2372d 2015-01-05 Wolfgang Denk <wd@denx.de>
+NETVIA powerpc mpc8xx f017cd7f 2015-01-05 Pantelis Antoniou <panto@intracom.gr>
+R360MPI powerpc mpc8xx 79cbecb8 2015-01-05 Wolfgang Denk <wd@denx.de>
+RRvision powerpc mpc8xx 8737fc75 2015-01-05 Wolfgang Denk <wd@denx.de>
+SPD823TS powerpc mpc8xx 72ba368f 2015-01-05 Wolfgang Denk <wd@denx.de>
+KUP4K powerpc mpc8xx 4317d070 2015-01-05 Klaus Heydeck <heydeck@kieback-peter.de>
+KUP4X powerpc mpc8xx 4317d070 2015-01-05 Klaus Heydeck <heydeck@kieback-peter.de>
+ELPT860 powerpc mpc8xx 3c5b20f1 2015-01-05 The LEOX team <team@leox.org>
+hmi1001 powerpc mpc5xxx ceaf499b 2015-01-05
+mucmc52 powerpc mpc5xxx ceaf499b 2015-01-05 Heiko Schocher <hs@denx.de>
+uc101 powerpc mpc5xxx ceaf499b 2015-01-05 Heiko Schocher <hs@denx.de>
+uc100 powerpc mpc8xx ceaf499b 2015-01-05 Stefan Roese <sr@denx.de>
+FPS850L powerpc mpc8xx 5d2a5ef7 2015-01-05 Wolfgang Denk <wd@denx.de>
+FPS860L powerpc mpc8xx 5d2a5ef7 2015-01-05 Wolfgang Denk <wd@denx.de>
+NSCU powerpc mpc8xx 5d2a5ef7 2015-01-05
+SM850 powerpc mpc8xx 5d2a5ef7 2015-01-05 Wolfgang Denk <wd@denx.de>
+TK885D powerpc mpc8xx 5d2a5ef7 2015-01-05
+virtlab2 powerpc mpc8xx 5d2a5ef7 2015-01-05 Wolfgang Denk <wd@denx.de>
+hermes powerpc mpc8xx 36da51e 2014-12-08 Wolfgang Denk <wd@denx.de>
+PRS200 powerpc mpc5200 ecfdcee 2014-11-12
+MCC200 powerpc mpc5200 ecfdcee 2014-11-12
+TOP5200 powerpc mpc5200 d58a945 2014-10-28 Reinhard Meyer <reinhard.meyer@emk-elektronik.de>
+TOP860 powerpc mpc860 d58a945 2014-10-28 Reinhard Meyer <reinhard.meyer@emk-elektronik.de>
+TOP9000 arm at91sam9xeXXX d58a945 2014-10-28 Reinhard Meyer <reinhard.meyer@emk-elektronik.de>
TQM8272 powerpc mpc8260 f06f9a1 2014-10-27 Wolfgang Denk <wd@denx.de>
TQM8260 powerpc mpc8260 ccc1950 2014-10-27 Wolfgang Denk <wd@denx.de>
IDS8247 powerpc mpc8260 6afb357 2014-10-27 Heiko Schocher <hs@denx.de>
diff --git a/doc/README.video b/doc/README.video
index dadbfcd2fd..d0a3ad6e8d 100644
--- a/doc/README.video
+++ b/doc/README.video
@@ -5,15 +5,8 @@
* SPDX-License-Identifier: GPL-2.0+
*/
-U-Boot MPC8xx video controller driver
-======================================
-
-The driver has been tested with the following configurations:
-
-- MPC823FADS with AD7176 on a PAL TV (YCbYCr) - arsenio@tin.it
-
"video-mode" environment variable
-===============================
+=================================
The 'video-mode' environment variable can be used to enable and configure
some video drivers. The format matches the video= command-line option used
@@ -28,4 +21,50 @@ for Linux:
<freq> The frequency (in Hz) to use.
<options> A comma-separated list of device-specific options
+
+U-Boot MPC8xx video controller driver
+=====================================
+
+The driver has been tested with the following configurations:
+
+- MPC823FADS with AD7176 on a PAL TV (YCbYCr) - arsenio@tin.it
+
Example: video-mode=fslfb:1280x1024-32@60,monitor=dvi
+
+
+U-boot sunxi video controller driver
+====================================
+
+U-boot supports hdmi and lcd output on Allwinner sunxi SoCs, lcd output
+requires the CONFIG_VIDEO_LCD_MODE Kconfig value to be set.
+
+The sunxi u-boot driver supports the following video-mode options:
+
+- monitor=[none|dvi|hdmi|lcd] - Select the video output to use
+ none: Disable video output.
+ dvi/hdmi: Selects output over the hdmi connector with dvi resp. hdmi output
+ format, if edid is used the format is automatically selected.
+ lcd: Selects video output to a LCD screen.
+ vga: Selects bideo output over the VGA connector.
+ Defaults to monitor=dvi.
+
+- hpd=[0|1] - Enable use of the hdmi HotPlug Detect feature
+ 0: Disabled. Configure dvi/hdmi output even if no cable is detected
+ 1: Enabled. Fallback to the lcd / vga / none in that order (if available)
+ Defaults to hpd=1.
+
+- hpd_delay=<int> - How long to wait for the hdmi HPD signal in milliseconds
+ When the monitor and the board power up at the same time, it may take some
+ time for the monitor to assert the HPD signal. This configures how long to
+ wait for the HPD signal before assuming no cable is connected.
+ Defaults to hpd_delay=500.
+
+- edid=[0|1] - Enable use of DDC + EDID to get monitor info
+ 0: Disabled.
+ 1: Enabled. If valid EDID info was read from the monitor the EDID info will
+ overrides the xres, yres and refresh from the video-mode env. variable.
+ Defaults to edid=1.
+
+For example to always use the hdmi connector, even if no cable is inserted,
+using edid info when available and otherwise initalizing it at 1024x768@60Hz,
+use: "setenv video-mode sunxi:1024x768-24@60,monitor=dvi,hpd=0,edid=1".
diff --git a/doc/README.x86 b/doc/README.x86
new file mode 100644
index 0000000000..7df8cc516a
--- /dev/null
+++ b/doc/README.x86
@@ -0,0 +1,177 @@
+#
+# Copyright (C) 2014, Simon Glass <sjg@chromium.org>
+# Copyright (C) 2014, Bin Meng <bmeng.cn@gmail.com>
+#
+# SPDX-License-Identifier: GPL-2.0+
+#
+
+U-Boot on x86
+=============
+
+This document describes the information about U-Boot running on x86 targets,
+including supported boards, build instructions, todo list, etc.
+
+Status
+------
+U-Boot supports running as a coreboot [1] payload on x86. So far only Link
+(Chromebook Pixel) has been tested, but it should work with minimal adjustments
+on other x86 boards since coreboot deals with most of the low-level details.
+
+U-Boot also supports booting directly from x86 reset vector without coreboot,
+aka raw support or bare support. Currently Link and Intel Crown Bay board
+support running U-Boot 'bare metal'.
+
+As for loading OS, U-Boot supports directly booting a 32-bit or 64-bit Linux
+kernel as part of a FIT image. It also supports a compressed zImage.
+
+Build Instructions
+------------------
+Building U-Boot as a coreboot payload is just like building U-Boot for targets
+on other architectures, like below:
+
+$ make coreboot-x86_defconfig
+$ make all
+
+Note this default configuration will build a U-Boot payload for the Link board.
+To build a coreboot payload against another board, you can change the build
+configuration during the 'make menuconfig' process.
+
+x86 architecture --->
+ ...
+ (chromebook_link) Board configuration file
+ (chromebook_link) Board Device Tree Source (dts) file
+ (0x19200000) Board specific Cache-As-RAM (CAR) address
+ (0x4000) Board specific Cache-As-RAM (CAR) size
+
+Change the 'Board configuration file' and 'Board Device Tree Source (dts) file'
+to point to a new board. You can also change the Cache-As-RAM (CAR) related
+settings here if the default values do not fit your new board.
+
+Building ROM version of U-Boot (hereafter referred to as u-boot.rom) is a
+little bit tricky, as generally it requires several binary blobs which are not
+shipped in the U-Boot source tree. Due to this reason, the u-boot.rom build is
+not turned on by default in the U-Boot source tree. Firstly, you need turn it
+on by uncommenting the following line in the main U-Boot Makefile:
+
+# ALL-$(CONFIG_X86_RESET_VECTOR) += u-boot.rom
+
+Link-specific instructions:
+
+First, you need the following binary blobs:
+
+* descriptor.bin - Intel flash descriptor
+* me.bin - Intel Management Engine
+* mrc.bin - Memory Reference Code, which sets up SDRAM
+* video ROM - sets up the display
+
+You can get these binary blobs by:
+
+$ git clone http://review.coreboot.org/p/blobs.git
+$ cd blobs
+
+Find the following files:
+
+* ./mainboard/google/link/descriptor.bin
+* ./mainboard/google/link/me.bin
+* ./northbridge/intel/sandybridge/systemagent-ivybridge.bin
+
+The 3rd one should be renamed to mrc.bin.
+As for the video ROM, you can get it here [2].
+Make sure all these binary blobs are put in the board directory.
+
+Now you can build U-Boot and obtain u-boot.rom:
+
+$ make chromebook_link_defconfig
+$ make all
+
+Intel Crown Bay specific instructions:
+
+U-Boot support of Intel Crown Bay board [3] relies on a binary blob called
+Firmware Support Package [4] to perform all the necessary initialization steps
+as documented in the BIOS Writer Guide, including initialization of the CPU,
+memory controller, chipset and certain bus interfaces.
+
+Download the Intel FSP for Atom E6xx series and Platform Controller Hub EG20T,
+install it on your host and locate the FSP binary blob. Note this platform
+also requires a Chipset Micro Code (CMC) state machine binary to be present in
+the SPI flash where u-boot.rom resides, and this CMC binary blob can be found
+in this FSP package too.
+
+* ./FSP/QUEENSBAY_FSP_GOLD_001_20-DECEMBER-2013.fd
+* ./Microcode/C0_22211.BIN
+
+Rename the first one to fsp.bin and second one to cmc.bin and put them in the
+board directory.
+
+Now you can build U-Boot and obtain u-boot.rom
+
+$ make crownbay_defconfig
+$ make all
+
+Test with coreboot
+------------------
+For testing U-Boot as the coreboot payload, there are things that need be paid
+attention to. coreboot supports loading an ELF executable and a 32-bit plain
+binary, as well as other supported payloads. With the default configuration,
+U-Boot is set up to use a separate Device Tree Blob (dtb). As of today, the
+generated u-boot-dtb.bin needs to be packaged by the cbfstool utility (a tool
+provided by coreboot) manually as coreboot's 'make menuconfig' does not provide
+this capability yet. The command is as follows:
+
+# in the coreboot root directory
+$ ./build/util/cbfstool/cbfstool build/coreboot.rom add-flat-binary \
+ -f u-boot-dtb.bin -n fallback/payload -c lzma -l 0x1110000 -e 0x1110015
+
+Make sure 0x1110000 matches CONFIG_SYS_TEXT_BASE and 0x1110015 matches the
+symbol address of _start (in arch/x86/cpu/start.S).
+
+If you want to use ELF as the coreboot payload, change U-Boot configuration to
+use CONFIG_OF_EMBED.
+
+CPU Microcode
+-------------
+Modern CPU usually requires a special bit stream called microcode [5] to be
+loaded on the processor after power up in order to function properly. U-Boot
+has already integrated these as hex dumps in the source tree.
+
+Driver Model
+------------
+x86 has been converted to use driver model for serial and GPIO.
+
+Device Tree
+-----------
+x86 uses device tree to configure the board thus requires CONFIG_OF_CONTROL to
+be turned on. Not every device on the board is configured via device tree, but
+more and more devices will be added as time goes by. Check out the directory
+arch/x86/dts/ for these device tree source files.
+
+Useful Commands
+---------------
+
+In keeping with the U-Boot philosophy of providing functions to check and
+adjust internal settings, there are several x86-specific commands that may be
+useful:
+
+hob - Display information about Firmware Support Package (FSP) Hand-off
+ Block. This is only available on platforms which use FSP, mostly
+ Atom.
+iod - Display I/O memory
+iow - Write I/O memory
+mtrr - List and set the Memory Type Range Registers (MTRR). These are used to
+ tell the CPU whether memory is cacheable and if so the cache write
+ mode to use. U-Boot sets up some reasonable values but you can
+ adjust then with this command.
+
+TODO List
+---------
+- Audio
+- Chrome OS verified boot
+- SMI and ACPI support, to provide platform info and facilities to Linux
+
+References
+----------
+[1] http://www.coreboot.org
+[2] http://www.coreboot.org/~stepan/pci8086,0166.rom
+[3] http://www.intel.com/content/www/us/en/embedded/design-tools/evaluation-platforms/atom-e660-eg20t-development-kit.html
+[4] http://www.intel.com/fsp
+[5] http://en.wikipedia.org/wiki/Microcode
diff --git a/doc/SPI/README.altera_spi b/doc/SPI/README.altera_spi
new file mode 100644
index 0000000000..b07449f80d
--- /dev/null
+++ b/doc/SPI/README.altera_spi
@@ -0,0 +1,6 @@
+SoCFPGA EPCS/EPCQx1 mini howto:
+- Instantiate EPCS/EPCQx1 Serial flash controller in QSys and rebuild
+- The controller base address is the "Base" in QSys + 0x400
+- Set MSEL[4:0]=10010 (AS Standard)
+- Load the bitstream into FPGA, enable bridges
+- Only then will the driver work
diff --git a/doc/device-tree-bindings/ata/intel-sata.txt b/doc/device-tree-bindings/ata/intel-sata.txt
new file mode 100644
index 0000000000..5e4da832a3
--- /dev/null
+++ b/doc/device-tree-bindings/ata/intel-sata.txt
@@ -0,0 +1,26 @@
+Intel Pantherpoint SATA Device Binding
+======================================
+
+The device tree node which describes the operation of the Intel Pantherpoint
+SATA device is as follows:
+
+Required properties :
+- compatible = "intel,pantherpoint-ahci"
+- intel,sata-mode : string, one of:
+ "ahci" : Use AHCI mode (default)
+ "combined" : Use combined IDE + legacy mode
+ "plain-ide" : Use plain IDE mode
+- intel,sata-port-map : Which SATA ports are enabled, bit 0=enable first port,
+ bit 1=enable second port, etc.
+- intel,sata-port0-gen3-tx : Value for the IOBP_SP0G3IR register
+- intel,sata-port1-gen3-tx : Value for the IOBP_SP1G3IR register
+
+Example
+-------
+
+sata {
+ compatible = "intel,pantherpoint-ahci";
+ intel,sata-mode = "ahci";
+ intel,sata-port-map = <1>;
+ intel,sata-port0-gen3-tx = <0x00880a7f>;
+};
diff --git a/doc/device-tree-bindings/input/cros-ec-keyb.txt b/doc/device-tree-bindings/input/cros-ec-keyb.txt
index 3118276078..0f6355ce39 100644
--- a/doc/device-tree-bindings/input/cros-ec-keyb.txt
+++ b/doc/device-tree-bindings/input/cros-ec-keyb.txt
@@ -1,45 +1,38 @@
-CROS_EC Keyboard
+ChromeOS EC Keyboard
-The CROS_EC (Matrix Keyboard Protocol) allows communcation with a secondary
-micro used for keyboard, and possible other features.
+Google's ChromeOS EC Keyboard is a simple matrix keyboard implemented on
+a separate EC (Embedded Controller) device. It provides a message for reading
+key scans from the EC. These are then converted into keycodes for processing
+by the kernel.
-The CROS_EC keyboard uses this protocol to receive key scans and produce input
-in U-Boot.
+This binding is based on matrix-keymap.txt and extends/modifies it as follows:
-Required properties :
-- compatible : "google,cros-ec-keyb"
-- google,key-rows : Number of key rows
-- google,key-columns : Number of key columns
+Required properties:
+- compatible: "google,cros-ec-keyb"
-Optional properties, in addition to those specified by the shared
-matrix-keyboard bindings:
+Optional properties:
+- google,needs-ghost-filter: True to enable a ghost filter for the matrix
+keyboard. This is recommended if the EC does not have its own logic or
+hardware for this.
-- linux,fn-keymap: a second keymap, same specification as the
- matrix-keyboard-controller spec but to be used when the KEY_FN modifier
- key is pressed.
-- google,repeat-delay-ms : delay in milliseconds before repeat starts
-- google,repeat-rate-ms : delay between each subsequent key press
-- google,ghost-filter : enable ghost filtering for this device
-Example, taken from daisy:
+Example:
cros-ec-keyb {
compatible = "google,cros-ec-keyb";
- google,key-rows = <8>;
- google,key-columns = <13>;
- google,ghost-filter;
- google,repeat-delay-ms = <240>;
- google,repeat-rate-ms = <30>;
+ keypad,num-rows = <8>;
+ keypad,num-columns = <13>;
+ google,needs-ghost-filter;
/*
- * Keymap entries take the form of 0xRRCCKKKK where
- * RR=Row CC=Column KKKK=Key Code
- * The values below are for a US keyboard layout and
- * are taken from the Linux driver. Note that the
- * 102ND key is not used for US keyboards.
- */
+ * Keymap entries take the form of 0xRRCCKKKK where
+ * RR=Row CC=Column KKKK=Key Code
+ * The values below are for a US keyboard layout and
+ * are taken from the Linux driver. Note that the
+ * 102ND key is not used for US keyboards.
+ */
linux,keymap = <
/* CAPSLCK F1 B F10 */
- 0x0001003a 0x0002003c 0x00030030 0x00040044
+ 0x0001003a 0x0002003b 0x00030030 0x00040044
/* N = R_ALT ESC */
0x00060031 0x0008000d 0x000a0064 0x01010001
/* F4 G F7 H */
diff --git a/doc/device-tree-bindings/misc/intel-lpc.txt b/doc/device-tree-bindings/misc/intel-lpc.txt
new file mode 100644
index 0000000000..ba6ca9dbc7
--- /dev/null
+++ b/doc/device-tree-bindings/misc/intel-lpc.txt
@@ -0,0 +1,64 @@
+Intel LPC Device Binding
+========================
+
+The device tree node which describes the operation of the Intel Low Pin
+Count device is as follows:
+
+Required properties :
+- compatible = "intel,lpc"
+- intel,alt-gp-smi-enable : Enable SMI sources. This cell is written to the
+ ALT_GP_SMI_EN register
+- intel,gen-dec : Specifies the values for the gen-dec registers. Up to four
+ cell pairs can be provided - the first of each pair is the base address and
+ the second is the size. These are written into the GENx_DEC registers of
+ the LPC device
+- intel,gpi-routing : Specifies the GPI routing. There are 16 cells, valid
+ values are:
+ 0 No effect (default)
+ 1 SMI# (if corresponding ALT_GPI_SMI_EN bit is also set)
+ 2 SCI (if corresponding GPIO_EN bit is also set)
+- intel,pirq-routing : Speciffies the routing IRQ number for each of PIRQA-H,
+ one cell for each.
+ 0x00 - 0000 = Reserved
+ 0x01 - 0001 = Reserved
+ 0x02 - 0010 = Reserved
+ 0x03 - 0011 = IRQ3
+ 0x04 - 0100 = IRQ4
+ 0x05 - 0101 = IRQ5
+ 0x06 - 0110 = IRQ6
+ 0x07 - 0111 = IRQ7
+ 0x08 - 1000 = Reserved
+ 0x09 - 1001 = IRQ9
+ 0x0A - 1010 = IRQ10
+ 0x0B - 1011 = IRQ11
+ 0x0C - 1100 = IRQ12
+ 0x0D - 1101 = Reserved
+ 0x0E - 1110 = IRQ14
+ 0x0F - 1111 = IRQ15
+ PIRQ[n]_ROUT[7] - PIRQ Routing Control
+ 0x80 - The PIRQ is not routed.
+
+
+Example
+-------
+
+lpc {
+ compatible = "intel,lpc";
+ #address-cells = <1>;
+ #size-cells = <1>;
+ intel,gen-dec = <0x800 0xfc 0x900 0xfc>;
+
+ intel,pirq-routing = <0x8b 0x8a 0x8b 0x8b
+ 0x80 0x80 0x80 0x80>;
+ /*
+ * GPI routing
+ * 0 No effect (default)
+ * 1 SMI# (if corresponding ALT_GPI_SMI_EN bit is
+ * also set)
+ * 2 SCI (if corresponding GPIO_EN bit is also set)
+ */
+ intel,gpi-routing = <0 0 0 0 0 0 0 2
+ 1 0 0 0 0 0 0 0>;
+ /* Enable EC SMI source */
+ intel,alt-gp-smi-enable = <0x0100>;
+};
diff --git a/doc/device-tree-bindings/video/intel-gma.txt b/doc/device-tree-bindings/video/intel-gma.txt
new file mode 100644
index 0000000000..914be4fedd
--- /dev/null
+++ b/doc/device-tree-bindings/video/intel-gma.txt
@@ -0,0 +1,40 @@
+Intel GMA Bindings
+==================
+
+This is the Intel Graphics Media Accelerator. This binding supports selection
+of display parameters only.
+
+
+Required properties:
+ - compatible : "intel,gma";
+
+Optional properties:
+ - intel,dp-hotplug : values for digital port hotplug, one cell per value for
+ ports B, C and D
+ - intel,panel-port-select : output port to use: 0=LVDS 1=DP_B 2=DP_C 3=DP_D
+ - intel,panel-power-cycle-delay : T4 time sequence (6 = 500ms)
+
+ The following delays are in units of 0.1ms:
+ - intel,panel-power-up-delay : T1+T2 time sequence
+ - intel,panel-power-down-delay : T3 time sequence
+ - intel,panel-power-backlight-on-delay : T5 time sequence
+ - intel,panel-power-backlight-off-delay : Tx time sequence
+
+ - intel,cpu-backlight : Value for CPU Backlight PWM
+ - intel,pch-backlight : Value for PCH Backlight PWM
+
+Example
+-------
+
+gma {
+ compatible = "intel,gma";
+ intel,dp_hotplug = <0 0 0x06>;
+ intel,panel-port-select = <1>;
+ intel,panel-power-cycle-delay = <6>;
+ intel,panel-power-up-delay = <2000>;
+ intel,panel-power-down-delay = <500>;
+ intel,panel-power-backlight-on-delay = <2000>;
+ intel,panel-power-backlight-off-delay = <2000>;
+ intel,cpu-backlight = <0x00000200>;
+ intel,pch-backlight = <0x04000000>;
+};
diff --git a/doc/driver-model/README.txt b/doc/driver-model/README.txt
index 0278dda4d7..eafa825ab4 100644
--- a/doc/driver-model/README.txt
+++ b/doc/driver-model/README.txt
@@ -36,9 +36,9 @@ How to try it
Build U-Boot sandbox and run it:
- make sandbox_config
+ make sandbox_defconfig
make
- ./u-boot
+ ./u-boot -d u-boot.dtb
(type 'reset' to exit U-Boot)
@@ -750,19 +750,43 @@ device pointers, but this is not currently implemented (the root device
pointer is saved but not made available through the driver model API).
-Things to punt for later
-------------------------
+SPL Support
+-----------
+
+Driver model can operate in SPL. Its efficient implementation and small code
+size provide for a small overhead which is acceptable for all but the most
+constrained systems.
+
+To enable driver model in SPL, define CONFIG_SPL_DM. You might want to
+consider the following option also. See the main README for more details.
+
+ - CONFIG_SYS_MALLOC_SIMPLE
+ - CONFIG_DM_WARN
+ - CONFIG_DM_DEVICE_REMOVE
+ - CONFIG_DM_STDIO
-- SPL support - this will have to be present before many drivers can be
-converted, but it seems like we can add it once we are happy with the
-core implementation.
-That is not to say that no thinking has gone into this - in fact there
-is quite a lot there. However, getting these right is non-trivial and
-there is a high cost associated with going down the wrong path.
+Enabling Driver Model
+---------------------
-For SPL, it may be possible to fit in a simplified driver model with only
-bind and probe methods, to reduce size.
+Driver model is being brought into U-Boot gradually. As each subsystems gets
+support, a uclass is created and a CONFIG to enable use of driver model for
+that subsystem.
+
+For example CONFIG_DM_SERIAL enables driver model for serial. With that
+defined, the old serial support is not enabled, and your serial driver must
+conform to driver model. With that undefined, the old serial support is
+enabled and driver model is not available for serial. This means that when
+you convert a driver, you must either convert all its boards, or provide for
+the driver to be compiled both with and without driver model (generally this
+is not very hard).
+
+See the main README for full details of the available driver model CONFIG
+options.
+
+
+Things to punt for later
+------------------------
Uclasses are statically numbered at compile time. It would be possible to
change this to dynamic numbering, but then we would require some sort of
diff --git a/doc/git-mailrc b/doc/git-mailrc
index ad22763960..d90793a6a6 100644
--- a/doc/git-mailrc
+++ b/doc/git-mailrc
@@ -14,16 +14,20 @@ alias aaribaud Albert Aribaud <albert.u.boot@aribaud.net>
alias abiessmann Andreas Bießmann <andreas.devel@googlemail.com>
alias afleming Andy Fleming <afleming@gmail.com>
alias ag Anatolij Gustschin <agust@denx.de>
+alias alisonwang Alison Wang <alison.wang@freescale.com>
+alias angelo_ts Angelo Dureghello <angelo@sysam.it>
+alias danielschwierzeck Daniel Schwierzeck <daniel.schwierzeck@gmail.com>
alias galak Kumar Gala <galak@kernel.crashing.org>
alias gruss Graeme Russ <graeme.russ@gmail.com>
alias hs Heiko Schocher <hs@denx.de>
alias ijc Ian Campbell <ijc+uboot@hellion.org.uk>
alias iwamatsu Nobuhiro Iwamatsu <iwamatsu@nigauri.org>
-alias jagan Jagannadha Sutradharudu Teki <jagannadh.teki@gmail.com>
+alias jagan Jagannadha Sutradharudu Teki <jagannadh.teki@gmail.com>
alias jasonjin Jason Jin <jason.jin@freescale.com>
alias jhersh Joe Hershberger <joe.hershberger@gmail.com>
alias jwrdegoede Hans de Goede <hdegoede@redhat.com>
alias kimphill Kim Phillips <kim.phillips@freescale.com>
+alias luka Luka Perkov <luka.perkov@sartura.hr>
alias lukma Lukasz Majewski <l.majewski@samsung.com>
alias macpaul Macpaul Lin <macpaul@andestech.com>
alias marex Marek Vasut <marex@denx.de>
@@ -53,7 +57,7 @@ alias arm uboot, aaribaud
alias at91 uboot, abiessmann
alias davinci ti
alias imx uboot, sbabic
-alias kirkwood uboot, prafulla
+alias kirkwood uboot, prafulla, luka
alias omap ti
alias pxa uboot, marex
alias rmobile uboot, iwamatsu
@@ -72,13 +76,13 @@ alias avr32 uboot, abiessmann
alias bfin uboot, vapier, sonic
alias blackfin bfin
-alias m68k uboot, jasonjin
+alias m68k uboot, alisonwang, angelo_ts
alias coldfire m68k
alias microblaze uboot, monstr
alias mb microblaze
-alias mips uboot, Shinya Kuribayashi <skuribay@pobox.com>
+alias mips uboot, danielschwierzeck
alias nds32 uboot, macpaul
@@ -118,7 +122,8 @@ alias kconfig uboot, masahiro
alias mmc uboot, panto
alias nand uboot, scottwood
alias net uboot, jhersh
-alias spi uboot, jagan
+alias spi uboot, jagan
+alias ubi uboot, hs
alias usb uboot, marex
alias video uboot, ag
alias patman uboot, sjg
diff --git a/doc/mkimage.1 b/doc/mkimage.1
index 14374da88a..b48f70bb3c 100644
--- a/doc/mkimage.1
+++ b/doc/mkimage.1
@@ -115,7 +115,7 @@ FIT image.
.TP
.BI "\-F"
Indicates that an existing FIT image should be modified. No dtc
-compilation is performed and the -f flag should not be given.
+compilation is performed and the \-f flag should not be given.
This can be used to sign images with additional keys after initial image
creation.
@@ -163,7 +163,8 @@ Create FIT image with compressed kernel and sign it with keys in the
skipping those for which keys cannot be found. Also add a comment.
.nf
.B mkimage -f kernel.its -k /public/signing-keys -K u-boot.dtb \\\\
--c "Kernel 3.8 image for production devices" kernel.itb
+.br
+.B -c "Kernel 3.8 image for production devices" kernel.itb
.fi
.P
@@ -173,7 +174,8 @@ with keys that are available in the new directory. Images that request signing
with unavailable keys are skipped.
.nf
.B mkimage -F -k /secret/signing-keys -K u-boot.dtb \\\\
--c "Kernel 3.8 image for production devices" kernel.itb
+.br
+.B -c "Kernel 3.8 image for production devices" kernel.itb
.fi
.SH HOMEPAGE