Entry | |
---|---|
R0 | 19, and flags: |
Bit 8: Input function provides physical addresses (=1), else logical (=0) | |
Bit 9: DMA is writing to RAM | |
Bit 10: DMA is complete | |
Bits 11+: Reserved (set to 0) | |
R1 | R12 value to provide to called functions |
R2 | Initial R9 value to provide to input function |
R3 | Pointer to input function |
R4 | Initial R9 value to provide to output function |
R5 | Pointer to output function (if bit 10 of R0 clear) |
Exit | |
---|---|
R2 | Updated to match last value returned by input function |
R4 | Updated to match last value returned by output function |
- | All other registers preserved |
This call performs address translation and cache maintenance operations, as necessary to allow for DMA to be performed to/from cacheable memory. It’s intended to be used as a replacement for the OS_Memory 0 “Enable/disable caching” feature, since there are many issues with that approach on modern systems.
As with OS_Memory 0, OS_Memory 19 must be called twice per DMA operation: Once at the start of the operation (with bit 10 of R0 clear), and once at the end of the operation (with bit 10 set). The same list of input addresses ranges must be provided each time.
Key differences from OS_Memory 0 are as follows:
OS_Memory 19 operates under the following principles:
Service_PagesUnsafe is issued by the OS whenever the physical page associated with a logical address is being “transparently” replaced with another physical page. This can occur as the result of the original physical page being requested by a Dynamic Area PreGrow handler. Programs which perform DMA need to listen out for this service call so that they can pause DMA while the pages are being moved, and then resume DMA (using the new logical → physical mapping) once the page move is complete.
Because OS_Memory 0 does not perform any operations which might cause pages to be moved in this manner, programs which uses OS_Memory 0 only need to start paying attention to Service_PagesUnsafe once they’ve received the results from the OS. But for OS_Memory 19, results are returned to your code in a piecemeal fashion. If your input or output function performs operations which may trigger page movement (e.g. allocating pages from the RMA), extra care is needed in order to deal with Service_PagesUnsafe correctly.
If a call to Service_PagesUnsafe occurs during the call to OS_Memory, and it affects the pages which are involved in the OS_Memory call: