summaryrefslogtreecommitdiffstats
path: root/README.adoc
diff options
context:
space:
mode:
authorJon Oster <jon@advancedtelematic.com>2017-01-05 17:13:46 +0100
committerJon Oster <jon@advancedtelematic.com>2017-01-05 17:13:46 +0100
commit7d99ac23abc539866ab6ccb4791690fc1a290b1e (patch)
treedf5df0db725c1d74dc0d60dc9502cd944766d9a6 /README.adoc
parent201e9f3bb143bad842235d4f3fe6686515115a58 (diff)
downloadmeta-updater-7d99ac23abc539866ab6ccb4791690fc1a290b1e.tar.gz
switch to asciidoc in readme
Diffstat (limited to 'README.adoc')
-rw-r--r--README.adoc120
1 files changed, 120 insertions, 0 deletions
diff --git a/README.adoc b/README.adoc
new file mode 100644
index 0000000..d7a8fbb
--- /dev/null
+++ b/README.adoc
@@ -0,0 +1,120 @@
1= meta-updater
2
3This layer enables over-the-air updates with OSTree and RVI SOTA client.
4
5https://github.com/ostreedev/ostree[OSTree] is a tool for atomic full file system upgrades with rollback capability. Main advantage of OSTree compared to traditional dual partition model is that OSTree minimizes network bandwidth and data storage footprint by sharing files with the same contents across file system deployments.
6
7https://github.com/advancedtelematic/rvi_sota_client[RVI SOTA client] adds authentication and provisioning capabilities to OTA and is integrated with OSTree.
8
9== Build
10
11=== Quickstart
12
13https://github.com/advancedtelematic/garage-quickstart-rpi[ATS Garage Quickstart] is an example yocto-based project combining stadard poky distribution with OSTree capabilities. For detailed getting started tutorial see https://github.com/advancedtelematic/garage-quickstart-rpi/blob/master/README.adoc[README].
14
15=== Adding meta-updater capabilities to your build
16
17If you already have a Yocto-base project and you want to add atomic filesystem updates to it you need to do just three things:
18
191. Clone meta-updater layer and add it to your https://www.yoctoproject.org/docs/2.1/ref-manual/ref-manual.html#structure-build-conf-bblayers.conf[conf/bblayers.conf].
202. Clone BSP integration layer (meta-updater-$\{PLATFORM}, e.g. meta-updater-raspberrypi) and add it to your conf/bblayers.conf. If your board isn't yet supported, you could write BSP integration work yourself. See <<Supported boards>> section for the details.
213. Set up your https://www.yoctoproject.org/docs/2.1/ref-manual/ref-manual.html#var-DISTRO[distro]. If you are using "poky", the default distro in Yocto, you can change it in your conf/local.conf to "poky-sota". Alternatively if you are using your own or third party distro configuration, you can add 'require conf/distro/sota.conf.inc' to it, thus combining capabilities of your distro with meta-updater features.
22
23You can then build your image as usual (bitbake ). After building the root file system bitbake will then create an https://ostree.readthedocs.io/en/latest/manual/adapting-existing/[OSTree-enabled version] of it, commit it to your local OSTree repo and optionally push it to a remote server. Additionally a live disk image will be created (normally named $\{IMAGE_NAME}.-sdimg-ota e.g. core-image-raspberrypi3.rpi-sdimg-ota). You can control this behaviour though <<SOTA-related variables in local.conf,OSTree-related variables in your local.conf>>.
24
25=== Build with OpenIVI
26
27=== Build in AGL
28
29With AGL you can just add agl-sota feature while configuring your build environment as in
30
31....
32source meta-agl/scripts/aglsetup.sh -m porter agl-demo agl-appfw-smack agl-devel agl-sota
33....
34
35you can then just run
36
37....
38bitbake agl-demo-platform
39....
40
41and get as a result "ostree_repo" folder in your images directory (tmp/deploy/images/$\{MACHINE}/ostree_repo) containing your OSTree repository with rootfs committed as an OSTree deployment, 'otaimg' bootstrap image which is an OSTree physical sysroot as a burnable filesystem image and optionally some machine-dependent live images (e.g. '_.rpi-sdimg-ota' for Raspberry Pi or '_.porter-sdimg-ota' Renesas Porter board).
42
43Although aglsetup.sh hooks provide reasonable defaults for SOTA-related variables you may want to tune some of them.
44
45== Supported boards
46
47Currently supported platforms are
48
49* https://github.com/advancedtelematic/meta-updater-raspberrypi[Raspberry Pi3]
50* https://github.com/advancedtelematic/meta-updater-minnowboard[Minnowboard]
51* https://github.com/advancedtelematic/meta-updater-qemux86-64[Native QEMU emulation]
52
53=== Adding support for your board
54
55If your board isn't yet supported you can add board integration code yourself. The main purpose of this code is to provide a bootloader that will get use of https://ostree.readthedocs.io/en/latest/manual/atomic-upgrades/[OSTree's boot directory] In meta-updater integration layers finished so far it is done by
56
571. Making the board boot into http://www.denx.de/wiki/U-Boot[U-Boot]
582. Making U-boot import variables from /boot/loader/uEnv.txt and load the kernel with initramfs and kernel command line arguments according to what is set this file.
59
60You may take a look into https://github.com/advancedtelematic/meta-updater-minnowboard[Minnowboard] or https://github.com/advancedtelematic/meta-updater-raspberrypi[Raspberry Pi] integration layers for examples.
61
62It is still possible to make other loaders work with OSTree as well.
63
64== SOTA-related variables in local.conf
65
66* OSTREE_REPO - path to your OSTree repository. Defaults to "$\{DEPLOY_DIR_IMAGE}/ostree_repo"
67* OSTREE_BRANCHNAME - the branch your rootfs will be committed to. Defaults to "ota"
68* OSTREE_OSNAME - OS deployment name on your target device. For more information about deployments and osnames see https://ostree.readthedocs.io/en/latest/manual/deployment/[OSTree documentation] Defaults to "poky".
69* OSTREE_INITRAMFS_IMAGE - initramfs/initrd image that is used as a proxy while booting into OSTree deployment. Do not change this setting unless you are sure that your initramfs can serve as such proxy.
70* OSTREE_PUSH_CREDENTIALS - when set adds pushing your ostree commit to a remote repo. sota-tools will then use credentials in the file pointed to by this variable.
71
72== Usage
73
74=== OSTree
75
76OSTree includes its own simple http server. It just exposes the whole OSTree repository to the network so that any remote device can pull data from it to device's local repository. To use OSTree http server you need OSTree installed on your build machine. Alternatively, you could run version built inside Yocto using bitbake's http://www.openembedded.org/wiki/Devshell[devshell].
77
78To expose your repo run ostree trivial-httpd using any free port.
79
80....
81ostree trivial-httpd tmp/deploy/images/qemux86-64/ostree_repo -P 57556
82....
83
84You can then run from inside your device or QEMU emulation, provided your network is set up correctly.
85
86....
87# agl-remote identifies the remote server in your local repo
88ostree remote add --no-gpg-verify agl-remote http://192.168.7.1:57556 agl-ota
89
90# agl-ota is a branch name in the remote repo, set in OSTREE_BRANCHNAME
91ostree pull agl-remote agl-ota
92
93# agl is OS name as set in OSTREE_OSNAME
94ostree admin deploy --os=agl agl-remote:agl-ota
95....
96
97After restart you should boot into the newly deployed OS image.
98
99E.g. for the raspberrypi3 you can try this sequence:
100
101....
102# add remote
103ostree remote add --no-gpg-verify agl-snapshot https://download.automotivelinux.org/AGL/snapshots/master/latest/raspberrypi3/deploy/images/raspberrypi3/ostree_repo/ agl-ota
104
105# pull
106ostree pull agl-snapshot agl-ota
107
108# deploy
109ostree admin deploy --os=agl agl-snapshot:agl-ota
110....
111
112=== SOTA tools
113
114SOTA tools now contains only one tool, garage-push that lets you push the changes in OSTree repository generated by bitbake process. It communicates with an http server capable of querying files with HEAD requests and uploading them with POST requests. garage-push is used as following:
115
116....
117garage-push --repo=/path/to/ostree-repo --ref=mybranch --credentials=~/.sota-tools.json --user=username --password=
118....
119
120You can set OSTREE_PUSH_CREDENTIALS in your local.conf to make your build results be automatically synchronized with a remote server. Credentials are stored in JSON format which is described in https://github.com/advancedtelematic/sota-tools/blob/master/README.adoc[sota-tools documentation]