Add docs for extra firmware feature #3257
Conversation
|
|
||
| | Requirement | Version | | ||
| | --- | --- | | ||
| | {{ $names.os.upper }} | TODO | |
There was a problem hiding this comment.
Change this to OS version before merge
There was a problem hiding this comment.
Can be set after https://github.com/balena-os/meta-balena/pull/3764/commits is merged
cywang117
force-pushed
the
extra-firmware-docs
branch
from
d305e03 to
fd31010
Compare
Change-type: patch Signed-off-by: Christina Ying Wang <christina@balena.io>
cywang117
force-pushed
the
extra-firmware-docs
branch
from
fd31010 to
b979d8e
Compare
|
Website deployed to CF Pages, 👀 preview link https://db1d4c25.balenacloud-docs.pages.dev |
|
|
||
| ### Step 3: Deploy and reboot | ||
|
|
||
| After deploying a release that includes the firmware block, you must reboot the device for the firmware to take effect. This is especially important for firmware that is used early in the boot process. |
There was a problem hiding this comment.
used early in the boot process.
used early in the container application startup process
|
|
||
| ### Step 3: Deploy and reboot | ||
|
|
||
| After deploying a release that includes the firmware block, you must reboot the device for the firmware to take effect. This is especially important for firmware that is used early in the boot process. |
There was a problem hiding this comment.
must reboot the device for the firmware to take effect.
must either reload the drivers that use the extra firmware, or reboot the device
|
|
||
| ### Step 1: Add the firmware block to your fleet | ||
|
|
||
| Add the extra firmware block as a service in your `docker-compose.yml` file. We release firmware for both arm64 and x86 architectures, under `bh.cr/balena_os/linux-firmware-arm` and `bh.cr/balena_os/linux-firmware-x86` respectively. The firmware block **must** include the `io.balena.features.extra-firmware` label to enable the feature: |
There was a problem hiding this comment.
will the arm64 firmware work on armv7? I seem to recall @alexgg saying they should?
There was a problem hiding this comment.
Now that the firmware block has a run CMD (rsync) I think it will be a problem, since the rsync package is going to be aarch64. Perhaps we should be publishing the block as armv7 instead for compatibility? Or we should revisit having the engine populate the volume natively and we just need to have the SV clear the volume if we have new firmware files.
|
|
||
| ### Step 1: Add the firmware block to your fleet | ||
|
|
||
| Add the extra firmware block as a service in your `docker-compose.yml` file. We release firmware for both arm64 and x86 architectures, under `bh.cr/balena_os/linux-firmware-arm` and `bh.cr/balena_os/linux-firmware-x86` respectively. The firmware block **must** include the `io.balena.features.extra-firmware` label to enable the feature: |
There was a problem hiding this comment.
@mtoman, @alexgg, @acostach, @cywang117, @shaunmulligan, @klutchell, I'm not clear as to why we'd store the firmware by arch? There's indeed arch dependent firmware for instance intel wifi chips are probably only for x86 arch, but most of the firmware are dependent only to the underlying hardware.
It's possible that having arch dependent extra firmware are going to be part of the long term answer, but short term, is it really a separation we want to make?
I feel like we should continue thinking of how we are going to store the firmware to see how we could cleverly store them. Like what's an interesting MVP? I think we already stated that it can't be all linux firmware outside of the rootfs, but then what is it?
I would have naively thought that the first step of this feature would have been, necessary firmwares on one side, and extra firmware on the other, and from there incrementally trying to find the most clever way group firmwares together.
It could have been by directory within linux-firmware as well. bh.cr/balena_os/linux-firmware-xe bh.cr/balena_os/linux-firmware-amdgpu
I don't have all the answer here, but I think there's a blind spot to discuss here.
There was a problem hiding this comment.
@ycardaillac I think one of the problems is not so much the firmware but the container wrapping it. balenaCloud currently doesn't support the platform manifests, so we can't have a single bh.cr/balena_os/linux-firmware image that would pull down and run the right architecture container for the device type. It would always be an amd64 container which would fail on arm.
What you mention about cleverly separating the firmware is 100% something we need to do and that is for next cycle, because this cycle we aren't removing any firmware. We are just adding the capability and for this we can do the most exhaustive set of firmware and then cut back. In the future we can rework the bh.cr/balena_os/linux-firmware or add additional ones like say ``bh.cr/balena_os/linux-firmware-connectivity` or whatever themes make most sense for our customers, but we don't have to figure all of that out first before releasing the underlying mechanism. Unless I am misunderstanding what your concern is?
There was a problem hiding this comment.
@shaunmulligan it make sense I understand the necessity of arch then, so at the end of cycle what will we have?
Can we confirm if I understood correctly:
on the os side:
- we still ship the whole linux-firmware
- we have the ability to hot plug an extra firmware path in config.json where linux firmware are going to be looked for
- we use the volume name to find the path final path thanks to the engine
on the supervisor side: - a label that will pull a docker image containing a version of linux-firmware and rsync it to a named volume
- update the config.json with the named volume so that OS can add the path to the kernel
Next cycles:
- splitting the firmware
When you mean releasing the underlying mechanism, do you mean making an announcement about it or merging the PRs? I'd just want to figure out the general process of multi cycles features and how / when we consider something released
There was a problem hiding this comment.
@ycardaillac yeah, although I think there slight adjustments to your statements:
- we still ship the whole linux-firmware --> We ship whatever we have always shipped for each device type, we don't ship all linux-firmware, we cut it down and remove a bunch and I think it varies between device types
- a label that will pull a docker image containing a version of linux-firmware and rsync it to a named volume
update the config.json with the named volume so that OS can add the path to the kernel --> the label doesn't instruct anything to be pulled, all the label does is tell the supervisor to mount the volume to any service/container that specifies that label. We could just leave the feature like that and tell the customers they have to figure out how to create a container with the firmware they want to add in. That is obviously not a great experience, so we create a "demo" block that automatically pulls in all the wholelinux-firmwarepackage. I expect that people going to production might cut that down to only the pieces they really need, but for getting started and prototyping the whole set works.
When you mean releasing the underlying mechanism, do you mean making an announcement about it or merging the PRs?
When I say release, I mean merge it and make an announcement to get people to start using it. The mechanism is just the ability to define a label which mounts a directory in which a customer can put firmware that the kernel will use next boot (or if they modprobe).
There was a problem hiding this comment.
Thanks @shaunmulligan, yes of course for the os part.
We could just leave the feature like that and tell the customers they have to figure out how to create a container with the firmware they want to add in. That is obviously not a great experience, so we create a "demo" block that automatically pulls in all the whole linux-firmware package
Oh ok that make much more sense now, so we don't even need to actually provide a linux-firmware image library with this or that firmware in them. We still need to figure out which ones are our "essentials" firmware but after that we're essentially done regarding how to provide the firmware to the customer.
Thanks for the info about the release part, so we basically keep the PRs open until we have the whole feature.
Sorry if my questions/remarks seems obvious there were few stuff that I needed to figure out about the whole extra firmware stuff.
Change-type: patch