USB-MSD boot EEPROM first update - 2020-05-28

[timg236]

This is BETA software and the intended audience is people who are already familiar with bootloader / firmware updates and the risks involved

The EEPROM image for the bootloader has been updated in Github. An APT update will probably be released tomorrow so long as most of the bug fixes are verified as fixed.

For convenience, I've created a Github release for an EEPROM rescue image for this https://github.com/raspberrypi/rpi-eepr ... eleases.md so that the EEPROM image can easily be updated via the Raspberry Pi Imager custom image route.

Please try to keep the discussion relevant to USB mass storage boot or new bootloader features (SELF_UPDATE, NETCONSOLE etc) and not other firmware issues (i.e. things that happen before the rainbow splash screen) otherwise, important bug reports might get lost in the noise.

See original thread for USB mass storage boot
viewtopic.php?f=63&t=274595

** Edit: Updated with DPI fix and shared the GPU firmware release binaries in the Github release **
** Edit: Point at 2020-05-28 release for corrected VLI update fix **
(No more edits, the next release gets a new thread!)

To update the firmware without using rpi-update

• Make a backup of *.elf and *.dat from the boot partition
• Unzip USB firmware release to the boot partition https://github.com/raspberrypi/rpi-eepr ... rmware.zip

Significant changes from release notes https://github.com/raspberrypi/rpi-eepr ... e-notes.md

• Resolve: VL805 readback failure in the bootloader #134
• Resolve: DPI failure after HDMI diagnostics screen in beta bootloader #133
• Resolve: USB boot fails if the GPT contains no basic data or EFI partitions #130
• Resolve: Fix default BOOT_ORDER in mass storage beta #129
• Resolve: Add support for booting from a "superfloppy" disk #120
• Resolve: USB MSD timeout message - incorrect units #131
• Resolve: Recognize efi partition (0xef) as a valid boot #126
• The HDMI diagnostics screen now displays the most significant bytes of the SHA-256 of the config.txt file.

[Kendek]

Thanks, I've tested it with two RPi4 and so far everything seems fine. The SELF_UPDATE feature is also works great through USB.

[alkersan]

I apologize if this is not the right place, as this is not about USB, but SELF_UPDATE was mentioned as allowed topic here.

Seems there is an issue with SELF_UPDATE and TFTP_BOOT, which leads to infinite reset loop. Tested with pieeprom-2020-05-26.bin and pieeprom-2020-05-15.bin.

Step 1. Flash the eeprom and vl805 with the following config:

Code: Select all

BOOT_UART=1
WAKE_ON_GPIO=1
DHCP_TIMEOUT=10000
DHCP_REQ_TIMEOUT=4000
TFTP_TIMEOUT=2000
TFTP_PREFIX=0
BOOT_ORDER=0x2
SD_BOOT_MAX_RETRIES=3
NET_BOOT_MAX_RETRIES=1
SELF_UPDATE=1

Main here is enabled SELF_UPDATE and a single TFTP boot option.
Here is the serial console output of eeprom update process.
As we see - vl805.bin was already up-to-date (i.e. 137ad), bootloader reports 0 bytes difference and skips it's update. EEPROM had 1 byte difference (that's correct, I've changed only BOOT_ORDER from 0x1 to 0x2) and proceeds with writing.
Now RPi is in the state when during next power cycle it will attempt to boot over TFTP.

Step 2. Prepare TFTP server.
A dnsmasq server was started, ready to serve the latest firmware blobs, device trees and kernels (i.e. all the required stuff to boot). The config.txt is the following:

Code: Select all

arm_64bit=1
gpu_mem=16

bootloader_update=1

enable_uart=1
dtoverlay=disable-bt
dtoverlay=disable-wifi
dtparam=audio=on
dtparam=i2c_arm=on
dtparam=spi=on

The main thing here is bootloader_update=1

According to SELF_UPDATE documentation I've also placed copies of previously flashed pieeprom.upd and vl805.bin files to the TFTP server (*.sig files included). Expectation - bootloader will request them, but no update should happen (as they are identical) and proceed with kernel boot.

Step 3. Infinite boot cycle.
Once rpi is turned on, it obtains IP address and starts requesting TFTP server:
- dnsmasq.log
- tftp_boot.log

What is unexpected here: the received vl805.bin is detected as different than the one which is flashed. Thus it's getting flashed and the process finishes with reset.
Under closer inspection I see that on every boot cycle - the amount of bytes difference is slightly varying:
- 1st boot: 94343 bytes differ
- 2nd boot: 94340 bytes differ
- 3rd boot: 94344 bytes differ
- ...
The pieeprom.upd is correctly identified as an up to date.

Now RPi is in the state of infinite boot -> update_vl805 -> reset loop.

[dickon]

I saw the same thing with the April firmware. Ended up nuking the files from the server, as it didn't seem to obey the bootloader_update flag, either.

[HawaiianPi]

EDIT
Tested with the new USB-MSD boot EEPROM update - 2020-05-28 (along with rpi-update) and all seems well.

Post has below been updated.
Tested with my known good Eluteng USB 3.0 to SATA-III adapter cable (ASMedia ASM1153E), and it worked fine (although I didn't have trouble with the previous version). Then I tested a JMicron adapter that needed quirks to boot (with the quirks) and that also worked.

Eluteng/ASMedia VID:PID = 174c:55aa
Generic JMicron VID:PID = 152d:0578 (usb-storage.quirks=152d:0578:u)

I didn't use the recovery SD card as suggested because I wanted a different configuration, so I just extracted the .zip and did the procedure I used previously to update my boot SSD.

Code: Select all

rpi-eeprom-config pieeprom.bin > bootconf.txt
nano bootconf.txt
rpi-eeprom-config --out pieeprom-usbboot.bin --config bootconf.txt pieeprom.bin
sudo rpi-eeprom-update -d -f ./pieeprom-usbboot.bin
sudo reboot

During reboot I saw the EEPROM programming output on my serial terminal, and didn't see any errors.

After reboot I checked the bootloader version and configuration, and everything was correct (bold is what I changed).

tim@RaspberryPi4B2:~$ vcgencmd bootloader_version
May 28 2020 08:22:33
version 7b40bda408e631812ad00ea210b149e7141d68ec (release)
timestamp 1590650553

tim@RaspberryPi4B2:~$ vcgencmd bootloader_config
[all]
BOOT_UART=1
WAKE_ON_GPIO=0
POWER_OFF_ON_HALT=1
DHCP_TIMEOUT=45000
DHCP_REQ_TIMEOUT=4000
TFTP_FILE_TIMEOUT=30000
ENABLE_SELF_UPDATE=1
DISABLE_HDMI=0
SD_BOOT_MAX_RETRIES=0
USB_MSD_BOOT_MAX_RETRIES=2
BOOT_ORDER=0xf41

tim@RaspberryPi4B2:~$ uname -a
Linux RaspberryPi4B2 5.4.42-v8+ #1319 SMP PREEMPT Wed May 20 14:18:56 BST 2020 aarch64 GNU/Linux

So, another job well done! Thanks again timg236, from another Tim.

[timg236]

What is unexpected here: the received vl805.bin is detected as different than the one which is flashed. Thus it's getting flashed and the process finishes with reset.
Under closer inspection I see that on every boot cycle - the amount of bytes difference is slightly varying:
- 1st boot: 94343 bytes differ
- 2nd boot: 94340 bytes differ
- 3rd boot: 94344 bytes differ
- ...
The pieeprom.upd is correctly identified as an up to date.

Now RPi is in the state of infinite boot -> update_vl805 -> reset loop.

That's a bit weird. It's as though the update has been successfully applied but the read of the VLI EEPROM is returning garbage.

Does USB work if you force an SD card boot? There is a vl805 command-line utility can be used to read the contents of the VLI EEPROM from Linux https://github.com/raspberrypi/rpi-eepr ... r/firmware

It might be worth using the Raspberry Pi Imager to flash the EEPROM via an SD card to see if that gets it to a stable state.
https://github.com/raspberrypi/rpi-eepr ... 5.27-137ad

The bootloader verifies the SHA256 of the EEPROM image before applying the VL805 update so it feels like an issue talking to the VLI.

[vintozver]

Applied this version (flashed eeprom, copied fixup*.dat & start*.elf to the boot fat32 partition).

I see the bootloader recognizing my HDD (MSD LUN 0 ...). Takes around 10 seconds, fail, next try, then screen just goes blank, nothing else happens, no boot rainbow.

Code: Select all

$ sudo parted /dev/sda
GNU Parted 3.2
Using /dev/sda
Welcome to GNU Parted! Type 'help' to view a list of commands.
(parted) print
Model: Seagate BUP BK (scsi)
Disk /dev/sda: 5001GB
Sector size (logical/physical): 512B/4096B
Partition Table: gpt
Disk Flags:

Number  Start   End    Size   File system  Name  Flags
 1      17.4kB  271MB  271MB  fat32        boot  boot, esp
 

Code: Select all

SD CMD: 0x371a0010 (55) 0x0 0x1fff0001
Boot mode: USB-MSD (04) order f
XHCI-STOP
xHC ports 5 slots 32 intrs 4
USB3 rport 2 status 00000000 -> 000002a0
USB3 rport 3 status 00000000 -> 000002a0
USB3 rport 4 status 00000000 -> 000002a0
USB3 rport 5 status 00000000 -> 000002a0
USB2 rport 1 status 400002f1 -> 40200e03
DEV [01:00] 2.16 000000:01 class 9 VID 2109 PID 3431
HUB init [01:00] 2.16 000000:01
USB3 rport 3 status 000002a0 -> 00021203
DEV [02:01] 1.16 000004:01 class 0 VID 1915 PID 1028
DEV [03:00] 3.00 000000:03 class 0 VID 0bc2 PID ab28
MSD device [03:00] 3.00 000000:03 conf 0 iface 0 ep 81#1024 02#1024
PM_RSTS: 0x00001000
XHCI-STOP
Boot mode: RESTART (0f) order 0
Boot mode: SD (01) order f4
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 HOST: 250000000 CTL0: 0x00000000 BUS: 100000 Hz actual: 100000 HZ div: 2500 (1250) status: 0x1fff0000 delay: 1080
SD HOST: 250000000 CTL0: 0x00000000 BUS: 100000 Hz actual: 100000 HZ div: 2500 (1250) status: 0x1fff0000 delay: 1080
SDV1
SD HOST: 250000000 CTL0: 0x00000000 BUS: 100000 Hz actual: 100000 HZ div: 2500 (1250) status: 0x1fff0000 delay: 1080
SD CMD: 0x371a0010 (55) 0x0 0x1fff0001
Retry SD 1/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 HOST: 250000000 CTL0: 0x00000000 BUS: 100000 Hz actual: 100000 HZ div: 2500 (1250) status: 0x1fff0000 delay: 1080
SD HOST: 250000000 CTL0: 0x00000000 BUS: 100000 Hz actual: 100000 HZ div: 2500 (1250) status: 0x1fff0000 delay: 1080
SDV1
SD HOST: 250000000 CTL0: 0x00000000 BUS: 100000 Hz actual: 100000 HZ div: 2500 (1250) status: 0x1fff0000 delay: 1080
SD CMD: 0x371a0010 (55) 0x0 0x1fff0001
Boot mode: USB-MSD (04) order f
XHCI-STOP
xHC ver: 256 HCS: 05000420 fc000031 00e70004 HCC: 002841eb
xHC ports 5 slots 32 intrs 4
USB3 rport 2 status 00000000 -> 000002a0
USB3 rport 3 status 00000000 -> 000002b1
USB3 rport 4 status 00000000 -> 000002a0
USB3 rport 5 status 00000000 -> 000002a0
USB2 rport 1 status 00000000 -> 400002e1
USB2 rport 1 status 400002f1 -> 40200e03
DEV [01:00] 2.16 000000:01 class 9 VID 2109 PID 3431
HUB init [01:00] 2.16 000000:01
USB3 rport 3 status 000002b1 -> 00281203
DEV [02:00] 3.00 000000:03 class 0 VID 0bc2 PID ab28
MSD device [02:00] 3.00 000000:03 conf 0 iface 0 ep 81#1024 02#1024
PM_RSTS: 0x00001000
MBR: 0x00000001,4294967295 type: 0xee
MBR: 0x00000000,       0 type: 0x00
MBR: 0x00000000,       0 type: 0x00
MBR: 0x00000000,       0 type: 0x00
GPT 808346296bbdac4baf08da8dbc3b0ec5 000000001 24630d9ae num-partitions 128 entry-size 128
GPT partition: 0 28732ac11ff8d211ba4b00a0c93ec93b 000000022..0000816e0
   EVT (32) e0 51 f9 3f 00 00 00 00 0d 00 00 03 01 80 03 02
   CMD (1) 88 f0 f8 3f 00 00 00 00 0d 00 00 00 21 04 00 00
SLOT IN
00 00 40 18 00 00 03 00
00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00
SLOT OUT
00 00 40 20 00 00 03 00
00 00 00 00 02 00 00 18
00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00
EP0 CTX
01 00 00 00 26 00 00 02
01 92 f4 3f 00 00 00 00
08 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00
Read autoboot.txt failed
PM_RSTS: 0x00001000

Ideas?

[alkersan]

That's a bit weird. It's as though the update has been successfully applied but the read of the VLI EEPROM is returning garbage.

Does USB work if you force an SD card boot? There is a vl805 command-line utility can be used to read the contents of the VLI EEPROM from Linux https://github.com/raspberrypi/rpi-eepr ... r/firmware

Yes, if I eliminate the reset loop (by removing the vl805.bin from tftp) - RPi boots as usual and USB devices are detected and mounted correctly. So there is no data corruption during flash. I tend to agree that there might be an error during vl805.bin content comparison in the bootloader.

It might be worth using the Raspberry Pi Imager to flash the EEPROM via an SD card to see if that gets it to a stable state.
https://github.com/raspberrypi/rpi-eepr ... 5.27-137ad

The bootloader verifies the SHA256 of the EEPROM image before applying the VL805 update so it feels like an issue talking to the VLI.

Agree, let's eliminate TFTP from the equation. I've made few experiments with the referenced eeprom releases. rpi-imager was used for sdcard preparation. After the flash I've power cycled rpi few times without removing the sdcard. Here are the serial logs:
- rpi-boot-eeprom-recovery-2020-05-27-vl805-000137ad-BETA.log
- rpi-boot-eeprom-recovery-2020-05-26-vl805-000137ad-BETA.log
- rpi-boot-eeprom-recovery-2020-04-16-vl805-000137ad.log

The pattern repeats - every time the reported amount of bytes difference for vl805.bin is slightly different and it is flashed every time. Is that makes sense?

[timg236]

That's a bit weird. It's as though the update has been successfully applied but the read of the VLI EEPROM is returning garbage.

Does USB work if you force an SD card boot? There is a vl805 command-line utility can be used to read the contents of the VLI EEPROM from Linux https://github.com/raspberrypi/rpi-eepr ... r/firmware

Yes, if I eliminate the reset loop (by removing the vl805.bin from tftp) - RPi boots as usual and USB devices are detected and mounted correctly. So there is no data corruption during flash. I tend to agree that there might be an error during vl805.bin content comparison in the bootloader.

It might be worth using the Raspberry Pi Imager to flash the EEPROM via an SD card to see if that gets it to a stable state.
https://github.com/raspberrypi/rpi-eepr ... 5.27-137ad

The bootloader verifies the SHA256 of the EEPROM image before applying the VL805 update so it feels like an issue talking to the VLI.

Agree, let's eliminate TFTP from the equation. I've made few experiments with the referenced eeprom releases. rpi-imager was used for sdcard preparation. After the flash I've power cycled rpi few times without removing the sdcard. Here are the serial logs:
- rpi-boot-eeprom-recovery-2020-05-27-vl805-000137ad-BETA.log
- rpi-boot-eeprom-recovery-2020-05-26-vl805-000137ad-BETA.log
- rpi-boot-eeprom-recovery-2020-04-16-vl805-000137ad.log

The pattern repeats - every time the reported amount of bytes difference for vl805.bin is slightly different and it is flashed every time. Is that makes sense?

Thanks, that makes sense. The update process is essentially a remote SPI read PCI config space on the VLI chip but it looks as though garbage is appearing on this and maybe some other boards. The write and subsequent readback appear to be successful so the obvious hack is to read it twice but I'd rather understand the root cause!

There isn't an explicit size. It's just data followed by all zeros (possibly all ones actually) but if there is garbage appearing then the size will change a bit.

I've raised a Github issue for this - unless I can see something via code inspection or find a board that reproduces it locally I'll need to create an instrumented build (probably next week). Would you be able to run that and collect logs?
https://github.com/raspberrypi/rpi-eeprom/issues/134

[alkersan]

I've raised a Github issue for this - unless I can see something via code inspection or find a board that reproduces it locally I'll need to create an instrumented build (probably next week). Would you be able to run that and collect logs?
https://github.com/raspberrypi/rpi-eeprom/issues/134

Here is a simpler way to reproduce the infinite reboot cycle, just using sdcard boot and the latest firmware (the one where SELF_UPDATE is enabled by default).

1. Flash the EEPROM (checked 2020-05-27 and 2020-05-26). The only change in the conf is BOOT_UART=1, to get the logs. Everything else is left by default:

Code: Select all

[all]
BOOT_UART=1
WAKE_ON_GPIO=1
POWER_OFF_ON_HALT=0
DHCP_TIMEOUT=45000
DHCP_REQ_TIMEOUT=4000
TFTP_FILE_TIMEOUT=30000
ENABLE_SELF_UPDATE=1
DISABLE_HDMI=0
SD_BOOT_MAX_RETRIES=1
USB_MSD_BOOT_MAX_RETRIES=1
BOOT_ORDER=0xf41

2. Prepare fresh raspbian sdcard using rpi-imager. Append following parameters to the end of config.txt:

Code: Select all

enable_uart=1
bootloader_update=1

3. Copy the vl805.bin and vl805.sig files to the raspbian boot directory (pieeprom files aren't event needed).
Now we're in the state when during next power cycle the bootloader should check the vl805 files and decide whether or not to flash them. This is the sole purpose of SELF_UPDATE, right?

3. Boot the RPi. It goes into infinite reset cycle. Here are the serial logs:
- sdcard_boot_2020-05-27_eeprom_vl805_present_on_boot.log

Upd: further updates i'll post to the referenced github issue.

[Kendek]

The update process is essentially a remote SPI read PCI config space on the VLI chip but it looks as though garbage is appearing on this and maybe some other boards.

As I wrote that my SELF_UPDATE test was successful, I feel I need to clarify that I didn’t try to update the VLI EEPROM. Simple because I'm on version 0138a1, so there is no need for update.
Although I would like to test it, but I don't have any USB-to-TTL cable yet to observe the UART output. And this bug seems to be able to fry the VLI chip.

[alkersan]

SELF_UPDATE bootconf parameter was renamed into ENABLE_SELF_UPDATE, correct?

[RonR]

3. Boot the RPi. It goes into infinite reset cycle. Here are the serial logs:
- sdcard_boot_2020-05-27_eeprom_vl805_present_on_boot.log

In updating to the later bootloader beta [Wed 27 May 11:50:19 UTC 2020 (1590580219)], vl805 version 000137ad overwrote the version 00138a1 I had been using. Simply attempting to reload version 000138a1 while booted from an SD card using:

Code: Select all

rpi-eeprom-update -u vl805-000138a1.bin

got me into the infinite reset cycle.

I had to manually remove the vl805 and recovery files from the boot partition to be able to boot properly. Everything was alright at that point.

[Kendek]

...
In updating to the later bootloader beta [Wed 27 May 11:50:19 UTC 2020 (1590580219)]
...

There is a new beta release (May 27 2020 18:24:25) with a fix for this VL805 self-update bug.

[RonR]

...
In updating to the later bootloader beta [Wed 27 May 11:50:19 UTC 2020 (1590580219)]
...

There is a new beta release (May 27 2020 18:24:25) with a fix for this VL805 self-update bug.

Thanks.

I updated the bootloader to: Wed 27 May 17:47:29 UTC 2020 (1590601649)

Now after a vl805 update, everything simply dies until you delete RECOVERY.000, vl805.sig, and vl805.bin. The update actually took, but you can't boot until you manually remove those files.

[vintozver]

Code: Select all

CBW 00000044 00000a00 fff8f074 00000000
MSD [03:00] 3.00 000000:03 CSW 53425355 00000044 00000000 00000000
MBR: 0x00000001,4294967295 type: 0xee
MBR: 0x00000000,       0 type: 0x00
MBR: 0x00000000,       0 type: 0x00
MBR: 0x00000000,       0 type: 0x00
GPT 808346296bbdac4baf08da8dbc3b0ec5 000000001 24630d9ae num-partitions 128 entry-size 128
GPT partition: 0 28732ac11ff8d211ba4b00a0c93ec93b 000000022..0000816e0
MSD [03:00] 3.00 000000:03 READ lun 0 addr: 34 count: 1
CBW 00000045 00000200 fff8f074 00000000
MSD [03:00] 3.00 000000:03 CSW 53425355 00000045 00000000 00000000
REQ [01:00] 2.16 000000:01 ep 0 163,0,0,1 4 @ 0x00000004
MSD [03:00] 3.00 000000:03 READ lun 0 addr: 8222 count: [b]-8158[/b]
CBW 00000046 ffc04400 fff8f074 00000000
REQ [01:00] 2.16 000000:01 ep 0 163,0,0,2 4 @ 0x00000004
REQ [01:00] 2.16 000000:01 ep 0 163,0,0,3 4 @ 0x00000004
REQ [01:00] 2.16 000000:01 ep 0 163,0,0,4 4 @ 0x00000004
   EVT (32) d0 65 f9 3f 00 00 00 00 0d 00 00 03 00 80 03 03
   CMD (1) 88 f0 f8 3f 00 00 00 00 0d 00 00 00 21 04 00 00
SLOT IN
00 00 40 18 00 00 03 00
00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00
SLOT OUT
00 00 40 20 00 00 03 00
00 00 00 00 03 00 00 18
00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00
EP0 CTX
01 00 00 00 26 00 00 02
01 94 f4 3f 00 00 00 00
08 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00
Read autoboot.txt failed
PM_RSTS: 0x00001000

issues with large disks?

[RonR]

1. Flash the EEPROM (checked 2020-05-27 and 2020-05-26). The only change in the conf is BOOT_UART=1, to get the logs.

Is it possible to capture these boot logs using PUTTY connected via serial? I can log in using PUTTY over serial, but I can't get any boot logging output of any sort when I reboot.

[alkersan]

Is it possible to capture these boot logs using PUTTY connected via serial? I can log in using PUTTY over serial, but I can't get any boot logging output of any sort when I reboot.

Yes it is (screenshot). Terminal program doesn't really mater. It's just BOOT_UART=1 should be set in booloader config.

[RonR]

Is it possible to capture these boot logs using PUTTY connected via serial? I can log in using PUTTY over serial, but I can't get any boot logging output of any sort when I reboot.

Yes it is (screenshot). Terminal program doesn't really matter. It's just BOOT_UART=1 should be set in booloader config.

Thanks for the screenshot. It led me to my PUTTY configuration that had XON/XOFF enabled on the serial session definition.

[jdb]

...
In updating to the later bootloader beta [Wed 27 May 11:50:19 UTC 2020 (1590580219)]
...

There is a new beta release (May 27 2020 18:24:25) with a fix for this VL805 self-update bug.

Thanks.

I updated the bootloader to: Wed 27 May 17:47:29 UTC 2020 (1590601649)

Now after a vl805 update, everything simply dies until you delete RECOVERY.000, vl805.sig, and vl805.bin. The update actually took, but you can't boot until you manually remove those files.

I'll try and reproduce this. What are the specific steps you do in order to trigger a hang?
As in, what are the states/versions of the boot EEPROM and the VLI EEPROM at the start of day, and what state are you trying to get to?

[timg236]

I pushed the fix again, there was a secondary change which appeared in the binary release but not in Git due to finger trouble so I've just replaced it with 2020-05-28. The APT package might not get updated until next week because we are busy with the new Pi OS release.

The binary release rescue image
https://github.com/raspberrypi/rpi-eepr ... 5.28-137ad

It's possible to grab the files from Github but you'll need to add the -i flag to instruct the script to skip the validation against the package manifest checksums because they won't match.

[RonR]

There is a new beta release (May 27 2020 18:24:25) with a fix for this VL805 self-update bug.

Thanks.

I updated the bootloader to: Wed 27 May 17:47:29 UTC 2020 (1590601649)

Now after a vl805 update, everything simply dies until you delete RECOVERY.000, vl805.sig, and vl805.bin. The update actually took, but you can't boot until you manually remove those files.

I'll try and reproduce this. What are the specific steps you do in order to trigger a hang?
As in, what are the states/versions of the boot EEPROM and the VLI EEPROM at the start of day, and what state are you trying to get to?

BOOT: Wed 27 May 17:47:29 UTC 2020 (1590601649)

VL805: Going either way : 000138a1 / 000137ad

rpi-eeprom-update -u /lib/firmware/raspberrypi/bootloader/beta/vl805-000137ad.bin

or

rpi-eeprom-update -u /lib/firmware/raspberrypi/bootloader/beta/vl805-000138a1.bin

[jdb]

Yup, you were tripping over the bug that's fixed in the 2020-05-28 release.

[bunklung]

Should that other thread be closed at this point? I think it may be causing confusion.

"Raspberry Pi 4 USB mass storage beta (beta means it not ready yet, and not officially released!)" here: viewtopic.php?f=63&t=274595

Thanks for all the test reports.

There's a new release of the bootloader (no rpi-update firmware changes) on the following thread.
viewtopic.php?f=63&t=275187

Once the binaries are available in APT (hopefully tomorrow) we'll probably lock this thread to reduce confusion and extract the best bits to a sticky.

[W. H. Heydt]

I'm seeing odd behavior...

Used apt to update/upgrade plus rpi-update my test system.

If I log in as user 'pi' everything is fine. If I use another ID, which was working fine prior to the update, the menu bar flashes present and not present several times, then disappears. The only way out of it that I've found is to reboot from a remote (PuTTY) session. Since this didn't happen before today's update and isn't happening on non-beta-test systems, I figure it's either something I did to this one Pi, or a bug in the beta software (not the EEPROM, but somewhere else).

Any suggestions?

Code: Select all

pi@ddc4test:~ $ sudo rpi-eeprom-update
BCM2711 detected
Dedicated VL805 EEPROM detected
BOOTLOADER: up-to-date
CURRENT: Wed 27 May 2020 05:47:29 PM UTC (1590601649)
 LATEST: Wed 27 May 2020 05:47:29 PM UTC (1590601649)
 FW DIR: /lib/firmware/raspberrypi/bootloader/beta
VL805: up-to-date
CURRENT: 000137ad
 LATEST: 000137ad