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
This trouble renders all Rasberry Pi GPIO etc. scripts unusable on this architecture.
/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
.This is a won't fix.
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
Most helpful comment
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 thepicamera
lib working (see e.g. here (64-bit kernel, 32-bit Raspbian userspace in this case)), and will iirc allow a 64-bit build ofwiringpi
to run OK (64-bit kernel, 64-bit userspace). YMMV.hth,
sakaki