Pi 4 won't boot with GPIO 1 pulled low (and on my 8GB board, floating).

[dickontoo]

Describe the bug
The Raspberry Pi 4 will not boot if GPIO 1 / ID_SC is pulled low. Admittedly, this shouldn't happen, but it semingly is on my 8G Pi 4 when left floating: to get it to reliably boot I need a wire between a 3v3 pin and pin 28. The Pi 2 is unaffected.

To reproduce
Connect a ground pin to pin 28 and reboot. Watch in wonder as your Pi boots as far as the rainbow screen and freezes. If you're network booting, you can see the thing stopping before the DTB is loaded.

Expected behaviour
The Pi boots.

Actual behaviour
The Pi doesn't boot.

System

• Which model of Raspberry Pi? e.g. Pi3B+, PiZeroW

Pi 4 2G (tied to ground), Pi 4 8G (left floating or tied to ground, on apparently my board only; possibly also user jk123 on the forums, too).

• Which OS and version (cat /etc/rpi-issue)?

Doesn't get that far.

• Which firmware version (vcgencmd version)?

Everything that I have tried from when I got it (last Tuesday) until today: da3752a358a86014cdcce5fc3be5b18d7ec074c4 and 31eda665dcc45e61650a2ef018ef2cf94091c46f at least.

• Which kernel version (uname -a)?
  Irrelevant.

Logs
Please see this post for details.

Additional context
As I say, this seems to affect my new 8G Pi 4 when left floating, which has caused me much headscratching over the last week. Obviously, the ID I2C pins should be left clear when unused, so this is a little concerning. force_eeprom_read=0 has no effect.

I can't see any obviously-knocked-off pullup resistor, but it's quite a complicated board these days and I don't know where I should be looking, should such a thing exist.

config.txt:

arm_64bit=1
gpu_mem=256
uart_2ndstage=1
kernel_address=0x80000

# start_file=start4db.elf
# fixup_file=fixup4db.dat

force_eeprom_read=0

dtoverlay=miniuart-bt

# over_voltage=1

initramfs initrd.gz
hdmi_enable_4k=1

# dtoverlay=w1-gpio,gpiopin=11
hdmi_ignore_cec_init=1

# Enable audio (loads snd_bcm2835)
dtparam=audio=on
bootloader_update=1

[pi4]
# Enable DRM VC4 V3D driver on top of the dispmanx display stack
dtoverlay=vc4-fkms-v3d
# dtoverlay=vc4-kms-v3d
max_framebuffers=2
enable_uart=1
# dtoverlay=uart5
# dtoverlay=uart0
start_x=1
dtparam=act_led_trigger=heartbeat
disable_overscan=1

[all]
#dtoverlay=vc4-fkms-v3d
hdmi_enable_4kp60=1

[pelwell]

GPIOs 0-8 pull high by default, so there should be no floating involved. On BCM2711 we can read back the pull state to confirm:

pi@raspberrypi:~$ raspi-gpio get 0-9
GPIO 0: level=1 fsel=0 func=INPUT pull=UP
GPIO 1: level=1 fsel=0 func=INPUT pull=UP
GPIO 2: level=1 fsel=0 func=INPUT pull=UP
GPIO 3: level=1 fsel=0 func=INPUT pull=UP
GPIO 4: level=1 fsel=0 func=INPUT pull=UP
GPIO 5: level=1 fsel=0 func=INPUT pull=UP
GPIO 6: level=1 fsel=0 func=INPUT pull=UP
GPIO 7: level=1 fsel=0 func=INPUT pull=UP
GPIO 8: level=1 fsel=0 func=INPUT pull=UP
GPIO 9: level=0 fsel=0 func=INPUT pull=DOWN

What output do you get?

Pulling GPIO 0 or 1 low is an error condition - the only thing that should be attached to pins 28 and 29 is a HAT EEPROM.

We can verify whether the state of GPIO 1 is varying with this Python script (originally by Alex Eames, modded to change the GPIO number):

#!/usr/bin/env python2.7
# script by Alex Eames https://raspi.tv/
# https://raspi.tv/2013/how-to-use-interrupts-with-python-on-the-raspberry-pi-and-rpi-gpio
import RPi.GPIO as GPIO
GPIO.setmode(GPIO.BCM)

gpio=1

# GPIO set up as input. It is pulled up to stop false signals
GPIO.setup(gpio, GPIO.IN, pull_up_down=GPIO.PUD_UP)

print "Make sure you have a button connected so that when pressed"
print "it will connect GPIO port", gpio, "to GND (pin 6)\n"
raw_input("Press Enter when ready\n>")

print "Waiting for falling edge on port", gpio
# now the program will do nothing until the signal on port 23
# starts to fall towards zero. This is why we used the pullup
# to keep the signal high and prevent a false interrupt

print "During this waiting time, your computer is not"
print "wasting resources by polling for a button press.\n"
print "Press your button when ready to initiate a falling edge interrupt."
try:
    GPIO.wait_for_edge(gpio, GPIO.FALLING)
    print "\nFalling edge detected. Now your program can continue with"
    print "whatever was waiting for a button press."
except KeyboardInterrupt:
    GPIO.cleanup()       # clean up GPIO on CTRL+C exit
GPIO.cleanup()           # clean up GPIO on normal exit

If you really are seeing a floating GPIO 1 while 2711 is claiming it is pulling high then that points to a failure of the internal pull-up resistor - a problem I have never encountered before and one that suggests a high voltage event in the Pi's past.

[dickontoo]

root@rhsmon:~# raspi-gpio get 0-9
GPIO 0: level=1 fsel=0 func=INPUT pull=UP
GPIO 1: level=0 fsel=0 func=INPUT pull=UP
GPIO 2: level=1 fsel=0 func=INPUT pull=UP
GPIO 3: level=1 fsel=0 func=INPUT pull=UP
GPIO 4: level=1 fsel=0 func=INPUT pull=UP
GPIO 5: level=1 fsel=0 func=INPUT pull=UP
GPIO 6: level=1 fsel=0 func=INPUT pull=UP
GPIO 7: level=0 fsel=0 func=INPUT pull=UP
GPIO 8: level=0 fsel=0 func=INPUT pull=UP
GPIO 9: level=0 fsel=0 func=INPUT pull=DOWN

I say 'floating' as in 'I'm not doing anything explicit to pull it up or down' -- nothing connected to the pins, and whatever default the SoC does. Apparently it thinks it's pulling up, but isn't; also 7 and 8, which are adjacent to 1 on the board.

There's at least one other user who appears to have this problem: This thread looks remarkably similar. If it was subjected to a high-voltage event, it was before I got near it: it first exhibited this problem after an initial boot and being left running for an hour or so, physically untouched.

Either way, shouldn't the force_eeprom_read=0 mean it would ignore the whole I2C bus anyway?

[pelwell]

Either way, shouldn't the force_eeprom_read=0 mean it would ignore the whole I2C bus anyway?

There's currently an exception - the POE HAT probing ignores force_eeprom_read, which is logical because it's looking for a fan controller, not an EEPROM. Adding disable_poe_fan=1 as well will skip that I2C access and allow the device to boot.

At the point the boot stalls, the I2C driver has already detected an error but is waiting for the Transfer Active bit to clear so as not to leave the controller in a strange state - it looks as though something extra is required to cancel the current operation.

[dickontoo]

That works nicely, thanks. I'll use that until I can obtain a replacement -- my supplier is claiming they're out of stock there until mid-August, which is irksome.

[pelwell]

If you're feeling bored in the near future and you have the necessary equipment (errm, some resistors) I wouldn't mind finding out what is the largest value pull-up resistor that allows it to boot once you've removed the disable_poe_fan setting.

[dickontoo]

I do actually have a range of that terribly expensive and hard to obtain hardware, and some flying leads to test with, but in a very odd development, simply plugging the flying lead in is enough to trigger the thing to boot, in certain regions of the room (eg. at desk level, but not at speaker level; I need to physically touch the insulated wire to get it to boot at that point). A while :; do raspi-gpio get 1 | grep level=1; done shows a 1 being read every second or so, albeit heavily jittered.

I have no idea. I hate hardware, sometimes.

[pelwell]

We might want to take a look at that board. If you are open to the possibility of us sending out a replacement in exchange for your defective unit, send me an email - [email protected].

[dickontoo]

Running the loop above, I've narrowed the 1-level to somewhere between 6k8 and 8k2, which seems awfully low to me. I don't have anything in between those two values, and I'm not about to try any resistor chaining.