raspberrypi
different PM_RSTS register content when doing an u-boot reset between v20250430 and v20250915?
Hi,
when applying a reset command from within u-boot (on a CM4), the content of the PM_RSTS has different values between these 2 versions after the reset. This leads to different boot partitions used by the EEPROM-bootloader:
Version 20250915 after an u-boot reset command:
0.18 RPi: BOOTSYS release VERSION:75c1e570 DATE: 2025/02/11 TIME: 17:00:13
0.22 BOOTMODE: 0x06 partition 32 build-ts BUILD_TIMESTAMP=1739293213 serial 73d45949 boardrev d03141 stc 522662
0.32 PM_RSTS 00000420
0.34 POWER_OFF_ON_HALT: 1 WAIT_FOR_POWER_BUTTON 0 power-on-reset 0
0.50 part 00000020 reset_info 00000000
0.51 uSD voltage 3.3V
0.77 Initialising SDRAM rank 2 total-size: 64 Gbit 3200 (0x14 0x00)
0.80 DDR 3200 1 0 64 152 BL:3
2.80 OTP boardrev d03141 bootrom 48b0 48b0
2.82 Customer key hash 0000000000000000000000000000000000000000000000000000000000000000
2.89 VC-JTAG unlocked
2.67 RPi: BOOTLOADER release VERSION:75c1e570 DATE: 2025/02/11 TIME: 17:00:13
2.72 BOOTMODE: 0x06 partition 32 build-ts BUILD_TIMESTAMP=1739293213 serial 73d45949 boardrev d03141 stc 2472066
2.07 Boot mode: SD (01) order f
2.22 SD HOST: 200000000 CTL0: 0x00800000 BUS: 400000 Hz actual: 390625 HZ div: 512 (256) status: 0x1fff0000 delay: 276
2.32 SD HOST: 200000000 CTL0: 0x00800f00 BUS: 400000 Hz actual: 390625 HZ div: 512 (256) status: 0x1fff0000 delay: 276
2.41 EMMC
2.41 SD retry 1 oc 0
2.66 SD HOST: 200000000 CTL0: 0x00800000 BUS: 400000 Hz actual: 390625 HZ div: 512 (256) status: 0x1fff0000 delay: 276
2.77 OCR c0ff8080 [0]
CID: 00150100384754463452064e135fa46a
2.97 SD HOST: 200000000 CTL0: 0x00800f04 BUS: 25000000 Hz actual: 25000000 HZ div: 8 (4) status: 0x1fff0000 delay: 4
2.07 SD HOST: 200000000 CTL0: 0x00800f04 BUS: 50000000 Hz actual: 50000000 HZ div: 4 (2) status: 0x1fff0000 delay: 2
2.16 MBR: 0x00000800, 102400 type: 0x0c
2.19 MBR: 0x0001a000, 102400 type: 0x0c
2.22 MBR: 0x00033000, 102400 type: 0x0c
2.26 MBR: 0x0004c7fe,14948354 type: 0x0f
2.30 Trying partition: 0
2.33 type: 16 lba: 2048 'mkfs.fat' ' V ^ ' clusters 25541 (4)
2.39 rsc 4 fat-sectors 100 root dir cluster 1 sectors 32 entries 512
2.45 FAT16 clusters 25541
2.49 Read autoboot.txt bytes 23 hnd 0x3
2.52 Select partition rsts 32 C(boot_partition) 3 EEPROM config 0 result 32
2.59 Trying partition: 32
2.61 EBR: 0x0004c7fe 0x00000002, 2048000 0x001f4782, 9420928 signature: aa55
2.68 EBR: 0x00240f80 0x00000080, 9420800 0x00af0f82, 1024128 signature: aa55
2.75 EBR: 0x00b3d780 0x00000080, 1024000 0x00beb782, 2048128 signature: aa55
2.82 EBR: 0x00c37f80 0x00000080, 2048000 0x00ddff82, 399488 signature: aa55
2.89 EBR: 0x00e2c780 0x00000080, 399360 0x00000000, 0 signature: aa55
2.96 Failed to open partition 32
Version 20253004 after an u-boot reset command (starts correct partition stated in autoboot.txt):
0.20 RPi: BOOTSYS release VERSION:75c1e570 DATE: 2025/02/11 TIME: 17:00:13
0.24 BOOTMODE: 0x06 partition 0 build-ts BUILD_TIMESTAMP=1739293213 serial 73d45949 boardrev d03141 stc 524132
0.34 PM_RSTS 00000020
0.36 POWER_OFF_ON_HALT: 1 WAIT_FOR_POWER_BUTTON 0 power-on-reset 0
0.53 part 00000000 reset_info 00000000
0.54 uSD voltage 3.3V
0.80 Initialising SDRAM rank 2 total-size: 64 Gbit 3200 (0x14 0x00)
0.83 DDR 3200 1 0 64 152 BL:3
2.84 OTP boardrev d03141 bootrom 48b0 48b0
2.86 Customer key hash 0000000000000000000000000000000000000000000000000000000000000000
2.93 VC-JTAG unlocked
2.72 RPi: BOOTLOADER release VERSION:75c1e570 DATE: 2025/02/11 TIME: 17:00:13
2.76 BOOTMODE: 0x06 partition 0 build-ts BUILD_TIMESTAMP=1739293213 serial 73d45949 boardrev d03141 stc 2476492
2.11 Boot mode: SD (01) order f
2.26 SD HOST: 200000000 CTL0: 0x00800000 BUS: 400000 Hz actual: 390625 HZ div: 512 (256) status: 0x1fff0000 delay: 276
2.37 SD HOST: 200000000 CTL0: 0x00800f00 BUS: 400000 Hz actual: 390625 HZ div: 512 (256) status: 0x1fff0000 delay: 276
2.46 EMMC
2.46 SD retry 1 oc 0
2.70 SD HOST: 200000000 CTL0: 0x00800000 BUS: 400000 Hz actual: 390625 HZ div: 512 (256) status: 0x1fff0000 delay: 276
2.82 OCR c0ff8080 [0]
CID: 00150100384754463452064e135fa46a
2.01 SD HOST: 200000000 CTL0: 0x00800f04 BUS: 25000000 Hz actual: 25000000 HZ div: 8 (4) status: 0x1fff0000 delay: 4
2.12 SD HOST: 200000000 CTL0: 0x00800f04 BUS: 50000000 Hz actual: 50000000 HZ div: 4 (2) status: 0x1fff0000 delay: 2
2.20 MBR: 0x00000800, 102400 type: 0x0c
2.23 MBR: 0x0001a000, 102400 type: 0x0c
2.27 MBR: 0x00033000, 102400 type: 0x0c
2.31 MBR: 0x0004c7fe,14948354 type: 0x0f
2.34 Trying partition: 0
2.37 type: 16 lba: 2048 'mkfs.fat' ' V ^ ' clusters 25541 (4)
2.43 rsc 4 fat-sectors 100 root dir cluster 1 sectors 32 entries 512
2.50 FAT16 clusters 25541
2.54 Read autoboot.txt bytes 23 hnd 0x4
2.56 Select partition rsts 0 C(boot_partition) 2 EEPROM config 1 result 2
2.63 Trying partition: 2
2.65 type: 12 lba: 106496 'mkfs.fat' ' V ^ ' clusters 1133 (4)
2.72 rsc 1 fat-sectors 4 root dir cluster 1 sectors 32 entries 512
2.78 FAT12 clusters 1133
2.80 secure-boot
2.82 Loading boot.img ...
2.85 boot.sig
Also in the old version u-boot is watchdog resetted after some seconds and on the new version it is not. What exactly has changed here? It is really a problem that it trys to start partition 32.
in config.txt I have "dtparam=watchdog=on"
The 4 in 00000420 is bit 10, which corresponds to bit 5 in the partition number, i.e. partition 32. This bit must be being set by U-boot. What does sudo reboot in RPiOS do?
By the way, I notice that the U-boot reset/reboot logic does not clear the partition bits, whereas the Linux watchdog driver does.
I used the same u-boot with both firmwares and I see the difference. So u-boot does not set Bit 10, but the firmware 20250915 seems to set it. After a normal reboot from Linux, Bit 10 is not set. So you say these are cleared by the Linux watchdog driver? But why does the new firmware set Bit 10 at all? The problem is, that we need the reset from u-boot under some circumstances. It is normal logic. But we want that after a u-boot reset the partition from "boot_partition" in autoboot.txt is booted. This is corrupted now because it always trys to boot partition 32. Also PARTITION_WALK or [all]PARTITION=1 is no solution because it is not the partition from autoboot.txt (which can be dynamically changed)
'sudo reboot' on RPi OS will invoke the bcm2835 watchdog driver to do the reset and this always sets/clears the PM_RSTS bits. This pattern should be followed by other operating systems / u-boot (if implementing a watchdog).
It's possible that the the partition-walk end-case was written to PM_RSTS which is normally invisible in RPi OS when it was enabled by default, if so, we'll fix that.
Actually, this looks like fallout from the watchdog changes in early boot. In newer firmware the bootloader latches PM_RSTS for the partition number before doing watchdog stuff and restores it later. However, if it makes it through to the OS / u-boot and bit5 is not cleared it will appear again as the latched value and be treated as partition 32.
I've just seen and approved the patch from @timg236 that fixes this issue. It must have taken some tracking down because the error is very easy to miss. I would expect an updated EEPROM image in the next few days.
I've just seen and approved the patch from @timg236 that fixes this issue. It must have taken some tracking down because the error is very easy to miss. I would expect an updated EEPROM image in the next few days.
Nice! Thanks for the quick help. In the meantime, I have patched u-boot to delete the bits, just like the kernel driver does.
u-boot patch:
diff --git a/arch/arm/mach-bcm283x/reset.c b/arch/arm/mach-bcm283x/reset.c
index f13ac0c6375..5d4968c166c 100644
--- a/arch/arm/mach-bcm283x/reset.c
+++ b/arch/arm/mach-bcm283x/reset.c
@@ -25,6 +25,8 @@
/* max ticks timeout */
#define BCM2835_WDOG_MAX_TIMEOUT 0x000fffff
+#define BCM2835_RSTS_PARTITION_CLR 0xfffffaaa
+
void hw_watchdog_disable(void) {}
__efi_runtime_data struct bcm2835_wdog_regs *wdog_regs;
@@ -34,6 +36,11 @@ __reset_cpu(struct bcm2835_wdog_regs *wdog_regs, ulong ticks)
{
uint32_t rstc, timeout;
+ u32 val = readl(&wdog_regs->rsts);
+ val |= BCM2835_WDOG_PASSWORD;
+ val &= BCM2835_RSTS_PARTITION_CLR;
+ writel(val, &wdog_regs->rsts);
+
if (ticks == 0) {
hw_watchdog_disable();
timeout = RESET_TIMEOUT;
Your patch looks OK to me. A new EEPROM image including the PM_RSTS fix has been uploaded to the rpi-eeprom repo: https://github.com/raspberrypi/rpi-eeprom
The fix should now be available in rpi-update, APT updates should follow in a few days.