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