Rasberry Pi 5 support?

[huntercaron]

I recently got a Pi5 and was hoping to set up these panels I have, but don't seem to be getting any LEDs to light up whatsoever.

I'm trying with a single 64x64 1/32 panel with a ICN2037BP chipset, connected directly via jumper cables. (This Panel).

• I've hooked up the E pin
• I've tried led-slowdown-gipio=4

I've powered the panel ok with a Pico so the Panel is fine (but had slow perf so now im here)

From what I’ve read in the issues here, it should be working pretty smoothly. So I am starting to think its something with the Pi5? Happy to give more info here, just not sure what would be helpful

[hzeller]

I have not have adapted the library yet to work with Pi5. Since there were always additions needed with every new Pi, as each GPIO is different, it is no surprise that the new one is not working yet.

Good news: I got a Pi5 so I can work on that.
But bad news: I don't know yet when I'll have time to adapt the library, might be probably around the end of the year. So if you have, use an older Pi for now.

[huntercaron]

Ah makes sense! Thank you for the quick response.

I think I have an older Pi somewhere I will dig up in the meantime. Please let me know if you need any help testing.

[huntercaron]

Update: All is working well with Pi4B for now

[babsher]

@hzeller I am also interested in Pi5 support. Is this in the works still?

[Primek17]

Hi @hzeller. Is there a chance to launch the library on PI5 this month? :)

[hzeller]

I'll try. I am doing this in my spare time, and end-of-year is of course always busy.
But I might have a day or two in the holidays.

[imCharlieB]

Any updates on the pi5 support?

[bsparacino]

I am trying to adapt the code to get the Pi 5 to work but am struggling, maybe someone smarter can figure it out.
I simply followed the process for how other models of the Pi are detected.
The thing I seem to be struggling with is the value for BCM2712_PERI_BASE.

It's possible the Pi 5 drastically changed how its offsets worked, but I can't seem to find a datasheet on the BCM2712 and even if I did, I would still be too confused to know what to do.

My code is here:
master...bsparacino:rpi-rgb-led-matrix:master

[davemaster]

I will try tomorrow just as I do with a RPi 4

[imCharlieB]

i found this little bit of info browsing cant rem what site i saved it in a note so i could look at it later...

The Pi 5 has a huge peripheral area starting at 0x40000000. This is the physical address which is translated to 0x1f00000000 in the 40-bit address space. The /dev/mem file can be used in the usual way but you have to be running with root privileges. The /dev/gpiomem0 file only maps the GPIO area starting at 0x400d0000, or 0x1f000d0000, but it doesn’t need root privileges. In the examples that follow, the mem file is used with root privileges because it works with peripherals other than the GPIO lines.

To access the GPIO area of memory you can map the entire peripherals area into user space using:

int memfd = open("/dev/mem", O_RDWR | O_SYNC);
uint32_t *map = (uint32_t )mmap(
NULL,
64 * 1024 1024,
(PROT_READ | PROT_WRITE),
MAP_SHARED,
memfd,
0x1f00000000
);
if (map == MAP_FAILED)
{
printf("mmap failed: %s\n", strerror(errno));
return (-1);
};
close(memfd);

This maps the entire 64MByte area – if you only want to use the GPIO lines then you can make this smaller, but there is no problem accommodating it in the 4,096MByte, 32-bit address space.

Once you have the address of the peripheral area you can access the registers that control them using offsets from the hardware-specified base address. For example, the GPIO control registers have an address of 0x400d0000, which gives an offset of 0xd0000. As the pointers are to uint32_t we have to remember to divide by 4 so that the correct offset is added. That is, the GPIO registers are located at:

uint32_t *PERIBase = map;
uint32_t *GPIOBase = PERIBase + 0xd0000 / 4;

[IsaacMAllen]

i found this little bit of info browsing cant rem what site i saved it in a note so i could look at it later...

The Pi 5 has a huge peripheral area starting at 0x40000000. This is the physical address which is translated to 0x1f00000000 in the 40-bit address space. The /dev/mem file can be used in the usual way but you have to be running with root privileges. The /dev/gpiomem0 file only maps the GPIO area starting at 0x400d0000, or 0x1f000d0000, but it doesn’t need root privileges. In the examples that follow, the mem file is used with root privileges because it works with peripherals other than the GPIO lines.

To access the GPIO area of memory you can map the entire peripherals area into user space using:

int memfd = open("/dev/mem", O_RDWR | O_SYNC); uint32_t *map = (uint32_t )mmap( NULL, 64 * 1024 1024, (PROT_READ | PROT_WRITE), MAP_SHARED, memfd, 0x1f00000000 ); if (map == MAP_FAILED) { printf("mmap failed: %s\n", strerror(errno)); return (-1); }; close(memfd);

This maps the entire 64MByte area – if you only want to use the GPIO lines then you can make this smaller, but there is no problem accommodating it in the 4,096MByte, 32-bit address space.

Once you have the address of the peripheral area you can access the registers that control them using offsets from the hardware-specified base address. For example, the GPIO control registers have an address of 0x400d0000, which gives an offset of 0xd0000. As the pointers are to uint32_t we have to remember to divide by 4 so that the correct offset is added. That is, the GPIO registers are located at:

uint32_t *PERIBase = map;
uint32_t *GPIOBase = PERIBase + 0xd0000 / 4;

Here's the link:
https://www.i-programmer.info/programming/148-hardware/16887-raspberry-pi-iot-in-c-pi-5-memory-mapped-gpio.html

[DJEF97]

Hi @hzeller. Is there a chance to launch the library on PI5 this month? :)

[bsparacino]

IsaacMAllen
I'm still not having luck trying this.
I am also not 100% sure what to do with this info

uint32_t *PERIBase = map;
uint32_t *GPIOBase = PERIBase + 0xd0000 / 4;

[JimM58]

Ok, I just got a pi5 running bookworm, and trying to run some apps on it. In this case, the adafruit-circuitpython-rgb-display stuff

And I get this

pi@pi5:~/ciq-common $ python3 tfteco.py
Traceback (most recent call last):
File "/home/pi/ciq-common/tfteco.py", line 209, in
cs_pin = digitalio.DigitalInOut(board.CE0)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/usr/local/lib/python3.11/dist-packages/digitalio.py", line 185, in init
self.direction = Direction.INPUT
^^^^^^^^^^^^^^
File "/usr/local/lib/python3.11/dist-packages/digitalio.py", line 215, in direction
self._pin.init(mode=Pin.IN)
File "/usr/local/lib/python3.11/dist-packages/adafruit_blinka/microcontroller/generic_linux/libgpiod/libgpiod_pin_1_x.py", line 92, in init
self._line.request(
OSError: [Errno 16] Device or resource busy

It runs fine on all earlier pi devices.

Here's what I have on the pi 5 as far as adadfruit packages:

Package Version

---

Adafruit-Blinka 8.32.0
adafruit-circuitpython-bme280 2.6.24
adafruit-circuitpython-busdevice 5.2.6
adafruit-circuitpython-requests 2.0.5
adafruit-circuitpython-rgb-display 3.11.3
adafruit-circuitpython-typing 1.10.0
Adafruit-PlatformDetect 3.60.0
Adafruit-PureIO 1.1.11

[hannescam]

IsaacMAllen I'm still not having luck trying this. I am also not 100% sure what to do with this info

uint32_t *PERIBase = map;
uint32_t *GPIOBase = PERIBase + 0xd0000 / 4;

Do you have any progress with the Raspberry Pi 5 support?
Maybe this will help: opi-rockchip-3b-rgb-led-matrix

[bsparacino]

No luck yet and I'm too busy with normal work this time of year to work on this.
That repo seems to add support for the Orange Pi 3B which doesn't help in this situation.

[0xe1f]

Same as all others - unable to run on Pi 5:

mmap error: : Invalid argument
MMapping from base 0x3f000000, offset 0x3000
mmap error: : Invalid argument
MMapping from base 0x3f000000, offset 0x101000
Need root. You are configured to use the hardware pulse generator for smooth color
rendering, however the necessary hardware registers can't be accessed because you
probably don't run with root permissions or privileges have been dropped.
So you either have to run as root (e.g. using sudo) or supply the
--led-no-hardware-pulse command-line flag.
Exiting; run as root or with --led-no-hardware-pulse

I am running as root. --led-no-hardware-pulse doesn't seem to affect anything (though the message does go away)

[MikeDaBird]

Bumping this. Currently working on a project utilizing chained Adafruit 64x32 matrices, but so far cannot get a display on one using Pi 5. It could be my current power situation, but I feel like the compatibility thing could also be a culprit. It's weird (and kind of misleading) that Adafruit's description and docs on their Bonnet HAT say they support "any Raspberry Pi with a 40-pin GPIO header" and explicitly list Pi 5 in the description, yet they list the use of this library which does not support Pi 5 :/ (supporting this: their installer wrote the dtparam=audio=off line for the Quality option in the old config.txt location prior to Bookworm OS, which Pi 5 requires)

I did get a Pi 3 as a backup and haven't tested the bonnet on it yet, but it can barely run what I need it to run, so preferably would use the Pi 5 once possible unless I can figure out how to optimize my software even more.

Pretty new to Pi, so I'm unable to really troubleshoot except through a lot of Google searching. Hopefully you can manage to find time to figure out support for it!

UPDATE: Either I didn't notice it before or they just updated it, but the docs now note above the command to start the Adafruit installer that this library does not work for Pi 5 and Pi 400. However the store page still says that Pi 5 is supported, which is false unless they made their own internal library for testing and never released it. In the hope someone figures it out tho, at least my project will likely work with Pi 3

[AbrahamChalita]

Hello! Has anyone had any luck with the Pi 5 support?

[Vizzyy]

I also ran into the above output @0xe1f mentioned above with a new rpi5.

I dug out an older rpi3 I have, slapped on the hat, swapped the SD cards and my 64x32 matrix worked instantly with the demo script.

It's unfortunate that as @MikeDaBird noted the Adafruit website explicitly lists support with rpi5, but we're not quite there yet.

[ladyada]

oops sorry about that, it was a copy-paste typo (since almost all of our HATs do work with the Pi 5) - if you cant use it email support@adafruit for a refund :)

[MikeDaBird]

Heya, thanks for acknowledging and fixing the description. I did get a Pi 3 for backup as mentioned above so I can still work on my project. Did get both my Pi 3 and 5 from the Adafruit website in the same order, and will keep both in the mindset that Pi 5 support will eventually be complete (with that big graphics improvement it would be really nice to have support for it). Besides, I can experiment with other things using my spare Pi ^^

[ignaciogaticarojas]

upgrading this program to work also with raspberry pi 5 would be an amazing option for it! hopefully @hzeller would have some time to work on it . Will keep an eye on this thread

[ElBertrando]

@hzeller I just got a bunch of Pi5's and have my program ready to load ! Do we have an ETA ?

[sawsaw382]

Can I add to the above, very keen to get Pi5 compatibility enabled.

[hzeller]

I've reserved a bit of time this weekend to work on it.

[bsparacino]

@hzeller
This is as far as I was able to get on it, it may save you a little work
master...bsparacino:rpi-rgb-led-matrix:master

[Speedy-VI]

I have not had any luck finding P2 128x64 panels that use LED driver chips that will work with the Matrix Portal S3. I'm not saying it's impossible, but I have only had success with lower-density panels that use ICN2037, FM6124, or RUL2038S driver chips. It seems that to control panels with more complex driver chips, I need a Raspberry Pi. I was about to take the plunge and order a Pi 4 B but the Pi 5 is only $5 more. If there is one thing I have learned from buying LED panels on Ali Express, it's patience! Fingers crossed that support for the Pi 5 is coming soon.

[hzeller]

Update on the Pi 5 exploration

I did get the memory mapping and parallel output on the GPIO pins to work in my local experiments, so the first hurdle is taken. However, it is slower than other recent Raspberry Pi models.

The GPIO handling is very different on the Pi5 compared to the earlier models. Previously, it was handled directly from the SoC, now the Pi5 handles that with a separate chip that is connected via the PCIe system bus. Due to that, it can't reach the same performance.

There are still are few more hardware things to figure out (in particular hardware timers and routing them to GPIO) before rpi-rgb-led-matrix can be updated. Unfortunately, the documentation by Raspberry is in parts very incomplete, so I have to fish out relevant information from sources on the raspberrypi github as well as the Linux kernel. This might take a while.

What I can say: output will probably not reach higher frame-rates (and likely be lower) than with a Pi 4 or Pi 3, so if you want to use this library, I don't currently recommend hoping for the Pi5 to be faster once support has been added. Get a Pi4 for now.

[0xe1f]

Thanks for taking the time to look into it. I ultimately decided to use multiple Pi4's, and am able to drive 320x128 just on a single Pi4.

[Speedy-VI]

@hzeller
Thanks for the update. I was surprised to learn that the Pi 5 will likely be slower than a Pi 4 due to offloading GPIO to the RP1 southbridge chip. I think I will order a Pi 4 Model B.

Newbie Question - I did not see anything in the README about RAM requirements. The Pi 4B is available with up to 8-Gig of RAM. Will more RAM make any difference when using a Pi 4B and this library to drive LED panels?

[hzeller]

send a PR

[primaltechguides]

Would this be relevant to the implementation?
From the WiringPi repositiory

https://github.com/WiringPi/WiringPi

Pi5 full PWM support
WiringPi/WiringPi@f2b23cf

[Krasnomakov]

Update on the Pi 5 exploration

I did get the memory mapping and parallel output on the GPIO pins to work in my local experiments, so the first hurdle is taken. However, it is slower than other recent Raspberry Pi models.

The GPIO handling is very different on the Pi5 compared to the earlier models. Previously, it was handled directly from the SoC, now the Pi5 handles that with a separate chip that is connected via the PCIe system bus. Due to that, it can't reach the same performance.

There are still are few more hardware things to figure out (in particular hardware timers and routing them to GPIO) before rpi-rgb-led-matrix can be updated. Unfortunately, the documentation by Raspberry is in parts very incomplete, so I have to fish out relevant information from sources on the raspberrypi github as well as the Linux kernel. This might take a while.

What I can say: output will probably not reach higher frame-rates (and likely be lower) than with a Pi 4 or Pi 3, so if you want to use this library, I don't currently recommend hoping for the Pi5 to be faster once support has been added. Get a Pi4 for now.

Hello, are there any updates? Info on what is possible now?

[davemaster]

Update on the Pi 5 exploration

I did get the memory mapping and parallel output on the GPIO pins to work in my local experiments, so the first hurdle is taken. However, it is slower than other recent Raspberry Pi models.
The GPIO handling is very different on the Pi5 compared to the earlier models. Previously, it was handled directly from the SoC, now the Pi5 handles that with a separate chip that is connected via the PCIe system bus. Due to that, it can't reach the same performance.
There are still are few more hardware things to figure out (in particular hardware timers and routing them to GPIO) before rpi-rgb-led-matrix can be updated. Unfortunately, the documentation by Raspberry is in parts very incomplete, so I have to fish out relevant information from sources on the raspberrypi github as well as the Linux kernel. This might take a while.
What I can say: output will probably not reach higher frame-rates (and likely be lower) than with a Pi 4 or Pi 3, so if you want to use this library, I don't currently recommend hoping for the Pi5 to be faster once support has been added. Get a Pi4 for now.

Hello, are there any updates? Info on what is possible now?

May be that, it's a GOOD THING, I imagine that GPIO "section" now can refresh data to panel(s) meanwhile the main "section" of the SBC can manage other matters, or am I wrong?

Thanks for your research

[bitslip6]

PI5 support for HUB75 is available here with GPU rendering (not for GPIO, just frame buffer rendering using fragment shaders with some support for shadertoy.com)
The implementation is a bit different than this library, but it should have enough info to port to rpi-rgb-led-matrix if someone is inclined. It ONLY supports Pi5 as I still need to track down the GPIO mmap addresses for pi4 and pi3. but that should be complete when I get back from a canyoning trip to Zion in a couple weeks.

refresh rate is 9600Hz / number chained panels. So 4 chained panels has a refresh of 2400Hz. The library also supports up to 64 bits of PWM data (64 color levels for each RGB) or 262144 colors and has no limit on max frame rate refresh. converting 24bpp RGB frame data to PWM bit masks is about 600 microseconds per 64x64 panel and uses the PI's 128 bit SIMD instructions, but this could be offloaded to multiple threads allowing frame rates well over 600fps, but in practice, 120fps looks very smooth on my displays.

Flicker-free video recording from your phone as well. Clock rate is fixed at 20Mhz and consumes 100% of 1 CPU core.

https://github.com/bitslip6/rpi-gpu-hub75-matrix

[ydixken]

Also struggled with this a lot, before I found this bug. Support would be highly appreciated!

[bitslip6]

@ydixken
This library is similar with pi5 support. drop an issue here and I'll take a look: https://github.com/bitslip6/rpi-gpu-hub75-matrix/issues

[ydixken]

@bitslip6 Thanks, just tried it out, can't get it to build on a fresh OS.

[christerdk]

Update on the Pi 5 exploration

I did get the memory mapping and parallel output on the GPIO pins to work in my local experiments, so the first hurdle is taken. However, it is slower than other recent Raspberry Pi models.

...

Any updates on this?

[Robyn-bot]

I also ran into the above output @0xe1f mentioned above with a new rpi5.

I also ran into the same issue, does the library now work with @hzeller updating the library? It's unclear to me whether I should be able to solve this issue, or if it is due to incompatability?

sudo python simple_square.py
mmap error: : Invalid argument
MMapping from base 0x3f000000, offset 0x3000
mmap error: : Invalid argument
MMapping from base 0x3f000000, offset 0x101000
Suggestion: to slightly improve display update, add
	isolcpus=3
at the end of /boot/cmdline.txt and reboot (see README.md)
Need root. You are configured to use the hardware pulse generator for
	smooth color rendering, however the necessary hardware
	registers can't be accessed because you probably don't run
	with root permissions or privileges have been dropped.
	So you either have to run as root (e.g. using sudo) or
	supply the --led-no-hardware-pulse command-line flag.

	Exiting; run as root or with --led-no-hardware-pulse

[marcmerlin]

@Robyn-bot Henner has not had the time/resources to work on this.
Between you and me, a Pi4 is cheaper and already works faster than you can output 3 channels, so you need to slow it down.
There is no reason to use a Pi5 or great pressing need to make this lib on an even faster and more expensive board just that it can be slowed down even more not to overwhelm the panels with too much I/O speed.

[marcobrianza]

hello, I have been a long time user of this software, and today after this blog post https://blog.adafruit.com/2024/12/26/driving-hub75-rgb-matrices-on-raspi-5-with-pio/
I came here to check pi5 support. maybe Adafruit work can be beneficial :-) ciao!

[marcmerlin]

@marcobrianza The adafruit HUB75 support has always been super basic. It's cool that someone hacked something on Pi5, but that work doesn't translate in any way to this lib. This lib would have to be seriously adapted to the new hardware on Pi5 and last I talked to @hzeller just a month ago, he had no plans to work on it at this time, since he has no personal need.
I will also add again that a Pi4 is already faster than needed for 3 channels at speeds faster than the panels can accept, so using a Pi5 is just paying more money for faster hardware that has to be slowed down even more, and with software support that does not exist as of today.
So again, the question is why?
If you find it fun to port it, because why not, please do so and contribute back.
If you are expecting existing users to have enough of a need for this to spend their time to do it, I'd say the odds are low since as I said again Pi4 is cheaper, already too fast, and works today.

[marcobrianza]

why?
for my experience on pi4 with all the recommended optimisation the system is often on the edge to glitch if using the board for simultaneous tasks. (for this reason I have mostly switched to colorlight cards driven by fpp)
I expect that the Pi5 using the pio external chip could optimise led driving decoupled from the cpus
From what I understand current achievements of Adafuits are due to a recent raspberry pi releasing some examples previously unavailable.

[marcmerlin]

@marcobrianza fair enough.
Note that glitches are due to linux not being real time (although apparently real time was just merged into upstream kernels very recently) and therefore any GPIO bit banging can be glitchy indeed, no matter how fast the CPU is (i.e. it will be mostly the same on RPI5 as long as the code is using the CPU to push bits).
Trust me, I know, I have very fast many core CPUs computers doing some bit banging for some old protocols, and they routinely have issues when the system is too busy/stuck with IO and the other threads are blocked.
The only way to make this totally glitch free would indeed be to write some full DMA driver using some dedicated IO pins, which may exist on Pi5, but that would indeed be a new driver backend to write from scratch.
As you already pointed out, if you need perfect forever glitch free output, FPGA boards are indeed the way to go

[bitslip6]

@marcobrianza The adafruit HUB75 support has always been super basic. It's cool that someone hacked something on Pi5, but that work doesn't translate in any way to this lib. This lib would have to be seriously adapted to the new hardware on Pi5 and last I talked to @hzeller just a month ago, he had no plans to work on it at this time, since he has no personal need.
I will also add again that a Pi4 is already faster than needed for 3 channels at speeds faster than the panels can accept, so using a Pi5 is just paying more money for faster hardware that has to be slowed down even more, and with software support that does not exist as of today.
So again, the question is why?
If you find it fun to port it, because why not, please do so and contribute back.
If you are expecting existing users to have enough of a need for this to spend their time to do it, I'd say the odds are low since as I said again Pi4 is cheaper, already too fast, and works today.

This is incorrect. The reason that the delays need to be added is not for the hub75 panels but because the horribly rounded edges on the rpi 4 "square" wave form. This is a hardware limitation on thr pi4 not on thr panels themselves whixh you can see are driven beautifully by better hardware. There is pi5 support on another library in this thread with 10x performance (20Mhz, vs 2Mhz on rp4). Piolib could theorirtically push this to 70Mhz.

[ValentinR06]

Is there any Update on the Raspberry Pi5 support?

[ladyada]

we have a separate project to add HUB75 via PIO to Pi 5 https://github.com/adafruit/Adafruit_Blinka_Raspberry_Pi5_Piomatter
its not documented yet but it does work

[marcmerlin]

Thanks @ladyada , much appreciated.
@bitslip6 thanks for correcting my understanding on maximum speed limits. It's good to know that we could output at a higher speed if the square waveform were more square.
@ladyada , is the rPi5 port using IO hardware that is more precise and more square, like an FPGA output?

[ladyada]

yes PIO is a high speed peripheral, it does something like 150 FPS and does not require a core since the IO toggles is handled by the external chip

[marcmerlin]

This is great news, thank you @ladyada . As for IO pins available, how many channels can be controlled by those new PIO pins, and how many are currently supported by the driver you mentioned? (looks like one, but just checking).
Reason I ask is that if it's just one channel, I'm going to guess that for a big display, it may still be faster with an rPi4 and 3 channels than an rPi5 and one channel (which would divide bandwidth by 3 and add additional issues with clock mis-sync on long bus wiring)

[ladyada]

pretty sure you could just use another PIO state machine for another panel. we havent tried or inplemented it, if someone wants to look into it.

…

On Thu, Jan 30, 2025 at 1:32 PM Marc MERLIN ***@***.***> wrote: This is great news, thank you @ladyada <https://github.com/ladyada> . As for IO pins available, how many channels can be controlled by those new PIO pins, and how many are currently supported by the driver you mentioned? (looks like one, but just checking). Reason I ask is that if it's just one channel, I'm going to guess that for a big display, it may still be faster with an rPi4 and 3 channels than an rPi5 and one channel (which would divide bandwidth by 3 and add additional issues with clock mis-sync on long bus wiring) — Reply to this email directly, view it on GitHub <#1603 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAJINUIMZAFVUKMWUU42DZT2NJV3ZAVCNFSM6AAAAAA7O2R4LSVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDMMRVGI3TENZSHA> . You are receiving this because you were mentioned.Message ID: ***@***.***>