On Wed, Mar 11, 2020 at 11:20:17AM +0100, Francois Ozog wrote:
On Wed, 11 Mar 2020 at 07:48, Heinrich Schuchardt xypron.glpk@gmx.de wrote:
On 3/11/20 12:04 AM, Heinrich Schuchardt wrote:
On 3/10/20 7:37 PM, Francois Ozog wrote:
Le mar. 10 mars 2020 à 18:37, Daniel Thompson daniel.thompson@linaro.org a écrit :
On Tue, Mar 10, 2020 at 05:35:40PM +0100, Francois Ozog wrote:
This is driven by the BL2 which is platform specific and I am not sure we can have any influence. The flashimage.bin in a number of system consists of a (blob) FIP that has BL2, SCP stuff, BL31, BL32, BL33. Ilias upstream U-Boot patches to change from "ADR" to "ADRL" because the code grew too much.
I'm not quite sure I understand the concern here.
Are you still working on systems where the boot ROM mandates using MBR partitioning and attempting to put secure boot on it? If so perhaps we could simply discontinue MBR support for systems with secure boot!
Well..... we want Products on the market to benefit from EBBR compliance rather than two years from now. So MBR is inevitable. And is not that a pain ;-) Of course its not as clean as we would like but “sales first”!
A typical problem is that a SoC has an entry address within the first 17 KiB, e.g. the Allwinner CPUs want a firmware entry point at 0x2000. If I correctly understand the UEFI standard, one might use PartitionEntryLBA to place the GPT Partition Entry Array behind the firmware in this case.
In the expert mode of gdisk there is command 'j' for moving the GPT Partition Entry Array to an arbitrary sector. This will protect the area between the GPT header and the GPT Partition Entry Array from being used for a partition. The same can be done with parameter -j of sgdisk.
Furthermore gdisk supports creating a hybrid MBR. This allow to have GUID partition table and a MBR partion table at the same time where the MBR partition table mirrors up to three GPT partitions and the fourth MBR partition is used to protect the GUID partition table.
So requiring GPT and having boards only supporting booting from an MBR partition (like the Raspberry) seems not to be exclusive.
That sounds like a great solution!
The last time we discussed this there was *very* strong opposition during meetings to hybrid partitioning and IIRC language was added to the spec to prohibit it.
Hybrid partitioning is a problem because it imposes to difficult to meet constraints on partitioning tools provided by the operating system.
In other words if we permit hybrid partitioning in order that boot code can find the firmware then the operating system would inherit a duty to not to screw up the firmware loading when it modifies the partition tables. It is hard to express how the OS should go about that.
Hence the current approach where we accept that MBR partitioning offers an inferior feature set to GPT.
Daniel.