README 8.2 KB

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146147148149150151152153154155156157158159160161162163164165166167168169170171172173174175176177178179180181182183184185186187188189190191192193194195196197198199200201202203204205
  1. Summary
  2. =======
  3. This document covers various features of the 'am335x_evm' build, and some of
  4. the related build targets (am335x_evm_uartN, etc).
  5. Hardware
  6. ========
  7. The binary produced by this board supports, based on parsing of the EEPROM
  8. documented in TI's reference designs:
  9. - AM335x GP EVM
  10. - AM335x EVM SK
  11. - Beaglebone White
  12. - Beaglebone Black
  13. Customization
  14. =============
  15. Given that all of the above boards are reference platforms (and the
  16. Beaglebone platforms are OSHA), it is likely that this platform code and
  17. configuration will be used as the basis of a custom platform. It is
  18. worth noting that aside from things such as NAND or MMC only being
  19. required if a custom platform makes use of these blocks, the following
  20. are required, depending on design:
  21. - GPIO is only required if DDR3 power is controlled in a way similar to
  22. EVM SK
  23. - SPI is only required for SPI flash, or exposing the SPI bus.
  24. The following blocks are required:
  25. - I2C, to talk with the PMIC and ensure that we do not run afoul of
  26. errata 1.0.24.
  27. When removing options as part of customization,
  28. CONFIG_EXTRA_ENV_SETTINGS will need additional care to update for your
  29. needs and to remove no longer relevant options as in some cases we
  30. define additional text blocks (such as for NAND or DFU strings). Also
  31. note that all of the SPL options are grouped together, rather than with
  32. the IP blocks, so both areas will need their choices updated to reflect
  33. the custom design.
  34. NAND
  35. ====
  36. The AM335x GP EVM ships with a 256MiB NAND available in most profiles. In
  37. this example to program the NAND we assume that an SD card has been
  38. inserted with the files to write in the first SD slot and that mtdparts
  39. have been configured correctly for the board. All images are first loaded
  40. into memory, then written to NAND.
  41. Step-1: Building u-boot for NAND boot
  42. Set following CONFIGxx options for NAND device.
  43. CONFIG_SYS_NAND_PAGE_SIZE number of main bytes in NAND page
  44. CONFIG_SYS_NAND_OOBSIZE number of OOB bytes in NAND page
  45. CONFIG_SYS_NAND_BLOCK_SIZE number of bytes in NAND erase-block
  46. CONFIG_SYS_NAND_ECCPOS ECC map for NAND page
  47. CONFIG_NAND_OMAP_ECCSCHEME (refer doc/README.nand)
  48. Step-2: Flashing NAND via MMC/SD
  49. # select BOOTSEL to MMC/SD boot and boot from MMC/SD card
  50. U-Boot # mmc rescan
  51. # erase flash
  52. U-Boot # nand erase.chip
  53. U-Boot # env default -f -a
  54. U-Boot # saveenv
  55. # flash MLO. Redundant copies of MLO are kept for failsafe
  56. U-Boot # load mmc 0 0x82000000 MLO
  57. U-Boot # nand write 0x82000000 0x00000 0x20000
  58. U-Boot # nand write 0x82000000 0x20000 0x20000
  59. U-Boot # nand write 0x82000000 0x40000 0x20000
  60. U-Boot # nand write 0x82000000 0x60000 0x20000
  61. # flash u-boot.img
  62. U-Boot # load mmc 0 0x82000000 u-boot.img
  63. U-Boot # nand write 0x82000000 0x80000 0x60000
  64. # flash kernel image
  65. U-Boot # load mmc 0 0x82000000 uImage
  66. U-Boot # nand write 0x82000000 ${nandsrcaddr} ${nandimgsize}
  67. # flash filesystem image
  68. U-Boot # load mmc 0 0x82000000 filesystem.img
  69. U-Boot # nand write 0x82000000 ${loadaddress} 0x300000
  70. Step-3: Set BOOTSEL pin to select NAND boot, and POR the device.
  71. The device should boot from images flashed on NAND device.
  72. NOR
  73. ===
  74. The Beaglebone White can be equipped with a "memory cape" that in turn can
  75. have a NOR module plugged into it. In this case it is then possible to
  76. program and boot from NOR. Note that due to how U-Boot is designed we
  77. must build a specific version of U-Boot that knows we have NOR flash. This
  78. build is named 'am335x_evm_nor'. Further, we have a 'am335x_evm_norboot'
  79. build that will assume that the environment is on NOR rather than NAND. In
  80. the following example we assume that and SD card has been populated with
  81. MLO and u-boot.img from a 'am335x_evm_nor' build and also contains the
  82. 'u-boot.bin' from a 'am335x_evm_norboot' build. When booting from NOR, a
  83. binary must be written to the start of NOR, with no header or similar
  84. prepended. In the following example we use a size of 512KiB (0x80000)
  85. as that is how much space we set aside before the environment, as per
  86. the config file.
  87. U-Boot # mmc rescan
  88. U-Boot # load mmc 0 ${loadaddr} u-boot.bin
  89. U-Boot # protect off 08000000 +80000
  90. U-Boot # erase 08000000 +80000
  91. U-Boot # cp.b ${loadaddr} 08000000 ${filesize}
  92. Falcon Mode
  93. ===========
  94. The default build includes "Falcon Mode" (see doc/README.falcon) via NAND,
  95. eMMC (or raw SD cards) and FAT SD cards. Our default behavior currently is
  96. to read a 'c' on the console while in SPL at any point prior to loading the
  97. OS payload (so as soon as possible) to opt to booting full U-Boot. Also
  98. note that while one can program Falcon Mode "in place" great care needs to
  99. be taken by the user to not 'brick' their setup. As these are all eval
  100. boards with multiple boot methods, recovery should not be an issue in this
  101. worst-case however.
  102. Falcon Mode: eMMC
  103. =================
  104. The recommended layout in this case is:
  105. MMC BLOCKS |--------------------------------| LOCATION IN BYTES
  106. 0x0000 - 0x007F : MBR or GPT table : 0x000000 - 0x020000
  107. 0x0080 - 0x00FF : ARGS or FDT file : 0x010000 - 0x020000
  108. 0x0100 - 0x01FF : SPL.backup1 (first copy used) : 0x020000 - 0x040000
  109. 0x0200 - 0x02FF : SPL.backup2 (second copy used) : 0x040000 - 0x060000
  110. 0x0300 - 0x06FF : U-Boot : 0x060000 - 0x0e0000
  111. 0x0700 - 0x08FF : U-Boot Env + Redundant : 0x0e0000 - 0x120000
  112. 0x0900 - 0x28FF : Kernel : 0x120000 - 0x520000
  113. Note that when we run 'spl export' it will prepare to boot the kernel.
  114. This includes relocation of the uImage from where we loaded it to the entry
  115. point defined in the header. As these locations overlap by default, it
  116. would leave us with an image that if written to MMC will not boot, so
  117. instead of using the loadaddr variable we use 0x81000000 in the following
  118. example. In this example we are loading from the network, for simplicity,
  119. and assume a valid partition table already exists and 'mmc dev' has already
  120. been run to select the correct device. Also note that if you previously
  121. had a FAT partition (such as on a Beaglebone Black) it is not enough to
  122. write garbage into the area, you must delete it from the partition table
  123. first.
  124. # Ensure we are able to talk with this mmc device
  125. U-Boot # mmc rescan
  126. U-Boot # tftp 81000000 am335x/MLO
  127. # Write to two of the backup locations ROM uses
  128. U-Boot # mmc write 81000000 100 100
  129. U-Boot # mmc write 81000000 200 100
  130. # Write U-Boot to the location set in the config
  131. U-Boot # tftp 81000000 am335x/u-boot.img
  132. U-Boot # mmc write 81000000 300 400
  133. # Load kernel and device tree into memory, perform export
  134. U-Boot # tftp 81000000 am335x/uImage
  135. U-Boot # run findfdt
  136. U-Boot # tftp ${fdtaddr} am335x/${fdtfile}
  137. U-Boot # run mmcargs
  138. U-Boot # spl export fdt 81000000 - ${fdtaddr}
  139. # Write the updated device tree to MMC
  140. U-Boot # mmc write ${fdtaddr} 80 80
  141. # Write the uImage to MMC
  142. U-Boot # mmc write 81000000 900 2000
  143. Falcon Mode: FAT SD cards
  144. =========================
  145. In this case the additional file is written to the filesystem. In this
  146. example we assume that the uImage and device tree to be used are already on
  147. the FAT filesystem (only the uImage MUST be for this to function
  148. afterwards) along with a Falcon Mode aware MLO and the FAT partition has
  149. already been created and marked bootable:
  150. U-Boot # mmc rescan
  151. # Load kernel and device tree into memory, perform export
  152. U-Boot # load mmc 0:1 ${loadaddr} uImage
  153. U-Boot # run findfdt
  154. U-Boot # load mmc 0:1 ${fdtaddr} ${fdtfile}
  155. U-Boot # run mmcargs
  156. U-Boot # spl export fdt ${loadaddr} - ${fdtaddr}
  157. This will print a number of lines and then end with something like:
  158. Using Device Tree in place at 80f80000, end 80f85928
  159. Using Device Tree in place at 80f80000, end 80f88928
  160. So then you:
  161. U-Boot # fatwrite mmc 0:1 0x80f80000 args 8928
  162. Falcon Mode: NAND
  163. =================
  164. In this case the additional data is written to another partition of the
  165. NAND. In this example we assume that the uImage and device tree to be are
  166. already located on the NAND somewhere (such as filesystem or mtd partition)
  167. along with a Falcon Mode aware MLO written to the correct locations for
  168. booting and mtdparts have been configured correctly for the board:
  169. U-Boot # nand read ${loadaddr} kernel
  170. U-Boot # load nand rootfs ${fdtaddr} /boot/am335x-evm.dtb
  171. U-Boot # run nandargs
  172. U-Boot # spl export fdt ${loadaddr} - ${fdtaddr}
  173. U-Boot # nand erase.part u-boot-spl-os
  174. U-Boot # nand write ${fdtaddr} u-boot-spl-os