]> git.kernelconcepts.de Git - karo-tx-uboot.git/blobdiff - doc/README.POST
karo: tx28: request gpio for acitivity LED and disable LED on failure
[karo-tx-uboot.git] / doc / README.POST
index 3d882311aaed5abad1080029008c3fbc89e39004..6815d491cf4fbcaf790c332722257a279564e54e 100644 (file)
@@ -5,7 +5,7 @@ This project is to support Power-On-Self-Test (POST) in U-Boot.
 
 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
@@ -72,27 +72,27 @@ tests. All POST tests will be divided into the following groups:
      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.
@@ -114,13 +114,15 @@ rest of U-Boot.
 
 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:
 
@@ -168,6 +170,13 @@ U-Boot common code:
      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:
@@ -650,12 +659,19 @@ not need any modifications for porting them to another board/CPU.
 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
 
@@ -704,7 +720,7 @@ use external loopback for testing. That will need appropriate
 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)
 
@@ -716,7 +732,7 @@ will be transmitted. These tests may be enhanced to make to perform
 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
 
@@ -725,8 +741,3 @@ TBD
 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.