Changes between Version 1 and Version 2 of provisioning


Ignore:
Timestamp:
01/30/2018 11:09:26 PM (7 years ago)
Author:
Tim Harvey
Comment:

convert restored html to wiki markup

Legend:

Unmodified
Added
Removed
Modified

  • provisioning

    v1 v2  
    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>
     1[[PageOutline]]
     2
     3= Provisioning boards =
     4We refer to the act of duplicating a firmware image across multiple boards as **Provisioning**.
     5
     6The 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 [wiki:linux/ubi linux/ubi].
     7
    618If 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>
     9
     10
     11== Avila / Cambria / Laguna / Ventana NOR / SPI flash based boards ==
    6512Products 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>
     13
    6814For 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>
     15
     16Please read more about JTAG upload here: [wiki:jtag_instructions JTAG Instructions]
     17
     18
     19== Ventana NAND flash based boards ==
    7820Products 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>
     21
    8122There 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>
     23 * using JTAG (this is what Gateworks uses on our production line)
     24 * using U-Boot (more complex, much faster than JTAG, but does not allow provisioning the SPL)
     25 * using Linux (even more complex, much faster than JTAG, but allows provisioning the SPL)
     26 * a combination of the above
     27
    8828Regardless 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>
     29 * SPL (secondary program loader)
     30 * u-boot.img (bootloader)
     31 * env (bootloader env)
     32 * ubi (unsorted block image containing ubifs filesystem)
     33
     34
     35=== Pulling Software off of an Existing Board ===
     36
     37==== SPL and Bootloader ====
     38The SPL and u-boot.img are built artifacts (which can be downloaded from ​http://svn.gateworks.com/ventana/images).
     39
     40==== Bootloader Environment ====
    10141The env can be blank, which will use built-in defaults, or can be customized and extracted from the flash.
    102 </p>
    103 <p>
     42
    10443To 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)
     44 1. Create the env on a board:
     45{{{#!bash
     46# blank per-board vars (which are set from eeprom by default, yet overridable via env)
    10847setenv fdt_file
    10948setenv ethaddr
    … …  
    11251# save
    11352saveenv
    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
     53}}}
     54 2. Extract the env from the board and save to removable storage:
     55  - from Linux
     56{{{#!bash
     57dd if=/dev/mtd1 of=env bs=1M
     58}}}
     59  - from U-Boot:
     60{{{#!bash
     61# read the env (environment) partition into temporary memory, note the size reported below as 0x100000
    11962
    120 Ventana &gt; nand read ${loadaddr} env
     63Ventana > nand read ${loadaddr} env
    12164
    12265NAND read: device 0 offset 0x1000000, size 0x100000
    12366 1048576 bytes read: OK
    124 Ventana &gt;
     67Ventana >
    12568
    12669# store it to file on micro-SD with an ext4 fs (size re-used from above)
    127 mmc dev 0 &amp;&amp; ext4write mmc 0:1 ${loadaddr} /env 0x100000
     70mmc dev 0 && ext4write mmc 0:1 ${loadaddr} /env 0x100000
    12871
    12972# or store it to file on USB mass storage with an ext4 fs
    130 usb start &amp;&amp; usb dev 0 &amp;&amp; ext4write usb 0:1 ${loadaddr} /env 0x100000
     73usb start && usb dev 0 && ext4write usb 0:1 ${loadaddr} /env 0x100000
     74}}}
     75  - 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
    13176
    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>
     77
     78==== Root Filesystem ====
    13579The 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
     80 * 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)
     81{{{#!bash
     82dd if=/dev/mtd2 of=/tmp/ubi bs=4M
     83}}}
     84 * From U-Boot
     85{{{#!bash
     86# read the rootfs (filesystem) partition into temporary memory, note the size reported below as 0xef00000
    14187
    142 Ventana &gt; nand read ${loadaddr} rootfs
     88Ventana > nand read ${loadaddr} rootfs
    14389
    14490NAND read: device 0 offset 0x1100000, size 0xef00000
    … …  
    14793
    14894# store it to file on micro-SD with an ext4 fs (size re-used from above)
    149 Ventana &gt; mmc dev 0 &amp;&amp; ext4write mmc 0:1 ${loadaddr} /rootfs 0xef00000
     95Ventana > mmc dev 0 && ext4write mmc 0:1 ${loadaddr} /rootfs 0xef00000
    15096switch to partitions #0, OK
    15197mmc0 is current device
    … …  
    15399update journal finished
    154100250609664 bytes written in 57489 ms (4.2 MiB/s)
    155 Ventana &gt;
     101Ventana >
    156102
    157103# or store it to file on USB mass storage with an ext4 fs
    158 usb start &amp;&amp; usb dev 0 &amp;&amp; ext4write usb 0:1 ${loadaddr} /rootfs 0xef00000
     104usb start && usb dev 0 && ext4write usb 0:1 ${loadaddr} /rootfs 0xef00000
     105}}}
    159106
    160 </pre></li></ul><h3 id="FlashingBoardswithPulledSoftware">Flashing Boards with Pulled Software</h3>
    161 <p>
     107
     108=== Flashing Boards with Pulled Software ===
    162109Once 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 &gt; image.bin
    165 </pre><p>
     110{{{#!bash
     111mkimage_jtag -e SPL@0 u-boot.img@14M env@16M ubi@17M > image.bin
     112}}}
     113
    166114Or, 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 &gt; 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
     115 1. create a JTAG image of the SPL + bootloader + env:
     116{{{#!bash
     117mkimage_jtag SPL u-boot.img env > image.bin
     118}}}
     119 2. 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
     120 3. break out into the bootloader, transfer the ubi image from a tftp server into SDRAM, and flash it:
     121{{{#!bash
     122setenv ipaddr 192.168.1.1 # local ip
    173123setenv serverip 192.168.1.146 # server ip
    174124tftp ${loadaddr} image.ubi # tftp ubi image
    175125nand erase.part rootfs # erase the nand partition named rootfs from the mdtparts variable
    176126nand write ${loadaddr} rootfs ${filesize} # write the downloaded ubi to rootfs
    177 </pre></li></ol><p>
     127}}}
     128
    178129Notes:
    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>
     130 * you can always elect to build your own bootloader with a custom config rather than pulling the env data off a board
     131
     132
     133[=#microsd]
     134== micro-SD provisioning ==
     135
     136=== Directly Cloning SD Cards ===
     137See [wiki:linux/blockdev#Creatingadiskimage linux/blockdev]
     138
     139=== U-Boot MicroSD Provisioning ===
    191140The 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>
     141
    194142If 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>
     143
    197144The Ventana bootloader stores its microSD env on raw block sectors from offset 709K and is 256K in size.
    198 </p>
    199 <p>
     145
    200146The env can be blank, which will use built-in defaults, or can be customized and extracted.
    201 </p>
    202 <p>
     147
    203148To 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)
     149 1. Create the env on a board:
     150{{{#!bash
     151# blank per-board vars (which are set from eeprom by default, yet overridable via env)
    207152setenv fdt_file
    208153setenv ethaddr
    … …  
    211156# save
    212157saveenv
    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
     158}}}
     159 2. extract the env from a board that boots to micro-SD:
     160  * from Linux:
     161{{{#!bash
     162# copy 256KB from offset 709KB to 'env' file
    216163dd 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
     164}}}
     165  * from U-Boot:
     166{{{#!bash
     167mmc read ${loadaddr} 0x58a 0x200 # read 512x 512byte blocks (256K) from block 0x1418
    219168# store it to file on micro-SD with an ext4 fs
    220169ext4write mmc 0:1 ${loadaddr} /mmc.env 0x40000
    221170# store it to file on USB mass storage with an ext4 fs
    222 usb start &amp;&amp; usb dev 0 &amp;&amp; ext4write usb 0:1 ${loadaddr} /mmc.env 0x40000
    223 </pre></li></ul></li></ol><p>
     171usb start && usb dev 0 && ext4write usb 0:1 ${loadaddr} /mmc.env 0x40000
     172}}}
     173
    224174To 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:
     175 * from Linux:
     176{{{#!bash
     177# copy 256KB from file env to offset 709KB:
    228178dd 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>
    233179}}}
     180
     181Other key words
     182 * procure, procurement , copy , jtag upload , production