Cannot flash secure bootloader on a new RPi4 dual-rank (not CM4)

[andr2000]

Describe the bug

I have a very strange issue with the latest bootloader and the new RPi4 boards:

• use plain usbboot on Ubuntu 24.04 built from sources
• commit-id: "87d6e03272b0ae155d85a125bfdec03e3d4a1095"
• sign the bootloader
• create rpi-boot-eeprom-recovery-2026-05-17-2711-vl805-000138c0-sd.img
• flash it to sdcard

  2.60 RPi: BOOTSYS release VERSION:d179f03a DATE: 2025/09/08 TIME: 15:51:29
  2.60 BOOTMODE: 0x07 partition 0 build-ts BUILD_TIMESTAMP=1757343089 serial ddd14e9d boardrev b03115 stc 2609877
  2.61 PM_RSTS 00001000
  2.62 POWER_OFF_ON_HALT: 0 WAIT_FOR_POWER_BUTTON 0 power-on-reset 1
  2.62 part 00000000 reset_info 00000000
  2.63 uSD voltage 3.3V
  2.63 USB-OTG disconnect
  5.01 SDRAM_CONFIG: 16
  5.01 Initialising SDRAM rank 2 total-size: 16 Gbit 3200 (0x16 0x16)
  5.22 MCB 3200 size-gbit 16 dual-rank 1 not found
  5.02 USB-OTG disconnect
  5.29 BOOT ERROR: code 8 - 'SDRAM failure'

Then I did the same, but with older version:

• commit-id: "86a39220a870e463533b7b12294768df08c7582d"

  2.56 RPi: BOOTSYS release VERSION:fedc72ea DATE: 2026/06/02 TIME: 16:04:56
  2.57 MFG_VER: 1
  2.57 BOOTMODE: 0x07 partition 0 build-ts BUILD_TIMESTAMP=1780412696 serial ddd14e9d boardrev b03115 stc 2574548
  2.58 PM_RSTS 00001000
  2.58 POWER_OFF_ON_HALT: 0 WAIT_FOR_POWER_BUTTON 0 power-on-reset 1
  2.59 EEPROM ID 0xef3013
  2.59 SFDP None
  2.59 part 00000000 reset_info 00000000
  2.60 uSD voltage 3.3V
  2.60 USB-OTG disconnect
  5.22 SDRAM_CONFIG: 16 board-rev 00000005
  5.22 vc_driver_sdram_init_2711
  5.23 Initialising SDRAM rank 2 total-size: 16Gbit part: 0 (0x16 0x16) odt: 1
  5.23 memsys_init: 0 16Gbit MCB 0x80015ff0: 11696
  5.24 DDR 3200 Mbps dual-rank:1 byte-mode:0 size-gbit:16 part-config:0 odt:1
  6.70 SD_SB 11013110
  6.88 OTP boardrev b03115 bootrom 48b0 48b0

Configuration used in both cases:

#uart_2ndstage=1
#eeprom_write_protect=1
program_pubkey=1
program_rpiboot_gpio=6
program_jtag_lock=1
#recovery_reboot=1
recovery_metadata=0

After i used the older version I was not able to take the board into mass-storage
device mode, but was able to do so with the latest usbboot.

Unfortunatelly I do not have any blank RPi4 to provide more information,
but hope you can advise what needs to be done for the latest usbboot images
to work in particular with dual-rank RAM variant.

Thank you in advance

Steps to reproduce the behaviour

see above

Device(s)

Other

Compute Module IO board.

No response

RPIBOOT logs

No response

Kernel logs

No response

Device UART logs

• commit-id: "87d6e03272b0ae155d85a125bfdec03e3d4a1095"

  2.60 RPi: BOOTSYS release VERSION:d179f03a DATE: 2025/09/08 TIME: 15:51:29
  2.60 BOOTMODE: 0x07 partition 0 build-ts BUILD_TIMESTAMP=1757343089 serial ddd14e9d boardrev b03115 stc 2609877
  2.61 PM_RSTS 00001000
  2.62 POWER_OFF_ON_HALT: 0 WAIT_FOR_POWER_BUTTON 0 power-on-reset 1
  2.62 part 00000000 reset_info 00000000
  2.63 uSD voltage 3.3V
  2.63 USB-OTG disconnect
  5.01 SDRAM_CONFIG: 16
  5.01 Initialising SDRAM rank 2 total-size: 16 Gbit 3200 (0x16 0x16)
  5.22 MCB 3200 size-gbit 16 dual-rank 1 not found
  5.02 USB-OTG disconnect
  5.29 BOOT ERROR: code 8 - 'SDRAM failure'

• commit-id: "86a39220a870e463533b7b12294768df08c7582d"

  2.56 RPi: BOOTSYS release VERSION:fedc72ea DATE: 2026/06/02 TIME: 16:04:56
  2.57 MFG_VER: 1
  2.57 BOOTMODE: 0x07 partition 0 build-ts BUILD_TIMESTAMP=1780412696 serial ddd14e9d boardrev b03115 stc 2574548
  2.58 PM_RSTS 00001000
  2.58 POWER_OFF_ON_HALT: 0 WAIT_FOR_POWER_BUTTON 0 power-on-reset 1
  2.59 EEPROM ID 0xef3013
  2.59 SFDP None
  2.59 part 00000000 reset_info 00000000
  2.60 uSD voltage 3.3V
  2.60 USB-OTG disconnect
  5.22 SDRAM_CONFIG: 16 board-rev 00000005
  5.22 vc_driver_sdram_init_2711
  5.23 Initialising SDRAM rank 2 total-size: 16Gbit part: 0 (0x16 0x16) odt: 1
  5.23 memsys_init: 0 16Gbit MCB 0x80015ff0: 11696
  5.24 DDR 3200 Mbps dual-rank:1 byte-mode:0 size-gbit:16 part-config:0 odt:1
  6.70 SD_SB 11013110
  6.88 OTP boardrev b03115 bootrom 48b0 48b0

[andr2000]

[timg236]

According to your logs

The failing version is
2.60 RPi: BOOTSYS release VERSION:d179f03a DATE: 2025/09/08 TIME: 15:51:29

The passing version is
2.56 RPi: BOOTSYS release VERSION:fedc72ea DATE: 2026/06/02 TIME: 16:04:56

The passing bootloader verison is newer than the failing version and is the minimum version that I would expect.

I'm wondering if you have a stale pieeprom.bin (not run update-eeprom.sh). The top of tree Github has an evern newer pieeprom.original.bin

(.venv) tim@buildbot:master:~/usbboot/recovery$ strings pieeprom.original.bin | grep DATE
ENABLE_SELF_UPDATE
DATE: 2026/05/17

[andr2000]

Sorry for the mess and let me check that.

BTW, HEAD has rpi-eeprom @ 387e8cc which is firmware: 2712: Update to 2026-05-26
Does it need to be switched to more recent version or this is expected?

[timg236]

I think you might be looking in the 2712 directory. For Pi4

rwxrwxrwx 1 tim tim 61 Jun 6 09:51 pieeprom.bin -> ../../rpi-eeprom/firmware-2711/latest/pieeprom-2026-05-17.bin
lrwxrwxrwx 1 tim tim 50 Jun 6 09:51 recovery.bin -> ../../rpi-eeprom/firmware-2711/latest/recovery.bin

Anything 2026/06/02 or newer is fine

[andr2000]

But in your listing we have May, 17th
But you recommend June and newer
Thanks

[timg236]

May would be ok

[andr2000]

Well, I asked the customer to check the following (brand new RPi4, dual rank):

commit 87d6e03272b0ae155d85a125bfdec03e3d4a1095 (HEAD, origin/master, origin/HEAD, master)
Author: Ed Maste <emaste@FreeBSD.org>
Date:   Thu May 28 13:38:28 2026 -0400

    readme: Add FreeBSD instructions

They've got 4 long and 4 short blinks of the green LED with the SD card from the above commit which was about to provision secure boot on the device.
Then they used pretty old SD card built with commit id 48821f073a8a48a84685f1fd0721eb28d24b2f9f and the same signing keys (previous release we provided to them).
They were able to flash secure boot, but then were not able to proceed with provisioning as mass-storage device was not available.
So, they used the latest usbboot 87d6e03272b0ae155d85a125bfdec03e3d4a1095 and were able to access mass-storage device with it.

So, it seems that 48821f073a8a48a84685f1fd0721eb28d24b2f9f is able to write secure boot, but can't work with MSD.
87d6e03272b0ae155d85a125bfdec03e3d4a1095 can work with MSD, but can't install secure boot.

P.S. Unfortunately the customer cannot provide serial logs.

[andr2000]

I think you might be looking in the 2712 directory. For Pi4

rwxrwxrwx 1 tim tim 61 Jun 6 09:51 pieeprom.bin -> ../../rpi-eeprom/firmware-2711/latest/pieeprom-2026-05-17.bin lrwxrwxrwx 1 tim tim 50 Jun 6 09:51 recovery.bin -> ../../rpi-eeprom/firmware-2711/latest/recovery.bin

Anything 2026/06/02 or newer is fine

lrwxrwxrwx 1 yyy yyy 61 Aug 10 14:11 pieeprom.bin -> ../../rpi-eeprom/firmware-2711/latest/pieeprom-2026-05-17.bin
lrwxrwxrwx 1 yyy yyy 50 Aug 10 14:11 recovery.bin -> ../../rpi-eeprom/firmware-2711/latest/recovery.bin

[timg236]

Git 381732e of usbboot broke the symlink to bootfiles.bin, is it possible that that is what they are seeing?
It might be best to use APT version of rpiboot if possible to reduce the amount of churn they see and latest APT release should be last-known-good.

[andr2000]

But I am on commit 87d6e03 which already has this fix and that was for 2712, and I have issues with 2711 Model B

[pelwell]

firmware-2711/latest includes 2 pieeprom .bin files, which doesn't look correct.

[andr2000]

firmware-2711/latest includes 2 pieeprom .bin files, which doesn't look correct.

can this be fixed please?

[timg236]

firmware-2711/latest includes 2 pieeprom .bin files, which doesn't look correct.

I can't see two files
https://github.com/raspberrypi/usbboot/tree/master/firmware/2711

If you are looking in the rpi-eeprom submodule then you will see all of the available releases

[pelwell]

Yes, it was the submodule: https://github.com/raspberrypi/rpi-eeprom/tree/master/firmware-2711/latest

2 seemed like an odd(!) number for latest, but I now see that 2712 has more and that the others were archived to old not long ago.

[timg236]

Yes, it was the submodule: https://github.com/raspberrypi/rpi-eeprom/tree/master/firmware-2711/latest

2 seemed like an odd(!) number for latest, but I now see that 2712 has more and that the others were archived to old not long ago.

Yes, there used to be more but the old releases which didn't support all the current SDRAMs were archived. There's a small change of a stale symlink if the rebase didn't work?
@andr2000 Can you ask the customer to clone this to a new tree and do the submodue init and run the signing scripts to be sure ?