GitLab

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'

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

This is facilitated by two extended calls. From the HAL:
* RISCOS_MapInIO64 allows the physical address to be specified as 64-bit

From the OS:
* OS_Memory 21 acts like OS_Memory 13, but takes a 64-bit physical address

There is no need to extend RISCOS_LogToPhys, instead we change its return
type to uint64_t. Any existing HALs will only read the a1 register, thereby
narrowing the result to 32 bits, which is fine because all existing HALs
only expected a 32-bit physical address space anyway.

Internally, RISCOS_MapInIO has been rewritten to detect and use supersections
for IO regions that end above 4GB. Areas that straddle the 4GB boundary should
also work, although if you then search for a sub-area that doesn't, it won't
find a match and will instead map it in again using vanilla sections - this is
enough of an edge case that I don't think we need to worry about it too much.

The rewrite also conveniently fixes a bug in the old code: if the area being
mapped in went all the way up to physical address 0xFFFFFFFF (inclusive) then
only the first megabyte of the area was actually mapped in due to a loop
termination issue.

Requires RiscOS/Sources/Programmer/HdrSrc!2

Detail:
  s/MemInfo - The wrapper around OS_Memory 0 introduced in Kernel-5_35-4_79_2_311 was preserving the wrong PSR field on exit, causing any error generated by the core code to be lost.
Admin:
  Tested on Iyonix
  Fixes *screensave saving mostly white pixels (address translation for "external" VRAM should have failed and caused ADFS to fall back to a bounce buffer)
  Is also likely to be the cause of https://www.riscosopen.org/forum/forums/5/topics/11713 (address translation should have failed for soft ROM)


Version 6.10. Tagged as 'Kernel-6_10'

Detail:
  s/MemInfo, hdr/KernelWS - Rather than peeking L2PT to determine if the compatibility page is enabled, use a workspace var to track its state. This ensures we won't get confused if other software decides to map something of its own to &0.
  s/NewReset - Ensure the CompatibilityPageEnabled flag is initialised correctly
Admin:
  Tested in Iyonix ROM softload


Version 5.90. Tagged as 'Kernel-5_90'

Detail:
  When HiProcVecs is enabled, there will now be a read-only page located at &0 in order to ease compatibility with buggy software which reads from null pointers
  Although most of the page is zero-filled, the start of the page contains a few words which are invalid pointers, discouraging dereferencing them, and a warning message if the memory is interpreted as a string.
  On ARMv6+ the page is also made non-executable, to deal with branch-through-zero type situations
  OS_Memory 20 has been introduced as a way of determining whether the compatibility page is present, and also to enable/disable it
  File changes:
  - hdr/Options - Add CompatibilityPage option
  - hdr/OSMem - Declare OS_Memory reason code 20
  - hdr/KernelWS - When CompatibilityPage is enabled, make sure nothing else is located at &0
  - s/NewReset - Enable compatibility page just before Service_PostInit (try and keep zero-tolerance policy for null pointer dereferencing during ROM init)
  - s/MemInfo - OS_Memory 20 implementation. Add knowledge of the compatibility page to OS_Memory 16 and 24.
Admin:
  Tested on BB-xM


Version 5.87. Tagged as 'Kernel-5_87'

Add OS_Memory 19, which is intended to replace the OS_Memory 0 "make uncacheable" feature, when used for DMA

Detail:
  Making pages uncacheable to allow them to be used with DMA can be troublesome for a number of reasons:
  * Many processors ignore cache hits for non-cacheable pages, so to avoid breaking any IRQ handlers the page table manipulation + cache maintenance must be performed with IRQs disabled, impacting the IRQ latency of the system
  * Some processors don't support LDREX/STREX to non-cacheable pages
  * In SMP setups it may be necessary to temporarily park the other cores somewhere safe, or perform some other explicit synchronisation to make sure they all have consistent views of the cache/TLB
  The above issues are most likely to cause problems when the page is shared by multiple programs; a DMA operation which targets one part of a page could impact the programs which are using the other parts.
  To combat these problems, OS_Memory 19 is being introduced, which allows DMA cache coherency/address translation to be performed without altering the attributes of the pages.
  Files changed:
  - hdr/OSMem - Add definitions for OS_Memory 19
  - s/MemInfo - Add OS_Memory 19 implementation
Admin:
  Tested on Raspberry Pi 3, iMx6


Version 5.86, 4.129.2.3. Tagged as 'Kernel-5_86-4_129_2_3'

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:
  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:
  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):
  * 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'

Add new OS_PlatformFeatures reason code for reading CPU features (inspired by ARMv6+ CPUID scheme). Add OS_ReadSysInfo 8 flags for indicating the alignment mode the ROM was built with. Fix long-standing bug with OS_PlatformFeatures when an unknown reason code is used.

Detail:
  s/CPUFeatures, hdr/OSMisc, hdr/KernelWS - Code and definitions for reading CPU features and reporting them via OS_PlatformFeatures 34. All the instruction set features which are exposed by the CPUID scheme and which are relevant to RISC OS are exposed, along with a few extra flags which we derive ourselves (e.g. things relating to < ARMv4, and some register usage restrictions in instructions). s/CPUFeatures is designed to be easily copyable into a future version of CallASWI without requiring any changes.
  s/ARMops - Read and cache CPU features during ARMop initialisation
  s/GetAll - GET new file
  s/Kernel - Hook up the CPU features code to OS_PlatformFeatures. Fix a long standing stack imbalance bug (fixed in RISC OS 3.8, but never merged back to our main branch) which meant that calling OS_PlatformFeatures with an invalid reason code would raise an error, even if it was the X form of the SWI that was called. Similar fix also applied to the unused service call code, along with a fix for the user's R1-R9 being corrupt (shuffled up one place) should an error have been generated.
  s/MemInfo - Extra LTORG needed to keep things happy
  s/Middle - Extend OS_ReadSysInfo 8 to include flags for indicating what memory alignment mode (if any) the OS relies upon. Together with OS_PlatformFeatures 34 this could e.g. be used by !CPUSetup to determine which options should be offered to the user.
Admin:
  Tested on Raspberry Pi 1, 2, 3


Version 5.35, 4.79.2.319. Tagged as 'Kernel-5_35-4_79_2_319'

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:
  s/MemInfo - To avoid cache coherency issues when the current SVC stack page is being made uncacheable, shift SP somewhere else by temporarily dropping into IRQ mode
  s/ARMops - Change default VMSAv6 cache policy to writeback, write allocate. Unlike other CPUs we've supported so far, Cortex-A53 suffers very badly from writes to read-allocate pages, with performance being roughly equivalent to writes to non-cacheable memory. Using a write (+read) allocate policy seems to be needed to get the expected performance, and may help boost other CPUs too.
Admin:
  Tested on IGEPv5, Pi 3


Version 5.35, 4.79.2.307. Tagged as 'Kernel-5_35-4_79_2_307'

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/MemInfo - Remove OS_Memory 10 (free pool locking). Locking the free pool has never been a very nice thing to do, so now that there's no logical mapping of the free pool it seems like it's a good time to outlaw the behaviour altogether.
  s/ChangeDyn - No free pool locking means one less thing to check when claiming the OS_ChangeDynamicArea mutex.
  hdr/KernelWS - VRAMRescue_control workspace variable is no longer needed
Admin:
  Tested on Pandaboard


Version 5.35, 4.79.2.285. Tagged as 'Kernel-5_35-4_79_2_285'

Detail:
  This set of changes adds support for "physical memory pools" (aka PMPs), a new type of dynamic area which allow physical pages to be claimed/allocated without mapping them in to the logical address space. PMPs have full control over which physical pages they use (similar to DAs which request specific physical pages), and also have full control over the logical mapping of their pages (which pages go where, and per-page access/cacheability control).
  Currently the OS makes use of two PMPs: one for the free pool (which now has a logical size of zero - freeing up gigabytes of logical space), and one for the RAM disc (logical size of 1MB, allowing for a physical size limited only by the amount of free memory)
  Implementing these changes has required a number of other changes to be made:
  * The CAM has been expanded from 8 bytes per entry to 16 bytes per entry, in order to allow each RAM page to store information about its PMP association
  * The system heap has been expanded to 32MB in size (from just under 4MB), in order to allow it to be used to store PMP page lists (1 word needed per page, but PMP pages may not always have physical pages assigned to them - so to allow multiple large PMPs to exist we need more than just 1 word per RAM page)
  * The &FA000000-&FBFFFFFF area of fixed kernel workspace has been shuffled around to accomodate the larger CAM, and the system heap is now located just above the RMA.
  * SoftResets code stripped out (unlikely we'll ever want to fix and re-enable it)
  * A couple of FastCDA options are now permanently on
  * Internal page flags shuffled around a bit. PageFlags_Unavailable now publicly exposed so that PMP clients can lock/unlock pages at will.
  * When OS_ChangeDynamicArea is asked to grow or shrink the free pool, it now implicitly converts it into a shrink or grow of application space (which is what would happen anyway). This simplifies the implementation; during a grow, pages (or replacement pages) are always sourced from the free pool, and during a shrink pages are always sent to the free pool.
  File changes:
  - hdr/KernelWS - Extend DANode structure. Describe CAM format. Adjust kernel workspace.
  - hdr/OSRSI6, s/Middle - Add new item to expose the CAM format
  - hdr/Options - Remove SoftResets switch. Add some PMP switches.
  - s/ARM600, s/VMSAv6 - Updated for new CAM format. Note that although the CAM stores PMP information, BangCamUpdate currently doesn't deal with updating that data - it's the caller's responsibility to do so where appropriate.
  - s/ChangeDyn - Lots of changes to implement PMP support, and to cope with the new CAM format.
  - s/HAL - Updated to cope with new CAM format, and lack of logical mapping of free pool.
  - s/MemInfo - Updated to cope with new CAM format. OS_Memory 0 updated to cope with converting PPN to PA for pages which are mapped out. OS_Memory 24 updated to decode the access permissions on a per-page basis for PMPs, and fixed its HWM usage for sparse DAs.
  - s/NewReset - Soft reset code and unused AddCamEntries function removed. Updated to cope with new CAM format, PMP free pool, PMP RAMFS
  - s/AMBControl/allocate - Update comment (RMA hasn't been used for AMBControl nodes for a long time)
  - s/AMBControl/growp, s/AMBControl/memmap, s/AMBControl/shrinkp - Update for new CAM format + PMP free pool
  - s/vdu/vdudriver - Strip out soft reset code.
Admin:
  Tested on Pandaboard
  This is just a first iteration of the PMP feature, with any luck future changes will improve functionality. This means APIs are subject to change as well.


Version 5.35, 4.79.2.284. Tagged as 'Kernel-5_35-4_79_2_284'

Improve support for VMSAv6 cache policies & memory types. Expose raw ARMops via OS_MMUControl & cache information via OS_PlatformFeatures.

Detail:
  Docs/HAL/ARMop_API - Document two new ARMops: Cache_Examine and IMB_List
  hdr/KernelWS - Shuffle workspace round a bit to allow space for the two new ARMops. IOSystemType now deleted (has been deprecated and fixed at 0 for some time)
  s/ARM600 - Cosmetic changes to BangCam to make it clearer what's going on. Add OS_MMUControl 2 (get ARMop) implementation.
  s/ARMops - Switch out different ARMop implementations and XCB tables depending on MMU model - helps reduce assembler warnings and make it clearer what code paths are and aren't possible. Add implementations of the two new ARMops. Simplify ARM_Analyse_Fancy by removing some tests which we know will have certain results. Use CCSIDR constants in ARMv7 ARMops instead of magic numbers. Update XCB table comments, and add a new table for VMSAv6
  s/ChangeDyn - Define constant for the new NCB 'idempotent' cache policy (VMSAv6 normal, non-cacheable memory)
  s/HAL - Use CCSIDR constants instead of magic numbers. Extend RISCOS_MapInIO to allow the TEX bits to be specified.
  s/Kernel - OS_PlatformFeatures 33 (read cache information) implementation (actually, just calls through to an ARMop)
  s/MemInfo - Modify VMSAv6 OS_Memory 0 cache/uncache implementation to use the XCB table instead of modifying L2_C directly. This allows the cacheability to be changed without affecting the memory type - important for e.g. unaligned accesses to work correctly. Implement cache policy support for OS_Memory 13.
  s/Middle - Remove IOSystemType from OS_ReadSysInfo 6.
  s/VMSAv6 - Make sure BangCam uses the XCB table for working out the attributes of temp-uncacheable pages instead of manipulating L2_C directly. Add OS_MMUControl 2 implementation.
  s/AMBControl/memmap - Update VMSAv6 page table pokeing to use XCB table
  s/PMF/osinit - Remove IOSystemType reference, and switch out some pre-HAL code that was trying to use IOSystemType.
Admin:
  Tested on Iyonix, ARM11, Cortex-A7, -A8, -A9, -A15
  Note that contrary to the comments in the source the default NCB policy currently maps to VMSAv6 Device memory type (as per previous kernel versions). This is just a temporary measure, and it will be switched over to Normal, non-cacheable once appropriate memory barriers have been added to the affected IO code.


Version 5.35, 4.79.2.273. Tagged as 'Kernel-5_35-4_79_2_273'

Expose more areas via OS_ReadSysInfo 6 & OS_Memory 16. Expose processor vectors base + size via OS_PlatformFeatures.

Detail:
  hdr/KernelWS - Define processor vectors address. Currently same as ZeroPage, but in the future will differ for some machines.
  hdr/OSRSI6, s/Middle - Expose VecPtrTab & NVECTORS via OS_ReadSysInfo items 85 & 86
  s/Kernel - Add OS_PlatformFeatures 32, for returning the base + size of the processor vectors
  s/MemInfo - Add areas 12 thru 15 to OS_Memory 16, for reporting ZeroPage, ProcVecs, DebuggerSpace and ScratchSpace. The task manager can now use these for calculating memory usage instead of assuming 32K workspace from &0-&8000.
Admin:
  Tested on Raspberry Pi


Version 5.35, 4.79.2.271. Tagged as 'Kernel-5_35-4_79_2_271'

Detail:
  s/ARMops - Implement Cache_RangeThreshold for PL310 (helps AMBControl to decide what type of TLB maintenance is best). Fix MMU_ChangingEntry_PL310 doing more work than is necessary; was attempting to flush all ways for a given address tag, when really it should have only been flushing all the lines within a page and letting the cache worry about the tags/indices they correspond to.
  s/ChangeDyn, s/VMSAv6, s/AMBControl/memmap - Do extra TLB maintenance following writes to the page tables, as mandated by the ARMv6+ memory order model. Fixes frequent crashes on Cortex-A9 when running with lazy task swapping disabled (and presumably fixes other crashes too)
  s/MemInfo - Fix OS_Memory cache/uncache so that it does cache/TLB maintenance on a per-page basis instead of a global basis. Vastly improves performance when you have a large cache, but may need tweaking again in future to do a global op if large numbers of pages are being modified.
Admin:
  Tested on Pandaboard


Version 5.35, 4.79.2.255. Tagged as 'Kernel-5_35-4_79_2_255'

MemInfo.s:
 Several places in this code called the HAL or other ATPCS defined functions like memset() and hoped that the overall result was V clear. If any of them accidentally set V (for example a CMP that straddles 0x80000000) you ended up trying to look up an international error at the address of the reason code to OS_Memory.
 Now, explicitly clear V in the non error cases where an ATPCS function was called.
 Change the HAL_PhysInfo call to expect a physical ROM size back as an inclusive range, to match the RAM range subreason code. Add 1 to correct for this. A value of 0 & 0 is taken to mean "no physical ROM" as before.
Middle.s:
 Document that 255 means "no IOMD" or "no VIDC", that's what the HALs have been using since year dot.

Version 5.35, 4.79.2.248. Tagged as 'Kernel-5_35-4_79_2_248'

Detail:
  s/MemInfo - Fixed typo causing build error with HiProcVecs/zero page relocated kernel
  s/PMF/osinit - Fix the call to GraphicsV_StartupMode to work correctly with non-zero driver numbers
Admin:
  Tested on BB-xM with high processor vectors


Version 5.35, 4.79.2.226. Tagged as 'Kernel-5_35-4_79_2_226'

Add OS_Memory 24 implementation. Change OS_ValidateAddress to use it. Fix kernel leaving the physical access MB in a messy state. Try and protect against infinite abort loops caused by bad environment handlers.

Detail:
  s/MemInfo - Added an implementation of ROL's OS_Memory 24 call. Unlike the old OS_ValidateAddress call, this call should successfully report the presence of all memory areas known to the kernel. It should also correctly indicate which parts of a sparse DA are mapped in, unlike the old OS_ValidateAddress implementation.
  s/ChangeDyn - Update dynamic area handling to construct a lookup table for mapping logical addresses to dynamic areas; this is used by OS_Memory 24 to quickly locate which DA(s) hit a given region
  s/AMBControl/main - Make sure lazy task swapping is marked as disabled when AMB_LazyMapIn is {FALSE} - required so that OS_Memory 24 will give application space the correct flags
  s/ArthurSWIs - Switch OS_ValidateAddress over to using OS_Memory 24, as per ROL. For compatibili...

Detail:
  s/MemInfo - Fix OS_Memory 0 physical-to-logical conversion returning bad addresses for most cases due to R5 being modified by physical_to_ppn (bug introduced in revision 4.4.2.20)
  s/vdu/vdudriver - Fix some VDU driver variables not being initialised correctly when switching GraphicsV driver
  s/vdu/vdugrafv - Fix handling of VSync events from GraphicsV drivers other than driver zero
  s/vdu/vduswis - Fix abort when OS_ScreenMode 11 is passed a bad driver number
Admin:
  Tested on Raspberry Pi
  There still seems to be a bug lurking somewhere when switching to a GraphicsV driver that uses DA2; the system will crash horribly unless DA2 is already a suitable size for the initial mode change


Version 5.35, 4.79.2.206. Tagged as 'Kernel-5_35-4_79_2_206'

Detail:
  Briefly, this set of changes:
  * Adjusts PhysRamTable so that it retains the flags passed in by the HAL from OS_AddRAM (by storing them in the lower 12 bits of the size field)
  * Sorts the non-VRAM entries of PhysRamTable by speed and DMA capability, to ensure optimal memory allocation during OS startup.
  * Adjust the initial memory allocation logic to allow the cursor/sound chunk and HAL noncacheable workspace to come from DMA capable memory
  * Extends OS_Memory 12 to accept a 'must be DMA capable' flag in bit 8 of R0. This is the same as available in ROL's OS.
  * Extends OS_DynamicArea 0 to allow the creation of dynamic areas that automatically allocate from DMA capable memory. In ROL's OS this was done by setting bit 12 of R4, but we're using bits 12-14 for specifying the cache policy, so instead bit 15 is used.
  * Fixes OS_ReadSysInfo 6 to return the correct DevicesEnd value now that the IRQ/device limit is computed at runtime
  File changes:
  * hdr/OSEntries - Add definitions of the various flags passed to OS_AddRAM by the HAL. Add a new flag, NoDMA, for memory which can't be used for DMA.
  * hdr/KernelWS - Tidy PhysRamTable definition a bit by removing all the DRAM bank definitions except the first - this makes it easier to search for code which is interacting with the table. Remove VRAMFlags, it's redundant now that the flags are kept in the table. Add DMA allocation info to InitWs.
  * s/AMBControl/memmap - Updated to mask out the flags from PhysRamTable when reading RAM block sizes.
  * s/ARM600 - Strip out a lot of IOMD specific pre-HAL code.
  * s/ChangeDyn - Updated to cope with the flags stored in PhysRamTable. Implement support for DMA-capable dynamic areas. Rewrite InitDynamicAreas to insert pages into the free pool in the right order so that the fastest memory will be taken from it first.
  * s/GetAll, s/Middle - Fix OS_ReadSysInfo 6 to return the correct HAL-specific DevicesEnd value
  * s/HAL - Significant rework of initial RAM allocation code to allow the kernel workspace to come from the fastest DMA incapable RAM, while also allowing allocation of DMA capable memory for HAL NCNB workspace & kernel cursor/sound chunks. ClearPhysRAM rewritten as part of this.
  * s/MemInfo - Updated to cope with the flags stored in PhysRamTable. Add support for the new OS_Memory 12 flag. Update OS_Memory 7 to not assume PhysRamTable entries are sorted in address order, and rip out the old pre-HAL IOMD implementation.
  * s/NewReset - Remove GetPagesFromFreePool option, assume TRUE (as this has been the case for the past 10+ years). Revise a few comments and strip dead code. Update to cope with PhysRamTable flags.
  * s/VMSAv6 - Remove a couple of unused definitions
  * s/vdu/vdudriver - Update to cope with PhysRamTable flags
Admin:
  Tested in Kinetic RiscPC ROM softload, Iyonix softload, & OMAP3


Version 5.35, 4.79.2.186. Tagged as 'Kernel-5_35-4_79_2_186'

Detail:
  Revisions Kernel-5_35-4_79_2_153 and Kernel-5_35-4_79_2_161 merged with one
  trivial conflict.
Admin:
  Confirmed that this builds, but not tested on hardware.

Version 5.35, 4.79.2.147.2.15. Tagged as 'Kernel-5_35-4_79_2_147_2_15'

Previously HAL_PhysInfo took one of two routes to get the arrangment table of arrangement table size.
Reorganised to accept a subreason to allow other physical info to be requested.


Version 5.35, 4.79.2.161. Tagged as 'Kernel-5_35-4_79_2_161'

The only fake result now is the hard ROM amount, which is hardwired to 4MB and might not be correct.
Unrelated changes
 hdr.HALDevice: Assign a device for VIDC20.
 hdr.KernelWS: Reorder into ascending order, remove legacy addresses.
 s.ARM600: Move PhysSpaceSize inside :LNOT:HAL switch.
 s.Kernel: Move PhysSpaceSize inside :LNOT:HAL switch.

Version 5.35, 4.79.2.153. Tagged as 'Kernel-5_35-4_79_2_153'

Detail:
  A whole mass of changes to add high processor vectors + zero page relocation support to the Cortex branch of the kernel
  At the moment the code can only cope with two ZeroPage locations, &0 and &FFFF0000. But with a bit more tweaking those restrictions can probably be lifted, allowing ZeroPage to be hidden at almost any address (assuming it's fixed at compile time). If I've done my job right, these restrictions should all be enforced by asserts.
  There's a new option, HiProcVecs, in hdr/Options to control whether high processor vectors are used. When enabling it and building a ROM, remember:
  * FPEmulator needs to be built with the FPEAnchor=High option specified in the components file (not FPEAnchorType=High as my FPEmulator commit comments suggested)
  * ShareFS needs unplugging/removing since it can't cope with it yet
  * Iyonix users will need to use the latest ROOL boot sequence, to ensure the softloaded modules are compatible (OMAP, etc. don't really softload much so they're OK with older sequences)
  * However VProtect also needs patching to fix a nasty bug there - http://www.riscosopen.org/tracker/tickets/294
  The only other notable thing I can think of is that the ProcessTransfer code in s/ARM600 & s/VMSAv6 is disabled if high processor vectors are in use (it's fairly safe to say that code is obsolete in HAL builds anyway?)
  Fun challenge for my successor: Try setting ZeroPage to &FFFF00FF (or similar) so its value can be loaded with MVN instead of LDR. Then use positive/negative address offsets to access the contents.
  File changes:
  - hdr/ARMops - Modified ARMop macro to take the ZeroPage pointer as a parameter instead of 'zero'
  - hdr/Copro15ops - Corrected $quick handling in myISB macro
  - hdr/Options - Added ideal setting for us to use for HiProcVecs
  - s/AMBControl/allocate, s/AMBControl/growp, s/AMBControl/mapslot, s/AMBControl/memmap, s/AMBControl/service, s/AMBControl/shrinkp, s/Arthur2, s/Arthur3, s/ArthurSWIs, s/ChangeDyn, s/ExtraSWIs, s/HAL, s/HeapMan, s/Kernel, s/MemInfo, s/Middle, s/ModHand, s/MoreSWIs, s/MsgCode, s/NewIRQs, s/NewReset, s/Oscli, s/PMF/buffer, s/PMF/IIC, s/PMF/i2cutils, s/PMF/key, s/PMF/mouse, s/PMF/osbyte, s/PMF/oseven, s/PMF/osinit, s/PMF/osword, s/PMF/oswrch, s/SWINaming, s/Super1, s/SysComms, s/TickEvents, s/Utility, s/vdu/vdu23, s/vdu/vdudriver, s/vdu/vdugrafl, s/vdu/vdugrafv, s/vdu/vdupalxx, s/vdu/vdupointer, s/vdu/vduswis, s/vdu/vduwrch - Lots of updates to deal with zero page relocation
  - s/ARM600 - UseProcessTransfer option. Zero page relocation support. Deleted pre-HAL ClearPhysRAM code to tidy the file up a bit.
  - s/ARMops - Zero page relocation support. Set CPUFlag_HiProcVecs when high vectors are in use.
  - s/KbdResPC - Disable compilation of dead code
  - s/VMSAv6 - UseProcessTransfer option. Zero page relocation support.
Admin:
  Tested with OMAP & Iyonix ROM softloads, both with high & low zero page.
  High zero page hasn't had extensive testing, but boot sequence + ROM apps seem to work.


Version 5.35, 4.79.2.98.2.48. Tagged as 'Kernel-5_35-4_79_2_98_2_48'

Detail:
  Makefile - Now uses ${PERL} for running perl
  s/Kernel - Now uses correct "Bad OS_PlatformFeatures reason code" error number
  s/MemInfo - Updated list of OS_Memory 9 controllers
Admin:
  OMAP3 ROM compiles OK; untested at runtime


Version 5.35, 4.79.2.98.2.43. Tagged as 'Kernel-5_35-4_79_2_98_2_43'

Detail:
  s/MemInfo - List of OS_Memory 9 controllers now updated to include details of the ones that ROL are using, along with which numbers should/shouldn't be safe for us to expand into in the future.
Admin:
  Tested in ROM softload on RiscPC


Version 5.35, 4.79.2.114. Tagged as 'Kernel-5_35-4_79_2_114'

Detail:
  Noted reservation of IO controller type  passed to OS_Memory 9 used when
  system is running as a coprocessor. Not used by current code but we need to
  make sure that any future reservations use different numbers.
Admin:
  No functional change. Brought to our attention by Rob Sprowson.

Version 5.35, 4.79.2.103. Tagged as 'Kernel-5_35-4_79_2_103'

Add support for Cortex cache type. Extend ARM_Analyse to, where appropriate, use CPU feature registers to identify CPU capabilities.

Detail:
  s/ARMops - Support for Cortex multi-level cache (CT_ctype_WB_CR7_Lx). New ARM_Analyse_Fancy to identify CPU capabilities using feature registers.
  s/HAL - Modify pre-ARMop cache code to handle Cortex-syle caches.
  s/MemInfo - Replace ARM_flush_TLB macro call with appropriate ARMop to provide Cortex compatability
  hdr/ARMops - Update list of ARM architectures
  hdr/CoPro15ops - Deprecate ARM_flush_* macros for HAL kernels, as they are no longer capable of flushing all cache types. ARMops should be used instead.
  hdr/KernelWS - Add storage space for multi-level cache properties required for new cache cleaning code.
Admin:
  Tested under qemu-omap3. Still unable to verify on real hardware due to lack of appropriate MMU code. However new OMAP3 HAL code that uses similar cache management functions appears to work fine on real hardware.


Version 5.35, 4.79.2.98.2.2. Tagged as 'Kernel-5_35-4_79_2_98_2_2'

Added "fast" flash tool for Customer L, allowing ROMs to be sent serially at
115200 baud not 9600 baud.
Fix to VDU despatch for ARMv4 and later.
Fixes to power on delete keyboard and keyboard timeout
Implemented MemoryReadPhys and MemoryAmounts with the HAL.

Version 5.35, 4.79.2.59. Tagged as 'Kernel-5_35-4_79_2_59'

*Configure ANYTHINGsize was broken due to not setting R0 to ReadUnsigned
IIC ack message uninternationalised
OS_Memory was saying we only had 4M of RAM
VDU4 scrolling when output was switched to sprite was causing corruption
on use of CTRL-J and CTRL-K
Default SystemSize CMOS set to 32k

Version 5.35, 4.79.2.55. Tagged as 'Kernel-5_35-4_79_2_55'

Detail:
  Lots of changes since last version, at least the following:
  * Updated OS timestamp, removed alpha status
  * Negative INKEY OS version changed to &AA
  * GraphicsV is now alocated vector number &2A
  * ROM moved up to &FC000000
  * Max application slot increased to 512 Mbytes (for now)
  * Max size of RMA increased to 256 Mbytes
  * RMA is now first-created dynamic area (so it gets lowest address after
    top of application slot)
  * OS_Memory 10 reimplemeted
  * New OS_ReadSysInfo 6 values 18-22 added
  * OS_ReadSysInfo 8 gains flag bit to indicate soft power-off
  * Misc internal top-bit-set-address fixes
  * *ChangeDynamicArea can take sizes in megabytes or gigabytes
  * Magic word "&off" in R0 passed to OS_Reset powers down if possible
  * Added acceleration: block copy; CLS; text window scroll up; rectangle
    fill
  * Disabled LED flashing in page mode (liable to crash)
  * Masked sprite plot and VDU 5 text avoids reading the screen if possible
  * Framestore made USR mode accessible
  * Fix for VDU 5,127 bug - now relies on font definitions being in extreme
    quarters of memory, rather than bottom half
  * Allocated 64-bit OS_Convert... SWIs
  * IIC errors use allocated error numbers
  * Looks for Dallas RTC before Philips RTC because we're using a Philips
    NVRAM device with the same ID
  * Fix to bug that meant the oscillator in the Dallas RTC wasn't enabled
  * Default mouse type (USB) changed to allocated number
  * Ram disc max size increased to 128 Mbytes (Ursula merge) and made
    cacheable for StrongARMs (not XScale)
  * Branch through zero handler now works in USR mode, by use of a
    trampoline in the system stack to allow PC-relative register storage
  * Address exception handler changed to not use 0 as workspace
  * OS_Memory 13 extended to allow specification of cacheability and access
    privileges
  * Added OS_Memory 16 to return important memory addresses
  * RISCOS_MapInIO() takes cacheable flag in bit 3, access permissions in
    bits 10 and 11, doubly-mapped flag in bit 20, and access permissions
    specified flag in bit 21
  * Bug fix in last version for application abort handlers didn't quite
    work; register shuffle required
  * "Module is not 32-bit compatible" error now reports the module name
  * Default configured language changed from 10 to 11 (now Desktop again)

Version 5.35, 4.79.2.51. Tagged as 'Kernel-5_35-4_79_2_51'

Version 5.35, 4.79.2.48. Tagged as 'Kernel-5_35-4_79_2_48'