Changes between Initial Version and Version 1 of Yocto/Building

10/22/2017 05:28:45 AM (5 years ago)



  • Yocto/Building

    v1 v1  
     2          <div id="wikipage" class="trac-content"><p>
     3</p><div class="wiki-toc">
     5  <li>
     6    <a href="#BuildingYoctoInstallingfortheGateworksVentanaFamily">Building Yocto &amp; 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>
     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>
     62<h1 id="BuildingYoctoInstallingfortheGateworksVentanaFamily">Building Yocto &amp; Installing for the Gateworks Ventana Family</h1>
     64The following versions of Yocto are supported:
     66<ul><li>Yocto v1.8 (Fido) Poky 13.0 released on 02/23/2016 (<strong>Recommended</strong>)
     67<ul><li>using the gateworks_fslc_3.14_1.0.x_ga kernel
     68</li><li><strong>Considered stable</strong>
     70</p><div> <h3 class="foldable">Old Releases</h3><div><p>
     72<ul><li>Yocto v1.7 (Dizzy) Poky 12.0 released on 02/25/2015
     73<ul><li>using the gateworks_3.10.17_1.0.0_ga kernel
     74</li></ul></li><li>Yocto v1.6 (Daisy) Poky 11.0 released on 4/25/2014
     75<ul><li>using the gateworks_3.10.17_1.0.0_ga kernel
     76</li></ul></li><li>Yocto v1.3 (Danny) Poky 8.0 released on 10/24/2012
     77<ul><li>using the gateworks_3.0.35_4.0.0 kernel
     82The Gateworks Ventana Yocto BSP provides a layer of package recipes that replace or override recipes in the upstream Yocto project such as:
     86</li><li>filesystem images
     87</li><li>support utilities
     89For details on Yocto releases please see:
     91<ul><li><a class="ext-link" href=""><span class="icon">​</span></a>
     93<span class="wikianchor" id="prebuilt"></span>
     95<h1 id="Pre-CompiledYoctoBinaries">Pre-Compiled Yocto Binaries</h1>
     97For 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 2GB NAND Flash. You can see the size output from the bootloader over the serial console.
     100<strong> <a class="wiki" href="/wiki/Yocto/Building#InstallingFirmware">Installation instructions here</a> </strong>
     103Most recent releases:
     105<ul><li>Yocto 1.8.2 (Fido) 20160328-1730:
     106<ul><li>Multimedia: (supports gstreamer video in/out encode/decode, but no GUI desktop)
     107<ul><li><a class="ext-link" href=""><span class="icon">​</span>ubi 256MB FLASH</a> (sha256sum:a012d6ffb287221e686de973870e4232fe54f08d208f9ce5a436933ecff02606)
     108</li><li><a class="ext-link" href=""><span class="icon">​</span>ubi 2GB FLASH</a> (sha256sum:be735f02f0a68b9cca797cd62e71b9de2ecea3ab6e64c23e3406b175c160f25a)
     109</li><li><a class="ext-link" href=""><span class="icon">​</span>rootfs tarball</a> (sha256sum:94734c2c442427deb1df537d1da9abebb9b6e5dab2891c3a35e8ac200540dd07)
     110</li></ul></li><li>GUI: (supports gstreamer video in/out encode/decode and SATO X11 desktop with Matchbox window manager and Midori web browser)
     111<ul><li><a class="ext-link" href=""><span class="icon">​</span>ubi 2GB FLASH</a> (sha256sum:96d229507a82022a9da7e91998b55dea706619c09548821d69712b97dc76919a)
     112</li><li><a class="ext-link" href=""><span class="icon">​</span>rootfs tarball</a> (sha256sum:12aecb6b2e38ba9f55c1986e8bb27c057521f96be1cb63227748db4cf3e8e7a3)
     113</li></ul></li></ul></li></ul><ul><li><a class="wiki" href="/wiki/ventana/bootloader">Pre-Built Bootloader Binaries</a>
     115</p><div> <h3 class="foldable">Old Releases</h3><div><p>
     117<ul><li>Yocto 1.8.1 (Fido) 20160223-1730:
     119<ul><li><a class="ext-link" href=""><span class="icon">​</span>ubi 256MB FLASH</a> (sha256sum:82aadb23405b286ffb934fa73d8205a9ac61249e38cacdae45d57fab49582afb)
     120</li><li><a class="ext-link" href=""><span class="icon">​</span>ubi 2GB FLASH</a> (sha256sum:f2847825989455b8d8eee0ecf1a58b4eae026b0f8498c829620fe96c41624493)
     121</li><li><a class="ext-link" href=""><span class="icon">​</span>rootfs tarball</a> (sha256sum:d17b603d3f81aad31aa4e642a03cf057c1ba21726d51f929fe027283d70624cf)
     123<ul><li><a class="ext-link" href=""><span class="icon">​</span>ubi 2GB FLASH</a> (sha256sum:e1df74be24d85b3c671f97c0c3f57189c5b40b62725c8acb9a7bffb6cb948e7e)
     124</li><li><a class="ext-link" href=""><span class="icon">​</span>rootfs tarball</a> (sha256sum:640e9b46715d098c272112cd477fb0b62fa7c11e26b59e2a8a10658231c52efb)
     125</li></ul></li></ul></li><li>Yocto 1.7.1 (Dizzy) 20150904-1730:
     127<ul><li><a class="ext-link" href=""><span class="icon">​</span>ubi 256MB FLASH</a> (sha256sum:85bff50eca91596a19180a8e3c18132871c66efd44e4e7ba411ce15592191413)
     128</li><li><a class="ext-link" href=""><span class="icon">​</span>ubi 2GB FLASH</a> (sha256sum:34ec5c06c770b5eb286169afaa76285141965f6ddc56b4aa396742e427defd8e)
     129</li><li><a class="ext-link" href=""><span class="icon">​</span>rootfs tarball</a> (sha256sum:82e6643ee93927e19183325d4c584eb777803e39f108f6aa6932b654b5d6902f)
     131<ul><li><a class="ext-link" href=""><span class="icon">​</span>ubi 2GB FLASH</a> (sha256sum:4c53aae441c8ffda882e1c662e7a6d1e3f31484fae5b09089f454c5459ce16aa)
     132</li><li><a class="ext-link" href=""><span class="icon">​</span>rootfs tarball</a> (sha256sum:52967b45a3d3eb1b5ca2051200eae0f787e254c5f4d92ad2e07f2101907aa470)
     133</li></ul></li></ul></li><li>Yocto 1.6.2 (Daisy) 20150221_0538:
     135<ul><li><a class="ext-link" href=""><span class="icon">​</span>ubi 256MB FLASH</a> (sha256sum:c05a6cca542bd2004cf51bc161d5c73b1e63322a9a543c6f566a8e876ec9274a)
     136</li><li><a class="ext-link" href=""><span class="icon">​</span>ubi 2GB FLASH</a> (sha256sum:10b27d97025df0c389972995497381a5e8e15beb79915f35c760aa0439370b7a)
     137</li><li><a class="ext-link" href=""><span class="icon">​</span>rootfs tarball</a> (sha256sum:b383e6bcc4543719423c318cae588897fde36d5f68f4b1f989054bd287f7557b)
     139<ul><li><a class="ext-link" href=""><span class="icon">​</span>ubi 2GB FLASH</a> (sha256sum:908162a6740d0086d268a905d26bb28f79f3eb21c0b0da205dda98d44267b54f)
     140</li></ul></li></ul></li><li>Yocto 1.3.2 (Danny) 20140502:
     142<ul><li><a class="ext-link" href=""><span class="icon">​</span>ubi 256MB FLASH</a> (sha256sum:ff2118d68433ffa8995741c902ed035b02c85aaea0125d0e9d6e3e09f245e5c6)
     143</li><li><a class="ext-link" href=""><span class="icon">​</span>rootfs tarball</a> (sha256sum:4bec68e7040e151845358b1539830c164f29ffab6883233267ff1aa12813af34)
     148Version History:
     150<ul><li>Yocto v1.8:
     151<ul><li>Yocto 1.8.2 (Fido) 20160328-1730:
     152<ul><li>kernel: <a class="ext-link" href=""><span class="icon">​</span>3.14.48-1.0.x_ga+yocto+g3ae25e0</a>
     153</li><li>wireless drivers from linux-backports: 20160122
     154</li><li>fixed: cryptodev support
     155</li><li>removed: unused crda package
     157</p><div> <h3 class="foldable">Older History</h3><div><p>
     159<ul><li>Yocto v1.8:
     160<ul><li>Yocto 1.8.1 (Fido) 20160223-1730:
     161<ul><li>kernel:  3.14.48-1.0.x_ga+yocto+g7a5ffca6
     162</li><li>wireless drivers from linux-backports: 20150129
     163</li><li>fixed: gsc_update no longer erases user EEPROM data
     164</li><li>fixed: VPU firmware update to resolve various encoding timeouts
     165</li><li>fixed: FEC ethernet tx queue stalls
     166</li><li>fixed: NAND stability issue
     167</li><li>fixed: PWM pinmux
     168</li><li>fixed: mxc_v4l2_capture initialization
     169</li><li>fixed: reboot fix for GW5100 A/B revisions
     170</li><li>updated: bootscript updated to v1.06 to remove LVDS display detection
     171</li><li>added: added user controllable quality steps to gst-variable-rtsp-server
     172</li><li>added: gpsd
     173</li><li>added: crda
     174</li><li>added: ethtool
     175</li><li>added: hostapd-conf
     176</li><li>added: SPI for GW522x
     177</li><li>added: USB serial drivers
     178</li><li>added: 7" LVDS display touchscreen controller (gt9x)
     179</li><li>added: use GSC for power-down and restart
     180</li></ul></li><li>Yocto 1.8 (Fido) 20150904-2139:
     181<ul><li>Initial Gateworks Yocto v1.8 release
     182</li><li>kernel:  3.14.48-1.0.x_ga+yocto+g4ba0a59
     183</li><li>wireless drivers from linux-backports: 20150129
     184<ul><li>much improved ath10k performance/support including adhoc
     185</li></ul></li><li>added gstreamer 1.0 / gstreamer-imx
     186</li><li>added avc8000 8x D1 miniPCIe capture card support
     187</li><li>added gsc-update
     188</li><li>added uboot-envtools
     189</li><li>added gwsoc (GW16113) support)
     190</li></ul></li></ul></li><li>Yocto v1.7:
     191<ul><li>Yocto 1.7.1 (Dizzy) 20150904-1730:
     192<ul><li>kernel:  3.10.17-1.0.0_ga+yocto+g4078cea
     193</li><li>wireless drivers from linux-backports: 20141221
     194</li><li>default to ldo-enabled mode
     195</li><li>i2c: add retries on i2c nak's
     196</li><li>gsc: fix gsc hwmon negative temperature readings
     197</li><li>video: mxc: add support for HDMI interlace out
     198</li><li>add UHS-I support
     199</li><li>enable SATA_AHCI support
     200</li><li>enable PCA953x IRQ
     201</li><li>update IMX6SDL voltage set-points
     202</li><li>disable PCIe Gen2
     203</li><li>imx-thermal: set thresholds based on CPU temperature grade
     204</li><li>tda1997x: default to yuv422smp capture mode for 1080p60Hz
     205</li><li>tda1997x: fixed ITU709 colorimetry colorspace conversion
     206</li><li>sgtl5000: fix audio pop
     207</li></ul></li><li>Yocto 1.7.1 (Dizzy) 20150221-0225:
     208<ul><li>Initial Gateworks Yocto v1.7 release
     209</li><li>kernel:  3.10.17-1.0.0_ga+yocto+g4d177f6
     210</li></ul></li></ul></li><li>Yocto v1.6:
     211<ul><li>Yocto 1.6.2 - 20150221_0538:
     212<ul><li>added support for GW551x, GW552x
     213</li><li>added cryptodev module
     214</li><li>wireless drivers:
     215<ul><li>updated drivers to compat-wireless_20141221
     216</li><li>use internal regdb
     217</li></ul></li><li>kernel:  3.10.17-1.0.0_ga+yocto+g4d177f6
     218<ul><li>added support for DLC800FIGT3 8in XGA (1024x768) capacitive multi-touch touchscreen
     219</li><li>added support for DLC700JMGT4 7in WSVGA (1024x600) capacitive multi-touch touchscreens
     220</li><li>bumped IMX6Q/IMX6DL operating point voltages for VDD_ARM/VDD_SOC
     221</li><li>added GSC drivers (Watchdog / Input)
     222</li><li>fix gpio input state detect for PCA953x port expanders
     223</li><li>added support for GW551x, GW552x
     224</li><li>HDMI input:
     225<ul><li>fixed EDID handling
     226</li><li>add supoprt for HDMI input in 16bit YUV422 mode (requires alternate device-tree configuration)
     227</li><li>fix audio output format details and constrain samplerate
     228</li></ul></li><li>disable IMX6 busfreq driver
     229</li><li>add i210 support
     230</li><li>add GW16103 support
     231</li><li>GW51xx: fix invalid PPS gpio
     232</li><li>disable evbug driver
     233</li><li>add LTC3676 PMIC support and ldo-bypass mode for GW53xx/GW52xx/GW51xx/GW551x/GW552x) (lowers overall power-reduction and thermal envelope)
     234</li></ul></li></ul></li><li>Yocto 1.6.1 - 20141024:
     235<ul><li>kernel: 3.10.17-1.0.0_ga+yocto+gb5914e9
     236</li><li>occasional PCIe link issue resolved
     237</li><li>video sink issue resolved for same resolution input/output
     238</li><li>dual-display HDMI+CVBS fixed
     239</li><li>GW16082 support fixed
     240</li><li>PCIe IRQ slot mapping issue fixed
     241</li><li>GW5400 stability issue fixed
     242</li></ul></li></ul></li><li>Yocto v1.3:
     243<ul><li>Yocto v1.3.2 - 20140502:
     244<ul><li>kernel: gateworks_3.0.35-4.4.0-gaabbed9
     249For instructions on flashing UBI files, please see <a class="wiki" href="/wiki/Yocto/Building#NANDFlash">this section</a>.
     252<span class="wikianchor" id="build"></span>
     254<h1 id="ObtainingandCompilingtheSourceCode">Obtaining and Compiling the Source Code</h1>
     256The following build instructions refer to Debian GNU/Linux 7.4 and Ubuntu 12.04 - 15.10.
     259Please make sure the following packages are installed
     261<div class="code"><pre>sudo apt-get install chrpath libsdl-dev texinfo curl build-essential git subversion diffstat gawk
     262</pre></div><ol><li>fetch the <tt>repo</tt> tool (if you don't have it already in your path):
     263<div class="code"><pre>mkdir ~/bin
     264curl &gt; ~/bin/repo
     265chmod a+x ~/bin/repo
     266</pre></div></li></ol><ol start="2"><li>Setup source repos:
     267<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
     268mkdir ~/ventana-yocto
     269<span class="nb">cd </span>ventana-yocto
     270repo init -u -b fido
     271</pre></div><ul><li>in the above command <tt>fido</tt> is the name of the branch that refers to Yocto v1.8
     272</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:
     273<div class="code"><pre>wget <span class="c"># fetch the pinned manifest from the last successful nightly build
     274</span>mv snapshot.xml .repo/manifest.xml <span class="c"># copy over the generic un-pinned manifest
     275</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=""><span class="icon">​</span></a>
     276</li></ul></li></ol><ol start="4"><li>Download latest sources:
     277<div class="code"><pre>repo sync -c -j8
     278</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)
     279</li><li>the <tt>-j</tt> parameter tells repo to use multiple processes (8 in this example) which will speed up fetching
     280</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
     281</li></ul></li></ol><ol start="5"><li>Activate <tt>bitbake</tt> environment. You will have to accept license agreement.
     282<div class="code"><pre>. ./setup-environment build
     283</pre></div><ul><li><strong>do this every time for a new shell when you wish to use <tt>bitbake</tt></strong>
     284</li></ul></li></ol><ol start="6"><li>Build a filesystem image recipe. <tt>gateworks-image-multimedia</tt> is recommended.
     285<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>.
     286<div class="code"><pre>bitbake gateworks-image-multimedia
     287</pre></div></li><li>This could take several hours depending on your Internet speed and development host
     288</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.
     289</li><li>By default, images, kernels, etc are found in <tt>tmp/deploy/images/ventana</tt>
     290</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:
     291<div class="code"><pre>tmp/deploy/images/ventana/gateworks-image-multimedia-ventana_normal.ubi
     296<ul><li>to download any updates and rebuild, repeat the above starting with step 3
     297</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)
     298</li><li>to clean a specific recipe use <tt>bitbake -f -c clean &lt;recipe&gt;</tt>. Note that to represent the kernel you can use the virtual recipe name 'virtual/kernel'
     299<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 &lt;recipe&gt;</tt>
     300</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>
     301</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)
     303Useful References:
     305<ul><li><a class="ext-link" href=""><span class="icon">​</span></a>
     306</li><li><a class="ext-link" href=""><span class="icon">​</span></a>
     307</li></ul><h2 id="Troubleshootingbuildfailures">Troubleshooting build failures</h2>
     309The <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.
     312In 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:
     314<div class="code"><pre>ERROR: Function failed: Fetcher failure <span class="k">for </span>URL: <span class="s1">';name=archive'</span>. Unable to fetch URL from any source.
     315ERROR: 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
     316ERROR: Task 452 <span class="o">(</span>/usr/src/tharvey/nightly/yocto/danny/20140820_8bd8be2d/sources/meta-openembedded/meta-oe/recipes-support/evtest/, do_fetch<span class="o">)</span> failed with <span class="nb">exit </span>code <span class="s1">'1'</span>
     318The 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.
     320<h3 id="Fetchfailure">Fetch failure</h3>
     322The 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.
     325If this occurs you will see an 'ERROR: Function failed: Fetcher failure' message such as the following output from <tt>bitbake</tt>:
     327<div class="code"><pre>ERROR: Function failed: Fetcher failure <span class="k">for </span>URL: <span class="s1">';name=archive'</span>. Unable to fetch URL from any source.
     329If 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).
     332To 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=""><span class="icon">​</span></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:
     334<div class="code"><pre>wget
     335cp evtest-1.25.tar.bz2 downloads/
     336touch downloads/evtest-1.25.tar.bz2.done
     337bitbake gateworks-image-multimedia
     338</pre></div><h3 id="UpstreamBreakage">Upstream Breakage</h3>
     340It 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.
     343If 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>
     346<span class="wikianchor" id="repo"></span>
     348<h2 id="Keepinguptodateandorpinningsourcewithrepo">Keeping up to date and/or pinning source with repo</h2>
     350When 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.
     353The <tt>repo sync</tt> command will update all repositories with upstream changes:
     355<div class="code"><pre>repo sync --quiet
     357You 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:
     359<ul><li>adding new projects
     360</li><li>pinning certain projects
     361</li><li>removing certain projects
     363To 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:
     365<div class="code"><pre><span class="cp">&lt;?xml version="1.0" encoding="UTF-8"?&gt;</span>
     366<span class="nt">&lt;manifest&gt;</span>
     367   <span class="nt">&lt;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">/&gt;</span>
     368   <span class="nt">&lt;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">/&gt;</span>
     369<span class="nt">&lt;/manifest&gt;</span>
     371The <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:
     373<div class="code"><pre>repo manifest -o snapshot.xml -r
     375This snapshot can then be copied over <tt>.repo/manifest.xml</tt> in a different build directory to pin the repository sources.
     378The 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.
     383<ul><li><a class="ext-link" href=""><span class="icon">​</span>Official docs on using repo</a>
     384</li><li><a class="ext-link" href=""><span class="icon">​</span>xda-university repo tips and tricks</a>
     385</li><li><a class="ext-link" href=""><span class="icon">​</span>Cyanogenmod docs on using manifests</a>
     386</li><li><a class="ext-link" href=""><span class="icon">​</span>repo Manifest Format: the official, technical documentation for repo manifests</a>
     388<span class="wikianchor" id="rebuild"></span>
     390<h2 id="Updatingandrebuilding">Updating and rebuilding</h2>
     392From 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.
     395The <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:
     397<div class="code"><pre>./repo sync
     399Following a sync, you can <tt>bitbake</tt> your filesystem image again to build a new filesystem with all updates:
     401<div class="code"><pre><span class="c"># activate a bitbake shell if not already done
     402</span>. ./setup-environment build
     403bitbake gateworks-image-multimedia
     404</pre></div><ul><li>build the filesystem image of your liking
     405</li></ul><h2 id="Diskusageandkeepingthingsclean">Disk usage and keeping things clean</h2>
     407Yocto builds can chew up a lot of disk space (true really of any OS build system).
     410<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 &lt;;</tt> to clean specific recipes (note that <tt>bitbake -cclean &lt;package&gt;</tt> will only clean the current preferred version, not old packages).
     413Another 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:
     415<div class="code"><pre>rm -rf build/tmp/deploy/images/gateworks-image-multimedia* ;<span class="c"># remove old images we don't care about
     416</span>bitbake gateworks-image-multimedia ;<span class="c"># build a new one
     418For Yocto, all temporary files will be in build/tmp so if you want to clear out everything and start over you can:
     420<div class="code"><pre>rm -rf build/tmp
     421</pre></div><h2 id="BuildingUpdatingAddingPackages">Building / Updating / Adding Packages</h2>
     423Please read more <a class="wiki" href="/wiki/Yocto/packages">Yocto/packages</a>
     426<span class="wikianchor" id="yocto_building_sdk"></span>
     428<h2 id="BuildingatoolchainandorSDK">Building a toolchain and/or SDK</h2>
     430See <a class="wiki" href="/wiki/Yocto/SDK">Yocto/SDK</a> for information about a pre-built downloadable SDK
     433You can use <tt>bitbake</tt> to create a toolchain (cross-compiler) or an Software Development Kit (SDK) comprised of a cross-toolchain and libs.
     438<div class="code"><pre>bitbake meta-toolchain
     440SDK (contains meta-toolchain as well as -dev and -dbg packages with headers and libs):
     442<div class="code"><pre>bitbake -cpopulate_sdk gateworks-image-multimedia
     443</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.
     444</li></ul><h2 id="Otherusefullinks">Other useful links</h2>
     445<ul><li>For those that may want to compile the Freescale Image:
     446<ul><li><a class="ext-link" href=""><span class="icon">​</span></a>
     448<span class="wikianchor" id="yocto_installing"></span>
     450<h1 id="InstallingFirmware">Installing Firmware</h1>
     452<span class="wikianchor" id="yocto_installing_flash"></span>
     454<h2 id="NANDFLASH">NAND FLASH</h2>
     456There are 2 options:
     458<ol><li>TFTP Server (recommended) - Read below
     459</li><li>JTAG Programmer (more steps and slower, requires no network)- Link <a class="wiki" href="/wiki/jtag_instructions#CreatingjtagableimagesforVentana">here</a>
     461Boards 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 2GB 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>.
     464To install firmware to a Ventana board using Serial/ENET, do the following:
     467First, get yourself into a sane state:
     469<ul><li>Copy your UBI file to a proper location that your <a class="wiki" href="/wiki/tftpserver">tftpserver</a> has access to
     470</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)
     471</li></ul><ol><li>Connect your target board to your network, set ipaddress and serverip in uboot
     472<div class="code"><pre><span class="c"># Break out of the bootloader
     473</span>setenv ipaddr &lt;localip&gt;
     474setenv serverip &lt;serverip&gt;
     475</pre></div>For Example:
     476<div class="code"><pre>setenv ipaddr
     477setenv serverip
     478</pre></div></li></ol><ol start="2"><li>Modify the boot variables to point to the image file on the tftp server and update:
     479<div class="code"><pre><span class="c"># Note: Adjust file path/name to match file structure on your tftpserver
     480</span>setenv image_rootfs gateworks-image-gui-ventana.ubi
     481</pre></div></li></ol><ol start="3"><li>Run the nand update script to pull the image from the tftp server and load it:
     482<div class="code"><pre>run nand_update
     484<ul><li>Be sure that the tftp server is working properly and started on the host PC
     485</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.
     486</li></ul></li></ul></li></ol><ol start="4"><li> Once it is done loading, type the command boot
     487<div class="code"><pre>boot
     488</pre></div></li></ol><ol start="5"><li>The login is <tt>root</tt> with no default password.
     490<span class="wikianchor" id="yocto_installing_blockdev"></span>
     492<h2 id="InstallingonRemovablestorage:mSATAUSBuSD">Installing on Removable storage: mSATA/USB/uSD</h2>
     494For this, do not use the .ubi file. Use the tarball, for example: gateworks-image-gui-ventana.tar.bz2
     497To 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.
     499<div class="code"><pre><span class="nv">DISK</span><span class="o">=</span>/dev/sdc
     500<span class="c"># create a single Linux partition
     501</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>
     502<span class="c"># format it as ext4
     503</span>sudo mkfs.ext4 <span class="k">${</span><span class="nv">DISK</span><span class="k">}</span>1
     504<span class="c"># mount it
     505</span>sudo mount <span class="k">${</span><span class="nv">DISK</span><span class="k">}</span>1 /mnt/disk
     506<span class="c"># untar the filesystem image
     507</span>sudo tar -C /mnt/disk -xvf tmp/deploy/images/ventana/gateworks-image-gui-ventana.tar.bz2
     508sudo umount /mnt/disk
     510<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)
     512Using the latest bootloader and bootloader env scripts simply placing this removable media in a Ventana board will boot it.
     515See <a class="wiki" href="/wiki/Yocto/Building#Pre-CompiledBinary">above</a> for pre-built rootfs tarballs of our latest releases