Merge branch 'u-boot-atmel/master' into 'u-boot-arm/master'

[karo-tx-uboot.git] / board / ti / am335x / README

diff --git a/board/ti/am335x/README b/board/ti/am335x/README
index ccc5e16066fd13b82322be46f397504faf2020de..2a30ab89817df5881aca0a75241df847715f2a92 100644 (file)
--- a/board/ti/am335x/README
+++ b/board/ti/am335x/README
@@ -14,6 +14,79 @@ documented in TI's reference designs:
 - Beaglebone White
 - Beaglebone Black
 
+Customization
+=============
+
+Given that all of the above boards are reference platforms (and the
+Beaglebone platforms are OSHA), it is likely that this platform code and
+configuration will be used as the basis of a custom platform.  It is
+worth noting that aside from things such as NAND or MMC only being
+required if a custom platform makes use of these blocks, the following
+are required, depending on design:
+
+- GPIO is only required if DDR3 power is controlled in a way similar to
+  EVM SK
+- SPI is only required for SPI flash, or exposing the SPI bus.
+
+The following blocks are required:
+- I2C, to talk with the PMIC and ensure that we do not run afoul of
+  errata 1.0.24.
+
+When removing options as part of customization,
+CONFIG_EXTRA_ENV_SETTINGS will need additional care to update for your
+needs and to remove no longer relevant options as in some cases we
+define additional text blocks (such as for NAND or DFU strings).  Also
+note that all of the SPL options are grouped together, rather than with
+the IP blocks, so both areas will need their choices updated to reflect
+the custom design.
+
+NAND
+====
+
+The AM335x GP EVM ships with a 256MiB NAND available in most profiles.  In
+this example to program the NAND we assume that an SD card has been
+inserted with the files to write in the first SD slot and that mtdparts
+have been configured correctly for the board.  As a time saving measure we
+load MLO into memory in one location, copy it into the three locatations
+that the ROM checks for additional valid copies, then load U-Boot into
+memory.  We then write that whole section of memory to NAND.
+
+U-Boot # mmc rescan
+U-Boot # env default -f -a
+U-Boot # nand erase.chip
+U-Boot # saveenv
+U-Boot # load mmc 0 81000000 MLO
+U-Boot # cp.b 81000000 81020000 20000
+U-Boot # cp.b 81000000 81040000 20000
+U-Boot # cp.b 81000000 81060000 20000
+U-Boot # load mmc 0 81080000 u-boot.img
+U-Boot # nand write 81000000 0 260000
+U-Boot # load mmc 0 ${loadaddr} uImage
+U-Boot # nand write ${loadaddr} kernel 500000
+
+NOR
+===
+
+The Beaglebone White can be equiped with a "memory cape" that in turn can
+have a NOR module plugged into it.  In this case it is then possible to
+program and boot from NOR.  Note that due to how U-Boot is architectured we
+must build a specific version of U-Boot that knows we have NOR flash.  This
+build is named 'am335x_evm_nor'.  Further, we have a 'am335x_evm_norboot'
+build that will assume that the environment is on NOR rather than NAND.  In
+the following example we assume that and SD card has been populated with
+MLO and u-boot.img from a 'am335x_evm_nor' build and also contains the
+'u-boot.bin' from a 'am335x_evm_norboot' build.  When booting from NOR, a
+binary must be written to the start of NOR, with no header or similar
+prepended.  In the following example we use a size of 512KiB (0x80000)
+as that is how much space we set aside before the environment, as per
+the config file.
+
+U-Boot # mmc rescan
+U-Boot # load mmc 0 ${loadaddr} u-boot.bin
+U-Boot # protect off 08000000 +80000
+U-Boot # erase 08000000 +80000
+U-Boot # cp.b ${loadaddr} 08000000 ${filesize}
+
 Falcon Mode
 ===========