/proc/cpuinfo missing Hardware/Revision/Serial on arm64

[thomasklingbeil]

The information contained in /proc/cpuinfo while using an arm64 kernel contains less information than then 32-bit arm version, leading to the system not being recognized as a Raspberry Pi, e.g. by the RPi.GPIO library.

Especially, the missing Hardware/Revision lines below the individual CPUs seem to cause trouble, as they are being used for identification of the specific model.

From what I can see in the source code, for arm64 the cpuinfo comes from here: https://github.com/raspberrypi/linux/blob/rpi-4.12.y/arch/arm64/kernel/cpuinfo.c, while for arm it is generated in setup.c (would be https://github.com/raspberrypi/linux/blob/rpi-4.12.y/arch/arm64/kernel/setup.c for arm64).

Content of /proc/cpuinfo with the arm64 kernel:

processor	: 0
BogoMIPS	: 38.40 
Features	: fp asimd evtstrm crc32
CPU implementer	: 0x41
CPU architecture: 8
CPU variant	: 0x0
CPU part	: 0xd03
CPU revision	: 4

... ... ...

What I expected (running on a 32-Bit arm kernel, serial removed):

processor       : 0
model name      : ARMv7 Processor rev 4 (v7l)
BogoMIPS        : 38.40
Features        : half thumb fastmult vfp edsp neon vfpv3 tls vfpv4 idiva idivt vfpd32 lpae evtstrm crc32 
CPU implementer : 0x41
CPU architecture: 7
CPU variant     : 0x0
CPU part        : 0xd03
CPU revision    : 4

... ... ...

Hardware        : BCM2709
Revision        : a22082
Serial          : 00000000XXXXXXXX

Additional system information:

$ cat /etc/os-release 
PRETTY_NAME="Debian GNU/Linux 8 (jessie)"
NAME="Debian GNU/Linux"
VERSION_ID="8"
VERSION="8 (jessie)"
ID=debian
HOME_URL="http://www.debian.org/"
SUPPORT_URL="http://www.debian.org/support"
BUG_REPORT_URL="https://bugs.debian.org/"
HYPRIOT_OS="HypriotOS/arm64"
HYPRIOT_OS_VERSION="v1.1.1"
HYPRIOT_DEVICE="Raspberry Pi 3 64bit"
HYPRIOT_IMAGE_VERSION="v20170303-185520"

$ uname -a
Linux black-pearl 4.9.13-bee42-v8 #1 SMP PREEMPT Fri Mar 3 16:42:37 UTC 2017 aarch64 GNU/Linux

[koolkhel]

This trouble renders all Rasberry Pi GPIO etc. scripts unusable on this architecture.

[pelwell]

1. We aren't supporting 64-bit builds, although if there are simple things we can do (like hosting defconfigs for arm64) then we will.
2. When we do support arm64 it will be with the absolute minimum number of changes to the upstream kernel (ideally none), and the content of /proc/cpuinfo would not be high on the list of priorities. Board revision number and serial number are concepts that don't appear to exist in the arm64 architecture, but we will continue to make that information available via /proc/device-tree/system/linux,revision and /proc/device-tree/system/linux,serial, with human-readable versions in /proc/device-tree/model and /proc/device-tree/serial-number.

[pelwell]

This is a won't fix.

[sakaki-]

A simple, although not very elegant, workaround for this (without patching the userspace libraries or kernel) is to bind-mount a faux version of /proc/cpuinfo when required; see for example my post here.

With the rpi-4.19.y kernel, this is sufficient to e.g. get the picamera lib working (see e.g. here (64-bit kernel, 32-bit Raspbian userspace in this case)), and will iirc allow a 64-bit build of wiringpi to run OK (64-bit kernel, 64-bit userspace). YMMV.

You can use e.g. a mount namespace for your target app to prevent this workaround affecting the rest of your system (although most well-behaved 64-bit userland stuff seems to check the devicetree anyhow, rather than /proc/cpuinfo, and so doesn't seem to care ^-^).

hth,
sakaki