The current situation has the 64MB user flash at an awkward
alignment; shifted back from 0xfc00_0000 by 8M, to leave an 8MB hole
for the soldered on boot flash @ EOM. But to switch to optionally
supporting booting off the 64MB flash, the 64MB will then be mapped
at the sane address of 0xfc00_0000.
This leads to awkward things when programming the 64MB flash prior
to transitioning to it -- i.e. even though the chip spans from
0xfb80_0000 to 0xff7f_ffff, you would have to program a u-boot image
into the two sectors from 0xfbf0_0000 --> 0xfbff_ffff so that it was
in the right place when JP12/SW2.8 were switched to make the 64MB on
/CS0. (i.e. the chip is only looking at the bits in mask 0x3ff_ffff)
We also have to have three TLB entries responsible for dealing with
mapping the 64MB flash due to this 8MB of misalignment.
In the end, there is address space from 0xec00_0000 to 0xefff_ffff
where we can map it, and then the transition from booting from one
config to the other will be a simple 0xec --> 0xfc mapping. Plus we
can toss out a TLB entry.
Note that TLB0 is kept at 64MB and not shrunk down to the 8MB boot
flash; this means we won't have to change it when the alternate
config uses the full 64MB for booting, in TLB0.
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
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>
3fd673cf36