Re-partitioning; Adding swap partition; Using GPT partitions
12-12-2019, 04:17 AM
Hi @z4v4l, for UEFI I think completeness is best defined by the ability to accomplish useful tasks, such as booting an installer from SD card and installing a (working 
) OS to eMMC. Ultimately the minimum feature set needed to be UEFI complaint is surprisingly small (and, with the latest spec update, includes the option to return EFI_UNSUPPORTED for all runtime services) and I think it is better to measure "completeness" in what percentage of *use-cases* work rather than what percentage of *features* are implemented.
As a concrete example personally I would prioritize support for the eDP panel over support for setting non-volatile variables (neither of which is required to be compliant). This is because multiple Linux installers can install a bootable OS on UEFI systems where EFI_RUNTIME_SERVICES.SetVariable() is not implemented but interacting with grub via the serial port is a lousy user experience. To be clear SetVariable() is a good thing to implement but for my own hacking it is not on the radar yet.
Bringing this back to @Arwen's topic, which perhaps we have been derailing a bit, adopting GPT with protective partitions is a great step towards running a real installer (although I guess moving the bootloaders to SPI is better still). After that I think the least work to unlock installer use cases is u-boot driver enablement, and authoring an installer ISO with a PBP kernel support included.
Maybe we will reach a point where improving the completeness of the generic u-boot UEFI support is a road block that must be overcome to unlock another use-case. However that, IMHO would be a success, not a failure, since it would be an indicator of how far the PBP has come!
) OS to eMMC. Ultimately the minimum feature set needed to be UEFI complaint is surprisingly small (and, with the latest spec update, includes the option to return EFI_UNSUPPORTED for all runtime services) and I think it is better to measure "completeness" in what percentage of *use-cases* work rather than what percentage of *features* are implemented.As a concrete example personally I would prioritize support for the eDP panel over support for setting non-volatile variables (neither of which is required to be compliant). This is because multiple Linux installers can install a bootable OS on UEFI systems where EFI_RUNTIME_SERVICES.SetVariable() is not implemented but interacting with grub via the serial port is a lousy user experience. To be clear SetVariable() is a good thing to implement but for my own hacking it is not on the radar yet.
Bringing this back to @Arwen's topic, which perhaps we have been derailing a bit, adopting GPT with protective partitions is a great step towards running a real installer (although I guess moving the bootloaders to SPI is better still). After that I think the least work to unlock installer use cases is u-boot driver enablement, and authoring an installer ISO with a PBP kernel support included.
Maybe we will reach a point where improving the completeness of the generic u-boot UEFI support is a road block that must be overcome to unlock another use-case. However that, IMHO would be a success, not a failure, since it would be an indicator of how far the PBP has come!