Flashing » History » Revision 2
Revision 1 (tsaitgaist, 10/07/2017 02:16 PM) → Revision 2/8 (tsaitgaist, 10/07/2017 02:39 PM)
h1. Flashing
There are several way to flash partitions (e.g. updating) manually:
* using @/usr/sbin/ubiupdatevol@:
<pre>
ubiupdatevol version 1.2 - a tool to write data to UBI volumes.
Usage: ubiupdatevol <UBI volume node file name> [-t] [-s <size>] [-h] [-V] [--truncate]
[--size=<size>] [--help] [--version] <image file>
Example 1: ubiupdatevol /dev/ubi0_1 fs.img - write file "fs.img" to UBI volume /dev/ubi0_1
Example 2: ubiupdatevol /dev/ubi0_1 -t - wipe out UBI volume /dev/ubi0_1
-t, --truncate truncate volume (wipe it out)
-s, --size=<bytes> bytes in input, if not reading from file
-h, --help print help message
-V, --version print program version
</pre>
* using @/APP/dev_only/swupd.sh@
<pre>
swupd.sh - update flash partitions on the target
Easy mode:
using NFS: swupd.sh -i<IP> -p<PATH>
where:
<IP> = IP address of your VM (defaults to 192.168.16.18)
<PATH> = path of NFS directory (defaults to /home/femto/ftpdata)
using wget: swupd.sh -w<URL>
where:
<URL> = URL to fetch images from (e.g. ftp://user:pass@host/path)
Expert mode: (stay away from them!)
-k update kernel
-r update root fs
-a update application partition
-u update unitdata partition
-c update caldata partition
-x toggle banks
-z don't reboot after successful update
-o<str> Pass option string <str> to wget
</pre>
@/etc/init.d/flash_update@ takes care of flashing all partitions at once (also done during boot in @/etc/init.d/rcS@). (automatically).
Lastly the operator can also flash images remotely through @/APP/bin/oam_start@.
h1. Secure boot
h2. System
The femtocell uses "secure boot" (see [[Bootlog]]).
You can check if it has been activated using @cat /proc/prc6000/otp_data/boot/secured@.
The partition signatures (kernel, rootfs, data) are stored in @/dev/mtdblock2/bootdata.ini@ (the only file in the @bootdata@ partition).
While @bootdata@ is not signed itself, it only contains the signatures.
You can also see the content using @/APP/dev_only/cat_bootdata.sh@
The corresponding public key seems to be burned in the OTP section of the CPU, providing secure boot (this has not been verified).
@bootdata.ini@ also defines which system will be booted (A or B).
The file is updated using @/APP/dev_only/write_bootdata.sh@
h2. Operator
The @unidata@ (mtd3) signature is checked in @/etc/init.d/flash_update@ (called by @/etc/init.d/rcS@) using @/boot/bc_cli -u${PARTNUM_UNITDATA} -q@ (with PARTNUM_UNITDATA=3):
* hash is sha1sum of 0x2000 (8192) first bytes
* signature is at 0x2000 (after the cramfs indicated size)
* public key is first 256 bytes of @/caldata/unitkey.bin@
It the signature check fails, @unidata_backup@ is used.
If this signature check fails too, it enters recovery mode
@caldata@ in mounted without check (in @/etc/init.d/flash_update@)
