u-boot/doc/README.POST

28 2) The results of tests shall be saved so that it will be possible to
56 A new optional module will be added to U-Boot, which will run POST
57 tests and collect their results at boot time. Also, U-Boot will
61 The list of available POST tests will be configured at U-Boot build
62 time. The POST layer will allow the developer to add any custom POST
63 tests. All POST tests will be divided into the following groups:
67      This group will contain those tests that run only once on
72      This group will contain those tests that do not take much
77      This group will contain POST tests that consume much time
82      This group will contain those tests that can be run manually.
90 Also, all tests will be discriminated by the moment they run at.
91 Specifically, the following groups will be singled out:
95      These tests will run immediately after initializing RAM
97      contents. Basically, this group will contain memory tests
102      These tests will run immediately before entering the main
105 The POST layer will also distinguish a special group of tests that
107 layer will automatically detect rebooting and will notify the test
115 The following flags will be defined:
127 The POST layer will export the following interface routines:
131      This routine will run the test (or the group of tests) specified
133      argument is not NULL, the test with this name will be performed,
135      argument) will be executed. This routine will be called at least
137      from board_init_r(). The flags argument will also specify the
143      This routine will be called from board_init_r() and will
148      This routine will print the list of all POST tests that can be
154      This routine will be called from POST tests to log their
155      results. Basically, this routine will print the results to
157      will be identical to the printf() routine.
159 Also, the following board-specific routines will be called from the
164      This routine will return the mode the system is running in
169      This routine will turn off the power supply of the board. It
170      will be called on power-fail booting after running all POST
175      This routine will scan the keyboard to detect if a magic key
181 filled at U-Boot build time. The format of entry in this array will
194      This field will contain a short name of the test, which will be
199      This field will keep a name for identifying the test on manual
205      This field will contain a detailed description of the test,
206      which will be printed on user request. For more information, see
211      This field will contain a combination of the bit flags described
212      above, which will specify the mode the test is running in
219      This field will contain a pointer to the routine that will
220      perform the test, which will take 2 arguments. The first
221      argument will be a pointer to the board info structure, while
222      the second will be a combination of bit flags specifying the
225      the test caused system rebooting (POST_REBOOT). The routine will
230 power-fail booting will be kept in the environment. Namely, the
231 following environment variables will be used: post_poweron,
236 The results of tests will be collected by the POST layer. The POST
237 log will have the following format:
247 Basically, the results of tests will be printed to stderr. This
254 All POST-related code will be #ifdef'ed with the CONFIG_POST macro.
255 This macro will be defined in the config_<board>.h file for those
256 boards that need POST. The CONFIG_POST macro will contain the list of
257 POST tests for the board. The macro will have the format of array
269 A new file, post.h, will be created in the include/ directory. This
270 file will contain common POST declarations and will define a set of
271 macros that will be reused for defining CONFIG_POST. As an example,
282 A new subdirectory will be created in the U-Boot root directory. It
283 will contain the source code of the POST layer and most of POST
284 tests. Each POST test in this directory will be placed into a
285 separate file (it will be needed for building standalone tests). Some
286 POST tests (mainly those for testing peripheral devices) will be
288 way will be used only if the test subtantially uses the driver.
292 The POST framework will allow to develop and run standalone tests. A
293 user-space library will be developed to provide the POST interface
298 A new command, diag, will be added to U-Boot. This command will be
302 More specifically, being run without any arguments, this command will
315 descriptions of the specified tests will be printed:
324 If the first argument to diag is 'run', the specified tests will be
325 executed. If no tests are specified, all available tests will be
328 It will be prohibited to execute tests running in ROM manually. The
329 'diag' command will not display such tests and/or run them.
333 The Linux kernel will be modified to detect power failures and
334 automatically reboot the system in such cases. It will be assumed
337 To perform correct system shutdown, the kernel will register a
339 will run /sbin/reboot using the call_usermodehelper() routine.
340 /sbin/reboot will automatically bring the system down in a secure
341 way. This feature will be configured in/out from the kernel
344 The POST layer of U-Boot will check whether the system runs in
345 power-fail mode. If it does, the system will be powered off after
351 some tests, this will indicate a failure, while for the Watchdog
354 In order to support such tests, the following scheme will be
355 implemented. All the tests that may cause system rebooting will have
358 the POST layer will store an identification number of the test in a
359 location in IMMR. On booting, the POST layer will check the value of
360 this variable and if it is set will skip over the tests preceding the
362 bit flag will be set in the flag argument to the test routine. This
363 will allow to detect system rebooting on the previous iteration. For
399 This project will also develop a set of POST tests for MPC8xx- based
400 systems. This section provides technical details of how it will be
405 The following generic POST tests will be developed:
409      This test will check the arithmetic logic unit (ALU) of CPU. The
410      test will take several milliseconds and will run on normal
415      This test will verify the CPU cache (L1 cache). The test will
420      This test will examine RAM and check it for errors. The test
421      will always run on booting. On normal booting, only a limited
422      amount of RAM will be checked. On power-fail booting a fool
423      memory check-up will be performed.
427 This test will verify the following ALU instructions:
431      This group will contain: mtcrf, mfcr, mcrxr, crand, crandc,
434      The mtcrf/mfcr instructions will be tested by loading different
437      the expected one. The mcrxr instruction will be tested by
441      register with the expected one. The rest of instructions will be
450      This group will contain: cmp, cmpi, cmpl, cmpli.
452      To verify these instructions the test will run them with
455      the test will contain a pre-built table containing the
462      This group will contain: add, addc, adde, addme, addze, subf,
466      The test will contain a pre-built table of instructions,
468      register. For each table entry, the test will cyclically use
471      iteration r0/r1 will be used as operands and r2 for result. On
472      the second iteration, r1/r2 will be used as operands and r3 as
473      for result and so on. This will enable to verify all
478      This group will contain: and, andc, andi, andis, or, orc, ori,
481      The test scheme will be identical to that from the previous
486      This group will contain: slw, srw, sraw, srawi, rlwinm, rlwnm,
489      The test scheme will be identical to that from the previous
494      This group will contain: b, bl, bc.
496      The first 2 instructions (b, bl) will be verified by jumping to
499      register will be checked as well (using mfspr). To verify the bc
501      and the condition register values will be checked. The list of
502      such combinations will be pre-built and linked in U-Boot at
507      This group will contain: lbz(x)(u), lhz(x)(u), lha(x)(u),
510      All operations will be performed on a 16-byte array. The array
511      will be 4-byte aligned. The base register will point to offset
512      8. The immediate offset (index register) will range in [-8 ...
513      +7]. The test cases will be composed so that they will not cause
514      alignment exceptions. The test will contain a pre-built table
516      entry will contain: the instruction opcode, the value of the
518      executing the instruction, the test will verify the contents of
521      table entry will contain: the instruction opcode, the array
524      the test will verify the value of the destination register and
531 The CPU test will run in RAM in order to allow run-time modification
540 To verify the data cache operation the following test scenarios will
593 scenarios will be used:
617 The CPU test will run in RAM in order to allow run-time modification
622 The memory test will verify RAM using sequential writes and reads
623 to/from RAM. Specifically, there will be several test cases that will
624 use different patterns to verify RAM. Each test case will first fill
626 compare its contents with the pattern. The following patterns will be
635 Patterns #1, #2 will help to find unstable bits. Patterns #3, #4 will
637 change if adjacent bits are modified. The last pattern will be used
640 last pattern will help to detect memory controller misconfigurations
643 Being run in normal mode, the test will verify only small 4Kb regions
645 following areas will be verified: 0x00000000-0x00000800,
647 0x04000000. If the test is run in power-fail mode, it will verify the
650 The memory test will run in ROM before relocating U-Boot to RAM in
661 For verifying the I2C bus, a full I2C bus scanning will be performed
663 CONFIG_SYS_POST_I2C_ADDRS the I2C test will pass if all devices
666 the test will pass if any I2C device is found.
670 CONFIG_SYS_POST_I2C_ADDRS.  The I2C POST test will pass regardless
679 section "Hazardous tests") will be used. Namely, this test will be
681 test routine will make a 10-second delay. If the system does not
684 POST_REBOOT bit will be set in the flag argument to the test routine.
685 The test routine will check this bit and report a success if it is
690 The RTC test will use the rtc_get()/rtc_set() routines. The following
691 features will be verified:
695      This will be verified by reading RTC in polling within a short
700      This will be checked by setting RTC to a second before a month
702      will be performed for both leap- and nonleap-years.
706 This project will develop a set of tests verifying the peripheral
708 MPC8xx communication processor module (CPM) will be tested:
716 The internal (local) loopback mode will be used to test SCC. To do
717 that the controllers will be configured accordingly and several
718 packets will be transmitted. These tests may be enhanced in future to
719 use external loopback for testing. That will need appropriate
722 The test routines for the SCC ethernet tests will be located in
727 To perform these tests the internal (local) loopback mode will be
728 used. The SMC/SCC controllers will be configured to connect the
730 will be transmitted. These tests may be enhanced to make to perform
732 test will be executed manually.
734 The test routine for the SMC/SCC UART tests will be located in