summaryrefslogtreecommitdiff
path: root/doc
diff options
context:
space:
mode:
authorPaul Gortmaker <paul.gortmaker@windriver.com>2009-09-25 11:14:11 -0400
committerKumar Gala <galak@kernel.crashing.org>2009-09-30 08:29:47 -0500
commitdd9ca98f2600000e5c2744735040100b770650e7 (patch)
tree0eeacea3bc8b43a5025fbadeb808166a0c94962d /doc
parent8280912e0657e96a7b7d8da7003656d62b0fd109 (diff)
downloadu-boot-imx-dd9ca98f2600000e5c2744735040100b770650e7.zip
u-boot-imx-dd9ca98f2600000e5c2744735040100b770650e7.tar.gz
u-boot-imx-dd9ca98f2600000e5c2744735040100b770650e7.tar.bz2
sbc8548: reclaim wasted sector in boot flash
By nature of being based off the MPC8548CDS board, this board inherited an ENV_SIZE setting of 256k. But since it has a smaller flash device (8MB soldered on), it has a native sector size of 128k, and hence the ENV_SIZE was causing 2 sectors to be used for the environment. By removing the unused sector, we can push TEXT_BASE up closer to the end of address space and reclaim that sector for any other application. This also fixes the mismatch between TEXT_BASE and MONITOR_LEN reported by Kumar earlier. Since this board also supports the ability to boot off the 64MB SODIMM flash, this change is forward looking with that in mind; i.e. the settings for MONITOR_LEN and ENV_SIZE will work when the 512k sectors of the SODIMM flash are used for alternate boot in the future. Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com> Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
Diffstat (limited to 'doc')
-rw-r--r--doc/README.sbc854824
1 files changed, 24 insertions, 0 deletions
diff --git a/doc/README.sbc8548 b/doc/README.sbc8548
index d72d97d..6cbe12f 100644
--- a/doc/README.sbc8548
+++ b/doc/README.sbc8548
@@ -63,6 +63,30 @@ a 33MHz PCI configuration is currently untested.)
=>
+Updating U-boot with U-boot:
+============================
+
+Note that versions of u-boot up to and including 2009.08 had u-boot stored
+at 0xfff8_0000 -> 0xffff_ffff (512k). Currently it is being stored from
+0xfffa_0000 -> 0xffff_ffff (384k). If you use an old macro/script to
+update u-boot with u-boot and it uses the old address, you will render
+your board inoperable, and you will require JTAG recovery.
+
+The following steps list how to update with the current address:
+
+ tftp u-boot.bin
+ md 200000 10
+ protect off all
+ erase fffa0000 ffffffff
+ cp.b 200000 fffa0000 60000
+ md fffa0000 10
+ protect on all
+
+The "md" steps in the above are just a precautionary step that allow
+you to confirm the u-boot version that was downloaded, and then confirm
+that it was copied to flash.
+
+
Hardware Reference:
===================