- 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. All images are first loaded
+into memory, then written to NAND.
+
+Step-1: Building u-boot for NAND boot
+ Set following CONFIGxx options for NAND device.
+ CONFIG_SYS_NAND_PAGE_SIZE number of main bytes in NAND page
+ CONFIG_SYS_NAND_OOBSIZE number of OOB bytes in NAND page
+ CONFIG_SYS_NAND_BLOCK_SIZE number of bytes in NAND erase-block
+ CONFIG_SYS_NAND_ECCPOS ECC map for NAND page
+ CONFIG_NAND_OMAP_ECCSCHEME (refer doc/README.nand)
+
+Step-2: Flashing NAND via MMC/SD
+ # select BOOTSEL to MMC/SD boot and boot from MMC/SD card
+ U-Boot # mmc rescan
+ # erase flash
+ U-Boot # nand erase.chip
+ U-Boot # env default -f -a
+ U-Boot # saveenv
+ # flash MLO. Redundant copies of MLO are kept for failsafe
+ U-Boot # load mmc 0 0x82000000 MLO
+ U-Boot # nand write 0x82000000 0x00000 0x20000
+ U-Boot # nand write 0x82000000 0x20000 0x20000
+ U-Boot # nand write 0x82000000 0x40000 0x20000
+ U-Boot # nand write 0x82000000 0x60000 0x20000
+ # flash u-boot.img
+ U-Boot # load mmc 0 0x82000000 u-boot.img
+ U-Boot # nand write 0x82000000 0x80000 0x60000
+ # flash kernel image
+ U-Boot # load mmc 0 0x82000000 uImage
+ U-Boot # nand write 0x82000000 ${nandsrcaddr} ${nandimgsize}
+ # flash filesystem image
+ U-Boot # load mmc 0 0x82000000 filesystem.img
+ U-Boot # nand write 0x82000000 ${loadaddress} 0x300000
+
+Step-3: Set BOOTSEL pin to select NAND boot, and POR the device.
+ The device should boot from images flashed on NAND device.
+
+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
===========
projects / karo-tx-uboot.git / blobdiff