RPi4 CM4 (Onlogic FR201) - how to get CM4 to work with Nerves?

SundayPowerEndre · January 17, 2025, 12:02pm

Hey guys, my colleagues and I are currently trying to use the FR201 from Onlogic with Nerves. It is a Rpi CM4 based system. We have been struggling a bit, and were wondering if CM4 is supposed to work out of the box with Nerves, or if there is any adjustments we need to make.

We made a slack thread0, and have figured out that one of our issues is that the SSD (not eMMC) is not supported out of the box. This was due to lack of SSD drivers.

We are going to attempt to adjust the cmdline.txt and fwup.conf to have the correct path to our disks

lawik · January 17, 2025, 12:41pm

Yeah, if @fhunleth or @amclain or someone who has done this a thousand times can point out what piece of Linux driver stuff might be missing that would be cool. I’ve shared what I could in a previous Slack thread. But searching for SSD and Linux drivers is death by terrible forum threads.

tomfarm · January 17, 2025, 3:40pm

Hi!

I’m not sure if this is entirely relevant, but we added support in our app for NVMe SSDs using these Buildroot packages. However, our application boots from eMMC and mounts the SSD during runtime similar to Nerves.Runtime.Init

Our Buildroot changes:

Nerves.Runtime.Init

github.com

nerves-project/nerves_runtime/blob/main/lib/nerves_runtime/init.ex

defmodule Nerves.Runtime.Init do
  @moduledoc """
  GenServer that handles device initialization.

  Initialization currently consists of:

  1. Mounting the application partition
  2. If the application partition can't be mounted, format it, and then mount it.

  Device initialization is usually a first boot only operation. It's possible
  that device filesystems get corrupt enough to cause them to be reinitialized.
  Since corruption should be rare, Nerves systems create firmware images
  without formatting the application partition. This has the benefit of
  exercising the corruption repair code. It's also required since some
  filesystem types can only be formatted on device.

  Long format times can be problematic in manufacturing. If this is an issue,
  see if you can use F2FS since it formats much faster than ext4. Some devices
  have also had stalls when formatting while waiting for enough entropy to
  generate a UUID. Look into hardcoding UUIDs or enabling a hw random number

This file has been truncated. show original

amclain · January 17, 2025, 11:19pm

Hey guys, my colleagues and I are currently trying to use the FR201 from Onlogic with Nerves. […] The SSD (not eMMC) is not supported out of the box.

The official Raspberry Pi single board computers are well-supported by Nerves, but once you start venturing into the Pi-derivative products, like Pi-based industrial controllers, then your mileage will vary. It’s not really a fault of Nerves, but rather there are so many different ways to customize hardware. One of the challenges to supporting these systems is being able to get access to the right information.

Looking at the FR201 manual, the SATA drive appears to be the Innodisk
DEM28-A28M41BW1DC-27. The first step is to look for this device family in the Linux and Buildroot menuconfigs for your Nerves system. If it’s difficult to find there, then search the device tree for the SSD, find it’s driver family (compatible), and use that to find that driver’s C source file in Linux to determine what to enable.

Our recommendation for a Nerves-supported industrial controller at Redwire Labs is the Compulab IOT-GATE-IMX8PLUS, which we maintain a Nerves system for. It’s been nice to work with and is priced well.

abelino · January 18, 2025, 12:36am

@SundayPowerEndre Normally, I would break into the bootloader’s console in order to better troubleshoot this but that is not possible with the Raspberry Pi platform. Here are a few things that come to mind to troubleshoot the situation:

Boot into RaspberryPi OS and capture the output of the following: lspci and lsblk where lspci will display the NVME SSD controller if the device is detected, something like: 41:00.0 Non-Volatile memory controller: Micron Technology Inc 7450 PRO NVMe SSD (rev 01). This should also shed some light as to what drivers to enable in Linux.

lsblk will display the available block devices and I suspect it’ll be mmcblk0. If we do see mmcblk0 from the output of lsblk, we don’t need to modify the current fwup-common.conf, fw_env.config, and erlinit.config files. If lsblk displays something other than mmcblk0, then yes, those files will need to be updated accordingly.

Now, after reviewing @tomfarm’s response, it does indeed look like the base rpi4/cm4 nerves system does not include support for NVMe SSD devices. Applying the commit Thomas suggested (linux-6.6.defconfig and nerves_defconfig changes) should help with that and if all goes well, should hopefully get you a step closer to booting your system off the NVMe SSD block device.

Vincent · January 23, 2025, 4:31pm

Hi, colleague of @SundayPowerEndre here. I’ve managed to get it booting after some trail-and-error. I copied some config from @tomfarm’s links as well as changing all references to /dev/mmcblk0 to /dev/sda (as well as changing the references to the partitions from for instance /dev/mmcblk0p2 to /dev/sda2).
Here is a a repo (GitHub - sundaypower/nerves_system_rpi4_fr201: Base Nerves system configuration for the Raspberry Pi 4) of the config (forked from the pi4 repo) that seems to be booting. I don’t think all my additions are necessary, so it’s probably possible to reduce it towards the standard pi4 config. Anyways, thanks for all the help!