u-boot/board/zeus
Masahiro Yamada 93d4334f7f Add board MAINTAINERS files
We have switched to Kconfig and the boards.cfg file is going to
be removed. We have to retrieve the board status and maintainers
information from it.

The MAINTAINERS format as in Linux Kernel would be nice
because we can crib the scripts/get_maintainer.pl script.

After some discussion, we chose to put a MAINTAINERS file under each
board directory, not the top-level one because we want to collect
relevant information for a board into a single place.

TODO:
Modify get_maintainer.pl to scan multiple MAINTAINERS files.

Signed-off-by: Masahiro Yamada <yamada.m@jp.panasonic.com>
Suggested-by: Tom Rini <trini@ti.com>
Acked-by: Simon Glass <sjg@chromium.org>
2014-07-30 08:48:06 -04:00
..
Kconfig kconfig: add board Kconfig and defconfig files 2014-07-30 08:48:01 -04:00
MAINTAINERS Add board MAINTAINERS files 2014-07-30 08:48:06 -04:00
Makefile board: powerpc: convert makefiles to Kbuild style 2013-11-01 11:42:12 -04:00
README doc: cleanup - move board READMEs into respective board directories 2012-07-29 15:42:02 +02:00
update.c Add GPL-2.0+ SPDX-License-Identifier to source files 2013-07-24 09:44:38 -04:00
zeus.c Add GPL-2.0+ SPDX-License-Identifier to source files 2013-07-24 09:44:38 -04:00

Storage of the board specific values (ethaddr...)
-------------------------------------------------

The board specific environment variables that should be unique
for each individual board, can be stored in the I2C EEPROM. This
will be done from offset 0x80 with the length of 0x80 bytes. The
following command can be used to store the values here:

=> setdef de:20:6a:ed:e2:72 de:20:6a:ed:e2:73 AB0001

	  ethaddr           eth1addr          serial#

Now those 3 values are stored into the I2C EEPROM. A CRC is added
to make sure that the values get not corrupted.


SW-Reset Pushbutton handling:
-----------------------------

The SW-reset push button is connected to a GPIO input too. This
way U-Boot can "see" how long the SW-reset was pressed, and a
specific action can be taken. Two different actions are supported:

a) Release after more than 5 seconds and less then 10 seconds:
   -> Run POST

   Please note, that the POST test will take a while (approx. 1 min
   on the 128MByte board). This is mainly due to the system memory
   test.

b) Release after more than 10 seconds:
   -> Restore factory default settings

   The factory default values are restored. The default environment
   variables are restored (ipaddr, serverip...) and the board
   specific values (ethaddr, eth1addr and serial#) are restored
   to the environment from the I2C EEPROM. Also a bootline parameter
   is added to the Linux bootline to signal the Linux kernel upon
   the next startup, that the factory defaults should be restored.

The command to check this sw-reset status and act accordingly is

=> chkreset

This command is added to the default "bootcmd", so that it is called
automatically upon startup.

Also, the 2 LED's are used to indicate the current status of this
command (time passed since pushing the button). When the POST test
will be run, the green LED will be switched off, and when the
factory restore will be initiated, the reg LED will be switched off.


Loggin of POST results:
-----------------------

The results of the POST tests are logged in a logbuffer located at the end
of the onboard memory. It can be accessed with the U-Boot command "log":

=> log show
<4>POST memory PASSED
<4>POST cache PASSED
<4>POST cpu PASSED
<4>POST uart PASSED
<4>POST ethernet PASSED

The DENX Linux kernel tree has support for this log buffer included. Exactly
this buffer is used for logging of all kernel messages too. By enabling the
compile time option "CONFIG_LOGBUFFER" this support is enabled. This way you
can access the U-Boot log messages from Linux too.

2007-08-10, Stefan Roese <sr@denx.de>