NOTE In conjunction with the Yocto BSP, please be sure to use the latest bootloader for proper operation. Bootloader Instructions Here
The following versions of Yocto are supported:
The Gateworks Ventana Yocto BSP provides a layer of package recipes that replace or override recipes in the upstream Yocto project such as:
For details on Yocto releases please see:
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 2GB NAND Flash. You can see the size output from the bootloader over the serial console.
Installation instructions here
Most recent releases:
Version History:
For instructions on flashing UBI files, please see this section.
The following build instructions refer to Debian GNU/Linux 7.4 and Ubuntu 12.04 - 15.10.
Please make sure the following packages are installed
sudo apt-get install chrpath libsdl-dev texinfo curl build-essential git subversion diffstat gawk
mkdir ~/bin curl http://commondatastorage.googleapis.com/git-repo-downloads/repo > ~/bin/repo chmod a+x ~/bin/repo
PATH=${PATH}:~/bin mkdir ~/ventana-yocto cd ventana-yocto repo init -u https://github.com/Gateworks/gateworks-yocto-bsp-platform -b fido
wget http://dev.gateworks.com/yocto/1.8/snapshot.xml # fetch the pinned manifest from the last successful nightly build mv snapshot.xml .repo/manifest.xml # copy over the generic un-pinned manifest
repo sync -c -j8
. ./setup-environment build
bitbake gateworks-image-multimedia
tmp/deploy/images/ventana/gateworks-image-multimedia-ventana_normal.ubi tmp/deploy/images/ventana/gateworks-image-multimedia-ventana_large.ubi
Notes:
Useful References:
The OpenEmbedded? build system does a fairly good job of reporting build errors in a sane way to help you diagnose the problem.
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:
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. 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 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'
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.
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.
If this occurs you will see an 'ERROR: Function failed: Fetcher failure' message such as the following output from bitbake:
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.
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).
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:
wget http://dev.gateworks.com/sources/evtest-1.25.tar.bz2 cp evtest-1.25.tar.bz2 downloads/ touch downloads/evtest-1.25.tar.bz2.done bitbake gateworks-image-multimedia
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.
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 instructions above
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.
The repo sync command will update all repositories with upstream changes:
repo sync --quiet
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:
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:
<?xml version="1.0" encoding="UTF-8"?> <manifest> <remove-project path="hardware/qcom/display" name="CyanogenMod/android_hardware_qcom_display" /> <project path="hardware/qcom/display" name="WinSuk/android_hardware_qcom_display" /> </manifest>
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:
repo manifest -o snapshot.xml -r
This snapshot can then be copied over .repo/manifest.xml in a different build directory to pin the repository sources.
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.
References:
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.
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:
./repo sync
Following a sync, you can bitbake your filesystem image again to build a new filesystem with all updates:
# activate a bitbake shell if not already done
. ./setup-environment build
bitbake gateworks-image-multimedia
Yocto builds can chew up a lot of disk space (true really of any OS build system).
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).
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:
rm -rf build/tmp/deploy/images/gateworks-image-multimedia* ;# remove old images we don't care about bitbake gateworks-image-multimedia ;# build a new one
For Yocto, all temporary files will be in build/tmp so if you want to clear out everything and start over you can:
rm -rf build/tmp
Please read more Yocto/packages
See Yocto/SDK for information about a pre-built downloadable SDK
You can use bitbake to create a toolchain (cross-compiler) or an Software Development Kit (SDK) comprised of a cross-toolchain and libs.
Toolchain:
bitbake meta-toolchain
SDK (contains meta-toolchain as well as -dev and -dbg packages with headers and libs):
bitbake -cpopulate_sdk gateworks-image-multimedia
There are 2 options:
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 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 sources/meta-gateworks/conf/machine/ventana.conf from 'normal' to 'large' which will result in a ubi image ending with _large.ubi.
To install firmware to a Ventana board using Serial/ENET, do the following:
First, get yourself into a sane state:
# Break out of the bootloader
setenv ipaddr <localip>
setenv serverip <serverip>
setenv ipaddr 192.168.1.211 setenv serverip 192.168.1.14
# Note: Adjust file path/name to match file structure on your tftpserver
setenv image_rootfs gateworks-image-gui-ventana.ubi
run nand_update
boot
For this, do not use the .ubi file. Use the tarball, for example: gateworks-image-gui-ventana.tar.bz2
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.
DISK=/dev/sdc # create a single Linux partition printf ",,L,,\n" | sudo sfdisk -uS ${DISK} # format it as ext4 sudo mkfs.ext4 ${DISK}1 # mount it sudo mount ${DISK}1 /mnt/disk # untar the filesystem image sudo tar -C /mnt/disk -xvf tmp/deploy/images/ventana/gateworks-image-gui-ventana.tar.bz2 sudo umount /mnt/disk
Using the latest bootloader and bootloader env scripts simply placing this removable media in a Ventana board will boot it.
See above for pre-built rootfs tarballs of our latest releases
}}}