GitLab

These are the 4 common access privilege values in bits 0-3 of OS_DynamicArea 0
and word 3 of the entries used with OS_Read/SetMemMapEntries. They are
equivalent to the kernel's internal OSAP_* symbols.

Version 6.59. Not tagged

Pyromaniac doesn't allow low-level control or examination of the memory
map; allocate an OS_PlatformFeatures bit to allow software to directly
detect this limitation instead of having to rely on the affected SWIs
erroring.

https://www.riscosopen.org/forum/forums/3/topics/16609

The long descriptor page table format doesn't support RISC OS access
privilege 1 (user RX, privileged RWX). Previously we were downgrading
this to AP 0 (user RWX, privielged RWX), which obviously weakens the
security of the memory. However now that we have an AbortTrap
implementation, we can map the memory as "user none, privileged RWX" and
provide user read support via AbortTrap's instruction decode & execute
logic.

There's no support for executing usermode code from the memory, but the
compatibility issues caused by that are likely to be minimal.

This implementation should be compatible with RISCOS Ltd's
implementation.

This supports all the load/store instructions, including FPA & VFP/NEON.
Most instructions are handled directly via the base version of the
AbortTrap API that was first implemented in RISC OS Select. However, to
properly cope with LDREX/STREX, and future support for prefetch aborts,
the API has been extended to allow the kernel to request that a block of
memory is mapped in with certain permissions. For LDREX/STREX the kernel
will then rewind the PC so that the instruction can be retried directly.

Test code in Dev/AbortTrap exists in order to allow checking of all
major functionality, along with code for building the code in a
softloadable module for easier/quicker testing.

Report whether:
* DFAR & DFSR are writable
* IFAR, IFSR, AIFSR, ADFSR are implemented

More data & prefetch abort registers

There was some redundant code needlessly pushing & popping various
registers to the stack, left behind from when we removed the code that
dealt with 26-bit processor vector reads on StrongARM & processed the
proto-OS_AbortTrap "abort indirection nodes".

* Instruct the linker to place any RW/ZI data sections in the last ~16MB
of the memory map, starting from &ff000000 (with the current toolchain,
giving it a fixed base address is much easier than giving it a variable
base address)
* The RW/ZI section is mapped as completely inaccessible to user mode
* The initial content of the RW section is copied over shortly after MMU
startup (in Continue_after_HALInit)
* Since link's -bin option produces a file containing a copy of the
(zero-initialised) ZI section, the kernel binary is now produced from a
"binary with AIF header" AIF with the help of the new 'kstrip' tool.
kstrip extracts just the RO and RW sections, ensuring the ROM doesn't
contain a redundant block of zeros for the ZI section.

This should make it easier to use C code & arbitrary libraries within
the kernel, providing they're compiled with suitable settings (e.g.
non-module, no FP, no stack checking, like HALs typically use)

* RISCOS_LogToPhys upgraded to allow it to cope with all page types
(added support for 64KB "large" pages and lazily-mapped pages)

* Added OS_Memory 65, which calls through to RISCOS_LogToPhys, to allow
regular software to do logical-to-physical conversions for all page
types (other calls, like OS_Memory 0/64, typically only work with 4KB
pages)

* LoadAndDecodeL2Entry updated to always return a page/entry size, like
LoadAndDecodeL1Entry

Version 6.56. Tagged as 'Kernel-6_56'

Runtime selection between long descriptor and short descriptor page
table format is now possible (with the decision based on whether the HAL
registers any high RAM or not). The main source changes are as follows:

* LongDesc and ShortDesc switches are in hdr.Options to control what
kernel variant is built
* PTOp and PTWhich macros introduced in hdr.ARMops to allow for
invocation of functions / code blocks which are specific to the page
table format. If the kernel is being built with only one page table
format enabled, PTOp is just a BL instruction, ensuring there's no
performance loss compared to the old code.
* _LongDesc and _ShortDesc suffixes added to various function names, to
allow both versions of the function to be included at once if runtime
selection is enabled
* Most of the kernel / MMU initialisation code in s.HAL is now encased
in a big WHILE loop, allowing it to be duplicated if runtime switching
is enabled (easier than adding dynamic branches all over the place, and
only costs a few KB of ROM/RAM)
* Some more functions (notably AccessPhysicalAddress,
ReleasePhysicalAddress, and MapInIO) have been moved to s.ShortDesc /
s.LongDesc since they were already 90% specific to page table format

Bit 11 of R0 can be used to indicate that the callback functions use
64bit physical addresses instead of 32bit ones.

OS_Memory 64 is an extended form of OS_Memory 0 which uses 64bit
addresses instead of 32bit. Using 64bit physical addresses allows
conversions to/from physical addresses to be performed on pages with
large physical addresses. Using 64bit logical addresses provides us some
future-proofing for an AArch64 version of RISC OS, with a 64bit logical
memory map.

MaxCamEntry32 is an internal variable which the kernel can use to
quickly determine whether a RAM page has a 32bit physical address or
something larger, by comparing with the physical page number (currently
entries in PhysRamTable are sorted such that all 32bit pages come first)

CPUFlag_HighRAM (aka OS_PlatformFeatures 0 bit 21) is a flag that
external code can use to detect whether any high RAM is present, and
thus whether 64bit physical address APIs should be preferred over 32bit
ones (once the new APIs are implemented!). Using APIs which only support
32bit physical addresses will result in functionality being limited.

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.

Define that bit 12 of the RISCOS_AddRAM flags indicates that the
supplied start, end, and sigbits values are in 4KB units instead of byte
units. This allows a 44 bit address space to be used, higher than the 40
bit LPAE limit.

The page list that RISCOS_AddRAM constructs will now store everything in
4KB page units, however any RAM above 4GB will currently be thrown away
when the list is later transferred to the PhysRamTable which the OS uses
at runtime.

Version 6.54. Tagged as 'Kernel-6_54'

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.

It's the only privileged-mode stack which doesn't have its address
exposed via OS_ReadSysInfo 6. Expose it so that software which wants to
know its address can read it instead of relying on hardcoded values.

Tested on Raspberry Pi 4

Version 6.50. Tagged as 'Kernel-6_50'

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.

* Create new header file defining symbolic name for OS_AMBControl
  reason codes and flags
* Implement OS_AMBControl 9 (used to determine required size of buffer
  passed to OS_AMBControl 8 - potential thread safety issue not addressed)
* Return allocated error numbers in various failure cases

Version 6.38. Tagged as 'Kernel-6_38'

Edits to the RISCOS header file should really have gone through the
allocations system. Fortunately, no harm was done in this case, but a
minor syntactical change is required in order to bring it in line with
the automatic redaction scripts used when exporting the header from the
allocations database.

Version 6.37. Not tagged

* Listen out for PointerV 9, which (RISC OS 5) mouse drivers use to
indicate scroll wheel updates + extra button status
* Changes in the state of the extra buttons are treated the same as
changes to normal mouse buttons: signalled via Event_Mouse, and stored
in the mouse buffer (for reading via OS_Mouse).
* Changes in the scroll wheel(s) are signalled via Event_Expansion,4. If
the event vector call is unclaimed, the kernel's wheel position
accumulators will be updated
* Wheel position accumulators can be read via OS_Pointer 2
* Wheel position accumulators implement "wrap to zero" logic on overflow

This matches RISCOS Ltd's implementation
(http://www.riscos.com/support/developers/riscos6/input/pointerdevices.html),
except that:

* The kernel currently doesn't call PointerV 4, so PointerV 9 is the
only way drivers can report wheel + extra button status
* Extra mouse buttons don't generate KeyV transitions
* Our implementation is in the kernel, not an OSPointer module

Version 6.37. Tagged as 'Kernel-6_37'

OS_Module
=> R0=24
   R3=size in bytes
   R4=alignment in bytes (must be a power of 2)
<= R2=base of request
   or error
Tested with a handful of valid and invalid alignments, and with one grossly larger than the free RMA to trigger an RMA extend to occur.

Version 6.35. Tagged as 'Kernel-6_35'

Detail:
  * various low-numbered dynamic areas used by RISC OS 6 and Pyromaniac
  * OS_ReadSysInfo 8 host platform classes for VirtualRPC, A9Home, Pyromaniac
  * OS_Byte 0,<not 0> MosVer values for various systems since the BBC micro
  * OS_Byte 129,0,255 (BASIC INKEY -256) values for various RISC OS systems

Admin:
  Discovered that these weren't really recorded anywhere during recent
  allocation request. Some information gleaned from http://beebwiki.mdfs.net

Version 6.34. Not tagged

The XHCIDriver module adds 64k to get the register address. In an attempt to phase this out (so the registers are the true base address), assign a flag so that loading a suitable XHCIDriver on an old HAL still works.

Version 6.33. Not tagged

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

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

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

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

Version 6.29. Tagged as 'Kernel-6_29'

Version 6.28. Not tagged

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

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

Notes:

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

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

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

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

Version 6.28. Tagged as 'Kernel-6_28'

Detail:
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

ControlList_Interlaced is taken to have meant "output interlaced sync on H/V" and "configure DMA to show alternate lines in the framestore on alternate fields", therefore SyncPol flags mean:
b43
 00 = 'normal' progressive scan
 01 = interlaced sync, but both fields show the same image
 10 = (invalid)
 11 = interlaced sync, fields use alternate lines from the image

Version 6.21. Tagged as 'Kernel-6_21'

Detail:
  s/vdu/legacymodes - Make the Service_ModeExtension implementation automatically use ExtraBytes to request that the row length is a multiple of a word (since things fail with non-word aligned rows)
  hdr/VIDCList - Un-deprecate SyncPol bits 2 & 3 and improve the comments to indicate the difference between SyncPol interlace and control list interlace
Admin:
  Tested on BB-xM


Version 6.17. Tagged as 'Kernel-6_17'