Tom Rini | 0b9b95a | 2021-09-11 08:57:31 -0400 | [diff] [blame] | 1 | .. SPDX-License-Identifier: GPL-2.0+ OR BSD-3-Clause |
| 2 | .. sectionauthor:: Tom Rini <trini@konsulko.com> |
| 3 | |
Bryan Brattlof | 10d3f17 | 2022-12-19 14:29:49 -0600 | [diff] [blame] | 4 | AM335x Generation |
| 5 | ================= |
| 6 | |
Tom Rini | 5d32dbd | 2013-07-08 12:15:18 -0400 | [diff] [blame] | 7 | Summary |
Bryan Brattlof | 10d3f17 | 2022-12-19 14:29:49 -0600 | [diff] [blame] | 8 | ------- |
Tom Rini | 5d32dbd | 2013-07-08 12:15:18 -0400 | [diff] [blame] | 9 | |
Tom Rini | 90b24ff | 2021-09-11 08:57:32 -0400 | [diff] [blame] | 10 | This document covers various features of the `am335x_evm` default |
| 11 | configuration, some of the related defconfigs, and how to enable hardware |
| 12 | features not present by default in the defconfigs. |
Tom Rini | 5d32dbd | 2013-07-08 12:15:18 -0400 | [diff] [blame] | 13 | |
| 14 | Hardware |
Tom Rini | 0b9b95a | 2021-09-11 08:57:31 -0400 | [diff] [blame] | 15 | -------- |
Tom Rini | 5d32dbd | 2013-07-08 12:15:18 -0400 | [diff] [blame] | 16 | |
| 17 | The binary produced by this board supports, based on parsing of the EEPROM |
| 18 | documented in TI's reference designs: |
Tom Rini | 0b9b95a | 2021-09-11 08:57:31 -0400 | [diff] [blame] | 19 | * AM335x GP EVM |
| 20 | * AM335x EVM SK |
Tom Rini | 90b24ff | 2021-09-11 08:57:32 -0400 | [diff] [blame] | 21 | * The Beaglebone family of designs |
Tom Rini | 50bbca7 | 2013-08-20 08:53:50 -0400 | [diff] [blame] | 22 | |
| 23 | Customization |
Tom Rini | 0b9b95a | 2021-09-11 08:57:31 -0400 | [diff] [blame] | 24 | ------------- |
Tom Rini | 50bbca7 | 2013-08-20 08:53:50 -0400 | [diff] [blame] | 25 | |
| 26 | Given that all of the above boards are reference platforms (and the |
| 27 | Beaglebone platforms are OSHA), it is likely that this platform code and |
| 28 | configuration will be used as the basis of a custom platform. It is |
| 29 | worth noting that aside from things such as NAND or MMC only being |
| 30 | required if a custom platform makes use of these blocks, the following |
| 31 | are required, depending on design: |
| 32 | |
Tom Rini | 0b9b95a | 2021-09-11 08:57:31 -0400 | [diff] [blame] | 33 | * GPIO is only required if DDR3 power is controlled in a way similar to EVM SK |
| 34 | * SPI is only required for SPI flash, or exposing the SPI bus. |
Tom Rini | 50bbca7 | 2013-08-20 08:53:50 -0400 | [diff] [blame] | 35 | |
| 36 | The following blocks are required: |
Tom Rini | 0b9b95a | 2021-09-11 08:57:31 -0400 | [diff] [blame] | 37 | |
| 38 | * I2C, to talk with the PMIC and ensure that we do not run afoul of |
Tom Rini | 50bbca7 | 2013-08-20 08:53:50 -0400 | [diff] [blame] | 39 | errata 1.0.24. |
| 40 | |
Tom Rini | 90b24ff | 2021-09-11 08:57:32 -0400 | [diff] [blame] | 41 | When removing options as part of customization, note that you will likely need |
| 42 | to look at both `include/configs/am335x_evm.h`, |
| 43 | `include/configs/ti_am335x_common.h` and `include/configs/am335x_evm.h` as the |
| 44 | migration to Kconfig is not yet complete. |
Tom Rini | 50bbca7 | 2013-08-20 08:53:50 -0400 | [diff] [blame] | 45 | |
Neha Malcom Francis | b61ad15 | 2023-09-08 15:06:16 +0530 | [diff] [blame] | 46 | Secure Boot |
| 47 | ----------- |
| 48 | |
| 49 | .. secure_boot_include_start_config_ti_secure_device |
| 50 | |
| 51 | Secure TI devices require a boot image that is authenticated by ROM |
| 52 | code to function. Without this, even JTAG remains locked and the |
| 53 | device is essentially useless. In order to create a valid boot image for |
| 54 | a secure device from TI, the initial public software image must be signed |
| 55 | and combined with various headers, certificates, and other binary images. |
| 56 | |
| 57 | Information on the details on the complete boot image format can be obtained |
| 58 | from Texas Instruments. The tools used to generate boot images for secure |
| 59 | devices are part of a secure development package (SECDEV) that can be |
| 60 | downloaded from: |
| 61 | |
| 62 | http://www.ti.com/mysecuresoftware (login required) |
| 63 | |
| 64 | The secure development package is access controlled due to NDA and export |
| 65 | control restrictions. Access must be requested and granted by TI before the |
| 66 | package is viewable and downloadable. Contact TI, either online or by way |
| 67 | of a local TI representative, to request access. |
| 68 | |
| 69 | .. secure_boot_include_end_config_ti_secure_device |
| 70 | |
| 71 | .. secure_boot_include_start_spl_boot |
| 72 | |
| 73 | 1. Booting of U-Boot SPL |
| 74 | ^^^^^^^^^^^^^^^^^^^^^^^^ |
| 75 | |
| 76 | When CONFIG_TI_SECURE_DEVICE is set, the U-Boot SPL build process |
| 77 | requires the presence and use of these tools in order to create a |
| 78 | viable boot image. The build process will look for the environment |
| 79 | variable TI_SECURE_DEV_PKG, which should be the path of the installed |
| 80 | SECDEV package. If the TI_SECURE_DEV_PKG variable is not defined or |
| 81 | if it is defined but doesn't point to a valid SECDEV package, a |
| 82 | warning is issued during the build to indicate that a final secure |
| 83 | bootable image was not created. |
| 84 | |
| 85 | Within the SECDEV package exists an image creation script: |
| 86 | |
| 87 | .. prompt:: bash |
| 88 | :prompts: $ |
| 89 | |
| 90 | ${TI_SECURE_DEV_PKG}/scripts/create-boot-image.sh |
| 91 | |
| 92 | This is called as part of the SPL/u-boot build process. As the secure |
| 93 | boot image formats and requirements differ between secure SOC from TI, |
| 94 | the purpose of this script is to abstract these details as much as |
| 95 | possible. |
| 96 | |
| 97 | The script is basically the only required interface to the TI SECDEV |
| 98 | package for creating a bootable SPL image for secure TI devices. |
| 99 | |
| 100 | .. prompt:: bash |
| 101 | :prompts: $ |
| 102 | |
| 103 | create-boot-image.sh \ |
| 104 | <IMAGE_FLAG> <INPUT_FILE> <OUTPUT_FILE> <SPL_LOAD_ADDR> |
| 105 | |
| 106 | .. secure_boot_include_end_spl_boot |
| 107 | |
| 108 | <IMAGE_FLAG> is a value that specifies the type of the image to |
| 109 | generate OR the action the image generation tool will take. Valid |
| 110 | values are: |
| 111 | |
| 112 | .. list-table:: |
| 113 | :widths: 25 25 |
| 114 | :header-rows: 0 |
| 115 | |
| 116 | * - PI_X-LOADER |
| 117 | - Generates an image for SPI flash (byte swapped) |
| 118 | * - X-LOADER |
| 119 | - Generates an image for non-XIP flash |
| 120 | * - MLO |
| 121 | - Generates an image for SD/MMC/eMMC media |
| 122 | * - 2ND |
| 123 | - Generates an image for USB, UART and Ethernet |
| 124 | * - XIP_X-LOADER |
| 125 | - Generates a single stage u-boot for NOR/QSPI XiP |
| 126 | |
| 127 | <INPUT_FILE> is the full path and filename of the public world boot |
| 128 | loaderbinary file (depending on the boot media, this is usually |
| 129 | either u-boot-spl.bin or u-boot.bin). |
| 130 | |
| 131 | <OUTPUT_FILE> is the full path and filename of the final secure |
| 132 | image. The output binary images should be used in place of the standard |
| 133 | non-secure binary images (see the platform-specific user's guides and |
| 134 | releases notes for how the non-secure images are typically used) |
| 135 | |
| 136 | .. list-table:: |
| 137 | :widths: 25 25 |
| 138 | :header-rows: 0 |
| 139 | |
| 140 | * - u-boot-spl_HS_SPI_X-LOADER |
| 141 | - byte swapped boot image for SPI flash |
| 142 | * - u-boot-spl_HS_X-LOADER |
| 143 | - boot image for NAND or SD/MMC/eMMC rawmode |
| 144 | * - u-boot-spl_HS_MLO |
| 145 | - boot image for SD/MMC/eMMC media |
| 146 | * - u-boot-spl_HS_2ND |
| 147 | - boot image for USB, UART and Ethernet |
| 148 | * - u-boot_HS_XIP_X-LOADER |
| 149 | - boot image for NOR or QSPI Xip flash |
| 150 | |
| 151 | <SPL_LOAD_ADDR> is the address at which SOC ROM should load the |
| 152 | <INPUT_FILE> |
| 153 | |
| 154 | .. secure_boot_include_start_primary_u_boot |
| 155 | |
| 156 | 2. Booting of Primary U-Boot (u-boot.img) |
| 157 | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ |
| 158 | |
| 159 | The SPL image is responsible for loading the next stage boot loader, |
| 160 | which is the main u-boot image. For secure TI devices, the SPL will |
| 161 | be authenticated, as described above, as part of the particular |
| 162 | device's ROM boot process. In order to continue the secure boot |
| 163 | process, the authenticated SPL must authenticate the main u-boot |
| 164 | image that it loads. |
| 165 | |
| 166 | The configurations for secure TI platforms are written to make the boot |
| 167 | process use the FIT image format for the u-boot.img (CONFIG_SPL_FRAMEWORK |
| 168 | and CONFIG_SPL_LOAD_FIT). With these configurations the binary |
| 169 | components that the SPL loads include a specific DTB image and u-boot |
| 170 | image. These DTB image may be one of many available to the boot |
| 171 | process. In order to secure these components so that they can be |
| 172 | authenticated by the SPL as they are loaded from the FIT image, the |
| 173 | build procedure for secure TI devices will secure these images before |
| 174 | they are integrated into the FIT image. When those images are extracted |
| 175 | from the FIT image at boot time, they are post-processed to verify that |
| 176 | they are still secure. The outlined security-related SPL post-processing |
| 177 | is enabled through the CONFIG_SPL_FIT_IMAGE_POST_PROCESS option which |
| 178 | must be enabled for the secure boot scheme to work. In order to allow |
| 179 | verifying proper operation of the secure boot chain in case of successful |
| 180 | authentication messages like "Authentication passed" are output by the |
| 181 | SPL to the console for each blob that got extracted from the FIT image. |
| 182 | |
| 183 | The exact details of the how the images are secured is handled by the |
| 184 | SECDEV package. Within the SECDEV package exists a script to process |
| 185 | an input binary image: |
| 186 | |
| 187 | .. prompt:: bash |
| 188 | :prompts: $ |
| 189 | |
| 190 | ${TI_SECURE_DEV_PKG}/scripts/secure-binary-image.sh |
| 191 | |
| 192 | This is called as part of the u-boot build process. As the secure |
| 193 | image formats and requirements can differ between the various secure |
| 194 | SOCs from TI, this script in the SECDEV package abstracts these |
| 195 | details. This script is essentially the only required interface to the |
| 196 | TI SECDEV package for creating a u-boot.img image for secure TI |
| 197 | devices. |
| 198 | |
| 199 | The SPL/u-boot code contains calls to dedicated secure ROM functions |
| 200 | to perform the validation on the secured images. The details of the |
| 201 | interface to those functions is shown in the code. The summary |
| 202 | is that they are accessed by invoking an ARM secure monitor call to |
| 203 | the device's secure ROM (fixed read-only-memory that is secure and |
| 204 | only accessible when the ARM core is operating in the secure mode). |
| 205 | |
| 206 | Invoking the secure-binary-image script for Secure Devices |
| 207 | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ |
| 208 | |
| 209 | .. prompt:: bash |
| 210 | :prompts: $ |
| 211 | |
| 212 | secure-binary-image.sh <INPUT_FILE> <OUTPUT_FILE> |
| 213 | |
| 214 | <INPUT_FILE> is the full path and filename of the input binary image |
| 215 | |
| 216 | <OUTPUT_FILE> is the full path and filename of the output secure image. |
| 217 | |
| 218 | .. secure_boot_include_end_primary_u_boot |
| 219 | |
Tom Rini | 9e6cff3 | 2013-07-17 12:24:30 -0400 | [diff] [blame] | 220 | NAND |
Tom Rini | 0b9b95a | 2021-09-11 08:57:31 -0400 | [diff] [blame] | 221 | ---- |
Tom Rini | 9e6cff3 | 2013-07-17 12:24:30 -0400 | [diff] [blame] | 222 | |
| 223 | The AM335x GP EVM ships with a 256MiB NAND available in most profiles. In |
| 224 | this example to program the NAND we assume that an SD card has been |
| 225 | inserted with the files to write in the first SD slot and that mtdparts |
pekon gupta | b770903 | 2013-11-19 11:02:18 +0530 | [diff] [blame] | 226 | have been configured correctly for the board. All images are first loaded |
| 227 | into memory, then written to NAND. |
| 228 | |
Neha Malcom Francis | b61ad15 | 2023-09-08 15:06:16 +0530 | [diff] [blame] | 229 | 1. Building u-boot for NAND boot |
pekon gupta | b770903 | 2013-11-19 11:02:18 +0530 | [diff] [blame] | 230 | |
Neha Malcom Francis | b61ad15 | 2023-09-08 15:06:16 +0530 | [diff] [blame] | 231 | .. list-table:: CONFIGxx options for NAND device |
| 232 | :widths: 25 25 |
| 233 | :header-rows: 1 |
Tom Rini | 0b9b95a | 2021-09-11 08:57:31 -0400 | [diff] [blame] | 234 | |
Neha Malcom Francis | b61ad15 | 2023-09-08 15:06:16 +0530 | [diff] [blame] | 235 | * - Config |
| 236 | - Description |
| 237 | * - CONFIG_SYS_NAND_PAGE_SIZE |
| 238 | - number of main bytes in NAND page |
| 239 | * - CONFIG_SYS_NAND_OOBSIZE |
| 240 | - number of OOB bytes in NAND page |
| 241 | * - CONFIG_SYS_NAND_BLOCK_SIZE |
| 242 | - number of bytes in NAND erase-block |
| 243 | * - CFG_SYS_NAND_ECCPOS |
| 244 | - ECC map for NAND page |
| 245 | * - CONFIG_NAND_OMAP_ECCSCHEME |
| 246 | - (refer doc/README.nand) |
Tom Rini | 0b9b95a | 2021-09-11 08:57:31 -0400 | [diff] [blame] | 247 | |
Neha Malcom Francis | b61ad15 | 2023-09-08 15:06:16 +0530 | [diff] [blame] | 248 | 2. Flashing NAND via MMC/SD |
Tom Rini | 9e6cff3 | 2013-07-17 12:24:30 -0400 | [diff] [blame] | 249 | |
Neha Malcom Francis | b61ad15 | 2023-09-08 15:06:16 +0530 | [diff] [blame] | 250 | .. prompt:: bash |
| 251 | :prompts: => |
| 252 | |
| 253 | # select BOOTSEL to MMC/SD boot and boot from MMC/SD card |
| 254 | mmc rescan |
| 255 | # erase flash |
| 256 | nand erase.chip |
| 257 | env default -f -a |
| 258 | saveenv |
| 259 | # flash MLO. Redundant copies of MLO are kept for failsafe |
| 260 | load mmc 0 0x82000000 MLO |
| 261 | nand write 0x82000000 0x00000 0x20000 |
| 262 | nand write 0x82000000 0x20000 0x20000 |
| 263 | nand write 0x82000000 0x40000 0x20000 |
| 264 | nand write 0x82000000 0x60000 0x20000 |
| 265 | # flash u-boot.img |
| 266 | load mmc 0 0x82000000 u-boot.img |
| 267 | nand write 0x82000000 0x80000 0x60000 |
| 268 | # flash kernel image |
| 269 | load mmc 0 0x82000000 uImage |
| 270 | nand write 0x82000000 ${nandsrcaddr} ${nandimgsize} |
| 271 | # flash filesystem image |
| 272 | load mmc 0 0x82000000 filesystem.img |
| 273 | nand write 0x82000000 ${loadaddress} 0x300000 |
| 274 | |
| 275 | 3. Set BOOTSEL pin to select NAND boot, and POR the device. |
pekon gupta | b770903 | 2013-11-19 11:02:18 +0530 | [diff] [blame] | 276 | The device should boot from images flashed on NAND device. |
Tom Rini | 5d32dbd | 2013-07-08 12:15:18 -0400 | [diff] [blame] | 277 | |
Tom Rini | 9fe5cea | 2013-07-18 15:13:05 -0400 | [diff] [blame] | 278 | |
Tom Rini | 5d32dbd | 2013-07-08 12:15:18 -0400 | [diff] [blame] | 279 | Falcon Mode |
Tom Rini | 0b9b95a | 2021-09-11 08:57:31 -0400 | [diff] [blame] | 280 | ----------- |
Tom Rini | 5d32dbd | 2013-07-08 12:15:18 -0400 | [diff] [blame] | 281 | |
| 282 | The default build includes "Falcon Mode" (see doc/README.falcon) via NAND, |
| 283 | eMMC (or raw SD cards) and FAT SD cards. Our default behavior currently is |
| 284 | to read a 'c' on the console while in SPL at any point prior to loading the |
| 285 | OS payload (so as soon as possible) to opt to booting full U-Boot. Also |
| 286 | note that while one can program Falcon Mode "in place" great care needs to |
| 287 | be taken by the user to not 'brick' their setup. As these are all eval |
| 288 | boards with multiple boot methods, recovery should not be an issue in this |
| 289 | worst-case however. |
| 290 | |
| 291 | Falcon Mode: eMMC |
Tom Rini | 0b9b95a | 2021-09-11 08:57:31 -0400 | [diff] [blame] | 292 | ----------------- |
Tom Rini | 5d32dbd | 2013-07-08 12:15:18 -0400 | [diff] [blame] | 293 | |
| 294 | The recommended layout in this case is: |
| 295 | |
Neha Malcom Francis | b61ad15 | 2023-09-08 15:06:16 +0530 | [diff] [blame] | 296 | .. list-table:: eMMC Recommended Layout |
| 297 | :widths: 25 25 50 |
| 298 | :header-rows: 1 |
Tom Rini | 0b9b95a | 2021-09-11 08:57:31 -0400 | [diff] [blame] | 299 | |
Neha Malcom Francis | b61ad15 | 2023-09-08 15:06:16 +0530 | [diff] [blame] | 300 | * - MMC Blocks |
| 301 | - Description |
| 302 | - Location in bytes |
| 303 | * - 0x0000 - 0x007F |
| 304 | - MBR or GPT table |
| 305 | - 0x000000 - 0x020000 |
| 306 | * - 0x0080 - 0x00FF |
| 307 | - ARGS or FDT file |
| 308 | - 0x010000 - 0x020000 |
| 309 | * - 0x0100 - 0x01FF |
| 310 | - SPL.backup1 (first copy used) |
| 311 | - 0x020000 - 0x040000 |
| 312 | * - 0x0200 - 0x02FF |
| 313 | - SPL.backup2 (second copy used) |
| 314 | - 0x040000 - 0x060000 |
| 315 | * - 0x0300 - 0x06FF |
| 316 | - U-Boot |
| 317 | - 0x060000 - 0x0e0000 |
| 318 | * - 0x0700 - 0x08FF |
| 319 | - U-Boot Env + Redundant |
| 320 | - 0x0e0000 - 0x120000 |
| 321 | * - 0x0900 - 0x28FF |
| 322 | - Kernel |
| 323 | - 0x120000 - 0x520000 |
Tom Rini | 5d32dbd | 2013-07-08 12:15:18 -0400 | [diff] [blame] | 324 | |
| 325 | Note that when we run 'spl export' it will prepare to boot the kernel. |
| 326 | This includes relocation of the uImage from where we loaded it to the entry |
| 327 | point defined in the header. As these locations overlap by default, it |
| 328 | would leave us with an image that if written to MMC will not boot, so |
| 329 | instead of using the loadaddr variable we use 0x81000000 in the following |
| 330 | example. In this example we are loading from the network, for simplicity, |
| 331 | and assume a valid partition table already exists and 'mmc dev' has already |
| 332 | been run to select the correct device. Also note that if you previously |
| 333 | had a FAT partition (such as on a Beaglebone Black) it is not enough to |
| 334 | write garbage into the area, you must delete it from the partition table |
| 335 | first. |
| 336 | |
Neha Malcom Francis | b61ad15 | 2023-09-08 15:06:16 +0530 | [diff] [blame] | 337 | .. prompt:: bash |
| 338 | :prompts: => |
Tom Rini | 0b9b95a | 2021-09-11 08:57:31 -0400 | [diff] [blame] | 339 | |
Neha Malcom Francis | b61ad15 | 2023-09-08 15:06:16 +0530 | [diff] [blame] | 340 | # Ensure we are able to talk with this mmc device |
| 341 | mmc rescan |
| 342 | tftp 81000000 am335x/MLO |
| 343 | # Write to two of the backup locations ROM uses |
| 344 | mmc write 81000000 100 100 |
| 345 | mmc write 81000000 200 100 |
| 346 | # Write U-Boot to the location set in the config |
| 347 | tftp 81000000 am335x/u-boot.img |
| 348 | mmc write 81000000 300 400 |
| 349 | # Load kernel and device tree into memory, perform export |
| 350 | tftp 81000000 am335x/uImage |
| 351 | run findfdt |
| 352 | tftp ${fdtaddr} am335x/${fdtfile} |
| 353 | run mmcargs |
| 354 | spl export fdt 81000000 - ${fdtaddr} |
| 355 | # Write the updated device tree to MMC |
| 356 | mmc write ${fdtaddr} 80 80 |
| 357 | # Write the uImage to MMC |
| 358 | mmc write 81000000 900 2000 |
Tom Rini | 5d32dbd | 2013-07-08 12:15:18 -0400 | [diff] [blame] | 359 | |
| 360 | Falcon Mode: FAT SD cards |
Tom Rini | 0b9b95a | 2021-09-11 08:57:31 -0400 | [diff] [blame] | 361 | ------------------------- |
Tom Rini | 5d32dbd | 2013-07-08 12:15:18 -0400 | [diff] [blame] | 362 | |
| 363 | In this case the additional file is written to the filesystem. In this |
| 364 | example we assume that the uImage and device tree to be used are already on |
| 365 | the FAT filesystem (only the uImage MUST be for this to function |
| 366 | afterwards) along with a Falcon Mode aware MLO and the FAT partition has |
| 367 | already been created and marked bootable: |
| 368 | |
Neha Malcom Francis | b61ad15 | 2023-09-08 15:06:16 +0530 | [diff] [blame] | 369 | .. prompt:: bash |
| 370 | :prompts: => |
Tom Rini | 0b9b95a | 2021-09-11 08:57:31 -0400 | [diff] [blame] | 371 | |
Neha Malcom Francis | b61ad15 | 2023-09-08 15:06:16 +0530 | [diff] [blame] | 372 | mmc rescan |
| 373 | # Load kernel and device tree into memory, perform export |
| 374 | load mmc 0:1 ${loadaddr} uImage |
| 375 | run findfdt |
| 376 | load mmc 0:1 ${fdtaddr} ${fdtfile} |
| 377 | run mmcargs |
| 378 | spl export fdt ${loadaddr} - ${fdtaddr} |
Tom Rini | 5d32dbd | 2013-07-08 12:15:18 -0400 | [diff] [blame] | 379 | |
| 380 | This will print a number of lines and then end with something like: |
Tom Rini | 0b9b95a | 2021-09-11 08:57:31 -0400 | [diff] [blame] | 381 | |
Neha Malcom Francis | b61ad15 | 2023-09-08 15:06:16 +0530 | [diff] [blame] | 382 | .. code-block:: bash |
Tom Rini | 0b9b95a | 2021-09-11 08:57:31 -0400 | [diff] [blame] | 383 | |
Neha Malcom Francis | b61ad15 | 2023-09-08 15:06:16 +0530 | [diff] [blame] | 384 | Using Device Tree in place at 80f80000, end 80f85928 |
| 385 | Using Device Tree in place at 80f80000, end 80f88928 |
Tom Rini | 0b9b95a | 2021-09-11 08:57:31 -0400 | [diff] [blame] | 386 | |
Tom Rini | 5d32dbd | 2013-07-08 12:15:18 -0400 | [diff] [blame] | 387 | So then you: |
| 388 | |
Neha Malcom Francis | b61ad15 | 2023-09-08 15:06:16 +0530 | [diff] [blame] | 389 | .. prompt:: bash |
| 390 | :prompts: => |
Tom Rini | 0b9b95a | 2021-09-11 08:57:31 -0400 | [diff] [blame] | 391 | |
Neha Malcom Francis | b61ad15 | 2023-09-08 15:06:16 +0530 | [diff] [blame] | 392 | fatwrite mmc 0:1 0x80f80000 args 8928 |
Tom Rini | 5d32dbd | 2013-07-08 12:15:18 -0400 | [diff] [blame] | 393 | |
| 394 | Falcon Mode: NAND |
Tom Rini | 0b9b95a | 2021-09-11 08:57:31 -0400 | [diff] [blame] | 395 | ----------------- |
Tom Rini | 5d32dbd | 2013-07-08 12:15:18 -0400 | [diff] [blame] | 396 | |
| 397 | In this case the additional data is written to another partition of the |
| 398 | NAND. In this example we assume that the uImage and device tree to be are |
Jeremiah Mahler | bec3d9d | 2015-01-06 16:40:28 -0800 | [diff] [blame] | 399 | already located on the NAND somewhere (such as filesystem or mtd partition) |
Tom Rini | 5d32dbd | 2013-07-08 12:15:18 -0400 | [diff] [blame] | 400 | along with a Falcon Mode aware MLO written to the correct locations for |
| 401 | booting and mtdparts have been configured correctly for the board: |
| 402 | |
Neha Malcom Francis | b61ad15 | 2023-09-08 15:06:16 +0530 | [diff] [blame] | 403 | .. prompt:: bash |
| 404 | :prompts: => |
Tom Rini | 0b9b95a | 2021-09-11 08:57:31 -0400 | [diff] [blame] | 405 | |
Neha Malcom Francis | b61ad15 | 2023-09-08 15:06:16 +0530 | [diff] [blame] | 406 | nand read ${loadaddr} kernel |
| 407 | load nand rootfs ${fdtaddr} /boot/am335x-evm.dtb |
| 408 | run nandargs |
| 409 | spl export fdt ${loadaddr} - ${fdtaddr} |
| 410 | nand erase.part u-boot-spl-os |
| 411 | nand write ${fdtaddr} u-boot-spl-os |
Miquel Raynal | 1b9d2a0 | 2023-08-07 08:42:41 +0200 | [diff] [blame] | 412 | |
| 413 | USB device |
| 414 | ---------- |
| 415 | |
| 416 | The platform code for am33xx based designs is legacy in the sense that |
| 417 | it is not fully compliant with the driver model in its management of the |
| 418 | various resources. This is particularly true for the USB Ethernet gadget |
| 419 | which will automatically be bound to the first USB Device Controller |
| 420 | (UDC). This make the USB Ethernet gadget work out of the box on common |
| 421 | boards like the Beagle Bone Blacks and by default will prevents other |
| 422 | gadgets to be used. |
| 423 | |
| 424 | The output of the 'dm tree' command shows which driver is bound to which |
| 425 | device, so the user can easily configure their platform differently from |
| 426 | the command line: |
| 427 | |
Neha Malcom Francis | b61ad15 | 2023-09-08 15:06:16 +0530 | [diff] [blame] | 428 | .. prompt:: bash |
| 429 | :prompts: => |
| 430 | |
| 431 | dm tree |
| 432 | |
Miquel Raynal | 1b9d2a0 | 2023-08-07 08:42:41 +0200 | [diff] [blame] | 433 | .. code-block:: text |
| 434 | |
Neha Malcom Francis | b61ad15 | 2023-09-08 15:06:16 +0530 | [diff] [blame] | 435 | Class Index Probed Driver Name |
| 436 | ----------------------------------------------------------- |
| 437 | [...] |
| 438 | misc 0 [ + ] ti-musb-wrapper | |-- usb@47400000 |
| 439 | usb 0 [ + ] ti-musb-peripheral | | |-- usb@47401000 |
| 440 | ethernet 1 [ + ] usb_ether | | | `-- usb_ether |
| 441 | bootdev 3 [ ] eth_bootdev | | | `-- usb_ether.bootdev |
| 442 | usb 0 [ ] ti-musb-host | | `-- usb@47401800 |
Miquel Raynal | 1b9d2a0 | 2023-08-07 08:42:41 +0200 | [diff] [blame] | 443 | |
| 444 | Typically here any network command performed using the usb_ether |
| 445 | interface would work, while using other gadgets would fail: |
| 446 | |
Neha Malcom Francis | b61ad15 | 2023-09-08 15:06:16 +0530 | [diff] [blame] | 447 | .. prompt:: bash |
| 448 | :prompts: => |
| 449 | |
| 450 | fastboot usb 0 |
| 451 | |
Miquel Raynal | 1b9d2a0 | 2023-08-07 08:42:41 +0200 | [diff] [blame] | 452 | .. code-block:: text |
| 453 | |
Neha Malcom Francis | b61ad15 | 2023-09-08 15:06:16 +0530 | [diff] [blame] | 454 | All UDC in use (1 available), use the unbind command |
| 455 | g_dnl_register: failed!, error: -19 |
| 456 | exit not allowed from main input shell. |
Miquel Raynal | 1b9d2a0 | 2023-08-07 08:42:41 +0200 | [diff] [blame] | 457 | |
| 458 | As hinted by the primary error message, the only controller available |
| 459 | (usb@47401000) is currently bound to the usb_ether driver, which makes |
| 460 | it impossible for the fastboot command to bind with this device (at |
| 461 | least from a bootloader point of view). The solution here would be to |
| 462 | use the unbind command specifying the class and index parameters (as |
| 463 | shown above in the 'dm tree' output) to target the driver to unbind: |
| 464 | |
Neha Malcom Francis | b61ad15 | 2023-09-08 15:06:16 +0530 | [diff] [blame] | 465 | .. prompt:: bash |
| 466 | :prompts: => |
Miquel Raynal | 1b9d2a0 | 2023-08-07 08:42:41 +0200 | [diff] [blame] | 467 | |
Neha Malcom Francis | b61ad15 | 2023-09-08 15:06:16 +0530 | [diff] [blame] | 468 | unbind ethernet 1 |
Miquel Raynal | 1b9d2a0 | 2023-08-07 08:42:41 +0200 | [diff] [blame] | 469 | |
| 470 | The output of the 'dm tree' command now shows the availability of the |
| 471 | first USB device controller, the fastboot gadget will now be able to |
| 472 | bind with it: |
| 473 | |
Neha Malcom Francis | b61ad15 | 2023-09-08 15:06:16 +0530 | [diff] [blame] | 474 | .. prompt:: bash |
| 475 | :prompts: => |
| 476 | |
| 477 | dm tree |
| 478 | |
Miquel Raynal | 1b9d2a0 | 2023-08-07 08:42:41 +0200 | [diff] [blame] | 479 | .. code-block:: text |
| 480 | |
Neha Malcom Francis | b61ad15 | 2023-09-08 15:06:16 +0530 | [diff] [blame] | 481 | Class Index Probed Driver Name |
| 482 | ----------------------------------------------------------- |
| 483 | [...] |
| 484 | misc 0 [ + ] ti-musb-wrapper | |-- usb@47400000 |
| 485 | usb 0 [ ] ti-musb-peripheral | | |-- usb@47401000 |
| 486 | usb 0 [ ] ti-musb-host | | `-- usb@47401800 |