openbmc/phosphor-ipmi-blobs/README.md

5 to blob-specific implementations. Introduction This mechanism supports reading
11 - Enumerating blobs
12 - Opening a blob for reading or writing
13 - Writing blob content
14 - Committing a blob
15 - Polling until the blob has been committed
16 - Closing a blob
17 - Reading blob content
18 - Deleting a blob
27 identified by NULL-terminated C strings. This protocol supports
28 implementation-specific blob identifiers; some blobs may have single well-known
31 well-known blob that supports BMC firmware updates, whereas "/g/skm/[N]" may
36 maximum size is platform-dependent; theoretically a packet could be up to 256
39 If an identifier is malformed, e.g. does not have a trailing NUL-byte or is
43 [openbmc oen](https://github.com/openbmc/phosphor-host-ipmid/blob/194375f2676715a0e0697bab63234a4ef…
48 reference to the command body starts after the 3 bytes of OEM header, the 1-byte
49 subcommand code, and (in the cases where the command body is non-empty) a
50 two-byte CRC over all data that follows in the body.
52 All non-empty responses should lead with a two-byte CRC. The CRC algorithm is
53 CRC-16-CCITT (poly 0x1021).
55 All multi-byte values are encoded as little-endian. All structs are assumed
78     uint32_t blob_idx; /* 0-based index of blob to retrieve. */
117     <bits 2-7 reserved>
118     <bits 8-15 given blob-specific definitions>
123 for writing". Optional blob-specific behavior: if the blob has been open for
147     uint32_t offset; /* The byte sequence start, 0-based. */
164 (3 bytes), sub-command (1 byte), and the structure size (4 bytes). If no bytes
180     uint32_t offset; /* The byte sequence start, 0-based. */
187 bytes to write is the size of the command body less the OEN and sub-command (4
202     uint8_t  commit_data[]; /* Optional blob-specific commit data. */
211 (implementation dependant). Callers are expected to poll on `BmcBlobSessionStat`
219 The `BmcBlobClose` command must be called after commit-polling has finished,
269     uint8_t  metadata[]; /* Optional blob-specific metadata. */
282     <bits 5-7 reserved>
283     <bits 8-15 given blob-specific definitions>
292 Immediately following this structure are optional blob-specific bytes. The
294 sub-command and less the structure size. The metadata must fit in a single IPMI
295 packet, which has a platform-dependent maximum size. (For reference, Aspeed
322     uint8_t  metadata[]; /* Optional blob-specific metadata. */
329 blob-specific, and not all blobs must support it.
338     uint32_t offset; /* The byte sequence start, 0-based. */
345 bytes to write is the size of the command body less the OEN and sub-command (4
353 "send-with-retries" strategy to ensure that commands make their way from the
356 It is possible that an IPMI command successfully invokes the BMC-side handler,
360 value if repeated, while avoiding potentially destructive side-effects.
376 - The blob manager will only call `open()` on your handler if the handler
378 - The blob manager will only call a session-based command against your handler
380   - The caveat is the open command where the session is provided to the handler
382 - The blob manager will only call `delete()` on a blob if there are no open