# RPi Compute Module 3+ with Mender-Convert? **URL:** \ **Category:** General Discussions\ **Tags:** raspberrypi-cm3\ **Created:** [December 5, 2019, 9:16am UTC](https://hub.mender.io/t/rpi-compute-module-3-with-mender-convert/1325 "2019-12-05T09:16:41Z")\ **Posts on this page:** 4\ **Page:** 1
**Author:** ![sddw](https://avatars.discourse-cdn.com/v4/letter/s/278dde/32.png) [@sddw](https://hub.mender.io/u/sddw)\ **Post date:** [December 5, 2019, 9:16am UTC](https://hub.mender.io/t/rpi-compute-module-3-with-mender-convert/1325/1 "2019-12-05T09:16:41Z")
Hello, I have followed the board integration instructions for RPi 3 [found here](https://hub.mender.io/t/raspberry-pi-3-model-b-b-raspbian/140), 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](https://hub.mender.io/t/raspberry-pi-cm3-error-message/749) 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! ---
**Author:** ![drewmoseley](https://yyz2.discourse-cdn.com/flex036/user_avatar/hub.mender.io/drewmoseley/32/47_2.png) [@drewmoseley](https://hub.mender.io/u/drewmoseley)\ **Post date:** [December 5, 2019, 2:13pm UTC](https://hub.mender.io/t/rpi-compute-module-3-with-mender-convert/1325/2 "2019-12-05T14:13:57Z")
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](https://hub.mender.io/t/new-iteration-of-the-mender-convert-tool/824) 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 ---
**Author:** ![sddw](https://avatars.discourse-cdn.com/v4/letter/s/278dde/32.png) [@sddw](https://hub.mender.io/u/sddw)\ **Post date:** [December 6, 2019, 8:47am UTC](https://hub.mender.io/t/rpi-compute-module-3-with-mender-convert/1325/3 "2019-12-06T08:47:46Z")
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](https://github.com/raspberrypi/firmware/blob/master/extra/dt-blob.dts)) with desired pin muxing settings, which is then compiled into a .dtb following the RPi instructions [here](https://www.raspberrypi.org/documentation/configuration/pin-configuration.md). 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! ---
**Author:** ![mirzak](https://yyz2.discourse-cdn.com/flex036/user_avatar/hub.mender.io/mirzak/32/2056_2.png) [@mirzak](https://hub.mender.io/u/mirzak)\ **Post date:** [December 6, 2019, 12:37pm UTC](https://hub.mender.io/t/rpi-compute-module-3-with-mender-convert/1325/4 "2019-12-06T12:37:51Z")
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, > > [@sddw](#): > > Is there any simple way to use the mender-convert tool while maintaining our customized pin muxing? 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: > [@Raspberry Pi Firmware](https://hub.mender.io/t/raspberry-pi-firmware/1172/10): > > 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: > > > 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