mirror of
https://github.com/u-boot/u-boot.git
synced 2024-11-28 23:23:30 +08:00
Add bloblist documentation
Add a description of the purpose of bloblist and how to use it. Signed-off-by: Simon Glass <sjg@chromium.org>
This commit is contained in:
parent
919e7a8fb6
commit
cff8870131
82
doc/README.bloblist
Normal file
82
doc/README.bloblist
Normal file
@ -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
|
Loading…
Reference in New Issue
Block a user