| | 1 | {{{#!html |
| | 2 | <div class="wiki-toc"> |
| | 3 | <ol> |
| | 4 | <li> |
| | 5 | <a href="#Provisioningboards">Provisioning boards</a> |
| | 6 | <ol> |
| | 7 | <li> |
| | 8 | <a href="#AvilaCambriaLagunaVentanaNORSPIflashbasedboards">Avila / Cambria / Laguna / Ventana NOR / SPI flash based boards</a> |
| | 9 | </li> |
| | 10 | <li> |
| | 11 | <a href="#VentanaNANDflashbasedboards">Ventana NAND flash based boards</a> |
| | 12 | <ol> |
| | 13 | <li> |
| | 14 | <a href="#PullingSoftwareoffofanExistingBoard">Pulling Software off of an Existing Board</a> |
| | 15 | <ol> |
| | 16 | <li> |
| | 17 | <a href="#SPLandBootloader">SPL and Bootloader</a> |
| | 18 | </li> |
| | 19 | <li> |
| | 20 | <a href="#BootloaderEnvironment">Bootloader Environment</a> |
| | 21 | </li> |
| | 22 | <li> |
| | 23 | <a href="#RootFilesystem">Root Filesystem</a> |
| | 24 | </li> |
| | 25 | </ol> |
| | 26 | </li> |
| | 27 | <li> |
| | 28 | <a href="#FlashingBoardswithPulledSoftware">Flashing Boards with Pulled Software</a> |
| | 29 | </li> |
| | 30 | </ol> |
| | 31 | </li> |
| | 32 | <li> |
| | 33 | <a href="#micro-SDprovisioning">micro-SD provisioning</a> |
| | 34 | <ol> |
| | 35 | <li> |
| | 36 | <a href="#DirectlyCloningSDCards">Directly Cloning SD Cards</a> |
| | 37 | </li> |
| | 38 | <li> |
| | 39 | <a href="#U-BootMicroSDProvisioning">U-Boot MicroSD Provisioning</a> |
| | 40 | <ol> |
| | 41 | <li> |
| | 42 | <a href="#Otherkeywords">Other key words</a> |
| | 43 | </li> |
| | 44 | </ol> |
| | 45 | </li> |
| | 46 | </ol> |
| | 47 | </li> |
| | 48 | </ol> |
| | 49 | </li> |
| | 50 | </ol> |
| | 51 | </div><p> |
| | 52 | </p> |
| | 53 | <h1 id="Provisioningboards">Provisioning boards</h1> |
| | 54 | <p> |
| | 55 | We refer to the act of duplicating a firmware image across multiple boards as <strong>Provisioning</strong>. |
| | 56 | </p> |
| | 57 | <p> |
| | 58 | The easiest way to provision boards or removable storage devices is to build the particular BSP you are interested in, and use its tools to create a JTAG image suitable for programming with the Gateworks JTAG dongle (for NAND flash boards) or to create removable storage devices (for NAND-less boards). See <a class="wiki" href="/wiki/linux/ubi">linux/ubi</a> |
| | 59 | </p> |
| | 60 | <p> |
| | 61 | If however you wish to customize a board's configuration in some way that you have not configured into the build system you will want to boot a board, make your customizations, then pull those customizations off and use them to provision further boards. This is what is presented in detail on this page. |
| | 62 | </p> |
| | 63 | <h2 id="AvilaCambriaLagunaVentanaNORSPIflashbasedboards">Avila / Cambria / Laguna / Ventana NOR / SPI flash based boards</h2> |
| | 64 | <p> |
| | 65 | Products that use NOR and/or SPI flash have the ability to be uploaded to a host PC via the Gateworks GW16042 JTAG dongle and jtag_usb application. |
| | 66 | </p> |
| | 67 | <p> |
| | 68 | For these products simply configuring a board the way you want it at runtime then uploading the flash to a file provides you with a firmware image that can then be programmed onto other boards. |
| | 69 | </p> |
| | 70 | <p> |
| | 71 | Please read more about JTAG upload here: <a class="wiki" href="/wiki/jtag_instructions">JTAG Instructions</a> |
| | 72 | </p> |
| | 73 | <p> |
| | 74 | <span class="wikianchor" id="nandprovisioning"></span> |
| | 75 | </p> |
| | 76 | <h2 id="VentanaNANDflashbasedboards">Ventana NAND flash based boards</h2> |
| | 77 | <p> |
| | 78 | Products that use NAND flash present an issue in that they can contain bad blocks. As a result the raw flash devices can differ in size making it difficult to implement a JTAG flash upload/download scenario. |
| | 79 | </p> |
| | 80 | <p> |
| | 81 | There are several ways of provisioning NAND bootable boards: |
| | 82 | </p> |
| | 83 | <ul><li>using JTAG (this is what Gateworks uses on our production line) |
| | 84 | </li><li>using U-Boot (more complex, much faster than JTAG, but does not allow provisioning the SPL) |
| | 85 | </li><li>using Linux (even more complex, much faster than JTAG, but allows provisioning the SPL) |
| | 86 | </li><li>a combination of the above |
| | 87 | </li></ul><p> |
| | 88 | Regardless of the method used for provisioning there are several artifacts that you need in order to provision NAND: |
| | 89 | </p> |
| | 90 | <ul><li>SPL (secondary program loader) |
| | 91 | </li><li>u-boot.img (bootloader) |
| | 92 | </li><li>env (bootloader env) |
| | 93 | </li><li>ubi (unsorted block image containing ubifs filesystem) |
| | 94 | </li></ul><h3 id="PullingSoftwareoffofanExistingBoard">Pulling Software off of an Existing Board</h3> |
| | 95 | <h4 id="SPLandBootloader">SPL and Bootloader</h4> |
| | 96 | <p> |
| | 97 | The SPL and u-boot.img are built artifacts (which can be downloaded from <a class="ext-link" href="http://svn.gateworks.com/ventana/images"><span class="icon"></span>http://svn.gateworks.com/ventana/images</a>). |
| | 98 | </p> |
| | 99 | <h4 id="BootloaderEnvironment">Bootloader Environment</h4> |
| | 100 | <p> |
| | 101 | The env can be blank, which will use built-in defaults, or can be customized and extracted from the flash. |
| | 102 | </p> |
| | 103 | <p> |
| | 104 | To create and extract a bootloader env: |
| | 105 | </p> |
| | 106 | <ol><li>Create the env on a board: |
| | 107 | <pre class="wiki"># blank per-board vars (which are set from eeprom by default, yet overridable via env) |
| | 108 | setenv fdt_file |
| | 109 | setenv ethaddr |
| | 110 | setenv eth1addr |
| | 111 | # perform any other desired changes |
| | 112 | # save |
| | 113 | saveenv |
| | 114 | </pre></li><li>Extract the env from the board and save to removable storage: |
| | 115 | <ul><li>from Linux |
| | 116 | <pre class="wiki">dd if=/dev/mtd1 of=env bs=1M |
| | 117 | </pre></li><li>from U-Boot: |
| | 118 | <pre class="wiki"># read the env (environment) partition into temporary memory, note the size reported below as 0x100000 |
| | 119 | |
| | 120 | Ventana > nand read ${loadaddr} env |
| | 121 | |
| | 122 | NAND read: device 0 offset 0x1000000, size 0x100000 |
| | 123 | 1048576 bytes read: OK |
| | 124 | Ventana > |
| | 125 | |
| | 126 | # store it to file on micro-SD with an ext4 fs (size re-used from above) |
| | 127 | mmc dev 0 && ext4write mmc 0:1 ${loadaddr} /env 0x100000 |
| | 128 | |
| | 129 | # or store it to file on USB mass storage with an ext4 fs |
| | 130 | usb start && usb dev 0 && ext4write usb 0:1 ${loadaddr} /env 0x100000 |
| | 131 | |
| | 132 | </pre></li><li>Note that you may find it easier to build yourself a custom bootloader with defaults that match your needs rather than deal with extracting and imaging an env flash partition |
| | 133 | </li></ul></li></ol><h4 id="RootFilesystem">Root Filesystem</h4> |
| | 134 | <p> |
| | 135 | The ubi root filesystem is originally built by the the build system of the specific BSP your using, however if you end up imaging this onto a board, and customizing it, you may be able to pull it back off as long as your flash size is far less than your memory: |
| | 136 | </p> |
| | 137 | <ul><li>From Linux assuming /tmp is a tmpfs (ram based) and that you are booted into the filesystem you are copying and you have more ram available than the size of /dev/mtd2 (such as a 256MB flash on a 512MB system) |
| | 138 | <pre class="wiki">dd if=/dev/mtd2 of=/tmp/ubi bs=4M |
| | 139 | </pre></li><li>From U-Boot |
| | 140 | <pre class="wiki"># read the rootfs (filesystem) partition into temporary memory, note the size reported below as 0xef00000 |
| | 141 | |
| | 142 | Ventana > nand read ${loadaddr} rootfs |
| | 143 | |
| | 144 | NAND read: device 0 offset 0x1100000, size 0xef00000 |
| | 145 | 250609664 bytes read: OK |
| | 146 | |
| | 147 | |
| | 148 | # store it to file on micro-SD with an ext4 fs (size re-used from above) |
| | 149 | Ventana > mmc dev 0 && ext4write mmc 0:1 ${loadaddr} /rootfs 0xef00000 |
| | 150 | switch to partitions #0, OK |
| | 151 | mmc0 is current device |
| | 152 | File System is consistent |
| | 153 | update journal finished |
| | 154 | 250609664 bytes written in 57489 ms (4.2 MiB/s) |
| | 155 | Ventana > |
| | 156 | |
| | 157 | # or store it to file on USB mass storage with an ext4 fs |
| | 158 | usb start && usb dev 0 && ext4write usb 0:1 ${loadaddr} /rootfs 0xef00000 |
| | 159 | |
| | 160 | </pre></li></ul><h3 id="FlashingBoardswithPulledSoftware">Flashing Boards with Pulled Software</h3> |
| | 161 | <p> |
| | 162 | Once you have all the artifacts you can re-assemble them into a JTAG image suitable for the Gateworks JTAG adapter and software. The following usage of mkimage_jtag will create a jtagable image matching the partitioning described by 'mtdparts=nand:16m(uboot),1m(env),-(rootfs)' |
| | 163 | </p> |
| | 164 | <pre class="wiki">mkimage_jtag -e SPL@0 u-boot.img@14M env@16M ubi@17M > image.bin |
| | 165 | </pre><p> |
| | 166 | Or, for a faster two-step method of imaging using U-Boot with serial and ethernet (to a tftp server with the ubi): |
| | 167 | </p> |
| | 168 | <ol><li>create a JTAG image of the SPL + bootloader + env: |
| | 169 | <pre class="wiki">mkimage_jtag SPL u-boot.img env > image.bin |
| | 170 | </pre></li><li>once the above is flashed with the Gateworks JTAG adapter and software you can flash the ubi (much more quickly than via JTAG) within U-Boot |
| | 171 | </li><li>break out into the bootloader, transfer the ubi image from a tftp server into SDRAM, and flash it: |
| | 172 | <pre class="wiki">setenv ipaddr 192.168.1.1 # local ip |
| | 173 | setenv serverip 192.168.1.146 # server ip |
| | 174 | tftp ${loadaddr} image.ubi # tftp ubi image |
| | 175 | nand erase.part rootfs # erase the nand partition named rootfs from the mdtparts variable |
| | 176 | nand write ${loadaddr} rootfs ${filesize} # write the downloaded ubi to rootfs |
| | 177 | </pre></li></ol><p> |
| | 178 | Notes: |
| | 179 | </p> |
| | 180 | <ul><li>you can always elect to build your own bootloader with a custom config rather than pulling the env data off a board |
| | 181 | </li></ul><p> |
| | 182 | <span class="wikianchor" id="microsdprovisioning"></span> |
| | 183 | </p> |
| | 184 | <h2 id="micro-SDprovisioning">micro-SD provisioning</h2> |
| | 185 | <h3 id="DirectlyCloningSDCards">Directly Cloning SD Cards</h3> |
| | 186 | <p> |
| | 187 | <a class="wiki" href="/wiki/linux/blockdev#Creatingadiskimage">Read this wiki link</a> |
| | 188 | </p> |
| | 189 | <h3 id="U-BootMicroSDProvisioning">U-Boot MicroSD Provisioning</h3> |
| | 190 | <p> |
| | 191 | The main difference between provisioning removable storage devices such as micro-SD compared to non-removable storage devices (such as NAND flash) is that the removable devices can be potentially booted on a board with a different model, CPU, or memory configuration. This causes us to treat the U-Boot environment differently when we extract it from a configured board. |
| | 192 | </p> |
| | 193 | <p> |
| | 194 | If you do not want a blank env (which uses built-in defaults) you must provision one board, boot it to the bootloader, customize your env, then extract that env to use when provisioning additional boards. |
| | 195 | </p> |
| | 196 | <p> |
| | 197 | The Ventana bootloader stores its microSD env on raw block sectors from offset 709K and is 256K in size. |
| | 198 | </p> |
| | 199 | <p> |
| | 200 | The env can be blank, which will use built-in defaults, or can be customized and extracted. |
| | 201 | </p> |
| | 202 | <p> |
| | 203 | To create and extract a bootloader env: (only if this is being used, otherwise skip this step) |
| | 204 | </p> |
| | 205 | <ol><li>Create the env on a board: |
| | 206 | <pre class="wiki"># blank per-board vars (which are set from eeprom by default, yet overridable via env) |
| | 207 | setenv fdt_file |
| | 208 | setenv ethaddr |
| | 209 | setenv eth1addr |
| | 210 | # perform any other desired changes |
| | 211 | # save |
| | 212 | saveenv |
| | 213 | </pre></li><li>extract the env from a board that boots to micro-SD: |
| | 214 | <ul><li>from Linux: |
| | 215 | <pre class="wiki"># copy 256KB from offset 709KB to 'env' file |
| | 216 | dd if=/dev/sdc of=env bs=1K skip=709 count=256 oflag=sync |
| | 217 | </pre></li><li>from U-Boot: |
| | 218 | <pre class="wiki">mmc read ${loadaddr} 0x58a 0x200 # read 512x 512byte blocks (256K) from block 0x1418 |
| | 219 | # store it to file on micro-SD with an ext4 fs |
| | 220 | ext4write mmc 0:1 ${loadaddr} /mmc.env 0x40000 |
| | 221 | # store it to file on USB mass storage with an ext4 fs |
| | 222 | usb start && usb dev 0 && ext4write usb 0:1 ${loadaddr} /mmc.env 0x40000 |
| | 223 | </pre></li></ul></li></ol><p> |
| | 224 | To place an extracted env onto a micro-SD: |
| | 225 | </p> |
| | 226 | <ul><li>from Linux: |
| | 227 | <pre class="wiki"># copy 256KB from file env to offset 709KB: |
| | 228 | dd if=env of=/dev/sdc bs=1K seek=709 count=256 oflag=sync |
| | 229 | </pre></li></ul><h4 id="Otherkeywords">Other key words</h4> |
| | 230 | <p> |
| | 231 | procure, procurement , copy , jtag upload , production |
| | 232 | </p> |
| | 233 | }}} |