diff options
Diffstat (limited to 'doc')
| -rw-r--r-- | doc/README.commands | 18 | ||||
| -rw-r--r-- | doc/README.displaying-bmps | 27 | ||||
| -rw-r--r-- | doc/README.falcon | 209 | ||||
| -rw-r--r-- | doc/README.memory-test | 98 | ||||
| -rw-r--r-- | doc/README.ns9750dev | 36 | ||||
| -rw-r--r-- | doc/README.scrapyard | 163 | ||||
| -rw-r--r-- | doc/README.silent | 4 | ||||
| -rw-r--r-- | doc/SPL/README.am335x-network | 92 | ||||
| -rw-r--r-- | doc/driver-model/UDM-pci.txt | 4 | ||||
| -rw-r--r-- | doc/driver-model/UDM-serial.txt | 2 | ||||
| -rw-r--r-- | doc/driver-model/UDM-watchdog.txt | 5 | ||||
| -rw-r--r-- | doc/feature-removal-schedule.txt | 17 | ||||
| -rw-r--r-- | doc/git-mailrc | 3 |
13 files changed, 540 insertions, 138 deletions
diff --git a/doc/README.commands b/doc/README.commands index 923418b..9eb3671 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 0000000..3311541 --- /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 0000000..93e855d --- /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 0000000..eb60e8d --- /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 2991440..0000000 --- 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 2b868e6..189b883 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 70202ce..6d90a0e 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 0000000..e5a198f --- /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 b65e9ea..c2cf2d5 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 c6a8ab0..ef71fea 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 271bd26..7db3286 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 e04ba2d..d9a0cc2 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 6600c15..0f23776 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 |