summaryrefslogtreecommitdiff
path: root/doc
diff options
context:
space:
mode:
Diffstat (limited to 'doc')
-rw-r--r--doc/README.commands18
-rw-r--r--doc/README.displaying-bmps27
-rw-r--r--doc/README.falcon209
-rw-r--r--doc/README.memory-test98
-rw-r--r--doc/README.ns9750dev36
-rw-r--r--doc/README.scrapyard163
-rw-r--r--doc/README.silent4
-rw-r--r--doc/SPL/README.am335x-network92
-rw-r--r--doc/driver-model/UDM-pci.txt4
-rw-r--r--doc/driver-model/UDM-serial.txt2
-rw-r--r--doc/driver-model/UDM-watchdog.txt5
-rw-r--r--doc/feature-removal-schedule.txt17
-rw-r--r--doc/git-mailrc3
13 files changed, 540 insertions, 138 deletions
diff --git a/doc/README.commands b/doc/README.commands
index 923418b1a45..9eb367104fd 100644
--- a/doc/README.commands
+++ b/doc/README.commands
@@ -15,24 +15,22 @@ help: Long description. This is a string
**** Behind the scene ******
-The structure created is named with a special prefix (__u_boot_list_cmd_)
-and placed by the linker in a special section.
+The structure created is named with a special prefix and placed by
+the linker in a special section using the linker lists mechanism
+(see include/linker_lists.h)
This makes it possible for the final link to extract all commands
compiled into any object code and construct a static array so the
-command can be found in an array starting at _u_boot_list_cmd__start.
+command array can be iterated over using the linker lists macros.
-To ensure that the linker does not discard these symbols when linking
-full U-Boot we generate a list of all the commands we have built (based
-on the sections mentioned above) and use that to force the linker to
-first enter the symbol as undefined in the output object so that there
-is then a need for the symbol to be kept (this is the UNDEF_SYM logic in
-the Makefile).
+The linker lists feature ensures that the linker does not discard
+these symbols when linking full U-Boot even though they are not
+referenced in the source code as such.
If a new board is defined do not forget to define the command section
by writing in u-boot.lds ($(TOPDIR)/board/boardname/u-boot.lds) these
3 lines:
.u_boot_list : {
- #include "u-boot.lst";
+ KEEP(*(SORT(.u_boot_list*)));
}
diff --git a/doc/README.displaying-bmps b/doc/README.displaying-bmps
new file mode 100644
index 00000000000..331154166d9
--- /dev/null
+++ b/doc/README.displaying-bmps
@@ -0,0 +1,27 @@
+If you are experiencing hangups/data-aborts when trying to display a BMP image,
+the following might be relevant to your situation...
+
+Some architectures cannot handle unaligned memory accesses, and an attempt to
+perform one will lead to a data abort. On such architectures it is necessary to
+make sure all data is properly aligned, and in many situations simply choosing
+a 32 bit aligned address is enough to ensure proper alignment. This is not
+always the case when dealing with data that has an internal layout such as a
+BMP image:
+
+BMP images have a header that starts with 2 byte-size fields followed by mostly
+32 bit fields. The packed struct that represents this header can be seen below:
+
+typedef struct bmp_header {
+ /* Header */
+ char signature[2];
+ __u32 file_size;
+ __u32 reserved;
+ __u32 data_offset;
+ ... etc
+} __attribute__ ((packed)) bmp_header_t;
+
+When placed in an aligned address such as 0x80a00000, char signature offsets
+the __u32 fields into unaligned addresses (in our example 0x80a00002,
+0x80a00006, and so on...). When these fields are accessed by U-Boot, a 32 bit
+access is generated at a non-32-bit-aligned address, causing a data abort.
+The proper alignment for BMP images is therefore: 32-bit-aligned-address + 2.
diff --git a/doc/README.falcon b/doc/README.falcon
new file mode 100644
index 00000000000..93e855d20ea
--- /dev/null
+++ b/doc/README.falcon
@@ -0,0 +1,209 @@
+U-Boot Falcon Mode
+====================
+
+Introduction
+------------
+
+This document provides an overview of how to add support for Falcon Mode
+to a board.
+
+Falcon Mode is introduced to speed up the booting process, allowing
+to boot a Linux kernel (or whatever image) without a full blown U-Boot.
+
+Falcon Mode relies on the SPL framework. In fact, to make booting faster,
+U-Boot is split into two parts: the SPL (Secondary Program Loader) and U-Boot
+image. In most implementations, SPL is used to start U-Boot when booting from
+a mass storage, such as NAND or SD-Card. SPL has now support for other media,
+and can generally be seen as a way to start an image performing the minimum
+required initialization. SPL mainly initializes the RAM controller, and then
+copies U-Boot image into the memory.
+
+The Falcon Mode extends this way allowing to start the Linux kernel directly
+from SPL. A new command is added to U-Boot to prepare the parameters that SPL
+must pass to the kernel, using ATAGS or Device Tree.
+
+In normal mode, these parameters are generated each time before
+loading the kernel, passing to Linux the address in memory where
+the parameters can be read.
+With Falcon Mode, this snapshot can be saved into persistent storage and SPL is
+informed to load it before running the kernel.
+
+To boot the kernel, these steps under a Falcon-aware U-Boot are required:
+
+1. Boot the board into U-Boot.
+Use the "spl export" command to generate the kernel parameters area or the DT.
+U-Boot runs as when it boots the kernel, but stops before passing the control
+to the kernel.
+
+2. Save the prepared snapshot into persistent media.
+The address where to save it must be configured into board configuration
+file (CONFIG_CMD_SPL_NAND_OFS for NAND).
+
+3. Boot the board into Falcon Mode. SPL will load the kernel and copy
+the parameters which are saved in the persistent area to the required address.
+
+It is required to implement a custom mechanism to select if SPL loads U-Boot
+or another image.
+
+The value of a GPIO is a simple way to operate the selection, as well as
+reading a character from the SPL console if CONFIG_SPL_CONSOLE is set.
+
+Falcon Mode is generally activated by setting CONFIG_SPL_OS_BOOT. This tells
+SPL that U-Boot is not the only available image that SPL is able to start.
+
+Configuration
+----------------------------
+CONFIG_CMD_SPL Enable the "spl export" command.
+ The command "spl export" is then available in U-Boot
+ mode
+CONFIG_SYS_SPL_ARGS_ADDR Address in RAM where the parameters must be
+ copied by SPL.
+ In most cases, it is <start_of_ram> + 0x100
+
+CONFIG_SYS_NAND_SPL_KERNEL_OFFS Offset in NAND where the kernel is stored
+
+CONFIG_CMD_SPL_NAND_OFS Offset in NAND where the parameters area was saved.
+
+CONFIG_CMD_SPL_WRITE_SIZE Size of the parameters area to be copied
+
+CONFIG_SPL_OS_BOOT Activate Falcon Mode.
+
+Function that a board must implement
+------------------------------------
+
+void spl_board_prepare_for_linux(void) : optional
+ Called from SPL before starting the kernel
+
+spl_start_uboot() : required
+ Returns "0" if SPL should start the kernel, "1" if U-Boot
+ must be started.
+
+
+Using spl command
+-----------------
+
+spl - SPL configuration
+
+Usage:
+
+spl export <img=atags|fdt> [kernel_addr] [initrd_addr] [fdt_addr ]
+
+img : "atags" or "fdt"
+kernel_addr : kernel is loaded as part of the boot process, but it is not started.
+ This is the address where a kernel image is stored.
+initrd_addr : Address of initial ramdisk
+ can be set to "-" if fdt_addr without initrd_addr is used
+fdt_addr : in case of fdt, the address of the device tree.
+
+The spl export command does not write to a storage media. The user is
+responsible to transfer the gathered information (assembled ATAGS list
+or prepared FDT) from temporary storage in RAM into persistant storage
+after each run of 'spl export'. Unfortunately the position of temporary
+storage can not be predicted nor provided at commandline, it depends
+highly on your system setup and your provided data (ATAGS or FDT).
+However at the end of an succesful 'spl export' run it will print the
+RAM address of temporary storage.
+Now the user have to save the generated BLOB from that printed address
+to the pre-defined address in persistent storage
+(CONFIG_CMD_SPL_NAND_OFS in case of NAND).
+The following example shows how to prepare the data for Falcon Mode on
+twister board with ATAGS BLOB.
+
+The "spl export" command is prepared to work with ATAGS and FDT. However,
+using FDT is at the moment untested. The ppc port (see a3m071 example
+later) prepares the fdt blob with the fdt command instead.
+
+
+Usage on the twister board:
+--------------------------------
+
+Using mtd names with the following (default) configuration
+for mtdparts:
+
+device nand0 <omap2-nand.0>, # parts = 9
+ #: name size offset mask_flags
+ 0: MLO 0x00080000 0x00000000 0
+ 1: u-boot 0x00100000 0x00080000 0
+ 2: env1 0x00040000 0x00180000 0
+ 3: env2 0x00040000 0x001c0000 0
+ 4: kernel 0x00600000 0x00200000 0
+ 5: bootparms 0x00040000 0x00800000 0
+ 6: splashimg 0x00200000 0x00840000 0
+ 7: mini 0x02800000 0x00a40000 0
+ 8: rootfs 0x1cdc0000 0x03240000 0
+
+
+twister => nand read 82000000 kernel
+
+NAND read: device 0 offset 0x200000, size 0x600000
+ 6291456 bytes read: OK
+
+Now the kernel is in RAM at address 0x82000000
+
+twister => spl export atags 0x82000000
+## Booting kernel from Legacy Image at 82000000 ...
+ Image Name: Linux-3.5.0-rc4-14089-gda0b7f4
+ Image Type: ARM Linux Kernel Image (uncompressed)
+ Data Size: 3654808 Bytes = 3.5 MiB
+ Load Address: 80008000
+ Entry Point: 80008000
+ Verifying Checksum ... OK
+ Loading Kernel Image ... OK
+OK
+cmdline subcommand not supported
+bdt subcommand not supported
+Argument image is now in RAM at: 0x80000100
+
+The result can be checked at address 0x80000100:
+
+twister => md 0x80000100
+80000100: 00000005 54410001 00000000 00000000 ......AT........
+80000110: 00000000 00000067 54410009 746f6f72 ....g.....ATroot
+80000120: 65642f3d 666e2f76 77722073 73666e20 =/dev/nfs rw nfs
+
+The parameters generated with this step can be saved into NAND at the offset
+0x800000 (value for twister for CONFIG_CMD_SPL_NAND_OFS)
+
+nand erase.part bootparms
+nand write 0x80000100 bootparms 0x4000
+
+Now the parameters are stored into the NAND flash at the address
+CONFIG_CMD_SPL_NAND_OFS (=0x800000).
+
+Next time, the board can be started into Falcon Mode moving the
+setting the gpio (on twister gpio 55 is used) to kernel mode.
+
+The kernel is loaded directly by the SPL without passing through U-Boot.
+
+Example with FDT: a3m071 board
+-------------------------------
+
+To boot the Linux kernel from the SPL, the DT blob (fdt) needs to get
+prepard/patched first. U-Boot usually inserts some dynamic values into
+the DT binary (blob), e.g. autodetected memory size, MAC addresses,
+clocks speeds etc. To generate this patched DT blob, you can use
+the following command:
+
+1. Load fdt blob to SDRAM:
+=> tftp 1800000 a3m071/a3m071.dtb
+
+2. Set bootargs as desired for Linux booting (e.g. flash_mtd):
+=> run mtdargs addip2 addtty
+
+3. Use "fdt" commands to patch the DT blob:
+=> fdt addr 1800000
+=> fdt boardsetup
+=> fdt chosen
+
+4. Display patched DT blob (optional):
+=> fdt print
+
+5. Save fdt to NOR flash:
+=> erase fc060000 fc07ffff
+=> cp.b 1800000 fc060000 10000
+...
+
+
+Falcon Mode was presented at the RMLL 2012. Slides are available at:
+
+http://schedule2012.rmll.info/IMG/pdf/LSM2012_UbootFalconMode_Babic.pdf
diff --git a/doc/README.memory-test b/doc/README.memory-test
new file mode 100644
index 00000000000..eb60e8d83e7
--- /dev/null
+++ b/doc/README.memory-test
@@ -0,0 +1,98 @@
+The most frequent cause of problems when porting U-Boot to new
+hardware, or when using a sloppy port on some board, is memory errors.
+In most cases these are not caused by failing hardware, but by
+incorrect initialization of the memory controller. So it appears to
+be a good idea to always test if the memory is working correctly,
+before looking for any other potential causes of any problems.
+
+U-Boot implements 3 different approaches to perform memory tests:
+
+1. The get_ram_size() function (see "common/memsize.c").
+
+ This function is supposed to be used in each and every U-Boot port
+ determine the presence and actual size of each of the potential
+ memory banks on this piece of hardware. The code is supposed to be
+ very fast, so running it for each reboot does not hurt. It is a
+ little known and generally underrated fact that this code will also
+ catch 99% of hardware related (i. e. reliably reproducible) memory
+ errors. It is strongly recommended to always use this function, in
+ each and every port of U-Boot.
+
+2. The "mtest" command.
+
+ This is probably the best known memory test utility in U-Boot.
+ Unfortunately, it is also the most problematic, and the most
+ useless one.
+
+ There are a number of serious problems with this command:
+
+ - It is terribly slow. Running "mtest" on the whole system RAM
+ takes a _long_ time before there is any significance in the fact
+ that no errors have been found so far.
+
+ - It is difficult to configure, and to use. And any errors here
+ will reliably crash or hang your system. "mtest" is dumb and has
+ no knowledge about memory ranges that may be in use for other
+ purposes, like exception code, U-Boot code and data, stack,
+ malloc arena, video buffer, log buffer, etc. If you let it, it
+ will happily "test" all such areas, which of course will cause
+ some problems.
+
+ - It is not easy to configure and use, and a large number of
+ systems are seriously misconfigured. The original idea was to
+ test basically the whole system RAM, with only exempting the
+ areas used by U-Boot itself - on most systems these are the areas
+ used for the exception vectors (usually at the very lower end of
+ system memory) and for U-Boot (code, data, etc. - see above;
+ these are usually at the very upper end of system memory). But
+ experience has shown that a very large number of ports use
+ pretty much bogus settings of CONFIG_SYS_MEMTEST_START and
+ CONFIG_SYS_MEMTEST_END; this results in useless tests (because
+ the ranges is too small and/or badly located) or in critical
+ failures (system crashes).
+
+ Because of these issues, the "mtest" command is considered depre-
+ cated. It should not be enabled in most normal ports of U-Boot,
+ especially not in production. If you really need a memory test,
+ then see 1. and 3. above resp. below.
+
+3. The most thorough memory test facility is available as part of the
+ POST (Power-On Self Test) sub-system, see "post/drivers/memory.c".
+
+ If you really need to perform memory tests (for example, because
+ it is mandatory part of your requirement specification), then
+ enable this test which is generic and should work on all archi-
+ tectures.
+
+WARNING:
+
+It should pointed out that _all_ these memory tests have one
+fundamental, unfixable design flaw: they are based on the assumption
+that memory errors can be found by writing to and reading from memory.
+Unfortunately, this is only true for the relatively harmless, usually
+static errors like shorts between data or address lines, unconnected
+pins, etc. All the really nasty errors which will first turn your
+hair gray, only to make you tear it out later, are dynamical errors,
+which usually happen not with simple read or write cycles on the bus,
+but when performing back-to-back data transfers in burst mode. Such
+accesses usually happen only for certain DMA operations, or for heavy
+cache use (instruction fetching, cache flushing). So far I am not
+aware of any freely available code that implements a generic, and
+efficient, memory test like that. The best known test case to stress
+a system like that is to boot Linux with root file system mounted over
+NFS, and then build some larger software package natively (say,
+compile a Linux kernel on the system) - this will cause enough context
+switches, network traffic (and thus DMA transfers from the network
+controller), varying RAM use, etc. to trigger any weak spots in this
+area.
+
+Note: An attempt was made once to implement such a test to catch
+memory problems on a specific board. The code is pretty much board
+specific (for example, it includes setting specific GPIO signals to
+provide triggers for an attached logic analyzer), but you can get an
+idea how it works: see "examples/standalone/test_burst*".
+
+Note 2: Ironically enough, the "test_burst" did not catch any RAM
+errors, not a single one ever. The problems this code was supposed
+to catch did not happen when accessing the RAM, but when reading from
+NOR flash.
diff --git a/doc/README.ns9750dev b/doc/README.ns9750dev
deleted file mode 100644
index 29914406bac..00000000000
--- a/doc/README.ns9750dev
+++ /dev/null
@@ -1,36 +0,0 @@
-U-Boot Port to the NS9750 DevKit from NetSilicon
-
-1 Overview
-2 Board Configuration
-3 Installation
-
-
-1 Overview
-----------
-
-This port supports these NS9750 features.
-
-o one UART
-
-2 Board Configuration
----------------------
-
-Switches:
-SW10: 4
-SW11: 6,7
-SW16: 6,7,8
-SW17-SW20: 1
-SW4: 3, 6
-SW 1: 1
-SW2: 4
-SW3: 3
-SW8: 3 (rotated by 180 degree!!!!)
-
-Serial Console is Port B (bottom right port)
-
-3 Installation
---------------
-
-Have fun,
---
-Markus Pietrek <mpietrek@fsforth.de>
diff --git a/doc/README.scrapyard b/doc/README.scrapyard
index 2b868e65154..189b8839d51 100644
--- a/doc/README.scrapyard
+++ b/doc/README.scrapyard
@@ -9,83 +9,86 @@ maintain a list of such former fellows, so archeologists can check
easily if here is something they might want to dig for...
-Board Arch CPU removed Commit last known maintainer/contact
-=============================================================================
-AMX860 powerpc mpc860 - - Wolfgang Denk <wd@denx.de>
-c2mon powerpc mpc855 - - Wolfgang Denk <wd@denx.de>
-ETX094 powerpc mpc850 - - Wolfgang Denk <wd@denx.de>
-IAD210 powerpc mpc860 - - -
-LANTEC powerpc mpc850 - - Wolfgang Denk <wd@denx.de>
-SCM powerpc mpc8260 - - Wolfgang Grandegger <wg@denx.de>
-SX1 arm arm925t - -
-TQM85xx powerpc MPC85xx d923a5d5 2012-10-04 Stefan Roese <sr@denx.de>
-apollon arm omap24xx 535c74f 2012-09-18 Kyungmin Park <kyungmin.park@samsung.com>
-tb0229 mips mips32 3f3110d 2011-12-12
-rmu powerpc MPC850 fb82fd7 2011-12-07 Wolfgang Denk <wd@denx.de>
-OXC powerpc MPC8240 309a292 2011-12-07
-BAB7xx powerpc MPC740/MPC750 c53043b 2011-12-07 Frank Gottschling <fgottschling@eltec.de>
-xm250 arm pxa c746cdd 2011-25-11
-pleb2 arm pxa b185a1c 2011-25-11
-cradle arm pxa 4e24f8a 2011-25-11 Kyle Harris <kharris@nexus-tech.net>
-cerf250 arm pxa a3f1241 2011-25-11 Prakash Kumar <prakash@embedx.com>
-mpq101 powerpc mpc85xx e877fab 2011-10-23 Alex Dubov <oakad@yahoo.com>
-ixdpg425 arm ixp 0ca8eb7 2011-09-22 Stefan Roese <sr@denx.de>
-ixdp425 arm ixp 0ca8eb7 2011-09-22 Kyle Harris <kharris@nexus-tech.net>
-zylonite arm pxa b66521a 2011-09-05
-shannon arm sa1100 5df092d 2011-09-05 Rolf Offermanns <rof@sysgo.de>
-modnet50 arm arm720t 9c62815 2011-09-05 Thomas Elste <info@elste.org>
-lpc2292sodimm arm arm720t d1a067a 2011-09-05
-lart arm sa1100 3d57573 2011-09-05 Alex Züpke <azu@sysgo.de>
-impa7 arm arm720t c1f8750 2011-09-05 Marius Gröger <mag@sysgo.de>
-gcplus arm sa1100 2c650e2 2011-09-05 George G. Davis <gdavis@mvista.com>
-evb4510 arm arm720t 26e670e 2011-09-05 Curt Brune <curt@cucy.com>
-ep7312 arm arm720t c8f63b4 2011-09-05 Marius Gröger <mag@sysgo.de>
-dnp1110 arm sa1100 fc5e5ce 2011-09-05 Alex Züpke <azu@sysgo.de>
-SMN42 arm arm720t 6aac646 2011-09-05
-at91rm9200dk arm arm920t 1c85752 2011-07-17
-m501sk arm arm920t b1a2bd4 2011-07-17
-kb9202 arm arm920t 5bd3814 2011-07-17
-csb637 arm arm920t d14af08 2011-07-17
-cmc_pu2 arm arm920t 37a9b4d 2011-07-17
-at91cap9adk arm arm926ejs b550834 2011-07-17 Stelian Pop <stelian@popies.net>
-voiceblue arm arm925t 1b793a4 2011-07-17
-smdk2400 arm arm920t ad218a8 2011-07-17 Gary Jennejohn <garyj@denx.de>
-sbc2410x arm arm920t 1f7f0ed 2011-07-17
-netstar arm arm925t 6ea2405 2011-07-17
-mx1fs2 arm arm920t 6962419 2011-07-17
-lpd7a404 arm lh7a40x 957731e 2011-07-17
-edb9301 arm arm920t 716f7ad 2011-07-17
-edb9302 arm arm920t 716f7ad 2011-07-17
-edb9302a arm arm920t 716f7ad 2011-07-17
-edb9307 arm arm920t 716f7ad 2011-07-17
-edb9307a arm arm920t 716f7ad 2011-07-17
-edb9312 arm arm920t 716f7ad 2011-07-17
-edb9315 arm arm920t 716f7ad 2011-07-17
-edb9315a arm arm920t 716f7ad 2011-07-17
-B2 arm s3c44b0 5dcf536 2011-07-16 Andrea Scian <andrea.scian@dave-tech.it>
-armadillo arm arm720t be28857 2011-07-16 Rowel Atienza <rowel@diwalabs.com>
-assabet arm sa1100 c91e90d 2011-07-16 George G. Davis <gdavis@mvista.com>
-trab arm S3C2400 566e5cf 2011-05-01 Gary Jennejohn <garyj@denx.de>
-xsengine ARM PXA2xx 4262a7c 2010-10-20
-wepep250 ARM PXA2xx 7369478 2010-10-20 Peter Figuli <peposh@etc.sk>
-delta ARM PXA2xx 75e2035 2010-10-20
-mp2usb ARM AT91RM2900 ee986e2 2011-01-25 Eric Bénard <eric@eukrea.com>
-barco powerpc MPC8245 afaa27b 2010-11-23 Marc Leeman <marc.leeman@barco.com>
-ERIC powerpc 405GP d9ba451 2010-11-21 Swen Anderson <sand@peppercon.de>
-VoVPN-GW_100MHz powerpc MPC8260 26fe3d2 2010-10-24 Juergen Selent <j.selent@elmeg.de>
-NC650 powerpc MPC852 333d86d 2010-10-19 Wolfgang Denk <wd@denx.de>
-CP850 powerpc MPC852 333d86d 2010-10-19 Wolfgang Denk <wd@denx.de>
-logodl ARM PXA2xx 059e778 2010-10-18 August Hoeraendl <august.hoerandl@gmx.at>
-CCM powerpc MPC860 dff07e1 2010-10-06 Wolfgang Grandegger <wg@denx.de>
-PCU_E powerpc MPC860T 544d97e 2010-10-06 Wolfgang Denk <wd@denx.de>
-spieval powerpc MPC5200 69434e4 2010-09-19
-smmaco4 powerpc MPC5200 9ddc3af 2010-09-19
-HMI10 powerpc MPC823 77efe35 2010-09-19 Wolfgang Denk <wd@denx.de>
-GTH powerpc MPC860 0fe247b 2010-07-17 Thomas Lange <thomas@corelatus.se>
-AmigaOneG3SE 953b7e6 2010-06-23
-suzaku microblaze 4f18060 2009-10-03 Yasushi Shoji <yashi@atmark-techno.com>
-XUPV2P microblaze 8fab49e 2008-12-10 Michal Simek <monstr@monstr.eu>
-MVS1 powerpc MPC823 306620b 2008-08-26 Andre Schwarz <andre.schwarz@matrix-vision.de>
-adsvix ARM PXA27x 7610db1 2008-07-30 Adrian Filipi <adrian.filipi@eurotech.com>
-R5200 ColdFire 48ead7a 2008-03-31 Zachary P. Landau <zachary.landau@labxtechnologies.com>
-CPCI440 powerpc 440GP b568fd2 2007-12-27 Matthias Fuchs <matthias.fuchs@esd-electronics.com>
+Board Arch CPU Commit Removed Last known maintainer/contact
+=================================================================================================
+ns9750dev arm arm926ejs - - Markus Pietrek <mpietrek@fsforth.de>
+AMX860 powerpc mpc860 1b0757e 2012-10-28 Wolfgang Denk <wd@denx.de>
+c2mon powerpc mpc855 1b0757e 2012-10-28 Wolfgang Denk <wd@denx.de>
+ETX094 powerpc mpc850 1b0757e 2012-10-28 Wolfgang Denk <wd@denx.de>
+IAD210 powerpc mpc860 1b0757e 2012-10-28 -
+LANTEC powerpc mpc850 1b0757e 2012-10-28 Wolfgang Denk <wd@denx.de>
+SCM powerpc mpc8260 1b0757e 2012-10-28 Wolfgang Grandegger <wg@denx.de>
+SX1 arm arm925t 53c4154 2012-10-26
+TQM85xx powerpc MPC85xx d923a5d 2012-10-04 Stefan Roese <sr@denx.de>
+apollon arm omap24xx 535c74f 2012-09-18 Kyungmin Park <kyungmin.park@samsung.com>
+tb0229 mips mips32 3f3110d 2011-12-12
+rmu powerpc MPC850 fb82fd7 2011-12-07 Wolfgang Denk <wd@denx.de>
+OXC powerpc MPC8240 309a292 2011-12-07
+BAB7xx powerpc MPC740/MPC750 c53043b 2011-12-07 Frank Gottschling <fgottschling@eltec.de>
+xm250 arm pxa c746cdd 2011-25-11
+pleb2 arm pxa b185a1c 2011-25-11
+cradle arm pxa 4e24f8a 2011-25-11 Kyle Harris <kharris@nexus-tech.net>
+cerf250 arm pxa a3f1241 2011-25-11 Prakash Kumar <prakash@embedx.com>
+mpq101 powerpc mpc85xx e877fab 2011-10-23 Alex Dubov <oakad@yahoo.com>
+ixdpg425 arm ixp 0ca8eb7 2011-09-22 Stefan Roese <sr@denx.de>
+ixdp425 arm ixp 0ca8eb7 2011-09-22 Kyle Harris <kharris@nexus-tech.net>
+zylonite arm pxa b66521a 2011-09-05
+shannon arm sa1100 5df092d 2011-09-05 Rolf Offermanns <rof@sysgo.de>
+modnet50 arm arm720t 9c62815 2011-09-05 Thomas Elste <info@elste.org>
+lpc2292sodimm arm arm720t d1a067a 2011-09-05
+lart arm sa1100 3d57573 2011-09-05 Alex Züpke <azu@sysgo.de>
+impa7 arm arm720t c1f8750 2011-09-05 Marius Gröger <mag@sysgo.de>
+gcplus arm sa1100 2c650e2 2011-09-05 George G. Davis <gdavis@mvista.com>
+evb4510 arm arm720t 26e670e 2011-09-05 Curt Brune <curt@cucy.com>
+ep7312 arm arm720t c8f63b4 2011-09-05 Marius Gröger <mag@sysgo.de>
+dnp1110 arm sa1100 fc5e5ce 2011-09-05 Alex Züpke <azu@sysgo.de>
+SMN42 arm arm720t 6aac646 2011-09-05
+at91rm9200dk arm arm920t 1c85752 2011-07-17
+m501sk arm arm920t b1a2bd4 2011-07-17
+kb9202 arm arm920t 5bd3814 2011-07-17
+csb637 arm arm920t d14af08 2011-07-17
+cmc_pu2 arm arm920t 37a9b4d 2011-07-17
+at91cap9adk arm arm926ejs b550834 2011-07-17 Stelian Pop <stelian@popies.net>
+voiceblue arm arm925t 1b793a4 2011-07-17
+smdk2400 arm arm920t ad218a8 2011-07-17 Gary Jennejohn <garyj@denx.de>
+sbc2410x arm arm920t 1f7f0ed 2011-07-17
+netstar arm arm925t 6ea2405 2011-07-17
+mx1fs2 arm arm920t 6962419 2011-07-17
+lpd7a404 arm lh7a40x 957731e 2011-07-17
+edb9301 arm arm920t 716f7ad 2011-07-17
+edb9302 arm arm920t 716f7ad 2011-07-17
+edb9302a arm arm920t 716f7ad 2011-07-17
+edb9307 arm arm920t 716f7ad 2011-07-17
+edb9307a arm arm920t 716f7ad 2011-07-17
+edb9312 arm arm920t 716f7ad 2011-07-17
+edb9315 arm arm920t 716f7ad 2011-07-17
+edb9315a arm arm920t 716f7ad 2011-07-17
+B2 arm s3c44b0 5dcf536 2011-07-16 Andrea Scian <andrea.scian@dave-tech.it>
+armadillo arm arm720t be28857 2011-07-16 Rowel Atienza <rowel@diwalabs.com>
+assabet arm sa1100 c91e90d 2011-07-16 George G. Davis <gdavis@mvista.com>
+trab arm S3C2400 566e5cf 2011-05-01 Gary Jennejohn <garyj@denx.de>
+xsengine ARM PXA2xx 4262a7c 2010-10-20
+wepep250 ARM PXA2xx 7369478 2010-10-20 Peter Figuli <peposh@etc.sk>
+delta ARM PXA2xx 75e2035 2010-10-20
+mp2usb ARM AT91RM2900 ee986e2 2011-01-25 Eric Bénard <eric@eukrea.com>
+barco powerpc MPC8245 afaa27b 2010-11-23 Marc Leeman <marc.leeman@barco.com>
+ERIC powerpc 405GP d9ba451 2010-11-21 Swen Anderson <sand@peppercon.de>
+VoVPN-GW_100MHz powerpc MPC8260 26fe3d2 2010-10-24 Juergen Selent <j.selent@elmeg.de>
+NC650 powerpc MPC852 333d86d 2010-10-19 Wolfgang Denk <wd@denx.de>
+CP850 powerpc MPC852 333d86d 2010-10-19 Wolfgang Denk <wd@denx.de>
+logodl ARM PXA2xx 059e778 2010-10-18 August Hoeraendl <august.hoerandl@gmx.at>
+CCM powerpc MPC860 dff07e1 2010-10-06 Wolfgang Grandegger <wg@denx.de>
+PCU_E powerpc MPC860T 544d97e 2010-10-06 Wolfgang Denk <wd@denx.de>
+spieval powerpc MPC5200 69434e4 2010-09-19
+smmaco4 powerpc MPC5200 9ddc3af 2010-09-19
+HMI10 powerpc MPC823 77efe35 2010-09-19 Wolfgang Denk <wd@denx.de>
+GTH powerpc MPC860 0fe247b 2010-07-17 Thomas Lange <thomas@corelatus.se>
+AmigaOneG3SE powerpc 74xx_7xx 953b7e6 2010-06-23
+suzaku microblaze - 4f18060 2009-10-03 Yasushi Shoji <yashi@atmark-techno.com>
+XUPV2P microblaze - 8fab49e 2008-12-10 Michal Simek <monstr@monstr.eu>
+MVS1 powerpc MPC823 306620b 2008-08-26 Andre Schwarz <andre.schwarz@matrix-vision.de>
+adsvix ARM PXA27x 7610db1 2008-07-30 Adrian Filipi <adrian.filipi@eurotech.com>
+R5200 ColdFire - 48ead7a 2008-03-31 Zachary P. Landau <zachary.landau@labxtechnologies.com>
+CPCI440 powerpc 440GP b568fd2 2007-12-27 Matthias Fuchs <matthias.fuchs@esd-electronics.com>
+PCIPPC2 powerpc MPC740/MPC750 7c9e89b 2013-02-07 Wolfgang Denk <wd@denx.de>
+PCIPPC6 powerpc MPC740/MPC750 - - Wolfgang Denk <wd@denx.de>
diff --git a/doc/README.silent b/doc/README.silent
index 70202cece97..6d90a0ec403 100644
--- a/doc/README.silent
+++ b/doc/README.silent
@@ -23,4 +23,6 @@ The following actions are taken if "silent" is set at boot time:
- When booting a linux kernel, the "bootargs" are fixed up so that
the argument "console=" will be in the command line, no matter how
- it was set in "bootargs" before.
+ it was set in "bootargs" before. If you don't want the linux command
+ line to be affected, define CONFIG_SILENT_U_BOOT_ONLY in your board
+ config file as well, and this part of the feature will be disabled.
diff --git a/doc/SPL/README.am335x-network b/doc/SPL/README.am335x-network
new file mode 100644
index 00000000000..e5a198f49cc
--- /dev/null
+++ b/doc/SPL/README.am335x-network
@@ -0,0 +1,92 @@
+USING AM335x NETBOOT FEATURE
+
+ Some boards (like TI AM335x based ones) have quite big on-chip RAM and
+have support for booting via network in ROM. The following describes
+how to setup network booting and then optionally use this support to flash
+NAND and bricked (empty) board with only a network cable.
+
+ I. Building the required images
+ 1. You have to enable generic SPL configuration options (see
+docs/README.SPL) as well as CONFIG_SPL_NET_SUPPORT,
+CONFIG_ETH_SUPPORT, CONFIG_SPL_LIBGENERIC_SUPPORT and
+CONFIG_SPL_LIBCOMMON_SUPPORT in your board configuration file to build
+SPL with support for booting over the network. Also you have to enable
+the driver for the NIC used and CONFIG_SPL_BOARD_INIT option if your
+board needs some board-specific initialization (TI AM335x EVM does).
+If you want SPL to use some Vendor Class Identifier (VCI) you can set
+one with CONFIG_SPL_NET_VCI_STRING option. am335x_evm configuration
+comes with support for network booting preconfigured.
+ 2. Define CONFIG_BOOTCOMMAND for your board to load and run debrick
+script after boot:
+#define CONFIG_BOOTCOMMAND \
+ "setenv autoload no; " \
+ "bootp; " \
+ "if tftp 80000000 debrick.scr; then " \
+ "source 80000000; " \
+ "fi"
+(Or create additional board configuration with such option).
+ 3. Build U-Boot as usual
+ $ make <your_board_name>
+ You will need u-boot.img and spl/u-boot.bin images to perform
+network boot. Copy them to u-boot-restore.img and
+u-boot-spl-restore.bin respectively to distinguish this version
+(with automatic restore running) from the main one.
+
+ II. Host configuration.
+ 1. Setup DHCP server (recommended server is ISC DHCPd).
+ - Install DHCP server and setup it to listen on the interface you
+chose to connect to the board (usually configured in
+/etc/default/dhcpd or /etc/default/isc-dhcp-server). Make sure there
+are no other active DHCP servers in the same network segment.
+ - Edit your dhcpd.conf and subnet declaration matching the address
+on the interface. Specify the range of assigned addresses and bootfile
+to use. IMPORTANT! Both RBL and SPL use the image filename provided
+in the BOOTP reply but obviously they need different images (RBL needs
+raw SPL image -- u-boot-spl-restore.bin while SPL needs main U-Boot
+image -- u-boot-restore.img). So you have to configure DHCP server to
+provide different image filenames to RBL and SPL (and possibly another
+one to main U-Boot). This can be done by checking Vendor Class
+Identifier (VCI) set by BOOTP client (RBL sets VCI to "DM814x ROM v1.0"
+and you can set VCI used by SPL with CONFIG_SPL_NET_VCI_STRING option,
+see above).
+ - If you plan to use TFTP server on another machine you have to set
+server-name option to point to it.
+ - Here is sample configuration for ISC DHCPd, assuming the interface
+used to connect to the board is eth0, and it has address 192.168.8.1:
+
+subnet 192.168.8.0 netmask 255.255.255.0 {
+ range dynamic-bootp 192.168.8.100 192.168.8.199;
+
+ if substring (option vendor-class-identifier, 0, 10) = "DM814x ROM" {
+ filename "u-boot-spl-restore.bin";
+ } elsif substring (option vendor-class-identifier, 0, 17) = "AM335x U-Boot SPL" {
+ filename "u-boot-restore.img";
+ } else {
+ filename "uImage";
+ }
+}
+
+ 2. Setup TFTP server.
+ Install TFTP server and put image files to it's root directory
+(likely /tftpboot or /var/lib/tftpboot or /srv/tftp). You will need
+u-boot.img and spl/u-boot-spl-bin files from U-Boot build directory.
+
+ III. Reflashing (debricking) the board.
+ 1. Write debrick script. You will need to write a script that will
+be executed after network boot to perform actual rescue actions. You
+can use usual U-Boot commands from this script: tftp to load additional
+files, nand erase/nand write to erase/write the NAND flash.
+
+ 2. Create script image from your script. From U-Boot build directory:
+
+$ ./tools/mkimage -A arm -O U-Boot -C none -T script -d <your script> debrick.scr
+
+This will create debrick.scr file with your script inside.
+
+ 3. Copy debrick.scr to TFTP root directory. You also need to copy
+there all the files your script tries to load via TFTP. Example script
+loads u-boot.img and MLO. You have to create these files doing regular
+(not restore_flash) build and copy them to tftpboot directory.
+
+ 4. Boot the board from the network, U-Boot will load debrick script
+and run it after boot.
diff --git a/doc/driver-model/UDM-pci.txt b/doc/driver-model/UDM-pci.txt
index b65e9ea73e3..c2cf2d5a626 100644
--- a/doc/driver-model/UDM-pci.txt
+++ b/doc/driver-model/UDM-pci.txt
@@ -240,10 +240,6 @@ III) Analysis of in-tree drivers
----------------
Standard driver, uses indirect functions.
- 8) pcippc2/cpc710_pci.c
- -----------------------
- Standard driver, uses indirect functions, has two busses.
-
9) Marvell/db64360/pci.c
------------------------
Standard driver, uses dword for read/write ops, has two busses.
diff --git a/doc/driver-model/UDM-serial.txt b/doc/driver-model/UDM-serial.txt
index c6a8ab05212..ef71fea2b8c 100644
--- a/doc/driver-model/UDM-serial.txt
+++ b/doc/driver-model/UDM-serial.txt
@@ -86,7 +86,7 @@ III) Analysis of in-tree drivers
7) ns9750_serial.c
------------------
- No support for CONFIG_SERIAL_MULTI. Simple conversion possible.
+ Unmaintained port. Code got removed.
8) opencores_yanu.c
-------------------
diff --git a/doc/driver-model/UDM-watchdog.txt b/doc/driver-model/UDM-watchdog.txt
index 271bd263355..7db328639fe 100644
--- a/doc/driver-model/UDM-watchdog.txt
+++ b/doc/driver-model/UDM-watchdog.txt
@@ -292,11 +292,6 @@ III) Analysis of in-tree drivers
Only function proxy call. Code cleanup needed.
- 45) board/pcippc2/pcippc2.c
- ---------------------------
- The driver is standard HW watchdog. Simple conversion is possible.
-
-
46) board/pcs440ep/pcs440ep.c
-----------------------------
The driver is standard HW watchdog. Simple conversion is possible.
diff --git a/doc/feature-removal-schedule.txt b/doc/feature-removal-schedule.txt
index e04ba2dda5a..d9a0cc267be 100644
--- a/doc/feature-removal-schedule.txt
+++ b/doc/feature-removal-schedule.txt
@@ -7,6 +7,23 @@ file.
---------------------------
+What: Remove CONFIG_CMD_MEMTEST from default list
+When: Release v2013.07
+
+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.
+
+Who: Wolfgang Denk <wd@denx.de>
+
+---------------------------
+
What: Users of the legacy miiphy_* code
When: undetermined
diff --git a/doc/git-mailrc b/doc/git-mailrc
index 6600c150dcf..0f237760419 100644
--- a/doc/git-mailrc
+++ b/doc/git-mailrc
@@ -32,6 +32,7 @@ alias sbabic Stefano Babic <sbabic@denx.de>
alias scottwood Scott Wood <scottwood@freescale.com>
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 vapier Mike Frysinger <vapier@gentoo.org>
alias wd Wolfgang Denk <wd@denx.de>
@@ -57,7 +58,7 @@ alias ti uboot, Tom Rini <trini@ti.com>
alias avr32 uboot, abiessmann
-alias bfin uboot, vapier
+alias bfin uboot, vapier, sonic
alias blackfin bfin
alias m68k uboot, jasonjin