cbfstool: Change FMD annotation to flags

The idea of "annotation" for firmware sections was pretty flexible, but
in future we will want multiple attributes applied to same area. For
example, indicate the section must be preserved when updating firmware
so serial number or MAC address can be preserved.

The solution here is to extend annotation so it can take multiple
identifiers (flags) in a row. For example, to declare a 64KB COREBOOT
section as CBFS using annotation:

 COREBOOT(CBFS)@0x0 64k

If there's a new flag "PRESERVE" indicating the section must be
preserved before update, we can declare it following CBFS flag:

 COREBOOT(CBFS PRESERVE)@0x0 64k

The flags are directly parsed in fmd_parser, and stored in an union
flashmap_flags. Output modules can choose to ignore or process the
flags.

Currently the only supported flag is "CBFS" (for backward compatible
with annotation). There will be more new flags in follow up patches.

BUG=chromium:936768
TEST=make; boots on x86 "google/eve" and arm "google/kukui" devices

Change-Id: Ie2d99f570e6faff6ed3a4344d6af7526a4515fae
Signed-off-by: Hung-Te Lin <hungte@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/31706
Reviewed-by: Julius Werner <jwerner@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>

1 files changed, 7 insertions, 5 deletions

diff --git a/util/cbfstool/README.fmaptool b/util/cbfstool/README.fmaptool
index f806c43d78..86fc3b2192 100644
--- a/util/cbfstool/README.fmaptool
+++ b/util/cbfstool/README.fmaptool
@@ -9,12 +9,12 @@ scanner, parser, semantic analyser, and flashmap converter. Here's an informal l
 
 # <line comment>
 <image name>[@<memory-mapped address>] <image size> {
-	<section name>[@<offset from start of image>] [<section size>] [{
+	<section name>[(flags)][@<offset from start of image>] [<section size>] [{
 		<subsection name>[@<offset from start of parent section>] [<subsection size>] [{
 			# Sections can be nested as deeply as desired
-			<subsubsection name>[(CBFS)][@...] [...] [{...}]
+			<subsubsection name>[(flags)][@...] [...] [{...}]
 		}]
-		[<subsection name>[(CBFS)][@...] [...] [{...}]]
+		[<subsection name>[(flags)][@...] [...] [{...}]]
 		# There can be many subsections at each level of nesting: they will be inserted
 		# sequentially, and although gaps are allowed, any provided offsets are always
 		# relative to the closest parent node's and must be strictly increasing with neither
@@ -33,9 +33,11 @@ neither meaning nor place in a real file. The <.*> s indicate placeholders for p
 The [.*] s indicate that a portion of the file could be omitted altogether:
  - Just because something is noted as optional doesn't mean it is in every case: the answer might
    actually depend on which other information is---or isn't---provided.
- - In particular, it is only legal to place a (CBFS) annotation on a leaf section; that is, choosing
+ - The "flag" specifies the attribute or type for given section. The most
+   important supported flag is "CBFS", which indicates the section will contain a CBFS structure.
+ - In particular, it is only legal to place a (CBFS) flag on a leaf section; that is, choosing
    to add child sections excludes the possibility of putting a CBFS in their parent. Such
-   annotations are only used to decide where CBFS empty file headers should be created, and do not
+   flags are only used to decide where CBFS empty file headers should be created, and do not
    result in the storage of any additional metadata in the resulting FMAP section.
 Additionally, it's important to note these properties of the overall file and its values:
  - Other than within would-be strings and numbers, whitespace is ignored. It goes without saying