dom
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 5807
Joined: Wed Aug 17, 2011 7:41 pm
Location: Cambridge

Re: Raspberry Pi very early boot issue

Thu Oct 07, 2021 5:24 pm

geerlingguy wrote:
Thu Oct 07, 2021 4:59 pm
Might be morning brain fog, but the fact that the recovery.bin loads and runs means clocks and SDRAM are initialized, right?
No. recovery.bin is loaded from the bootrom with sdram disabled (it is loaded into L2 cache).
I believe the power supply you've hacked off goes to sdram. Without it sdram will never work.

User avatar
geerlingguy
Posts: 256
Joined: Sun Feb 15, 2015 3:43 am
Location: St. Louis, MO, USA
Contact: Website Twitter YouTube

Re: Raspberry Pi very early boot issue

Thu Oct 07, 2021 5:27 pm

dom wrote:
Thu Oct 07, 2021 5:24 pm
geerlingguy wrote:
Thu Oct 07, 2021 4:59 pm
Might be morning brain fog, but the fact that the recovery.bin loads and runs means clocks and SDRAM are initialized, right?
No. recovery.bin is loaded from the bootrom with sdram disabled (it is loaded into L2 cache).
I believe the power supply you've hacked off goes to sdram. Without it sdram will never work.
That would indeed make sense.

And that also makes more sense about the placement—I was wondering why that part of the power supply would be so far removed from the main components over by the USB-C connector... but that space is a little closer to the SDRAM package.
The question is not whether something should be done on a Raspberry Pi, it is whether it can be done on a Raspberry Pi.

User avatar
geerlingguy
Posts: 256
Joined: Sun Feb 15, 2015 3:43 am
Location: St. Louis, MO, USA
Contact: Website Twitter YouTube

Re: Raspberry Pi very early boot issue

Thu Oct 07, 2021 6:19 pm

cleverca22 wrote:
Wed Sep 29, 2021 2:38 pm
i think the next course of action, is to try and re-flash the eeprom to enable debug

Code: Select all

[clever@system76:~/apps/rpi]$ git clone https://github.com/raspberrypi/rpi-eeprom
[clever@system76:~/apps/rpi]$ cd rpi-eeprom/
[clever@system76:~/apps/rpi/rpi-eeprom]$ cat bootconf.txt 
[all]
BOOT_UART=1
WAKE_ON_GPIO=1
POWER_OFF_ON_HALT=0
ENABLE_SELF_UPDATE=1
BOOT_ORDER=0xf541

[none]
FREEZE_VERSION=0
[clever@system76:~/apps/rpi/rpi-eeprom]$ ./rpi-eeprom-config --config bootconf.txt --out pieeprom.bin firmware/beta/pieeprom-2021-09-27.bin 
[clever@system76:~/apps/rpi/rpi-eeprom]$ sha256sum pieeprom.bin | cut -d' ' -f1 > pieeprom.sig
[clever@system76:~/apps/rpi/rpi-eeprom]$ echo 'ts: 42' >> pieeprom.sig 
[clever@system76:~/apps/rpi/rpi-eeprom]$ cat pieeprom.sig 
7f5baecf2cfe680cfb914b6abe737236ddcbfdf2fffc8aecfe339a06159f7e15
ts: 42
this will grab the latest beta firmware, and modify the config file within it
it enables the debug logs on the uart, and sets the boot order to SD, usb, bcmusb, restart

it then generates a sig file containing the hash, which is needed for the next step

Code: Select all

[root@system76:~]# mount -v /dev/mmcblk0p1 /mnt/
[root@system76:~]# cp -vi /home/clever/apps/rpi/rpi-eeprom/pieeprom.{bin,sig} /mnt/
'/home/clever/apps/rpi/rpi-eeprom/pieeprom.bin' -> '/mnt/pieeprom.bin'
'/home/clever/apps/rpi/rpi-eeprom/pieeprom.sig' -> '/mnt/pieeprom.sig'
[root@system76:~]# cp -v /home/clever/apps/rpi/rpi-eeprom/firmware/beta/recovery.bin /mnt/
'/home/clever/apps/rpi/rpi-eeprom/firmware/beta/recovery.bin' -> '/mnt/recovery.bin'
[root@system76:~]# umount /mnt
this puts the new firmware file onto an SD card, along with the official recovery.bin, which does reflashing

all of the above can be done on any system with python2, i just happened to use my x86 laptop, because its got a good SD socket built-in

Code: Select all

BMD "vl805.bin" not found
SIG pieeprom.sig 7f5baecf2cfe680cfb914b6abe737236ddcbfdf2fffc8aecfe339a06159f7e15 0
Reading EEPROM: 524288
Writing EEPROM
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++...............................
Verify BOOT EEPROM
Reading EEPROM: 524288
BOOT-EEPROM: UPDATED
if you then power up the pi4 with that SD in it, the above will be printed to the serial port
each + represents a block of the SPI that didnt match, so it had to be erased and re-programmed
each . represents a block of SPI that did match, so it was just left as-is

once that is done, you can take the card back out, and turn the pi on a second time, and you should see:

Code: Select all

RPi: BOOTLOADER release VERSION:39e76747 DATE: Sep 27 2021 TIME: 14:30:29 BOOTMODE: 0x00000006 part: 0 BUILD_TIMESTAMP=1632749428 0xd328cdce 0x00c03112 0x00051599
PM_RSTS: 0x00001000
part 00000000 reset_info 00000000
uSD voltage 3.3V
Initialising SDRAM 'Micron' 16Gb x2 total-size: 32 Gbit 3200

XHCI-STOP
xHC ver: 256 HCS: 05000420 fc000031 00e70004 HCC: 002841eb
USBSTS 11
xHC ver: 256 HCS: 05000420 fc000031 00e70004 HCC: 002841eb
xHC ports 5 slots 32 intrs 4
Reset USB port-power 1000 ms
xhci_set_port_power 1 0
xhci_set_port_power 2 0
xhci_set_port_power 3 0
xhci_set_port_power 4 0
xhci_set_port_power 5 0
xhci_set_port_power 1 1
xhci_set_port_power 2 1
xhci_set_port_power 3 1
xhci_set_port_power 4 1
xhci_set_port_power 5 1
XHCI-STOP
xHC ver: 256 HCS: 05000420 fc000031 00e70004 HCC: 002841eb
USBSTS 10
XHCI-STOP
xHC ver: 256 HCS: 05000420 fc000031 00e70004 HCC: 002841eb
USBSTS 11
xHC ver: 256 HCS: 05000420 fc000031 00e70004 HCC: 002841eb
xHC ports 5 slots 32 intrs 4
Boot mode: SD (01) order f54
SD HOST: 250000000 CTL0: 0x00000000 BUS: 100000 Hz actual: 100000 HZ div: 2500 (1250) status: 0x1fff0000 delay: 1080
SD HOST: 250000000 CTL0: 0x00000f00 BUS: 100000 Hz actual: 100000 HZ div: 2500 (1250) status: 0x1fff0000 delay: 1080
EMMC
SD retry 1 oc 0
SD HOST: 250000000 CTL0: 0x00000000 BUS: 100000 Hz actual: 100000 HZ div: 2500 (1250) status: 0x1fff0000 delay: 1080
SD retry 2 oc 0
SD HOST: 250000000 CTL0: 0x00000000 BUS: 100000 Hz actual: 100000 HZ div: 2500 (1250) status: 0x1fff0000 delay: 1080
SDV1
SD retry 3 oc 0
SD HOST: 250000000 CTL0: 0x00000000 BUS: 100000 Hz actual: 100000 HZ div: 2500 (1250) status: 0x1fff0000 delay: 1080
SD CMD: 0x371a0010 (55) 0x0 0x1fff0001
Failed to open device: 'sdcard' (cmd 371a0010 status 1fff0001)
Retry SD 1
SD HOST: 250000000 CTL0: 0x00000000 BUS: 100000 Hz actual: 100000 HZ div: 2500 (1250) status: 0x1fff0000 delay: 1080
SD HOST: 250000000 CTL0: 0x00000f00 BUS: 100000 Hz actual: 100000 HZ div: 2500 (1250) status: 0x1fff0000 delay: 1080
EMMC
SD retry 1 oc 0
SD HOST: 250000000 CTL0: 0x00000000 BUS: 100000 Hz actual: 100000 HZ div: 2500 (1250) status: 0x1fff0000 delay: 1080
SD retry 2 oc 0
SD HOST: 250000000 CTL0: 0x00000000 BUS: 100000 Hz actual: 100000 HZ div: 2500 (1250) status: 0x1fff0000 delay: 1080
SDV1
SD retry 3 oc 0
SD HOST: 250000000 CTL0: 0x00000000 BUS: 100000 Hz actual: 100000 HZ div: 2500 (1250) status: 0x1fff0000 delay: 1080
SD CMD: 0x371a0010 (55) 0x0 0x1fff0001
Failed to open device: 'sdcard' (cmd 371a0010 status 1fff0001)
Boot mode: USB-MSD (04) order f5
XHCI-STOP
xHC ver: 256 HCS: 05000420 fc000031 00e70004 HCC: 002841eb
USBSTS 0
XHCI-STOP
xHC ver: 256 HCS: 05000420 fc000031 00e70004 HCC: 002841eb
USBSTS 1
xHC ver: 256 HCS: 05000420 fc000031 00e70004 HCC: 002841eb
xHC ports 5 slots 32 intrs 4
USB2[1] 400202e1 connected
USB2 root HUB port 1 init
DEV [01:00] 2.16 000000:01 class 9 VID 2109 PID 3431
HUB init [01:00] 2.16 000000:01
it brought the ram online, failed to find an sd card, and has now begun searching usb ports for drives

if something is wrong with the ram, it should print some kind of error during that process

Tried this out, and unfortunately when I put in the microSD card and boot, the ACT LED goes straight to bright green, like something failed.

If I switch back to the recovery.bin you sent, it boots to that little serial console. I also tried reverting back to the earliest commit in the raspberrypi/rpi-eeprom repo, and using its recovery.bin, but that still seems to be doing whatever it is to cause the green ACT LED to light up and nothing else to happen (no serial output at all, except for an occasional � every third or fourth power cycle.
The question is not whether something should be done on a Raspberry Pi, it is whether it can be done on a Raspberry Pi.

User avatar
geerlingguy
Posts: 256
Joined: Sun Feb 15, 2015 3:43 am
Location: St. Louis, MO, USA
Contact: Website Twitter YouTube

Re: Raspberry Pi very early boot issue

Thu Oct 07, 2021 7:42 pm

Also posting two helpful/relevant links @cleverca22 sent me via IRC:

A/V jack physical layout and circuit (this stuff seems intact): viewtopic.php?p=1746010#p1746010

X-ray view (topside/bottomside) of Pi 4 board: https://al.zerostem.io/~al/dzi/xray.html (note: this is the design for the non-8GB boards)
The question is not whether something should be done on a Raspberry Pi, it is whether it can be done on a Raspberry Pi.

User avatar
geerlingguy
Posts: 256
Joined: Sun Feb 15, 2015 3:43 am
Location: St. Louis, MO, USA
Contact: Website Twitter YouTube

Re: Raspberry Pi very early boot issue

Thu Oct 14, 2021 3:25 am

Just had a crazy idea, now that I have a hot air station... could I flash eeprom on another Pi 4, then replace the eeprom chip on the suffering pi 4 with it? Basically get the BOOT_UART option going that way?

Might be annoying to do that though, because I don't know how much I'd trust my ability to preserve that chip transferring back to the donor Pi...
The question is not whether something should be done on a Raspberry Pi, it is whether it can be done on a Raspberry Pi.

cleverca22
Posts: 4622
Joined: Sat Aug 18, 2012 2:33 pm

Re: Raspberry Pi very early boot issue

Thu Oct 14, 2021 4:58 am

that could work, but it might be simpler to just implement reflashing in the open firmware instead

implementing serprog has been on my todo list for a while

once implemented, you just run a custom recovery.bin from an SD card as youve already done, and then the serial port will present the standard serprog api

then you just point flashrom at that serial port, and you have full access to the SPI chip, without having to remove it

jj_0
Posts: 146
Joined: Wed Jul 11, 2012 7:07 am

Re: Raspberry Pi very early boot issue

Thu Oct 14, 2021 11:02 am

Could you instead connect the EEPROM's pins to another Pi's SPI GPIO's and then flash it? https://flashrom.org/RaspberryPi

cleverca22
Posts: 4622
Joined: Sat Aug 18, 2012 2:33 pm

Re: Raspberry Pi very early boot issue

Thu Oct 14, 2021 9:03 pm

jj_0 wrote:
Thu Oct 14, 2021 11:02 am
Could you instead connect the EEPROM's pins to another Pi's SPI GPIO's and then flash it? https://flashrom.org/RaspberryPi
the issue is how small the pins are, and the potential damage from trying to remove the chip

we need to probe the pins on the boot eeprom

Image

Return to “General discussion”