Closed driver1998 closed 4 years ago
andreiw
commented
4 years ago Yeah I don’t think hiding it would be best... I am guessing you’re trying to avoid needing to change the boot order on first boot?
Another cringe-worthy idea: modify the Shell. If it detects to be the first boot option invoked, it will attempt to chain to remaining boot options after an interruptible timeout.
driver1998
commented
4 years ago My first attempt is actually write a startup.nsh on SD card and change boot order there. But the UEFI Shell is so weak in automation so I have to made some assumption to make it work...
# This script assumes fs0 is the SD card
# It may change if you connect USB devices
# DO NOT USE THIS SCRIPT FOR USB BOOT!
# GUID for Raspberry Pi Specific Settings
SET GUID CD7CC258-31DB-22E6-9F22-63B0B8EED6B5
ECHO %GUID%
# Set CPU Clock to Max (1200Mhz on Pi3B, 1400Mhz on Pi3B+)
SETVAR -guid %GUID% CpuClock =0x00000002
SETVAR -guid %GUID% CpuClock
# Move SD Card to the first boot option
bcfg boot mv 2 0
# Disable this script
mv fs0:\startup.nsh fs0:\startup.fsh
reset@andreiw: Why is the shell being the first in the first place? Is that because the drive detection happens after the shell item is added?
andreiw
commented
4 years ago Yeah
A
3 июля 2019 г., в 8:55, driver1998 notifications@github.com написал(а):
@andreiw: Why is the shell being the first in the first place? Is that because the drive detection happens after the shell item is added?
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.
This hides the shell item in boot menu, and therefore boot from USB/SD card by default. Useful in unattended deployments, like the WoA Deployer. F1 at startup still boot to UEFI Shell.
Still looking for suggestions for what is the best to do though, maybe keeping the boot item but in the lowest priority.