2

I'm running Debian Buster (Not Raspbian / RaspberryPiOS) and need to install the rpi userland in order to get access to vcgencmd.

I've tried the following:

cd /tmp
git clone https://github.com/raspberrypi/userland.git
sudo apt-get install cmake
cd userland
./buildme

This ends around the 5% mark, with many error lines and ultimately the following output:

/tmp/userland/interface/khronos/common/khrn_int_hash_asm.s: Assembler messages:
/tmp/userland/interface/khronos/common/khrn_int_hash_asm.s:36: Error: unknown architecture `armv6'
...
...
...
make[2]: *** [interface/khronos/CMakeFiles/khrn_client.dir/build.make:102: interface/khronos/CMakeFiles/khrn_client.dir/common/khrn_int_hash_asm.s.o] Error 1
make[1]: *** [CMakeFiles/Makefile2:439: interface/khronos/CMakeFiles/khrn_client.dir/all] Error 2
make: *** [Makefile:152: all] Error 2

I'm not sure what the solution to this problem is. The 'unknown architecture' seems like a good tarting point. But, I've no idea what the next move is.

Any suggestions / help would be greatly appreciated.

1
  • 1
    Thank you for making it clear ("Not Raspbian / RaspberryPiOS"). – goldilocks Dec 29 '20 at 20:02
2

That github page does refer to the fact that you can specify an architecture as an option to buildme, eg. the 64-bit build would be --aarch64, if you are running 64-bit Debian. Otherwise you would want --arm7l (these are listed at the top of that buildme script as the native, ie. on the Pi, builds).

There are pre-compiled versions in https://github.com/raspberrypi/firmware/tree/master/hardfp/opt/vc -- they may or may not work but worth a try if you can't get the build to fly.

Minor nitpick that /tmp is not a great place to build stuff if it is a tmpfs system (it usually is), because that is actually in RAM. Compiling often requires a fair bit of memory (though the vc lib stuff is I think not that much), so by writing the output to RAM, you are directly reducing the amount of memory available for the ongoing compile processes. Not such a big deal if you have a 4+ GB model, but something to be aware of if you are not already.

It looks like the following is needed to be able to get it to run: LD_LIBRARY_PATH=/opt/vc/lib /opt/vc/bin/vcgencmd

That makes sense. Executables are usually linked to libraries that are separate entities in the file system. There is a default set of paths that are searched for them, much like $PATH works for commands, but the linker (which finds the library components) uses a binary cache which is created from configuration files in /etc. The primary one is ld.so.conf, which sources stuff in /etc/ld.so.conf.d.

I notice in the current64-bit version of RpiOS the VideoCore libs are in conventional places, but in the 32-bit version there is still the /opt/vc, and to inform the linker, there's an /etc/ld.so.conf.d/00-vmcs.conf with one line:

/opt/vc/lib

If that's where you've installed stuff, just duplicate this. It doesn't matter what the file is called, as long as it is in /etc/ld.so.conf.d/ and it contains that line. Also make sure it is only writable by root as this is potentially a very nasty security hole (so owned root.root and with 644 permissions, as non-privileged process do need to read it). Then:

sudo ldconfig

This reads those files and updates the linker cache, so that the VC libs will now be found without explicitly having to set LIBRARY_PATH.

11
  • Grest thanks. I can't actually find a readme etc that mentions the different build options / flags. As for the /tmp I only used that because it was given as a step over on the raspberry pi forums (possibly by Dougie Lawson). – Phill Healey Dec 29 '20 at 20:24
  • Ok, I just saw the bit about --aarch6 – Phill Healey Dec 29 '20 at 20:27
  • SO now I get this when trying to run vcgencmd: error while loading shared libraries: libvchiq_arm.so: cannot open shared object file: No such file or directory Any idea what this is about? – Phill Healey Dec 29 '20 at 21:17
  • It looks like the following is needed to be able to get it to run: LD_LIBRARY_PATH=/opt/vc/lib /opt/vc/bin/vcgencmd <command> – Phill Healey Dec 29 '20 at 21:28
  • 1
    That makes sense. You don't have to do that all the time if you don't want though -- I've added a few paragraphs at the end above about that. I'm impressed you are setting out to do this (run a generic distro) without much prior linux nuts and bolts knowledge. It isn't that hard (I am sure you can do it), but it does mean sitting down and putting some time in to learn relevant parts of the big picture. – goldilocks Dec 29 '20 at 22:07
0

My solution to the problem copy it over from the 64 bit image of the Raspian, now Rasberry Pi OS I used the 2020-05-27-raspios-buster-arm64.img to do this a simple straight forward copy of the files required for it to work.

root@zeus-H370M-DS3H:~#  mkdir /tmp/cardroot
root@zeus-H370M-DS3H:~# mount /dev/sde2 /tmp/cardroot

After seeing this I was almost certain it would work.

zeus@zeus-H370M-DS3H:~$ file /tmp/cardroot/opt/vc/bin/vcgencmd
vcgencmd: ELF 64-bit LSB pie executable, ARM aarch64, version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux-aarch64.so.1, for GNU/Linux 3.7.0, BuildID[sha1]=a22f9bd0844d3be74cd9dbd74dd86b6dd3196f7e, stripped
root@buster-raspi:~# file /usr/bin/dd 
/usr/bin/dd: ELF 64-bit LSB pie executable, ARM aarch64, version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux-aarch64.so.1, for GNU/Linux 3.7.0, BuildID[sha1]=aa90bcf288d1293ca8980145095ba1dfba8e9b16, stripped

So I copied it over with rsync to my Pi and tried it.

root@buster-raspi:~# rsync -avP zeus@192.168.0.3:/tmp/cardroot/usr/bin/vcgencmd .
root@buster-raspi:~# ./vcgencmd temp
./vcgencmd: error while loading shared libraries: libvchiq_arm.so.0: cannot open shared object file: No such file or directory

To find the missing files.

root@buster-raspi:~# ldd vcgencmd
linux-vdso.so.1 (0x0000ffff8125e000)
libvchiq_arm.so.0 => not found
libvcos.so.0 => not found
libpthread.so.0 => /lib/aarch64-linux-gnu/libpthread.so.0 (0x0000ffff811eb000)
libdl.so.2 => /lib/aarch64-linux-gnu/libdl.so.2 (0x0000ffff811d7000)
librt.so.1 => /lib/aarch64-linux-gnu/librt.so.1 (0x0000ffff811bf000)
libc.so.6 => /lib/aarch64-linux-gnu/libc.so.6 (0x0000ffff8104d000)
/lib/ld-linux-aarch64.so.1 (0x0000ffff81230000)

root@zeus-H370M-DS3H:/home/zeus/qemu_vms# find /tmp/cardroot/ -name libvcos.so.0
/tmp/cardroot/usr/lib/aarch64-linux-gnu/libvcos.so.0
root@zeus-H370M-DS3H:/home/zeus/qemu_vms# find /tmp/cardroot/ -name libvchiq_arm.so.0 
/tmp/cardroot/usr/lib/aarch64-linux-gnu/libvchiq_arm.so.0

To copy them over into the proper places.

root@buster-raspi:~# rsync -avP zeus@192.168.0.3:/tmp/cardroot/usr/lib/aarch64-linux-gnu/libvcos.so.0 /usr/lib/aarch64-linux-gnu/
root@buster-raspi:~# rsync -avP zeus@192.168.0.3:/tmp/cardroot/usr/lib/aarch64-linux-gnu/libvchiq_arm.so.0 /usr/lib/aarch64-linux-gnu/

Test again to see if it worked.

root@buster-raspi:~# ./vcgencmd measure_temp
temp=49.0'C

Success so copy it to the place it was on the Raspian.

root@buster-raspi:~# mv vcgencmd /usr/bin/
root@buster-raspi:~# which vcgencmd
/usr/bin/vcgencmd

root@buster-raspi:~# cat /etc/debian_version 
10.8
root@buster-raspi:~# uname -a
Linux buster-raspi 5.9.0-0.bpo.5-arm64 #1 SMP Debian 5.9.15-1~bpo10+1 (2020-12-31) aarch64 GNU/Linux

I spent hours more time searching to find this solution and this page. Than the five minutes it actually took once I clued in and had the thought, hey it is based on Buster, perhaps it will work with a copy of it from their system. Sure enough it did, so for anyone finding this is the future who want to know how to do it give it a try.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.