GitLab

This changes PhysRamTable to store the address of each RAM bank in terms
of (4KB) pages instead of bytes, effectively allowing it to support a 44
bit physical address space. This means that (when the long descriptor
page table format is used) the OS can now make use of memory located
outside the lower 4GB of the physical address space. However some
public APIs still need extending to allow for all operations to be
supported on high RAM (e.g. OS_Memory logical to physical address
lookups)

OS_Memory 12 (RecommendPage) has been extended to allow R4-R7 to be used
to specify a (64bit) physical address range which the recommended pages
must lie within. For backwards compatibility this defaults to 0-4GB.

Value needs to be increased from 256 to 320, so that the IRQ table is
large enough to allow the core 2 & 3 private interrupts to be managed.

Previously the CAM sat inside a fixed 16MB window, restricting it to
storing the details of 1 million pages, i.e. 4GB of RAM. Shuffle things
around a bit to allow this restriction to be removed: the CAM is now
located just above the IO region, and the CAM start address /
IO top will calculated appropriately during kernel init. This change
paves the way for us to support machines with over 4GB of RAM.

FixedAreasTable has also been removed, since it's no longer really
necessary (DAs can only be created between the top of application space
and the bottom of the used IO space, and it's been a long time since
we've had any fixed bits in the middle of there)

This adds initial support for the "long descriptor" MMU page table
format, which allows the CPU to (flexibly) use a 40-bit physical address
space.

There are still some features that need fixing (e.g. RISCOS_MapInIO
flags), and the OS doesn't yet support RAM above the 32bit limit, but
this set of changes is enough to allow for working ROMs to be produced.

Also, move MMUControlSoftCopy initialisation out of ClearWkspRAM, since
it's unrelated to whether the HAL has cleared the RAM or not.

The correct amount of space is now reserved for Kbuffs, and there's no
need to have a 1MB gap where the old PhysicalAccess window was.

Tested on Raspberry Pi 4

Although storage maps are useful for allowing the fixed areas of the
memory map to be relocated, it isn't clear in the current definition
what the size of each area is, and it's hard to ensure that all the
areas are kept at the correct alignment.

Replace the current basic workspace definition with one which makes use
of the new ASpace macro, to allow addresses to be calculated
automatically based on the size & alignment of each area. Also output
the address of each area in the build log for easy
debugging/verification.

Binary unchanged.

Move ROM constant to KernelWS with the reset of the memory layout.
Add ASSERT to guard against workspace colliding with ROM.

Rather than specifing absolute addresses for the workspace,
use ObjASM's storage layout support.

* Update OS_ScreenMode 11's handling of drivers which fail to
initialise. If there was no previous driver, then instead of trying to
restore that nonexistant driver, stick with the new one. This is mainly
to help with the case where the kernel's built in modes aren't accepted
by the driver, and valid modes only become available once an MDF is
loaded (this can happen with early OMAP3 chip revisions, which have very
tight sync & porch limits, causing 90% of the kernel's modes to be
rejected). If the kernel was to revert to the "no driver" state, then
loading the MDF would still leave you with no video output.
* Since we can now end up in a state where a driver is selected but
hasn't been programmed yet, update OS_Byte 19 to detect this (via the
magic ScreenBlankDPMSState value of 255) and avoid waiting for VSync
* Update RemovePages & InsertRemovePagesExit (screen DA handlers) to
avoid infinite loops if the screen DA gets shrunk to zero size (was seen
while attempting to complete the !Boot sequence while no driver was
active)

Version 6.33. Tagged as 'Kernel-6_33'

Detail:
Similar to HeapReason_GetAligned, GetSkewAligned is used for allocating
aligned blocks (with optional boundary limit). However instead of using
the logical address of the user portion of the block for the alignment
calculation, it uses an arbitrary offset specified in R5. This makes
it useful for clients such as the PCI module, which care about the
physical alignment of blocks rather than logical alignment.

Admin:
Tested with heaptest

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'

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:
  Over the years the OS's substitute screen mode selection logic has grown to be a tangled mess, and the logic it does implement isn't always very useful. Additionally, the kernel is structured in such a way that it can be hard for modules to override it.
  This set of changes aims to fix the many of the problems, by doing the following:
  - Moving all substitute mode selection logic out of the core VDU driver code and into a Service_ModeTranslation handler. This means you now only have one place in the kernel to look instead of several, and modules can override the behaviour by claiming/blocking the service call as appropriate.
  - Moving handling of the built-in VIDC lists out of the core VDU driver code and into a Service_ModeExtension handler. This means programs can now inspect these VIDC lists by issuing the right service call (although you are essentially limited to lists which the GraphicsV driver is OK with)
  - Moving *TV interlace & offset adjustment logic into the Service_ModeExtension handler, since they're legacy things which can be handled more cleanly for MDF/EDID (and the old code was poking memory the kernel didn't own)
  - Adding a Service_EnumerateScreenModes implementation, so that if you end up in the desktop with ScreenModes non-functional, the display manager at least has something useful to show you
  - Enhancing the handling of the built-in numbered modes so that they are now available in any colour depth; the Service_ModeExtension handler (and related handlers) treat the builtin VIDC lists as a set of mode timings, not a discrete set of modes
  - Substitute mode selection logic is a complete re-write. Instead of trying a handful of numbered fallback modes, it now tries:
    - Same mode but at higher colour depths
    - Same mode but at lower colour depths
    - Alternate resolutions (half-width mode with no double-pixel if original request was for double-pixel, and default resolution for monitor type)
  - Combined with the logic to allow the builtin VIDC lists to be used at any colour depth, this means that the kernel should now be able to find substitute modes for machines which lack support for <=8bpp modes (e.g. OMAP5)
  - Additionally the mode substitution code will attempt to retain as many properties of the originally requested mode as possible (eigen values, gap mode type, etc.)
  Other improvements:
  - The kernel now actually vets the builtin VIDC lists instead of assuming that they'll work (which also means they'll have the correct ExtraBytes value, where applicable)
  - The kernel now uses GraphicsV 19 (VetMode2) to vet the mode during the mode switch process, using the result to detect where the framebuffer will be placed. This allows for GraphicsV drivers to switch between DA 2 and external framestores on a per-mode basis.
  - The kernel now supports mode selectors which specify LineLength values which are larger than necessary; this will get translated to a suitable ExtraBytes control list item (+ combined with whatever padding the driver indicates is necessary via the VetMode2 result)
  File changes:
  - hdr/KernelWS - Reserve space for a VIDC list, since the Service_ModeExtension implementation typically can't use the built-in list as-is
  - s/Arthur3 - Issue Service_ModeFileChanged when the configured monitor type is changed, so that DisplayManager + friends are aware that the set of available modes has changed
  - s/GetAll - Fiddle with GETs a bit
  - s/MemMap2 - Extra LTORG
  - s/NewIRQs - Small routine to install/uninstall false VSync routine (previously from PushModeInfo, which wasn't really the appropriate place for it)
  - s/Utility - Hook up the extra service call handlers
  - s/vdu/legacymodes - New file containing the new service call implementations, and some related code
  - s/vdu/vdudecl - Move mode workspace definition here, from vdumodes
  - s/vdu/vdudriver - Remove assorted bits of mode substitution code. Plug in new bits for calling GraphicsV 19 during mode set, and deal with ExtraBytes/LineLength during PushModeInfo
  - s/vdu/vdumodes - Move some workspace definitions to s/vdu/vdudecl. Tweak how the builtin VIDC lists are stored.
  - s/vdu/vduswis - Rip out more mode substitution code. Issue Service_ModeFileChanged when monitor type is changed by OS_ScreenMode.
Admin:
  Tested on Raspberry Pi 3, Iyonix, IGEPv5


Version 6.14. Tagged as 'Kernel-6_14'

Detail:
  ECFIndex and PalIndex claim to be mode variables, but it's impossible for extension modes to specify their values.
  Since they're easy to calculate from the ModeFlags and Log2BPP values, drop them from the mode workspace (+ table of builtin modes) and calculate them on the fly instead.
  File changes:
  - hdr/KernelWS - Drop ECFIndex & PalIndex from workspace
  - s/vdu/vdumodes - Adjust workspace definition, drop ECFIndex & PalIndex values from VWSTAB
  - s/vdu/vdudriver - Remove now-redundant copy loop from ModeChangeSub. Remove code from GenerateModeSelectorVars that sets up the ECFIndex & PalIndex values on the stack
  - s/vdu/vdugrafl - Adjust copy loop in SwitchOutputToSprite/Mask
  - s/vdu/vdupalette, s/vdu/vdupalxx - Add GetPalIndex routine to generate PalIndex on the fly. Drop the obsolete 16bpp palette/gamma table and shuffle the other entries to simplify GetPalIndex a bit.
  - s/vdu/vduplot - Add GetECFIndex routine to generate ECFIndex on the fly. Also, fix things so that mode 0 isn't the only rectangular-pixel mode which uses the special rectangular-pixel ECF patterns (index 0 vs. index 4). Fiddle with ExportedHLine a bit to avoid an out-of-range ADR.
  - s/NewReset - Fix UAL warning for MOV R0, AppSpaceStart. Adjust memset to not assume 512KB is the correct amount
Admin:
  Tested on Raspberry Pi 3


Version 6.11. Tagged as 'Kernel-6_11'

Detail:
  The error block checks introduced in Kernel-5_35-4_79_2_313 are generating a few too many false positives and edge cases, so take the safe option of just disabling them rather than trying to tweak the rules further. Error pointers will still be checked, but the content of the error blocks will not.
  hdr/Options - Add CheckErrorBlocks switch so we can easily turn the code back on again in the future if necessary
  s/Kernel - Switch out all the code relating to error number checks, except for the dummy load of the first word of the error block, since that's still useful as a pointer validity check
  hdr/KernelWS - Revise SWIDespatch_Size definition so it's easier for it to cope with the various factors which may affect the despatcher size
Admin:
  Tested on PandaBoard
  Relevant discussion:
  https://www.riscosopen.org/forum/forums/11/topics/11133


Version 6.04. Tagged as 'Kernel-6_04'

Version 6.03. Tagged as 'Kernel-6_03'

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:
  To make it easier to support arbitrary complexity keyboard controllers (eg. USB via DWCDriver on the Pi) have the kernel do the early keyboard recovery key press detection instead of the HAL.
  During the first pass those modules used for reading the keyboard are started, ignoring the CMOS frugal bits.
  The keyboard is then scanned for 3s, during which time the RAM is cleared (unless the HAL indicated it has already been done).
  During the second pass the remaining modules are started respecting the CMOS frugal bits. Any which were already started in the first pass are inserted into the new chain, so the keyboard is reset once and only once.

  Boot times, with a 300cs key scan time in NewReset.
  Risc PC with 160MB RAM (128+32+0).
  Times from turning on power to initial "beep", using a stopwatch.
                RISC OS 3.70 RISC OS 5.22 This OS
  ARM610        12.5         10.4         10.3
  ARM710        11.8         10.2         9.7
  StrongARM 233 11.1         9.5          8.4

  In NewReset.s:
  Remove old KbdScan code (leave Reset_IRQ_Handler for IIC only)
  If HAL_KbdScanDependencies returns a null string then present KbdDone flag and skip to full init.
  A few vestiges of soft resets removed.
  Do RAM clear when waiting for INKEY (being careful not to trash the running modules...).
  Clearing just the freepool on a 2GB Titanium cleared 7EFD6 pages (99.2%).

  In ModHand.s:
  2nd pass need to sneaky renumber the nodes (so *ROMModules is in the right order, frugal bits line up) without resetting the chain

  In HAL.s:
  Change ClearPhysRAM to ClearWkspRAM, such that it only clears the kernel workspace rather than all RAM. The bulk of the RAM is cleared during the keyboard scan by new function ClearFreePoolSection.
  Add a variant of Init_MapInRAM which clears the mapped in RAM too (as these very early claims will not be in the free pool when the RAM is cleared later).
  Remove HAL keyboard scan setup & IRQ handler.
  Fix bug in HALDebugHexTX2, the input value needs pre-shifting by 16b before continuing.

  In GetAll.s, PMF/osbyte.s:
  Use Hdr:Countries and Hdr:OsBytes for constants.

  In PMF/key.s, PMF/osinit.s:
  Relocate the key post init from PostInit to KeyPostInit.
  Changed PostInit to not tail call KeyPostInit so they can be called independently.

  In hdr/KernelWs:
  Improve comments, add InitWsStart label to refer to.

  In hdr/HALEntries:
  Add HAL_KbdScanDependencies.
  Delete KbdFlag exports.
  Took the opportunity to reorder some of the higher numbered HAL entries and re-grouping, specifically (112,120) (84,106,108,117).
Admin:
  Tested on an ARM6/ARM7/SA Risc PC, BeagleBoard xM, Iyonix, Pandaboard ES, Wandboard Quad, IPEGv5, Titanium, Pi 2 and 3.
  Requires corresponding HAL change.
  Submission for USB bounty.

Version 5.89. Tagged as 'Kernel-5_89'

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'

Detail:
  This commit lays some of the groundwork for SMP support within the HAL, kernel, and OS.
  Makefile, hdr/HALDevice, hdr/DBellDevice - Add definitions for a doorbell HAL device, to allow CPU cores to signal each other via interrupts
  hdr/HALEntries - Repurpose HAL_Matrix and HAL_Touchscreen entry points for new SMP-related entry points. Add a couple of IRQ-related definitions.
  hdr/KernelWS - Boost MaxInterrupts to 256
  hdr/Options - Add new SMP build switch to control whether the kernel is built in SMP-friendly mode or not. SMP-friendly kernels should still run on single-core machines, but may behave slightly differently.
  s/ARMops - Make as many ARMops SMP-safe as possible, relying on hardware support for broadcasting of cache/TLB maintenance operations
  s/ExtraSWIs - Make SMP-friendly full OS_SynchroniseCodeAreas only sync application space and the RMA (full-cache IMB not really possible with SMP)
  s/NewIRQs - Update IRQ despatcher comments to (hopefully) reflect reality
  Docs/SMP/HAL, Docs/SMP/IRQ - Add documentation covering the new HAL calls and IRQ behaviour
Admin:
  Tested on Raspberry Pi 2, 3, OMAP4, iMX6


Version 5.86, 4.129.2.2. Tagged as 'Kernel-5_86-4_129_2_2'

Detail:
  The ExtraBytes control list item can be used to add padding between framebuffer rows.
  When the kernel sees a VIDC list containing this item, it will now adjust the LineLength and ScreenSize mode variables accordingly, with the end result that the correct amount of memory will be allocated for the framebuffer and the OS will render into it correctly.
  Files changed:
  - hdr/KernelWS - Add DisplayLineLength variable to allow the correct LineLength value to be preserved when screen output is redirected to a sprite
  - s/vdu/vdudriver - Make ModeChangeSub initialise DisplayLineLength before calling SwitchOutputToSprite. Update PushModeInfo to take ExtraBytes into account when calculating LineLength and ScreenSize.
  - s/vdu/vdugrafl - Adjust SwitchOutputToSprite to use DisplayLineLength when restoring screen output
  - s/vdu/vduwrch - Fix full-screen CLS to not write to the padding bytes
Admin:
  Tested on Raspberry Pi 3


Version 5.82. Tagged as 'Kernel-5_82'

Detail:
  s/vdu/vdugrafl, s/vdu/vduttx - Adjust initialisation & shutdown of TTX workspace to fix workspace being erroneously freed/reinitialised when redirecting output to a sprite
  s/vdu/vdugrafk - If ScreenLoad needs to load one row at a time (e.g. when graphics window width != sprite width), allocate a block from the RMA instead of assuming that ScrLoaBuffer is large enough
  hdr/KernelWS - Get rid of ScrLoaBuffer, and shrink LargeCommon to a suitable size. Frees about 2K of VDU workspace.
  s/GetAll - Move Hdr:Sprite earlier in list of GETs
Admin:
  Tested on Raspberry Pi


Version 5.75. Tagged as 'Kernel-5_75'

Detail:
  This set of changes:
  * Adds support for the T, TX and TY mode string elements (as per RISCOS Ltd)
  * Adds support for entering arbitrary-resolution teletext modes by using mode selector blocks with the Teletext mode flag set
  * ScrRCol and ScrBRow mode variables can be provided in the mode selector in order to restrict the number of text rows/columns in teletext modes (as per RISCOS Ltd)
  * If the rows / columns are restricted in this manner then the text window will be centered on the screen, to try and avoid things looking too ugly (no variable text scaling implemented)
  * For HiResTTX, all colour depths >= 4bpp are now supported by teletext. This essentially makes the TTX256 switch obsolete.
  * If the "native" mode 7 is unavailable then the kernel will try a series of fallback resolutions & colour depths in an effort to find a combination that works
  Known bugs/issues:
  * Teletext column count has a max limit of 255 due to TTXDoubleCounts being a byte array
  * If there's a border around the text window, the border will not be refreshed when changing transparency modes using a VDU 23,18,0 sequence
  * ScreenLoad looks like it can overflow the LargeCommon buffer (no buffer size check) - needs fixing before LargeCommon can be safely shrunk below (Old)TTXMapSize
  File changes:
  - hdr/KernelWS - Make CharWidth non-conditional. Adjust handling of teletext workspace; it's now allocated from the system heap to allow it to cope with arbitrary screen sizes
  - s/vdu/vdu23 - Make CharWidth non-conditional
  - s/vdu/vducursoft - Make CursorTeletext cope with arbitrary colour depths, make CharWidth non-conditional, remove hard-coded teletext values
  - s/vdu/vdudriver - Deal with teletext workspace allocation during ModeChangeSub. Deal with selecting teletext modes (and validating colour depth) in GenerateModeSelectorVars.
  - s/vdu/vdugrafl - Make CharWidth non-conditional. Calculate offset required for text window centering.
  - s/vdu/vdumodes - Remove TTX256
  - s/vdu/vduswis - Try other teletext modes if native mode 7 not available. Extend OS_ScreenMode reason codes to cope with teletext mode strings.
  - s/vdu/vduttx - Update to use dynamic workspace. Replace various hardcoded values with variable lookups. Update character plotting + colour/palette selection to work with true-colour modes if HiResTTX.
  - s/vdu/vduwrch - Move some useful code into a subroutine. Update FastCLS to cope with true-colour teletext. Update AddressR0R1 to cope with text window centering offset. Make CharWidth non-conditional.
Admin:
  Tested on Raspberry Pi, BB-xM
  VDU 23,18,0 in 256-colour teletext now works correctly (previously 64-colour mode was in use, causing palette update to be ruined by VIDC1-mangling)


Version 5.74. Tagged as 'Kernel-5_74'

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'

Add new ARMops. Add macros which map the ARMv7/v8 cache/TLB maintenance mnemonics (as featured in recent ARM ARMs) to MCR ops.

Detail:
  - Docs/HAL/ARMop_API - Document the new ARMops. These ops are intended to help with future work (DMA without OS_Memory 0 "make temp uncacheable", and minimising cache maintenance when unmapping pages) and aren't in use just yet.
  - hdr/Copro15ops - Add new macros for ARMv7+ which map the mnemonics seen in recent ARM ARMs to the corresponding MCR ops. This should make things easier when cross-referencing docs and reduce the risk of typos.
  - hdr/KernelWS - Shuffle kernel workspace a bit to make room for the new ARMops
  - hdr/OSMisc - Expose new ARMops via OS_MMUControl 2
  - s/ARMops - Implement the new ARMops. Change the ARMv7+ ARMops to use the new mnemonic macros. Also get rid of myDSB / myISB usage from ARMv7+ code paths; use DSB/ISB/etc. directly to ensure correct behaviour
  - s/HAL - Mnemonic + ISB/DSB updates. Change software RAM clear to do 16 bytes at a time for kernel workspace instead of 32 to allow the kernel workspace tweaks to work.
Admin:
  Binary diff shows that mnemonics map to the original MCR ops correctly
  Note: Raspberry Pi builds will now emit lots of warnings due to increased DSB/ISB instruction use. However it should be safe to ignore these as they should only be present in v7+ code paths.
  Note: New ARMops haven't been tested yet, will be disabled (or at least hidden from user code) in a future checkin


Version 5.68. Tagged as 'Kernel-5_68'

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'

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/Kernel, hdr/KernelWS - Avoid performing error pointer checks for XOS_GenerateError, since (a) it's a no-op as far as errors are concerned, and (b) many programs take advantage of that fact and abuse the SWI for other purposes (triggering callbacks, BASIC string conversion, etc.)
Admin:
  Tested on Raspberry Pi
  Fixes issue reported on forums with Sunfish crashing:
  https://www.riscosopen.org/forum/forums/5/topics/4060


Version 5.35, 4.79.2.314. Tagged as 'Kernel-5_35-4_79_2_314'

Detail:
  Resources/UK/Messages, hdr/KernelWS, s/Kernel - On return from a SWI with V set, do some basic validity checks on the error pointer in order to try and catch buggy SWIs that return bad pointers or invalid error blocks. If a bad pointer is found we'll substitute it with a pointer to a different error block, which has the SWI number in the error message, to allow the user to identify the source of the problem. (There's also a chance we'll crash when investigating a bad pointer, but crashing here in the kernel is preferable to crashing elsewhere because R12 should still contain the SWI number)
  hdr/OSMisc - Define SeriousErrorV reason codes and extended ROM footer entry IDs
  hdr/Options - Remove HangWatch integration flag, obsolete now that SeriousErrorV is available
  s/ArthurSWIs - Keep defaultvectab up to date with vector allocations
  s/Middle - Update serious error handling to call SeriousErrorV at several key points. This allows for accurate crash dumps to be obtained, along with a mechanism to warn low-level components such as RTSupport that the privileged mode stacks are being flattened.
  s/Middle - Add OS_ReadSysInfo 15, for enumerating extended ROM footer entries
  s/PMF/osbyte - Update InitNewFX0Error to use the ROM footer entry ID defined in hdr/OSMisc
Admin:
  Tested on Pi 1B, 2B, 3B


Version 5.35, 4.79.2.313. Tagged as 'Kernel-5_35-4_79_2_313'

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:
  Raise the maximum number of interrupts and IIC buses acceptable, to account for the OMAP5 port.
  Add TLV320/TLV320/SDMA/SDMA/AM572x/GC320/CPSW/SynopsisDWC for Titanium.
  Add OMAP5/OMAP5/OMAP5/TWL6037/OMAP5/OMAP5/SynopsisDWC for OMAP5.
Admin:
  There's likely some rationalisation to be had here, these controllers especially across the OMAP3/4/5 are probably the same thing really and don't merit individual allocations.

Version 5.35, 4.79.2.297. Tagged as 'Kernel-5_35-4_79_2_297'

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'

Detail:
  - Docs/HAL/ARMop_API - Updated with documentation for the new ARMops.
  - s/ARMops - Set up pointers for the new memory barrier ARMops. Add full implementations for ARMv6 & ARMv7; older architectures should be able to get by with a mix of null ops & write buffer drain ops. Update ARMopPtrTable to validate structure against the list in hdr/OSMisc
  - hdr/KernelWS - Reserve workspace for new ARMops. Free up a bit of space by limiting ourselves to 2 cache levels with ARMv7. Remove some unused definitions.
  - hdr/OSMisc - New header defining OS_PlatformFeatures & OS_MMUControl reason codes, OS_PlatformFeatures 0 flags, and OS_MMUControl 2 ARMop indices
  - Makefile - Add export rules for OSMisc header
  - hdr/ARMops, s/ARM600, s/VMSAv6 - Remove CPUFlag_* and MMUCReason_* definitions. Update OS_MMUControl write buffer drain to use DSB_ReadWrite ARMop (which is what most existing write buffer drain implementations have been renamed to).
  - s/GetAll - Get Hdr:OSMisc
  - s/Kernel - Use OS_PlatformFeatures reason code symbols
  - s/vdu/vdudecl - Remove unused definition
Admin:
  Tested on ARM11, Cortex-A8, Cortex-A9


Version 5.35, 4.79.2.279. Tagged as 'Kernel-5_35-4_79_2_279'

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:
  This set of changes adds support for rendering software mouse pointers directly in the kernel, rather than requiring graphics drivers to render them themselves as was the case previously.
  If a driver returns from GraphicsV_Features with the 'hardware pointer' bit clear, and a call to GraphicsV_UpdatePointer is returned unclaimed, then the kernel will step in and render a software pointer. This allows selective control over which areas of the screen the software pointer is used (e.g. if hardware only supports its use in some areas)
  hdr/KernelWS - Shrink PointerXEigFactor to 1 byte to free up some space for tracking the display log2bpp. Use 8 words of space for tracking software pointer state.
  s/vdu/vducursoft - Adjust existing the existing calls to the software pointer RemovePointer/RestorePointer functions so that they're called with IRQs enabled
  s/vdu/vdudriver - Keep track of display log2bpp. Claim/release memory needed for restoring pixels under software pointer.
  s/vdu/vdugrafhal - Update HAL_VideoUpdatePointer handling so that 0 can be returned in a1 to indicate the GraphicsV call should be left unclaimed.
  s/vdu/vdupalxx - Trigger updates of the cached software pointer palette whenever it's likely to become invalidated.
  s/vdu/vdupointer - Add software pointer implementation. Relying on a SpriteExtend OS_SpriteOp would be nice, but we're in the background so have to do plotting & unplotting manually. ColourTrans is used to cache the pointer palette colours for the current mode, although we're limited to calling it from a callback.
Admin:
  Tested on Raspberry Pi & BB-xM
  Pointer is very flickery under some circumstances (e.g. running !CloseUp) due to needing to plot/unplot around any VDU driver screen access (as per text cursor). So code may need revising in future once we can trap reads/writes from specific screen memory pages.


Version 5.35, 4.79.2.269. Tagged as 'Kernel-5_35-4_79_2_269'