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”! > > 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
