This is an automated email from the ASF dual-hosted git repository.
ccollins pushed a commit to branch master
in repository https://gitbox.apache.org/repos/asf/mynewt-newt.git
The following commit(s) were added to refs/heads/master by this push:
new 10a946c mfg/README.md: Section describing MMR structure
10a946c is described below
commit 10a946ce5b83dc0020bd4c638c5298227b091dc8
Author: Christopher Collins <ccoll...@apache.org>
AuthorDate: Wed Aug 12 16:47:53 2020 -0700
mfg/README.md: Section describing MMR structure
---
newt/mfg/README.md | 55 ++++++++++++++++++++++++++++++++++++++++++++++++++++++
1 file changed, 55 insertions(+)
diff --git a/newt/mfg/README.md b/newt/mfg/README.md
index 8c29a27..ceb4340 100644
--- a/newt/mfg/README.md
+++ b/newt/mfg/README.md
@@ -105,6 +105,61 @@ The `meta` manifest object describes the contents of an
mfgimage's MMR. It cons
| `flash_map_present` | `true` if the MMR contains a set of flash area TLVs;
`false` otherwise. |
| `mmrs` | An array of references to external MMRs. |
+### MMR Structure
+
+Every mfgimage contains an MMR (manufacturing meta region). The MMR is always
located at the end of a flash area (that is, the last byte in the MMR occupies
the last byte in the flash area).
+
+In a boot mfgimage, the MMR must go in the first flash area, i.e., the area
containing the boot loader. A non-boot mfgimage can place its MMR in any flash
area.
+
+The reason a boot mfgimage's MMR must go in the boot loader area is to solve a
boot strapping problem. The flash map that bsp.yml defines is not necessarily
the flash map that every device uses; it is just the flash map that gets
embedded in newly built mfg images. This is so becauase the flash map itself
is embedded in the boot mfgimage's MMR. If we change the contents of bsp.yml
and then start manufacturing devices with a new mfgimage, we now have two
different flash maps being used i [...]
+
+An MMR has three basic components: header, TLVs, and footer.
+
+
+```
+ 0 1 2 3
+ 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ -,
+ |Version (0x01) | 0xff padding | >--
Header
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ -'
+ | TLV type | TLV size | TLV data ("TLV size" bytes) ~
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~
+ ~ ~
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ | TLV type | TLV size | TLV data ("TLV size" bytes) ~
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~
+ ~ ~
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ -,
+ | Region size | 0xff padding | \
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ >-
Footer
+ | Magic (0x3bb2a269) | /
+ +-+-+-+-+-+--+-+-+-+-end of boot loader area+-+-+-+-+-+-+-+-+-+-+ -'
+```
+
+All numeric fields are in host byte order (typically little endian).
+
+The number of TLVs is variable; two are shown above for illustrative purposes.
+
+*Header*
+
+| Field | Description |
+| ----- | ----------- |
+| Version | Manufacturing meta version number; always 0x01. |
+
+*TLVs*
+
+| Field | Description |
+| ----- | ----------- |
+| TLV type | Indicates the type of data to follow. |
+| TLV size | The number of bytes of data to follow. |
+| TLV data | TLV-size bytes of data. |
+
+*Footer*
+
+| Field | Description |
+| ----- | ----------- |
+| Region size | The size, in bytes, of the entire manufacturing meta region;
includes header, TLVs, and footer. |
+| Magic | indicates the presence of the manufacturing meta region. |
### Design
