OS_DynamicArea 22 (changes)
Showing changes from revision #0 to #1:
Added | Removed | Changed
OS_DynamicArea
» OS_DynamicArea 22
OS_DynamicArea 22
(SWI &66)
| Entry | |
|---|---|
| R0 | 22 (reason code) |
| R1 | Area number |
| R2 | Pointer to page list |
| R3 | Number of entries in page list |
| Exit | |
|---|---|
| R2 | Advanced to first entry not processed (or end of list) |
| R3 | Number of entries not processed |
Use
This call is used to map/unmap pages within the logical portion of a Physical Memory Pool.
Notes
Each entry in the page list is 12 bytes in length, structured as follows:
| Word | |
|---|---|
| 0 | DA page number indicating the logical address to alter (Zero-based) |
| 1 | PMP page index: |
| -1: Unmap any page from the indicated location | |
| Other: Index of PMP page to map in to the location | |
| 2 | Page flags: |
| Bits 0-5, 12-14: As per Memory Page Access Flags | |
| Bit 15: Lock page to prevent it from being claimed by another dynamic area | |
| Other bits: Reserved (ignored). Specify zero for future compatibility. |
The entries in the page list will be processed in order. For each entry the kernel will compare the state given in the list with the current state of that DA page number and perform the appropriate action – mapping in a physical page, unmapping a physical page, or altering its flags. If the state of the page matches the state given in the list then no action will be taken.
If an error occurs then R2 and R3 will be updated to point to the first entry that has not been processed. However this may not be the entry that generated the error (it might be caused by an entry further on in the list).
When unmapping a page, the flags specified in word 2 of the page list entry are ignored – if you need to change the flags of a page when mapping it out either change the flags before mapping it out, or issue a OS_DynamicArea 21 call afterwards.
Attempting to map in a PMP page which does not have a physical RAM page allocated to it (via OS_DynamicArea 21) will fail.
Currently a PMP page can only be mapped in at one location at a time. So if page X is currently mapped in to location Y, and you submit a request to map it in at location Z, then the page tables will be updated so that location Y generates a translation fault before location Z is updated to map to page X. As far as the sequential order of operations is performed, this all happens within the context of the entry that requests the page to be moved.
For performance reasons, when making large numbers of changes you should map out any cacheable pages first, then non-cacheable pages, then map in new pages (in any order). The kernel will scan ahead through the list to work out how many pages (and of what type) are being mapped out so that it can work out whether it should perform global or per-page cache/TLB invalidation.
Bit 15 of the flags as specified here maps directly to bit 15 of the flags that are set via OS_DynamicArea 21 – the flag is associated with the physical page, not with its logical mapping.
See also
Social
and
ROOL Store
Buy RISC OS Open merchandise here, including SD cards for Raspberry Pi and more.