Add a description of the purpose of bloblist and how to use it.
Signed-off-by: Simon Glass sjg@chromium.org ---
Changes in v3: None Changes in v2: None
doc/README.bloblist | 82 +++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 82 insertions(+) create mode 100644 doc/README.bloblist
diff --git a/doc/README.bloblist b/doc/README.bloblist new file mode 100644 index 00000000000..b0e787b97db --- /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