MMIO service implementation with MMIO bundle interfaces. Should be
relatively easy to adapt to physical interfaces by wrapping the wires to
channels then bundles. Allows the implementation to be shared and (hopefully)
platform independent.
Whether or not to support unaligned accesses is up to the clients. The header
and manifest do not support unaligned accesses and throw away the lower three
bits.
Only allows one outstanding request at a time. This is enforced in hardware
by a `MaxOutstandingLimiter` on the command channel, which stalls incoming
commands until the previous response has been consumed. If a client fails to
return a response, the MMIO service will hang. TODO: add some kind of
timeout.
Implementation-defined MMIO layout:
- 0x0: 0 constant
- 0x8: Magic number (0x207D98E5_E5100E51)
- 0x12: ESI version number (0)
- 0x18: Location of the manifest ROM (absolute address)
- 0x100: Start of MMIO space for requests. Mapping is contained in the
manifest so can be dynamically queried.
- Directly above the last client allocation (rounded up to a power of two):
Start of the manifest ROM. It matches any address with a bit set above
the client space, so it is never truncated by its window.
- addr(Manifest ROM) + 0: Size of compressed manifest
- addr(Manifest ROM) + 8: Start of compressed manifest
This layout _should_ be pretty standard, but different BSPs may have various
different restrictions. Any BSP which uses this service implementation will
have this layout, possibly with an offset or address window.
Definition at line 586 of file common.py.
