1. High-level requirements
-The key rquirements for this project are as follows:
+The key requirements for this project are as follows:
1) The project shall develop a flexible framework for implementing
and running Power-On-Self-Test in U-Boot. This framework shall
This group will contain those tests that do not take much
time and can be run on the regular basis (e.g. CPU test)
- 3) Tests running on power-fail booting only
+ 3) Tests running in special "slow test mode" only
This group will contain POST tests that consume much time
- and cannot be run regularly (e.g. I2C test)
+ and cannot be run regularly (e.g. strong memory test, I2C test)
4) Manually executed tests
This group will contain those tests that can be run manually.
If necessary, some tests may belong to several groups simultaneously.
-For example, SDRAM test may run on both noarmal and power-fail
-booting. On normal booting, SDRAM test may perform a fast superficial
-memory test only, while running on power-fail booting it may perform
-a full memory check-up.
+For example, SDRAM test may run in both normal and "slow test" mode.
+In normal mode, SDRAM test may perform a fast superficial memory test
+only, while running in slow test mode it may perform a full memory
+check-up.
Also, all tests will be discriminated by the moment they run at.
Specifically, the following groups will be singled out:
1) Tests running before relocating to RAM
- These tests will run immediatelly after initializing RAM
+ These tests will run immediately after initializing RAM
as to enable modifying it without taking care of its
contents. Basically, this group will contain memory tests
only.
The following flags will be defined:
-#define POST_ROM 0x01 /* test runs in ROM */
-#define POST_RAM 0x02 /* test runs in RAM */
-#define POST_POWERON 0x04 /* test runs on power-on booting */
-#define POST_NORMAL 0x08 /* test runs on normal booting */
-#define POST_SHUTDOWN 0x10 /* test runs on power-fail booting */
-#define POST_MANUAL 0x20 /* test can be executed manually */
-#define POST_REBOOT 0x80 /* test may cause rebooting */
+#define POST_POWERON 0x01 /* test runs on power-on booting */
+#define POST_NORMAL 0x02 /* test runs on normal booting */
+#define POST_SLOWTEST 0x04 /* test is slow, enabled by key press */
+#define POST_POWERTEST 0x08 /* test runs after watchdog reset */
+#define POST_ROM 0x100 /* test runs in ROM */
+#define POST_RAM 0x200 /* test runs in RAM */
+#define POST_MANUAL 0x400 /* test can be executed manually */
+#define POST_REBOOT 0x800 /* test may cause rebooting */
+#define POST_PREREL 0x1000 /* test runs before relocation */
The POST layer will export the following interface routines:
will be called on power-fail booting after running all POST
tests.
+ o) int post_hotkeys_pressed(gd_t *gd)
+
+ This routine will scan the keyboard to detect if a magic key
+ combination has been pressed, or otherwise detect if the
+ power-on long-running tests shall be executed or not ("normal"
+ versus "slow" test mode).
+
The list of available POST tests be kept in the post_tests array
filled at U-Boot build time. The format of entry in this array will
be as follows:
argument will be a pointer to the board info structure, while
the second will be a combination of bit flags specifying the
mode the test is running in (POST_POWERON, POST_NORMAL,
- POST_POWERFAIL, POST_MANUAL) and whether the last execution of
+ POST_SLOWTEST, POST_MANUAL) and whether the last execution of
the test caused system rebooting (POST_REBOOT). The routine will
return 0 on successful execution of the test, and 1 if the test
failed.
The lists of the POST tests that should be run at power-on/normal/
power-fail booting will be kept in the environment. Namely, the
following environment variables will be used: post_poweron,
-powet_normal, post_shutdown.
+powet_normal, post_slowtest.
2.1.2. Test results
"On-board peripherals test", "board", \
" This test performs full check-up of the " \
"on-board hardware.", \
- POST_RAM | POST_POWERFAIL, \
+ POST_RAM | POST_SLOWTEST, \
&board_post_test \
}
This group will contain: b, bl, bc.
The first 2 instructions (b, bl) will be verified by jumping to
- a fixed address and checking whether control was transfered to
+ a fixed address and checking whether control was transferred to
that very point. For the bl instruction the value of the link
register will be checked as well (using mfspr). To verify the bc
instruction various combinations of the BI/BO fields, the CTR
2.2.2.1. I2C test
For verifying the I2C bus, a full I2C bus scanning will be performed
-using the i2c_probe() routine. If any I2C device is found, the test
-will be considered as passed, otherwise failed. This particular way
-will be used because it provides the most common method of testing.
-For example, using the internal loopback mode of the CPM I2C
-controller for testing would not work on boards where the software
-I2C driver (also known as bit-banged driver) is used.
+using the i2c_probe() routine. If a board defines
+CONFIG_SYS_POST_I2C_ADDRS the I2C test will pass if all devices
+listed in CONFIG_SYS_POST_I2C_ADDRS are found, and no additional
+devices are detected. If CONFIG_SYS_POST_I2C_ADDRS is not defined
+the test will pass if any I2C device is found.
+
+The CONFIG_SYS_POST_I2C_IGNORES define can be used to list I2C
+devices which may or may not be present when using
+CONFIG_SYS_POST_I2C_ADDRS. The I2C POST test will pass regardless
+if the devices in CONFIG_SYS_POST_I2C_IGNORES are found or not.
+This is useful in cases when I2C devices are optional (eg on a
+daughtercard that may or may not be present) or not critical
+to board operation.
2.2.2.2. Watchdog timer test
reconfiguration of the physical interface chip.
The test routines for the SCC ethernet tests will be located in
-cpu/mpc8xx/scc.c.
+arch/powerpc/cpu/mpc8xx/scc.c.
2.2.3.2. UART tests (SMC/SCC)
test will be executed manually.
The test routine for the SMC/SCC UART tests will be located in
-cpu/mpc8xx/serial.c.
+arch/powerpc/cpu/mpc8xx/serial.c.
2.2.3.3. USB test
2.2.3.4. SPI test
TBD
-
-2.3. Design notes
-
-Currently it is unknown how we will power off the board after running
-all power-fail POST tests. This point needs further clarification.