mirzak
December 6, 2019, 12:37pm
4
We are in the processing of updating the docs for the new iteration of mender-convert. You can take a look here for a couple of examples,
---
title: Image configuration
taxonomy:
category: docs
---
-------------------------------------------------------------------------------
## Configuration Files
The configuration files are a means to customize the conversion process for
`mender-convert`. In the `configs/` directory, there are customization scripts
which add support for board-specific configurations. A run of `mender-convert`
can include multiple configuration files, each one added with the `--config`
command-line option. The standard configuration which will always be included
can be found in the
[configs/mender_convert_config](https://github.com/mendersoftware/mender-convert/blob/next/configs/mender_convert_config)
file, and includes the defaults for the configuration options which the tool
supports.
show original
You would have a similar problem in Yocto with this, and you can provide a custom U-Boot binary in the new mender-convert as well.
Unfortunately this is just how the Raspberry Pi works, and as they are not using U-Boot in “stock” images they do not care if they break/conflict in functionality so it is up to the community/users to sort out the problems.
There are some interesting discussions going on regarding this topic, and the possibility of supporting Raspberry Pi together with Mender and other similar workflows that require boot loader integration without U-Boot is currently investigated.
You can read more here:
Sorry for the slow reply!
Preferably you would want to be able mark “old” as insecure and to be able to disable the automatic rollback.
That makes sense. You probably wouldn’t even have to erase the image, just change/delete the recovery_prefix or rename the kernel or something like that. I guess it depends on how thorough you want to be. It would likely require some extra changes in the mender client either way though. I’ll mention that it would be nice to make the fallback boot selectable …
and here:
opened 01:31PM - 17 Sep 19 UTC
closed 02:00PM - 19 Mar 20 UTC
Although most users are unaware of it, the RPi firmware has special support for … "upstream" (compiled from source code found on kernel.org) Linux kernels and Device Tree files. Specifically, the `upstream_kernel=1` flag can be used to request that the relevant upstream DTB files are loaded, falling back to the downstream variants as necessary and applying the `upstream` overlay to help bridge the gap between the two worlds.
This mechanism has relied on the fact that the upstream developers have used a different naming convention for their DT files, basing them on the package name (`BCM283x`) as opposed to the die name (`BCM27xx`) (*). The Pi 4B SoC chip is called BCM2711 - there is no BCM2838, although the name is guaranteed free for use - and against expectations the upstream devs have chosen to also use `bcm2711` as their SoC identifier. This will break the select-by-filename logic used up to now, so an alternative is needed.
Another little-known firmware feature is the ability to request that overlays are loaded from a different subdirectory of the boot partition (on SD card or network share). This is controlled by the `overlay_prefix` setting, the default for which is `overlays/`.
A third item for consideration is that it would be useful to be able to store multiple independent operating systems on a single image and select between them at boot time based on a config.txt setting. This would allow (for example) a "recovery" OS for the case when a bad kernel build prevents the device from booting (almost a daily occurrence for me, sometimes). I've recently implemented a physical "64-bit switch" on my daily driver Pi4 that pulls GPIO5 to ground, activating the `[gpio5=0]` section that sets `arm_64bit=1`. It would be nice to be able to extend that to multiple alternate builds of the same kernel type, etc.
Pulling these strands together brings me to suggest a new config.txt setting - `os_prefix`. The default value would be the empty string, but if set it would be prepended to the names of "OS" files. Booting with `os_prefix=backup-` might load `backup-kernel.img`, whereas `os_prefix=backup/` would cause the firmware to look in the `backup` directory.
What constitutes an "OS" file? The kernel, .dtbs and cmdline.txt definitely fit the description, and I'm declaring that the firmware files (`bootcode.bin`, `start*.elf`, `fixup*.dat`) don't. Overlays fall into a grey area - making them OS-specific is conceptually cleanest and most flexible, making them common saves a small amount of space. I'm leaning towards a hybrid scheme whereby the firmware looks for `${os_prefix}${overlay_prefix}README`(**) and, if found, sets `overlay_prefix` to `${os_prefix}${overlay_prefix}`, otherwise leaving it unchanged. This allows shared and unshared overlays, but prevents a pick-and-mix approach.
The proposal for the handling of upstream files is that setting `upstream_kernel=1` has an implicit side-effect of setting `os_prefix=upstream/` (unless `os_prefix` is explicitly set). Putting all upstream kernel files into a subdirectory allows upstream and downstream to coexist, regardless of the names of the individual files.
N.B. `os_prefix` and `upstream_kernel` only affect automatic file selection - they have no effect on explicit `cmdline=`, `kernel=`, `device_tree=` and `ramfsfile=` settings which are always relative to the root of the boot partition (or the network equivalent).
Does anybody have any improvements to suggest or concerns about this approach?
(*) This could be the wrong way round - all that matters is that that each chip effectively has two names.
(**) The network and USB boot mechanisms don't have a way to test for the existence of a directory, only a file (and in the case of a non-directory prefix it wouldn't make sense anyway) so test for the existence of the README instead.
Please join the discussion if you have any feedback
1 Like