SPI0 bus corruption on Pi4 on linux 6.12.75 (and not on 6.12.47)

[craigerl]

Describe the bug

Using an ILI9486 gpio TFT display connected to SPI0 @48Meg baud, the screen is corrupted when using kernel 6.12.75, but works fine when using the older kernel 6.12.47 (regressed with rpi-update 6d1da66). Reducing baud rate to 32Meg masks the problem, but significantly reduces screen refresh rate.

Problem is not present on the Pi5.

Tried using 40bit dual dma buffers with "dtparam=spi_dma4" - no effect.

Stuck on 6.12.47, thanks, for the support!

-craig

Steps to reproduce the behaviour

Run direwatch.py https://github.com/craigerl/direwatch at 48meg baud, observe horizontal banding/color corruption on ili9486 display. Regress kernel, problem goes away. Specific to Pi4.

Device (s)

Raspberry Pi 4 Mod. B

System

pi@digipi:~ $ cat /etc/rpi-issue
Raspberry Pi reference 2023-10-10
Generated using pi-gen, https://github.com/RPi-Distro/pi-gen, fb56ad562991cf3ae5c96ab50983e1deeaefc7b6, stage2

pi@digipi:~ $ vcgencmd version
Aug 20 2025 17:02:45
Copyright (c) 2012 Broadcom
version cd866525580337c0aee4b25880e1f5f9f674fb24 (clean) (release) (start_cd)

6.12.75+rpt-rpi-v8

Logs

No response

Additional context

No response

[popcornmix]

Can you confirm that only the kernel version changed between the working and not-working cases?
i.e. both were using the same version of firmware?

The only changes between those versions are upstream, and there's nothing obvious changed relating to spi.

Can you test with:

force_turbo=1

in config.txt?

[craigerl]

Hi popcornmix - you're omnipresent here!! thanks for the help.

I did nothing more than run "rpi-update 6d1da66" and the problem was resolved, no other changes. I don't know exactly what that does other than drop the kernel from .75 to .47.

force_turbo=1 fixed it!

I don't want to trouble you, but is there a big backstory there? Is that a long term fix, should force_tubo be in [all] or just in [pi4] section. This was observed on more than one pi4 and .75 kernel, at different locations. Again, Pi5 is just fine with .75. I need to test 3B+, Zero2W.

thank you again!

-craig

[craigerl]

just doing a little research force_turbo might not be a long-term fix, with no cpu frequency scaling, so i'm open to ideas - thanks again!
craig

[popcornmix]

No, force_turbo is not the fix - just a test to see if the issue is related to core clock frequency (which is the parent of the spi clock).

rpi-update switches the kernel and firmware by default.
"Aug 20 2025 17:02:45" is the firmware you got from 6d1da66.
I believe bookworm is on "May 21 2026"

Perhaps the easiest was to bump the firmware back to expected version (but leave kernel at 6.12.47) is to run:

sudo SKIP_KERNEL=1  rpi-update 5208a0129

After a reboot, report uname -a and vcgencmd version to confirm you are where we want to be, and report if SPI is good/bad.

[craigerl]

Hi Popcornmix,

Unfortunately there's still spi0 corruption with the downgraded firmware

pi@digipi7:/boot/firmware $ uname -a
Linux digipi7 6.12.75+rpt-rpi-v8 #1 SMP PREEMPT Debian 1:6.12.75-1+rpt1 (2026-03-11) aarch64 GNU/Linux

pi@digipi7:/boot/firmware $ vcgencmd version
May 21 2026 11:20:39
Copyright (c) 2012 Broadcom
version 288930ab4712b99596f32732664aaaeb881ef1e0 (clean) (release) (start_cd)

I don't know if it helps, but this is an example of the spi0 corruption on pi4 with 6.12.75 at 48M baud.

So far, it is fully resolved with force_turbo, or reducing to 32M baud, or rpi-update 6d1da66 (kernel 6.12.47), or switching to pi5.

For the moment, this user community is stuck on 6.12.47 (digipi.org project, with ~6000 users).

I'll keep looking, and I'm fully open to suggestions - thanks for the great support, and not just for this!

best,
-craig

[popcornmix]

Unfortunately there's still spi0 corruption with the downgraded firmware

technically that's "restored" firmware (i.e. the default version of bookworm).
That's a useful result though - it rules out the firmware as the cause of the regression.

I'll see if anyone in the office has a device that may reproduce this issue.

[craigerl]

Great - thanks. fwiw, this is "trixie" on armhf userspace.

[pelwell]

What does that screen look like when not corrupted?

[popcornmix]

Great - thanks. fwiw, this is "trixie" on armhf userspace.

trixie should be using 6.18 kernel by default. Do you have the issue with the 6.18 kernel?

[craigerl]

What does that screen look like when not corrupted?

Good question - the house shouldn't have horizontal banding, the text should be solid colors.

[craigerl]

I didn't realize we made the leap to 6.18 on trixie thanks. I just dist-upgraded from 6.12.47 Pi4 (which was working) and now it's not working (spi0 corrupted screen):

pi@digipi:~ $ uname -a
Linux digipi 6.18.34+rpt-rpi-v8 #1 SMP PREEMPT Debian 1:6.18.34-1+rpt1 (2026-06-09) aarch64 GNU/Linux

pi@digipi:~ $ vcgencmd version
May 21 2026 11:20:39
Copyright (c) 2012 Broadcom
version 288930ab4712b99596f32732664aaaeb881ef1e0 (clean) (release) (start_cd)

pi@digipi:~ $ cat /etc/*release
PRETTY_NAME="Raspbian GNU/Linux 13 (trixie)"

pi@digipi:~ $ cat /proc/cpuinfo | grep Model | cut -d: -f 2
Raspberry Pi 4 Model B Rev 1.5

pi@digipi:~ $ file /usr/bin/ls #32bit user space so i can fit in 512MB
/usr/bin/ls: ELF 32-bit LSB executable,

[craigerl]

and just to be sure, 6.12.47 regression fixes it,

sudo rpi-update 6d1da66 #(regress to 6.12.47 on pi4),

[craigerl]

Replicated on Pi Zero2W, though, corruption is not as severe.

also resolved by reducing baud from 48M to 32M (prohibitively slow refresh in my case), or downgrading kernel to 6.12.47 (6d1da66)

pi@digipi:~ $ vcgencmd version
Feb 11 2026 18:31:52
Copyright (c) 2012 Broadcom
version ce768004a1c9657e60b33b0cc413d8e07320cb0d (clean) (release) (start_cd)

Linux digipi 6.12.75+rpt-rpi-v7

[popcornmix]

I've borrowed an SPI display from a colleague (I believe ILI9486 comaptible).

But I can't reproduce. Both old kernel and latest seem to be clean at 48MHz but show mild corruption at 64MHz (not the banding you see but a coloured speckles at edges of difference colours).

Note, as SPI takes an even divisder from core clock, it can't actually get 48MHz (it will get 500/12=41.666MHz)

Can you post your config.txt in case you have any non-default options in there that affect the clock?

[pelwell]

coloured speckles at edges of difference colours

I should have asked if the corruption you see is static/stable or more like flickering or speckles - how would you describe it?