USB boot support for raspberrypicm4-ioboard-sb #1141
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
alexgg
force-pushed
the
alexgg/rpisb
branch
5 times, most recently
from
b2c0b9f
to
7f933b5
Compare
alexgg
force-pushed
the
alexgg/rpisb
branch
6 times, most recently
from
3f5d6a2
to
cdfe6e2
Compare
alexgg
changed the title
…e USB boot With this change the device will first attempt to boot from USB and then boot from the NVME/internal eMMC/SD card. This allows to use USB flasher images as provisioning tools in preference of usbboot. 5: USB 2.0 boot from USB type A socket (CM4) or Type C socket (RPI4) 6: NVME 1: eMMC / SD Card 2: Network boot We place NVME before eMMC/SDcard as there are reports that NVME is not working if initialized after. Also, there is no USB mass storage boot to limit this option to using physical jumper configuration. See https://www.raspberrypi.com/documentation/computers/raspberry-pi.html#BOOT_ORDER Note that trying USB boot first adds a considerable delay to the boot process as the CM4 has a timeout of 2s (5s if extended via `program_usb_boot_timeout=1` per USB port enumeration. As such, this change is only done to the `raspberrypicm4-ioboard-sb` that requires USB boot for the secure boot provisioning flow. Changelog-entry: Modify boot order to prioritize USB boot Signed-off-by: Alex Gonzalez <alexg@balena.io>
This is useful for the use case of a flasher image ran from external media, like in the traditional flasher workflow that expects the device to shutdown after programming. From https://www.raspberrypi.com/documentation/computers/raspberry-pi.html#POWER_OFF_ON_HALT Changelog-entry: configure to power off on halt for raspberrypicm4-ioboard-sb Signed-off-by: Alex Gonzalez <alexg@balena.io>
As CM4 and CM4IO don’t include the external USB 3 controller, RaspberryPi OS sets `otg_mode=1` for better performance. See https://www.raspberrypi.com/documentation/computers/config_txt.html#otg_mode-raspberry-pi-4-only However, while testing, the kernel driver oops when the otg cable is connected at boot (works well if it is connected after boot though). As this is only needed in the USB provisioning mode, restrict the change to the raspberrypicm4-ioboard-sb for the time being. Changelog-entry: enable USB 2.0 for raspberrypicm4-ioboard-sb Signed-off-by: Alex Gonzalez <alexg@balena.io>
With the USB provisioning being preferred, the msd binaries are no longer required. This commit adds a recipe configuration to make the signing conditional. Changelog-entry: do not sign msd binaries by default as they are not needed Signed-off-by: Alex Gonzalez <alexg@balena.io>
Changelog-entry: deploy CM4/RPI4 locking binaries Signed-off-by: Alex Gonzalez <alexg@balena.io>
Also, remove mentioning that write protecting further OTP changes is globally possible as only the customer OTP registers have this feature and these are not used by the secure boot implementation. Change-type: patch Signed-off-by: Alex Gonzalez <alexg@balena.io>
Changelog-entry: update rpi-eeprom firmware to 2024-05-17 Signed-off-by: Alex Gonzalez <alexg@balena.io>
|
@resin-jenkins retest this please |
The `otg_mode=1` setting makes the firmware mux the USB port to the XHCI host-only controller. However, even though this correctly enabled host mode in the USB port, the kernel drivers oops when a cable is plugged into the OTG port in the ioboard, probably because the XCHI controller does not support OTG or device mode. This commit reverts to using the dwc2 kernel overlay which has less performance but does not crash. Changelog-entry: use dwc2 driver for USB host mode in CM4-SB. Signed-off-by: Alex Gonzalez <alexg@balena.io>
This adds support for the DesignWare Core USB 2.0 controller, required for the USB boot flow. Changelog-entry: add dwc2 support to the raspberrypicm4-ioboard-sb kernel Signed-off-by: Alex Gonzalez <alexg@balena.io>
|
@resin-jenkins retest this please |
|
lgtm |
|
Passed:
|
|
@resin-jenkins retest this please |
1 similar comment
|
@resin-jenkins retest this please |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
No description provided.