1# Virtual PNOR Functionality 2 3In the abstract, the virtual PNOR function shifts mboxd away from accessing raw 4flash to dynamically presenting a raw flash image to the host from a set of 5backing files. 6 7Enabling the feature virtualises both the host's access to the flash (the mbox 8protocol), and the BMC's access to the flash (via some filesystem on top of the 9flash device). 10 11## Do I want to use this feature in my platform? 12 13Maybe. It depends on how the image construction is managed, particularly the 14behaviour around writes from the host. It is likely the scheme will prevent 15firmware updates from being correctly applied when using flash tools on the 16host. 17 18## Use-case Requirements 19 20Currently, the virtual PNOR implementation requires that: 21 22- The host expect an FFS layout (OpenPOWER systems) 23- The BMC provide a directory tree presenting the backing files in a hierarchy 24 that reflects the partition properties in the FFS table of contents. 25 26## Implementation Behavioural Properties 27 281. The FFS ToC defines the set of valid access ranges in terms of partitions 292. The read-only property of partitions is enforced 303. The ToC is considered read-only 314. Read access to valid ranges must be granted 325. Write access to valid ranges may be granted 336. Access ranges that are valid may map into a backing file associated with the 34 partition 357. A read of a valid access range that maps into the backing file will render 36 the data held in the backing file at the appropriate offset 378. A read of a valid access range that does not map into the backing file will 38 appear erased 399. A read of an invalid access range will appear erased 4010. A write to a valid access range that maps into the backing file will update 41 the data in the file at the appropriate offset 4211. A write to a valid access range that does not map into the backing file will 43 expand the backing file to accommodate the write. 4412. A write to a valid access range may fail if the range is not marked as 45 writeable. The error should be returned in response to the request to open 46 the write window intersecting the read-only range. 4713. A write of an invalid access range will return an error. The error should be 48 returned in response to the request to open the write window covering the 49 invalid range. 50 51The clarification on when the failure occurs in points 11 and 12 is useful for 52host-side error handling. Opening a write window gives the indication that 53future writes are expected to succeed, but in both cases we define them as 54always failing. Therefore we should not give the impression to the host that 55what it is asking for can be satisfied. 56