Lines Matching full:flash
20 access to a flash device(s) with the specifics of how the host is required to
35 for the host to control access to the flash device(s).
38 (the iLPC-to-AHB bridge) to directly manipulate the BMCs own flash controller.
42 1. Every piece of the host software stack that needs flash access (HostBoot,
43 OCC, OPAL, ...) has to have a complete driver for the flash controller,
44 update it on each BMC generation, have all the quirks for all the flash
58 system in some kind of data center, not only the host flash needs to be
60 flash too as nothing can be trusted. So we want to disable it.
65 the flash controller. All flash erase and write operations are performed by the
66 BMC and the BMC only. (We can allow direct reads from flash under some
72 window or a write window onto the flash.
80 window and which offset into the flash it maps.
82 * A read window can be a direct window to the flash controller space (ie.
83 0x3000\_0000) or it can be a window to a RAM image of a flash. It doesn't have
84 to be the full size of the flash per protocol (commands can be used to "slide"
85 it to various parts of the flash) but if it's set to map the actual flash
87 flash. The host makes no assumption, it's your choice what to provide. The
88 simplest implementation is to just route to the flash read/only.
93 command to map the write window at a given offset of the flash, the BMC should
94 copy that portion of the flash into a reserved memory buffer, and modify the
98 send a command to "commit" those updates to flash.
102 details are still being ironed out: either mapping the full flash read only or
103 reset to a "window" that is either at the bottom or top of the flash. The
104 current implementation resets to point to the full flash.
204 host requests access to a section of flash. It is worth noting that the host
210 control when the changed blocks are written to flash.
238 In order to access flash contents, the host must request a window be opened at
239 the flash offset it would like to access with the CREATE_{READ,WRITE}_WINDOW
245 which correctly represents the state of flash at the time the response is given.
280 of back to the flash, at which point the dirty or erased marking is cleared
282 written to flash unless an explicit flush call was successful, a close of an
284 write window was successful - otherwise consistency between the flash and memory
293 The host may lock an area of flash using the MARK_LOCKED command. Any attempt
294 to mark dirty or erased this area of flash must fail with the LOCKED_ERROR
296 of flash however changes to a locked area of flash must never be written back
297 to the backing data source (i.e. that area of flash must be treated as read
299 of flash which is not clean in the current window must fail with PARAM_ERROR.
300 Locked flash regions must persist across a BMC reboot or daemon restart. It is
319 The BMC may at some points require access to the flash and the BMC daemon must
320 set the BMC Flash Control Lost event when the BMC is accessing the flash behind
322 contents of the active window could be inconsistent with the contents of flash.
388 BUSY - Daemon in suspended state (currently unable to access flash)
396 LOCKED_ERROR - Tried to mark dirty or erased locked area of flash
422 to specify flash addresses of at least 256MB.
439 use it. Currently, this means pointing back to BMC flash
475 Args 8: Num Allocated Flash IDs
500 Args 0: Flash ID
503 Args 0-3: Flash size (bytes)
507 Args 0-1: Flash size (blocks)
515 Args 0-1: Requested flash offset (blocks)
518 Args 0-1: Requested flash offset (blocks)
519 Args 2-3: Requested flash size to access (blocks)
522 Args 0-1: Requested flash offset (blocks)
523 Args 2-3: Requested flash size to access (blocks)
524 Args 4: Flash ID
532 Args 4-5: Flash offset mapped by window (blocks)
534 The flash offset which the host requests access to is always
535 taken from the start of flash - that is it is an absolute
536 offset into flash.
547 The flash offset mapped by the window is an absolute flash
548 offset and must be less than or equal to the flash offset
595 Args 0-1: Flash offset to mark from base of flash (blocks)
611 Offsets are given as an absolute (either into flash (V1) or the
617 erase a flash area before writing to it by setting ARG[4]. This
628 Args 0-1: Flash offset to mark from base of flash (blocks)
640 In V1 this can also be used to mark parts of the flash
684 Args 0: Flash ID
686 Args 0 : Flash Name Length (bytes)
687 Args 1-10: Flash Name / UID
689 Describes a flash with some kind of identifier useful to the
693 as part of the flash name field which the host should expect to
700 Args 0-1: Flash offset to lock (blocks)
702 Args 4: Flash ID
706 Lock an area of flash so that the host can't mark it dirty or
730 0x40: BMC Flash Control Lost (V2)
758 0x40 - BMC Flash Control Lost: (V2)
760 controls access to the flash (most likely because some
762 flash and has suspended the BMC daemon to preclude
765 control of the flash (the host isn't able to clear it
768 correctly reflect the contents of flash while this bit is set.