On Wed, 11 Mar 2020 at 07:48, Heinrich Schuchardt <[email protected]> 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 > >> <[email protected]> > >> a écrit : > >> > >>> On Tue, Mar 10, 2020 at 05:35:40PM +0100, Francois Ozog wrote: > >>>>>> 0.2 - normative text > >>>>>> The normative section shall be stated clearly: is " 1.2. Guiding > >>>>>> Principles" normative? > >>>>>> > >>>>>> IETF and ETSI have different language conventions to express > >>>>>> absolutely mandated and various levels of optionality. This spec may > >>>>>> be red by Telecom people or Linux people. Their interpretation may be > >>>>>> erroneous on words such as "shall" (ETSI "SHALL" = "IETF "MUST"). The > >>>>>> language need to be explicit. > >>>>> > >>>>> Fair point. Do you have a suggesting on how to proceed here? > >>>>> > >>>> > >>>> Thanks Leif for the links. I tend to like the ETSI one because it is > >>>> somewhat complete on necessary english grammar stuff. > >>>> But I am flexible, important we state explicitly the reference > >>>> document and we use the language constructs. > >>> > >>> Does ETSI offer us "features" that are missing from RFC 2119. > >>> > >>> Personally I would favour RFC 2119 simply because it is so much better > >>> known than the ETSI drafting rules. > >>> > >>> If you cite RFC 2119 and I don't have to go and read anything... and > >>> even if I did it is super concise and quick to read. > >>> > >>> Cite ETSI drafting rules, clause 3 and I have to put in a lot more > >>> effort. > >>> > >>>> > >>>>>> I - protective offsets > >>>>>> EBBR 1.0 states in "4.1. Partitioning of Shared Storage" that > >>>>>> "Automatic partitioning tools (e.g. an OS installer) must not create > >>>>>> partitions within the first 1MiB of storage, or delete, move, or > >>>>>> modify protective partition entries." > >>>>>> > >>>>>> StandaloneMM is 2.5MB by itself with U-Boot being over 1MB without > >>> the > >>>>>> variable rework done and update capsules. 4MB seems the minimum. 8MB > >>>>>> to get margin and 16MB for A/B scheme. > >>>>> > >>>>> 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. > > > > 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! > Best regards > > Heinrich > > > > >> > >>> > >>> In all other cases a bulky firmware installed on shared media must have > >>> a protective partition (with the appropriate flags) to prevent partition > >>> tools from damaging it anyway. In such a case it does not matter if > >>> there is firmware above the 1MB boundary. > >>> > >>> > >>>>>> EBBR same paragraph also states: > >>>>>> "Automatic partitioning tools (e.g. an OS installer) must not create > >>>>>> partitions within the first 1MiB of storage, or delete, move, or > >>>>>> modify protective partition entries. Manual partitioning tools should > >>>>>> provide warnings when modifying protective partitions or creating > >>>>>> partitions within the first 1MiB." > >>>>>> > >>>>>> is it expected that Linaro upstreams changes in installation tools, > >>>>>> partition tools to conform to this (with updated to be agreed > >>>>>> minimum)? > >>>>> > >>>>> I would expect so, if they aren't already doing that. > >>>> > >>>> Will need to create initiatives for that. > >>> > >>> Pretty much all tools already respect the 1MiB boundary. Sometimes they > >>> use an "expert mode" rather than a explicit warning but I'd view that > >>> as equivalent. > >>> > >>> > >>> Daniel. > >>> > > > -- François-Frédéric Ozog | Director Linaro Edge & Fog Computing Group T: +33.67221.6485 [email protected] | Skype: ffozog _______________________________________________ boot-architecture mailing list [email protected] https://lists.linaro.org/mailman/listinfo/boot-architecture
