README.POST 26 KB

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