Flashing » History » Revision 3
Revision 2 (tsaitgaist, 10/07/2017 02:39 PM) → Revision 3/8 (tsaitgaist, 10/13/2017 05:08 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@).
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@
For the [[Bootlog]] the femtocell seems to use "secure boot":
# the Percello bootrom verifies the Percello bootloader:
<pre>
Percello bootrom version 1.2.8
...
Board: Secure mode
...
Secured device - OTP2: verification ...PASSED
Secured device - OTP3: verification ...PASSED
Running Percello bootloader
PASSED
</pre>
# the Percello bootloader loader the Sagemcom FM-loader
<pre>
Nand execute: load_addr: 3fe0000
Percello bootloader version 0.6 (from NAND)
</pre>
# the Sagemcom FM-loader verifies the signatures of the kernel, rootfs, and app partitions
<pre>
Sagemcom FM-loader v2.0.4-11
Boot 1 (cold) into main system, secured
...
Unit key found and verified
TrustStor signature check passed
Group A signature check passed
Kernel A signature check passed
Root file system A signature check passed
Application file system A signature check passed
</pre>
You can check if secure boot has been activated using @cat /proc/prc6000/otp_data/boot/secured@ but it is unclear how the signatures are verified.
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@)
