Merge branch '2018-11-25-master-imports'

- Bring in the series from Simon for SPL logging support and bloblist

2 files changed, 83 insertions, 1 deletions

diff --git a/doc/README.bloblist b/doc/README.bloblist
new file mode 100644
index 0000000000..b0e787b97d
--- /dev/null
+++ b/doc/README.bloblist
@@ -0,0 +1,82 @@
+# SPDX-License-Identifier: GPL-2.0+
+
+Blob Lists - bloblist
+=====================
+
+Introduction
+------------
+
+A bloblist provides a way to store collections of binary information (blobs) in
+a central structure. Each record of information is assigned a tag so that its
+owner can find it and update it. Each record is generally described by a C
+structure defined by the code that owns it.
+
+
+Passing state through the boot process
+--------------------------------------
+
+The bloblist is created when the first U-Boot component runs (often SPL,
+sometimes TPL). It is passed through to each successive part of the boot and
+can be accessed as needed. This provides a way to transfer state from one part
+to the next. For example, TPL may determine that a watchdog reset occurred by
+reading an SoC register. Reading the register may reset the value, so that it
+cannot be read a second time. So TPL can store that in a bloblist record which
+can be passed through to SPL and U-Boot proper, which can print a message
+indicating that something went wrong and the watchdog fired.
+
+
+Blobs
+-----
+
+While each blob in the bloblist can be of any length, bloblists are designed to
+hold small amounts of data, typically a few KB at most. It is not possible to
+change the length of a blob once it has been written. Each blob is normally
+created from a C structure which can beused to access its fields.
+
+
+Blob tags
+---------
+
+Each blob has a tag which is a 32-bit number. This uniquely identifies the
+owner of the blob. Blob tags are listed in enum blob_tag_t and are named
+with a BLOBT_ prefix.
+
+
+Single structure
+----------------
+
+There is normally only one bloblist in U-Boot. Since a bloblist can store
+multiple blobs it does not seem useful to allow multiple bloblists. Of course
+there could be reasons for this, such as needing to spread the blobs around in
+different memory areas due to fragmented memory, but it is simpler to just have
+a single bloblist.
+
+
+API
+---
+
+Bloblist provides a fairly simple API which allows blobs to be created  and
+found. All access is via the blob's tag.
+
+
+Finishing the bloblist
+----------------------
+
+When a part of U-Boot is about to jump to the next part, it can 'finish' the
+bloblist in preparation for the next stage. This involves adding a checksum so
+that the next stage can make sure that the data arrived safely. While the
+bloblist is in use, changes can be made which will affect the checksum, so it
+is easier to calculate the checksum at the end after all changes are made.
+
+
+Future work
+-----------
+
+Bootstage has a mechanism to 'stash' its records for passing to the next part.
+This should move to using bloblist, to avoid having its own mechanism for
+passing information between U-Boot parts.
+
+
+Simon Glass
+sjg@chromium.org
+12-Aug-2018
diff --git a/doc/README.trace b/doc/README.trace
index 74ba26a5a4..2e7ca3319a 100644
--- a/doc/README.trace
+++ b/doc/README.trace
@@ -88,7 +88,7 @@ stdin=serial
 stdout=serial
 
 Environment size: 117/8188 bytes
-=>sb save host 0 trace 0 ${profoffset}
+=>host save host 0 trace 0 ${profoffset}
 11405888 bytes written in 10 ms (1.1 GiB/s)
 =>reset