BSP¶
In addition to containers, Pantavisor is in charge of the life-cycle of the Linux kernel, modules and firmware. To allow upgrading all this plus Pantavisor itself, all these binaries have been included under the BSP denomination in the state JSON.
Pantavisor¶
The Pantavisor binary and dependency tree are part of the revision BSP in the state JSON.
Addons¶
Additional files can be added to Pantavisor initrd rootfs without having to do it during compile time.
It is important to remark that the binary file has to be under cpio.xz4 compression. That is, cpio.xz with 4 Byte alignment. You can take a look at how we do the cpio.xz4 compression at this example. For the rest of gdbserver installation and use, go here.
Linux Kernel¶
The Linux Kernel, modules and firmware are also part of the revision BSP of the state JSON.
Managed Drivers¶
Pantavisor offers a declarative way to define a list of drivers at BSP level, each driver being just a set of Kernel modules. Parameters for Kernel loading are supported too by mapping drivers to device or user metadata.
The modules that are part of a driver will only be loaded if referenced from a container. Therefore, the loading order of the drivers will depend on their start up order.
Bootloader¶
To natively run Pantavisor on a device, it is necessary to have some on-disk artifacts that fall out of the umbrella of Pantavisor revisions. This is the case of the bootloader, which will load the Linux kernel and directly execute the initrd (Pantavisor) after that. Both the bootloader and Pantavisor will interact with Pantavisor storage to communicate with each other.
We support a number of boards, using both u-boot and grub bootloaders. These include all the bring up stuff that is necessary to run Pantavisor in its minimal form. You can take a look at the supported boards here. Contact us if you need support for your board!
Besides the u-boot and grub we have some interesting variants:
uboot-ab¶
This mode is based on fit images and mtd partitions. The idea is to keep one fit image per partition and switching the active partition on each update, in this way we always have the opportunity to rollback to the older one in case of error. To activate this mode we need to set some options in pantavisor.conf or directly in the kernel cmdline:
- PV_BOOTLOADER_TYPE, should be set to "uboot-ab", this is the option which triggers the new behavior.
- PV_BOOTLOADER_UBOOTAB_A_NAME, this is the name of the A partition, this name can be check in /proc/mtd (default fitA).
- PV_BOOTLOADER_UBOOTAB_B_NAME, similar than the previous option, but for partition B (default fitB).
- PV_BOOTLOADER_UBOOTAB_ENV_NAME, name of the partition used to store the uboot environment variables.
- PV_BOOTLOADER_UBOOTAB_ENV_BAK_NAME, name of the environment variables backup partition.
- PV_BOOTLOADER_UBOOTAB_ENV_OFFSET, offset of the environment variables inside the partition.
- PV_BOOTLOADER_UBOOTAB_ENV_SIZE, size of the environment variables partition.
Now with all set, Pantavisor on each update will evaluate if the kernel image has changes, to do this the system inspects the internal signatures of the fit image, if they not change, that means the kernel remains the same, and we don't need to save this image or switch the partition, otherwise, the fit image will be written in the available partition and the system will boot from there in the next reboot.
The image images are written preceding of a 4096 bytes header, right now only a small amount of this header is used to store the revision to which they belong.
rpiab¶
This is the implementation of A/B bootloader for Raspberry Pi, to trigger this behavior PV_BOOTLOADER_TYPE must be set to "rpiab"
uboot-pvk¶
In this mode, the bootloader works as usual for pvk kernels