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 _______________________________________________ boot-architecture mailing list [email protected] https://lists.linaro.org/mailman/listinfo/boot-architecture
