sudo rpi-eeprom-update -f /lib/firmware/raspberrypi/bootloader/critical/pieeprom-2019-07-15.bin
sudo rpi-eeprom-update -u /lib/firmware/raspberrypi/bootloader/critical/vl805-00013701.bin

Ideally, these commands should place the following files in BOOTFS:

pieeprom.sig
pieeprom.upd
vl805.bin
vl805.sig

However, removePreviousUpdates will remove the first 2 when installing the second 2, and vice versa. There is no option to avoid this step.

Similarly, rpi-eeprom-update -A bootloader and rpi-eeprom-update -A vl805 do the same thing.

Hi,

I determined a problem with a usb sound device which is working without any problems on a RPi3 or a x86 Debian PC.

On RPi4 boot i get the following messages:

[ 5.812440] usb 1-1.1: new full-speed USB device number 3 using xhci_hcd
[ 5.967382] usb 1-1.1: New USB device found, idVendor=2573, idProduct=0004, bcdDevice= 1.00
[ 5.967403] usb 1-1.1: New USB device strings: Mfr=1, Product=2, SerialNumber=0
[ 5.967420] usb 1-1.1: Product: UDJ6
[ 5.967436] usb 1-1.1: Manufacturer: ESI Audiotechnik GmbH
[ 7.106603] usb 1-1.1: Not enough bandwidth for new device state.
[ 7.106773] usb 1-1.1: Not enough bandwidth for altsetting 1
[ 7.154563] usbcore: registered new interface driver snd-usb-audio

My guess is, that there must be a problem with the VL805 usb firmware.

If I run alsa speaker-test command I can reproduce the kernel bandwidth messages.

speaker-test -D hw:1 -c 6 -F S24_3LE

speaker-test 1.1.8

Playback device is hw:1
Stream parameters are 48000Hz, S24_3LE, 6 channels
Using 16 octaves of pink noise
Rate set to 48000Hz (requested 48000Hz)
Buffer size range from 96 to 58254
Period size range from 48 to 29127
Using max buffer size 58252
Periods = 4
Unable to set hw params for playback: Input/output error
Setting of hwparams failed: Input/output error

dmesg

[ 3406.656563] usb 1-1.1: Not enough bandwidth for new device state.
[ 3406.656676] usb 1-1.1: Not enough bandwidth for altsetting 1

Regards,

Björn

Describe the bug

Using an SSD disk inside a USB3 adaptor works as long as the PI has first been booted. A cold boot will not power up the USB drive.
This drive apparently requires a specific instruction to power on the disk: if I plug it on a computer, the light goes on, but if I plug it on a powered usb hub with no computer attached, it will not illuminate.

Same on the PI: using it while the Linux OS is running works fine, but a cold boot with just the disk will not power it on.

If I turn on the PI with an SD card, wait for the boot, issue an OS reboot and remove the SD when the screen goes black, the PI reboots on the hard disk as it's already ON.

Bootloader version and configuration
version 2020-05-15 with the default configuration

[all]
BOOT_UART=0
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

USB boot (please complete the following information):

Bus 002 Device 002: ID 174c:1351 ASMedia Technology Inc.
Device Descriptor:
  bLength                18
  bDescriptorType         1
  bcdUSB               3.10
  bDeviceClass            0
  bDeviceSubClass         0
  bDeviceProtocol         0
  bMaxPacketSize0         9
  idVendor           0x174c ASMedia Technology Inc.
  idProduct          0x1351
  bcdDevice            1.00
  iManufacturer           2 asmedia
  iProduct                3 ASMT1351
  iSerial                 1 123456789012
  bNumConfigurations      1
  Configuration Descriptor:
    bLength                 9
    bDescriptorType         2
    wTotalLength       0x0079
    bNumInterfaces          1
    bConfigurationValue     1
    iConfiguration          0
    bmAttributes         0xc0
      Self Powered
    MaxPower                0mA
    Interface Descriptor:
      bLength                 9
      bDescriptorType         4
      bInterfaceNumber        0
      bAlternateSetting       0
      bNumEndpoints           2
      bInterfaceClass         8 Mass Storage
      bInterfaceSubClass      6 SCSI
      bInterfaceProtocol     80 Bulk-Only
      iInterface              0
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x81  EP 1 IN
        bmAttributes            2
          Transfer Type            Bulk
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0400  1x 1024 bytes
        bInterval               0
        bMaxBurst              15
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x02  EP 2 OUT
        bmAttributes            2
          Transfer Type            Bulk
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0400  1x 1024 bytes
        bInterval               0
        bMaxBurst              15
    Interface Descriptor:
      bLength                 9
      bDescriptorType         4
      bInterfaceNumber        0
      bAlternateSetting       1
      bNumEndpoints           4
      bInterfaceClass         8 Mass Storage
      bInterfaceSubClass      6 SCSI
      bInterfaceProtocol     98
      iInterface              0
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x81  EP 1 IN
        bmAttributes            2
          Transfer Type            Bulk
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0400  1x 1024 bytes
        bInterval               0
        bMaxBurst              15
        MaxStreams             32
        Data-in pipe (0x03)
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x02  EP 2 OUT
        bmAttributes            2
          Transfer Type            Bulk
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0400  1x 1024 bytes
        bInterval               0
        bMaxBurst              15
        MaxStreams             32
        Data-out pipe (0x04)
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x83  EP 3 IN
        bmAttributes            2
          Transfer Type            Bulk
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0400  1x 1024 bytes
        bInterval               0
        bMaxBurst              15
        MaxStreams             32
        Status pipe (0x02)
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x04  EP 4 OUT
        bmAttributes            2
          Transfer Type            Bulk
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0400  1x 1024 bytes
        bInterval               0
        bMaxBurst               0
        Command pipe (0x01)
Binary Object Store Descriptor:
  bLength                 5
  bDescriptorType        15
  wTotalLength       0x002a
  bNumDeviceCaps          3
  USB 2.0 Extension Device Capability:
    bLength                 7
    bDescriptorType        16
    bDevCapabilityType      2
    bmAttributes   0x0000f41e
      BESL Link Power Management (LPM) Supported
    BESL value     1024 us
    Deep BESL value    61440 us
  SuperSpeed USB Device Capability:
    bLength                10
    bDescriptorType        16
    bDevCapabilityType      3
    bmAttributes         0x00
    wSpeedsSupported   0x000e
      Device can operate at Full Speed (12Mbps)
      Device can operate at High Speed (480Mbps)
      Device can operate at SuperSpeed (5Gbps)
    bFunctionalitySupport   1
      Lowest fully-functional device speed is Full Speed (12Mbps)
    bU1DevExitLat          10 micro seconds
    bU2DevExitLat        2047 micro seconds
  SuperSpeedPlus USB Device Capability:
    bLength                20
    bDescriptorType        16
    bDevCapabilityType     10
    bmAttributes         0x00000001
      Sublink Speed Attribute count 1
      Sublink Speed ID count 0
    wFunctionalitySupport   0x1100
    bmSublinkSpeedAttr[0]   0x000a4030
      Speed Attribute ID: 0 10Gb/s Symmetric RX SuperSpeedPlus
    bmSublinkSpeedAttr[1]   0x000a40b0
      Speed Attribute ID: 0 10Gb/s Symmetric TX SuperSpeedPlus
can't get debug descriptor: Resource temporarily unavailable
Device Status:     0x000d
  Self Powered
  U1 Enabled
  U2 Enabled

I'm trying to make the pi PXE boot from a TFTP directory as described at Raspberry Pi4 network boot (BETA), but using TFTP_PREFIX_STR=rpi1/ (or even using rpi1/yadayada) makes the firmware load rpi1start4.elf instead of rpi1/start4.elf (or rpi1/yadayadastart4.elf). It seems there's a bug somewhere that makes is only use the basename of the prefix, which is a real bummer.

I'm using the /lib/firmware/raspberrypi/bootloader/beta/pieeprom-2019-11-18.bin bootloader.

BTW, where is the source-code for the bootloader code that handles TFTP_PREFIX_STR?

These are my changes to stock bootconf.txt file:

--- bootconf.txt.orig	2019-12-14 18:56:25.007004012 +0000
+++ bootconf.txt	2019-12-14 18:56:25.207005728 +0000
@@ -1,15 +1,17 @@
 [all]
-BOOT_UART=0
+BOOT_UART=1
 WAKE_ON_GPIO=1
 POWER_OFF_ON_HALT=0
 DHCP_TIMEOUT=45000
 DHCP_REQ_TIMEOUT=4000
 TFTP_FILE_TIMEOUT=30000
 TFTP_IP=
-TFTP_PREFIX=0
-BOOT_ORDER=0x1
+TFTP_PREFIX=1
+BOOT_ORDER=0x2
 SD_BOOT_MAX_RETRIES=3
-NET_BOOT_MAX_RETRIES=5
+NET_BOOT_MAX_RETRIES=-1
+TFTP_PREFIX_STR=rpi1/
+
 [none]
 FREEZE_VERSION=0

any estimation on availability?

Normal vfat partitions with id 0xef are not seen as valid boot partitions, changing it to 0xc makes it work, but make it more complicated for using generic images for different devices.

will support for 64bit be impletement,
debian64 archlinux64 and gentoopi64 is available.
vl805 and userland is working in 64bit

in addition to the current SD and ethernet boot options, i'm thinking the firmware should also support an SPI boot option

BOOT_ORDER=0x3 for example, would then boot from the configured SPI chip, loading start4.elf from it, and then that loads config.txt and kernel.img as normal

the bootconf.txt should have config to say which group of SPI pins to use (for example, 7-11 or 16-21)
which SPI controller to use (despite 19-21 sharing the main data/clock, they have different chip-enable lines, so using the right one can be important)
and of couse, which chip-enable to use within that controller

this would allow a hat style board with a large enough SPI chip, could hold start4.elf + a custom arm baremetal kernel

that kernel, could also be a full tianocore build, offering full uefi support, any SD card with a valid efi system partition would just boot, without needing firmware files

the external SPI chip can also use the existing filesystem that the internal one does, it already has support for named files and sharing code keeps the bootcode size small and saves development time

When are you planning implement booting from USB?

Thanks

Hi all,

I'm trying to boot an RPi 4 4GB unit using the latest master branch

The Pi seems to be endlessly looping at downloading files over TFTP. Doing a tcpdump reveals the following output

01:20:54.190362 IP 192.168.1.35.6970 > 192.168.1.199.69:  48 RRQ "d9780558/start.elf" octet tsize 0 blksize 1024
01:20:56.190341 IP 192.168.1.35.6970 > 192.168.1.199.69:  48 RRQ "d9780558/start.elf" octet tsize 0 blksize 1024
01:20:58.190323 IP 192.168.1.35.6970 > 192.168.1.199.69:  48 RRQ "d9780558/start.elf" octet tsize 0 blksize 1024
01:21:00.190311 IP 192.168.1.35.6970 > 192.168.1.199.69:  48 RRQ "d9780558/start.elf" octet tsize 0 blksize 1024
01:21:02.190267 IP 192.168.1.35.6970 > 192.168.1.199.69:  48 RRQ "d9780558/start.elf" octet tsize 0 blksize 1024
01:21:04.190242 IP 192.168.1.35.6970 > 192.168.1.199.69:  48 RRQ "d9780558/start.elf" octet tsize 0 blksize 1024
01:21:06.190234 IP 192.168.1.35.6970 > 192.168.1.199.69:  48 RRQ "d9780558/start.elf" octet tsize 0 blksize 1024
01:21:08.190188 IP 192.168.1.35.6970 > 192.168.1.199.69:  48 RRQ "d9780558/start.elf" octet tsize 0 blksize 1024
01:21:10.190168 IP 192.168.1.35.6970 > 192.168.1.199.69:  48 RRQ "d9780558/start.elf" octet tsize 0 blksize 1024
01:21:12.190137 IP 192.168.1.35.6970 > 192.168.1.199.69:  48 RRQ "d9780558/start.elf" octet tsize 0 blksize 1024
01:21:14.190117 IP 192.168.1.35.6970 > 192.168.1.199.69:  48 RRQ "d9780558/start.elf" octet tsize 0 blksize 1024
01:21:16.190091 IP 192.168.1.35.6970 > 192.168.1.199.69:  48 RRQ "d9780558/start.elf" octet tsize 0 blksize 1024
01:21:18.190075 IP 192.168.1.35.6970 > 192.168.1.199.69:  48 RRQ "d9780558/start.elf" octet tsize 0 blksize 1024
01:21:20.190055 IP 192.168.1.35.6970 > 192.168.1.199.69:  48 RRQ "d9780558/start.elf" octet tsize 0 blksize 1024
01:21:22.190003 IP 192.168.1.35.6970 > 192.168.1.199.69:  48 RRQ "d9780558/start.elf" octet tsize 0 blksize 1024
01:21:24.189886 IP 192.168.1.35.6970 > 192.168.1.199.69:  20 ERROR EUNDEF "Early terminate"
01:21:24.190017 IP 192.168.1.35.6971 > 192.168.1.199.69:  40 RRQ "config.txt" octet tsize 0 blksize 1024
01:21:26.190000 IP 192.168.1.35.6971 > 192.168.1.199.69:  40 RRQ "config.txt" octet tsize 0 blksize 1024
01:21:28.189974 IP 192.168.1.35.6971 > 192.168.1.199.69:  40 RRQ "config.txt" octet tsize 0 blksize 1024
01:21:30.189986 IP 192.168.1.35.6971 > 192.168.1.199.69:  40 RRQ "config.txt" octet tsize 0 blksize 1024
01:21:32.189942 IP 192.168.1.35.6971 > 192.168.1.199.69:  40 RRQ "config.txt" octet tsize 0 blksize 1024
01:21:34.189915 IP 192.168.1.35.6971 > 192.168.1.199.69:  40 RRQ "config.txt" octet tsize 0 blksize 1024
01:21:36.189890 IP 192.168.1.35.6971 > 192.168.1.199.69:  40 RRQ "config.txt" octet tsize 0 blksize 1024
01:21:38.189840 IP 192.168.1.35.6971 > 192.168.1.199.69:  40 RRQ "config.txt" octet tsize 0 blksize 1024
01:21:40.189840 IP 192.168.1.35.6971 > 192.168.1.199.69:  40 RRQ "config.txt" octet tsize 0 blksize 1024
01:21:42.189791 IP 192.168.1.35.6971 > 192.168.1.199.69:  40 RRQ "config.txt" octet tsize 0 blksize 1024
01:21:44.189792 IP 192.168.1.35.6971 > 192.168.1.199.69:  40 RRQ "config.txt" octet tsize 0 blksize 1024
01:21:46.189764 IP 192.168.1.35.6971 > 192.168.1.199.69:  40 RRQ "config.txt" octet tsize 0 blksize 1024
01:21:48.189712 IP 192.168.1.35.6971 > 192.168.1.199.69:  40 RRQ "config.txt" octet tsize 0 blksize 1024
01:21:50.189696 IP 192.168.1.35.6971 > 192.168.1.199.69:  40 RRQ "config.txt" octet tsize 0 blksize 1024
01:21:52.189668 IP 192.168.1.35.6971 > 192.168.1.199.69:  40 RRQ "config.txt" octet tsize 0 blksize 1024
01:21:54.189522 IP 192.168.1.35.6971 > 192.168.1.199.69:  20 ERROR EUNDEF "Early terminate"

I've tried disabling things such as letting the Pi negotiate the TFTP blocksize inside dnsmasq without success. I'm not sure if this is a bug or regression or what

https://github.com/raspberrypi/rpi-eeprom/blob/master/rpi-eeprom-update#L355

This check should be changed to make use of /proc/device-tree which should be more reliable.
cat /proc/cpuinfo on 4.19.x ARM64 kernel built from from raspberrypi/linux repo

processor       : 0
BogoMIPS        : 108.00
Features        : fp asimd evtstrm crc32 cpuid
CPU implementer : 0x41
CPU architecture: 8
CPU variant     : 0x0
CPU part        : 0xd08
CPU revision    : 3

processor       : 1
BogoMIPS        : 108.00
Features        : fp asimd evtstrm crc32 cpuid
CPU implementer : 0x41
CPU architecture: 8
CPU variant     : 0x0
CPU part        : 0xd08
CPU revision    : 3

processor       : 2
BogoMIPS        : 108.00
Features        : fp asimd evtstrm crc32 cpuid
CPU implementer : 0x41
CPU architecture: 8
CPU variant     : 0x0
CPU part        : 0xd08
CPU revision    : 3

processor       : 3
BogoMIPS        : 108.00
Features        : fp asimd evtstrm crc32 cpuid
CPU implementer : 0x41
CPU architecture: 8
CPU variant     : 0x0
CPU part        : 0xd08
CPU revision    : 3

The /lib/firmware/raspberrypi/bootloader/beta/pieeprom-2019-11-18.bin firmware requests the PXE (67) Bootfile name parameter, but the bootloader seems completely ignore it. At least when I return the filename as rpi1/start4.elf. Isn't this a bug?

Also, the bootloader requests some unknown/vendor PXE options, as displayed in Wireshark:

#         Option: (55) Parameter Request List
#             Length: 14
#             Parameter Request List Item: (1) Subnet Mask
#             Parameter Request List Item: (3) Router
#             Parameter Request List Item: (43) Vendor-Specific Information
#             Parameter Request List Item: (60) Vendor class identifier
#             Parameter Request List Item: (66) TFTP Server Name
#             Parameter Request List Item: (67) Bootfile name
#             Parameter Request List Item: (128) DOCSIS full security server IP [TODO]
#             Parameter Request List Item: (129) PXE - undefined (vendor specific)
#             Parameter Request List Item: (130) PXE - undefined (vendor specific)
#             Parameter Request List Item: (131) PXE - undefined (vendor specific)
#             Parameter Request List Item: (132) PXE - undefined (vendor specific)
#             Parameter Request List Item: (133) PXE - undefined (vendor specific)
#             Parameter Request List Item: (134) PXE - undefined (vendor specific)
#             Parameter Request List Item: (135) PXE - undefined (vendor specific)

Where is documentation about it?

Hi there
From boot loader 11/18/19
I'm testing the start of EMMC cards (ODroid with adapter)
Raspbian starts without problems.
PINN and NOOBS do not start.
Ubuntu 32Bit and 64bit do not start either.

It is important for me that EMMC starts. (3 SD cards already destroyed)
I test a lot

Sry for Google Translation ;-)

I am using my Pi as a NAS running OpenMediaVault - with a dual raid box connected via usb 3.
Before installing this update the USB drives lights and fans shutdown with the PI.
After the update fans and lights stay on - and then when I reboot the Pi the drives all reboot...

Describe the bug
With a Startech 3.5inch HDD enclosure (S3510BMU33) attached to a Pi 4, I cannot get it to boot from USB MSD. If one or more of these enclosures is attached at boot time, boot appears to stop when the bootloader tries to talk to this device. I have two of these enclosures, each with different brand of hard disk in them - both show the same problem.

To Reproduce
Steps to reproduce the behavior:

1. Configure Pi 4 for USB MSD boot per the instructions at https://www.raspberrypi.org/forums/viewtopic.php?f=63&t=274595#p1663644, leaving the SD card slot empty, and BOOT_ORDER=0xf41.

2. Attach at least one Startech S3510BMU33 hard disk enclosure to the Pi 4 and power it up using its own PSU.

3. Attach HDMI screen to the Pi 4 so you can see what is happening.

4. Apply power to Pi 4.

5. Observe bootloader output on HDMI screen.

Expected behaviour
Pi 4 should try each SD card boot, fail, try eachUSB device in turn looking for a bootable device, fail to find a bootable USB device and continue in a loop from SD card boot again.

Screenshots

Pi 4 gets stuck at the point shown in the screenshot, although it is still sending out trace packets over the network so it does appear to still be running OK, not hung.

Bootloader version and configuration

Bootloader configuration:
[all]
BOOT_UART=0
WAKE_ON_GPIO=1
POWER_OFF_ON_HALT=0
DHCP_TIMEOUT=45000
DHCP_REQ_TIMEOUT=4000
TFTP_FILE_TIMEOUT=30000
BOOT_ORDER=0xf41
SD_BOOT_MAX_RETRIES=1
USB_MSD_BOOT_MAX_RETRIES=1
ENABLE_SELF_UPDATE=1
DISABLE_HDMI=0
XHCI_DEBUG=0x23
[email protected]/eth0,6666@/

Bootloader version:
May 15 2020 11:05:52
version 23a9f59b85f5a81bb2eec455e064ef9905216322 (release)
timestamp 1589537152

USB boot (please complete the following information):
sudo lsusb -vvv output:
lsusb-vvv.txt.gz

Netconsole boot trace:
Startech-S3510BMU33-hdd-enclosure-w-hdd.pcapng.gz

Additional context
Problem occurs whether there is a usable USB MSD boot device attached or not (i.e. one that has been prepared and verified to boot the Pi 4 successfully). Problem does not occur with SD card boot, since the boot order is set to do SD card boot first. I would expect it to fail if it was the other way around, since the whole boot process stops, although the trace shows that the bootloader is still running and sending trace packets out over the network.

The network trace is done with the enclosure connected to a USB 3 hub. I have tried it with a USB 2.0 hub and it shows the same problem.

I have attempted to activate XHCI_DEBUG bits 5, 1 and 0, using the setting 0x23. I may have got that wrong.

Post this to the forum firstly, and I think it's better be here.

Hi, I'm a developer focused on network boot for about 20 years, mainly support x86 pc boot to Windows and Linux.
I got RPi4 just one week, already tested raspbian, ubuntu, debian and network boot.

some issues about network boot

0) testing environment
EEPROM version: pieeprom-2020-01-09.bin
DHCP/PXE/TFTP server: developed by myself.

1) in DHCP requests:
other than the MAC address, there is no any field to identify a RPi client,
option 93 is set to "0" means IA x86 PC
option 97 UUID just repeat serial no 4 times
the OUI(dc:a6:32) can be use, but it not reliable as my experience
why this needed?
because the PXE options need a special menu item to continue and need to identify x86(bios/uefi) and RPI
suggestion:
option 97, change to magic number + serial no, there is enough length
-or-
option 93, acquire a unique number for RPi (it's complex with IEEE/IANA/RFC...)
-or-
any other option not defined by RFC

2)in DHCP REQUEST packet, there is no PXEClient(60) option
this is not consistency whit DHCP DISCOVER packet.
in my server, I just skip the packets without PXEClient(60), many desktop/laptop/mobile will sent request, and some ones running like flood

3) in DHCP response option 0 (padding) is not handled properly
then this response ignored.
in some(many) not implemented very well DHCP/PXE bootrom, padding zero is required to let them got correct hostname / bootfile / etc...

4) TFTP download files
blocksize is 1024, could be larger?
is there any future plan to implement windowsize ? since start.elf / kernel / initrd are big, set windowsize > 1 to speed up downloading.

I have the following dnsmasq.conf that network boots both x86 computers as well as Raspberry Pi 3B+'s. However, I recently switched to Raspberry Pi 4's with the latest firmware (pieeprom-2019-11-18.bin) and this fails.

port=0
dhcp-range=192.168.0.255,proxy
enable-tftp
tftp-root=/tftp
tftp-unique-root

# chainload to iPXE then run boot.ipxe script
dhcp-userclass=set:ipxe,iPXE
pxe-service=tag:!ipxe, x86PC, "Chainloading iPXE", ipxe.pxe
pxe-service=tag:ipxe, x86PC, "iPXE Script", boot.ipxe

# required to have the Raspberry Pi PXE boot
pxe-service=0,"Raspberry Pi Boot"

# x86 chooses first pxe-service option immediately; ignored by Raspberry Pi
pxe-prompt="PXE",0

If I move the "Raspberry Pi Boot" line, as in the following, the Raspberry Pi 4 boots, but the x86 machine will not (unless I remove the pxe-prompt line and manually select iPXE):

port=0
dhcp-range=192.168.0.255,proxy
enable-tftp
tftp-root=/tftp
tftp-unique-root

# required to have the Raspberry Pi PXE boot
pxe-service=0,"Raspberry Pi Boot"

# chainload to iPXE then run boot.ipxe script
dhcp-userclass=set:ipxe,iPXE
pxe-service=tag:!ipxe, x86PC, "Chainloading iPXE", ipxe.pxe
pxe-service=tag:ipxe, x86PC, "iPXE Script", boot.ipxe

# x86 chooses first pxe-service option immediately; ignored by Raspberry Pi
pxe-prompt="PXE",0

I'm currently trying to figure out if I can modify the code in such a way to get both the Raspberry Pi 4 and x86 computers to network boot automatically. But I thought I'd file a bug report since the behavior is different than Raspberry Pi 3B+.

I'm not sure which is correctly implemented, but the different behavior between the Pi 3B+ and Pi 4B merits a closer look. Thanks!

Describe the bug
Blank DPI screen after install USB-MSD beta bootloader

Bootloader version and configuration
pieeprom-2020-05-26.bin and earlier

See raspberrypi/firmware#1397 with experimental fix

Hello.
I have about 15 RPI4s and I tested pieeprom-2019-09-25.bin.
All boots to login prompt (eg. DHCP, TFTP, NFS seems to be OK - firmware+kernel from rpi-update) but about 50% of RPI4 have VideoCore blocked ("vcgencmd" hung).

See differences in "bcm2835-codec bcm2835-codec" startup:

# ### DMESG from OK
grep bcm2835 dmesg_o
[    0.000000] Kernel command line: coherent_pool=1M 8250.nr_uarts=1 cma=64M cma=256M video=HDMI-A-1:1280x1024M@60,margin_left=0,margin_right=0,margin_top=0,margin_bottom=0 smsc95xx.macaddr=DC:A6:32:0B:63:09 vc_mem.mem_base=0x3ec00000 vc_mem.mem_size=0x40000000  dwc_otg.lpm_enable=0 console=ttyAMA0,115200 console=tty1 root=/dev/nfs nfsroot=10.199.100.21:/nfs/rootfs,vers=3,nolock ro ip=dhcp elevator=deadline rootwait logo.nologo systemd.show_status=no bcm2835_wdt.nowayout=1 bcm2835_wdt.heartbeat=10
[    0.034134] bcm2835-mbox fe00b880.mailbox: mailbox enabled
[    0.069387] bcm2835-dma fe007000.dma: DMA legacy API manager at (ptrval), dmachans=0x1
[    0.326814] gpiomem-bcm2835 fe200000.gpiomem: Initialised: Registers at 0xfe200000
[    0.960963] bcm2835-wdt bcm2835-wdt: Broadcom BCM2835 watchdog timer
[    0.962895] bcm2835-cpufreq: min=600000 max=1500000
[    1.262263] bcm2835-power bcm2835-power: Broadcom BCM2835 power domains driver
[   10.548433] bcm2835_vc_sm_cma_probe: Videocore shared memory driver
[   10.563911] bcm2835_mmal_vchiq: module is from the staging directory, the quality is unknown, you have been warned.
[   10.573834] bcm2835_codec: module is from the staging directory, the quality is unknown, you have been warned.
[   10.602303] bcm2835-codec bcm2835-codec: Device registered as /dev/video10
[   10.602338] bcm2835-codec bcm2835-codec: Loaded V4L2 decode
[   10.613746] bcm2835-codec bcm2835-codec: Device registered as /dev/video11
[   10.613788] bcm2835-codec bcm2835-codec: Loaded V4L2 encode
[   10.621454] bcm2835-codec bcm2835-codec: Device registered as /dev/video12
[   10.621487] bcm2835-codec bcm2835-codec: Loaded V4L2 isp
[   10.626609] bcm2835_v4l2: module is from the staging directory, the quality is unknown, you have been warned.
[   10.849370] snd_bcm2835: module is from the staging directory, the quality is unknown, you have been warned.
[   10.859843] bcm2835_audio soc:audio: card created with 8 channels

# ### DMESG from hung
grep bcm2835 dmesg_e
[    0.000000] Kernel command line: coherent_pool=1M 8250.nr_uarts=1 cma=64M cma=256M video=HDMI-A-1:1280x1024M@60,margin_left=0,margin_right=0,margin_top=0,margin_bottom=0 smsc95xx.macaddr=DC:A6:32:0B:66:E3 vc_mem.mem_base=0x3ec00000 vc_mem.mem_size=0x40000000  dwc_otg.lpm_enable=0 console=ttyAMA0,115200 console=tty1 root=/dev/nfs nfsroot=10.199.100.21:/nfs/rootfs,vers=3,nolock ro ip=dhcp elevator=deadline rootwait logo.nologo systemd.show_status=no bcm2835_wdt.nowayout=1 bcm2835_wdt.heartbeat=10
[    0.034189] bcm2835-mbox fe00b880.mailbox: mailbox enabled
[    0.069679] bcm2835-dma fe007000.dma: DMA legacy API manager at (ptrval), dmachans=0x1
[    0.326883] gpiomem-bcm2835 fe200000.gpiomem: Initialised: Registers at 0xfe200000
[    0.960830] bcm2835-wdt bcm2835-wdt: Broadcom BCM2835 watchdog timer
[    0.962780] bcm2835-cpufreq: min=600000 max=1500000
[    1.280745] bcm2835-power bcm2835-power: Broadcom BCM2835 power domains driver
[   10.525541] bcm2835_vc_sm_cma_probe: Videocore shared memory driver
[   10.607926] bcm2835_mmal_vchiq: module is from the staging directory, the quality is unknown, you have been warned.
[   10.643553] bcm2835_v4l2: module is from the staging directory, the quality is unknown, you have been warned.
[   10.643558] bcm2835_codec: module is from the staging directory, the quality is unknown, you have been warned.
[   10.655302] bcm2835-codec bcm2835-codec: Device registered as /dev/video10
[   10.655339] bcm2835-codec bcm2835-codec: Loaded V4L2 decode
[   10.933601] snd_bcm2835: module is from the staging directory, the quality is unknown, you have been warned.
[   10.964786] bcm2835_audio soc:audio: card created with 8 channels
[   13.671798] bcm2835_mmal_vchiq: timed out waiting for sync completion
[   16.711764] bcm2835_mmal_vchiq: timed out waiting for sync completion

dmesg_e.gz
dmesg_o.gz

this is part of #82

1) in DHCP requests:
other than the MAC address, there is no any field to identify a RPi client,
option 93 is set to "0" means IA x86 PC
option 97 UUID just repeat serial no 4 times
the OUI(dc:a6:32) can be use, but it not reliable as my experience
why this needed?
because the PXE options need a special menu item to continue and need to identify x86(bios/uefi) and RPI
suggestion:
option 97, change to magic number + serial no, there is enough length
-or-
option 93, acquire a unique number for RPi (it's complex with IEEE/IANA/RFC...)
-or-
any other option not defined by RFC

2)in DHCP REQUEST packet, there is no PXEClient(60) option
this is not consistency whit DHCP DISCOVER packet.
in my server, I just skip the packets without PXEClient(60), many desktop/laptop/mobile will sent request, and some ones running like flood

@timg236 as you mentioned

I'd suggest an EEPROM config for customizing Option97 e.g.
magic + board-revision + serial + reserved

I think it's a very good idea.
a new video shown netboot to Archlinux and Debian

Hi,

It seems that the SSH isn't working while netbooting, even after activating it with raspi-config before rsyncing it to the servers. Also, adding ssh file to both the TFTP boot root, TFTP boot specific to that raspberry or adding it to its filesystem directly does not seem to work...

Any fixes recommended?

Thank you!

All pieprom files have been following the YYYY-MM-DD format but last one 'pieeprom-2020-16-04.bin' is using YYYY-DD-MM, when next pieeeprom file will be released it would be more difficult to detect the last one as pieeprom-2020-16-04 would be the last in order during 2020.

$dpkg -s rpi-eeprom-images
Package: rpi-eeprom-images
Status: install ok installed
Priority: optional
Section: misc
Installed-Size: 10669
Maintainer: Serge Schneider [email protected]
Architecture: all
Source: rpi-eeprom
Version: 5.6-1
Description: Raspberry Pi 4 boot EEPROM images
This package contains the bootloader EEPROM images for Raspberry Pi 4
Homepage: https://github.com/raspberrypi/rpi-eeprom/

$ ls /lib/firmware/raspberrypi/bootloader/beta/pieeprom-*|tail -n 4
/lib/firmware/raspberrypi/bootloader/beta/pieeprom-2020-03-16.bin
/lib/firmware/raspberrypi/bootloader/beta/pieeprom-2020-03-19.bin
/lib/firmware/raspberrypi/bootloader/beta/pieeprom-2020-04-09.bin
/lib/firmware/raspberrypi/bootloader/beta/pieeprom-2020-16-04.bin

The documentation built into the rpi-eeprom-update tool does not specify that it only works on the Pi 4B. Since the package gets installed on all Raspberry Pis (which run Raspbian), it needs to document that it only does anything useful on the Pi 4B.

Would it be possible to include the version string returned by vcgencmd bootloader_version in an easy to query way inside the pieeprom.bin file itself? My naive approach would to be include another file (version.txt?) next to the already existing bootconf.txt. That way the mechanism in rpi-eeprom-config could be used. Or maybe another VERSION_MAGIC that's otherwise unused by the firmware itself?

This change would make automatically processing firmware file a bit easier.

If BOOT_ORDER is not specified then it should be 0xf41 instead of 0xf21 to enable SD->MSD instead of SD->NETWORK

Raspberry PI 4B
pieeprom-2019-12-03.bin

firmware has a problem while network booting to TFTP server.
If TFTP server's IP lass than 3 digits pieeprom pads to IP value 3 digits with a garbage.

/etc/dhcp/dhcpd.conf
option tftp-server-name "192.168.0.21";

tcpdump gets following string
00:12:47.464387 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 192.168.2.214 tell ...

our 192.168.0.21 becomes 192.168.2.214 and nothing comes to our real TFTP server, while we awaitig for requests on 192.168.0.21

in case we set 3 digit it works good
option tftp-server-name "192.168.0.211";

When I check for updates on my RPI4 raspbian 10 I see this:

Of course it is super there are continious improvements. But I seem not to be able to relate these version numbers anywhere. Any search on Google seems to exclude the version numbers.

TX,

i'm attempting to debug and document the exact rules for when recovery.bin gets ran by the boot rom

other issues have shown uart output when its running, so i have tried running it with only recover.bin and no other files, to ensure it only prints messages and cant flash

after several days of being confused by 4 blink codes, i used rpi-eeprom-update to reflash the eeprom and enable BOOT_UART=1

and thats when i confirmed/discovered, that recovery.bin itself, was giving the 4 blink code, which does not mean start*.elf not found as the forums claim

what blink codes is recovery.bin able to emit, and how do i convince it to print debug over the uart?

After updating with the rpi-eeprom my Pi is no longer powering down properly.

Once the screen goes blank and it appears the Pi is powered down, the SSD remains still powered on, both blue light and red light, and the Ethernet light is flashing continuously.

It would be a really great thing if the TFTP Blocksize Option (RFC 2348) could be specified in the bootconf.txt to use bigger values than the 512 bytes default. That would be helpful, to speed up the network boot of systems with "big" ramdisks.

1. tested 2020-03-04, option 97 already in new spec, but the ETH_MAC_LSB part is missing, the 4 bytes are all zero, not copied from my rpi4.
   tcpdump: rpi4.zip

2. another discuss of PXE_OPTION43: PXE menu option, maybe too late but just let's talk about it
   in previous version, the eeprom was check "Raspberry Pi" part only and can not modified, this version, it can be customized to any user specified string.
   as my guess, it's used for identify a "regular DHCP server" or a "netboot enabled DHCP server", but it's no need to so complicated, in a "regular" server, it will never set option-60("PXEClient"), then check option-60 is well enough
   is there any reason to make this mandatory?

3. any plan to support proxyDHCP mode? PXE spec support to get IP address from a "regular" server but get boot file/info from a proxyDHCP server.
   in a large network, users may not want/allow multi DHCP server co-exists, and may not "touch" the DHCP server at all, so proxyDHCP mode is very necessary.

Hi,

after the upgrade to 000137ad (latest stable) I have the issue, that the USB-hub "disappears" after ~18h.
[67672.041354] xhci_hcd 0000:01:00.0: xHCI host not responding to stop endpoint command.
[67672.057405] xhci_hcd 0000:01:00.0: Host halt failed, -110
[67672.057414] xhci_hcd 0000:01:00.0: xHCI host controller not responding, assume dead
[67672.057463] xhci_hcd 0000:01:00.0: HC died; cleaning up
[67672.057558] usb 1-1: USB disconnect, device number 2
[67672.057577] usb 1-1.4: USB disconnect, device number 3
[67672.057895] ftdi_sio ttyUSB0: ftdi_set_termios FAILED to set databits/stopbits/parity
[67672.057916] ftdi_sio ttyUSB0: ftdi_set_termios urb failed to set baudrate
[67672.057928] ftdi_sio ttyUSB0: failed to set flow control: -19
[67672.060856] ftdi_sio ttyUSB0: FTDI USB Serial Device converter now disconnected from ttyUSB0
[67672.060963] ftdi_sio 1-1.4:1.0: device disconnected

and lsusb:
root@xxxx:~ # lsusb
Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

after a reboot (without any disconnecting of cables, only "reboot"):
root@xxxx:~ # lsusb
Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 001 Device 003: ID 0403:6001 Future Technology Devices International, Ltd FT232 Serial (UART) IC
Bus 001 Device 002: ID 2109:3431 VIA Labs, Inc. Hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

In my eyes the most important difference is in dmesg:
-usb 1-1: New USB device found, idVendor=2109, idProduct=3431, bcdDevice= 4.20
+usb 1-1: New USB device found, idVendor=2109, idProduct=3431, bcdDevice= 4.21

This issue happens ~18h after reboot. The same hardware worked without any problems with the previrous stable eeprom-image for many weeks.

Any hints?

Robert

When run as a non-root user, rpi-eeprom-update shows the current and latest applicable version of bootloader EEPROM. It shows a blank space where the current VL805 EEPROM version should be, and shows the latest applicable VL805 EEPROM version that is available. When run using sudo it successfully retrieves the VL805 EEPROM version.

pi@livingroom:~ $ rpi-eeprom-update
Bootloader EEPROM is up to date
BOOTLOADER
CURRENT: Wed 16 Oct 17:00:03 UTC 2019 (1571245203)
LATEST: Tue 10 Sep 10:41:50 UTC 2019 (1568112110)
VL805
CURRENT:
LATEST: 000137ab
pi@livingroom:~ $ sudo rpi-eeprom-update
Bootloader EEPROM is up to date
BOOTLOADER
CURRENT: Wed 16 Oct 17:00:03 UTC 2019 (1571245203)
LATEST: Tue 10 Sep 10:41:50 UTC 2019 (1568112110)
VL805
CURRENT: 000137ab
LATEST: 000137ab

Raspberry Pi 4B (2GB). After failing to boot a fresh setup of the latest Raspbian, I followed the recommendation to make sure the EEPROM is in tact.

I took an sdcard, formatted with FAT32, and simply put the content of the .zip file from raspberrypi.org in it. I then put it in the Pi, plugged in the power and presented with 2 long flashes and then 4 short ones, repeatedly, which is apparently an undocumented error sequence.

Having no micro HDMI cable, I connected the serial pins to UART. The error in the console is:

Loading vl805.sig hnd: 0x00000031
Loading vl805.bin hnd: 0x0000002a
SHA256
00000000  12 67 75 0e 2e e8 49 b3  44 8a 93 fa 7b f2 92 90      | .gu...I. D...{...|
00000010  75 1c c8 98 a5 4d 76 ab  0d 6e c7 a4 7a c1 89 60      | u....Mv. .n..z..`|
File has Invalid/missing signature: 'vl805.sig' (65)
FATAL @ 0x8000654a

I tried to remove vl805.bin and vol805.sig completely, which brought me to the same error but in regards to pieeprom.sig/bin.

I also tried to replace the recovery.bin, vl805.bin and pieeeprom.bin files with more recent ones from this repo (and update the .sig files accordingly).

The voltage of the Pi is rock steady at 5.17vdc (exactly, constantly, for at least 15 seconds). I plugged the sdcard into a different pc with a different card reader, and checked the SHA256 of the files - they match the checksums inside the .sig files. I tried the procedure with 4 different sdcards, 1 of which is brand new and 1 is 100% working.

Trying to have Pi4 4GB do auto eeprom updates due to being net-booted
eeprom beta pieeprom-2020-04-16.bin
pi@raspi1:~ $ vcgencmd bootloader_config
[all]
BOOT_UART=0
WAKE_ON_GPIO=1
POWER_OFF_ON_HALT=0
DHCP_TIMEOUT=45000
DHCP_REQ_TIMEOUT=4000
TFTP_FILE_TIMEOUT=30000
TFTP_IP=
TFTP_PREFIX=0
BOOT_ORDER=0x21
SD_BOOT_MAX_RETRIES=3
NET_BOOT_MAX_RETRIES=5
[none]
FREEZE_VERSION=0
Follow instructions to extract, modify, re-apply, and re-install here:
https://www.raspberrypi.org/documentation/hardware/raspberrypi/bcm2711_bootloader_config.md
adding SELF_UPDATE=1 after the line [all], and before and after [none]
I have been able to have BOOT_ORDER=0x21 to do Net Boot, successfully.
Just can't get the SELF_UPDATE to stay.

rpi-eeprom-update tries to modprobe spi-bcm2835 after loading the spi-gpio40-45 overlay. If spi-bcm2835 is already loaded then modprobe will do nothing and the SPI pins won't change. flashrom will try to reflash whatever is connected to the SPI pins on the GPIO header.

Unloading spi-bcm2835 will be difficult so it is probably best to tell the user to disable SPI themselves to do the update.

I am planning on deploying about 30 Pi's in an industrial environment at individual work centers. I am going to use them much like a kiosk to do various web based functions. The pages I need to serve up are unique to each work center. Ideally I would like to boot directly to the needed page. The only way that I have thought to do that is if I could give each of the Pi's its own host name and use that host name to populate the link in the script I use to boot from. Is there any way that I could tie the description field under the Clients tab in PiServer to the hostname of each device?

I understand the desire to protect users from making mistakes, but I've just setup an RPi 4B with network boot (yay!), and as a result I have an SD card in the board with nothing on it. rpi-eeprom-update refused to put a bootloader update on that filesystem until I created a dummy .elf file. After doing that the bootloader file was placed there, I rebooted, and the board successfully applied the update and removed the file (and then proceeded on with its network boot).

If it's important to keep this check, then the documentation should probably be updated as a warning to others who are switching to network boot and won't have the usual contents of /boot in their SD card filesystem.

Raspbian package rpi-eeprom depends on python (from apt-cache show rpi-eeprom):

Package: rpi-eeprom
Version: 2.0-1
Architecture: all
Maintainer: Serge Schneider <[email protected]>
Installed-Size: 427
Depends: rpi-eeprom-images, libraspberrypi-bin, python, raspberrypi-bootloader (>= 1.20190819)
Recommends: flashrom
Homepage: https://github.com/raspberrypi/rpi-eeprom/
[...]

Python dependency defaults to Python2 and it is getting out of support in 2020. I have checked the program rpi-update and it works with Python3 (checked with Python 3.7.3), so I am wondering if it is possible to update the shebang and the Raspbian Deb package to depend on Python3.

Should raspberry_pi4_network_boot_beta.md be recommending https://github.com/raspberrypi/firmware as the source of latest firmware, rather than https://github.com/Hexxeh/rpi-update ?
ping @popcornmix

Hi

I am trying to netboot my pi4 with no success.

After plug the pi, the green LED is fix. I saw DHCP requests on my server.
The Pi keep requesting DHCP server and the server answer with the IP.
I only see DHCPDISCOVER and DHCPOFFER. No DHCPACK.

I have tried with pieeprom-2019-11-18.bin and pieeprom-2019-10-16.bin.

My dhcp server is a isc-dhcp on a Debian Jessie. Note that it works for a pi3.
The definition for the subnet is :

subnet 10.10.10.0 netmask 255.255.255.0 {
        interface eth0;
        allow unknown-clients;
        range 10.10.10.230 10.10.10.234;
        option subnet-mask 255.255.255.0;
        option routers 10.10.10.254;

        next-server 10.10.10.1;
        option tftp-server-name "10.10.10.1";
}

The LICENSE files states that everything in the root is:

Files: *
Copyright: 2019, Raspberry Pi (Trading) Ltd.
License: BSD-3"

Is the vl805 binary under this license? If so is the source published somewhere so it could be built for aarch64 use too? If not I believe the license needs to be clarified.

Describe the bug
When testing USB MSD boot, I received some messages like this:

USB MSD timed out after 10000 seconds

The timeout appears to actually be 10000 milliseconds, i.e. 10 seconds.

Originally reported in the forums at https://www.raspberrypi.org/forums/viewtopic.php?f=63&t=274595#p1663699

To Reproduce
Steps to reproduce the behavior:

Boot Pi 4 with no boot devices attached, and USB MSD boot enable in the bootloader config (e.g. BOOT_ORDER=0xf41).

Expected behaviour
seconds -> milliseconds

Screenshots

Bootloader version and configuration

pi@pi4b2hdd:~ $ vcgencmd bootloader_version
May 15 2020 11:05:52
version 23a9f59b85f5a81bb2eec455e064ef9905216322 (release)
timestamp 1589537152

and

pi@pi4b2hdd:~ $ vcgencmd bootloader_version
May 21 2020 18:02:07
version ae867e96f2d7d0613dfb7e21b98b7cf99a606efc (release)
timestamp 1590080527

Config is unmodified in both cases.

The main readme says "Beta features are always documented here first...". That link needs updating.

I have successfully followed this guide: https://github.com/raspberrypi/rpi-eeprom/blob/master/firmware/raspberry_pi4_network_boot_beta.md and added a RPi4 to our PiServer install and have it net-booting.

My question is what is the easiest way to update a lab full of RPi4 to use the ne-tboot eeprom without having to follow all of these steps on every RPi4?

Thanks,
Jon

Observe the following output:

$ rpi-eeprom-config /lib/firmware/raspberrypi/bootloader/critical/pieeprom-2019-05-10.bin --out bootconf-2019-05-10.txt
$ rpi-eeprom-config /lib/firmware/raspberrypi/bootloader/critical/pieeprom-2019-07-15.bin --out bootconf-2019-07-15.txt
$ cat bootconf-2019-05-10.txt 
BOOT_UART=0
WAKE_ON_GPIO=0
$ cat bootconf-2019-07-15.txt 
BOOT_UART=0
WAKE_ON_GPIO=1
POWER_OFF_ON_HALT=0
                                                                              
                                                                              
                                                                              
                                                                              
                                                                              
                                                                              
                                                                              
                                                                              
                                                                              
                                                                              
                                                                             
                                                                              
             

I guess there's not much point in including the blank lines in bootconf-2019-07-15.txt ?

The boot ROM itself can boot just fine from a superfloppy disk (i've tested this with the recovery.bin image), but if there's no recovery image on the disk, it loads the EEPROM bootloader which can only boot from MBR-partitioned disks.

This worked fine on the Pi 3 as the bootcode was loaded by the boot ROM directly from the SD card.

apt-rdepends -r --state-follow=Installed --state-show=Installed python2
Reading package lists... Done
Building dependency tree
Reading state information... Done
python2
Reverse Depends: python (= 2.7.16-1)
python
Reverse Depends: python-rpi.gpio (<< 0.6.5-1)
Reverse Depends: rpi-eeprom (4.0-1)
python-rpi.gpio
rpi-eeprom

Was wondering if this program could be ported to python3 and the apt package updated to reflect the change. Trying to build a pure python3 image for the rpi4 with no python2 installed but there is a dependence from raspberrypi-bootloader upon rpi-eeprom. The other python-rpi.gpio dependence of python2 I can drop within pi-gen when building the image. Thanks in advance.

Describe the bug
On some boards, the VL805 self or recovery.bin update fails. This seems to be due to the read of the VLI SPI EEPROM failing causing the bootloader to think an update is required.

To Reproduce
Use the Raspberry Pi Imager to create an EEPROM recovery image and observe the UART output.

Additional context
Forum post - logs https://www.raspberrypi.org/forums/viewtopic.php?p=1667830#p1667830

https://pastebin.com/dicQb0b0
https://pastebin.com/n1rGrJM8
https://pastebin.com/2YcP69kL

In rpi-eeprom-config, line 40, the magic mask check is done incorrectly; a value of 0xFFFFFFFF will check out as valid.