OpenSystemsDevelopment / usbboot

Initial BETA release for secure-boot.

secure-boot adds two new sub-directory to usbboot:

* secure-boot-recovery is used to create an EEPROM signed with
  the customer's RSA private key and configures the 2711 OTP
  settings permenantely require signed boot images.
  See secure-boot-recovery/README.md
* Once secure-boot is enabled the CM4 MSD mode firmware must
  also be signed with the customer's RSA private key.
  See secure-boot-msd/README.md

N.B The revoke_devkey and program_jtag_lock are NOT enabled in
this initial BETA release.

Update to the latest bootcode.bin built from top-of-tree source repo.

Update bootcode4.bin

Update this binary to the latest.
Also rebuilt the windows installer

bootloader: Remove NVMe beta files

The latest bootloader now supports NVMe

Fix `install` and `uninstall` targets in Makefile.

Add `install` target for  executable and default
`bootcode.bin`/`bootcode4.bin` and
`start.elf`/`start4.elf` files.

Update `uninstall` target.

Update Raspberry Pi 4 EEPROM to pieeprom-2021-07-06

Select the latest, stable bootloader EEPROM release which supports NVMe.

Update start4.elf (USB MSD firmware) to top-of-tree.

readme: add macOS build step

Adds instructions for macOS users.
It will mainly help with the perception that this only works on ubuntu.
You can also use this on macOS without a problem.

Update bootcode4.bin to avoid some blocking operations which can cause
USB errors.

Fixes issue with PCIe bridges in Linux
Last commit 05552182f98adadd27ba1aa9e3ca671c9dd5123f

The manufacuring image now enables SELF_UDPATE and NETWORK boot by
default in order to make the initial setup for CM4 based products
easier. For embedded or physically inaccessible products the bootloader
should be updated to disable self-update. Hardware write-protection
should also be configured.

The symlink from pieeprom-2021-02-16 to pieeprom.original.bin has
been replaced with a simple copy of the file because the Windows
installer doesn't seem to support symlinks.

* Update the EEPROM image to the latest/stable release.
* Change the default boot-order to 0xf541 so that USB MSD will boot
  from the type-A sockets on the CM4 IO board.
* Add simple update-pieeprom.sh utility with latest rpi-eeprom-config
  to make it easier to refresh the EEPROM image with a new configuration.

Also add extra logging to indicate where the file was loaded
from to make it more obvious where a file is loaded from.

Update Windows installer

* Add 2711 bootcode and FW binaries with the 4 suffix.
* Use the device descriptor to select the correct bootcode and
  hack it so that bootcode.bin translates to bootcode4.bin on a
  Pi4 allowing the files to remain in the same directory.
* Add the latest best for recovery.bin and pieeprom.bin for CM4
* Update the installer.

Move the second stage preparation until after the device descriptor
has been retrieved because BCM2711 needs a different bootcode.bin.

If the '-d' argument specified then check for bootcode.bin in the
specified directory and don't fail over to the embedded fmem files.

Remove the default 'msd' directory and the references to /usr/share
because the behaviour conflicts with the original change to use
the fmem files.

It's possible that SerialNumber=3 might be received twice due to
differences in timing causing rpiboot to exit too early i.e. before
the second stage has started.

Tweak the loop condition to handle this.

Fixes: https://github.com/raspberrypi/usbboot/issues/53

With recent kernels I get timeouts booting Linux with rpiboot, after increasing the timeout to 3000 I have no issues.

Debugging I see the ep_read call after ReadFile: cmdline.txt (before it tries to retrieve recovery.img/kernel.img) takes around 2.1-2.2 seconds which looks to be related to the size of the iniramfs I'm using.

Current output
 Failed : 0x0Waiting for BCM2835/6/7

And now
 Failed : 0x0
 Waiting for BCM2835/6/7/2711...

Commit 45c7237d9dc2 ("Fixup for recent firmware inclusion changes")
breaks builds on non-Apple platforms. Fix it for platforms that
already have fmemopen - others may still need attention.

See: https://github.com/raspberrypi/usbboot/issues/47

Signed-off-by: Phil Elwell <phil@raspberrypi.com>

* Fix check against NULL for a static var actually looking for an empty c string.

* Update .gitignore for code change moving msd firmware to static vars.

* Fix support for OS X and *BSD after adding static vars for msd firmware.

* Do not require root privileges

Give members of plugdev group access to the usb device by udev
rules.

* Disallow requests for files outside directory

* Be more verbose about errors

* Error out if permission was denied while opening device.
* Show error if request for file containing .. was denied.

Apt is newer and more user-friendly than apt-get

The second stage can/will support file-server so don't force
bootcode.bin for 2711. The second stage will (probably) reply
with SerialNumber==1 when it wants the file-server as on Pi3.

The BCM2711 can also boot in USB device mode. Note that the boot ROM
code now sets the iSerialNumber to 3, but it does not expect the
second stage boot server, instead it downloads a single image over
USB.

Signed-off-by: Petr Tesarik <petr@tesarici.cz>

* Add support for larger files.

Based on original patch by ZoltanSzenczi:
https://github.com/raspberrypi/tools/pull/20

* Fix typo in max transfer size.

Original patch had a magic number of "LIBUSB_MAX_TRANSFER 507904"

Assume that 496K ia a typo for 4096K, although 8M also works for me.

* Put back out_ep and long timeout.

Master uses out_ep variable instead of hard coding 0x01.

Master also sets a much longer time out for the transfer. Transfering
4MB takes almost 5 seconds, so the original patch was dangerously close
to timing out here. Master uses 100 second timeout, which is plenty.

* Use 16KB instead of 4MB.

The usbfs buffer memory is apparently shared across all usbfs devs.
So we should try not to use a huge amount of it. Using a 16KB buffer
here has no observable impact on performance as the trasnfer will be
split up in to packets at least that small anyway.

This also removes the abort counter. That doesn't seem to do anything
except make the transfer fail if it has to be split into more than
20 parts. There is no "retry" code to break out of; the loop always
aborts after a single error.

* Reduce the timeout for 16KB blocks.

Since the block size is reduced we no longer need to set a huge
time out of 100 seconds. 5 seconds should be plenty to transfer
16KB. It should in fact take well under 1 second.

This helps avoid picking up the wrong files when msd files have already
been installed as a debian package