wdenk | 43d9616 | 2003-03-06 00:02:04 +0000 | [diff] [blame] | 1 | Power-On-Self-Test support in U-Boot |
| 2 | ------------------------------------ |
| 3 | |
| 4 | This project is to support Power-On-Self-Test (POST) in U-Boot. |
| 5 | |
| 6 | 1. High-level requirements |
| 7 | |
| 8 | The key rquirements for this project are as follows: |
| 9 | |
| 10 | 1) 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 | |
| 28 | 2) The results of tests shall be saved so that it will be possible to |
| 29 | retrieve them from Linux. |
| 30 | |
| 31 | 3) 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 | |
| 45 | 4) The LWMON board shall be used for reference. |
| 46 | |
| 47 | 2. Design |
| 48 | |
| 49 | This section details the key points of the design for the project. |
| 50 | The whole project can be divided into two independent tasks: |
| 51 | enhancing U-Boot/Linux to provide a common framework for running POST |
| 52 | tests and developing such tests for particular hardware. |
| 53 | |
| 54 | 2.1. Hardware-independent POST layer |
| 55 | |
| 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 |
| 58 | support running POST tests manually at any time by executing a |
| 59 | special command from the system console. |
| 60 | |
| 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: |
| 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 | |
| 84 | If necessary, some tests may belong to several groups simultaneously. |
| 85 | For example, SDRAM test may run on both noarmal and power-fail |
| 86 | booting. On normal booting, SDRAM test may perform a fast superficial |
| 87 | memory test only, while running on power-fail booting it may perform |
| 88 | a full memory check-up. |
| 89 | |
| 90 | Also, all tests will be discriminated by the moment they run at. |
| 91 | Specifically, 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 | |
| 105 | The POST layer will also distinguish a special group of tests that |
| 106 | may cause system rebooting (e.g. watchdog test). For such tests, the |
| 107 | layer will automatically detect rebooting and will notify the test |
| 108 | about it. |
| 109 | |
| 110 | 2.1.1. POST layer interfaces |
| 111 | |
| 112 | This section details the interfaces between the POST layer and the |
| 113 | rest of U-Boot. |
| 114 | |
| 115 | The 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 | |
| 125 | The 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 | |
| 157 | Also, the following board-specific routines will be called from the |
| 158 | U-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 | |
| 171 | The list of available POST tests be kept in the post_tests array |
| 172 | filled at U-Boot build time. The format of entry in this array will |
| 173 | be as follows: |
| 174 | |
| 175 | struct 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, |
wdenk | 8564acf | 2003-07-14 22:13:32 +0000 | [diff] [blame] | 215 | POST_SLOWTEST, POST_MANUAL) and whether the last execution of |
wdenk | 43d9616 | 2003-03-06 00:02:04 +0000 | [diff] [blame] | 216 | 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 | |
| 220 | The lists of the POST tests that should be run at power-on/normal/ |
| 221 | power-fail booting will be kept in the environment. Namely, the |
| 222 | following environment variables will be used: post_poweron, |
wdenk | 8564acf | 2003-07-14 22:13:32 +0000 | [diff] [blame] | 223 | powet_normal, post_slowtest. |
wdenk | 43d9616 | 2003-03-06 00:02:04 +0000 | [diff] [blame] | 224 | |
| 225 | 2.1.2. Test results |
| 226 | |
| 227 | The results of tests will be collected by the POST layer. The POST |
| 228 | log will have the following format: |
| 229 | |
| 230 | ... |
| 231 | -------------------------------------------- |
| 232 | START <name> |
| 233 | <test-specific output> |
| 234 | [PASSED|FAILED] |
| 235 | -------------------------------------------- |
| 236 | ... |
| 237 | |
| 238 | Basically, the results of tests will be printed to stderr. This |
| 239 | feature may be enhanced in future to spool the log to a serial line, |
| 240 | save it in non-volatile RAM (NVRAM), transfer it to a dedicated |
| 241 | storage server and etc. |
| 242 | |
| 243 | 2.1.3. Integration issues |
| 244 | |
| 245 | All POST-related code will be #ifdef'ed with the CONFIG_POST macro. |
| 246 | This macro will be defined in the config_<board>.h file for those |
| 247 | boards that need POST. The CONFIG_POST macro will contain the list of |
| 248 | POST tests for the board. The macro will have the format of array |
| 249 | composed 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.", \ |
wdenk | 8564acf | 2003-07-14 22:13:32 +0000 | [diff] [blame] | 256 | POST_RAM | POST_SLOWTEST, \ |
wdenk | 43d9616 | 2003-03-06 00:02:04 +0000 | [diff] [blame] | 257 | &board_post_test \ |
| 258 | } |
| 259 | |
| 260 | A new file, post.h, will be created in the include/ directory. This |
| 261 | file will contain common POST declarations and will define a set of |
| 262 | macros that will be reused for defining CONFIG_POST. As an example, |
| 263 | the 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 | |
| 273 | A new subdirectory will be created in the U-Boot root directory. It |
| 274 | will contain the source code of the POST layer and most of POST |
| 275 | tests. Each POST test in this directory will be placed into a |
| 276 | separate file (it will be needed for building standalone tests). Some |
| 277 | POST tests (mainly those for testing peripheral devices) will be |
| 278 | located in the source files of the drivers for those devices. This |
| 279 | way will be used only if the test subtantially uses the driver. |
| 280 | |
| 281 | 2.1.4. Standalone tests |
| 282 | |
| 283 | The POST framework will allow to develop and run standalone tests. A |
| 284 | user-space library will be developed to provide the POST interface |
| 285 | functions to standalone tests. |
| 286 | |
| 287 | 2.1.5. Command line interface |
| 288 | |
| 289 | A new command, diag, will be added to U-Boot. This command will be |
| 290 | used for listing all available hardware tests, getting detailed |
| 291 | descriptions of them and running these tests. |
| 292 | |
| 293 | More specifically, being run without any arguments, this command will |
| 294 | print the list of all available hardware tests: |
| 295 | |
| 296 | => diag |
| 297 | Available hardware tests: |
| 298 | cache - cache test |
| 299 | cpu - CPU test |
| 300 | enet - SCC/FCC ethernet test |
| 301 | Use 'diag [<test1> [<test2>]] ... ' to get more info. |
| 302 | Use 'diag run [<test1> [<test2>]] ... ' to run tests. |
| 303 | => |
| 304 | |
| 305 | If the first argument to the diag command is not 'run', detailed |
| 306 | descriptions of the specified tests will be printed: |
| 307 | |
| 308 | => diag cpu cache |
| 309 | cpu - CPU test |
| 310 | This test verifies the arithmetic logic unit of CPU. |
| 311 | cache - cache test |
| 312 | This test verifies the CPU cache operation. |
| 313 | => |
| 314 | |
| 315 | If the first argument to diag is 'run', the specified tests will be |
| 316 | executed. If no tests are specified, all available tests will be |
| 317 | executed. |
| 318 | |
| 319 | It will be prohibited to execute tests running in ROM manually. The |
| 320 | 'diag' command will not display such tests and/or run them. |
| 321 | |
| 322 | 2.1.6. Power failure handling |
| 323 | |
| 324 | The Linux kernel will be modified to detect power failures and |
| 325 | automatically reboot the system in such cases. It will be assumed |
| 326 | that the power failure causes a system interrupt. |
| 327 | |
| 328 | To perform correct system shutdown, the kernel will register a |
| 329 | handler of the power-fail IRQ on booting. Being called, the handler |
| 330 | will run /sbin/reboot using the call_usermodehelper() routine. |
| 331 | /sbin/reboot will automatically bring the system down in a secure |
| 332 | way. This feature will be configured in/out from the kernel |
| 333 | configuration file. |
| 334 | |
| 335 | The POST layer of U-Boot will check whether the system runs in |
| 336 | power-fail mode. If it does, the system will be powered off after |
| 337 | executing all hardware tests. |
| 338 | |
| 339 | 2.1.7. Hazardous tests |
| 340 | |
| 341 | Some tests may cause system rebooting during their execution. For |
| 342 | some tests, this will indicate a failure, while for the Watchdog |
| 343 | test, this means successful operation of the timer. |
| 344 | |
| 345 | In order to support such tests, the following scheme will be |
| 346 | implemented. All the tests that may cause system rebooting will have |
| 347 | the POST_REBOOT bit flag set in the flag field of the correspondent |
| 348 | post_test structure. Before starting tests marked with this bit flag, |
| 349 | the POST layer will store an identification number of the test in a |
| 350 | location in IMMR. On booting, the POST layer will check the value of |
| 351 | this variable and if it is set will skip over the tests preceding the |
| 352 | failed one. On second execution of the failed test, the POST_REBOOT |
| 353 | bit flag will be set in the flag argument to the test routine. This |
| 354 | will allow to detect system rebooting on the previous iteration. For |
| 355 | example, the watchdog timer test may have the following |
| 356 | declaration/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 | ... |
| 369 | int 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 | |
| 388 | 2.2. Hardware-specific details |
| 389 | |
| 390 | This project will also develop a set of POST tests for MPC8xx- based |
| 391 | systems. This section provides technical details of how it will be |
| 392 | done. |
| 393 | |
| 394 | 2.2.1. Generic PPC tests |
| 395 | |
| 396 | The 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 | |
| 416 | 2.2.1.1. CPU test |
| 417 | |
| 418 | This 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 | |
| 522 | The CPU test will run in RAM in order to allow run-time modification |
| 523 | of the code to reduce the memory footprint. |
| 524 | |
| 525 | 2.2.1.2 Special-Purpose Registers Tests |
| 526 | |
| 527 | TBD. |
| 528 | |
| 529 | 2.2.1.3. Cache test |
| 530 | |
| 531 | To verify the data cache operation the following test scenarios will |
| 532 | be 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 | |
| 583 | To verify the instruction cache operation the following test |
| 584 | scenarios 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 | |
| 608 | The CPU test will run in RAM in order to allow run-time modification |
| 609 | of the code. |
| 610 | |
| 611 | 2.2.1.4. Memory test |
| 612 | |
| 613 | The memory test will verify RAM using sequential writes and reads |
| 614 | to/from RAM. Specifically, there will be several test cases that will |
| 615 | use different patterns to verify RAM. Each test case will first fill |
| 616 | a region of RAM with one pattern and then read the region back and |
| 617 | compare its contents with the pattern. The following patterns will be |
| 618 | used: |
| 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 | |
| 626 | Patterns #1, #2 will help to find unstable bits. Patterns #3, #4 will |
| 627 | be used to detect adherent bits, i.e. bits whose state may randomly |
| 628 | change if adjacent bits are modified. The last pattern will be used |
| 629 | to detect far-located errors, i.e. situations when writing to one |
| 630 | location modifies an area located far from it. Also, usage of the |
| 631 | last pattern will help to detect memory controller misconfigurations |
| 632 | when RAM represents a cyclically repeated portion of a smaller size. |
| 633 | |
| 634 | Being run in normal mode, the test will verify only small 4Kb regions |
| 635 | of RAM around each 1Mb boundary. For example, for 64Mb RAM the |
| 636 | following areas will be verified: 0x00000000-0x00000800, |
| 637 | 0x000ff800-0x00100800, 0x001ff800-0x00200800, ..., 0x03fff800- |
| 638 | 0x04000000. If the test is run in power-fail mode, it will verify the |
| 639 | whole RAM. |
| 640 | |
| 641 | The memory test will run in ROM before relocating U-Boot to RAM in |
| 642 | order to allow RAM modification without saving its contents. |
| 643 | |
| 644 | 2.2.2. Common tests |
| 645 | |
| 646 | This section describes tests that are not based on any hardware |
| 647 | peculiarities and use common U-Boot interfaces only. These tests do |
| 648 | not need any modifications for porting them to another board/CPU. |
| 649 | |
| 650 | 2.2.2.1. I2C test |
| 651 | |
| 652 | For verifying the I2C bus, a full I2C bus scanning will be performed |
| 653 | using the i2c_probe() routine. If any I2C device is found, the test |
| 654 | will be considered as passed, otherwise failed. This particular way |
| 655 | will be used because it provides the most common method of testing. |
| 656 | For example, using the internal loopback mode of the CPM I2C |
| 657 | controller for testing would not work on boards where the software |
| 658 | I2C driver (also known as bit-banged driver) is used. |
| 659 | |
| 660 | 2.2.2.2. Watchdog timer test |
| 661 | |
| 662 | To test the watchdog timer the scheme mentioned above (refer to |
| 663 | section "Hazardous tests") will be used. Namely, this test will be |
| 664 | marked with the POST_REBOOT bit flag. On the first iteration, the |
| 665 | test routine will make a 10-second delay. If the system does not |
| 666 | reboot during this delay, the watchdog timer is not operational and |
| 667 | the test fails. If the system reboots, on the second iteration the |
| 668 | POST_REBOOT bit will be set in the flag argument to the test routine. |
| 669 | The test routine will check this bit and report a success if it is |
| 670 | set. |
| 671 | |
| 672 | 2.2.2.3. RTC test |
| 673 | |
| 674 | The RTC test will use the rtc_get()/rtc_set() routines. The following |
| 675 | features 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 | |
| 688 | 2.2.3. MPC8xx peripherals tests |
| 689 | |
| 690 | This project will develop a set of tests verifying the peripheral |
| 691 | units of MPC8xx processors. Namely, the following controllers of the |
| 692 | MPC8xx communication processor module (CPM) will be tested: |
| 693 | |
| 694 | o) Serial Management Controllers (SMC) |
| 695 | |
| 696 | o) Serial Communication Controllers (SCC) |
| 697 | |
| 698 | 2.2.3.1. Ethernet tests (SCC) |
| 699 | |
| 700 | The internal (local) loopback mode will be used to test SCC. To do |
| 701 | that the controllers will be configured accordingly and several |
| 702 | packets will be transmitted. These tests may be enhanced in future to |
| 703 | use external loopback for testing. That will need appropriate |
| 704 | reconfiguration of the physical interface chip. |
| 705 | |
| 706 | The test routines for the SCC ethernet tests will be located in |
| 707 | cpu/mpc8xx/scc.c. |
| 708 | |
| 709 | 2.2.3.2. UART tests (SMC/SCC) |
| 710 | |
| 711 | To perform these tests the internal (local) loopback mode will be |
| 712 | used. The SMC/SCC controllers will be configured to connect the |
| 713 | transmitter output to the receiver input. After that, several bytes |
| 714 | will be transmitted. These tests may be enhanced to make to perform |
| 715 | "external" loopback test using a loopback cable. In this case, the |
| 716 | test will be executed manually. |
| 717 | |
| 718 | The test routine for the SMC/SCC UART tests will be located in |
| 719 | cpu/mpc8xx/serial.c. |
| 720 | |
| 721 | 2.2.3.3. USB test |
| 722 | |
| 723 | TBD |
| 724 | |
| 725 | 2.2.3.4. SPI test |
| 726 | |
| 727 | TBD |
| 728 | |
| 729 | 2.3. Design notes |
| 730 | |
| 731 | Currently it is unknown how we will power off the board after running |
| 732 | all power-fail POST tests. This point needs further clarification. |