Yes, we are working on it, there will be an eeprom updater script and appropriate apt-package(s). Covering all the possible corner cases will requires quite a lot of testing and we'll beta-test the package files via the forums once we are happy with it.trejan wrote: ↑Wed Jul 17, 2019 4:20 pmReflashed the RPi 4 boards I've got and looks to be working here.
Is there going to be an easier procedure for updating in the future or is this it? e.g. it'll start booting instead of just rapidly blinking the LED once it has updated the EEPROM. Just wondering as an update process that doesn't require physical access would be nice.
Code: Select all
sudo apt-get install flashrom sudo dtparam audio=off sudo dtoverlay spi-gpio40-45 sudo modprobe spidev sudo modprobe spi-bcm2835 sudo flashrom -p linux_spi:dev=/dev/spidev0.0,spispeed=16000 | grep W25X sudo flashrom -p linux_spi:dev=/dev/spidev0.0,spispeed=16000 -r pieeprom-backup.bin sudo flashrom -p linux_spi:dev=/dev/spidev0.0,spispeed=16000 -w pieeprom.bin
Is rescuing oneself from an erased / corrupted Bootloader Eeprom not covered by booting an SD Card with the SPI Bootloader Eeprom Recovery files on it ?
The sd-card rescue image will always work and also always resets any config i.e. it's a factory reset of the EEPROM. The ROM always runs recovery.bin on the sd-card in preference to the EEPROM so this will always be safe.hippy wrote: ↑Wed Jul 17, 2019 7:40 pmIs rescuing oneself from an erased / corrupted Bootloader Eeprom not covered by booting an SD Card with the SPI Bootloader Eeprom Recovery files on it ?
Got it - Thanks.timg236 wrote: ↑Wed Jul 17, 2019 7:56 pmThe sd-card rescue image will always work and also always resets any config i.e. it's a factory reset of the EEPROM. The ROM always runs recovery.bin on the sd-card in preference to the EEPROM so this will always be safe.
The 'safe mode' / minimal bootloader (could do with a better name) is just enough of a bootloader to load Linux from the sd-card in-case there's a power failure during flashrom. i.e. cp recovery-safe.bin /boot/recovery.bin && sync && apply-update && rm -f /boot/recovery.bin
This is intended to support unattended updates (e.g. for remote machines) in a safe manner.
flashrom detects it as a Winbond W25X40. The USB controller uses a Winbond W25X10.
Or something else is.
hippy wrote: ↑Wed Jul 17, 2019 9:50 pmOr something else is.
I was idly wondering how quickly one could brick someone else's Pi for them - not that I have any intention of doing so.
About an hour I reckon. Though erase-cycles are often conservatively stated so it could take a lot longer.
Absolutely and it's a great idea. On the downside it's a potentially new attack vector which could be exploited by anyone who had malicious intent. Such malicious attacks are unlikely but it is useful to know how effective they could be.
Any scripts using flashrom should be safe because flashrom already avoids unnecessary erase/write cycles. The updater script also checks this because it stores a backup and we don't want to fill the disk with duplicate backups.hippy wrote: ↑Thu Jul 18, 2019 10:32 amBut something executing autonomously could erase-write it, or parts of it, far more frequently, and one likely only needs to make the smallest part of the Eeprom unusable to bring everything down. I was basing my hour long prediction on 100K x 30ms typical Sector Erase being the fastest damage could be done. In practice it is likely to be longer than that, but a program has all the time in the world to do its damage.