RPi Compute Module 3+ with Mender-Convert?

sddw · December 5, 2019, 9:16am

Hello,

I have followed the board integration instructions for RPi 3 found here, except that I am using a Compute Module 3+. I was able to convert the stock Raspbian Stretch Lite 2019-04-08 image to support Mender, using the mender-convert tool as described (though curiously I had to explicitly set the “–storage-total-size-mb 7400” parameter before it would fit in the 8GB eMMC). With this converted image flashed to the CM3+, and the CM3+ connected to my custom PoE carrier board, the board boots successfully however it is not connecting to my network via Ethernet. If I use the stock Raspbian image without converting for Mender, it works and connects fine.

I see in the “Known Issues” section how “Devicetree is not updated”, and other forum posts like this one where it seems the root issue may be related to U-Boot doing some of its own pin muxing instead of honoring the .dtb as supplied in the image.

As we use a custom carrier board, there are various tweaks that we have made and need regarding pin muxing. Is there any simple way to use the mender-convert tool while maintaining our customized pin muxing? Or is our only option to set up a Yocto environment, attempt to modify the U-Boot files to avoid undesired muxing, and build the image that way?

I am new to Yocto and U-Boot, so that seems a bit daunting. Any tips or guidance would be much appreciated.

Thanks!

drewmoseley · December 5, 2019, 2:13pm

Hello @sddw, and welcome to Mender Hub.

In the case of stock Raspbian, without Mender, how do you provide updated DTBs? I know Raspbian makes heavy use of config.txt and DTB overlays and I suspect that can be made to work with mender-convert although you may need to do some of the setup manually on the board during first boot.

The new iteration of mender-convert allows you to add custom hooks to modify the created images so it’s possible that may allow you to add your customizations during image creation. And if you are not using the new version of mender-convert, I strongly urge you to do so as the old one is not being actively maintained.

Drew

sddw · December 6, 2019, 8:47am

Hi @drewmoseley, thank you for the response.

To answer your question, I have made a customized Device Tree source (.dts file, non-customized sample found here) with desired pin muxing settings, which is then compiled into a .dtb following the RPi instructions here.

The instructions in the Mender RPi board integration guide pointed me to v1.2.1 of mender-convert, but okay thank you for the link and I will soon test with the new iteration recommended there. Where can I find information on how I might use these custom hooks?

Thanks!

mirzak · December 6, 2019, 12:37pm

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,

github.com

mendersoftware/mender-docs/blob/62d9b1cba2130f0162f96902a504149be1d3507a/04.Artifacts/02.Debian-family/02.image-configuration/docs.md

---
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.

This file has been truncated. 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:

and here:

github.com/raspberrypi/linux

Firmware handling of upstream kernel and Device Tree files

opened 01:31PM - 17 Sep 19 UTC

closed 02:00PM - 19 Mar 20 UTC

pelwell

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

Topic		Replies	Views
RaspberryPi CM 3+ up to date image with mender-convert Debian family raspberry-pi-3 , mender-convert , bookworm	0	280	November 23, 2023
Flashing default Raspberry Pi OS image doesn't boot on Raspberry Pi 3 Compute Module General Discussions	5	715	June 1, 2022
Mender-convert with rpi cm3 b+ Debian family raspberrypi-cm3	2	380	March 14, 2024
Raspberry Pi Compute Module 3 Yocto Project yocto , sumo , raspberrypi-cm3	1	6455	August 15, 2019
CM3 module using Buildroot General Discussions	30	3695	November 13, 2019

RPi Compute Module 3+ with Mender-Convert?

Related topics