Remove bcm_host dependency

[ryandrake08]

Summary

Remove dependency on bcm_host library (libraspberrypi-dev) for VideoCore GPU FFT builds.

Problem

The libraspberrypi-dev package came from the raspberrypi/userland repository, which is now archived and marked as "ancient and deprecated." The package is not available in Trixie and is being phased out on Bookworm through package replacement. The libraspberrypi-dev package provided the bcm_host library. With it gone, builds with PLATFORM=rpiv2 will fail on recent Raspberry Pi OS distributions because gpu_fft_base.c depends on:

• bcm_host_get_peripheral_address()
• bcm_host_get_peripheral_size()
• bcm_host_get_sdram_address()

Solution

Query the board revision directly via the VideoCore mailbox interface (which is already used by gpu_fft for other purposes), and derive the peripheral address and memory flags from the processor type encoded in the revision bits.

I also considered an alternative approach using the device tree (/proc/device-tree/soc/ranges) to obtain the peripheral address, available in the remove-bcm-host-device-tree branch. I chose the mailbox approach because it fits better with the existing gpu_fft code.

Alternatives

If this change is not desired, users can work around the issue by building and installing bcm-host-shim, which provides stub implementations of the required bcm_host functions.

Testing

Tested on Raspberry Pi 2 Model B Rev 1.1 running Raspberry Pi OS Trixie.

[gabeschine]

Overall LG, although I cannot test as I don't have any RPI-2 hardware. Does anyone else who happens to be watching this PR have the ability to test?

[ryandrake08]

Thanks for the quick review. No hurry on merging. I did this change to solve my own problem, and it's only useful to people who are running the latest and greatest rpi operating systems. If it's helpful to others, that's great. If there is a way I can help with the CI checks above, I'm happy to look into it. I don't really use docker or containers so I hope I didn't break anything in those deployments.

[SullivanChrisJ]

I have a Pi3B, 2B and 1B (if it still works, I need to reinstall a filter capacitor) and can test them all with the revised code for which I've cloned. It's on the top of my pile which means a week or so to test it all. Lower down in the pile is adding milli/microsecond timestamps on the file names and preroll on the raw files (looking for transmitter fingerprints) so I'd like to know more about running the checks.

Chris

[charlie-foxtrot]

@ryandrake08 thanks for the PR. Should this be backwards compatible with early Bookworm (before the phase out) or Bullseye and earlier?

If not, it will need to be marked as a breaking change.

[ryandrake08]

Honestly, I don't know because my pi is running trixie. I can look around and see if I have another pi 2 or 3 laying around that I can install older operating systems on and test it out. The change itself removes a dependency, and doesn't add any, so it -should- be backwards compatible, but I can't guarantee it since I haven't tested it on an older OS.

The biggest risk is that the CMake logic is incorrect or won't work on bookworm and earlier. Let me see if I can either find a spare pi, or maybe I can use QEMU to emulate one just to test out compilation.

EDIT: For what it's worth, I installed raspbian Bookworm, Bullseye, and Buster into chroot containers and successfully built the software using -DPLATFORM=rpiv2 and encountered no build problems, with or without libraspberrypi-dev installed.

[charlie-foxtrot]

Awesome, thanks for checking. I'm going to get some hardware setup as GitHub runners in various combinations, and once that's running / passing I'll look to merge this PR