blob: 3d882311aaed5abad1080029008c3fbc89e39004 [file] [log] [blame]
wdenk43d96162003-03-06 00:02:04 +00001Power-On-Self-Test support in U-Boot
2------------------------------------
3
4This project is to support Power-On-Self-Test (POST) in U-Boot.
5
61. High-level requirements
7
8The key rquirements for this project are as follows:
9
101) The project shall develop a flexible framework for implementing
11 and running Power-On-Self-Test in U-Boot. This framework shall
12 possess the following features:
13
14 o) Extensibility
15
16 The framework shall allow adding/removing/replacing POST tests.
17 Also, standalone POST tests shall be supported.
18
19 o) Configurability
20
21 The framework shall allow run-time configuration of the lists
22 of tests running on normal/power-fail booting.
23
24 o) Controllability
25
26 The framework shall support manual running of the POST tests.
27
282) The results of tests shall be saved so that it will be possible to
29 retrieve them from Linux.
30
313) The following POST tests shall be developed for MPC823E-based
32 boards:
33
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
44
454) The LWMON board shall be used for reference.
46
472. Design
48
49This section details the key points of the design for the project.
50The whole project can be divided into two independent tasks:
51enhancing U-Boot/Linux to provide a common framework for running POST
52tests and developing such tests for particular hardware.
53
542.1. Hardware-independent POST layer
55
56A new optional module will be added to U-Boot, which will run POST
57tests and collect their results at boot time. Also, U-Boot will
58support running POST tests manually at any time by executing a
59special command from the system console.
60
61The list of available POST tests will be configured at U-Boot build
62time. The POST layer will allow the developer to add any custom POST
63tests. All POST tests will be divided into the following groups:
64
65 1) Tests running on power-on booting only
66
67 This group will contain those tests that run only once on
68 power-on reset (e.g. watchdog test)
69
70 2) Tests running on normal booting only
71
72 This group will contain those tests that do not take much
73 time and can be run on the regular basis (e.g. CPU test)
74
75 3) Tests running on power-fail booting only
76
77 This group will contain POST tests that consume much time
78 and cannot be run regularly (e.g. I2C test)
79
80 4) Manually executed tests
81
82 This group will contain those tests that can be run manually.
83
84If necessary, some tests may belong to several groups simultaneously.
85For example, SDRAM test may run on both noarmal and power-fail
86booting. On normal booting, SDRAM test may perform a fast superficial
87memory test only, while running on power-fail booting it may perform
88a full memory check-up.
89
90Also, all tests will be discriminated by the moment they run at.
91Specifically, the following groups will be singled out:
92
93 1) Tests running before relocating to RAM
94
95 These tests will run immediatelly after initializing RAM
96 as to enable modifying it without taking care of its
97 contents. Basically, this group will contain memory tests
98 only.
99
100 2) Tests running after relocating to RAM
101
102 These tests will run immediately before entering the main
103 loop as to guarantee full hardware initialization.
104
105The POST layer will also distinguish a special group of tests that
106may cause system rebooting (e.g. watchdog test). For such tests, the
107layer will automatically detect rebooting and will notify the test
108about it.
109
1102.1.1. POST layer interfaces
111
112This section details the interfaces between the POST layer and the
113rest of U-Boot.
114
115The following flags will be defined:
116
117#define POST_ROM 0x01 /* test runs in ROM */
118#define POST_RAM 0x02 /* test runs in RAM */
119#define POST_POWERON 0x04 /* test runs on power-on booting */
120#define POST_NORMAL 0x08 /* test runs on normal booting */
121#define POST_SHUTDOWN 0x10 /* test runs on power-fail booting */
122#define POST_MANUAL 0x20 /* test can be executed manually */
123#define POST_REBOOT 0x80 /* test may cause rebooting */
124
125The POST layer will export the following interface routines:
126
127 o) int post_run(bd_t *bd, char *name, int flags);
128
129 This routine will run the test (or the group of tests) specified
130 by the name and flag arguments. More specifically, if the name
131 argument is not NULL, the test with this name will be performed,
132 otherwise all tests running in ROM/RAM (depending on the flag
133 argument) will be executed. This routine will be called at least
134 twice with name set to NULL, once from board_init_f() and once
135 from board_init_r(). The flags argument will also specify the
136 mode the test is executed in (power-on, normal, power-fail,
137 manual).
138
139 o) void post_reloc(ulong offset);
140
141 This routine will be called from board_init_r() and will
142 relocate the POST test table.
143
144 o) int post_info(char *name);
145
146 This routine will print the list of all POST tests that can be
147 executed manually if name is NULL, and the description of a
148 particular test if name is not NULL.
149
150 o) int post_log(char *format, ...);
151
152 This routine will be called from POST tests to log their
153 results. Basically, this routine will print the results to
154 stderr. The format of the arguments and the return value
155 will be identical to the printf() routine.
156
157Also, the following board-specific routines will be called from the
158U-Boot common code:
159
160 o) int board_power_mode(void)
161
162 This routine will return the mode the system is running in
163 (POST_POWERON, POST_NORMAL or POST_SHUTDOWN).
164
165 o) void board_poweroff(void)
166
167 This routine will turn off the power supply of the board. It
168 will be called on power-fail booting after running all POST
169 tests.
170
171The list of available POST tests be kept in the post_tests array
172filled at U-Boot build time. The format of entry in this array will
173be as follows:
174
175struct post_test {
176 char *name;
177 char *cmd;
178 char *desc;
179 int flags;
180 int (*test)(bd_t *bd, int flags);
181};
182
183 o) name
184
185 This field will contain a short name of the test, which will be
186 used in logs and on listing POST tests (e.g. CPU test).
187
188 o) cmd
189
190 This field will keep a name for identifying the test on manual
191 testing (e.g. cpu). For more information, refer to section
192 "Command line interface".
193
194 o) desc
195
196 This field will contain a detailed description of the test,
197 which will be printed on user request. For more information, see
198 section "Command line interface".
199
200 o) flags
201
202 This field will contain a combination of the bit flags described
203 above, which will specify the mode the test is running in
204 (power-on, normal, power-fail or manual mode), the moment it
205 should be run at (before or after relocating to RAM), whether it
206 can cause system rebooting or not.
207
208 o) test
209
210 This field will contain a pointer to the routine that will
211 perform the test, which will take 2 arguments. The first
212 argument will be a pointer to the board info structure, while
213 the second will be a combination of bit flags specifying the
214 mode the test is running in (POST_POWERON, POST_NORMAL,
wdenk8564acf2003-07-14 22:13:32 +0000215 POST_SLOWTEST, POST_MANUAL) and whether the last execution of
wdenk43d96162003-03-06 00:02:04 +0000216 the test caused system rebooting (POST_REBOOT). The routine will
217 return 0 on successful execution of the test, and 1 if the test
218 failed.
219
220The lists of the POST tests that should be run at power-on/normal/
221power-fail booting will be kept in the environment. Namely, the
222following environment variables will be used: post_poweron,
wdenk8564acf2003-07-14 22:13:32 +0000223powet_normal, post_slowtest.
wdenk43d96162003-03-06 00:02:04 +0000224
2252.1.2. Test results
226
227The results of tests will be collected by the POST layer. The POST
228log will have the following format:
229
230...
231--------------------------------------------
232START <name>
233<test-specific output>
234[PASSED|FAILED]
235--------------------------------------------
236...
237
238Basically, the results of tests will be printed to stderr. This
239feature may be enhanced in future to spool the log to a serial line,
240save it in non-volatile RAM (NVRAM), transfer it to a dedicated
241storage server and etc.
242
2432.1.3. Integration issues
244
245All POST-related code will be #ifdef'ed with the CONFIG_POST macro.
246This macro will be defined in the config_<board>.h file for those
247boards that need POST. The CONFIG_POST macro will contain the list of
248POST tests for the board. The macro will have the format of array
249composed of post_test structures:
250
251#define CONFIG_POST \
252 {
253 "On-board peripherals test", "board", \
254 " This test performs full check-up of the " \
255 "on-board hardware.", \
wdenk8564acf2003-07-14 22:13:32 +0000256 POST_RAM | POST_SLOWTEST, \
wdenk43d96162003-03-06 00:02:04 +0000257 &board_post_test \
258 }
259
260A new file, post.h, will be created in the include/ directory. This
261file will contain common POST declarations and will define a set of
262macros that will be reused for defining CONFIG_POST. As an example,
263the following macro may be defined:
264
265#define POST_CACHE \
266 {
267 "Cache test", "cache", \
268 " This test verifies the CPU cache operation.", \
269 POST_RAM | POST_NORMAL, \
270 &cache_post_test \
271 }
272
273A new subdirectory will be created in the U-Boot root directory. It
274will contain the source code of the POST layer and most of POST
275tests. Each POST test in this directory will be placed into a
276separate file (it will be needed for building standalone tests). Some
277POST tests (mainly those for testing peripheral devices) will be
278located in the source files of the drivers for those devices. This
279way will be used only if the test subtantially uses the driver.
280
2812.1.4. Standalone tests
282
283The POST framework will allow to develop and run standalone tests. A
284user-space library will be developed to provide the POST interface
285functions to standalone tests.
286
2872.1.5. Command line interface
288
289A new command, diag, will be added to U-Boot. This command will be
290used for listing all available hardware tests, getting detailed
291descriptions of them and running these tests.
292
293More specifically, being run without any arguments, this command will
294print the list of all available hardware tests:
295
296=> diag
297Available hardware tests:
298 cache - cache test
299 cpu - CPU test
300 enet - SCC/FCC ethernet test
301Use 'diag [<test1> [<test2>]] ... ' to get more info.
302Use 'diag run [<test1> [<test2>]] ... ' to run tests.
303=>
304
305If the first argument to the diag command is not 'run', detailed
306descriptions of the specified tests will be printed:
307
308=> diag cpu cache
309cpu - CPU test
310 This test verifies the arithmetic logic unit of CPU.
311cache - cache test
312 This test verifies the CPU cache operation.
313=>
314
315If the first argument to diag is 'run', the specified tests will be
316executed. If no tests are specified, all available tests will be
317executed.
318
319It will be prohibited to execute tests running in ROM manually. The
320'diag' command will not display such tests and/or run them.
321
3222.1.6. Power failure handling
323
324The Linux kernel will be modified to detect power failures and
325automatically reboot the system in such cases. It will be assumed
326that the power failure causes a system interrupt.
327
328To perform correct system shutdown, the kernel will register a
329handler of the power-fail IRQ on booting. Being called, the handler
330will run /sbin/reboot using the call_usermodehelper() routine.
331/sbin/reboot will automatically bring the system down in a secure
332way. This feature will be configured in/out from the kernel
333configuration file.
334
335The POST layer of U-Boot will check whether the system runs in
336power-fail mode. If it does, the system will be powered off after
337executing all hardware tests.
338
3392.1.7. Hazardous tests
340
341Some tests may cause system rebooting during their execution. For
342some tests, this will indicate a failure, while for the Watchdog
343test, this means successful operation of the timer.
344
345In order to support such tests, the following scheme will be
346implemented. All the tests that may cause system rebooting will have
347the POST_REBOOT bit flag set in the flag field of the correspondent
348post_test structure. Before starting tests marked with this bit flag,
349the POST layer will store an identification number of the test in a
350location in IMMR. On booting, the POST layer will check the value of
351this variable and if it is set will skip over the tests preceding the
352failed one. On second execution of the failed test, the POST_REBOOT
353bit flag will be set in the flag argument to the test routine. This
354will allow to detect system rebooting on the previous iteration. For
355example, the watchdog timer test may have the following
356declaration/body:
357
358...
359#define POST_WATCHDOG \
360 {
361 "Watchdog timer test", "watchdog", \
362 " This test checks the watchdog timer.", \
363 POST_RAM | POST_POWERON | POST_REBOOT, \
364 &watchdog_post_test \
365 }
366...
367
368...
369int watchdog_post_test(bd_t *bd, int flags)
370{
371 unsigned long start_time;
372
373 if (flags & POST_REBOOT) {
374 /* Test passed */
375 return 0;
376 } else {
377 /* disable interrupts */
378 disable_interrupts();
379 /* 10-second delay */
380 ...
381 /* if we've reached this, the watchdog timer does not work */
382 enable_interrupts();
383 return 1;
384 }
385}
386...
387
3882.2. Hardware-specific details
389
390This project will also develop a set of POST tests for MPC8xx- based
391systems. This section provides technical details of how it will be
392done.
393
3942.2.1. Generic PPC tests
395
396The following generic POST tests will be developed:
397
398 o) CPU test
399
400 This test will check the arithmetic logic unit (ALU) of CPU. The
401 test will take several milliseconds and will run on normal
402 booting.
403
404 o) Cache test
405
406 This test will verify the CPU cache (L1 cache). The test will
407 run on normal booting.
408
409 o) Memory test
410
411 This test will examine RAM and check it for errors. The test
412 will always run on booting. On normal booting, only a limited
413 amount of RAM will be checked. On power-fail booting a fool
414 memory check-up will be performed.
415
4162.2.1.1. CPU test
417
418This test will verify the following ALU instructions:
419
420 o) Condition register istructions
421
422 This group will contain: mtcrf, mfcr, mcrxr, crand, crandc,
423 cror, crorc, crxor, crnand, crnor, creqv, mcrf.
424
425 The mtcrf/mfcr instructions will be tested by loading different
426 values into the condition register (mtcrf), moving its value to
427 a general-purpose register (mfcr) and comparing this value with
428 the expected one. The mcrxr instruction will be tested by
429 loading a fixed value into the XER register (mtspr), moving XER
430 value to the condition register (mcrxr), moving it to a
431 general-purpose register (mfcr) and comparing the value of this
432 register with the expected one. The rest of instructions will be
433 tested by loading a fixed value into the condition register
434 (mtcrf), executing each instruction several times to modify all
435 4-bit condition fields, moving the value of the conditional
436 register to a general-purpose register (mfcr) and comparing it
437 with the expected one.
438
439 o) Integer compare instructions
440
441 This group will contain: cmp, cmpi, cmpl, cmpli.
442
443 To verify these instructions the test will run them with
444 different combinations of operands, read the condition register
445 value and compare it with the expected one. More specifically,
446 the test will contain a pre-built table containing the
447 description of each test case: the instruction, the values of
448 the operands, the condition field to save the result in and the
449 expected result.
450
451 o) Arithmetic instructions
452
453 This group will contain: add, addc, adde, addme, addze, subf,
454 subfc, subfe, subme, subze, mullw, mulhw, mulhwu, divw, divwu,
455 extsb, extsh.
456
457 The test will contain a pre-built table of instructions,
458 operands, expected results and expected states of the condition
459 register. For each table entry, the test will cyclically use
460 different sets of operand registers and result registers. For
461 example, for instructions that use 3 registers on the first
462 iteration r0/r1 will be used as operands and r2 for result. On
463 the second iteration, r1/r2 will be used as operands and r3 as
464 for result and so on. This will enable to verify all
465 general-purpose registers.
466
467 o) Logic instructions
468
469 This group will contain: and, andc, andi, andis, or, orc, ori,
470 oris, xor, xori, xoris, nand, nor, neg, eqv, cntlzw.
471
472 The test scheme will be identical to that from the previous
473 point.
474
475 o) Shift instructions
476
477 This group will contain: slw, srw, sraw, srawi, rlwinm, rlwnm,
478 rlwimi
479
480 The test scheme will be identical to that from the previous
481 point.
482
483 o) Branch instructions
484
485 This group will contain: b, bl, bc.
486
487 The first 2 instructions (b, bl) will be verified by jumping to
488 a fixed address and checking whether control was transfered to
489 that very point. For the bl instruction the value of the link
490 register will be checked as well (using mfspr). To verify the bc
491 instruction various combinations of the BI/BO fields, the CTR
492 and the condition register values will be checked. The list of
493 such combinations will be pre-built and linked in U-Boot at
494 build time.
495
496 o) Load/store instructions
497
498 This group will contain: lbz(x)(u), lhz(x)(u), lha(x)(u),
499 lwz(x)(u), stb(x)(u), sth(x)(u), stw(x)(u).
500
501 All operations will be performed on a 16-byte array. The array
502 will be 4-byte aligned. The base register will point to offset
503 8. The immediate offset (index register) will range in [-8 ...
504 +7]. The test cases will be composed so that they will not cause
505 alignment exceptions. The test will contain a pre-built table
506 describing all test cases. For store instructions, the table
507 entry will contain: the instruction opcode, the value of the
508 index register and the value of the source register. After
509 executing the instruction, the test will verify the contents of
510 the array and the value of the base register (it must change for
511 "store with update" instructions). For load instructions, the
512 table entry will contain: the instruction opcode, the array
513 contents, the value of the index register and the expected value
514 of the destination register. After executing the instruction,
515 the test will verify the value of the destination register and
516 the value of the base register (it must change for "load with
517 update" instructions).
518
519 o) Load/store multiple/string instructions
520
521
522The CPU test will run in RAM in order to allow run-time modification
523of the code to reduce the memory footprint.
524
5252.2.1.2 Special-Purpose Registers Tests
526
527TBD.
528
5292.2.1.3. Cache test
530
531To verify the data cache operation the following test scenarios will
532be used:
533
534 1) Basic test #1
535
536 - turn on the data cache
537 - switch the data cache to write-back or write-through mode
538 - invalidate the data cache
539 - write the negative pattern to a cached area
540 - read the area
541
542 The negative pattern must be read at the last step
543
544 2) Basic test #2
545
546 - turn on the data cache
547 - switch the data cache to write-back or write-through mode
548 - invalidate the data cache
549 - write the zero pattern to a cached area
550 - turn off the data cache
551 - write the negative pattern to the area
552 - turn on the data cache
553 - read the area
554
555 The negative pattern must be read at the last step
556
557 3) Write-through mode test
558
559 - turn on the data cache
560 - switch the data cache to write-through mode
561 - invalidate the data cache
562 - write the zero pattern to a cached area
563 - flush the data cache
564 - write the negative pattern to the area
565 - turn off the data cache
566 - read the area
567
568 The negative pattern must be read at the last step
569
570 4) Write-back mode test
571
572 - turn on the data cache
573 - switch the data cache to write-back mode
574 - invalidate the data cache
575 - write the negative pattern to a cached area
576 - flush the data cache
577 - write the zero pattern to the area
578 - invalidate the data cache
579 - read the area
580
581 The negative pattern must be read at the last step
582
583To verify the instruction cache operation the following test
584scenarios will be used:
585
586 1) Basic test #1
587
588 - turn on the instruction cache
589 - unlock the entire instruction cache
590 - invalidate the instruction cache
591 - lock a branch instruction in the instruction cache
592 - replace the branch instruction with "nop"
593 - jump to the branch instruction
594 - check that the branch instruction was executed
595
596 2) Basic test #2
597
598 - turn on the instruction cache
599 - unlock the entire instruction cache
600 - invalidate the instruction cache
601 - jump to a branch instruction
602 - check that the branch instruction was executed
603 - replace the branch instruction with "nop"
604 - invalidate the instruction cache
605 - jump to the branch instruction
606 - check that the "nop" instruction was executed
607
608The CPU test will run in RAM in order to allow run-time modification
609of the code.
610
6112.2.1.4. Memory test
612
613The memory test will verify RAM using sequential writes and reads
614to/from RAM. Specifically, there will be several test cases that will
615use different patterns to verify RAM. Each test case will first fill
616a region of RAM with one pattern and then read the region back and
617compare its contents with the pattern. The following patterns will be
618used:
619
620 1) zero pattern (0x00000000)
621 2) negative pattern (0xffffffff)
622 3) checkerboard pattern (0x55555555, 0xaaaaaaaa)
623 4) bit-flip pattern ((1 << (offset % 32)), ~(1 << (offset % 32)))
624 5) address pattern (offset, ~offset)
625
626Patterns #1, #2 will help to find unstable bits. Patterns #3, #4 will
627be used to detect adherent bits, i.e. bits whose state may randomly
628change if adjacent bits are modified. The last pattern will be used
629to detect far-located errors, i.e. situations when writing to one
630location modifies an area located far from it. Also, usage of the
631last pattern will help to detect memory controller misconfigurations
632when RAM represents a cyclically repeated portion of a smaller size.
633
634Being run in normal mode, the test will verify only small 4Kb regions
635of RAM around each 1Mb boundary. For example, for 64Mb RAM the
636following areas will be verified: 0x00000000-0x00000800,
6370x000ff800-0x00100800, 0x001ff800-0x00200800, ..., 0x03fff800-
6380x04000000. If the test is run in power-fail mode, it will verify the
639whole RAM.
640
641The memory test will run in ROM before relocating U-Boot to RAM in
642order to allow RAM modification without saving its contents.
643
6442.2.2. Common tests
645
646This section describes tests that are not based on any hardware
647peculiarities and use common U-Boot interfaces only. These tests do
648not need any modifications for porting them to another board/CPU.
649
6502.2.2.1. I2C test
651
652For verifying the I2C bus, a full I2C bus scanning will be performed
653using the i2c_probe() routine. If any I2C device is found, the test
654will be considered as passed, otherwise failed. This particular way
655will be used because it provides the most common method of testing.
656For example, using the internal loopback mode of the CPM I2C
657controller for testing would not work on boards where the software
658I2C driver (also known as bit-banged driver) is used.
659
6602.2.2.2. Watchdog timer test
661
662To test the watchdog timer the scheme mentioned above (refer to
663section "Hazardous tests") will be used. Namely, this test will be
664marked with the POST_REBOOT bit flag. On the first iteration, the
665test routine will make a 10-second delay. If the system does not
666reboot during this delay, the watchdog timer is not operational and
667the test fails. If the system reboots, on the second iteration the
668POST_REBOOT bit will be set in the flag argument to the test routine.
669The test routine will check this bit and report a success if it is
670set.
671
6722.2.2.3. RTC test
673
674The RTC test will use the rtc_get()/rtc_set() routines. The following
675features will be verified:
676
677 o) Time uniformity
678
679 This will be verified by reading RTC in polling within a short
680 period of time (5-10 seconds).
681
682 o) Passing month boundaries
683
684 This will be checked by setting RTC to a second before a month
685 boundary and reading it after its passing the boundary. The test
686 will be performed for both leap- and nonleap-years.
687
6882.2.3. MPC8xx peripherals tests
689
690This project will develop a set of tests verifying the peripheral
691units of MPC8xx processors. Namely, the following controllers of the
692MPC8xx communication processor module (CPM) will be tested:
693
694 o) Serial Management Controllers (SMC)
695
696 o) Serial Communication Controllers (SCC)
697
6982.2.3.1. Ethernet tests (SCC)
699
700The internal (local) loopback mode will be used to test SCC. To do
701that the controllers will be configured accordingly and several
702packets will be transmitted. These tests may be enhanced in future to
703use external loopback for testing. That will need appropriate
704reconfiguration of the physical interface chip.
705
706The test routines for the SCC ethernet tests will be located in
707cpu/mpc8xx/scc.c.
708
7092.2.3.2. UART tests (SMC/SCC)
710
711To perform these tests the internal (local) loopback mode will be
712used. The SMC/SCC controllers will be configured to connect the
713transmitter output to the receiver input. After that, several bytes
714will be transmitted. These tests may be enhanced to make to perform
715"external" loopback test using a loopback cable. In this case, the
716test will be executed manually.
717
718The test routine for the SMC/SCC UART tests will be located in
719cpu/mpc8xx/serial.c.
720
7212.2.3.3. USB test
722
723TBD
724
7252.2.3.4. SPI test
726
727TBD
728
7292.3. Design notes
730
731Currently it is unknown how we will power off the board after running
732all power-fail POST tests. This point needs further clarification.