Lines Matching +full:no +full:- +full:loopback +full:- +full:test
1 Power-On-Self-Test support in U-Boot
2 ------------------------------------
4 This project is to support Power-On-Self-Test (POST) in U-Boot.
6 1. High-level requirements
11 and running Power-On-Self-Test in U-Boot. This framework shall
21 The framework shall allow run-time configuration of the lists
22 of tests running on normal/power-fail booting.
31 3) The following POST tests shall be developed for MPC823E-based
34 o) CPU test
35 o) Cache test
36 o) Memory test
37 o) Ethernet test
38 o) Serial channels test
39 o) Watchdog timer test
40 o) RTC test
41 o) I2C test
42 o) SPI test
43 o) USB test
51 enhancing U-Boot/Linux to provide a common framework for running POST
54 2.1. Hardware-independent POST layer
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
65 1) Tests running on power-on booting only
68 power-on reset (e.g. watchdog test)
73 time and can be run on the regular basis (e.g. CPU test)
75 3) Tests running in special "slow test mode" only
78 and cannot be run regularly (e.g. strong memory test, I2C test)
85 For example, SDRAM test may run in both normal and "slow test" mode.
86 In normal mode, SDRAM test may perform a fast superficial memory test
87 only, while running in slow test mode it may perform a full memory
88 check-up.
106 may cause system rebooting (e.g. watchdog test). For such tests, the
107 layer will automatically detect rebooting and will notify the test
113 rest of U-Boot.
117 #define POST_POWERON 0x01 /* test runs on power-on booting */
118 #define POST_NORMAL 0x02 /* test runs on normal booting */
119 #define POST_SLOWTEST 0x04 /* test is slow, enabled by key press */
120 #define POST_POWERTEST 0x08 /* test runs after watchdog reset */
121 #define POST_ROM 0x100 /* test runs in ROM */
122 #define POST_RAM 0x200 /* test runs in RAM */
123 #define POST_MANUAL 0x400 /* test can be executed manually */
124 #define POST_REBOOT 0x800 /* test may cause rebooting */
125 #define POST_PREREL 0x1000 /* test runs before relocation */
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,
138 mode the test is executed in (power-on, normal, power-fail,
144 relocate the POST test table.
150 particular test if name is not NULL.
159 Also, the following board-specific routines will be called from the
160 U-Boot common code:
170 will be called on power-fail booting after running all POST
177 power-on long-running tests shall be executed or not ("normal"
178 versus "slow" test mode).
181 filled at U-Boot build time. The format of entry in this array will
189 int (*test)(bd_t *bd, int flags);
194 This field will contain a short name of the test, which will be
195 used in logs and on listing POST tests (e.g. CPU test).
199 This field will keep a name for identifying the test on manual
205 This field will contain a detailed description of the test,
212 above, which will specify the mode the test is running in
213 (power-on, normal, power-fail or manual mode), the moment it
217 o) test
220 perform the test, which will take 2 arguments. The first
223 mode the test is running in (POST_POWERON, POST_NORMAL,
225 the test caused system rebooting (POST_REBOOT). The routine will
226 return 0 on successful execution of the test, and 1 if the test
229 The lists of the POST tests that should be run at power-on/normal/
230 power-fail booting will be kept in the environment. Namely, the
234 2.1.2. Test results
240 --------------------------------------------
242 <test-specific output>
244 --------------------------------------------
249 save it in non-volatile RAM (NVRAM), transfer it to a dedicated
254 All POST-related code will be #ifdef'ed with the CONFIG_POST macro.
262 "On-board peripherals test", "board", \
263 " This test performs full check-up of the " \
264 "on-board hardware.", \
276 "Cache test", "cache", \
277 " This test verifies the CPU cache operation.", \
282 A new subdirectory will be created in the U-Boot root directory. It
284 tests. Each POST test in this directory will be placed into a
288 way will be used only if the test subtantially uses the driver.
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
307 cache - cache test
308 cpu - CPU test
309 enet - SCC/FCC ethernet test
318 cpu - CPU test
319 This test verifies the arithmetic logic unit of CPU.
320 cache - cache test
321 This test verifies the CPU cache operation.
325 executed. If no tests are specified, all available tests will be
338 handler of the power-fail IRQ on booting. Being called, the handler
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
352 test, this means successful operation of the timer.
358 the POST layer will store an identification number of the test in a
361 failed one. On second execution of the failed test, the POST_REBOOT
362 bit flag will be set in the flag argument to the test routine. This
364 example, the watchdog timer test may have the following
370 "Watchdog timer test", "watchdog", \
371 " This test checks the watchdog timer.", \
383 /* Test passed */
388 /* 10-second delay */
397 2.2. Hardware-specific details
399 This project will also develop a set of POST tests for MPC8xx- based
407 o) CPU test
409 This test will check the arithmetic logic unit (ALU) of CPU. The
410 test will take several milliseconds and will run on normal
413 o) Cache test
415 This test will verify the CPU cache (L1 cache). The test will
418 o) Memory test
420 This test will examine RAM and check it for errors. The test
422 amount of RAM will be checked. On power-fail booting a fool
423 memory check-up will be performed.
425 2.2.1.1. CPU test
427 This test will verify the following ALU instructions:
436 a general-purpose register (mfcr) and comparing this value with
440 general-purpose register (mfcr) and comparing the value of this
444 4-bit condition fields, moving the value of the conditional
445 register to a general-purpose register (mfcr) and comparing it
452 To verify these instructions the test will run them with
455 the test will contain a pre-built table containing the
456 description of each test case: the instruction, the values of
466 The test will contain a pre-built table of instructions,
468 register. For each table entry, the test will cyclically use
474 general-purpose registers.
481 The test scheme will be identical to that from the previous
489 The test scheme will be identical to that from the previous
502 such combinations will be pre-built and linked in U-Boot at
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
515 describing all test cases. For store instructions, the table
518 executing the instruction, the test will verify the contents of
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
534 2.2.1.2 Special-Purpose Registers Tests
538 2.2.1.3. Cache test
540 To verify the data cache operation the following test scenarios will
543 1) Basic test #1
545 - turn on the data cache
546 - switch the data cache to write-back or write-through mode
547 - invalidate the data cache
548 - write the negative pattern to a cached area
549 - read the area
553 2) Basic test #2
555 - turn on the data cache
556 - switch the data cache to write-back or write-through mode
557 - invalidate the data cache
558 - write the zero pattern to a cached area
559 - turn off the data cache
560 - write the negative pattern to the area
561 - turn on the data cache
562 - read the area
566 3) Write-through mode test
568 - turn on the data cache
569 - switch the data cache to write-through mode
570 - invalidate the data cache
571 - write the zero pattern to a cached area
572 - flush the data cache
573 - write the negative pattern to the area
574 - turn off the data cache
575 - read the area
579 4) Write-back mode test
581 - turn on the data cache
582 - switch the data cache to write-back mode
583 - invalidate the data cache
584 - write the negative pattern to a cached area
585 - flush the data cache
586 - write the zero pattern to the area
587 - invalidate the data cache
588 - read the area
592 To verify the instruction cache operation the following test
595 1) Basic test #1
597 - turn on the instruction cache
598 - unlock the entire instruction cache
599 - invalidate the instruction cache
600 - lock a branch instruction in the instruction cache
601 - replace the branch instruction with "nop"
602 - jump to the branch instruction
603 - check that the branch instruction was executed
605 2) Basic test #2
607 - turn on the instruction cache
608 - unlock the entire instruction cache
609 - invalidate the instruction cache
610 - jump to a branch instruction
611 - check that the branch instruction was executed
612 - replace the branch instruction with "nop"
613 - invalidate the instruction cache
614 - jump to the branch instruction
615 - check that the "nop" instruction was executed
617 The CPU test will run in RAM in order to allow run-time modification
620 2.2.1.4. Memory test
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
632 4) bit-flip pattern ((1 << (offset % 32)), ~(1 << (offset % 32)))
638 to detect far-located errors, i.e. situations when writing to one
643 Being run in normal mode, the test will verify only small 4Kb regions
645 following areas will be verified: 0x00000000-0x00000800,
646 0x000ff800-0x00100800, 0x001ff800-0x00200800, ..., 0x03fff800-
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
656 peculiarities and use common U-Boot interfaces only. These tests do
659 2.2.2.1. I2C test
663 CONFIG_SYS_POST_I2C_ADDRS the I2C test will pass if all devices
664 listed in CONFIG_SYS_POST_I2C_ADDRS are found, and no additional
666 the test will pass if any I2C device is found.
670 CONFIG_SYS_POST_I2C_ADDRS. The I2C POST test will pass regardless
676 2.2.2.2. Watchdog timer test
678 To test the watchdog timer the scheme mentioned above (refer to
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
683 the test fails. If the system reboots, on the second iteration the
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
688 2.2.2.3. RTC test
690 The RTC test will use the rtc_get()/rtc_set() routines. The following
696 period of time (5-10 seconds).
701 boundary and reading it after its passing the boundary. The test
702 will be performed for both leap- and nonleap-years.
716 The internal (local) loopback mode will be used to test SCC. To do
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
731 "external" loopback test using a loopback cable. In this case, the
732 test will be executed manually.
734 The test routine for the SMC/SCC UART tests will be located in
737 2.2.3.3. USB test
741 2.2.3.4. SPI test