diff options
Diffstat (limited to 'doc')
| -rw-r--r-- | doc/README.memory-test | 98 | ||||
| -rw-r--r-- | doc/README.scrapyard | 2 | ||||
| -rw-r--r-- | doc/README.silent | 4 | ||||
| -rw-r--r-- | doc/driver-model/UDM-pci.txt | 4 | ||||
| -rw-r--r-- | doc/driver-model/UDM-watchdog.txt | 5 | ||||
| -rw-r--r-- | doc/feature-removal-schedule.txt | 17 |
6 files changed, 120 insertions, 10 deletions
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.scrapyard b/doc/README.scrapyard index e9ca96c..189b883 100644 --- a/doc/README.scrapyard +++ b/doc/README.scrapyard @@ -90,3 +90,5 @@ MVS1 powerpc MPC823 306620b 2008-08-26 Andre Schwar 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/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-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 |