Rename minimal image references to fixedfunction

Rename `minimal` to `fixedfunction` to reflects the "Fixed function device
scenario" from Apertis Platform Technical Vision.

Signed-off-by: Frédéric Danis <frederic.danis@collabora.com>

content/_index.md

 +++
 date = "2020-01-15"
-lastmod = "2021-04-05"
+lastmod = "2021-08-04"
 weight = 100
 
 title = "Home Page"
@@ -46,7 +46,7 @@ Ensure that all the software shipped in Apertis is
 so that downstreams are entitled to use, modify and redistribute work derived
 from our deliverables.
 
-Ensure that Apertis images targeting devices (such as target and minimal), are
+Ensure that Apertis images targeting devices (such as target and fixedfunction), are
 not subject to licensing constraints that may conflict with the regulatory
 requirementt of some intended use cases.
 

content/architecture/workflow-guide.md

@@ -3,6 +3,7 @@ title = "The Apertis Workflow"
 weight = 100
 
 date = "2021-05-10"
+lastmod = "2021-08-04"
 +++
 
 Apertis is primarily built from Debian source packages utilising optimised,
@@ -150,7 +151,7 @@ different platform specific recipes. It also enables different generic recipes
 for different use cases to be combined with the same platform-specific recipe,
 thus enabling a platform to be used for different use cases.
 
-For instance, the `target` and `minimal` recipes for `arm64` could be combined
+For instance, the `target` and `fixedfunction` recipes for `arm64` could be combined
 with the U-Boot and Raspberry Pi recipes to generate four possible combinations
 of flashable images, targeting either the Renesas R-Car or Raspberry Pi
 platforms.

content/concepts/automated-license-compliance.md

@@ -12,6 +12,7 @@ aliases = [
 ]
 outputs = [ "html", "pdf-in",]
 date = "2020-06-05"
+lastmod = "2021-08-04"
 +++
 
 
@@ -120,7 +121,7 @@ This same scripts also issues a warning in case a problematic license is found.
 ## CI Pipeline integration
 
 Apertis utilizes [Debos](https://github.com/go-debos/debos) in its image generation pipeline, which provides a very versatile way of customizing them. During the final stage of the image creation, the script `generate_bom.py` is used to build the BOM file with the license information of the image and export it as an additional artifact.
-Finally as both `minimal` and `target`images should not shipped extra data, the contents of `/usr/share/doc/` are dropped from the image.
+Finally as both `fixedfunction` and `target` images should not ship extra data, the contents of `/usr/share/doc/` are dropped from the image.
 
 # Step-by-step process
 
@@ -157,7 +158,7 @@ This is a description of the steps in the process as currently implemented:
 1. the [`generate_bom.py` script](https://gitlab.apertis.org/infrastructure/apertis-image-recipes/-/blob/283bcd3f/scripts/generate_bom.py)
    is [invoked at the end of each image recipe](https://gitlab.apertis.org/infrastructure/apertis-image-recipes/-/blob/283bcd3f/image-uboot.yaml#L150),
    loading all the `/usr/share/doc/*/copyright_report.gz` files producing
-   [a JSON report](https://images.apertis.org/release/v2022dev2/v2022dev2.0/arm64/minimal/apertis_v2022dev2-minimal-arm64-rpi64_v2022dev2.0.img.licenses.gz)
+   [a JSON report](https://images.apertis.org/release/v2022dev3/v2022dev3.0/arm64/fixedfunction/apertis_v2022dev3-fixedfunction-arm64-rpi64_v2022dev3.0.img.licenses.gz)
    alongside each produced image, using the source→license and binary→source
    mappings above to match each installed library and executable to the
    licenses of the sources used to build them

content/concepts/system-updates-and-rollback.md

@@ -3,7 +3,7 @@ title = "System updates and rollback"
 weight = 100
 outputs = [ "html", "pdf-in",]
 date = "2016-05-28"
-lastmod= "2021-01-20"
+lastmod = "2021-08-04"
 
 aliases = [
 	"/old-designs/latest/system-updates-and-rollback.html",
@@ -512,9 +512,9 @@ OSTree commit will produce identical results on the devices.
 ### Switching to the new branch
 
 The branches naming schema used in Apertis contains the major version, for instance:
-`apertis/v2020/armhf-uboot/minimal`. So for Apertis the "major upgrade" is technically
+`apertis/v2022/armhf-uboot/fixedfunction`. So for Apertis the "major upgrade" is technically
 considered as switching to another branch with a more recent Apertis version, for
-example `apertis/v2021/armhf-uboot/minimal`. By default such kinds of offline upgrade
+example `apertis/v2023/armhf-uboot/fixedfunction`. By default such kinds of offline upgrade
 with switching to another branch is restricted by the update manager.
 
 Offline upgrades between branches (including "major updates") consists of 2 steps which

content/download.md

 +++
 date = "2020-09-02"
+lastmod = "2021-08-04"
 weight = 100
 
 title = "Image Download"
@@ -16,7 +17,7 @@ release images presented below for evaluation.
   | ----- | ------------------ |
   | [Intel 64-bit (amd64)]({{< image-url Stable amd64 sdk >}}) | |
 
-- **Minimal**: A compact image, utilizing
+- **Minimal**: Up to v2021, a compact image, utilizing
   [OSTree]({{< ref "guides/ostree.md" >}}) for updates, designed to be run as a
   headless system on [target hardware]({{< ref "reference_hardware" >}}).
 
@@ -26,6 +27,16 @@ release images presented below for evaluation.
   | [ARM 32-bit (armhf)]({{< image-url Stable armhf minimal ostree >}}) | [bmap file]({{< image-url Stable armhf minimal ostree bmap >}}) |
   | [ARM 64-bit (arm64)]({{< image-url Stable arm64 minimal ostree >}}) | [bmap file]({{< image-url Stable arm64 minimal ostree bmap >}}) |
 
+- **FixedFunction**: Since v2022dev3, a compact image, utilizing
+  [OSTree]({{< ref "guides/ostree.md" >}}) for updates, designed to be run as a
+  headless system on [target hardware]({{< ref "reference_hardware" >}}).
+
+  | Image | Optional Downloads |
+  | ----- | ------------------ |
+  | [Intel 64-bit (amd64)]({{< image-url Development amd64 fixedfunction ostree >}}) | [bmap file]({{< image-url Development amd64 fixedfunction ostree bmap >}}) |
+  | [ARM 32-bit (armhf)]({{< image-url Development armhf fixedfunction ostree >}}) | [bmap file]({{< image-url Development armhf fixedfunction ostree bmap >}}) |
+  | [ARM 64-bit (arm64)]({{< image-url Development arm64 fixedfunction ostree >}}) | [bmap file]({{< image-url Development arm64 fixedfunction ostree bmap >}}) |
+
 - **Target**: A more featureful image, utilizing
   [OSTree]({{< ref "guides/ostree.md" >}}) for updates, providing an example
   graphical environment and designed to be run on

content/guides/deployment-management.md

@@ -12,6 +12,7 @@ aliases = [
     "/old-developer/v2022dev0/deployment-management.html",
 ]
 date = "2019-10-09"
+lastmod = "2021-08-04"
 +++
 
 The Apertis distribution provides a number of routes for managing updates to
@@ -43,12 +44,12 @@ The _OSTree static delta_ file is uploaded to the _module_ as its single artifac
 
 _Distribution_ and _module_ version are based on the _image_ version.
 
-To be more concrete, when the image pipeline is building the `armhf` minimal
+To be more concrete, when the image pipeline is building the `armhf` fixedfunction
 image it also builds a matching _full static OSTree bundle_ named, for
-instance, `apertis_ostree_v2019-minimal-armhf-uboot_v2019.4.delta`.
+instance, `apertis_ostree_v2022-fixedfunction-armhf-uboot_v2022.0.delta`.
 
 This bundle is uploaded to hawkBit under the
-`apertis_v2019-minimal-armhf-uboot` module with version `v2019.4`. This
+`apertis_v2022-fixedfunction-armhf-uboot` module with version `v2022.0`. This
 _module_ is linked to a _distribution_ sharing the same _name_ and _version_.
 
 # HawkBit backend installation
@@ -182,26 +183,26 @@ The distribution is a collection of _software module_(s).
 #### Using the API
 1st we need to define some variables which will be used: `name`, `description`, `version` and the `delta_file` to upload, e.g.:
 
-    $ name="apertis_test-minimal-armhf-uboot"
-    $ description="Apertis test minimal for armhf uboot"
+    $ name="apertis_test-fixedfunction-armhf-uboot"
+    $ description="Apertis test fixedfunction for armhf uboot"
     $ version="v1.0"
-    $ delta_file="apertis_ostree_minimal-armhf-uboot.delta"
+    $ delta_file="apertis_ostree_fixedfunction-armhf-uboot.delta"
 
 ##### Create a _Software Module_
     $ curl --user admin:admin 'http://localhost:8080/rest/v1/softwaremodules' -i -X POST -H 'Content-Type: application/json;charset=UTF-8' -d '[ {"vendor" : "Apertis","name" : "$name","description" : "$description", "type" : "os", "version" : "$version" } ]'
-    [{"createdBy":"admin","createdAt":1568627145649,"lastModifiedBy":"admin","lastModifiedAt":1568627145649,"name":"apertis_test-minimal-armhf-uboot","description":"Apertis test minimal for armhf uboot","version":"v1.0","type":"os","vendor":"Apertis","deleted":false,"_links":{"self":{"href":"http://localhost:8080/rest/v1/softwaremodules/1"}},"id":1}]
+    [{"createdBy":"admin","createdAt":1568627145649,"lastModifiedBy":"admin","lastModifiedAt":1568627145649,"name":"apertis_test-fixedfunction-armhf-uboot","description":"Apertis test fixedfunction for armhf uboot","version":"v1.0","type":"os","vendor":"Apertis","deleted":false,"_links":{"self":{"href":"http://localhost:8080/rest/v1/softwaremodules/1"}},"id":1}]
 
 ##### Upload an _artifact_ to a _Software Module_
 This will use the `href` link returned during the _Software Module_ creation.
 
     $ curl --user admin:admin 'http://localhost:8080/rest/v1/softwaremodules/1/artifacts' -i -X POST -H 'Content-Type: multipart/form-data' -F 'file=@$delta_file'
-    {"createdBy":"admin","createdAt":1568627195280,"lastModifiedBy":"admin","lastModifiedAt":1568627195280,"hashes":{"sha1":"d3b582709d7574e92e16671c5f097fda7795f832","md5":"c368c561a9279f60f7a1b04eabf63d58"},"providedFilename":"apertis_ostree_minimal-armhf-uboot.delta","size":21,"_links":{"self":{"href":"http://localhost:8080/rest/v1/softwaremodules/1/artifacts/1"},"download":{"href":"http://localhost:8080/rest/v1/softwaremodules/1/artifacts/1/download"}},"id":1}
+    {"createdBy":"admin","createdAt":1568627195280,"lastModifiedBy":"admin","lastModifiedAt":1568627195280,"hashes":{"sha1":"d3b582709d7574e92e16671c5f097fda7795f832","md5":"c368c561a9279f60f7a1b04eabf63d58"},"providedFilename":"apertis_ostree_fixedfunction-armhf-uboot.delta","size":21,"_links":{"self":{"href":"http://localhost:8080/rest/v1/softwaremodules/1/artifacts/1"},"download":{"href":"http://localhost:8080/rest/v1/softwaremodules/1/artifacts/1/download"}},"id":1}
 
 ##### Create a _Distribution_
 the will use the module `id` returned during the _Software Module_ creation.
 
     $ curl --user admin:admin 'http://localhost:8080/rest/v1/distributionsets/' -i -X POST -H 'Content-Type: application/json;charset=UTF-8' -d '[ {"requiredMigrationStep" : false,"name" : "$name","description" : "$description", "type" : "os", "version" : "$version", "modules" : [ {"id" : 1} ] } ]'
-    [{"createdBy":"admin","createdAt":1568627754940,"lastModifiedBy":"admin","lastModifiedAt":1568627754940,"name":"apertis_test-minimal-armhf-uboot","description":"Apertis test minimal for armhf uboot","version":"v1.0","modules":[{"createdBy":"admin","createdAt":1568627145649,"lastModifiedBy":"admin","lastModifiedAt":1568627195295,"name":"apertis_test-minimal-armhf-uboot","description":"Apertis test minimal for armhf uboot","version":"v1.0","type":"os","vendor":"Apertis","deleted":false,"_links":{"self":{"href":"http://localhost:8080/rest/v1/softwaremodules/1"}},"id":1}],"requiredMigrationStep":false,"type":"os","complete":true,"deleted":false,"_links":{"self":{"href":"http://localhost:8080/rest/v1/distributionsets/1"}},"id":1}]
+    [{"createdBy":"admin","createdAt":1568627754940,"lastModifiedBy":"admin","lastModifiedAt":1568627754940,"name":"apertis_test-fixedfunction-armhf-uboot","description":"Apertis test fixedfunction for armhf uboot","version":"v1.0","modules":[{"createdBy":"admin","createdAt":1568627145649,"lastModifiedBy":"admin","lastModifiedAt":1568627195295,"name":"apertis_test-fixedfunction-armhf-uboot","description":"Apertis test fixedfunction for armhf uboot","version":"v1.0","type":"os","vendor":"Apertis","deleted":false,"_links":{"self":{"href":"http://localhost:8080/rest/v1/softwaremodules/1"}},"id":1}],"requiredMigrationStep":false,"type":"os","complete":true,"deleted":false,"_links":{"self":{"href":"http://localhost:8080/rest/v1/distributionsets/1"}},"id":1}]
 
 ### Deployment to target(s)
 

content/guides/howtodevelopondevices.md

 +++
 date = "2018-10-17"
+lastmod = "2021-08-04"
 weight = 100
 
 title = "How to Develop on Devices"
@@ -14,7 +15,7 @@ reference Apertis images.
 
 # Which image to choose
 
-The APT-based [minimal]({{< ref "images.md#minimal" >}}) and [target]({{< ref
+The APT-based [fixedfunction]({{< ref "images.md#fixedfunction" >}}) and [target]({{< ref
 "images.md#target" >}}) images are the ones providing all the
 flexibility needed for development, letting developers install and remove
 packages, and otherwise customize the rootfs.

content/guides/lava-apertis-testing.md

 +++
 title = "Apertis integration testing with LAVA"
 date = "2021-03-31"
+lastmod = "2021-08-04"
 weight = 100
 outputs = [ "html", "pdf-in",]
 +++
@@ -202,7 +203,7 @@ for our changes:
      name: test-systemctl
      format: "Apertis Test Definition 1.0"
      image-types:
-       minimal:  [ armhf, arm64, amd64 ]
+       fixedfunction:  [ armhf, arm64, amd64 ]
      image-deployment:
        - OSTree
      type: functional
@@ -230,7 +231,7 @@ for our changes:
      pattern: "(?P<test_case_id>.*):\\s+(?P<result>(pass|fail))"
 
    ```
-   This test is aimed to be run for an ostree-based minimal Apertis image for
+   This test is aimed to be run for an ostree-based fixedfunction Apertis image for
    all supported architectures. However the metadata is mostly needed for
    documentation purposes.
 
@@ -301,11 +302,11 @@ for our changes:
 
    Profile file is mapping test jobs to devices under the test. So you need to
    add your job template into the proper list. For example we may extend
-   the templates list named `templates-minimal-ostree` in file
+   the templates list named `templates-fixedfunction-ostree` in file
    `lava/profiles.yaml`:
    ```
    .templates:
-     - &templates-minimal-ostree
+     - &templates-fixedfunction-ostree
        - test-systemctl-tpl.yaml
    ```
    It is highly recommended to temporarily remove or comment out the rest of
@@ -349,7 +350,7 @@ for our changes:
 
        release=v2022dev1
        version=v2022dev1.0rc2
-       variant=minimal
+       variant=fixedfunction
        arch=armhf
        board=uboot
        baseurl="https://images.apertis.org"

content/guides/virtualbox.md

 +++
 date = "2020-06-09"
-lastmod = "2021-02-03"
+lastmod = "2021-08-04"
 weight = 100
 toc = true
 
@@ -409,7 +409,7 @@ containing the virtual machine intact.
 
 # Non-SDK images
 
-We recommend running minimal, target and development images on
+We recommend running fixedfunction, target and development images on
 [real hardware]( {{< ref "/reference_hardware/_index.md" >}} ), but VirtualBox
 may be able to run some of our `amd64` images.
 

content/policies/hwpack-requirements.md

@@ -10,6 +10,7 @@ aliases = [
 ]
 outputs = [ "html", "pdf-in",]
 date = "2019-11-28"
+lastmod = "2021-08-04"
 +++
 
 This documentation covers the requirements and considerations that should be taken into account when implementing "hardware packs" for the Apertis project.
@@ -26,7 +27,7 @@ The selection and packaging of these packages are predominantly driven by the ne
 
 ### OSpack
 
-The OSpack stage generates one or more generic (architecture specific but largely hardware independent) archived rootfs built from Apertis packages. These rootfs archives are known as OSpacks. The process is managed by a tool called [Debos](https://github.com/go-debos/debos), which uses yaml configuration files to guide what steps it takes. Apertis provides yaml files to assemble a number of differently targeted OSpacks, ranging from a minimal GUI-less OSpack, a target focused GUI OSpack and a development environment with a desktop style GUI and has pre-packaged the components required to generate these OSpacks.
+The OSpack stage generates one or more generic (architecture specific but largely hardware independent) archived rootfs built from Apertis packages. These rootfs archives are known as OSpacks. The process is managed by a tool called [Debos](https://github.com/go-debos/debos), which uses yaml configuration files to guide what steps it takes. Apertis provides yaml files to assemble a number of differently targeted OSpacks, ranging from a fixedfunction GUI-less OSpack, a target focused GUI OSpack and a development environment with a desktop style GUI and has pre-packaged the components required to generate these OSpacks.
 
 ![OSpack creation with Debos](/images/debos-ospack.svg)
 

content/policies/images.md

 +++
 date = "2020-09-02"
+lastmod = "2021-08-04"
 weight = 100
 toc = true
 
@@ -56,24 +57,26 @@ The main kinds of artifacts are:
 There are a number of types of images provided by Apertis, depending on the
 platform, including:
 
-## Minimal
+## FixedFunction
 
-Minimal images provide compact example images for headless systems and
+FixedFunction images provide compact example images for headless systems and
 are a good starting point for product-specific customizations.
 
 Other than basic platform support in order to succesfully boot on the reference
-hardware, the minimal example images ship the complete connectivity stack.
+hardware, the FixedFunction example images ship the complete connectivity stack
+serving a minimal static web page.
 
 The reference update system is based on OSTree, but APT-based images are also
 provided for development purposes.
 
-No artifact covered by the GPLv3 is part of the `minimal` ospacks and images.
+No artifact covered by the GPLv3 is part of the `fixedfunction` ospacks and
+images.
 
 ## Target
 
 Target images provide the most complete superset of the features offered by the
-minimal images, shipping full graphics support with a sample HMI running on top
-and applications with full multimedia capabilities.
+FixedFunction images, shipping full graphics support with a sample HMI running
+on top and applications with full multimedia capabilities.
 
 The reference update system is based on OSTree, but APT-based images are also
 provided for development purposes.
@@ -148,7 +151,7 @@ each image type:
 
 | Type       | amd64 | armhf | arm64 | APT | OSTree | 
 | ---------- | ----- | ----- | ----- | --- | ------ |
-| Minimal    | ✅    | ✅    | ✅    | ✅  | ✅     |
+| FixedFunction | ✅ | ✅    | ✅    | ✅  | ✅     |
 | Target     | ✅    | ✅ \* |       | ✅  | ✅     |
 | Base SDK   | ✅    |       |       | ✅  |        |
 | SDK        | ✅    |       |       | ✅  |        |

content/policies/license-expectations.md

@@ -11,7 +11,7 @@ aliases = [
 ]
 outputs = [ "html", "pdf-in",]
 date = "2019-04-16"
-lastmod = "2021-07-06"
+lastmod = "2021-08-04"
 +++
 
 Apertis aims to accomplish the following goals with it's licensing:
@@ -19,7 +19,7 @@ Apertis aims to accomplish the following goals with it's licensing:
 - Ensure that all the software shipped in Apertis is open source or at least
   freely distributable, so that downstreams are entitled to use, modify and
   redistribute work derived from our deliverables.
-- Ensure that Apertis images targeting devices (such as target and minimal),
+- Ensure that Apertis images targeting devices (such as target and fixedfunction),
   are not subject to licensing constraints that may conflict with the
   regulatory requirements of some intended use cases.
 

content/qa/immutablerootfstests.md

 +++
 date = "2018-12-17"
+lastmod = "2021-08-04"
 weight = 100
 
 title = "Immutable Rootfs Tests"
@@ -76,7 +77,7 @@ unpacked on the device before the test is executed.
 
 In the simplest case the support git repository only ships a shell script and
 maybe some static test samples. Keep in mind that the Apertis reference images
-do not ship `bash` on minimal/target images but use `dash`, so stick to POSIX
+do not ship `bash` on fixedfunction/target images but use `dash`, so stick to POSIX
 features and avoid [bashisms](https://mywiki.wooledge.org/Bashism).
 
 If instead compiled binaries are needed, they need to be built on OBS and

content/qa/test-data-storage.md

@@ -9,7 +9,7 @@ aliases = [
 ]
 outputs = [ "html", "pdf-in",]
 date = "2019-09-27"
-lastmod = "2021-01-22"
+lastmod = "2021-08-04"
 +++
 
 The test cases, both manual and automated, are written in the LAVA test
@@ -43,7 +43,7 @@ name: Name of test case.
 type: This could be used to define a series of test case types (functional, sanity,
       system, unit-test).
 exec-type: Manual or automated test case.
-image-type: This is the image type (target, minimal, ostree, development, SDK)
+image-type: This is the image type (target, fixedfunction, ostree, development, SDK)
 	    and the architectures that it's supported on.  description: Brief
             description of the test case.
 priority: low, medium, high, critical.

content/reference_hardware/imx8mn_var_symphony_setup.md

 +++
 date = "2021-07-13"
+lastmod = "2021-08-04"
 weight = 100
 toc = true
 
@@ -27,7 +28,7 @@ You should have at least:
 - 1 iMX8MN Variscite Development Kit.
 - 1 Power supply/adaptor 12V/3A DC, center positive.
 - 1 USB type A to micro B cable.
-- 1 MicroSD card (at least 4GB for minimal image).
+- 1 MicroSD card (at least 4GB for fixedfunction image).
 
 # Board setup
 

content/reference_hardware/rcar-gen3_setup.md

 +++
 date = "2019-03-14"
-lastmod = "2020-12-17"
+lastmod = "2021-08-04"
 weight = 100
 toc = true
 
@@ -31,15 +31,15 @@ You need to provide your own:
 ## Prepare SD card
 
   - Download the
-    [arm64 minimal image](https://images.apertis.org/release/v2020/v2020.3/arm64/minimal/apertis_v2020-minimal-arm64-uboot_v2020.3.img.gz),
-    plus the [`.bmap` file](https://images.apertis.org/release/v2020/v2020.3/arm64/minimal/apertis_v2020-minimal-arm64-uboot_v2020.3.img.bmap).
+    [arm64 fixedfunction image](https://images.apertis.org/release/v2022/v2022.0/arm64/fixedfunction/apertis_v2022-fixedfunction-arm64-uboot_v2022.0.img.gz),
+    plus the [`.bmap` file](https://images.apertis.org/release/v2022/v2022.0/arm64/fixedfunction/apertis_v2022-fixedfunction-arm64-uboot_v2022.0.img.bmap).
     microSD card using command:
 
-        sudo bmaptool copy apertis_v2020-minimal-arm64-uboot_v2020.3.img.gz /dev/mmcblk0
+        sudo bmaptool copy apertis_v2022-fixedfunction-arm64-uboot_v2022.0.img.gz /dev/mmcblk0
 
     Alternatively bmaptool can flash directly from http e.g. by using:
 
-        sudo bmaptool copy https://images.apertis.org/release/v2020/v2020.3/arm64/minimal/apertis_v2020-minimal-arm64-uboot_v2020.3.img.gz /dev/mmcblk0
+        sudo bmaptool copy https://images.apertis.org/release/v2022/v2022.0/arm64/fixedfunction/apertis_v2022-fixedfunction-arm64-uboot_v2022.0.img.gz /dev/mmcblk0
 
 
   - Put the SD card in the board

content/reference_hardware/rpi4_setup.md

 +++
 date = "2021-06-26"
+lastmod = "2021-08-04"
 weight = 100
 
 title = "Raspberry Pi 4 Setup"
@@ -96,20 +97,20 @@ the most supported image.
 The support for RPI Imager is ongoing.
 {{% /notice %}}
 
-1. On your host [download the minimal image](https://images.apertis.org/daily/v2022dev3/) for
+1. On your host [download the fixedfunction image](https://images.apertis.org/daily/v2022dev3/) for
    Raspberry Pi 4 `arm64` architecture and corresponding `bmap` file (both must have
    `_rpi64_` suffix in file names). For instance,
-   for `apertis_v2022dev3-minimal-arm64-rpi64_20210630.0018.img.gz`:
+   for `apertis_v2022dev3-fixedfunction-arm64-rpi64_20210630.0018.img.gz`:
 
    ```
-   wget https://images.apertis.org/daily/v2022dev3/20210630.0018/arm64/minimal/apertis_v2022dev3-minimal-arm64-rpi64_20210630.0018.img.gz
-   wget https://images.apertis.org/daily/v2022dev3/20210630.0018/arm64/minimal/apertis_v2022dev3-minimal-arm64-rpi64_20210630.0018.img.bmap
+   wget https://images.apertis.org/daily/v2022dev3/20210630.0018/arm64/fixedfunction/apertis_v2022dev3-fixedfunction-arm64-rpi64_20210630.0018.img.gz
+   wget https://images.apertis.org/daily/v2022dev3/20210630.0018/arm64/fixedfunction/apertis_v2022dev3-fixedfunction-arm64-rpi64_20210630.0018.img.bmap
    ```
 
 2. Flash the downloaded images onto SD-card with `bmaptool`, assuming
    the `/dev/mmcblk0` is your card reader device:
    ```
-   sudo bmaptool copy apertis_v2022dev3-minimal-arm64-rpi64_20210630.0018.img.gz /dev/mmcblk0
+   sudo bmaptool copy apertis_v2022dev3-fixedfunction-arm64-rpi64_20210630.0018.img.gz /dev/mmcblk0
    ```
 
    {{% notice warning %}}