If you imagine the BCM2xxx chip as a typical Integrated Circuit
(much like any IC chip often used for peripheral hardware), then you
will understand that the BCM2835 library accesses the GPIO pins by
interacting with the BCM2xxx
chip's internal registers. CPU registers are a property used to make any type of processor, including peripheral IC chips. Prior to RPi5, this approach was possible because the
GPIO pins were connected directly to the CPU.
With
the RPi5, the GPIO pins are no longer directly connected to the CPU
(BCM2712 on RPi5). Instead, they are abstracted via a new RP1 chip (a
custom IC chip) that is connected to the BCM2712 through a PCI-express
port. This is why adapting the BCM2835 library to support the RPi5 is a
lot of work. And, adding such hardware support will likely result in an incompatibility with
older RPi models
or prove nearly impossible to maintain backward compatibility (given that the BCM2835 library is ultimately maintained by 1 person with no promise of financial reimbursement).
It
is not just a matter of hardware compatibility and having enough
motivated developers. It is more of a concern with library design vs
hardware schematics. The BCM2835 library simply wasn't designed to work
with the newer hardware schematics of RPi5 (& likely newer RPi
models in the future).
There is a long history of why the implementation in libraries like
RPi.GPIO (for python users), PiGPIO, BCM2835, and WiringPi are not the
best approach. In the past, the Linux kernel's GPIO interface was
woefully inadequate to satisfy the needs of the maker community. But
this has changed as of Linux kernel v4.8 (back in 2016). And, the
workaround implementations in most popular libraries were really just
well-coded hacks to circumvent or augment the Linux kernel. Such
implementations can pose a physical threat to users' hardware. Simply
put, if you're using `sudo` to interact with hardware, then the
OS/hardware wasn't designed well enough to be utilized by end-users.