Add a comment explaining the design goals of bloblist, to make it easier for people to understand and comment on the structure.
Signed-off-by: Simon Glass sjg@chromium.org ---
doc/develop/bloblist.rst | 2 ++ include/bloblist.h | 62 ++++++++++++++++++++++++++++++++++++++-- 2 files changed, 62 insertions(+), 2 deletions(-)
diff --git a/doc/develop/bloblist.rst b/doc/develop/bloblist.rst index 572aa65d764..81643c7674b 100644 --- a/doc/develop/bloblist.rst +++ b/doc/develop/bloblist.rst @@ -11,6 +11,8 @@ 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.
+For the design goals of bloblist, please see the comments at the top of the +`bloblist.h` header file.
Passing state through the boot process -------------------------------------- diff --git a/include/bloblist.h b/include/bloblist.h index d0e128acf10..9684bfd5f4b 100644 --- a/include/bloblist.h +++ b/include/bloblist.h @@ -3,8 +3,66 @@ * This provides a standard way of passing information between boot phases * (TPL -> SPL -> U-Boot proper.) * - * A list of blobs of data, tagged with their owner. The list resides in memory - * and can be updated by SPL, U-Boot, etc. + * It consists of a list of blobs of data, tagged with their owner / contents. + * The list resides in memory and can be updated by SPL, U-Boot, etc. + * + * Design goals for bloblist: + * + * 1. Small and efficient structure. This avoids UUIDs or 16-byte name fields, + * since a 32-bit tag provides enough space for all the tags we will even need. + * If UUIDs are desired, they can be added inside a particular blob. + * + * 2. Avoids use of pointers, so the structure can be relocated in memory. The + * data in each blob is inline, rather than using pointers. + * + * 3. Bloblist is designed to start small in TPL or SPL, when only a few things + * are needed, like the memory size or whether console output should be enabled. + * Then it can grow in U-Boot proper, e.g. to include space for ACPI tables. + * + * 4. The bloblist structure is simple enough that it can be implemented in a + * small amount of C code. The API does not require use of strings or UUIDs, + * which would add to code size. For Thumb-2 the code size needed in SPL is + * approximately 940 bytes (e.g. for chromebook_bob). + * + * 5. Bloblist uses 16-byte alignment internally and is designed to start on a + * 16-byte boundary. Its headers are multiples of 16 bytes. This makes it easier + * to deal with data structures which need this level of alignment, such as ACPI + * tables. For use in SPL and TPL the alignment can be relaxed, since it can be + * relocated to an aligned address in U-Boot proper. + * + * 6. Bloblist is designed to be passed to Linux as reserved memory. While linux + * doesn't understand the bloblist header, it can be passed the indivdual blobs. + * For example, ACPI tables can reside in a blob and the address of those is + * passed to Linux, without Linux ever being away of the existence of a + * bloblist. Having all the blobs contiguous in memory simplifies the + * reserved-memory space. + * + * 7. Bloblist tags are defined in the enum below. There is an area for + * project-specific stuff (e.g. U-Boot, TF-A) and vendor-specific stuff, e.g. + * something used only on a particular SoC. There is also a private area for + * temporary, local use. + * + * 8. Bloblist includes a simple checksum, so that each boot phase can update + * this and allow the next phase to check that all is well. While the bloblist + * is small, this is quite cheap to calculate. When it grows (e.g. in U-Boot\ + * proper), the CPU is likely running faster, so it is not prohibitive. Having + * said that, U-Boot is often the last phase that uses bloblist, so calculating + * the checksum there may not be necessary. + * + * 9. It would be possible to extend bloblist to support a non-contiguous + * structure, e.g. by creating a blob type that points to the next bloblist. + * This does not seem necessary for now. It adds complexity and code. We can + * always just copy it. + * + * 10. Bloblist is designed for simple structures, those that can be defined by + * a single C struct. More complex structures should be passed in a device tree. + * There are some exceptions, chiefly the various binary structures that Intel + * is fond of creating. But device tree provides a dictionary-type format which + * is fairly efficient (for use in U-Boot proper and Linux at least), along with + * a schema and a good set of tools. New formats should be designed around + * device tree rather than creating new binary formats, unless they are needed + * early in boot (where libfdt's 3KB of overhead is too large) and are trival + * enough to be described by a C struct. * * Copyright 2018 Google, Inc * Written by Simon Glass sjg@chromium.org