On Wed, Mar 11, 2020 at 12:04:45AM +0100, Heinrich Schuchardt wrote:
The 1MB was to deal with limitations in the boot rom. If the boot rom needs extra space, would it not be better to have an initial loader
that
understands partitioning in the 1st 1MB and load the remaining images from a real partition?
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.
Often when you try to get clever with the GPT stuff in the UEFI standard you find a field that does what you want and then somewhere else a bit a language that restricts what you can set it too ;-).
However I can't find anything like that for PartitionEntryLBA so this would certainly make the problem extremely narrow.
1. System boots from shared media
2. System cannot use hardware partitioning features of the shared boot media (perhaps it is an SD card or because the boot ROM does not try eMMC boot protocol first)
3. Either Boot ROM entry point makes GPT partitioning impossible or Boot ROM automatically parses MBR to locate additional boot code and therefore needs a real MBR partition.
4. We care that automatic partition tools doesn't know how to avoid reallocating space allocated to the firmware (and that manual tools can't warn about it).
Given the extremely narrow scope, I'm suggest that requirement #4 does not exist on any system ;-).
Daniel.