1Power-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 requirements 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 in special "slow test mode" only 76 77 This group will contain POST tests that consume much time 78 and cannot be run regularly (e.g. strong memory test, 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 in both normal and "slow test" mode. 86In normal mode, SDRAM test may perform a fast superficial memory test 87only, while running in slow test mode it may perform a full memory 88check-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 immediately 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_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 */ 126 127The POST layer will export the following interface routines: 128 129 o) int post_run(struct bd_info *bd, char *name, int flags); 130 131 This routine will run the test (or the group of tests) specified 132 by the name and flag arguments. More specifically, if the name 133 argument is not NULL, the test with this name will be performed, 134 otherwise all tests running in ROM/RAM (depending on the flag 135 argument) will be executed. This routine will be called at least 136 twice with name set to NULL, once from board_init_f() and once 137 from board_init_r(). The flags argument will also specify the 138 mode the test is executed in (power-on, normal, power-fail, 139 manual). 140 141 o) int post_info(char *name); 142 143 This routine will print the list of all POST tests that can be 144 executed manually if name is NULL, and the description of a 145 particular test if name is not NULL. 146 147 o) int post_log(char *format, ...); 148 149 This routine will be called from POST tests to log their 150 results. Basically, this routine will print the results to 151 stderr. The format of the arguments and the return value 152 will be identical to the printf() routine. 153 154Also, the following board-specific routines will be called from the 155U-Boot common code: 156 157 o) int post_hotkeys_pressed(gd_t *gd) 158 159 This routine will scan the keyboard to detect if a magic key 160 combination has been pressed, or otherwise detect if the 161 power-on long-running tests shall be executed or not ("normal" 162 versus "slow" test mode). 163 164The list of available POST tests be kept in the post_tests array 165filled at U-Boot build time. The format of entry in this array will 166be as follows: 167 168struct post_test { 169 char *name; 170 char *cmd; 171 char *desc; 172 int flags; 173 int (*test)(struct bd_info *bd, int flags); 174}; 175 176 o) name 177 178 This field will contain a short name of the test, which will be 179 used in logs and on listing POST tests (e.g. CPU test). 180 181 o) cmd 182 183 This field will keep a name for identifying the test on manual 184 testing (e.g. cpu). For more information, refer to section 185 "Command line interface". 186 187 o) desc 188 189 This field will contain a detailed description of the test, 190 which will be printed on user request. For more information, see 191 section "Command line interface". 192 193 o) flags 194 195 This field will contain a combination of the bit flags described 196 above, which will specify the mode the test is running in 197 (power-on, normal, power-fail or manual mode), the moment it 198 should be run at (before or after relocating to RAM), whether it 199 can cause system rebooting or not. 200 201 o) test 202 203 This field will contain a pointer to the routine that will 204 perform the test, which will take 2 arguments. The first 205 argument will be a pointer to the board info structure, while 206 the second will be a combination of bit flags specifying the 207 mode the test is running in (POST_POWERON, POST_NORMAL, 208 POST_SLOWTEST, POST_MANUAL) and whether the last execution of 209 the test caused system rebooting (POST_REBOOT). The routine will 210 return 0 on successful execution of the test, and 1 if the test 211 failed. 212 213The lists of the POST tests that should be run at power-on/normal/ 214power-fail booting will be kept in the environment. Namely, the 215following environment variables will be used: post_poweron, 216powet_normal, post_slowtest. 217 2182.1.2. Test results 219 220The results of tests will be collected by the POST layer. The POST 221log will have the following format: 222 223... 224-------------------------------------------- 225START <name> 226<test-specific output> 227[PASSED|FAILED] 228-------------------------------------------- 229... 230 231Basically, the results of tests will be printed to stderr. This 232feature may be enhanced in future to spool the log to a serial line, 233save it in non-volatile RAM (NVRAM), transfer it to a dedicated 234storage server and etc. 235 2362.1.3. Integration issues 237 238All POST-related code will be #ifdef'ed with the CONFIG_POST macro. 239This macro will be defined in the config_<board>.h file for those 240boards that need POST. The CFG_POST macro will contain the list of 241POST tests for the board. The macro will have the format of array 242composed of post_test structures: 243 244#define CFG_POST \ 245 { 246 "On-board peripherals test", "board", \ 247 " This test performs full check-up of the " \ 248 "on-board hardware.", \ 249 POST_RAM | POST_SLOWTEST, \ 250 &board_post_test \ 251 } 252 253A new file, post.h, will be created in the include/ directory. This 254file will contain common POST declarations and will define a set of 255macros that will be reused for defining CFG_POST. As an example, 256the following macro may be defined: 257 258#define POST_CACHE \ 259 { 260 "Cache test", "cache", \ 261 " This test verifies the CPU cache operation.", \ 262 POST_RAM | POST_NORMAL, \ 263 &cache_post_test \ 264 } 265 266A new subdirectory will be created in the U-Boot root directory. It 267will contain the source code of the POST layer and most of POST 268tests. Each POST test in this directory will be placed into a 269separate file (it will be needed for building standalone tests). Some 270POST tests (mainly those for testing peripheral devices) will be 271located in the source files of the drivers for those devices. This 272way will be used only if the test subtantially uses the driver. 273 2742.1.4. Standalone tests 275 276The POST framework will allow to develop and run standalone tests. A 277user-space library will be developed to provide the POST interface 278functions to standalone tests. 279 2802.1.5. Command line interface 281 282A new command, diag, will be added to U-Boot. This command will be 283used for listing all available hardware tests, getting detailed 284descriptions of them and running these tests. 285 286More specifically, being run without any arguments, this command will 287print the list of all available hardware tests: 288 289=> diag 290Available hardware tests: 291 cache - cache test 292 cpu - CPU test 293 enet - SCC/FCC ethernet test 294Use 'diag [<test1> [<test2>]] ... ' to get more info. 295Use 'diag run [<test1> [<test2>]] ... ' to run tests. 296=> 297 298If the first argument to the diag command is not 'run', detailed 299descriptions of the specified tests will be printed: 300 301=> diag cpu cache 302cpu - CPU test 303 This test verifies the arithmetic logic unit of CPU. 304cache - cache test 305 This test verifies the CPU cache operation. 306=> 307 308If the first argument to diag is 'run', the specified tests will be 309executed. If no tests are specified, all available tests will be 310executed. 311 312It will be prohibited to execute tests running in ROM manually. The 313'diag' command will not display such tests and/or run them. 314 3152.1.6. Power failure handling 316 317The Linux kernel will be modified to detect power failures and 318automatically reboot the system in such cases. It will be assumed 319that the power failure causes a system interrupt. 320 321To perform correct system shutdown, the kernel will register a 322handler of the power-fail IRQ on booting. Being called, the handler 323will run /sbin/reboot using the call_usermodehelper() routine. 324/sbin/reboot will automatically bring the system down in a secure 325way. This feature will be configured in/out from the kernel 326configuration file. 327 328The POST layer of U-Boot will check whether the system runs in 329power-fail mode. If it does, the system will be powered off after 330executing all hardware tests. 331 3322.1.7. Hazardous tests 333 334Some tests may cause system rebooting during their execution. For 335some tests, this will indicate a failure, while for the Watchdog 336test, this means successful operation of the timer. 337 338In order to support such tests, the following scheme will be 339implemented. All the tests that may cause system rebooting will have 340the POST_REBOOT bit flag set in the flag field of the correspondent 341post_test structure. Before starting tests marked with this bit flag, 342the POST layer will store an identification number of the test in a 343location in IMMR. On booting, the POST layer will check the value of 344this variable and if it is set will skip over the tests preceding the 345failed one. On second execution of the failed test, the POST_REBOOT 346bit flag will be set in the flag argument to the test routine. This 347will allow to detect system rebooting on the previous iteration. For 348example, the watchdog timer test may have the following 349declaration/body: 350 351... 352#define POST_WATCHDOG \ 353 { 354 "Watchdog timer test", "watchdog", \ 355 " This test checks the watchdog timer.", \ 356 POST_RAM | POST_POWERON | POST_REBOOT, \ 357 &watchdog_post_test \ 358 } 359... 360 361... 362int watchdog_post_test(struct bd_info *bd, int flags) 363{ 364 unsigned long start_time; 365 366 if (flags & POST_REBOOT) { 367 /* Test passed */ 368 return 0; 369 } else { 370 /* disable interrupts */ 371 disable_interrupts(); 372 /* 10-second delay */ 373 ... 374 /* if we've reached this, the watchdog timer does not work */ 375 enable_interrupts(); 376 return 1; 377 } 378} 379... 380 3812.2. Hardware-specific details 382 383This project will also develop a set of POST tests for MPC8xx- based 384systems. This section provides technical details of how it will be 385done. 386 3872.2.1. Generic PPC tests 388 389The following generic POST tests will be developed: 390 391 o) CPU test 392 393 This test will check the arithmetic logic unit (ALU) of CPU. The 394 test will take several milliseconds and will run on normal 395 booting. 396 397 o) Cache test 398 399 This test will verify the CPU cache (L1 cache). The test will 400 run on normal booting. 401 402 o) Memory test 403 404 This test will examine RAM and check it for errors. The test 405 will always run on booting. On normal booting, only a limited 406 amount of RAM will be checked. On power-fail booting a fool 407 memory check-up will be performed. 408 4092.2.1.1. CPU test 410 411This test will verify the following ALU instructions: 412 413 o) Condition register istructions 414 415 This group will contain: mtcrf, mfcr, mcrxr, crand, crandc, 416 cror, crorc, crxor, crnand, crnor, creqv, mcrf. 417 418 The mtcrf/mfcr instructions will be tested by loading different 419 values into the condition register (mtcrf), moving its value to 420 a general-purpose register (mfcr) and comparing this value with 421 the expected one. The mcrxr instruction will be tested by 422 loading a fixed value into the XER register (mtspr), moving XER 423 value to the condition register (mcrxr), moving it to a 424 general-purpose register (mfcr) and comparing the value of this 425 register with the expected one. The rest of instructions will be 426 tested by loading a fixed value into the condition register 427 (mtcrf), executing each instruction several times to modify all 428 4-bit condition fields, moving the value of the conditional 429 register to a general-purpose register (mfcr) and comparing it 430 with the expected one. 431 432 o) Integer compare instructions 433 434 This group will contain: cmp, cmpi, cmpl, cmpli. 435 436 To verify these instructions the test will run them with 437 different combinations of operands, read the condition register 438 value and compare it with the expected one. More specifically, 439 the test will contain a pre-built table containing the 440 description of each test case: the instruction, the values of 441 the operands, the condition field to save the result in and the 442 expected result. 443 444 o) Arithmetic instructions 445 446 This group will contain: add, addc, adde, addme, addze, subf, 447 subfc, subfe, subme, subze, mullw, mulhw, mulhwu, divw, divwu, 448 extsb, extsh. 449 450 The test will contain a pre-built table of instructions, 451 operands, expected results and expected states of the condition 452 register. For each table entry, the test will cyclically use 453 different sets of operand registers and result registers. For 454 example, for instructions that use 3 registers on the first 455 iteration r0/r1 will be used as operands and r2 for result. On 456 the second iteration, r1/r2 will be used as operands and r3 as 457 for result and so on. This will enable to verify all 458 general-purpose registers. 459 460 o) Logic instructions 461 462 This group will contain: and, andc, andi, andis, or, orc, ori, 463 oris, xor, xori, xoris, nand, nor, neg, eqv, cntlzw. 464 465 The test scheme will be identical to that from the previous 466 point. 467 468 o) Shift instructions 469 470 This group will contain: slw, srw, sraw, srawi, rlwinm, rlwnm, 471 rlwimi 472 473 The test scheme will be identical to that from the previous 474 point. 475 476 o) Branch instructions 477 478 This group will contain: b, bl, bc. 479 480 The first 2 instructions (b, bl) will be verified by jumping to 481 a fixed address and checking whether control was transferred to 482 that very point. For the bl instruction the value of the link 483 register will be checked as well (using mfspr). To verify the bc 484 instruction various combinations of the BI/BO fields, the CTR 485 and the condition register values will be checked. The list of 486 such combinations will be pre-built and linked in U-Boot at 487 build time. 488 489 o) Load/store instructions 490 491 This group will contain: lbz(x)(u), lhz(x)(u), lha(x)(u), 492 lwz(x)(u), stb(x)(u), sth(x)(u), stw(x)(u). 493 494 All operations will be performed on a 16-byte array. The array 495 will be 4-byte aligned. The base register will point to offset 496 8. The immediate offset (index register) will range in [-8 ... 497 +7]. The test cases will be composed so that they will not cause 498 alignment exceptions. The test will contain a pre-built table 499 describing all test cases. For store instructions, the table 500 entry will contain: the instruction opcode, the value of the 501 index register and the value of the source register. After 502 executing the instruction, the test will verify the contents of 503 the array and the value of the base register (it must change for 504 "store with update" instructions). For load instructions, the 505 table entry will contain: the instruction opcode, the array 506 contents, the value of the index register and the expected value 507 of the destination register. After executing the instruction, 508 the test will verify the value of the destination register and 509 the value of the base register (it must change for "load with 510 update" instructions). 511 512 o) Load/store multiple/string instructions 513 514 515The CPU test will run in RAM in order to allow run-time modification 516of the code to reduce the memory footprint. 517 5182.2.1.2 Special-Purpose Registers Tests 519 520TBD. 521 5222.2.1.3. Cache test 523 524To verify the data cache operation the following test scenarios will 525be used: 526 527 1) Basic test #1 528 529 - turn on the data cache 530 - switch the data cache to write-back or write-through mode 531 - invalidate the data cache 532 - write the negative pattern to a cached area 533 - read the area 534 535 The negative pattern must be read at the last step 536 537 2) Basic test #2 538 539 - turn on the data cache 540 - switch the data cache to write-back or write-through mode 541 - invalidate the data cache 542 - write the zero pattern to a cached area 543 - turn off the data cache 544 - write the negative pattern to the area 545 - turn on the data cache 546 - read the area 547 548 The negative pattern must be read at the last step 549 550 3) Write-through mode test 551 552 - turn on the data cache 553 - switch the data cache to write-through mode 554 - invalidate the data cache 555 - write the zero pattern to a cached area 556 - flush the data cache 557 - write the negative pattern to the area 558 - turn off the data cache 559 - read the area 560 561 The negative pattern must be read at the last step 562 563 4) Write-back mode test 564 565 - turn on the data cache 566 - switch the data cache to write-back mode 567 - invalidate the data cache 568 - write the negative pattern to a cached area 569 - flush the data cache 570 - write the zero pattern to the area 571 - invalidate the data cache 572 - read the area 573 574 The negative pattern must be read at the last step 575 576To verify the instruction cache operation the following test 577scenarios will be used: 578 579 1) Basic test #1 580 581 - turn on the instruction cache 582 - unlock the entire instruction cache 583 - invalidate the instruction cache 584 - lock a branch instruction in the instruction cache 585 - replace the branch instruction with "nop" 586 - jump to the branch instruction 587 - check that the branch instruction was executed 588 589 2) Basic test #2 590 591 - turn on the instruction cache 592 - unlock the entire instruction cache 593 - invalidate the instruction cache 594 - jump to a branch instruction 595 - check that the branch instruction was executed 596 - replace the branch instruction with "nop" 597 - invalidate the instruction cache 598 - jump to the branch instruction 599 - check that the "nop" instruction was executed 600 601The CPU test will run in RAM in order to allow run-time modification 602of the code. 603 6042.2.1.4. Memory test 605 606The memory test will verify RAM using sequential writes and reads 607to/from RAM. Specifically, there will be several test cases that will 608use different patterns to verify RAM. Each test case will first fill 609a region of RAM with one pattern and then read the region back and 610compare its contents with the pattern. The following patterns will be 611used: 612 613 1) zero pattern (0x00000000) 614 2) negative pattern (0xffffffff) 615 3) checkerboard pattern (0x55555555, 0xaaaaaaaa) 616 4) bit-flip pattern ((1 << (offset % 32)), ~(1 << (offset % 32))) 617 5) address pattern (offset, ~offset) 618 619Patterns #1, #2 will help to find unstable bits. Patterns #3, #4 will 620be used to detect adherent bits, i.e. bits whose state may randomly 621change if adjacent bits are modified. The last pattern will be used 622to detect far-located errors, i.e. situations when writing to one 623location modifies an area located far from it. Also, usage of the 624last pattern will help to detect memory controller misconfigurations 625when RAM represents a cyclically repeated portion of a smaller size. 626 627Being run in normal mode, the test will verify only small 4Kb regions 628of RAM around each 1Mb boundary. For example, for 64Mb RAM the 629following areas will be verified: 0x00000000-0x00000800, 6300x000ff800-0x00100800, 0x001ff800-0x00200800, ..., 0x03fff800- 6310x04000000. If the test is run in power-fail mode, it will verify the 632whole RAM. 633 634The memory test will run in ROM before relocating U-Boot to RAM in 635order to allow RAM modification without saving its contents. 636 6372.2.2. Common tests 638 639This section describes tests that are not based on any hardware 640peculiarities and use common U-Boot interfaces only. These tests do 641not need any modifications for porting them to another board/CPU. 642 6432.2.2.1. I2C test 644 645For verifying the I2C bus, a full I2C bus scanning will be performed 646using the i2c_probe() routine. If a board defines 647CFG_SYS_POST_I2C_ADDRS the I2C test will pass if all devices 648listed in CFG_SYS_POST_I2C_ADDRS are found, and no additional 649devices are detected. If CFG_SYS_POST_I2C_ADDRS is not defined 650the test will pass if any I2C device is found. 651 652The CFG_SYS_POST_I2C_IGNORES define can be used to list I2C 653devices which may or may not be present when using 654CFG_SYS_POST_I2C_ADDRS. The I2C POST test will pass regardless 655if the devices in CFG_SYS_POST_I2C_IGNORES are found or not. 656This is useful in cases when I2C devices are optional (eg on a 657daughtercard that may or may not be present) or not critical 658to board operation. 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 707arch/powerpc/cpu/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 719arch/powerpc/cpu/mpc8xx/serial.c. 720 7212.2.3.3. USB test 722 723TBD 724 7252.2.3.4. SPI test 726 727TBD 728