projects / J-u-boot.git / blame
| Commit | Line | Data |
|---|---|---|
| 779e9751 SR |
1 | |
| 2 | Storage of the board specific values (ethaddr...) | |
| 3 | ------------------------------------------------- | |
| 4 | ||
| 5 | The board specific environment variables that should be unique | |
| 6 | for each individual board, can be stored in the I2C EEPROM. This | |
| 7 | will be done from offset 0x80 with the length of 0x80 bytes. The | |
| 8 | following command can be used to store the values here: | |
| 9 | ||
| 10 | => setdef de:20:6a:ed:e2:72 de:20:6a:ed:e2:73 AB0001 | |
| 11 | ||
| 12 | ethaddr eth1addr serial# | |
| 13 | ||
| 14 | Now those 3 values are stored into the I2C EEPROM. A CRC is added | |
| 15 | to make sure that the values get not corrupted. | |
| 16 | ||
| 17 | ||
| 18 | SW-Reset Pushbutton handling: | |
| 19 | ----------------------------- | |
| 20 | ||
| 21 | The SW-reset push button is connected to a GPIO input too. This | |
| 22 | way U-Boot can "see" how long the SW-reset was pressed, and a | |
| 23 | specific action can be taken. Two different actions are supported: | |
| 24 | ||
| 25 | a) Release after more than 5 seconds and less then 10 seconds: | |
| 26 | -> Run POST | |
| 27 | ||
| 28 | Please note, that the POST test will take a while (approx. 1 min | |
| 29 | on the 128MByte board). This is mainly due to the system memory | |
| 30 | test. | |
| 31 | ||
| 32 | b) Release after more than 10 seconds: | |
| 33 | -> Restore factory default settings | |
| 34 | ||
| 35 | The factory default values are restored. The default environment | |
| 36 | variables are restored (ipaddr, serverip...) and the board | |
| 37 | specific values (ethaddr, eth1addr and serial#) are restored | |
| 38 | to the environment from the I2C EEPROM. Also a bootline parameter | |
| 39 | is added to the Linux bootline to signal the Linux kernel upon | |
| 40 | the next startup, that the factory defaults should be restored. | |
| 41 | ||
| 42 | The command to check this sw-reset status and act accordingly is | |
| 43 | ||
| 44 | => chkreset | |
| 45 | ||
| 46 | This command is added to the default "bootcmd", so that it is called | |
| 47 | automatically upon startup. | |
| 48 | ||
| 49 | Also, the 2 LED's are used to indicate the current status of this | |
| 50 | command (time passed since pushing the button). When the POST test | |
| 51 | will be run, the green LED will be switched off, and when the | |
| 52 | factory restore will be initiated, the reg LED will be switched off. | |
| 53 | ||
| 54 | ||
| 55 | Loggin of POST results: | |
| 56 | ----------------------- | |
| 57 | ||
| 58 | The results of the POST tests are logged in a logbuffer located at the end | |
| 59 | of the onboard memory. It can be accessed with the U-Boot command "log": | |
| 60 | ||
| 61 | => log show | |
| 62 | <4>POST memory PASSED | |
| 63 | <4>POST cache PASSED | |
| 64 | <4>POST cpu PASSED | |
| 65 | <4>POST uart PASSED | |
| 66 | <4>POST ethernet PASSED | |
| 67 | ||
| 68 | The DENX Linux kernel tree has support for this log buffer included. Exactly | |
| 69 | this buffer is used for logging of all kernel messages too. By enabling the | |
| 70 | compile time option "CONFIG_LOGBUFFER" this support is enabled. This way you | |
| 71 | can access the U-Boot log messages from Linux too. | |
| 72 | ||
| 73 | 2007-08-10, Stefan Roese <[email protected]> |