Regression in raspberrypi-bootloader 20250305-1 breaks RPi3

[salfter]

Yesterday, I threw Arch onto a Raspberry Pi 3 (using aarch64) to put one of the UPSes at work on the network with NUT. I had it running like a champ and was getting ready to have it start controlling our servers. I then let it upgrade itself this morning with yay --noconfirm and rebooted. After the reboot, it disappeared from the network. When I brought it over to my desk to troubleshoot, it looks like uboot was updated. After the uboot screen goes away, the kernel starts loading...but Tux's bill and feet are a weird shade of blue instead of yellow. A few seconds later, the screen blanks and the monitor switches away. Attempts to ssh into the Pi, which worked before the upgrade, now time out. The DHCP server on our network isn't being asked for a lease.

It would appear that something in the past 24 hours has changed to break both HDMI and Ethernet on the Raspberry Pi 3. I just did another scratch install and upgrade, and got the same result. I'm going to try again, this time blocking upgrades to uboot-raspberrypi, linux-aarch64, and raspberrypi-bootloader to see if one of those is to blame.

[salfter]

System came up again...screen went away for a bit, but then came back. Can still ssh in. The console shows some kernel messages from i2c-bcm2835 (one "unexpected interrupt," two "i2c transfer timed out"s) that I don't recall seeing before. I'm now letting linux-aarch64 update.

[salfter]

Still running normally after upgrading the kernel, so we can rule that out. The messages from i2c-bcm2835 have gone away. Going to image the system in its current state before I try upgrading it further.

[salfter]

It looks like raspberrypi-bootloader was updated yesterday:

[url]https://github.com/archlinuxarm/PKGBUILDs/commit/cc8c0fa8e8a777e6fb6b27175df658887d71d158[/url]

I'd guess that there's a regression in there, but I haven't yet confirmed it. If I do, where would I report it? It looks like issue reporting at [url]https://github.com/archlinuxarm/PKGBUILDs[/url] has been disabled.

[salfter]

...and it's confirmed. Upgrading uboot-raspberrypi didn't break the system, but upgrading raspberrypi-bootloader did. I'll block upgrades on raspberrypi-bootloader in /etc/pacman.conf until this is sorted.

[solskogen]

Is there a reason why you don't use the linux-rpi kernel instead of linux-aarch64?

[graysky]

I do not have a RPi3 for testing. Can you please open an issue upstream:make_clickable_callback(MAGIC_URL_FULL, ' ', 'https://github.com/raspberrypi/firmware/issues', '', ' class="postlink"')

[salfter]

[quote="solskogen"]Is there a reason why you don't use the linux-rpi kernel instead of linux-aarch64?[/quote]

linux-aarch64 was the kernel pulled in when the system was set up, AFAIK.

[solskogen]

[quote="salfter"][quote="solskogen"]Is there a reason why you don't use the linux-rpi kernel instead of linux-aarch64?[/quote]

linux-aarch64 was the kernel pulled in when the system was set up, AFAIK.[/quote]

You are correct, and I find that a bit strange that that kernel is the default on the tarball. Try replace it with the linux-rpi kernel and see if that works.

[graysky]

RPi is not the only SoC support by Arch ARM so shipping the tarballs with the most compatible kernels is the strategy.