Skip to main content

Identify Your Module

Before you flash an application to the C0-microSD+, or communicate with it from a host application, you need the device path that your host assigned to it. The C0-microSD+ presents itself as an unformatted block-storage device, so any operating system that supports the standard SD protocol enumerates it without additional drivers. It carries no partition table and no filesystem, which is what makes it easy to spot among the disks your host already has. It reports a capacity of 268.4 MB on macOS and 256 MiB on Linux and Windows, which are the same quantity written in decimal units and in binary units.

If your operating system prompts you to format the device, dismiss the prompt. Formatting writes a filesystem over the on-device data layout and corrupts it.

Find the device path

Run diskutil list and look for the small disk that has no volume name and no partitions.

% diskutil list
...
/dev/disk4 (internal, physical):
#: TYPE NAME SIZE IDENTIFIER
0: *268.4 MB disk4

Here the device is /dev/disk4.

Confirm the module identity

A device path on its own does not tell you which Signaloid compute module you found. Confirm it with the info command of the C0_SD_toolkit.py script from the Signaloid-Compute-Module-Utilities repository. Raw block-device access needs root privileges, so run the toolkit under sudo.

sudo python3 C0_SD_toolkit.py /dev/disk4 info

The device path is a positional argument, and it comes before the command.

The toolkit identifies the module from its device identity region, eight read-only bytes of ASCII stored at 0x0FFFE000. The region exists above the SPI flash, so the toolkit reads it whether the core is running or not. See Device identity region.

On a C0-microSD+ the output takes the following form, where the reported module type is C0-microSD+.

Detected compute module: C0-microSD+
Device Serial Number: ...
Device UUID: ...

Reading bitstream:
Compute module type: C0-microSD+
Creation date: ...
Bitstream type: ...
Metadata schema: ...
Bitstream size: ... bytes
Bitstream CRC: 0x...
Bitstream CRC verification: PASS
Done.

Stop the core before you run info

Identifying the module works while the core is running, but everything else that info command prints does not. The serial number and the UUID are stored in the flash OTP, and the bitstream metadata is stored in the SPI flash. The SD interface cannot access either of those while the core is running. See SD access while the core runs.

% sudo python3 C0_SD_toolkit.py /dev/disk4 info
cannot read the device information while the SoC core is running. Stop the core first with `configure core-stop`.
An error occurred, aborting.

Stop the core, read the information, and start the core again.

sudo python3 C0_SD_toolkit.py /dev/disk4 config core-stop
sudo python3 C0_SD_toolkit.py /dev/disk4 info
sudo python3 C0_SD_toolkit.py /dev/disk4 config core-start

Two options refine what info does.

  • --raw prints the decoded metadata as a single JSON object instead of the field-by-field listing.
  • --stop-core stops the core for the duration of the read and starts it again afterward, which replaces the three commands above with one.

Command info always checks the bitstream against the CRC recorded in its metadata. The toolkit reads back only the length the metadata declares, compares the CRC, and prints PASS or FAIL. When the metadata contains no CRC field the Bitstream CRC verification line reads unable to verify (no CRC field) instead.

Next steps