Open RomanValov opened 3 years ago
My goal is to prevent to boot from network for flashed devices.
If you changed the boot-order to BOOT_ORDER=0xf21
would it attempt to boot from eMMC, but then fail (because the eMMC is empty) and drop through to network-booting? And if the network-boot then flashed an image onto the eMMC and rebooted, I guess it'd then boot from eMMC for all subsequent boots?
Zero byte start.elf / start4.elf files are fine and I see no reason to change remove support for that.
It might be reasonable to add something to the EEPROM_CONFIG to disable the fallback to the non-prefixed directory. The default would be the same as Pi3 which has the fallback.
My goal is to prevent to boot from network for flashed devices.
If you changed the boot-order to
BOOT_ORDER=0xf21
would it attempt to boot from eMMC, but then fail (because the eMMC is empty) and drop through to network-booting? And if the network-boot then flashed an image onto the eMMC and rebooted, I guess it'd then boot from eMMC for all subsequent boots?
Your proposal may work in some scenarios. However in my case in some scenarios I have to periodically switch between network and eMMC boots. I.e. testing firmwares from the CI/CD pipeline: boot from network - flash - boot from eMMC - test - revert to network boot. Making eMMC boot a priority will require dealing with eMMC which is not always as convenient. I.e. in case of broken image I have to connect the board with USB cable and run usbboot
. I consider it to be less convenient than wipe directory on the server (maybe automated) and power cycle the board.
Zero byte start.elf / start4.elf files are fine and I see no reason to change remove support for that.
It might be reasonable to add something to the EEPROM_CONFIG to disable the fallback to the non-prefixed directory. The default would be the same as Pi3 which has the fallback.
Thank you for the clarification.
As of option, just a note that in my scenario fallback to non-prefixed directory should be disabled only if prefixed directory exists but enabled otherwise.
Ahhh, so what you actually want is "selectively prevent boot from network for flashed devices, with the network still having the ability to override that choice" ? :wink:
TFTP doesn't support directory existence checks. The firmware would failover to the non-prefix dir or if specified only request firmware from the prefix dir. For customising the BOOT_ORDER at runtime you might be better of using conditional GPIO filters.
Ahhh, so what you actually want is "selectively prevent boot from network for flashed devices, with the network still having the ability to override that choice" ? wink
Yeah, exactly
TFTP doesn't support directory existence checks. The firmware would failover to the non-prefix dir or if specified only request firmware from the prefix dir. For customising the BOOT_ORDER at runtime you might be better of using conditional GPIO filters.
Unfortunately using GPIO filters completely break my idea of fully automated setup and would require human interaction to alter GPIO configuration (I admit you meant using something like jumpers).
Tweaking the TFTP rules to fit a custom flashing process seems like the wrong approach. Since the server will see the MAC address in the DHCP request I think you can do this all server side.
Board: Raspberry Pi Compute Module 4 Rev 1.0
I'm developing an automated network flashing daemon for RPi boards based on PXE/TFTP server. My boards are configured with
BOOT_ORDER=0xf12
andTFTP_PREFIX=2
, so network boot is preferred and tftp prefix based on MAC-address is preferred.Flashing workflow is following:
start.elf
andstart4.elf
Everything is working fine. However I'm relying on kind of undocumented behavior of boot from prefixed directory. My goal is to prevent to boot from network for flashed devices.
If prefixed directory didn't contain any
start4.elf
/start.elf
files the bootloader fallbacks to network boot from non-prefixed directory and that would break the workflow.If prefixed directory contained proper
start4.elf
/start.elf
files the bootloader continues network boot from prefixed directory and that would break the workflow.I'm afraid relying on zero-sized
start4.elf
/start.elf
as a method to skip network boot could be broken one day. So I would ask either to provide a guarantee for the behavior (i.e. document it), or maybe provide some kind of more clean and straight-forward way to skip network boot, i.e. putting kind of skip-marker-file in a prefix dir to prevent fallback to non-prefixed dir and skip network boot method.Sorry if there is already a method to do this that I have missed.
Network boot (please complete the following information):
Here is a log of boot from prefixed directory:
Here is a log of boot from non-prefixed directory: