mirror of
https://github.com/optim-enterprises-bv/meta-overc.git
synced 2026-01-17 10:31:11 +00:00
f8091aecad
Currently we ship the linux-firmware in -essential this offers some direct and indirect challenges. The direct challenges are that the size of -essentially is almost double what it can be without the firmware include, additionally the # of reasons to require an update to -essential is greater with the firmware included. An indirect challenge is that dom0 will have to interact with -essential's rootfs should a container wish to add kernel firmware to the system. By using the 'bridge' filesystem (/var/lib/cube/essential) and shipping the firmware in dom0 we can offer solutions to the above challenges. We remove the added size of firmware in the -essential fileystem (and images), we affect firmware updates by updating dom0 and dom0 can contribute to firmware by simply manipulting its own filesystem. Signed-off-by: Mark Asselstine <mark.asselstine@windriver.com>
79 lines
3.1 KiB
Plaintext
79 lines
3.1 KiB
Plaintext
Shared Firmware
|
|
-------------------------
|
|
|
|
Since one of the goals for cube-essential is to keep a small
|
|
footprint, the kernel firmware files pose a specific challenge. The
|
|
/lib/firmware directory amounts to about half the total size of the
|
|
cube-essential image. With such a large portion of the image being
|
|
firmware, many updates to cube-essential could be triggered by the
|
|
need to update firmware (yes the # of updates isn't proportional to
|
|
the size ratio but it is also non-zero).
|
|
|
|
With the above in mind it was determined that sharing firmware with
|
|
dom0 we can perform firmware updates without ever having to update
|
|
cube-essential. Firmware updates can be made in dom0 and the result
|
|
will be shared with cube-essential.
|
|
|
|
|
|
Filesystem changes
|
|
-------------------------
|
|
|
|
cube-essential
|
|
---
|
|
In cube-essential '/lib/firmware' is no longer populated with firmware
|
|
blobs and associated files/directories. '/lib/firmware' becomes a link
|
|
to '/var/lib/cube/essential/lib/firmware' ('/var/lib/cube/essential'
|
|
being a directory which is visible to dom0 and keeping '/lib/firmware'
|
|
part of the path to make it clear what it is). If you examine
|
|
'/lib/firmware' on cube-essential you will see a typical firmware
|
|
directory, beyond this being a link to another directory.
|
|
|
|
NOTE: To accomplish the above you can examine the
|
|
linux-firmware-cube-shared package (linux-firmware_git.bbappend)
|
|
|
|
dom0
|
|
---
|
|
In dom0 you will find a '/lib/firmware' directory populated with
|
|
firmware related files, per usual. You will also find that the
|
|
dom0-ctl-core systemd service has a new 'ExecStartPre' called
|
|
'firmware-sync'. This 'ExecStartPre' will call
|
|
'/etc/dom0.d/firmware-sync' to allow the contents of dom0's
|
|
'/lib/firmware' directory to be 'copied' to
|
|
'/var/lib/cube/essential/lib/firmware', such that cube-essential will
|
|
end up with a matching copy of the firmware in its '/lib/firmware'
|
|
directory (link).
|
|
|
|
NOTE: The 'copy' is a one direction sync from dom0 to cube-essential,
|
|
additions/removals in dom0's '/lib/firmware' will be reflected in
|
|
cube-essential's '/lib/firmware' after a sync, but not the other way
|
|
around.
|
|
|
|
|
|
Syncing
|
|
-------------------------
|
|
|
|
Updating the cube-essential firmware now involves different steps than
|
|
you would find in the traditional model. A typical update now might
|
|
look like one of the following:
|
|
|
|
1)
|
|
a) replace dom0 (with the new image containing '/lib/firmware' updates)
|
|
b) restart dom0 (the dom0-ctl-core will automatically sync firmware)
|
|
c) reload cube-essential kernel modules affected by firmware updates
|
|
|
|
2)
|
|
a) update dom0 (with firmware related package updates)
|
|
b) run '/etc/dom0.d/firmware-sync' to complete a sync
|
|
c) reload cube-essential kernel modules affected by firmware updates
|
|
|
|
3)
|
|
a) update or replace dom0 (including firmware updates)
|
|
b) run '/etc/dom0.d/firmware-sync' to complete a sync
|
|
c) reboot the system
|
|
|
|
NOTE that it may not always be possible to complete an update, which
|
|
includes firmware updates, without having to perform a system
|
|
reboot. This change doesn't change this but rather provides additional
|
|
options to the system designer that can often avoid a system reboot in
|
|
most cases.
|