| 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 | }}} |