name: Bug report
about: Early I²C traffic on GPIO 0/1 with Bookworm firmware despite force_eeprom_read=0

Is this the right place for my bug report?
Yes. The issue is in the closed-source GPU firmware (start4.elf) used during early boot on Raspberry Pi CM4, before the kernel starts. It concerns behaviour of the early HAT EEPROM probe.

Describe the bug
On Compute Module 4 hardware with Raspberry Pi OS Bookworm firmware, early I²C traffic is observed on GPIO 0 and GPIO 1 (I²C0) immediately after power-on, before the Linux kernel starts, even with force_eeprom_read=0 set in config.txt.

This traffic consists of write accesses to addresses 0x50, 0x51, ff followed by a read from 0x51, all NACKed (no device present). The same hardware, same config.txt, and same bootloader EEPROM but with Bullseye firmware (start4.elf / fixup4.dat from Bullseye) shows no traffic on these pins.

Why does this bother me?
On my carrier board, I have connected an IC to GPIO 0-3 via SPI, but the interface is not currently needed. The Raspi GPIO 0-3 should therefore function as inputs. The I2C traffic on pins 0 and 1 causes the IC to crash during bootup.

To reproduce

1. CM4 with custom carrier board (GPIO0/1 unused, I²C1 used on GPIO44/45).
2. Install Raspberry Pi OS Bookworm with current stable firmware from repo.
3. In /boot/firmware/config.txt add at the end:

   [all]
   force_eeprom_read=0
   gpio=0-3=ip,pn
   disable_poe_fan=1

4. Cold power-on (not just reboot).
5. Monitor GPIO0/1 with logic analyser.

Expected behaviour
No I²C transactions on GPIO0/1 at any stage of boot when force_eeprom_read=0 and i2c_vc=off are set.

Actual behaviour
With Bookworm firmware:

• ~X ms after power-on: write to 0x50 (W), write to 0x51 (W), read from 0x51 (R), all NACKed.
• Occurs before kernel log output, so originates from firmware stage.
• Pins are later configured as inputs with no pull, as expected.
  With Bullseye firmware (start4.elf / fixup4.dat copied from Bullseye image):
• No I²C transactions at any point.
  System
  Copy and paste the results of the raspinfo command in to this section. Alternatively, copy and paste a pastebin link, or add answers to the following questions:

• Which model of Raspberry Pi? e.g. Pi3B+, PiZeroW
• Which OS and version (cat /etc/rpi-issue)?
• Which firmware version (vcgencmd version)?
• Which kernel version (uname -a)?

Logs
If applicable, add the relevant output from dmesg or similar.

Additional context
Add any other relevant context for the problem.

• Model: Raspberry Pi Compute Module 4
• OS: Raspberry Pi OS Bookworm (2025-08 image)
• /etc/rpi-issue: Raspberry Pi reference 2025-05-13
  Generated using pi-gen, https://github.com/RPi-Distro/pi-gen, f548f25325e28bea61904f5038a9b9fd0c92b07b, stage4
• Firmware version (Bookworm): Apr 30 2025 13:33:39
  Copyright (c) 2012 Broadcom
  version 5560078dcc8591a00f57b9068d13e5544aeef3aa (clean) (release) (start)
• Firmware version (Bootloader EEPROM): 2023/01/11 17:40:52
  version 8ba17717fbcedd4c3b6d4bce7e50c7af4155cba9 (release)
  timestamp 1673458852
  update-time 0
  capabilities 0x0000007f
• Kernel: Linux trinity-65281-MH4 6.12.34+rpt-rpi-v8 libilclient.a in hardffp not hardfp #1 SMP PREEMPT Debian 1:6.12.34-1+rpt1~bookworm (2025-06-26) aarch64 GNU/Linux
  Logs
  Logic analyser traces available (Bookworm vs Bullseye firmware).
  raspi-gpio get 0-3 after boot shows:
  GPIO 0: level=1 func=INPUT pull=UP
  GPIO 1: level=1 func=INPUT pull=UP
  GPIO 2: level=1 func=INPUT pull=NONE
  GPIO 3: level=1 func=INPUT pull=NONE

Additional context
Replacing /boot/firmware/start4.elf and /boot/firmware/fixup4.dat from Bullseye removes the issue completely without other configuration changes. Suggests a regression in start4.elf between Bullseye and Bookworm firmware where the force_eeprom_read=0 setting is ignored or applied too late in the boot sequence.