vcdbg missing

[satmandu]

I got it installed by copying it over from a 32-bit install to /usr/bin/vcdbg, installing apt install libc6-armhf-cross and then running sudo LD_LIBRARY_PATH=/opt/vc/lib /usr/bin/vcdbg though some messing with patchelf might negate the need to do that if you don't want to just compile it for arm64.

Relevant: raspberrypi/userland#314 (comment)

(I needed vcdbg to troubleshoot awb issues with my no-ir camera setup)

[pelwell]

See raspberrypi/linux#3666 and https://git.venev.name/hristo/rpi-vc-log for an alternative. @hvenev kindly submitted them ages ago and I've been pondering and tweaking when I get a spare moment because the driver change is larger than I feel ought to be necessary, but they should basically just work as is.

[satmandu]

Whoops. The command I end up needing to run is sudo LD_LIBRARY_PATH=/opt/vc/lib /usr/bin/vcdbg set awb_mode 0

I'm not seeing how to do that using vc-log though I can compile it just fine.

[hvenev]

For vc-log the last commit makes it use read() on /dev/vc-mem, which is implemented by the driver change @pelwell was talking about. Before it used `mmap()`, which only works on Pi 4 and on devices with <= 1008 MB RAM.

…

On July 1, 2020 11:48:03 PM GMT+03:00, satmandu ***@***.***> wrote: Whoops. The command I end up needing to run is ```sudo LD_LIBRARY_PATH=/opt/vc/lib /usr/bin/vcdbg set awb_mode 0``` I'm not seeing how to do that using ```vc-log``` though I can compile it just fine. -- You are receiving this because you were mentioned. Reply to this email directly or view it on GitHub: #67 (comment)

[satmandu]

Nevertheless, I can't get it to read the log on a RPI4:

pi@goat ~/src/rpi-vc-log$ sudo ./vc-log 
pread() failed: Invalid argument
Aborted
pi@goat ~/src/rpi-vc-log$ ls -aFl /dev/vc-mem
crw------- 1 root root 248, 0 Jul  1 16:17 /dev/vc-mem

[hvenev]

That's because you have checked out the latest commit, where it uses pread() instead of mmap(). The driver change hasn't been merged yet. On Pi4, you can try the previous commit (312af3705d02b198f09d6efa69c68ba1598fb721) instead. I think it should work.

…

On July 1, 2020 11:57:12 PM GMT+03:00, satmandu ***@***.***> wrote: Nevertheless, I can't get it to read the log on a RPI4: ``` ***@***.*** ~/src/rpi-vc-log$ sudo ./vc-log pread() failed: Invalid argument Aborted ***@***.*** ~/src/rpi-vc-log$ ls -aFl /dev/vc-mem crw------- 1 root root 248, 0 Jul 1 16:17 /dev/vc-mem ``` -- You are receiving this because you were mentioned. Reply to this email directly or view it on GitHub: #67 (comment)

[satmandu]

I think it should work.

Thanks that works splendidly for using vcdbg to get the log.

But I for instance need to run vcdbg set awb_mode 0 to get AWB turned off for my no-ir camera. vc-log doesn't seem to replicate that functionality from vcdbg for me yet, I think.

[hvenev]

Well, vc-log is what I managed to do in one evening of frustration and reverse engineering. vcdbg is a blob I don't want anywhere near me. I would appreciate help figuring out how to replicate the rest of its functionality.

…

On July 2, 2020 9:36:58 PM GMT+03:00, satmandu ***@***.***> wrote: > I think it should work. Thanks that works splendidly for using vcdbg to get the log. But I for instance need to run ```vcdbg set awb_mode 0``` to get AWB turned off for my no-ir camera. vc-log doesn't seem to replicate that functionality from vcdbg for me yet, I think. -- You are receiving this because you were mentioned. Reply to this email directly or view it on GitHub: #67 (comment)

[pelwell]

@satmandu Yes, of course - that wasn't obvious from your first few posts. I'll have a go at a static 64-bit build.

@hvenev You've already got all the tools for the vclog set <var> <value> in the form of vc_sym_find - the <var> is just a symbol in the list.

[pelwell]

Hmm, it's more than just a question of typing make - it's definitely not 64-bit clean.

Would a static 32-bit build of vcdbg be acceptable?

[satmandu]

@pelwell Any chance of having libraspberrypi0 packaged like the libc6-armhf-cross package such that the libraries in /opt/vc/lib end up in a standard location like /usr/arm-linux-gnueabihf/lib/? Since armhf binaries work fine in arm64 as long as the libraries are in the right place, this might be a cleaner way to deal with this in the near term until everything is made to compile properly on arm64?

As long as the libraries are in the right location, (and the right cross-libraries are installed, such as libgcc1-armhf-cross libstdc++6-armhf-cross libc6-armhf-cross, one can just use patchelf to force an rpath and interpreter for the vc* binaries as part of the packaging process.

sudo /opt/vc/bin/vcdbg
sudo: unable to execute /opt/vc/bin/vcdbg: No such file or directory
sudo patchelf --print-rpath   /opt/vc/bin/vcdbg

sudo patchelf --print-interpreter   /opt/vc/bin/vcdbg
/lib/ld-linux-armhf.so.3

sudo patchelf --force-rpath --set-rpath "/usr/arm-linux-gnueabihf/lib" /opt/vc/bin/vcdbg
sudo patchelf --set-interpreter /usr/arm-linux-gnueabihf/lib/ld-linux-armhf.so.3 /opt/vc/bin/vcdbg
sudo /opt/vc/bin/vcdbg
(lots of this)
debug_sym: vc_mem_copy: Unable to open '/dev/fb0': No such file or directory(2)
/opt/vc/bin/vcdbg - no command specified

[pelwell]

That's a larger task than I'm prepared to take on, as one that wouldn't naturally fall to me.

[satmandu]

And yes a static build would absolutely be acceptable.

[lurch]

I believe packaging comes under @XECDesign 's umbrella, and IIRC there was a decision to deliberately not ship cross-libraries by default in the 64-bit beta OS, in order to uncover exactly these kinds of issues 😉

[pelwell]

The fact that the utility is absent means this issue is already uncovered. Until the compilation and packaging has been sorted out, there's a static 32-bit build here: https://drive.google.com/file/d/1HS9E5vnxxNqrizB4mEYrnFoQQ1axSRKm/view?usp=sharing

[satmandu]

Thanks! Works perfectly.

…

On Thu, Jul 2, 2020 at 4:37 PM Phil Elwell ***@***.***> wrote: The fact that the utility is absent means this issue is already uncovered. Until the compilation and packaging has been sorted out, there's a static 32-bit build here: https://drive.google.com/file/d/1HS9E5vnxxNqrizB4mEYrnFoQQ1axSRKm/view?usp=sharing — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#67 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAILX7PEIGQE6O4RL4KTTA3RZTVX5ANCNFSM4ONUZQEQ> .

[acostach]

Hi, are there any plans to include the 32bit statically linked version in the firmware repository too, or is the gdrive link the only approved option for now, at least until packaging is sorted out?