On Tue, May 08, 2018 at 06:25:11PM +0200, Alexander Graf wrote:
On 08.05.18 16:38, Daniel Thompson wrote:
On Fri, May 04, 2018 at 02:41:56PM -0400, William Mills wrote:
Image is dedicated for one machine type (or closely related set). If raw mode is needed use MBR with 2MB reserved space OS should not touch reserved space in MBR
I'd still prefer that EBBR compliant firmware (where firmware is loaded from shared media) have a protective partition describing the first 2MB at the point the firmware is installed to the shared media.
The problem with a protective partition is that getting changes into partitioning tools is really hard - and there are many of those out there :).
Sorry, don't follow.
Why does requiring an EBBR compliant firmware to provide a protective partition describing the first N megabytes imply updating all partitioning tools? It is not the OS that has to create it; it is the firmware author and they can choose a working tool for this (possibly in expert mode to create the non-aligned partition).
A lot of OSs have installers which end up repartitioning existing disk targets. I wouldn't vouch for them to not nuke non-ESP partitions :).
I wouldn't wish to vouch for this either... so even if EBBR does allocate a partition ID I agree it could take a long time to gain support from installers. Its also clearly the case that there may exist boot ROMs that force a different ID anyway.
However putting a requirement on firmware to put a partition over the first megabyte doesn't contradict anything either and it does permits the OS installer to offer a better user experience (i.e. not nuking partitions) over time.
Daniel.
Also, I think we should only declare 1MB as reserved. If someone needs more space, they should really go the dedicated / separate partition route and use something like SPL to read from one of the options below.
The reason 1MB is so convenient is that basically all partitioning tools today already give you a natural 1MB alignment. So there are no OS changes needed.
Again, don't entirely follow.
"they should really go the dedicated / separate partition route" implies that implies that an installer should try to recognise it as a protective partition and not nuke it (unless the user really, really insists).
That also implies it can leave a pre-existing protective partition covering the first N megabytes alone doesn't it?
If we conclude that reusing the ESP is good enough then we don't need to manually cover anything. We can simply declare 0.2MB (end of GPT) - 1MB (start of first partition) of the target disk as reserved for firmware purposes. If we make it as easy as shoving all additional resources into the ESP, everything will "just work".
If using GPT, firmware should place needed files in either:
- Vendor registered dir in EFI partition
- GUID identified partitions w/ attribute bit 0 set (can fallback to using names if GUID not found)
No need to couple these to GPT. You can always have a vendor registered directory in the ESP with MBR as well.
For GUID partitions a GPT is obviously necessary.
Should we consider a future case #3? Case #3: New Platforms where firmware and OS share storage
Storage uses std GPT with no exceptions. Image may work with N preknown boards that are unrelated. Firmware files are all in a vendor specified dir in the EFI partition
Not sure about this.
For eMMC we'd prefer the boot ROM just load the firmware from the boot partition, then the OS can do whatever it wants with the main media (which could ship completely unpartitioned and leave it to the OS).
For UFS, the case is similar, although with multi-layer partitioning the terminology is hard. Either way we should rely on flash partitioning so that the firmware can be entirely separated by hardware partition. Again the flash partition to OS will be installed has not particular need to be partitioned in any way at all.
When booting from media without any hardware partitioning the case #3 scheme looks good although even there I'm not sure about the need to have an image work on unrelated boards though. To be useful it implies that EBBR implementations from different vendors can be combined in one disk image (i.e. that vendors will make EBBR implementations available with a license to redistribute them). We probably don't want to go there... even by implication!
Well, with a fully U-Boot stack for example this should be easily achievable. I don't think it's a bad idea to suggest. Imagine a world where you could download a single image that just happens to run on all 96boards!
I don't object to it. I just think its somewhat irrelevant. I'm not sure the distros should be shipping all these vendor firmwares (since they can and IMHO should assume the firmware is already installed on the board) but if distros don't do it then who is going to make the single image and why?
I care *so* much more about the case where we expect good quality firmware located on the eMMC/UFS that is able to boot that single image from *removable* media and then run an installer that can install the OS to the eMMC/UFS without destroying the firmware by mistake.
I agree.
Alex