1*6a51e5f4SPatrick Williams# Virtual PNOR Functionality 20971299fSAndrew Jeffery 30971299fSAndrew JefferyIn the abstract, the virtual PNOR function shifts mboxd away from accessing raw 40971299fSAndrew Jefferyflash to dynamically presenting a raw flash image to the host from a set of 50971299fSAndrew Jefferybacking files. 60971299fSAndrew Jeffery 70971299fSAndrew JefferyEnabling the feature virtualises both the host's access to the flash (the mbox 80971299fSAndrew Jefferyprotocol), and the BMC's access to the flash (via some filesystem on top of the 90971299fSAndrew Jefferyflash device). 100971299fSAndrew Jeffery 11*6a51e5f4SPatrick Williams## Do I want to use this feature in my platform? 120971299fSAndrew Jeffery 130971299fSAndrew JefferyMaybe. It depends on how the image construction is managed, particularly the 140971299fSAndrew Jefferybehaviour around writes from the host. It is likely the scheme will prevent 150971299fSAndrew Jefferyfirmware updates from being correctly applied when using flash tools on the 160971299fSAndrew Jefferyhost. 170971299fSAndrew Jeffery 18*6a51e5f4SPatrick Williams## Use-case Requirements 190971299fSAndrew Jeffery 200971299fSAndrew JefferyCurrently, the virtual PNOR implementation requires that: 210971299fSAndrew Jeffery 22*6a51e5f4SPatrick Williams- The host expect an FFS layout (OpenPOWER systems) 23*6a51e5f4SPatrick Williams- The BMC provide a directory tree presenting the backing files in a hierarchy 240971299fSAndrew Jeffery that reflects the partition properties in the FFS table of contents. 250971299fSAndrew Jeffery 26*6a51e5f4SPatrick Williams## Implementation Behavioural Properties 270971299fSAndrew Jeffery 280971299fSAndrew Jeffery1. The FFS ToC defines the set of valid access ranges in terms of partitions 290971299fSAndrew Jeffery2. The read-only property of partitions is enforced 300971299fSAndrew Jeffery3. The ToC is considered read-only 310971299fSAndrew Jeffery4. Read access to valid ranges must be granted 320971299fSAndrew Jeffery5. Write access to valid ranges may be granted 33*6a51e5f4SPatrick Williams6. Access ranges that are valid may map into a backing file associated with the 34*6a51e5f4SPatrick Williams partition 350971299fSAndrew Jeffery7. A read of a valid access range that maps into the backing file will render 360971299fSAndrew Jeffery the data held in the backing file at the appropriate offset 370971299fSAndrew Jeffery8. A read of a valid access range that does not map into the backing file will 380971299fSAndrew Jeffery appear erased 390971299fSAndrew Jeffery9. A read of an invalid access range will appear erased 400971299fSAndrew Jeffery10. A write to a valid access range that maps into the backing file will update 410971299fSAndrew Jeffery the data in the file at the appropriate offset 42*6a51e5f4SPatrick Williams11. A write to a valid access range that does not map into the backing file will 43*6a51e5f4SPatrick Williams expand the backing file to accommodate the write. 440971299fSAndrew Jeffery12. A write to a valid access range may fail if the range is not marked as 450971299fSAndrew Jeffery writeable. The error should be returned in response to the request to open 460971299fSAndrew Jeffery the write window intersecting the read-only range. 47*6a51e5f4SPatrick Williams13. A write of an invalid access range will return an error. The error should be 48*6a51e5f4SPatrick Williams returned in response to the request to open the write window covering the 49*6a51e5f4SPatrick Williams invalid range. 500971299fSAndrew Jeffery 510971299fSAndrew JefferyThe clarification on when the failure occurs in points 11 and 12 is useful for 520971299fSAndrew Jefferyhost-side error handling. Opening a write window gives the indication that 530971299fSAndrew Jefferyfuture writes are expected to succeed, but in both cases we define them as 540971299fSAndrew Jefferyalways failing. Therefore we should not give the impression to the host that 550971299fSAndrew Jefferywhat it is asking for can be satisfied. 56