Changes between Version 4 and Version 5 of Yocto/Building
- Timestamp:
- 01/15/2018 07:15:10 PM (7 years ago)
Legend:
- Unmodified
- Added
- Removed
- Modified
-
Yocto/Building
v4 v5 1 {{{#!html 2 <div id="wikipage" class="trac-content"><p> 3 </p><div class="wiki-toc"> 4 <ol> 5 <li> 6 <a href="#BuildingYoctoInstallingfortheGateworksVentanaFamily">Building Yocto & Installing for the Gateworks Ventana Family</a> 7 </li> 8 <li> 9 <a href="#Pre-CompiledYoctoBinaries">Pre-Compiled Yocto Binaries</a> 10 </li> 11 <li> 12 <a href="#ObtainingandCompilingtheSourceCode">Obtaining and Compiling the Source Code</a> 13 <ol> 14 <li> 15 <a href="#Troubleshootingbuildfailures">Troubleshooting build failures</a> 16 <ol> 17 <li> 18 <a href="#Fetchfailure">Fetch failure</a> 19 </li> 20 <li> 21 <a href="#UpstreamBreakage">Upstream Breakage</a> 22 </li> 23 </ol> 24 </li> 25 <li> 26 <a href="#Keepinguptodateandorpinningsourcewithrepo">Keeping up to date and/or pinning source with repo</a> 27 </li> 28 <li> 29 <a href="#Updatingandrebuilding">Updating and rebuilding</a> 30 </li> 31 <li> 32 <a href="#Diskusageandkeepingthingsclean">Disk usage and keeping things clean</a> 33 </li> 34 <li> 35 <a href="#BuildingUpdatingAddingPackages">Building / Updating / Adding Packages</a> 36 </li> 37 <li> 38 <a href="#BuildingatoolchainandorSDK">Building a toolchain and/or SDK</a> 39 </li> 40 <li> 41 <a href="#Otherusefullinks">Other useful links</a> 42 </li> 43 </ol> 44 </li> 45 <li> 46 <a href="#InstallingFirmware">Installing Firmware</a> 47 <ol> 48 <li> 49 <a href="#NANDFLASH">NAND FLASH</a> 50 </li> 51 <li> 52 <a href="#InstallingonRemovablestorage:mSATAUSBuSD">Installing on Removable storage: mSATA/USB/uSD</a> 53 </li> 54 </ol> 55 </li> 56 </ol> 57 </div><p> 58 </p> 59 <p> 60 <strong>NOTE</strong> In conjunction with the Yocto BSP, please be sure to use the latest bootloader for proper operation. <a class="wiki" href="/wiki/ventana/bootloader#PreBuiltBootloader">Bootloader Instructions Here</a> 61 </p> 62 <h1 id="BuildingYoctoInstallingfortheGateworksVentanaFamily">Building Yocto & Installing for the Gateworks Ventana Family</h1> 63 <p> 1 [[PageOutline]] 2 3 **NOTE** In conjunction with the Yocto BSP, please be sure to use the latest bootloader for proper operation. You can find Bootloader Instructions [wiki:ventana/bootloader#PreBuiltBootloader here]. 4 5 = Building Yocto & Installing for the Gateworks Ventana Family = 64 6 The following versions of Yocto are supported: 65 </p> 66 <ul><li>Yocto v2.3 (Pyro) Poky 17.0 released on 05/24/2017 (<strong>Recommended</strong>) 67 <ul><li>using the gateworks_fslc_3.14_1.0.x_ga kernel 68 </li><li><strong>Considered stable</strong> 69 </li></ul></li></ul><p> 70 </p><div> <h3 class="foldable">Old Releases</h3><div><p> 71 </p> 72 <ul><li>Yocto v1.8 (Fido) Poky 13.0 released on 02/23/2016 73 <ul><li>using the gateworks_fslc_3.14_1.0.x_ga kernel 74 </li></ul></li><li>Yocto v1.7 (Dizzy) Poky 12.0 released on 02/25/2015 75 <ul><li>using the gateworks_3.10.17_1.0.0_ga kernel 76 </li></ul></li><li>Yocto v1.6 (Daisy) Poky 11.0 released on 4/25/2014 77 <ul><li>using the gateworks_3.10.17_1.0.0_ga kernel 78 </li></ul></li></ul><p> 79 </div></div> 80 </p> 81 <p> 7 * Yocto v2.3 (Pyro) Poky 17.0 released on 05/24/2017 (Recommended) 8 - using the gateworks_fslc_3.14_1.0.x_ga kernel 9 - **Considered stable** 10 11 [[CollapsibleStart(Old Releases)]] 12 * Yocto v1.8 (Fido) Poky 13.0 released on 02/23/2016 13 - using the gateworks_fslc_3.14_1.0.x_ga kernel 14 * Yocto v1.7 (Dizzy) Poky 12.0 released on 02/25/2015 15 - using the gateworks_3.10.17_1.0.0_ga kernel 16 * Yocto v1.6 (Daisy) Poky 11.0 released on 4/25/2014 17 - using the gateworks_3.10.17_1.0.0_ga kernel 18 [[CollapsibleEnd]] 19 82 20 The Gateworks Ventana Yocto BSP provides a layer of package recipes that replace or override recipes in the upstream Yocto project such as: 83 </p> 84 <ul><li>kernel 85 </li><li>bootloader 86 </li><li>filesystem images 87 </li><li>support utilities 88 </li></ul><p> 21 * kernel 22 * bootloader 23 * filesystem images 24 * support utilities 25 89 26 For details on Yocto releases please see: 90 </p> 91 <ul><li><a class="ext-link" href="https://wiki.yoctoproject.org/wiki/Releases"><span class="icon"></span>https://wiki.yoctoproject.org/wiki/Releases</a> 92 </li></ul><p> 93 <span class="wikianchor" id="prebuilt"></span> 94 </p> 95 <h1 id="Pre-CompiledYoctoBinaries">Pre-Compiled Yocto Binaries</h1> 96 <p> 27 * https://wiki.yoctoproject.org/wiki/Releases 28 29 30 = Pre-Compiled Yocto Binaries = 97 31 For convenience Gateworks has some pre-built ubi files available. Note that you need to download a UBI image appropriate for the FLASH size on your board. Gateworks Ventana boards come with either 256MB NAND Flash or 1GB/2GB NAND Flash. You can see the size output from the bootloader over the serial console. 98 </p> 99 <p> 100 <strong> <a class="wiki" href="/wiki/Yocto/Building#InstallingFirmware">Installation instructions here</a> </strong> 101 </p> 102 <p> 32 33 Installation instructions here 34 103 35 Most recent releases: 104 </p> 105 <ul><li>Yocto 2.3 (Pyro) 20170524: 106 <ul><li>Multimedia: (supports gstreamer video in/out encode/decode, but no GUI desktop) 107 <ul> 108 <li><a class="ext-link" href="http://blog.gateworks.com/?wpdmpro=gateworks-image-multimedia-ventana-2.3_20170524183825_normal.rootfs.ubi"><span class="icon"></span>ubi 256MB FLASH</a> (sha256sum:e2b41e2ab9d0c7829996249b1bf04cb902cbdc1d300a1d4411d9f96540a2f91a) 109 </li> 110 <li><a class="ext-link" href="http://blog.gateworks.com/?wpdmpro=gateworks-image-multimedia-ventana-2.3_20170524183825_large.rootfs.ubi"><span class="icon"></span>ubi 1GB/2GB FLASH</a> (sha256sum:055b7644b1db05b96e33f948e1f314d39e7745fb1fd08dab248fe39f975c6eb2) 111 </li><li><a class="ext-link" href="http://blog.gateworks.com/?wpdmpro=gateworks-image-multimedia-ventana-2.3_20170524183825.rootfs.tar.bz2"><span class="icon"></span>rootfs tarball</a> (sha256sum:aa8db12b24a091db994d5cba1357e608b03be71c947a040954d70bd0ce7636d4) 112 </li></ul></li> 113 114 </p><div> <h3 class="foldable">Old Releases</h3><div><p> 115 </p> 116 <ul> 117 118 <li>Yocto 1.8.2 (Fido) 20160328-1730: 119 <ul><li>Multimedia: (supports gstreamer video in/out encode/decode, but no GUI desktop) 120 <ul><li><a class="ext-link" href="http://blog.gateworks.com/?wpdmpro=gateworks-image-multimedia-ventana-20160328-1730_normal-ubi"><span class="icon"></span>ubi 256MB FLASH</a> (sha256sum:a012d6ffb287221e686de973870e4232fe54f08d208f9ce5a436933ecff02606) 121 </li><li><a class="ext-link" href="http://blog.gateworks.com/?wpdmpro=gateworks-image-multimedia-ventana_large-ubi"><span class="icon"></span>ubi 1GB/2GB FLASH</a> (sha256sum:be735f02f0a68b9cca797cd62e71b9de2ecea3ab6e64c23e3406b175c160f25a) 122 </li><li><a class="ext-link" href="http://blog.gateworks.com/?wpdmpro=gateworks-image-multimedia-ventana-tar-bz2"><span class="icon"></span>rootfs tarball</a> (sha256sum:94734c2c442427deb1df537d1da9abebb9b6e5dab2891c3a35e8ac200540dd07) 123 </li></ul></li><li>GUI: (supports gstreamer video in/out encode/decode and SATO X11 desktop with Matchbox window manager and Midori web browser) 124 <ul><li><a class="ext-link" href="http://blog.gateworks.com/?wpdmpro=gateworks-image-gui-ventana_large-ubi"><span class="icon"></span>ubi 1GB/2GB FLASH</a> (sha256sum:96d229507a82022a9da7e91998b55dea706619c09548821d69712b97dc76919a) 125 </li><li><a class="ext-link" href="http://blog.gateworks.com/?wpdmpro=gateworks-image-gui-ventana-tar-bz2"><span class="icon"></span>rootfs tarball</a> (sha256sum:12aecb6b2e38ba9f55c1986e8bb27c057521f96be1cb63227748db4cf3e8e7a3) 126 </li></ul></li></ul></li> 127 128 <li>Yocto 1.8.1 (Fido) 20160223-1730: 129 <ul><li>Multimedia: 130 <ul><li><a class="ext-link" href="http://blog.gateworks.com/?wpdmpro=gateworks-image-multimedia-ventana-1.8.1_20160224031410_normal.rootfs.ubi"><span class="icon"></span>ubi 256MB FLASH</a> (sha256sum:c1ecd3a4b9406d9274e89de94a2c76486d2440fefc0588feb495c0d021944697) 131 </li><li><a class="ext-link" href="http://blog.gateworks.com/?wpdmpro=gateworks-image-multimedia-ventana-1.8.1_20160224031410_large.rootfs.ubi"><span class="icon"></span>ubi 1GB/2GB FLASH</a> (sha256sum:d156c12c8973f21400ed8a9f374a8727284c776abba34c5b4cebfbce46997141) 132 </li><li><a class="ext-link" href="http://blog.gateworks.com/?wpdmpro=gateworks-image-multimedia-ventana-1.8.1_20160224031410.rootfs.tar.bz2"><span class="icon"></span>rootfs tarball</a> (sha256sum:d17b603d3f81aad31aa4e642a03cf057c1ba21726d51f929fe027283d70624cf) 133 </li></ul></li></ul></li></ul></li> 134 135 <li>Yocto 1.7.1 (Dizzy) 20150904-1730: 136 <ul><li>Multimedia: 137 <ul><li><a class="ext-link" href="http://blog.gateworks.com/?wpdmpro=gateworks-image-multimedia-ventana-2.3_20170524183825_normal.rootfs.ubi"><span class="icon"></span>ubi 256MB FLASH</a> (sha256sum:e2b41e2ab9d0c7829996249b1bf04cb902cbdc1d300a1d4411d9f96540a2f91a) 138 </li><li><a class="ext-link" href="http://blog.gateworks.com/?wpdmpro=gateworks-image-multimedia-ventana-2.3_20170524183825_large.rootfs.ubi"><span class="icon"></span>ubi 1GB/2GB FLASH</a> (sha256sum:055b7644b1db05b96e33f948e1f314d39e7745fb1fd08dab248fe39f975c6eb2) 139 </li><li><a class="ext-link" href="http://blog.gateworks.com/?wpdmpro=gateworks-image-multimedia-ventana-2.3_20170524183825.rootfs.tar.bz2"><span class="icon"></span>rootfs tarball</a> (sha256sum:aa8db12b24a091db994d5cba1357e608b03be71c947a040954d70bd0ce7636d4) 140 </li></ul></li></ul></li></ul></li> 141 142 <li>Yocto 1.6.2 (Daisy) 20150221_0538: 143 <ul><li>Multimedia: 144 <ul><li><a class="ext-link" href="http://blog.gateworks.com/?wpdmpro=gateworks-image-multimedia-ventana-1.6.2_20150221_0538_normal.ubi"><span class="icon"></span>ubi 256MB FLASH</a> (sha256sum:c05a6cca542bd2004cf51bc161d5c73b1e63322a9a543c6f566a8e876ec9274a) 145 </li><li><a class="ext-link" href="http://blog.gateworks.com/?wpdmpro=gateworks-image-multimedia-ventana-1.6.2_20150221_0538_large.ubi"><span class="icon"></span>ubi 1GB/2GB FLASH</a> (sha256sum:10b27d97025df0c389972995497381a5e8e15beb79915f35c760aa0439370b7a) 146 </li><li><a class="ext-link" href="http://blog.gateworks.com/?wpdmpro=gateworks-image-multimedia-ventana-1.6.2_20150221_0538.rootfs.tar.bz2"><span class="icon"></span>rootfs tarball</a> (sha256sum:b383e6bcc4543719423c318cae588897fde36d5f68f4b1f989054bd287f7557b) 147 </li></ul></li></li></ul></li></ul> 36 * Yocto 2.3 (Pyro) 20170524: 37 - Multimedia: (supports gstreamer video in/out encode/decode, but no GUI desktop) 38 * [http://blog.gateworks.com/?wpdmpro=gateworks-image-multimedia-ventana-2.3_20170524183825_normal.rootfs.ubi ubi 256MB FLASH] (sha256sum:e2b41e2ab9d0c7829996249b1bf04cb902cbdc1d300a1d4411d9f96540a2f91a) 39 * [http://blog.gateworks.com/?wpdmpro=gateworks-image-multimedia-ventana-2.3_20170524183825_large.rootfs.ubi ubi 1GB/2GB FLASH] (sha256sum:055b7644b1db05b96e33f948e1f314d39e7745fb1fd08dab248fe39f975c6eb2) 40 * [http://blog.gateworks.com/?wpdmpro=gateworks-image-multimedia-ventana-2.3_20170524183825.rootfs.tar.bz2 rootfs tarball] (sha256sum:aa8db12b24a091db994d5cba1357e608b03be71c947a040954d70bd0ce7636d4) 41 42 [[CollapsibleStart(Old Releases)]] 43 * Yocto 1.8.2 (Fido) 20160328-1730: 44 - Multimedia: (supports gstreamer video in/out encode/decode, but no GUI desktop) 45 * [http://blog.gateworks.com/?wpdmpro=gateworks-image-multimedia-ventana-20160328-1730_normal-ubi ubi 256MB FLASH] (sha256sum:a012d6ffb287221e686de973870e4232fe54f08d208f9ce5a436933ecff02606) 46 * [http://blog.gateworks.com/?wpdmpro=gateworks-image-multimedia-ventana_large-ubi ubi 1GB/2GB FLASH] (sha256sum:be735f02f0a68b9cca797cd62e71b9de2ecea3ab6e64c23e3406b175c160f25a) 47 * [http://blog.gateworks.com/?wpdmpro=gateworks-image-multimedia-ventana-tar-bz2 rootfs tarball] (sha256sum:94734c2c442427deb1df537d1da9abebb9b6e5dab2891c3a35e8ac200540dd07) 48 - GUI: (supports gstreamer video in/out encode/decode and SATO X11 desktop with Matchbox window manager and Midori web browser) 49 * [http://blog.gateworks.com/?wpdmpro=gateworks-image-gui-ventana_large-ubi ubi 1GB/2GB FLASH] (sha256sum:96d229507a82022a9da7e91998b55dea706619c09548821d69712b97dc76919a) 50 * [http://blog.gateworks.com/?wpdmpro=gateworks-image-gui-ventana-tar-bz2 rootfs tarball] (sha256sum:12aecb6b2e38ba9f55c1986e8bb27c057521f96be1cb63227748db4cf3e8e7a3) 51 * Yocto 1.8.1 (Fido) 20160223-1730: 52 - Multimedia: 53 * [http://blog.gateworks.com/?wpdmpro=gateworks-image-multimedia-ventana-1.8.1_20160224031410_normal.rootfs.ubi ubi 256MB FLASH] (sha256sum:c1ecd3a4b9406d9274e89de94a2c76486d2440fefc0588feb495c0d021944697) 54 * [http://blog.gateworks.com/?wpdmpro=gateworks-image-multimedia-ventana-1.8.1_20160224031410_large.rootfs.ubi ubi 1GB/2GB FLASH] (sha256sum:d156c12c8973f21400ed8a9f374a8727284c776abba34c5b4cebfbce46997141) 55 * [http://blog.gateworks.com/?wpdmpro=gateworks-image-multimedia-ventana-1.8.1_20160224031410.rootfs.tar.bz2 rootfs tarball] (sha256sum:d17b603d3f81aad31aa4e642a03cf057c1ba21726d51f929fe027283d70624cf) 56 * Yocto 1.7.1 (Dizzy) 20150904-1730: 57 - Multimedia: 58 * [http://blog.gateworks.com/?wpdmpro=gateworks-image-multimedia-ventana-2.3_20170524183825_normal.rootfs.ubi ubi 256MB FLASH] (sha256sum:e2b41e2ab9d0c7829996249b1bf04cb902cbdc1d300a1d4411d9f96540a2f91a) 59 * [http://blog.gateworks.com/?wpdmpro=gateworks-image-multimedia-ventana-2.3_20170524183825_large.rootfs.ubi ubi 1GB/2GB FLASH] (sha256sum:055b7644b1db05b96e33f948e1f314d39e7745fb1fd08dab248fe39f975c6eb2) 60 * [http://blog.gateworks.com/?wpdmpro=gateworks-image-multimedia-ventana-2.3_20170524183825.rootfs.tar.bz2 rootfs tarball] (sha256sum:aa8db12b24a091db994d5cba1357e608b03be71c947a040954d70bd0ce7636d4) 61 * Yocto 1.6.2 (Daisy) 20150221_0538: 62 - Multimedia: 63 * [http://blog.gateworks.com/?wpdmpro=gateworks-image-multimedia-ventana-1.6.2_20150221_0538_normal.ubi ubi 256MB FLASH] (sha256sum:c05a6cca542bd2004cf51bc161d5c73b1e63322a9a543c6f566a8e876ec9274a) 64 * [http://blog.gateworks.com/?wpdmpro=gateworks-image-multimedia-ventana-1.6.2_20150221_0538_large.ubi ubi 1GB/2GB FLASH] (sha256sum:10b27d97025df0c389972995497381a5e8e15beb79915f35c760aa0439370b7a) 65 * [http://blog.gateworks.com/?wpdmpro=gateworks-image-multimedia-ventana-1.6.2_20150221_0538.rootfs.tar.bz2 rootfs tarball] (sha256sum:b383e6bcc4543719423c318cae588897fde36d5f68f4b1f989054bd287f7557b) 66 [[CollapsibleEnd]] 148 67 149 68 Version History: 150 </p> 151 <ul><li>Yocto v2.3: 152 <ul><li>Yocto 2.3 (Pyro) 20170524: 153 154 <ul><li>kernel: <a class="ext-link" href="https://github.com/Gateworks/linux-imx6/tree/3ae25e0dd3134b8f49270eee3b4a49733ff7eb05"><span class="icon"></span>3.14.48-1.0.x_ga+yocto+g3ae25e0</a> 155 156 </li><li>wireless drivers from linux-backports: 20160122 157 158 159 </li></ul></li></ul></li></ul><p> 160 </p><div> <h3 class="foldable">Older History</h3><div><p> 161 </p> 162 <ul><li>Yocto v1.8: 163 <ul><li>Yocto 1.8.2 (Fido) 20160328-1730: 164 <ul><li>kernel: <a class="ext-link" href="https://github.com/Gateworks/linux-imx6/tree/3ae25e0dd3134b8f49270eee3b4a49733ff7eb05"><span class="icon"></span>3.14.48-1.0.x_ga+yocto+g3ae25e0</a> 165 </li><li>wireless drivers from linux-backports: 20160122 166 </li></ul></li></ul> 167 168 <ul><li>Yocto 1.8.1 (Fido) 20160223-1730: 169 <ul><li>kernel: 3.14.48-1.0.x_ga+yocto+g7a5ffca6 170 </li><li>wireless drivers from linux-backports: 20150129 171 </li><li>fixed: gsc_update no longer erases user EEPROM data 172 </li><li>fixed: VPU firmware update to resolve various encoding timeouts 173 </li><li>fixed: FEC ethernet tx queue stalls 174 </li><li>fixed: NAND stability issue 175 </li><li>fixed: PWM pinmux 176 </li><li>fixed: mxc_v4l2_capture initialization 177 </li><li>fixed: reboot fix for GW5100 A/B revisions 178 </li><li>updated: bootscript updated to v1.06 to remove LVDS display detection 179 </li><li>added: added user controllable quality steps to gst-variable-rtsp-server 180 </li><li>added: gpsd 181 </li><li>added: crda 182 </li><li>added: ethtool 183 </li><li>added: hostapd-conf 184 </li><li>added: SPI for GW522x 185 </li><li>added: USB serial drivers 186 </li><li>added: 7" LVDS display touchscreen controller (gt9x) 187 </li><li>added: use GSC for power-down and restart 188 </li></ul></li> 189 190 <li>Yocto 1.8 (Fido) 20150904-2139: 191 <ul><li>Initial Gateworks Yocto v1.8 release 192 </li><li>kernel: 3.14.48-1.0.x_ga+yocto+g4ba0a59 193 </li><li>wireless drivers from linux-backports: 20150129 194 <ul><li>much improved ath10k performance/support including adhoc 195 </li></ul></li><li>added gstreamer 1.0 / gstreamer-imx 196 </li><li>added avc8000 8x D1 miniPCIe capture card support 197 </li><li>added gsc-update 198 </li><li>added uboot-envtools 199 </li><li>added gwsoc (GW16113) support) 200 </li></ul></li></ul></li><li>Yocto v1.7: 201 <ul><li>Yocto 1.7.1 (Dizzy) 20150904-1730: 202 <ul><li>kernel: 3.10.17-1.0.0_ga+yocto+g4078cea 203 </li><li>wireless drivers from linux-backports: 20141221 204 </li><li>default to ldo-enabled mode 205 </li><li>i2c: add retries on i2c nak's 206 </li><li>gsc: fix gsc hwmon negative temperature readings 207 </li><li>video: mxc: add support for HDMI interlace out 208 </li><li>add UHS-I support 209 </li><li>enable SATA_AHCI support 210 </li><li>enable PCA953x IRQ 211 </li><li>update IMX6SDL voltage set-points 212 </li><li>disable PCIe Gen2 213 </li><li>imx-thermal: set thresholds based on CPU temperature grade 214 </li><li>tda1997x: default to yuv422smp capture mode for 1080p60Hz 215 </li><li>tda1997x: fixed ITU709 colorimetry colorspace conversion 216 </li><li>sgtl5000: fix audio pop 217 </li></ul></li><li>Yocto 1.7.1 (Dizzy) 20150221-0225: 218 <ul><li>Initial Gateworks Yocto v1.7 release 219 </li><li>kernel: 3.10.17-1.0.0_ga+yocto+g4d177f6 220 </li></ul></li></ul></li><li>Yocto v1.6: 221 <ul><li>Yocto 1.6.2 - 20150221_0538: 222 <ul><li>added support for GW551x, GW552x 223 </li><li>added cryptodev module 224 </li><li>wireless drivers: 225 <ul><li>updated drivers to compat-wireless_20141221 226 </li><li>use internal regdb 227 </li></ul></li><li>kernel: 3.10.17-1.0.0_ga+yocto+g4d177f6 228 <ul><li>added support for DLC800FIGT3 8in XGA (1024x768) capacitive multi-touch touchscreen 229 </li><li>added support for DLC700JMGT4 7in WSVGA (1024x600) capacitive multi-touch touchscreens 230 </li><li>bumped IMX6Q/IMX6DL operating point voltages for VDD_ARM/VDD_SOC 231 </li><li>added GSC drivers (Watchdog / Input) 232 </li><li>fix gpio input state detect for PCA953x port expanders 233 </li><li>added support for GW551x, GW552x 234 </li><li>HDMI input: 235 <ul><li>fixed EDID handling 236 </li><li>add supoprt for HDMI input in 16bit YUV422 mode (requires alternate device-tree configuration) 237 </li><li>fix audio output format details and constrain samplerate 238 </li></ul></li><li>disable IMX6 busfreq driver 239 </li><li>add i210 support 240 </li><li>add GW16103 support 241 </li><li>GW51xx: fix invalid PPS gpio 242 </li><li>disable evbug driver 243 </li><li>add LTC3676 PMIC support and ldo-bypass mode for GW53xx/GW52xx/GW51xx/GW551x/GW552x) (lowers overall power-reduction and thermal envelope) 244 </li></ul></li></ul></li><li>Yocto 1.6.1 - 20141024: 245 <ul><li>kernel: 3.10.17-1.0.0_ga+yocto+gb5914e9 246 </li><li>occasional PCIe link issue resolved 247 </li><li>video sink issue resolved for same resolution input/output 248 </li><li>dual-display HDMI+CVBS fixed 249 </li><li>GW16082 support fixed 250 </li><li>PCIe IRQ slot mapping issue fixed 251 </li><li>GW5400 stability issue fixed 252 </li></ul></li></ul></li></ul><p> 253 </div></div> 254 </p> 255 <p> 256 For instructions on flashing UBI files, please see <a class="wiki" href="/wiki/Yocto/Building#NANDFlash">this section</a>. 257 </p> 258 <p> 259 <span class="wikianchor" id="build"></span> 260 </p> 261 <h1 id="ObtainingandCompilingtheSourceCode">Obtaining and Compiling the Source Code</h1> 262 <p> 69 * Yocto v2.3: 70 - Yocto 2.3 (Pyro) 20170524: 71 - kernel: 3.14.48-1.0.x_ga+yocto+g3ae25e0 72 - wireless drivers from linux-backports: 20160122 73 74 [[CollapsibleStart(Old Releases)]] 75 * Yocto v1.8: 76 - Yocto 1.8.2 (Fido) 20160328-1730: 77 - kernel: 3.14.48-1.0.x_ga+yocto+g3ae25e0 78 - wireless drivers from linux-backports: 20160122 79 - Yocto 1.8.1 (Fido) 20160223-1730: 80 - kernel: 3.14.48-1.0.x_ga+yocto+g7a5ffca6 81 - wireless drivers from linux-backports: 20150129 82 - fixed: gsc_update no longer erases user EEPROM data 83 - fixed: VPU firmware update to resolve various encoding timeouts 84 - fixed: FEC ethernet tx queue stalls 85 - fixed: NAND stability issue 86 - fixed: PWM pinmux 87 - fixed: mxc_v4l2_capture initialization 88 - fixed: reboot fix for GW5100 A/B revisions 89 - updated: bootscript updated to v1.06 to remove LVDS display detection 90 - added: added user controllable quality steps to gst-variable-rtsp-server 91 - added: gpsd 92 - added: crda 93 - added: ethtool 94 - added: hostapd-conf 95 - added: SPI for GW522x 96 - added: USB serial drivers 97 - added: 7" LVDS display touchscreen controller (gt9x) 98 - added: use GSC for power-down and restart 99 - Yocto 1.8 (Fido) 20150904-2139: 100 - Initial Gateworks Yocto v1.8 release 101 - kernel: 3.14.48-1.0.x_ga+yocto+g4ba0a59 102 - wireless drivers from linux-backports: 20150129 103 - much improved ath10k performance/support including adhoc 104 - added gstreamer 1.0 / gstreamer-imx 105 - added avc8000 8x D1 miniPCIe capture card support 106 - added gsc-update 107 - added uboot-envtools 108 - added gwsoc (GW16113) support) 109 * Yocto v1.7: 110 - Yocto 1.7.1 (Dizzy) 20150904-1730: 111 - kernel: 3.10.17-1.0.0_ga+yocto+g4078cea 112 - wireless drivers from linux-backports: 20141221 113 - default to ldo-enabled mode 114 - i2c: add retries on i2c nak's 115 - gsc: fix gsc hwmon negative temperature readings 116 - video: mxc: add support for HDMI interlace out 117 - add UHS-I support 118 - enable SATA_AHCI support 119 - enable PCA953x IRQ 120 - update IMX6SDL voltage set-points 121 - disable PCIe Gen2 122 - imx-thermal: set thresholds based on CPU temperature grade 123 - tda1997x: default to yuv422smp capture mode for 1080p60Hz 124 - tda1997x: fixed ITU709 colorimetry colorspace conversion 125 - sgtl5000: fix audio pop 126 - Yocto 1.7.1 (Dizzy) 20150221-0225: 127 - Initial Gateworks Yocto v1.7 release 128 - kernel: 3.10.17-1.0.0_ga+yocto+g4d177f6 129 * Yocto v1.6: 130 - Yocto 1.6.2 - 20150221_0538: 131 - added support for GW551x, GW552x 132 - added cryptodev module 133 - wireless drivers: 134 - updated drivers to compat-wireless_20141221 135 - use internal regdb 136 - kernel: 3.10.17-1.0.0_ga+yocto+g4d177f6 137 - added support for DLC800FIGT3 8in XGA (1024x768) capacitive multi-touch touchscreen 138 - added support for DLC700JMGT4 7in WSVGA (1024x600) capacitive multi-touch touchscreens 139 - bumped IMX6Q/IMX6DL operating point voltages for VDD_ARM/VDD_SOC 140 - added GSC drivers (Watchdog / Input) 141 - fix gpio input state detect for PCA953x port expanders 142 - added support for GW551x, GW552x 143 - HDMI input: 144 * fixed EDID handling 145 * add supoprt for HDMI input in 16bit YUV422 mode (requires alternate device-tree configuration) 146 - fix audio output format details and constrain samplerate 147 - disable IMX6 busfreq driver 148 - add i210 support 149 - add GW16103 support 150 - GW51xx: fix invalid PPS gpio 151 - disable evbug driver 152 - add LTC3676 PMIC support and ldo-bypass mode for GW53xx/GW52xx/GW51xx/GW551x/GW552x) (lowers overall power-reduction and thermal envelope) 153 - Yocto 1.6.1 - 20141024: 154 - kernel: 3.10.17-1.0.0_ga+yocto+gb5914e9 155 - occasional PCIe link issue resolved 156 - video sink issue resolved for same resolution input/output 157 - dual-display HDMI+CVBS fixed 158 - GW16082 support fixed 159 - PCIe IRQ slot mapping issue fixed 160 - GW5400 stability issue fixed 161 [[CollapsibleEnd]] 162 163 For instructions on flashing UBI files, please see [wiki:Yocto/Building#NANDFlash this section]. 164 165 166 = Obtaining and Compiling the Source Code = 263 167 The following build instructions refer to Debian GNU/Linux 7.4 and Ubuntu 12.04 - 15.10. 264 </p> 265 <p> 168 266 169 Please make sure the following packages are installed 267 </p> 268 <div class="code"><pre>sudo apt-get install chrpath libsdl-dev texinfo curl build-essential git subversion diffstat gawk 269 </pre></div><ol><li>fetch the <tt>repo</tt> tool (if you don't have it already in your path): 270 <div class="code"><pre>mkdir ~/bin 271 curl http://commondatastorage.googleapis.com/git-repo-downloads/repo > ~/bin/repo 170 {{{#!bash 171 sudo apt-get install chrpath libsdl-dev texinfo curl build-essential git subversion diffstat gawk 172 }}} 173 174 Instructions: 175 1. fetch the repo tool (if you don't have it already in your path): 176 {{{#!bash 177 mkdir ~/bin 178 curl http://commondatastorage.googleapis.com/git-repo-downloads/repo > ~/bin/repo 272 179 chmod a+x ~/bin/repo 273 </pre></div></li></ol><ol start="2"><li>Setup source repos: 274 <div class="code"><pre><span class="nv">PATH</span><span class="o">=</span><span class="k">${</span><span class="nv">PATH</span><span class="k">}</span>:~/bin 180 }}} 181 182 2. Setup source repos: 183 {{{#!bash 184 PATH=${PATH}:~/bin 275 185 mkdir ~/ventana-yocto 276 <span class="nb">cd </span>ventana-yocto186 cd ventana-yocto 277 187 repo init -u https://github.com/Gateworks/gateworks-yocto-bsp-platform -b fido 278 </pre></div><ul><li>in the above command <tt>fido</tt> is the name of the branch that refers to Yocto v1.8 279 </li></ul></li></ol><ol start="3"><li>(optional) pin the repo versions to the latest version which was known to have been successfully built by the Gateworks nightly build server: 280 <div class="code"><pre>wget http://dev.gateworks.com/yocto/1.8/snapshot.xml <span class="c"># fetch the pinned manifest from the last successful nightly build 281 </span>mv snapshot.xml .repo/manifest.xml <span class="c"># copy over the generic un-pinned manifest 282 </span></pre></div><ul><li>the <tt>repo init</tt> command will fetch a repo 'manifest' which refers to various source repositories and branches but will fetch the latest changes from those branches (which occasionally may fail to build due to upstream errors common with community based projects). The Gateworks nightly build server posts the manifest pinned to the specific revision used in the build on completion of a successful build. You can also use a snapshot from a previously released pre-built binary by using the other snapshot files in <a class="ext-link" href="http://dev.gateworks.com/yocto/1.8"><span class="icon"></span>http://dev.gateworks.com/yocto/1.8</a> 283 </li></ul></li></ol><ol start="4"><li>Download latest sources: 284 <div class="code"><pre>repo sync -c -j8 285 </pre></div><ul><li>the <tt>-c</tt> parameter tells repo to just pull down the current branch specified by the manifest file (thus is more network and disk usage efficient) 286 </li><li>the <tt>-j</tt> parameter tells repo to use multiple processes (8 in this example) which will speed up fetching 287 </li><li>you can later repeat the <tt>repo sync</tt> to pull down the latest sources specified for the repo manifest file for the current branch specified in the <tt>repo init</tt> in step 2 above 288 </li></ul></li></ol><ol start="5"><li>Activate <tt>bitbake</tt> environment. You will have to accept license agreement. 289 <div class="code"><pre>. ./setup-environment build 290 </pre></div><ul><li><strong>do this every time for a new shell when you wish to use <tt>bitbake</tt></strong> 291 </li></ul></li></ol><ol start="6"><li>Build a filesystem image recipe. <tt>gateworks-image-multimedia</tt> is recommended. 292 <ul><li>For a detailed description of the Gateworks specific images, please see <a class="wiki" href="/wiki/Yocto/images#ImageUseCases">the images page</a>. 293 <div class="code"><pre>bitbake gateworks-image-multimedia 294 </pre></div></li><li>This could take several hours depending on your Internet speed and development host 295 </li><li>core-image-minimal results in 1.8GB of downloaded sources, 14GB of space used in build/tmp, and takes ~70mins on a Quad-core 2.5GHz build host, not accounting for your network connection. 296 </li><li>By default, images, kernels, etc are found in <tt>tmp/deploy/images/ventana</tt> 297 </li></ul></li></ol><ol start="7"><li>Grab <tt>.ubi</tt> file which contains both kernel and root filesystem and program it to the board with instructions below: 298 <div class="code"><pre>tmp/deploy/images/ventana/gateworks-image-multimedia-ventana_normal.ubi 188 }}} 189 * in the above command, {{{fido}}} is the name of the branch that refers to Yocto v1.8 190 191 3. (optional) pin the repo versions to the latest version which was known to have been successfully built by the Gateworks nightly build server: 192 {{{#!bash 193 wget http://dev.gateworks.com/yocto/1.8/snapshot.xml # fetch the pinned manifest from the last successful nightly build 194 mv snapshot.xml .repo/manifest.xml # copy over the generic un-pinned manifest 195 }}} 196 * the {{{repo init}}} command will fetch a repo 'manifest' which refers to various source repositories and branches but will fetch the latest changes from those branches (which occasionally may fail to build due to upstream errors common with community based projects). The Gateworks nightly build server posts the manifest pinned to the specific revision used in the build on completion of a successful build. You can also use a snapshot from a previously released pre-built binary by using the other snapshot files in http://dev.gateworks.com/yocto/1.8 197 198 4. Download latest sources: 199 {{{#!bash 200 repo sync -c -j8 201 }}} 202 * the {{{-c}}} parameter tells repo to just pull down the current branch specified by the manifest file (thus is more network and disk usage efficient) 203 * the {{{-j}}} parameter tells repo to use multiple processes (8 in this example) which will speed up fetching 204 * you can later repeat the {{{repo sync}}} to pull down the latest sources specified for the repo manifest file for the current branch specified in the repo init in step 2 above 205 206 5. Activate bitbake environment. You will have to accept license agreement. 207 {{{#!bash 208 . ./setup-environment build 209 }}} 210 * **do this every time for a new shell when you wish to use {{{bitbake}}}** 211 212 6. Build a filesystem image recipe. gateworks-image-multimedia is recommended. 213 {{{#!bash 214 bitbake gateworks-image-multimedia 215 }}} 216 * For a detailed description of the Gateworks specific images, please see the images page. 217 * This could take several hours depending on your Internet speed and development host 218 * {{{core-image-minimal}}} results in 1.8GB of downloaded sources, 14GB of space used in build/tmp, and takes ~70mins on a Quad-core 2.5GHz build host, not accounting for your network connection. 219 * By default, images, kernels, etc are found in {{{tmp/deploy/images/ventana}}}. 220 221 7. Grab .ubi file which contains both kernel and root filesystem and program it to the board with instructions below: 222 {{{#!bash 223 tmp/deploy/images/ventana/gateworks-image-multimedia-ventana_normal.ubi 299 224 tmp/deploy/images/ventana/gateworks-image-multimedia-ventana_large.ubi 300 </pre></div></li></ol><p> 225 }}} 226 301 227 Notes: 302 </p> 303 <ul><li>to download any updates and rebuild, repeat the above starting with step 3 304 </li><li>to re-activate a new shell repeat the above starting with step 4 (you can only have 1 shell activated at a time - you need to activate a new shell if you have exited a previously activated shell) 305 </li><li>to clean a specific recipe use <tt>bitbake -f -c clean <recipe></tt>. Note that to represent the kernel you can use the virtual recipe name 'virtual/kernel' 306 <ul><li>Note: After cleaning a recipe, rebuild with the <tt>--no-setscene</tt> command line argument to <tt>bitbake</tt>, e.g. <tt>bitbake --no-setscene <recipe></tt> 307 </li></ul></li><li>to clean all built items (but not remove downloaded sources or the sstate-cache) you can <tt>rm -rf tmp</tt> 308 </li><li>to clean everything and start over you can remove the entire build directory and repeat the above starting with step 4 (this will remove all downloaded sources as well) 309 </li></ul><p> 228 * to download any updates and rebuild, repeat the above starting with step 3 229 * to re-activate a new shell repeat the above starting with step 4 (you can only have 1 shell activated at a time - you need to activate a new shell if you have exited a previously activated shell) 230 * to clean a specific recipe use {{{bitbake -f -c clean <recipe>}}}. Note that to represent the kernel you can use the virtual recipe name 'virtual/kernel' 231 - Note: After cleaning a recipe, rebuild with the {{{--no-setscene}}} command line argument to bitbake, e.g. bitbake --no-setscene <recipe> 232 * to clean all built items (but not remove downloaded sources or the sstate-cache) you can {{{rm -rf tmp}}}. 233 * to clean everything and start over you can remove the entire build directory and repeat the above starting with step 4 (this will remove all downloaded sources as well) 234 310 235 Useful References: 311 </p> 312 <ul><li><a class="ext-link" href="http://www.crashcourse.ca/wiki/index.php/Yocto_FAQ"><span class="icon"></span>http://www.crashcourse.ca/wiki/index.php/Yocto_FAQ</a> 313 </li><li><a class="ext-link" href="http://xda-university.com/as-a-developer/repo-tips-tricks"><span class="icon"></span>http://xda-university.com/as-a-developer/repo-tips-tricks</a> 314 </li></ul><h2 id="Troubleshootingbuildfailures">Troubleshooting build failures</h2> 315 <p> 316 The <a class="missing wiki">OpenEmbedded?</a> build system does a fairly good job of reporting build errors in a sane way to help you diagnose the problem. 317 </p> 318 <p> 319 In general, for each package that failed, you will see three lines of output from <tt>bitbake</tt> for each package. For example, the following shows a 'fetch error' for the <tt>evtest_1.25</tt> package: 320 </p> 321 <div class="code"><pre>ERROR: Function failed: Fetcher failure <span class="k">for </span>URL: <span class="s1">'http://cgit.freedesktop.org/~whot/evtest/snapshot/evtest-1.25.tar.bz2;name=archive'</span>. Unable to fetch URL from any source. 236 * http://www.crashcourse.ca/wiki/index.php/Yocto_FAQ 237 * http://xda-university.com/as-a-developer/repo-tips-tricks 238 239 240 == Troubleshooting build failures == 241 The OpenEmbedded build system does a fairly good job of reporting build errors in a sane way to help you diagnose the problem. 242 243 In general, for each package that failed, you will see three lines of output from {{{bitbake}}} for each package. For example, the following shows a 'fetch error' for the {{{evtest_1.25}}} package: 244 {{{#!bash 245 ERROR: Function failed: Fetcher failure for URL: 'http://cgit.freedesktop.org/~whot/evtest/snapshot/evtest-1.25.tar.bz2;name=archive'. Unable to fetch URL from any source. 322 246 ERROR: Logfile of failure stored in: /usr/src/tharvey/nightly/yocto/danny/20140820_8bd8be2d/build/tmp/work/armv7a-vfp-neon-poky-linux-gnueabi/evtest-1.25-r0/temp/log.do_fetch.23170 323 ERROR: Task 452 <span class="o">(</span>/usr/src/tharvey/nightly/yocto/danny/20140820_8bd8be2d/sources/meta-openembedded/meta-oe/recipes-support/evtest/evtest_1.25.bb, do_fetch<span class="o">)</span> failed with <span class="nb">exit </span>code <span class="s1">'1'</span> 324 </pre></div><p> 247 ERROR: Task 452 (/usr/src/tharvey/nightly/yocto/danny/20140820_8bd8be2d/sources/meta-openembedded/meta-oe/recipes-support/evtest/evtest_1.25.bb, do_fetch) failed with exit code '1' 248 }}} 249 325 250 The first ERROR line here shows the cause of the issue, the second shows where the detailed log of the failure is, and the third simply says what package and task failed. If you need assistance understanding a particular error, you will want to provide the three lines above as well as the log file pointed to in the second line. 326 </p> 327 <h3 id="Fetchfailure">Fetch failure</h3> 328 <p> 329 The most common build failure (of any linux build system) is failure to be able to fetch sources for the 100's of <a class="missing wiki">OpenSource?</a> projects the build system uses from the Internet. This can be caused by a network issue on your end, a network issue on the source package sites end, or a site/file that has been permanently moved/removed. 330 </p> 331 <p> 332 If this occurs you will see an 'ERROR: Function failed: Fetcher failure' message such as the following output from <tt>bitbake</tt>: 333 </p> 334 <div class="code"><pre>ERROR: Function failed: Fetcher failure <span class="k">for </span>URL: <span class="s1">'http://cgit.freedesktop.org/~whot/evtest/snapshot/evtest-1.25.tar.bz2;name=archive'</span>. Unable to fetch URL from any source. 335 </pre></div><p> 336 If you encounter such an error the most obvious thing to make sure your Internet connection is solid and try first is simply <tt>bitbake</tt> your desired package again. If it occurs again, its likely an issue on the site that the package URI specifies as the package source. This could be a temporary issue, or the site/file could have been permanently moved/removed for some reason and your either building an older BSP or the package source simply hasn't been updated to deal with the change (as I mentioned, this is a common issue). 337 </p> 338 <p> 339 To combat this issue, there are mirrors where you may be able to find the missing file(s). Note that Gateworks provides such a mirror that it tries to keep updated at <a class="ext-link" href="http://dev.gateworks.com/sources"><span class="icon"></span>http://dev.gateworks.com/sources</a>. Once you find the file, copy it to your download directory, touch the file indicating the fetch is done (the source file with a .done on the end) and <tt>bitbake</tt> your package again. For example, the above shows a failure to fetch the <tt>evtest-1.25.tar.bz2</tt> file: 340 </p> 341 <div class="code"><pre>wget http://dev.gateworks.com/sources/evtest-1.25.tar.bz2 251 252 === Fetch failure === 253 The most common build failure (of any linux build system) is failure to be able to fetch sources for the 100's of OpenSource projects the build system uses from the Internet. This can be caused by a network issue on your end, a network issue on the source package sites end, or a site/file that has been permanently moved/removed. 254 255 If this occurs you will see an 'ERROR: Function failed: Fetcher failure' message such as the following output from {{{bitbake}}}: 256 {{{#!bash 257 ERROR: Function failed: Fetcher failure for URL: 'http://cgit.freedesktop.org/~whot/evtest/snapshot/evtest-1.25.tar.bz2;name=archive'. Unable to fetch URL from any source. 258 }}} 259 260 If you encounter such an error the most obvious thing to make sure your Internet connection is solid and try first is simply {{{bitbake}}} your desired package again. If it occurs again, its likely an issue on the site that the package URI specifies as the package source. This could be a temporary issue, or the site/file could have been permanently moved/removed for some reason and your either building an older BSP or the package source simply hasn't been updated to deal with the change (as I mentioned, this is a common issue). 261 262 To combat this issue, there are mirrors where you may be able to find the missing file(s). Note that Gateworks provides such a mirror that it tries to keep updated at http://dev.gateworks.com/sources. Once you find the file, copy it to your download directory, touch the file indicating the fetch is done (the source file with a .done on the end) and bitbake your package again. For example, the above shows a failure to fetch the evtest-1.25.tar.bz2 file: 263 {{{#!bash 264 wget http://dev.gateworks.com/sources/evtest-1.25.tar.bz2 342 265 cp evtest-1.25.tar.bz2 downloads/ 343 266 touch downloads/evtest-1.25.tar.bz2.done 344 267 bitbake gateworks-image-multimedia 345 </pre></div><h3 id="UpstreamBreakage">Upstream Breakage</h3> 346 <p> 268 }}} 269 270 === Upstream Breakage === 347 271 It is not uncommon for community based projects such as Yocto to encounter build failures after changes because of the complexity of the build system. In some cases breakage may occur simply because of collisions between upstream Yocto repos and the packages that Gateworks overrides. 348 </p> 349 <p> 350 If you are building an 'un-pinned' release (you are not using a snapshot of the manifest file which has sha revisions for each repository) and you encounter a build failure, you may want to switch to a manifest file that produced a successful build by the Gateworks nightly build server. Manifests point to source code repositories by network server and branch, but typically do not pin the branch to a specific repository commit. A 'pinned' snapshot can be used instead that does specify a specific commit of each repository and branch. Refer to step 3 in the <a class="wiki" href="/wiki/Yocto/Building#build">instructions above</a> 351 </p> 352 <p> 353 <span class="wikianchor" id="repo"></span> 354 </p> 355 <h2 id="Keepinguptodateandorpinningsourcewithrepo">Keeping up to date and/or pinning source with repo</h2> 356 <p> 357 When building projects that use multiple source repositories any repository may change and thus make your working directory out of date. Because Yocto uses several package feeds with their own repositories this can make it difficult to keep in sync - this is where the <tt>repo</tt> tool comes in handy. 358 </p> 359 <p> 360 The <tt>repo sync</tt> command will update all repositories with upstream changes: 361 </p> 362 <div class="code"><pre>repo sync --quiet 363 </pre></div><p> 272 273 If you are building an 'un-pinned' release (you are not using a snapshot of the manifest file which has sha revisions for each repository) and you encounter a build failure, you may want to switch to a manifest file that produced a successful build by the Gateworks nightly build server. Manifests point to source code repositories by network server and branch, but typically do not pin the branch to a specific repository commit. A 'pinned' snapshot can be used instead that does specify a specific commit of each repository and branch. Refer to step 3 in the [wiki:Yocto/Building#build instructions above]. 274 275 276 == Keeping up to date and/or pinning source with repo == 277 When building projects that use multiple source repositories any repository may change and thus make your working directory out of date. Because Yocto uses several package feeds with their own repositories this can make it difficult to keep in sync - this is where the {{{repo}}} tool comes in handy. 278 279 The {{{repo sync}}} command will update all repositories with upstream changes: 280 {{{#!bash 281 repo sync --quiet 282 }}} 283 364 284 You can override the default Manifest by using a local manifest file if you want to keep in sync with the upstream manifest yet make some minor change like pin a specific project or add a couple of projects. Reasons for doing this could be: 365 </p> 366 <ul><li>adding new projects 367 </li><li>pinning certain projects 368 </li><li>removing certain projects 369 </li></ul><p> 370 To use a local manifest create <tt>.repo/local_manifest.xml</tt> and it will be merged with <tt>.repo/manifest.xml</tt> by the <tt>repo</tt> tool whenever the manifest is used. You can use the <tt>remove-project</tt> directive to remove a project that you don't want and even add it back with your own choices if you want something different. For example: 371 </p> 372 <div class="code"><pre><span class="cp"><?xml version="1.0" encoding="UTF-8"?></span> 373 <span class="nt"><manifest></span> 374 <span class="nt"><remove-project</span> <span class="na">path=</span><span class="s">"hardware/qcom/display"</span> <span class="na">name=</span><span class="s">"CyanogenMod/android_hardware_qcom_display"</span> <span class="nt">/></span> 375 <span class="nt"><project</span> <span class="na">path=</span><span class="s">"hardware/qcom/display"</span> <span class="na">name=</span><span class="s">"WinSuk/android_hardware_qcom_display"</span> <span class="nt">/></span> 376 <span class="nt"></manifest></span> 377 </pre></div><p> 378 The <tt>repo manifest</tt> command will create a snapshot of your current project's manifest allowing you to create a pinned version that can be used later to create a working directory with the various projects at the exact same state as your current working directory: 379 </p> 380 <div class="code"><pre>repo manifest -o snapshot.xml -r 381 </pre></div><p> 382 This snapshot can then be copied over <tt>.repo/manifest.xml</tt> in a different build directory to pin the repository sources. 383 </p> 384 <p> 385 The Gateworks nightly build server creates a manifest snapshot like this and uploads the latest successful build to <a class="ext-link" href="http://dev.gateworks/com/yocto"><span class="icon"></span>http://dev.gateworks/com/yocto</a> so that it can be used to re-create a successful nightly build. 386 </p> 387 <p> 285 * adding new projects 286 * pinning certain projects 287 * removing certain projects 288 289 To use a local manifest create {{{.repo/local_manifest.xml}}} and it will be merged with {{{.repo/manifest.xml}}} by the {{{repo}}} tool whenever the manifest is used. You can use the {{{remove-project}}} directive to remove a project that you don't want and even add it back with your own choices if you want something different. For example: 290 {{{#!bash 291 <?xml version="1.0" encoding="UTF-8"?> 292 <manifest> 293 <remove-project path="hardware/qcom/display" name="CyanogenMod/android_hardware_qcom_display" /> 294 <project path="hardware/qcom/display" name="WinSuk/android_hardware_qcom_display" /> 295 </manifest> 296 }}} 297 298 The {{{repo manifest}}} command will create a snapshot of your current project's manifest allowing you to create a pinned version that can be used later to create a working directory with the various projects at the exact same state as your current working directory: 299 {{{#!bash 300 repo manifest -o snapshot.xml -r 301 }}} 302 303 This snapshot can then be copied over {{{.repo/manifest.xml}}} in a different build directory to pin the repository sources. 304 305 The Gateworks nightly build server creates a manifest snapshot like this and uploads the latest successful build to http://dev.gateworks/com/yocto so that it can be used to re-create a successful nightly build. 306 388 307 References: 389 </p> 390 <ul><li><a class="ext-link" href="https://source.android.com/source/using-repo.html"><span class="icon"></span>Official docs on using repo</a> 391 </li><li><a class="ext-link" href="http://xda-university.com/as-a-developer/repo-tips-tricks"><span class="icon"></span>xda-university repo tips and tricks</a> 392 </li><li><a class="ext-link" href="http://wiki.cyanogenmod.org/w/Doc:_Using_manifests"><span class="icon"></span>Cyanogenmod docs on using manifests</a> 393 </li><li><a class="ext-link" href="https://gerrit.googlesource.com/git-repo/+/master/docs/manifest-format.txt"><span class="icon"></span>repo Manifest Format: the official, technical documentation for repo manifests</a> 394 </li></ul><p> 395 <span class="wikianchor" id="rebuild"></span> 396 </p> 397 <h2 id="Updatingandrebuilding">Updating and rebuilding</h2> 398 <p> 308 * [https://source.android.com/source/using-repo.html Official docs on using repo] 309 * [http://xda-university.com/as-a-developer/repo-tips-tricks xda-university repo tips and tricks] 310 * [https://gerrit.googlesource.com/git-repo/+/master/docs/manifest-format.txt repo Manifest Format: the official, technical documentation for repo manifests] 311 312 313 == Updating and rebuilding == 399 314 From time to time the various repositories including in the Yocto build (a combination of Gateworks packages, community packages, Freescale community packages, and Yocto community packages) will get updates to various packages to add features or resolve issues. 400 </p> 401 <p> 402 The <tt>repo</tt> tool which manages the set of repositories in your yocto directory (based on a package manifest) can 'sync' all repos to the latest state using the following in the main yocto directory (the directory containing the sources and build subdirs: 403 </p> 404 <div class="code"><pre>./repo sync 405 </pre></div><p> 406 Following a sync, you can <tt>bitbake</tt>your filesystem image again to build a new filesystem with all updates:407 </p> 408 <div class="code"><pre><span class="c"># activate a bitbake shell if not already done409 </span>. ./setup-environment build315 316 The {{{repo}}} tool which manages the set of repositories in your yocto directory (based on a package manifest) can 'sync' all repos to the latest state using the following in the main yocto directory (the directory containing the sources and build subdirs: 317 {{{#!bash 318 ./repo sync 319 }}} 320 321 Following a sync, you can {{{bitbake}}} your filesystem image again to build a new filesystem with all updates: 322 {{{#!bash 323 # activate a bitbake shell if not already done 324 . ./setup-environment build 410 325 bitbake gateworks-image-multimedia 411 </pre></div><ul><li>build the filesystem image of your liking 412 </li></ul><h2 id="Diskusageandkeepingthingsclean">Disk usage and keeping things clean</h2> 413 <p> 326 }}} 327 * build the filesystem image of your liking 328 329 330 == Disk usage and keeping things clean == 414 331 Yocto builds can chew up a lot of disk space (true really of any OS build system). 415 </p> 416 <p> 417 <tt>Bitbake</tt> will keep copies of all workdirs for old packages, so over time if you update recipes (or <tt>repo sync</tt> which may update recipes) your disk usage will grow. You can safely remove the old packages manually from <tt>build/tmp</tt> if you wish, or use <tt>bitbake -cclean <recipe.bb></tt> to clean specific recipes (note that <tt>bitbake -cclean <package></tt> will only clean the current preferred version, not old packages). 418 </p> 419 <p> 420 Another thing that can cause disk usage bloat is filesystem images. Each time you build a filesystem image (ie gateworks-image-*) <tt>bitbake</tt> will create a new one with a timestamp in <tt>build/tmp/deploy/images/</tt> and the build system will keep around several artifacts such as the filesystem tarball, the ubifs, and the ubi (thus a filesystem image resulting in a 100MB UBI actually chews up over 300MB of disk space each time you build it depending on compression). Its very likely that if you are re-building an image, you probably don't care about the old ones, so you might want to get in the habit of removing them before building. For example, if you want to build gateworks-image-multimedia: 421 </p> 422 <div class="code"><pre>rm -rf build/tmp/deploy/images/gateworks-image-multimedia* ;<span class="c"># remove old images we don't care about 423 </span>bitbake gateworks-image-multimedia ;<span class="c"># build a new one 424 </span></pre></div><p> 332 333 Bitbake will keep copies of all workdirs for old packages, so over time if you update recipes (or {{{repo sync}}} which may update recipes) your disk usage will grow. You can safely remove the old packages manually from build/tmp if you wish, or use {{{bitbake -cclean <recipe.bb>}}} to clean specific recipes (note that {{{bitbake -cclean <package>}}} will only clean the current preferred version, not old packages). 334 335 Another thing that can cause disk usage bloat is filesystem images. Each time you build a filesystem image (ie gateworks-image-*) {{{bitbake}}} will create a new one with a timestamp in {{{build/tmp/deploy/images/}}} and the build system will keep around several artifacts such as the filesystem tarball, the ubifs, and the ubi (thus a filesystem image resulting in a 100MB UBI actually chews up over 300MB of disk space each time you build it depending on compression). Its very likely that if you are re-building an image, you probably don't care about the old ones, so you might want to get in the habit of removing them before building. For example, if you want to build gateworks-image-multimedia: 336 {{{#!bash 337 rm -rf build/tmp/deploy/images/gateworks-image-multimedia* ;# remove old images we don't care about 338 bitbake gateworks-image-multimedia ;# build a new one 339 }}} 425 340 For Yocto, all temporary files will be in build/tmp so if you want to clear out everything and start over you can: 426 </p> 427 <div class="code"><pre>rm -rf build/tmp 428 </pre></div><h2 id="BuildingUpdatingAddingPackages">Building / Updating / Adding Packages</h2> 429 <p> 430 Please read more <a class="wiki" href="/wiki/Yocto/packages">Yocto/packages</a> 431 </p> 432 <p> 433 <span class="wikianchor" id="yocto_building_sdk"></span> 434 </p> 435 <h2 id="BuildingatoolchainandorSDK">Building a toolchain and/or SDK</h2> 436 <p> 437 See <a class="wiki" href="/wiki/Yocto/SDK">Yocto/SDK</a> for information about a pre-built downloadable SDK 438 </p> 439 <p> 440 You can use <tt>bitbake</tt> to create a toolchain (cross-compiler) or an Software Development Kit (SDK) comprised of a cross-toolchain and libs. 441 </p> 442 <p> 341 {{{ 342 rm -rf build/tmp 343 }}} 344 345 == Building / Updating / Adding Packages == 346 For information concerning building, updating, and adding packages please see [wiki:Yocto/packages Yocto/packages]. 347 348 == Building a toolchain and/or SDK == 349 See [wiki:Yocto/SDK Yocto/SDK] for information about a pre-built downloadable SDK. 350 351 You can use {{{bitbake}}} to create a toolchain (cross-compiler) or an Software Development Kit (SDK) comprised of a cross-toolchain and libs. 352 443 353 Toolchain: 444 </p> 445 <div class="code"><pre>bitbake meta-toolchain 446 </pre></div><p> 354 {{{#!bash 355 bitbake meta-toolchain 356 }}} 357 447 358 SDK (contains meta-toolchain as well as -dev and -dbg packages with headers and libs): 448 </p> 449 <div class="code"><pre>bitbake -cpopulate_sdk gateworks-image-multimedia 450 </pre></div><ul><li>The produced SDK will be a self-extracting shell-script in tmp/deploy/sdk that contains all the include headers and libs for the packages in the image - you can build an SDK for any image by replacing 'gateworks-image-multimedia' with any other buildable filesystem image. 451 </li></ul><h2 id="Otherusefullinks">Other useful links</h2> 452 <ul><li>For those that may want to compile the Freescale Image: 453 <ul><li><a class="ext-link" href="https://community.freescale.com/docs/DOC-1616"><span class="icon"></span>https://community.freescale.com/docs/DOC-1616</a> 454 </li></ul></li></ul><p> 455 <span class="wikianchor" id="yocto_installing"></span> 456 </p> 457 <h1 id="InstallingFirmware">Installing Firmware</h1> 458 <p> 459 <span class="wikianchor" id="yocto_installing_flash"></span> 460 </p> 461 <h2 id="NANDFLASH">NAND FLASH</h2> 462 <p> 359 {{{#!bash 360 bitbake -cpopulate_sdk gateworks-image-multimedia 361 }}} 362 * The produced SDK will be a self-extracting shell-script in tmp/deploy/sdk that contains all the include headers and libs for the packages in the image - you can build an SDK for any image by replacing 'gateworks-image-multimedia' with any other buildable filesystem image. 363 364 == Other useful links == 365 For those that may want to compile the Freescale Image: 366 * https://community.freescale.com/docs/DOC-1616 367 368 369 = Installing Firmware = 370 371 == NAND FLASH == 463 372 There are 2 options: 464 </p> 465 <ol><li>TFTP Server (recommended) - Read below 466 </li><li>JTAG Programmer (more steps and slower, requires no network)- Link <a class="wiki" href="/wiki/jtag_instructions#CreatingjtagableimagesforVentana">here</a> 467 </li></ol><p> 468 Boards with a NAND FLASH large enough to accommodate your image (Ventana boards have a 256MB NAND flash by default which is large enough for fsl-image-multimedia) can have the UBI filesystem created by the build process placed on them. A ubi image will be built in tmp/deploy/images directory alongside the kernel and filesystem tarballs. The ubi image will end with _normal.ubi which is suitable for standard NAND flash sizes on Ventana boards. If you have a Ventana with a 1GB or larger NAND device, you need to build for the 'large' NAND flash layout which you can do by changing the UBI_CONFIG variable in <tt>sources/meta-gateworks/conf/machine/ventana.conf</tt> from 'normal' to 'large' which will result in a ubi image ending with <tt>_large.ubi</tt>. 469 </p> 470 <p> 373 1. TFTP Server (recommended) - Read below 374 2. JTAG Programmer (more steps and slower, requires no network)- Link [wiki:jtag_instructions#CreatingjtagableimagesforVentana here] 375 376 Boards with a NAND FLASH large enough to accommodate your image (Ventana boards have a 256MB NAND flash by default which is large enough for fsl-image-multimedia) can have the UBI filesystem created by the build process placed on them. A ubi image will be built in tmp/deploy/images directory alongside the kernel and filesystem tarballs. The ubi image will end with _normal.ubi which is suitable for standard NAND flash sizes on Ventana boards. If you have a Ventana with a 1GB or larger NAND device, you need to build for the 'large' NAND flash layout which you can do by changing the UBI_CONFIG variable in {{{sources/meta-gateworks/conf/machine/ventana.conf}}} from 'normal' to 'large' which will result in a ubi image ending with {{{_large.ubi}}}. 377 471 378 To install firmware to a Ventana board using Serial/ENET, do the following: 472 </p> 473 <p> 379 474 380 First, get yourself into a sane state: 475 </p> 476 <ul><li>Copy your UBI file to a proper location that your <a class="wiki" href="/wiki/tftpserver">tftpserver</a> has access to 477 </li><li>connect to the serial console of the target board (instructions may be found <a class="wiki" href="/wiki/jtag_instructions#SerialConsoleAccessonLinux">here</a> if you are unfamiliar with this) 478 </li></ul><ol><li>Connect your target board to your network, set ipaddress and serverip in uboot 479 <div class="code"><pre><span class="c"># Break out of the bootloader 480 </span>setenv ipaddr <localip> 481 setenv serverip <serverip> 482 </pre></div>For Example: 483 <div class="code"><pre>setenv ipaddr 192.168.1.211 381 * Copy your UBI file to a proper location that your tftpserver has access to 382 * connect to the serial console of the target board (instructions may be found here if you are unfamiliar with this) 383 384 1. Connect your target board to your network, set ipaddress and serverip in uboot 385 {{{#!bash 386 # Break out of the bootloader 387 setenv ipaddr <localip> 388 setenv serverip <serverip> 389 }}} 390 For Example: 391 {{{#!bash 392 setenv ipaddr 192.168.1.211 484 393 setenv serverip 192.168.1.14 485 </pre></div></li></ol><ol start="2"><li>Modify the boot variables to point to the image file on the tftp server and update: 486 <div class="code"><pre><span class="c"># Note: Adjust file path/name to match file structure on your tftpserver 487 </span>setenv image_rootfs gateworks-image-gui-ventana.ubi 488 </pre></div></li></ol><ol start="3"><li>Run the nand update script to pull the image from the tftp server and load it: 489 <div class="code"><pre>run nand_update 490 </pre></div><ul><li>Troubleshooting 491 <ul><li>Be sure that the tftp server is working properly and started on the host PC 492 </li><li>An error such as 'ERROR: Need valid 'usbnet_devaddr' to be set at drivers/usb/gadget/ether.c:2362/usb_eth_init()' is simply because the ethernet transfer failed and it is attempting to use the USB network which needs to be configured. 493 </li></ul></li></ul></li></ol><ol start="4"><li> Once it is done loading, type the command boot 494 <div class="code"><pre>boot 495 </pre></div></li></ol><ol start="5"><li>The login is <tt>root</tt> with no default password. 496 </li></ol><p> 497 <span class="wikianchor" id="yocto_installing_blockdev"></span> 498 </p> 499 <h2 id="InstallingonRemovablestorage:mSATAUSBuSD">Installing on Removable storage: mSATA/USB/uSD</h2> 500 <p> 394 }}} 395 396 2. Modify the boot variables to point to the image file on the tftp server and update: 397 {{{#!bash 398 # Note: Adjust file path/name to match file structure on your tftpserver 399 setenv image_rootfs gateworks-image-gui-ventana.ubi 400 }}} 401 402 3. Run the nand update script to pull the image from the tftp server and load it: 403 {{{#!bash 404 run nand_update 405 }}} 406 * Be sure that the tftp server is working properly and started on the host PC 407 * An error such as 'ERROR: Need valid 'usbnet_devaddr' to be set at drivers/usb/gadget/ether.c:2362/usb_eth_init()' is simply because the ethernet transfer failed and it is attempting to use the USB network which needs to be configured. 408 409 4. Once it is done loading, type the command boot 410 {{{#!bash 411 boot 412 }}} 413 414 5. The login is {{{root}}} with no default password. 415 416 == Installing on Removable storage: mSATA/USB/uSD == 501 417 For this, do not use the .ubi file. Use the tarball, for example: gateworks-image-gui-ventana.tar.bz2 502 </p> 503 <p> 418 504 419 To image the built firmware onto a removable flash device such as an mSATA disk, uSD card, or USB stick you can use the following script which creates a single ext4 partition for rootfs. 505 </p> 506 <div class="code"><pre><span class="nv">DISK</span><span class="o">=</span>/dev/sdc507 <span class="c"># create a single Linux partition508 </span><span class="nb">printf</span> <span class="s2">",,L,,\n"</span> | sudo sfdisk -uS <span class="k">${</span><span class="nv">DISK</span><span class="k">}</span> 509 <span class="c"># format it as ext4510 </span>sudo mkfs.ext4 <span class="k">${</span><span class="nv">DISK</span><span class="k">}</span>1511 <span class="c"># mount it512 </span>sudo mount <span class="k">${</span><span class="nv">DISK</span><span class="k">}</span>1 /mnt/disk513 <span class="c"># untar the filesystem image514 </span>sudo tar -C /mnt/disk -xvf tmp/deploy/images/ventana/gateworks-image-gui-ventana.tar.bz2420 {{{#!bash 421 DISK=/dev/sdc 422 # create a single Linux partition 423 printf ",,L,,\n" | sudo sfdisk -uS ${DISK} 424 # format it as ext4 425 sudo mkfs.ext4 ${DISK}1 426 # mount it 427 sudo mount ${DISK}1 /mnt/disk 428 # untar the filesystem image 429 sudo tar -C /mnt/disk -xvf tmp/deploy/images/ventana/gateworks-image-gui-ventana.tar.bz2 515 430 sudo umount /mnt/disk 516 </pre></div><ul><li>Notes: 517 <ul><li><strong>set DISK to the appropriate device on your Linux Host (it may very well differ from <tt>/dev/sdc</tt>). If you do not do this, you risk overwriting your OS partition</strong>. Once the flash device is plugged into the computer, you can find the device by typing <tt>mount</tt> and examining the output. For example if A flash stick with 1 partition shows as <tt>/dev/sdc1</tt> then the block device is <tt>/dev/sdc</tt> (the 1 is the first partition) 518 </li></ul></li></ul><p> 431 }}} 432 * Notes: 433 - **set DISK to the appropriate device on your Linux Host (it may very well differ from {{{/dev/sdc}}}). If you do not do this, you risk overwriting your OS partition**. Once the flash device is plugged into the computer, you can find the device by typing mount and examining the output. For example if A flash stick with 1 partition shows as {{{/dev/sdc1}}} then the block device is {{{/dev/sdc}}} (the 1 is the first partition) 519 434 Using the latest bootloader and bootloader env scripts simply placing this removable media in a Ventana board will boot it. 520 </p> 521 <p> 522 See <a class="wiki" href="/wiki/Yocto/Building#Pre-CompiledBinary">above</a> for pre-built rootfs tarballs of our latest releases 523 </p> 524 }}} 435 436 See [wiki:Yocto/Building#Pre-CompiledBinary above] for pre-built rootfs tarballs of our latest releases