Merge pull request #128 from XECDesign/debian/buster

Debian/buster
This commit is contained in:
Tim Gover
2020-05-18 15:51:53 +01:00
committed by GitHub
43 changed files with 96 additions and 8 deletions

44
.github/ISSUE_TEMPLATE/bug_report.md vendored Normal file
View File

@@ -0,0 +1,44 @@
---
name: Bug report
about: Create a report to help us improve
title: ''
labels: ''
assignees: ''
---
For general boot questions please check the read the [Boot Problems] (https://www.raspberrypi.org/forums/viewtopic.php?t=58151) sticky post on the forums.
**Describe the bug**
A clear and concise description of what the bug is.
**To Reproduce**
Steps to reproduce the behavior:
**Expected behaviour**
A clear and concise description of what you expected to happen.
**Screenshots**
If applicable, add a photograph of the bootloader HDMI diagnostics screen.
**Bootloader version and configuration**
If you have modified the default bootloader release or configuration then please attach the bootloader configuration (vcgencmd bootloader_config) and version (vcgencmd bootloader_version)
**SD card boot (please complete the following information):**
- OS e.g. Raspbian
- SD card type
- Partition information (fdisk -l) if you are able to obtain this from another computer.
**Network boot (please complete the following information):**
Network boot configuration can get very complicated. To get started we recommend using [PiServer](https://github.com/raspberrypi/piserver) and this is the official test/reference configuration. For other configurations, packet capture or a UART log is nearly always required because setting up custom network configurations to investigate bugs is extremely time-consuming and error-prone.
- DHCP server configuration files e.g. dnsmasq.conf
- Wireshark binary packet capture
- UART logs
**USB boot (please complete the following information):**
For issues booting with specific USB devices please verify that the system boots from an SD-card with the same devices connected and attach the results of 'lsusb -vvv'. This helps to rule out USB HUB power issues.
In the beta release it's likely that a UART or NetConsole boot trace will be required.
**Additional context**
Add any other context about the problem here.

View File

@@ -23,7 +23,9 @@ Bootloader bugs are especially difficult to describe because there's no display.
* Wireshark trace for network boot. Filtering for DHCP and TFTP protocols or by mac-address for the Pi4 is fine. * Wireshark trace for network boot. Filtering for DHCP and TFTP protocols or by mac-address for the Pi4 is fine.
# BETA versions of the bootloader # BETA versions of the bootloader
If you want to try the BETA version of the bootloader then we recommend that you always try this with a spare sd-card and are comfortable with using the rescue image. For debugging you may find a USB serial cable useful. If you want to try the BETA version of the bootloader then we recommend that you always try this with a spare sd-card and are familiar with using the Raspberry Pi Imager to create recovery images to restore factory settings. For debugging you may find a USB serial cable useful.
See also - [Firmware release status](https://www.raspberrypi.org/documentation/hardware/raspberrypi/booteeprom.md)
Beta features are always documented [here](https://github.com/raspberrypi/rpi-eeprom/blob/master/firmware/release-notes.md) first. Once the configuration has stabalised then the [Bootloader configuration](https://www.raspberrypi.org/documentation/hardware/raspberrypi/bcm2711_bootloader_config.md) will be updated, however, there's normally a bit of a delay in order to allow official documentation to be reviewed. Beta features are always documented [here](https://github.com/raspberrypi/rpi-eeprom/blob/master/firmware/release-notes.md) first. Once the configuration has stabalised then the [Bootloader configuration](https://www.raspberrypi.org/documentation/hardware/raspberrypi/bcm2711_bootloader_config.md) will be updated, however, there's normally a bit of a delay in order to allow official documentation to be reviewed.

14
debian/changelog vendored
View File

@@ -1,3 +1,17 @@
rpi-eeprom (7.0-1) buster; urgency=medium
[ Tim Gover ]
* Update README.md
* Garbage collect old bootloader releases
* pieeprom-2020-05-15.bin - USB mass storage boot beta
* Update issue templates
[ andrum99 ]
* rpi-eeprom-update: mention Pi4 only, remove references to SD card
* rpi-eeprom-config: Pi 4B -> Pi 4
-- Serge Schneider <serge@raspberrypi.org> Mon, 18 May 2020 15:12:04 +0100
rpi-eeprom (6.0-1) buster; urgency=medium rpi-eeprom (6.0-1) buster; urgency=medium
[ Tim Gover ] [ Tim Gover ]

Binary file not shown.

Binary file not shown.

Binary file not shown.

Binary file not shown.

View File

@@ -0,0 +1 @@
../beta/pieeprom-2019-07-15.bin

View File

@@ -0,0 +1 @@
../beta/pieeprom-2019-09-10.bin

View File

@@ -0,0 +1 @@
../beta/pieeprom-2020-04-16.bin

View File

@@ -0,0 +1 @@
../beta/recovery.bin

View File

@@ -0,0 +1 @@
../beta/vl805-00013701.bin

View File

@@ -0,0 +1 @@
../beta/vl805-000137ab.bin

View File

@@ -0,0 +1 @@
../beta/vl805-000137ad.bin

View File

@@ -0,0 +1 @@
../beta/pieeprom-2020-01-17.bin

View File

@@ -0,0 +1 @@
../beta/pieeprom-2020-03-19.bin

View File

@@ -0,0 +1 @@
../beta/pieeprom-2020-04-16.bin

View File

@@ -0,0 +1 @@
../beta/recovery.bin

View File

@@ -0,0 +1 @@
../beta/vl805-000137ad.bin

View File

@@ -1,5 +1,19 @@
# Raspberry Pi4 bootloader EEPROM release notes # Raspberry Pi4 bootloader EEPROM release notes
## 2020-05-15 Add pieeprom-2020-05-15 beta with USB boot
* USB mass storage boot will NOT work without the updated firmware
start.elf binaries. These will probably be released via rpi-update
in a few days time.
This release simply helps to validate if there are regressions in
the current SD and Network boot modes.
* SELF_UPDATE and bootloader_update are now enabled by default.
## 2020-05-11 Garbage collect old binaries
* Now that 2020-04-16 is has been released as the default production
release move the old binaries to an old (deprecated) directory.
These can be removed for the APT package to reduce disk space.
## Promote 2020-04-16 EEPROM release critical ## Promote 2020-04-16 EEPROM release critical
* Make this the default release for all users. This supports network * Make this the default release for all users. This supports network
boot, configurable boot order and HDMI diagnostics screen. boot, configurable boot order and HDMI diagnostics screen.

View File

@@ -2,7 +2,7 @@
# rpi-eeprom-config # rpi-eeprom-config
# Utility for reading and writing the configuration file in the # Utility for reading and writing the configuration file in the
# Raspberry Pi4 bootloader EEPROM image. # Raspberry Pi 4 bootloader EEPROM image.
import argparse import argparse
import struct import struct
@@ -98,7 +98,7 @@ class BootloaderImage(object):
def main(): def main():
parser = argparse.ArgumentParser(formatter_class=argparse.RawDescriptionHelpFormatter, \ parser = argparse.ArgumentParser(formatter_class=argparse.RawDescriptionHelpFormatter, \
description='Bootloader EEPROM configuration tool for the Raspberry Pi 4B. \ description='Bootloader EEPROM configuration tool for the Raspberry Pi 4. \
\n\nThere are 3 operating modes: \ \n\nThere are 3 operating modes: \
\n\n1. Output the bootloader configuration stored in an EEPROM image file to \ \n\n1. Output the bootloader configuration stored in an EEPROM image file to \
the screen (STDOUT): specify only the name of an EEPROM image file using the \ the screen (STDOUT): specify only the name of an EEPROM image file using the \

View File

@@ -306,11 +306,13 @@ usage() {
cat <<EOF cat <<EOF
rpi-eeprom-update [options]... [FILE] rpi-eeprom-update [options]... [FILE]
Checks whether the Raspberry Pi bootloader and the VL805 USB controller Bootloader EEPROM update tool for the Raspberry Pi 4.
Checks whether the Raspberry Pi 4 bootloader and the VL805 USB controller
EEPROMs are up-to-date and optionally updates the EEPROMs at the next reboot. EEPROMs are up-to-date and optionally updates the EEPROMs at the next reboot.
The default update mechanism writes recovery.bin and the EEPROM update The default update mechanism writes recovery.bin and the EEPROM update
image(s) (pieeprom.upd and vl805.bin) to the boot partition on the sd-card. image(s) (pieeprom.upd and vl805.bin) to the boot partition.
The SHA256 hash of the corresponding images are written to pieeprom.sig The SHA256 hash of the corresponding images are written to pieeprom.sig
and/or vl805.sig. This guards against file system corruption which could and/or vl805.sig. This guards against file system corruption which could
cause the EEPROM to be flashed with an invalid image. This is not a cause the EEPROM to be flashed with an invalid image. This is not a
@@ -321,8 +323,8 @@ If the update was successful recovery.bin renames itself to recovery.000
to prevent it from running a second time then resets the system. to prevent it from running a second time then resets the system.
The system should then boot normally. The system should then boot normally.
If /boot does not correspond to the boot partition on the sd-card and this If /boot does not correspond to the boot partition and this
is not a NOOBS system then the mount point for BOOTFS should be defined is not a NOOBS system, then the mount point for BOOTFS should be defined
in /etc/default/rpi-eeprom-update by defining the BOOTFS variable. in /etc/default/rpi-eeprom-update by defining the BOOTFS variable.
A backup of the current EEPROM config file is written to ${FIRMWARE_BACKUP_DIR} A backup of the current EEPROM config file is written to ${FIRMWARE_BACKUP_DIR}
@@ -359,7 +361,7 @@ USE_FLASHROM
The flashrom update mechanism may be enabled by setting USE_FLASHROM=1. This The flashrom update mechanism may be enabled by setting USE_FLASHROM=1. This
also selects the vl805 tool instead of using recovery.bin to perform the also selects the vl805 tool instead of using recovery.bin to perform the
update. This may be desirable if an immediate update is required or if an update. This may be desirable if an immediate update is required or if an
sd-card is not present. SD card is not present.
However, this not recommended because the SPI pins are muxed with audio and other However, this not recommended because the SPI pins are muxed with audio and other
device drivers may be using SPI (e.g. HATs). This is also not safe in the device drivers may be using SPI (e.g. HATs). This is also not safe in the
event of a power failure during the update of the EEPROM. event of a power failure during the update of the EEPROM.