diff options
| author | Paul Gortmaker <paul.gortmaker@windriver.com> | 2009-09-25 11:14:11 -0400 |
|---|---|---|
| committer | Kumar Gala <galak@kernel.crashing.org> | 2009-09-30 08:29:47 -0500 |
| commit | dd9ca98f2600000e5c2744735040100b770650e7 (patch) | |
| tree | 0eeacea3bc8b43a5025fbadeb808166a0c94962d /doc | |
| parent | 8280912e0657e96a7b7d8da7003656d62b0fd109 (diff) | |
| download | u-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.sbc8548 | 24 |
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: =================== |