This repository provides tools to build Snappy Core images for Gumstix systems as well as Beagleboard and PandaBoard.
Snappy Core is under ongoing development and, as such, these images are meant only to provide a basis for experimentation and a starting point for Snappy + Gumstix. See Kudos and Caveats.
Prebuilt images are available for Overo, DuoVero, Pepper, Beagle, and Panda. These images can be directly copied to a 4GB or greater microSD card. Warning: this erases anything currently on the microSD card! Note that any mounted partititions of the SD card should be unmounted before writing the image. These steps each take several minutes; your computer isn't hanging, the files are just large.
# substitute one of 'overo', 'duovero', 'pepper', 'beagle' or 'panda' in
# place of <machine>
$ wget http://gumstix-snappy.s3.amazonaws.com/<machine>.img.xz
$ xz -d <machine>.img.xz
# substitute the path to the drive e.g. /dev/sdd or /dev/mmcblk0 (not the
# path of a partition e.g. /dev/sdd1 or /dev/mmcblk0p1) in place of <drive>
# use 'udevadm monitor' when you insert the card to determine the path
$ sudo dd if=<machine>.img bs=4k of=<drive>
$ sync
After the process completes, plug the microSD card into your Gumstix (or TI) system, boot, login as ubuntu with password ubuntu and start playing with your shiny new Ubuntu Snappy Core!
By way of example, try installing the xkcd-webserver package so you can enjoy random XKCD comics delivered to your browser by your Snappy system:
# on your snappy system
$ sudo snappy install xkcd-webserver
On your development machine (on the same network as your snappy device), navigate to http://machine-name.local
An autobuilder generates weekly images for Overo, DuoVero, Pepper, Beagle, and Panda from the latest code. This is a good place to look to try out the latest features or access a particular older version.
1. Grab some required software.
$ sudo apt-get install -y git build-essential make gcc-arm-linux-gnueabihf \
ubuntu-device-flash snappy-tools
2. (optional) Download an OEM Snappy package.
This package includes any components such as a bootloader that are specific to a particular device (i.e. Overo, DuoVero, [Pepper] pepper-snap, Beagle, and Panda).
$ wget http://gumstix-snappy.s3.amazonaws.com/<machine>.snap
As well as device-specific components, a system vendor could distribute a logo or pre-install other useful packages into any generated images. To make your own OEM package, see below.
Note:
As these OEM snaps are now available through the Snappy App Store, this step is optional. Just replace machine-name.snap with machine-name.gumstix in the --oem argument below and the OEM snap will be automatically fetched from the store.
3. Assembly a flashable image.
To support Snappy's rollback system, it has two OS partitions, system-a and system-b, both sized to be ~1GB as well as boot (system-boot) and user (writable) partitions; keep it roomy by creating a 4GB image. We'll use the 15.04 release and enable ssh as well developer-mode so we can install unsigned packages.
$ sudo ubuntu-device-flash core 15.04 -o <machine>.img --size 4 \
--oem <machine>.snap --developer-mode
Format a microSD as described above with the newly created img file. Once the card is created, take a look at the partition structure---there should be four as described above.
Technical Aside
There is unpartitioned space at the beginning of the card in which, on some installations, booloader components such as MLO and u-boot.img are written, rather than storing them on the system-boot partition. OMAP4 (DuoVero/Panda) and AM335x (Pepper) use this but, as OMAP3 (Overo/Beagle) u-boot would require a raw boot mode patch, we just place MLO and u-boot.img on the system-boot partition instead.
Note:
These steps were developed & tested on an Ubuntu 15.04 system. If you get errors about unknown arguments to ubuntu-device-flash, you probably have an older version. Grab the latest from the PPA:
$ sudo add-apt-repository ppa:snappy-dev/beta
$ sudo apt-get update
$ sudo apt-get install ubuntu-device-flash snappy-tools
The included Makefile should automate much of this process. Use the -j flag to specify the number of concurrent make processes.
$ make MACHINE=<machine> -j4
After some git-fetching and compiling, fresh binaries built from the newly checked out u-boot repository should be packaged up in a Snappy OEM package, machine-name.snap. The package build system for Snappy is pretty simple. Have a look at the package.yaml file in the machine's meta directory and then try building.
$ cd <machine>
$ snappy build
$ cp <machine>.snap ../
$ cd ..
If you make changes to any source files, just call make again to rebuild. We can also clean the build---we keep checked-out source around though.
$ make MACHINE=<machine> clean
Individual components can be also be (re-)built and cleaned e.g.
$ make MACHINE=overo uboot
$ make MACHINE=overo clean-uboot
$ make MACHINE=pepper oem
$ make MACHINE=pepper clean-oem
We grab the 2015.04 version of the u-boot bootloader from the Gumstix repository and store it in the u-boot directory.
$ git clone git://github.com/gumstix/u-boot.git -b v2015.04 u-boot
We then configure it using the machine-specific defconfig:
| Machine | Machine defconfig |
|---|---|
| overo | omap3_overo_defconfig |
| duovero | duovero_defconfig |
| pepper | pepper_defconfig |
| beagle | omap3_beagle_defconfig |
| panda | omap4_panda_defconfig |
$ cd u-boot
$ make CROSS_COMPILE=arm-linux-gnueabihf- <machine_defconfig>
Build and install the resulting MLO and u-boot.img files.
$ make CROSS_COMPILE=arm-linux-gnueabihf-
$ cp MLO u-boot.img ../<machine>/
In making this repository, there were many useful references. And of course, thanks to the good folks on the snappy-devel list :).
A few known issues:
- There is a long (~15 second) pause after 'Starting Kernel...' as the ramdisk gets loaded. It is not frozen---just be patient.
- Building the Snappy OEM package yields errors such as "(MANUAL REVIEW) type 'oem' not allowed". This is expected for OEM packages. The package will still be generated.
Currently, this is a yay-it-boots kinda thing; there is no customization of the filesystem, validation that all the hardware works, or any kernel config adjustments. If you find things that are broken or have suggestions, leave a comment, raise an issue, or best of all, send a pull request!