u-boot/doc/README.memory-test

1 The most frequent cause of problems when porting U-Boot to new
8 U-Boot implements 3 different approaches to perform memory tests:
12    This function is supposed to be used in each and every U-Boot port
14    memory banks on this piece of hardware.  The code is supposed to be
16    little known and generally underrated fact that this code will also
19    each and every port of U-Boot.
23    This is probably the best known memory test utility in U-Boot.
29    - It is terribly slow.  Running "mtest" on the whole system RAM
33    - It is difficult to configure, and to use.  And any errors here
36      purposes, like exception code, U-Boot code and data, stack,
41    - It is not easy to configure and use, and a large number of
43      test basically the whole system RAM, with only exempting the
44      areas used by U-Boot itself - on most systems these are the areas
46      system memory) and for U-Boot (code, data, etc. - see above;
54    Because of these issues, the "mtest" command is considered depre-
55    cated.  It should not be enabled in most normal ports of U-Boot,
60    POST (Power-On Self Test) sub-system, see "post/drivers/memory.c".
64    enable this test which is generic and should work on all archi-
77 but when performing back-to-back data transfers in burst mode.  Such
80 aware of any freely available code that implements a generic, and
84 compile a Linux kernel on the system) - this will cause enough context
86 controller), varying RAM use, etc. to trigger any weak spots in this
90 memory problems on a specific board.  The code is pretty much board
95 Note 2: Ironically enough, the "test_burst" did not catch any RAM
96 errors, not a single one ever.  The problems this code was supposed
97 to catch did not happen when accessing the RAM, but when reading from