IOT2050 PCAN-miniPCIe Driver: Resolving Missing Headers

Observed Failure Chain

The IOT2050 is running kernel 5.10.64 from IOT2050_Example_Image_V1.2.2. The kernel configuration check returns:

grep PEAK_ /boot/config-`uname -r`
# CONFIG_CAN_PEAK_PCIEFD is not set
# CONFIG_CAN_PEAK_USB is not set

This proves that these two in-tree PEAK CAN options are disabled in the running kernel. It does not prove that every possible PEAK driver is absent.

Building the external driver from /opt/PCAN_drivers/peak-linux-driver-8.16.0/ fails because its build system cannot locate kernel headers. Installing linux-headers-$(uname -r) also fails because the configured Debian Bullseye repositories contain no package matching linux-headers-5.10.64.

Choose the Driver Integration Path

There are two distinct paths. Do not mix their prerequisites:

Upgrading the kernel merely in the hope of finding headers is not a verified fix. A different kernel still requires either its matching headers for an external module or an image built with the necessary driver enabled.

Build the Driver into a Custom IOT2050 Image

The available evidence supports the custom-image path using meta-iot2050, isar, and the image configuration opened with ./kas-container menu. Apply the kernel selections in the relevant IOT2050 kernel configuration:

CONFIG_CAN_PEAK_PCIEFD=y
CONFIG_CAN_PEAK_USB=y

For a PCAN-miniPCIe installation, confirm that CONFIG_CAN_PEAK_PCIEFD matches the installed hardware before deployment. Enable CONFIG_CAN_PEAK_USB only when USB PEAK support is also required; the evidence does not establish that the miniPCIe card needs the USB option.

1. Start from the meta-iot2050 build environment with its required isar source available.
2. Run ./kas-container menu as a non-root user with the necessary privileges.
3. Open IOT2050 Image Configuration and select the required image type and project features.
4. Enable the applicable PEAK kernel option in the kernel configuration used by the build.
5. Run Save&Build, then deploy the resulting image using the established IOT2050 image procedure.

The evidence does not identify the exact configuration filename or establish which additional image options are mandatory for Node-RED, MQTT, or CAN utilities. Select those components according to the application requirements rather than assuming they are installed by the kernel driver options.

Separate Driver Configuration from Build Failures

One attempted build selected an Example Image with SWUpdate support plus Preempt-RT, Google Coral Edge TPU, and Docker features. That build reached BitBake task execution, then failed while fetching a TensorFlow revision for libedgetpu-16.0-1. This is a source-fetch failure associated with the selected Edge TPU feature, not evidence of a PEAK CAN driver compilation failure.

The earlier binfmt_misc messages report that /proc/sys/fs/binfmt_misc does not exist and cannot be mounted. Because the process continued through repository checks and into BitBake, the captured log does not establish that this warning caused the final failure.

1. Resolve or remove the feature that introduces the failing libedgetpu-16.0-1 fetch when Edge TPU support is not required.
2. Repeat the build and identify the first fatal ERROR, keeping warnings separate from the terminating failure.
3. If the image infrastructure itself still fails, report the complete build log through the official project issue channel.

Verify the Deployed Image

After booting the custom image, verify the running kernel rather than the build workspace:

uname -r
grep PEAK_ /boot/config-`uname -r`

The required option must no longer report is not set. Next, verify that the operating system detects the installed adapter and that the intended CAN interface can be brought into the application workflow. The evidence supplies no interface name, bitrate, or hardware-detection command, so derive those details from the deployed image and network requirements instead of assigning unsupported values.

If choosing the external-module path, rerun make only after providing the matching kernel build tree. Point KERNEL_LOCATION at the root of that built kernel when automatic header discovery cannot find it. Successful compilation alone is insufficient: confirm that the module loads against the running kernel and that the adapter is detected.

FAQ