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

[thatchunkylad198966]

Why doesn't 5ghz work?

[HawaiianPi]

Why doesn't 5ghz work?

Works for me. ¯\_(ツ)_/¯

When did it stop working for you?

[wildestpixel]

Why doesn't 5ghz work?

Works for me. ¯\_(ツ)_/¯

When did it stop working for you?

A lot of peoples issues with 5G WIFI tend to stem from having routers which have a combined SSID enabled. When you split the 2.4 and 5 to seperate SSID's the power saving roaming effect goes and you can stably attach to either.

In my case in the UK I have the popular BT Whole Home Mesh Discs, which cannot split SSID's, but are rock solid in what they do. Solution for PI's I have to use wifi on - use my ISP's router which I have setup with split bands.

[jamesh]

Why doesn't 5ghz work?

Off topic. Start a new thread for non-MSD related stuff.

[knute]

That doesn't work?

Code: Select all

echo | sudo tee /boot/.firmware_revision 
sudo rpi-update

What does that do?

pi@raspberrypi4B:/boot $ cat /boot/.firmware_revision
b2aabc3ac7852481cb7833ce068f65eaa4476a2f

[RonR]

@timg236, any comment?

[trejan]

What does that do?

pi@raspberrypi4B:/boot $ cat /boot/.firmware_revision
b2aabc3ac7852481cb7833ce068f65eaa4476a2f

/boot/.firmware_revision is the commit hash for the firmware/kernel that rpi-update last installed. If an apt upgrade overwrote the firmware/kernel but there hasn't been a newer development firmware/kernel then rpi-update will say you're up to date and do nothing. Blanking /boot/.firmware_revision forces rpi-update to run.

[RonR]

Blanking /boot/.firmware_revision forces rpi-update to run.

A simple 'sudo rm /boot/.firmware_revision' works equally well and doesn't make people scratch their head.

[trejan]

A simple 'sudo rm /boot/.firmware_revision' works equally well and doesn't make people scratch their head.

If you delete the file then it overwrites the /boot backup.

[RonR]

A simple 'sudo rm /boot/.firmware_revision' works equally well and doesn't make people scratch their head.

If you delete the file then it overwrites the /boot backup.

Different strokes, I guess.

If I didn't want the backup firmware and modules overwritten, I'd use:

Code: Select all

sudo SKIP_BACKUP=1 rpi-update

[HawaiianPi]

Interestingly, VLC stopped displaying video sometime recently.

Not sure exactly when (or why), but sudo apt update && sudo apt full-upgrade -y && sudo rpi-update fixed it, and USB boot still works.

Code: Select all

tim@RaspberryPi4B2:~$ uname -a
Linux RaspberryPi4B2 5.4.44-v8+ #1320 SMP PREEMPT Wed Jun 3 16:20:05 BST 2020 aarch64 GNU/Linux
tim@RaspberryPi4B2:~$ sudo rpi-eeprom-update
BCM2711 detected
Dedicated VL805 EEPROM detected
BOOTLOADER: up-to-date
CURRENT: Thu 28 May 2020 07:22:33 AM UTC (1590650553)
 LATEST: Wed 27 May 2020 05:47:29 PM UTC (1590601649)
 FW DIR: /lib/firmware/raspberrypi/bootloader/beta
VL805: up-to-date
CURRENT: 000138a1
 LATEST: 000137ad

[Gavinmc42]

Kernel 5.4.44?
Time to update again.

[W. H. Heydt]

Bug (somewhere) that makes the task bar blink in and out a few times then go away if the logged in user is not 'pi' is still present.

If anything more than what is below is needed for debugging, let me know.

Code: Select all

pi@ddc4test:~ $ uname -a
Linux ddc4test 5.4.44-v7l+ #1320 SMP Wed Jun 3 16:13:10 BST 2020 armv7l GNU/Linux

Code: Select all

pi@ddc4test:~ $ sudo rpi-update
 *** Raspberry Pi firmware updater by Hexxeh, enhanced by AndrewS and Dom
 *** Performing self-update
 *** Relaunching after update
 *** Raspberry Pi firmware updater by Hexxeh, enhanced by AndrewS and Dom
 *** Your firmware is already up to date

Code: Select all

pi@ddc4test:~ $ sudo rpi-eeprom-update
BCM2711 detected
Dedicated VL805 EEPROM detected
BOOTLOADER: up-to-date
CURRENT: Wed 03 Jun 2020 12:53:47 PM UTC (1591188827)
 LATEST: Wed 03 Jun 2020 12:53:47 PM UTC (1591188827)
 FW DIR: /lib/firmware/raspberrypi/bootloader/beta
VL805: up-to-date
CURRENT: 000137ad
 LATEST: 000137ad

[W. H. Heydt]

Kernel 5.4.44?
Time to update again.

New beta EEPROM package as well.

[satadru]

Quirk: using older firmware files (*.elf, *.dat) but current beta rpi4 eeprom firmware.

Code: Select all

sudo vcgencmd version
Feb 10 2020 15:15:59 
Copyright (c) 2012 Broadcom
version d21c2d51634b793e0b0ce2816c4e3d1cf0d87e6b (clean) (release) (start)
sudo ./rpi-eeprom/rpi-eeprom-update 
BCM2711 detected
Dedicated VL805 EEPROM detected
BOOTLOADER: up-to-date
CURRENT: Wed Jun  3 12:53:47 UTC 2020 (1591188827)
 LATEST: Wed Jun  3 12:53:47 UTC 2020 (1591188827)
 FW DIR: /lib/firmware/raspberrypi/bootloader/beta
VL805: up-to-date
CURRENT: 000138a1
 LATEST: 000137ad

This let's me netboot successfully. Obviously those firmware files don't work for USB-MSD, but current *.elf, *.dat files don't let me boot, with the system crapping out before initrd loads.

Before I file a bug report: Is anyone having success at loading an initrd over USB-MSD? I have kernel loading fine, but reliably have failure with the initrd. (Error sometimes ends with a "vcc_sd disabling" message.)

I'm able to load kernel 5.4.44 + initrd just fine via netboot over tftp (using the Feb 10th firmware files but June 3rd eeprom firmware), but newer *.elf and *.dat with the same kernel, dtb, and initrd are causing problems for me.

I'm using an ubuntu focal system, but that shouldn't make a difference since I'm not getting past USB device enumeration when booted via USB-MSD.

This is with a JMS583 equipped m2 nvme enclosure, and those are known to have issues with sketchier cables, but since it reliably works via netboot and not over usb-msd, I figured that there was an issue with usb-msd.

Maybe there is a timeout which helps? If I unplug the cable from the drive, wait the 20 seconds for network booting to start, and then plug in the drive, the drive is seen and works just fine.

I tried setting boot_delay=20 in config.txt on the drive's boot partition, and that didn't help.

Also tried adding usb-storage.delay_use=10 to cmdline.txt, and that didn't help either.

[dickon]

I managed it with last week's EEPROM and firmware, booting from a USB uSD card reader, and a Pi 0 in gadget mode. Haven't attempted with the 06-03, though.

[HawaiianPi]

New beta EEPROM package as well.

WTH? I must have updated right before that came out. Oh well, up to date now.

Code: Select all

tim@RaspberryPi4B2:~$ uname -a && sudo rpi-eeprom-update
Linux RaspberryPi4B2 5.4.44-v8+ #1320 SMP PREEMPT Wed Jun 3 16:20:05 BST 2020 aarch64 GNU/Linux
BCM2711 detected
Dedicated VL805 EEPROM detected
BOOTLOADER: up-to-date
CURRENT: Wed 03 Jun 2020 12:53:47 PM UTC (1591188827)
 LATEST: Wed 03 Jun 2020 12:53:47 PM UTC (1591188827)
 FW DIR: /lib/firmware/raspberrypi/bootloader/beta
VL805: up-to-date
CURRENT: 000138a1
 LATEST: 000137ad

USB booting, audio and video all still working. So far so good...


EDIT
Guess that means it's time to close this thread and start a new one...

** Edit: Point at 2020-05-28 release for corrected VLI update fix **
(No more edits, the next release gets a new thread!)

[davidcoton]

Code: Select all

tim@RaspberryPi4B2:~$ uname -a && sudo rpi-eeprom-update
Linux RaspberryPi4B2 5.4.44-v8+ #1320 SMP PREEMPT Wed Jun 3 16:20:05 BST 2020 aarch64 GNU/Linux
BCM2711 detected
Dedicated VL805 EEPROM detected
BOOTLOADER: up-to-date
CURRENT: Wed 03 Jun 2020 12:53:47 PM UTC (1591188827)
 LATEST: Wed 03 Jun 2020 12:53:47 PM UTC (1591188827)
 FW DIR: /lib/firmware/raspberrypi/bootloader/beta
VL805: up-to-date
CURRENT: 000138a1
 LATEST: 000137ad

Why does rpi-eeprom-update insist that VL805 000137ad is later than 000138a1 ?
Is something forgetting to check the beta/stable/critical setting, or is 000138a1 installed in such a way as to confuse the test?

[andrum99]

Why does rpi-eeprom-update insist that VL805 000137ad is later than 000138a1 ?

It doesn't. The latest update available to the rpi-eeprom-update script is 000137ad, so when it finds the VL805 has a newer EEPROM it tells you that it is up-to-date. It also reports the latest version available to it, 000137ad, which is correct, although earlier than the version you have installed.

(000138a1 has not been packaged as part of rpi-eeprom-images yet, since it is still under test).

[timg236]

Why does rpi-eeprom-update insist that VL805 000137ad is later than 000138a1 ?

It doesn't. The latest update available to the rpi-eeprom-update script is 000137ad, so when it finds the VL805 has a newer EEPROM it tells you that it is up-to-date. It also reports the latest version available to it, 000137ad, which is correct, although earlier than the version you have installed.

(000138a1 has not been packaged as part of rpi-eeprom-images yet, since it is still under test).

There's a PR under test for the version number comparison https://github.com/raspberrypi/rpi-eeprom/pull/146

[davidcoton]

There's a PR under test for the version number comparison https://github.com/raspberrypi/rpi-eeprom/pull/146

Looks like that should fix it.

[timg236]

@timg236,

I'm using the latest bootloader and vl805:

BCM2711 detected
Dedicated VL805 EEPROM detected
BOOTLOADER: up-to-date
CURRENT: Thu 28 May 07:22:33 UTC 2020 (1590650553)
LATEST: Thu 16 Apr 17:11:26 UTC 2020 (1587057086)
FW DIR: /lib/firmware/raspberrypi/bootloader/critical
VL805: up-to-date
CURRENT: 000138a1
LATEST: 000137ad

and the latest RaspOS (Lite) (4.19.118) + usb-msd-boot-firmware.

With an empty /boot/config.txt, the green activity LED flashes at one second intervals polling an empty SD card slot as expected.

With only 'enable_uart=1' in /boot/config.txt, the green activity LED is solid on 99.9% of the time with an empty SD card slot.

Is this expected behavior?

What's the bootloader configuration?
Do you see anything on the HDMI display when it's in this state?

It might be worth trying the 2020-06-03 release

[recantha2]

Hi,
I'm trying to test out the latest update (2020-05-28).
I've done the firmware update using rpi-update following the instructions posted.
I've then written the latest Raspbian Lite to a Samsung 850 EVO 500GB SSD.
I've removed the SD card, plugged in the SSD into a USB3 port with a USB-SATA bridge cable.

I'm currently getting the following errors in a loop:

Read start4.elf bytes 2252416 hnd 0x0001010108 hash '604055cff3214d78'
Read fixup4.dat bytes 5400 hnd 0x000002e9 hash 'a29f862f2cffc816'

0x00d03114 0x00000000 0x0000000f

start4.elf: is not compatible
USB-MSD boot requires new software
Get the latest software from https://www.raspberrypi.org/downloads/
ERROR: 00000044

Any ideas what I can do to continue with the test?

Thanks,

[timg236]

That doesn't match the start of the hash in rpi-update master

git clone --depth 1 https://github.com/raspberrypi/firmware.git
cd firmware
sha256sum start4.elf
319662b44a4c80d506a1294015c94eef2b5d45fe52ddfad60e58161b2e6ca7df start4.elf

[neilshep50]

Hi,
I'm trying to test out the latest update (2020-05-28).
I've done the firmware update using rpi-update following the instructions posted.
I've then written the latest Raspbian Lite to a Samsung 850 EVO 500GB SSD.
I've removed the SD card, plugged in the SSD into a USB3 port with a USB-SATA bridge cable.

I'm currently getting the following errors in a loop:

Read start4.elf bytes 2252416 hnd 0x0001010108 hash '604055cff3214d78'
Read fixup4.dat bytes 5400 hnd 0x000002e9 hash 'a29f862f2cffc816'

0x00d03114 0x00000000 0x0000000f

start4.elf: is not compatible
USB-MSD boot requires new software
Get the latest software from https://www.raspberrypi.org/downloads/
ERROR: 00000044

Any ideas what I can do to continue with the test?

Thanks,

Plug your SSD into a 3B+, let it set up, then do:

Code: Select all

sudo apt update
sudo apt upgrade
sudo apt rpi-update

Enjoy!