GitLab

Previously the supervisor stack was read-only in user mode, but since
the supervisor stack is typically empty when the CPU is in user mode,
it's questionable whether any software actually makes use of this
facility.

To simplify support for the long descriptor page table format (which
doesn't support the user-RO + privileged-RW access mode), let's
try and remove usermode SVC stack access completely.

Tested on Raspberry Pi 4

Version 6.48. Tagged as 'Kernel-6_48'

Detail:
RamFS now supports disc sizes up to 2GB-4KB, so raise the dynamic area limit from 508MB.

Admin:
Tested with a disc size up to 928MB

Version 6.46. Tagged as 'Kernel-6_46'

Multiple fixes, mostly related to error handling.

1. Ensure R1 is initialised correctly when generating BadPageNumber
errors (labels 94 & 95). Generally this involves setting it to zero to
indicate that no call to LogOp_MapOut is required. Failing to do this
would typically result in a crash.
2. When branching back to the start of the loop after calling
GetNonReservedPage, ensure R0 is reset to zero. Failing to do this would
have a performance impact on LogOp_MapOut, but shouldn't be fatal.
3. In the main routine, postpone writing back DANode_Size until after
the call to physical_to_ppn (because we may decide to abort the op
and return an error without moving a page).
4. Fix stack offset when accessing PMPLogOp_GlobalTBLFlushNeeded.
Getting this wrong could potentially result in some TLB maintenance
being skipped when moving uncacheable pages.
5. Fix stack imbalance at label 94

Version 6.43. Tagged as 'Kernel-6_43'

Fix GrowFreePoolFromAppSpace (i.e. appspace shrink operation) to issue
UpCall_MemoryMoving / Service_Memory when attempting to shrink PMP-based
appspace (i.e. AMBControl nodes). This fixes (e.g.) BASIC getting stuck
in an abort loop if you try and use OS_ChangeDynamicArea to grow the
free pool.

Version 6.40. Tagged as 'Kernel-6_40'

Fix AreaGrow to read appspace size correctly when appspace is a PMP
(i.e. an AMBControl node). Reading DANode_Size will only report the
amount of memory currently paged in (e.g. by lazy task swapping),
causing AreaGrow to underestimate how much it can potentially take from
the area.

Buggy since its introduction in Kernel-5_35-4_79_2_284, GrowFreePool was
attempting to grow the free pool by shrinking application space, an
operation which OS_ChangeDynamicArea doesn't support. Change it to grow
the free pool instead, and fix a couple of other issues that would have
caused it to work incorrectly (register corruption causing it to request
a size change of zero, and incorrect assumption that
OS_ChangeDynamicArea returns the amount unmoved, when really it returns
the amount moved)

When a DA tries to grow by more than the free pool size, the kernel
should try to take the necessary remaining amount from application
space. Historically this was handled as a combined "take from freepool
and appspace" operation, but with Kernel-5_35-4_79_2_284 this was
changed to use a nested call to OS_ChangeDynamicArea, so first appspace
is shrunk into the free pool and then the target DA is grown using just
the free pool.

However the code was foolishly trying to use ChangeDyn_AplSpace as the
argument to OS_ChangeDynamicArea, which that call doesn't recognise as a
valid DA number. Change it to use ChangeDyn_FreePool ("grow free pool
from appspace"), and also fix up a stack imbalance that would have
caused it to misbehave regardless of the outcome.

TryToShrinkShrinkables_Bytes expected both R1 and R2 to be byte counts,
but AreaGrow was calling with R1 as a byte count and R2 as a page count.
This would have caused it to request the first-found shrinkable to
shrink more than necessary, and also confuse the rest of AreaGrow when
the page-based R2 result of TryToShrinkShrinkables gets converted to a
byte count (when AreaGrow wants it as a page count)

Update AreaShrink so that (when shrinking appspace) CheckAppSpace is
passed the change amount as a negative number, so that Service_Memory is
issued with the correct sign.

Fixes issue reported on the forums, where BASIC was getting confused
because appspace shrinks were being reported as if they were a grow
operation:

https://www.riscosopen.org/forum/forums/4/topics/15067

It looks like this bug was introduced in Kernel-5_35-4_79_2_284
(introduction of PMPs), where the logic for appspace shrinks (which must
be performed via a grow of the free pool or some other DA) were moved
out of AreaGrow and into AreaShrink (because appspace shrinks are now
internally treated as "shrink appspace into free pool")

Dynamic area PostGrow handlers aren't able to return errors, so the V
flag is likely undefined. Fix AreaGrow so that it ignores any V-set
condition returned by the call (especially since the CallPostGrow rapper
will have clobbered any error pointer).

Fixes issue reported on forums:
https://www.riscosopen.org/forum/forums/4/topics/14662

Version 6.34. Tagged as 'Kernel-6_34'

OS_DynamicArea 21, 22 & 25 were using the value of the PMP page list
pointer (DANode_PMP) to determine whether the dynamic area is a PMP or
not. However, PMPs which have had their max physical size set to zero
will don't have the page list allocated, which will cause the test to
fail. Normally this won't matter (those calls can't do anything useful
when used on PMPs with zero max size), except for the edge case of where
the SWI has been given a zero-length page list as input. By checking the
value of DANode_PMP, this would result in the calls incorrectly
returning an error.

Fix this by having the code check the DA flags instead. Also, add a
check to OS_DynamicArea 23 (PMP resize), otherwise non-PMP DAs could end
up having page lists allocated for them.

In OS_DynamicArea 2, a stack imbalance would occur if an error is
encountered while releasing the physical pages of a PMP (R1-R8 pushed,
but only R1-R7 pulled). Fix it, but also don't bother storing R1, since
it's never modified.

* Fix caching of page table entry flags (was never updating R9, so the
flags would be recalculated for every page)
* Fix use of flag in bottom bit of R6; if the flag was set, the
early-exit case for having made all the cacheable pages uncacheable will
never be hit, forcing it to loop through the full page list instead

OS_DynamicArea 21 was treating MaxCamEntry as if it was the exclusive
upper bound, when really it's the inclusive bound. The consequence of
this was that PMPs were unable to explicitly claim the highest-numbered
RAM page in the system.

Version 6.31. Tagged as 'Kernel-6_31'

OS_DynamicArea 27 is the same as OS_DynamicArea 5 ("return free
memory"), except the result is measured in pages instead of bytes,
allowing it to behave sensibly on machines with many gigabytes of RAM.

Similarly, OS_DynamicArea 28 is the same as OS_DynamicArea 7 (internal
DA enumeration call used by TaskManager), except the returned size
values are measured in pages instead of bytes. A flags word has also
been added to allow for more expansion in the future.

Hdr:OSMem now also contains some more definitions which external code
will find useful.

Version 6.29. Tagged as 'Kernel-6_29'

This change adds a new OS_Memory reason code, 23, for reserving memory
without actually assigning it to a dynamic area. Other dynamic areas can
still use the memory, but only the code that reserved it will be allowed
to claim exclusive use over it (i.e. PageFlags_Unavailable).

This is useful for systems such as the PCI heap, where physically
contiguous memory is required, but the memory isn't needed all of the
time. By reserving the pages, it allows other regular DAs to make use of
the memory when the PCI heap is small. But when the PCI heap needs to
grow, it guarantees that (if there's enough free memory in the system)
the previously reserved pages can be allocated to the PCI heap.

Notes:

* Reservations are handled on an honour system; there's no checking that
the program that reserved the memory is the one attempting to map it in.

* For regular NeedsSpecificPages DAs, reserved pages can only be used if
the special "RESV" R0 return value is used.

* For PMP DAs, reserved pages can only be made Unavailable if the entry
in the page block also specifies the Reserved page flag. The actual
state of the Reserved flag can't be modified via PMP DA ops, the flag is
only used to indicate the caller's permission/intent to make the page
Unavailable.

* If a PMP DA tries to make a Reserved page Unavailable without
specifying the Reserved flag, the kernel will try to swap it out for a
replacement page taken from the free pool (preserving the contents and
generating Service_PagesUnsafe / Service_PagesSafe, as if another DA
had claimed the page)

Version 6.28. Tagged as 'Kernel-6_28'

Detail:
This adds a new OS_DynamicArea reason code, 26, for adjusting
AplWorkMaxSize at runtime. This allows compatibility tools such as
Aemulor to adjust the limit without resorting to patching the kernel.
Any adjustment made to the value will affect the upper limit of
application space, and the lower limit of dynamic area placement.
Attempting to adjust beyond the compile-time upper/default limit, or
such that it will interfere with existing dynamic areas / wimpslots,
will result in an error.

Relevant forum thread:
https://www.riscosopen.org/forum/forums/11/topics/14734

Admin:
Tested on BB-xM, desktop active & inactive

Version 6.24. Tagged as 'Kernel-6_24'

To achieve this:
* DecodeL1Entry and DecodeL2Entry return 64-bit physical addresses in
  r0 and r1, with additional return values shuffled up to r2 and r3
* DecodeL1Entry now returns the section size, so callers can distinguish
  section- from supersection-mapped memory
* PhysAddrToPageNo now accepts a 64-bit address (though since the physical
  RAM table is currently still all 32-bit, it will report any top-word-set
  addresses as being not in RAM)

Version 6.22. Tagged as 'Kernel-6_22'

Add a new reason code, OS_Memory 22, equivalent to OS_Memory 14, but
accepting a 64-bit physical address in r1/r2. Current ARM architectures can
only express 40-bit or 32-bit physical addresses in their page tables
(depending on whether they feature the LPAE extension or not) so unlike
OS_Memory 14, OS_Memory 22 can return an error if an invalid physical
address has been supplied. OS_Memory 15 should still be used to release a
temporary mapping, whether you claimed it using OS_Memory 14 or OS_Memory 22.

The logical memory map has had to change to accommodate supersection mapping
of the physical access window, which needs to be 16MB wide and aligned to a
16MB boundary. This results in there being 16MB less logical address space
available for dynamic areas on all platforms (sorry) and there is now a 1MB
hole spare in the system address range (above IO).

The internal function RISCOS_AccessPhysicalAddress has been changed to
accept a 64-bit physical address. This function has been a candidate for
adding to the kernel entry points from the HAL for a long time - enough that
it features in the original HAL documentation - but has not been so added
(at least not yet) so there are no API compatibility issues there.

Requires RiscOS/Sources/Programmer/HdrSrc!2

Detail:
  As the application slot is now a normal dynamic area, there's no need to manipulate the CAM directly. Convert FudgeSomeAppSpace into a OS_ChangeDynamicArea SWI followed by memset().
  ChangeDyn.s: Offset by 32k to account for the -32k that dynamic area -1 has.
  NewReset.s: Delete FudgeSomeAppSpace and replace as above.
Admin:
  Submission from Timothy Baldwin.

Version 6.08. Tagged as 'Kernel-6_08'

Detail:
  s/ChangeDyn - Due to the way that some page flags map to the same bits as (different) DA flags, the Batcall that PMP_PreGrow makes in order to claim the requested page was getting confused and thinking that the special DMA PreGrow handler should be used instead of the DA-specific one (which in this case is a custom one responsible for claiming the right page). Modify PMP_PreGrow so that it only supplies DA flags to the Batcall, and patches in any custom page flags afterwards.
  Also swap magic number for appropriate symbol in PMPGrowHandler.
Admin:
  Tested on BB-xM
  Fixes CAM corruption when a PMP claims a specific page, due to the PMP code and DA code disagreeing about which page should be used


Version 6.00. Tagged as 'Kernel-6_00'

Detail:
  s/ChangeDyn - Set r6 bit 0 if the area is smaller than the cache range threshold, because that's what's checked for at lines 3077 and 3092
Admin:
  Tested on Raspberry Pi


Version 5.76. Tagged as 'Kernel-5_76'

Detail:
  Modern ARMs (ARMv6+) introduce the possibility for the page table walk hardware to make use of the data cache(s) when performing memory accesses. This can significantly reduce the cost of a TLB miss on the system, and since the accesses are cache-coherent with the CPU it allows us to make the page tables cacheable for CPU (program) accesses also, improving the performance of page table manipulation by the OS.
  Even on ARMs where the page table walk can't use the data cache, it's been measured that page table manipulation operations can still benefit from placing the page tables in write-through or bufferable memory.
  So with that in mind, this set of changes updates the OS to allow cacheable/bufferable page tables to be used by the OS + MMU, using a system-appropriate cache policy.
  File changes:
  - hdr/KernelWS - Allocate workspace for storing the page flags that are to be used by the page tables
  - hdr/OSMem - Re-specify CP_CB_AlternativeDCache as having a different behaviour on ARMv6+ (inner write-through, outer write-back)
  - hdr/Options - Add CacheablePageTables option to allow switching back to non-cacheable page tables if necessary. Add SyncPageTables var which will be set {TRUE} if either the OS or the architecture requires a DSB after writing to a faulting page table entry.
  - s/ARM600, s/VMSAv6 - Add new SetTTBR & GetPageFlagsForCacheablePageTables functions. Update VMSAv6 for wider XCBTable (now 2 bytes per element)
  - s/ARMops - Update pre-ARMv7 MMU_Changing ARMops to drain the write buffer on entry if cacheable pagetables are in use (ARMv7+ already has this behaviour due to architectural requirements). For VMSAv6 Normal memory, change the way that the OS encodes the cache policy in the page table entries so that it's more compatible with the encoding used in the TTBR.
  - s/ChangeDyn - Update page table page flag handling to use PageTable_PageFlags. Make use of new PageTableSync macro.
  - s/Exceptions, s/AMBControl/memmap - Make use of new PageTableSync macro.
  - s/HAL - Update MMU initialisation sequence to make use of PageTable_PageFlags + SetTTBR
  - s/Kernel - Add PageTableSync macro, to be used after any write to a faulting page table entry
  - s/MemInfo - Update OS_Memory 0 page flag conversion. Update OS_Memory 24 to use new symbol for page table access permissions.
  - s/MemMap2 - Use PageTableSync. Add routines to enable/disable cacheable pagetables
  - s/NewReset - Enable cacheable pagetables once we're fully clear of the MMU initialision sequence (doing earlier would be trickier due to potential double-mapping)
Admin:
  Tested on pretty much everything currently supported
  Delivers moderate performance benefits to page table ops on old systems (e.g. 10% faster), astronomical benefits on some new systems (up to 8x faster)
  Stats: https://www.riscosopen.org/forum/forums/3/topics/2728?page=2#posts-58015


Version 5.71. Tagged as 'Kernel-5_71'

Detail:
  For a while we've known that the correct way of doing cache maintenance on ARMv6+ (e.g. when converting a page from cacheable to non-cacheable) is as follows:
  1. Write new page table entry
  2. Flush old entry from TLB
  3. Clean cache + drain write buffer
  The MMU_Changing ARMops (e.g. MMU_ChangingEntry) implement the last two items, but in the wrong order. This has caused the operations to fall out of favour and cease to be used, even in pre-ARMv6 code paths where the effects of improper cache/TLB management perhaps weren't as readily visible.
  This change re-specifies the relevant ARMops so that they perform their sub-operations in the correct order to make them useful on modern ARMs, updates the implementations, and updates the kernel to make use of the ops whereever relevant.
  File changes:
  - Docs/HAL/ARMop_API - Re-specify all the MMU_Changing ARMops to state that they are for use just after a page table entry has been changed (as opposed to before - e.g. 5.00 kernel behaviour). Re-specify the cacheable ones to state that the TLB invalidatation comes first.
  - s/ARM600, s/ChangeDyn, s/HAL, s/MemInfo, s/VMSAv6, s/AMBControl/memmap - Replace MMU_ChangingUncached + Cache_CleanInvalidate pairs with equivalent MMU_Changing op
  - s/ARMops - Update ARMop implementations to do everything in the correct order
  - s/MemMap2 - Update ARMop usage, and get rid of some lingering sledgehammer logic from ShuffleDoublyMappedRegionForGrow
Admin:
  Tested on pretty much everything currently supported


Version 5.70. Tagged as 'Kernel-5_70'

Detail:
  The kernel has always allowed software to create cacheable doubly-mapped DAs, despite the fact that the VIVT caches used on ARMv5 and below would have no way of keeping both of the mappings coherent
  This change places restrictions the following restrictions on doubly-mapped areas, to ensure that cache settings which can't be supported by the cache architecture of the CPU can't be selected:
  * On ARMv6 and below, cacheable doubly-mapped areas aren't supported.
    * Although ARMv6 has VIPT data caches, it's also subject to page colouring constraints which would require us to force the DA size to be a multiple of 16k. So for now keep things simple and disallow cacheable doubly-mapped areas on ARMv6.
  * On ARMv7 and above, cacheable doubly-mapped areas are allowed, but only if they are marked non-executable
    * The blocker to allowing executable cacheable doubly-mapped areas are the VIPT instruction caches; OS_SynchroniseCodeAreas (or callers of it) would need to know that a doubly-mapped area is in use so that they can flush both mappings from the I-cache. Although some chips do have PIPT instruction caches, again it isn't really worth supporting executable cacheable doubly-mapped areas at the moment.
  These changes also allow us to get rid of the expensive 'sledgehammer' logic when dealing with doubly-mapped areas
  File changes:
  - s/ARM600, s/VMSAv6 - Remove the sledgehammer logic, only perform cache/TLB maintenance for the required areas
  - s/ChangeDyn - Implement the required checks
  - s/MemMap2 - Move some cache maintenance logic into RemoveCacheabilityR0ByMinusR2, which previously would have had to be performed by the caller due to the sledgehammer paranoia
Admin:
  Cacheable doubly-mapped DAs tested on iMx6 (tried making screen memory write-through cacheable; decent performance gain seen)
  Note OS_Memory 0 "make temporarily uncacheable" doesn't work on doubly-mapped areas, so cacheable doubly-mapped areas are not yet safe for general DMA


Version 5.69. Tagged as 'Kernel-5_69'

Detail:
  s/MemMap2 - New file containing assorted low-level memory mapping routines taken from s/ChangeDyn. N.B. There's no special significance to this being named "MemMap2", it's just a name that stuck due to some earlier (abandoned) changes which added a file named "MemMap".
  s/ChangeDyn - Remove the routines/chunks of code that were moved to s/MemMap2. Also some duplicate code removal (Regular DA grow code and DoTheGrowNotSpecified are now rely on the new DoTheGrowCommon routine for doing the actual grow)
  s/GetAll - GET s/MemMap2 at an appropriate time
Admin:
  Tested on pretty much everything currently supported


Version 5.67. Tagged as 'Kernel-5_67'

Detail:
  With this set of changes, each AMB node is now the owner of a fake DANode which is linked to a PMP.
  From a user's perspective the behaviour of AMBControl is the same as before, but rewriting it to use PMPs internally offers the following (potential) benefits:
  * Reduction in the amount of code which messes with the CAM & page tables, simplifying future work/maintenance. Some of the AMB ops (grow, shrink) now just call through to OS_ChangeDynamicArea. However all of the old AMB routines were well-optimised, so to avoid a big performance hit for common operations not all of them have been removed (e.g. mapslot / mapsome). Maybe one day these optimal routines will be made available for use by regular PMP DAs.
  * Removal of the slow Service_MemoryMoved / Service_PagesSafe handlers that had to do page list fixup after the core kernel had reclaimed/moved pages. Since everything is a PMP, the kernel will now deal with this on behalf of AMB.
  * Removal of a couple of other slow code paths (e.g. Do_AMB_MakeUnsparse calls from OS_ChangeDynamicArea)
  * Potential for more flexible mapping of application space in future, e.g. sparse allocation of memory to the wimp slot
  * Simpler transition to an ASID-based task swapping scheme on ARMv6+?
  Other changes of note:
  * AMB_LazyMapIn switch has been fixed up to work correctly (i.e. turning it off now disables lazy task swapping and all associated code instead of producing a build error)
  * The DANode for the current app should be accessed via the GetAppSpaceDANode macro. This will either return the current AMB DANode, or AppSpaceDANode (if e.g. pre-Wimp). However be aware that AppSpaceDANode retains the legacy behaviour of having a base + size relative to &0, while the AMB DANodes (identifiable via the PMP flag) are sane and have their base + size relative to &8000.
  * Mostly-useless DebugAborts switch removed
  * AMBPhysBin (page number -> phys addr lookup table) removed. Didn't seem to give any tangible performance benefit, and was imposing hidden restrictions on memory usage (all phys RAM fragments in PhysRamTable must be multiple of 512k). And if it really was a good optimisation, surely it should have been applied to all areas of the kernel, not just AMB!
  Other potential future improvements:
  * Turn the fake DANodes into real dynamic areas, reducing the amount of special code needed in some places, but allow the DAs to be hidden from OS_DynamicArea 3 so that apps/users won't get too confused
  * Add a generic abort trapping system to PMPs/DAs (lazy task swapping abort handler is still a special case)
  File changes:
  - s/ARM600, s/VMSAv6, s/ExtraSWIs - Remove DebugAborts
  - s/ArthurSWIs - Remove AMB service call handler dispatch
  - s/ChangeDyn - AMB_LazyMapIn switch fixes. Add alternate internal entry points for some PMP ops to allow the DANode to be specified (used by AMB)
  - s/Exceptions - Remove DebugAborts, AMB_LazyMapIn switch fixes
  - s/Kernel - Define GetAppSpaceDANode macro, AMB_LazyMapIn switch fix
  - s/MemInfo - AMB_LazyMapIn switch fixes
  - s/AMBControl/AMB - Update GETs
  - s/AMBControl/Memory - Remove block size quantisation, AMB_BlockResize (page list blocks are now allocated by PMP code)
  - s/AMBControl/Options - Remove PhysBin definitions, AMBMIRegWords (moved to Workspace file), AMB_LimpidFreePool switch. Add AMB_Debug switch.
  - s/AMBControl/Workspace - Update AMBNode to contain an embedded DANode. Move AMBMIRegWords here from Options file.
  - s/AMBControl/allocate - Fake DA node initialisation
  - s/AMBControl/deallocate - Add debug output
  - s/AMBControl/growp, growshrink, mapslot, mapsome, shrinkp - Rewrite to use PMP ops where possible, add debug output
  - s/AMBControl/main - Remove PhysBin initialisation. Update the enumerate/mjs_info call.
  - s/AMBControl/memmap - Low-level memory mapping routines updated or rewritten as appropriate.
  - s/AMBControl/readinfo - Update to cope with DANode
  - s/AMBControl/service - Remove old service call handlers
  - s/AMBControl/handler - DA handler for responding to PMP calls from OS_ChangeDynamicArea; just calls through to growpages/shrinkpages as appropriate.
Admin:
  Tested on pretty much everything currently supported


Version 5.66. Tagged as 'Kernel-5_66'

Detail:
  s/ChangeDyn - A routine that was missed during the upgrade from 8 byte CAM entries to 16 byte CAM entries, DoTheGrowPageUnavailable was using still using the old CAM entry size, potentially corrupting the CAM whenever it was called (i.e. if a DA grow requested a page that had already been claimed for exclusive use by someone else)
Admin:
  Tested on BB-xM


Version 5.60. Tagged as 'Kernel-5_60'

Detail:
  s/ChangeDyn - Fix register corruption in PMP_LogOp when mapping a page into a location that already contains a page. Fix excessive TLB flush in AreaShrink.
  s/ARM600, s/VMSAv6 - Add asserts to GetTempUncache to detect invalid register combinations
Admin:
  Tested on BB-xM


Version 5.59. Tagged as 'Kernel-5_59'

Detail:
  s/ChangeDyn - When OS_DynamicArea 23 returned an error, R2 wasn't being set to zero correctly, incorrectly suggesting that a change had been made. And when a non-error resize of zero was being performed, registers were being pulled twice, resulting in a stack imbalance and crash.
Admin:
  Tested on BB-xM


Version 5.58. Tagged as 'Kernel-5_58'

Detail:
  s/ChangeDyn - Since the introduction of the 16 byte CAM entry format, OS_FindMemMapEntries has contained a bug where requesting the details for an address which does not have an L2PT page allocated for it (e.g. a location in ROM) would result in a misaligned CAM entry pointer being generated, resulting in either a crash or incorrect data being returned
Admin:
  Tested on Raspberry Pi 2
  Fixes issue reported on forums:
  https://www.riscosopen.org/forum/forums/4/topics/6393


Version 5.57. Tagged as 'Kernel-5_57'

Detail:
  This set of changes:
  * Refactors page table entry encoding/decoding so that it's (mostly) performed via functions in the MMU files (s.ARM600, s.VMSAv6) rather than on an ad-hoc basis as was the case previously
  * Page table entry encoding/decoding performed during ROM init is also handled via the MMU functions, which resolves some cases where the wrong cache policy was in use on ARMv6+
  * Adds basic support for shareable pages - on non-uniprocessor systems all pages will be marked as shareable (however, we are currently lacking ARMops which broadcast cache maintenance operations to other cores, so safe sharing of cacheable regions isn't possible yet)
  * Adds support for the VMSA XN flag and the "privileged ROM" access permission. These are exposed via RISC OS access privileges 4 and above, taking advantage of the fact that 4 bits have always been reserved for AP values but only 4 values were defined
  * Adds OS_Memory 17 and 18 to convert RWX-style access flags to and from RISC OS access privelege numbers; this allows us to make arbitrary changes to the mappings of AP values 4+ between different OS/hardware versions, and allows software to more easily cope with cases where the most precise AP isn't available (e.g. no XN on <=ARMv5)
  * Extends OS_Memory 24 (CheckMemoryAccess) to return executability information
  * Adds exported OSMem header containing definitions for OS_Memory and OS_DynamicArea
  File changes:
  - Makefile - export C and assembler versions of hdr/OSMem
  - Resources/UK/Messages - Add more text for OS_Memory errors
  - hdr/KernelWS - Correct comment regarding DCacheCleanAddress. Allocate workspace for MMU_PPLTrans and MMU_PPLAccess.
  - hdr/OSMem - New file containing exported OS_Memory and OS_DynamicArea constants, and public page flags
  - hdr/Options - Reduce scope of ARM6support to only cover builds which require ARMv3 support
  - s/AMBControl/Workspace - Clarify AMBNode_PPL usage
  - s/AMBControl/growp, mapslot, mapsome, memmap - Use AreaFlags_ instead of AP_
  - s/AMBControl/main, memmap - Use GetPTE instead of generating page table entry manually
  - s/ARM600 - Remove old coments relating to lack of stack. Update BangCam to use GetPTE. Update PPL tables, removing PPLTransL1 (L1 entries are now derived from L2 table on demand) and adding a separate table for ARM6. Implement the ARM600 versions of the Get*PTE ('get page table entry') and Decode*Entry functions
  - s/ARMops - Add Init_PCBTrans function to allow relevant MMU_PPLTrans/MMU_PCBTrans pointers to be set up during the pre-MMU stage of ROM init. Update ARM_Analyse to set up the pointers that are used post MMU init.
  - s/ChangeDyn - Move a bunch of flags to hdr/OSMem. Rename the AP_ dynamic area flags to AreaFlags_ to avoid name clashes and confusion with the page table AP_ values exported by Hdr:MEMM.ARM600/Hdr:MEMM.VMSAv6. Also generate the relevant flags for OS_Memory 24 so that it can refer to the fixed areas by their name instead of hardcoding the permissions.
  - s/GetAll - GET Hdr:OSMem
  - s/HAL - Change initial page table setup to use DA/page flags and GetPTE instead of building page table entries manually. Simplify AllocateL2PT by removing the requirement for the user to supply the access perimssions that will be used for the area; instead for ARM6 we just assume that cacheable memory is the norm and set L1_U for any L1 entry we create here.
  - s/Kernel - Add GetPTE macro (for easier integration of Get*PTE functions) and GenPPLAccess macro (for easy generation of OS_Memory 24 flags)
  - s/MemInfo - Fixup OS_Memory 0 to not fail on seeing non-executable pages. Implement OS_Memory 17 & 18. Tidy up some error generation. Make OS_Memory 13 use GetPTE. Extend OS_Memory 24 to return (non-) executability information, to use the named CMA_ constants generated by s/ChangeDyn, and to use the Decode*Entry functions when it's necessary to decode page table entries.
  - s/NewReset - Use AreaFlags_ instead of AP_
  - s/VMSAv6 - Remove old comments relating to lack of stack. Update BangCam to use GetPTE. Update PPL tables, removing PPLTransL1 (L1 entries are now derived from L2 table on demand) and adding a separate table for shareable pages. Implement the VMSAv6 versions of the Get*PTE and Decode*Entry functions.
Admin:
  Tested on Raspberry Pi 1, Raspberry Pi 3, Iyonix, RPCEmu (ARM6 & ARM7), comparing before and after CAM and page table dumps to check for any unexpected differences


Version 5.55. Tagged as 'Kernel-5_55'

Detail:
  This change gets rid of the following switches from the source (picking appropriate code paths for a 32bit HAL build):
  * FixCallBacks
  * UseProcessTransfer
  * CanLiveOnROMCard
  * BleedinDaveBell
  * NewStyleEcfs
  * DoVdu23_0_12
  * LCDPowerCtrl
  * HostVdu
  * Print
  * EmulatorSupport
  * TubeInfo
  * AddTubeBashers
  * TubeChar, TubeString, TubeDumpNoStack, TubeNewlNoStack macros
  * FIQDebug
  * VCOstartfix
  * AssemblingArthur (n.b. still defined for safety with anything in Hdr: which uses it, but not used explicitly by the kernel)
  * MouseBufferFix
  * LCDInvert
  * LCDSupport
  * DoInitialiseMode
  * Interruptible32bitModes
  * MouseBufferManager
  * StrongARM (new CacheCleanerHack and InterruptDelay switches added to hdr/Options to cover some functionality that StrongARM previously covered)
  * SAcleanflushbroken
  * StrongARM_POST
  * IrqsInClaimRelease
  * CheckProtectionLink
  * GSWorkspaceInKernelBuffers
  * EarlierReentrancyInDAShrink
  * LongCommandLines
  * ECC
  * NoSPSRcorruption
  * RMTidyDoesNowt
  * RogerEXEY
  * StorkPowerSave
  * DebugForcedReset
  * AssembleKEYV
  * AssemblePointerV
  * ProcessorVectors
  * Keyboard_Type
  Assorted old files have also been deleted.
Admin:
  Identical binary to previous revision for IOMD & Raspberry Pi builds


Version 5.51. Tagged as 'Kernel-5_51'

Detail:
  This change gets rid of the following switches from the source (picking appropriate code paths for a 32bit HAL build):
  * HAL
  * HAL26
  * HAL32
  * No26bitCode
  * No32bitCode
  * IncludeTestSrc
  * FixR9CorruptionInExtensionSWI
  Various old files have also been removed (POST code, Arc/STB keyboard drivers, etc.)
Admin:
  Identical binary to previous revision for IOMD & Raspberry Pi builds


Version 5.49. Tagged as 'Kernel-5_49'

Detail:
  s/ChangeDyn - When DynArea_PMP_PhysOp generates an error during the initial page list scan, make sure r12 is initialised to the (new) PMP size, as expected by PMPMemoryMoved.
  s/AMBControl/allocate, s/AMBControl/growshrink - Document some extra exit conditions for the AMB allocate & grow/shrink routines
Admin:
  Tested on BB-xM
  Fixes RAM disc PMP becoming corrupt when attempting to grow it (e.g. via *ChangeDynamicArea) by an amount larger than the amount of free memory in the system


Version 5.35, 4.79.2.324. Tagged as 'Kernel-5_35-4_79_2_324'

Detail:
  s/MemInfo - Wrap OS_Memory 0 in some code which will temporarily claim the FIQ vector when making pages temporarily uncacheable, to avoid any issues caused by modern ARMs ignoring unexpected cache hits
  s/VMSAv6 - Claim FIQs when OS_MMUControl is asked to make a change to the SCTLR, to avoid similar issues on modern ARMs. Also make the stack temporarily uncacheable before disabling the cache, so that we don't run into any problems using the stack inbetween disabling the cache and completing the clean+invalidate.
Admin:
  Tested on Pi 2B, 3B
  *Cache off now works reliably on Pi 2B, although there is sometimes a pause of a few seconds while things sort themselves out (USB?)
  *Cache off "works" on Pi 3B but everything will fall over soon afterwards due to the Cortex-A53 not supporting LDREX/STREX to non-cacheable pages (or when the page is effectively non-cacheable, i.e. cacheable page with cache disabled)


Version 5.35, 4.79.2.311. Tagged as 'Kernel-5_35-4_79_2_311'

Detail:
  This set of changes tackles two main issues:
  * Before mapping out a cacheable page or making it uncacheable, the OS performs a cache clean+invalidate op. However this leaves a small window where data may be fetched back into the cache, either accidentally (dodgy interrupt handler) or via agressive prefetch (as allowed for by the architecture). This rogue data can then result in coherency issues once the pages are mapped out or made uncacheable a short time later.
    The fix for this is to make the page uncacheable before performing the cache maintenance (although this isn't ideal, as prior to ARMv7 it's implementation defined whether address-based cache maintenance ops affect uncacheable pages or not - and on ARM11 it seems that they don't, so for that CPU we currently force a full cache clean instead)
  * Modern ARMs generally ignore unexpected cache hits, so there's an interrupt hole in the current OS_Memory 0 "make temporarily uncacheable" implementation where the cache is being flushed after the page has been made uncacheable (consider the case of a page that's being used by an interrupt handler, but the page is being made uncacheable so it can also be used by DMA). As well as affecting ARMv7+ devices this was found to affect XScale (and ARM11, although untested for this issue, would have presumably suffered from the "can't clean uncacheable pages" limitation)
    The fix for this is to disable IRQs around the uncache sequence - however FIQs are currently not being dealt with, so there's still a potential issue there.
  File changes:
  - Docs/HAL/ARMop_API, hdr/KernelWS, hdr/OSMisc - Add new Cache_CleanInvalidateRange ARMop
  - s/ARM600, s/VMSAv6 - BangCam updated to make the page uncacheable prior to flushing the cache. Add GetTempUncache macro to help with calculating the page flags required for making pages uncacheable. Fix abort in OS_MMUControl on Raspberry Pi - MCR-based ISB was resetting ZeroPage pointer to 0
  - s/ARMops - Cache_CleanInvalidateRange implementations. PL310 MMU_ChangingEntry/MMU_ChangingEntries refactored to rely on Cache_CleanInvalidateRange_PL310, which should be a more optimal implementation of the cache cleaning code that was previously in MMU_ChangingEntry_PL310.
  - s/ChangeDyn - Rename FastCDA_UpFront to FastCDA_Bulk, since the cache maintenance is no longer performed upfront. CheckCacheabilityR0ByMinusR2 now becomes RemoveCacheabilityR0ByMinusR2. PMP LogOp implementation refactored quite a bit to perform cache/TLB maintenance after making page table changes instead of before. One flaw with this new implementation is that mapping out large areas of cacheable pages will result in multiple full cache cleans while the old implementation would have (generally) only performed one - a two-pass approach over the page list would be needed to solve this.
  - s/GetAll - Change file ordering so GetTempUncache macro is available earlier
  - s/HAL - ROM decompression changed to do full MMU_Changing instead of MMU_ChangingEntries, to make sure earlier cached data is truly gone from the cache. ClearPhysRAM changed to make page uncacheable before flushing cache.
  - s/MemInfo - OS_Memory 0 interrupt hole fix
  - s/AMBControl/memmap - AMB_movepagesout_L2PT now split into cacheable+non-cacheable variants. Sparse map out operation now does two passes through the page list so that they can all be made uncacheable prior to the cache flush + map out.
Admin:
  Tested on StrongARM, XScale, ARM11, Cortex-A7, Cortex-A9, Cortex-A15, Cortex-A53
  Appears to fix the major issues plaguing SATA on IGEPv5


Version 5.35, 4.79.2.306. Tagged as 'Kernel-5_35-4_79_2_306'

Detail:
  s/ChangeDyn - Fix a couple of places where registers were being clobbered, preventing application space & shrinkable DA shrinking logic from being invoked correctly when performing a PMP PhysOp call
Admin:
  Tested on Raspberry Pi


Version 5.35, 4.79.2.293. Tagged as 'Kernel-5_35-4_79_2_293'

Detail:
  s/ChangeDyn - A few fixes to make behaviour be a closer match for the pre-PMP code, and a bit of tidying to get rid of redundant code paths:
  - Remove shrinkable DA checks from AreaShrink - the source of the op is never the free pool, so TryToShrinkShrinkables wouldn't have done anything anyway
  - Fix ShrinkFreePoolToAppSpace to behave more like old OS_ChangeDynamicArea when it was asked to shrink the free pool - allow partial moves (if move amount too large to fit in app space), shrink shrinkables if free pool is unable to satisfy request, and call CheckAppSpace to make sure app space is OK with being changed
  - Remove redundant logic from AreaGrow for clamping grow size to free pool max size (if dest was free pool - dest will never be free pool with current implementation). "Dest is apl space, moving reduced amount" comment was also inaccurate.
  - Fix AreaGrow logic for taking memory from application space to only do so if the dest isn't application space (I can't see anything in the old implementation to protect against this - but, then again, the old implementation didn't seem to fully deal with grows of application space properly anyway, e.g. MemLimit would be updated on a free pool shrink, but not on an app space grow)
  - Add extra sanity check to AreaGrow after taking memory from application space
Admin:
  Tested on iMx6
  Fixes issue with application space having little or no memory if not booting to desktop (due to free pool shrink performed by kernel failing due to shrink amount being larger than app space max size)


Version 5.35, 4.79.2.291. Tagged as 'Kernel-5_35-4_79_2_291'

Detail:
  s/ChangeDyn - Fix OS_DynamicArea 20 to work properly with sparse & PMP DAs. It now checks against the max extent of the area rather than the current size; this matches the logic used for checking fixed system workspace areas. The call only determines the ownership of a logical address, and it's considered the caller's responsibility to check if there's actually a page at the given address.
  s/ChangeDyn - Revise OS_DynamicArea 25 to remove the redundant 'PMP page flags' entry, and to allow pages to be looked up by either PMP page index, phys page number, or DA page index
  s/ChangeDyn - Tidy up InitDynamicAreas by adding the NextFreePage routine to help determine the next page to be added to the free pool.
  s/AMBControl/Workspace, s/AMBControl/main, s/AMBControl/memmap - Fix lazy mapping in of pages to use the correct L2PT flags for the default CB cache policy
  s/AMBControl/allocate - Get rid of magic constant when extracting page flags from DA flags, and make note of the fact that assorted bits of code ignore the flags
  s/AMBControl/growp, s/AMBControl/shrinkp - Reverse the page order when growing/shrinking areas, to match OS_ChangeDynamicArea. This helps both DAs and application space to have pages allocated to them in contiguous physical order - which in turn helps produce shorter, more optimal scatter lists for DMA
Admin:
  Tested on Pandaboard


Version 5.35, 4.79.2.287. Tagged as 'Kernel-5_35-4_79_2_287'