Hi Grant!
[ Re-adding the CC to the list, I guess you dropped that by mistake ]
On Thu, Feb 28, 2019 at 05:22:10PM +0000, Grant Likely wrote:
On 28/02/2019 17:12, Steve McIntyre wrote:
I'm now looking at updating our logic on armhf/arm64 to do something like:
if (booted via UEFI); then if (booted using U-Boot); then echo MBR else echo GPT fi else echo MBR fi
but I'll need to find a sane way to detect U-Boot->UEFI boot. For now I'm looking at parsing dmesg output to look for something like
[ 0.000000] efi: EFI v2.70 by Das U-Boot
but I'm hoping for a better solution. This is also somewhat assuming that detecting U-Boot in the boot chain is a valid indicator for "unsafe location for firmware", but I'm not sure of a better way!
I really want to avoid installers checking for specific firmware implementations. The interface is UEFI regardless of U-Boot or tianocore as the implementation.
It also isn't actually about U-Boot. It's a limitation of the boot masked ROM in the SoC that do not respect partitioning schemes. In these cases both Tianocore and U-Boot have the same problem, and repartitioning the device will blow away the bootloader.
ACK - I've acknowledged that above. I've personally seen very few devices with Tianocore firmware at arbitrary locations, but lots with U-Boot. That seems to be the pattern. Do you have any common examples for Tianocore?
Perhaps there should be a property in the DT that lists the reserved blocks on the SD or eMMC device.
Maybe, but that bird has already flown surely? I'm talking about existing devices that vendors are not updating.
Or, maybe, we can define an information block that has an identifiable header+checksum which can tell the OS which blocks are occupied by firmware. If it exists somewhere within the first few blocks then the partitioning tool could scan for it before repartitioning. It could also be embedded into the firmware image that gets dd'ed onto the media.
Maybe we can scan the first few sectors of a disk to see if it has any other recognisable strings, then. I'm trying to work out a safe(!) yet also reasonably easy way for partitioning to work. Our existing code isn't working, and we are already over-writing firmware stored in dumb places. :-(
Cheers,
On 04/03/2019 18:36, Steve McIntyre wrote:
Hi Grant!
[ Re-adding the CC to the list, I guess you dropped that by mistake ]
On Thu, Feb 28, 2019 at 05:22:10PM +0000, Grant Likely wrote:
On 28/02/2019 17:12, Steve McIntyre wrote:
I'm now looking at updating our logic on armhf/arm64 to do something like:
if (booted via UEFI); then if (booted using U-Boot); then echo MBR else echo GPT fi else echo MBR fi
but I'll need to find a sane way to detect U-Boot->UEFI boot. For now I'm looking at parsing dmesg output to look for something like
[ 0.000000] efi: EFI v2.70 by Das U-Boot
but I'm hoping for a better solution. This is also somewhat assuming that detecting U-Boot in the boot chain is a valid indicator for "unsafe location for firmware", but I'm not sure of a better way!
I really want to avoid installers checking for specific firmware implementations. The interface is UEFI regardless of U-Boot or tianocore as the implementation.
It also isn't actually about U-Boot. It's a limitation of the boot masked ROM in the SoC that do not respect partitioning schemes. In these cases both Tianocore and U-Boot have the same problem, and repartitioning the device will blow away the bootloader.
ACK - I've acknowledged that above. I've personally seen very few devices with Tianocore firmware at arbitrary locations, but lots with U-Boot. That seems to be the pattern. Do you have any common examples for Tianocore?
Perhaps there should be a property in the DT that lists the reserved blocks on the SD or eMMC device.
Maybe, but that bird has already flown surely? I'm talking about existing devices that vendors are not updating.
For most of those devices the DT is in the kernel tree. Updating the DT is the easy option.
Or, maybe, we can define an information block that has an identifiable header+checksum which can tell the OS which blocks are occupied by firmware. If it exists somewhere within the first few blocks then the partitioning tool could scan for it before repartitioning. It could also be embedded into the firmware image that gets dd'ed onto the media.
Maybe we can scan the first few sectors of a disk to see if it has any other recognisable strings, then.
I think we can be a bit more sophisticated by scanning for a GUID, and validated with a checksum at several known offsets in the first few blocks. That would give firmware flexibility on where that data block gets placed. However, that only works if the provisioning of the device can be updated.
I'm trying to work out a safe(!) yet also reasonably easy way for partitioning to work. Our existing code isn't working, and we are already over-writing firmware stored in dumb places. :-(
Guidance in EBBR for installers so far is to *not* erase existing partition table by default.
g.
boot-architecture@lists.linaro.org
-
Grant Likely -
Steve McIntyre