Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
thomasklingbeil opened this issue Jul 11, 2017 · 4 comments

Comments

Projects
None yet
4 participants
@thomasklingbeil
Copy link

commented Jul 11, 2017

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 comment has been minimized.

Copy link

commented Oct 5, 2017

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

@pelwell

This comment has been minimized.

Copy link
Contributor

commented Oct 5, 2017

  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 comment has been minimized.

Copy link
Contributor

commented Dec 5, 2017

This is a won't fix.

@sakaki-

This comment has been minimized.

Copy link

commented Feb 27, 2019

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.