rixty
/
OpenVoiceOS
mirror of https://github.com/OpenVoiceOS/OpenVoiceOS
1
1
Fork 0
Code Issues Releases Wiki Activity

Merge pull request #278 from shubhamsharma44/develop 

updated 3 files
This commit is contained in:
Peter Steenbergen 2024-10-17 20:47:31 +02:00 committed by GitHub
parent ba41a4da54 670f4578aa
commit 068941cc2c
No known key found for this signature in database
GPG Key ID: B5690EEEBB952194
3 changed files with 10 additions and 10 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

6
documentation/architecture.md
View File

@ -2,14 +2,14 @@
## Disk image build up
The system uses a so called "Double copy with fall-back" architecture. Also known as "A/B (seamless) system updates". This system guarantess that there is always a working copy even if the softwre update is interrupted or a power off occurs.
The system uses a so called "Double copy with fall-back" architecture. Also known as "A/B (seamless) system updates". This system guarantees that there is always a working copy even if the software update is interrupted or a power off occurs.
Each of these A/B copies contains a linux kernel within it's root file system, which is read only and compressed by utilizing squashfs. At current time the rootfs disk usage is ~300MB.
![Double_copy_layout](./images/Double_copy_layout.png)
A synergy with the boot loader is necessary, because the boot loader must decide which copy should be started. It must be possible to switch between the two copies. After a reboot, the boot loader decides which copy should run.
A seperate overlay partition for all changeable files is used to make the userspace system read/write. This seperate partition can be overlayed over either active rootfs partitions, being it slot A or slot B. A factory reset can therefor also being easliy obtained by resetting that overlay partition. It will then again start with the files shipped within the read only squashfs partition.
All docker containers and OVOS framework associated configuration files are stored with the users HOME directory which again is a seperate partition at the end of the disk which is also auto extended over the full size of the disk at boot. This is done based on the availability of free unused disk space at boot. (Any boot, being it the first or any consecutive boot)
A separate overlay partition for all changeable files is used to make the userspace system read/write. This separate partition can be overlayed over either active rootfs partitions, being it slot A or slot B. A factory reset can therefore also being easily obtained by resetting that overlay partition. It will then again start with the files shipped within the read only squashfs partition.
All docker containers and OVOS framework associated configuration files are stored with the users HOME directory which again is a separate partition at the end of the disk which is also auto extended over the full size of the disk at boot. This is done based on the availability of free unused disk space at boot. (Any boot, being it the first or any consecutive boot)
## Partition layout

4
documentation/building.md
View File

@ -63,7 +63,7 @@ As example to build the rpi4 version;
$ make clean
$ make rpi4_64
```
Building an image on the above stated devlopment machne takes around 3-4 hours. If you have a higher specification build machine, the building time can be as fast (or slow, depending on your point of view) as ~2 hours.
Building an image on the above stated development machine takes around 3-4 hours. If you have a higher specification build machine, the building time can be as fast (or slow, depending on your point of view) as ~2 hours.
When everything goes fine the following images/files will be available within the ./release directory;
#### OpenVoiceOS_{CONFIG}_{TIMESTAMP}.img
@ -71,7 +71,7 @@ This is the raw flashable disk image that can be flashed to your to be used disk
<br>* At current time this file is about ~1.4GB.
#### OpenVoiceOS_{CONFIG}_{TIMESTAMP}.img.xz
This is the same raw flashable disk image that can be flashed to your to be used disk (SD-Card, USB-Stick, SSD, SATA, etc), however xz compressed. This save bandwith if it needs to be downloaded and certain disk image utilities such as the Raspberry Pi Disk imager have native support to flash these type of files without uncompressing them first.
This is the same raw flashable disk image that can be flashed to your to be used disk (SD-Card, USB-Stick, SSD, SATA, etc), however xz compressed. This save bandwidth if it needs to be downloaded and certain disk image utilities such as the Raspberry Pi Disk imager have native support to flash these type of files without uncompressing them first.
<br>* At current time this file is about ~450MB.
#### OpenVoiceOS_{CONFIG}_{TIMESTAMP}.swu

6
documentation/features.md
View File

@ -2,7 +2,7 @@
## Updating the system
The system is using the SWUpdate system to seamlessly update and switch between Slot-A and Slot-B. An firmware update file basically contains a new version of the rootfs but can also include seperate files for either the overlay partion or even to update files wihin the HOME partition/ directory if required.
The system is using the SWUpdate system to seamlessly update and switch between Slot-A and Slot-B. An firmware update file basically contains a new version of the rootfs but can also include seperate files for either the overlay partion or even to update files within the HOME partition/ directory if required.
SWupdate files are using the .swu extension (SoftWare Update) and are basically CPIO images that can contain one or multiple rootfs images and/ or files. In addition, it also contain a sw-description file with meta information about the update.
A visual representation of this CPIO image looks like this:
@ -32,9 +32,9 @@ Updates can be applied by using the following multiple methods:
- Push/Pull from a fleet management server using Hawkbit. (Planned for stable updates in the future)
### Streaminig updates
### Streaming updates
Because we make use of a mirrored Slot A/B update architecture and therefor it will always be possible to boot into the other Slot and/ or recovery mode, updates are streamingly applied. Therefor no additional free space is required to first upload/download the firmware update image to the device. The update is applied as it is being uploaded/ downloaded.
Because we make use of a mirrored Slot A/B update architecture and therefore it will always be possible to boot into the other Slot and/ or recovery mode, updates are streamingly applied. Therefore no additional free space is required to first upload/download the firmware update image to the device. The update is applied as it is being uploaded/ downloaded.
### On-device webbased updates