GitLab

When AP1 memory is being emulated (long descriptor page tables are in
use), the AbortTrap machinery is used to emulate usermode read access.
This provides coverage for all read instructions except those that
AbortTrap handles via MemMap requests - LDREX, LDA, LDAEX, LDF & LFM.

LDREX & LDAEX request both read & write access, so are fine (the MemMap
request will get passed through to the registered AbortTrap handlers).

LDF & LFM are irrelevant, since they only exist on ARM7500FE (on other
machines FPEmulator will translate them to regular LDR/LDM, which are
handled correctly)

LDA however, will generate a plain "memmap with usermode read" request.
When AbortTrap looks at the permissions of emulated AP1 it doesn't take
into account the fact that the usermode read permission is being
emulated, so it thinks that everything is fine and claims the memmap
was successful, causing the abort handler to retry the instruction
without making any changes, resulting in an infinite abort loop.

Deal with this by detecting the above situation and also requesting
usermode execute access. This will avoid the kernel (and hopefully the
registered AbortTrap handlers) from thinking that the emulated AP1 is
acceptable, without adversely affecting the behaviour of other
instructions or access privileges. If no handler is present or the
memmap request is denied, the abort will get passed on to the next stage
of the abort handler (i.e. you'll get a standard data abort from trying
to LDA from arbitrary emulated AP1 memory)

The new test program (Dev/AbortTrap/attest_ap1) will check that this
edge case is dealt with correctly.

Tested on Pi 4, for both long & short page tables

Version 6.59. Tagged as 'Kernel-6_59'

To avoid CallASWI's CPUFeatures implementation getting dangerously out
of sync with the kernel, add extra asserts to both sets of sources to
check try and make sure both sets of sources get updated when new flags
are added.

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

Version 6.58. Tagged as 'Kernel-6_58'

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.

Also make lazy task swapping aborts to use IFAR where possible, to
ensure any Thumb-2/Jazelle instructions which cross page boundaries are
handled correctly.

OS_ReadSysInfo 7 is meant to record the details of the last data or
prefetch abort that was passed to the environment handlers. This was
implemented in Ursula, but the code for recording the prefetch abort
details got lost somewhere during the 32 bit conversion process. Restore
it.

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

Sadly we need one file per combination of action files, but by adding
these pre-generated cache files to git we can speed up building the
kernel from clean by a significant amount.

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

If lazy task swapping is active, but it isn't a lazy task swapping
abort, AMB_LazyFixUp will force all of application space to be mapped
in, in order to protect the data/prefetech abort environment handlers
from triggering unexpected recursive aborts (which could easily happen
if the handlers make use of application space in any way). Recursive
aborts generally aren't tolerated by these handlers because they're
entered in ABT32 mode and may rely on the DFSR/DFAR registers being
correct.

To allow for more stages to be added to the abort handler inbetween lazy
task swapping fixup & invoking the abort environment handler,
AMB_LazyFixUp has now been split in two so that the code which maps in
all of application space can be excuted at a more suitable time.

Add kalloc (malloc with an error pointer), free, _kernel_irqs_disabled,
_kernel_irqs_off, _kernel_irqs_on, and a simple memcpy implementation.

Export the symbols so they're actually usable from other object files.

Needed to resolve some literal pool range issues when long descriptor
page table support is enabled

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)

* Add KernelBaseA absolute symbol.
* Use KernelBase - KernelBaseA to convert some expressions
  to/from AREA relative form.
* Link to correct address.
* Remove ORG directive
* Move EndOfKernel to separate AREA

When PhysRamTable was updated to store addresses in page units instead
of byte units (commit df4efb68), the code which allocates the ROM
decompression workspace didn't get updated, causing it to break. Add a
few extra shifts to the code in order to account for the changes.

Fixes issue reported on forums with (compressed) OMAP3 ROM failing to
boot: https://www.riscosopen.org/forum/forums/5/topics/16446

Version 6.57. Tagged as 'Kernel-6_57'

* 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

LoadAndDecodeL1Entry will now always return the size/alignment of the
entry. This allows ConstructCAMfromPageTables to walk over a 2MB long
descriptor page table pointer in one go, instead of splitting it into
two 1MB chunks (as if short descriptor page tables were in use) and
calling LoadAndDecodeL1Entry twice. This has allowed the 1MB result
alignment bodge to be removed from the LongDesc version of
LoadAndDecodeL1Entry.

These use a page block with a 64bit address fields (matching OS_Memory
64). The page list(s) contain the full list of pages involved in the
operation, unlike the 32bit PagesUnsafe / PagesSafe calls, which only
list pages which have 32bit addresses. The kernel issues the service
calls in the following order:

1. Service_PagesUnsafe64
2. Service_PagesUnsafe
3. Service_PagesSafe
4. Service_PagesSafe64

Since only one PagesUnsafe operation can occur at a time, a program
which supports both service calls can safely ignore the PagesUnsafe /
PagesSafe calls if a PagesUnsafe64 operation is in progress (the
PagesUnsafe call will only list a subset of the pages from the
PagesUnsafe64 call). The 32bit PagesUnsafe / PagesSafe calls will be
skipped if no 32bit pages are being replaced.

The addition of these calls means that NeedsSpecificPages DAs (and PMPs)
can now request pages which have large physical addresses.

Note that the page replacement logic now has the restriction that pages
which have 32bit physical addresses can only be replaced by other pages
which have 32bit physical addresses. This is necessary to ensure that
users of the old 32bit APIs see the page replacement take place. However
it does mean that programs will be unable to claim pages of low RAM
which are in use if there are not enough free low RAM pages in the free
pool.

A future optimisation would be to update the service calls so that they
don't list required pages which are in the free pool; if all the
required pages are in the free pool this would allow the service calls
(and FIQ claiming) to be skipped completely.

If the HAL has flagged a chunk of RAM as non-DMAable, OS_Memory 19
(DMAPrep) will now indicate that DMA to/from that region should use a
bounce buffer.

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.

Add to s.ChangeDyn a definition of the OS_Memory 0 page block format,
and update all relevant code to use those definitions instead of
hardcoded offsets.

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.

There are 20 length bits per entry, not 22

IICInit only initialises the entries for valid IIC buses (i.e up to the
limit returned by HAL_IICBuses), but some code accesses the array
without checking against the HAL_IICBuses limit. This causes problems
because the array lives in the SkippedTables area of workspace, meaning
it isn't zero-initialised automatically.

Ensure that the entries for the invalid bus numbers are
zero-initialised, so that code which doesn't check against HAL_IICBuses
won't mistake the invalid entries for valid IRQ-driven buses
(InitialiseIRQ1Vtable, Reset_IRQ_Handler, etc.)

Also, protect against overwriting the end of the array if HAL_IICBuses
is more than the OS supports.

Fixes hang on startup on Pi 4 if memory is filled with -1 (and OS is
told that RAM isn't clear), and on Pi400 with normal memory:
https://www.riscosopen.org/forum/forums/11/topics/16313

Version 6.55. Tagged as 'Kernel-6_55'

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.

PageShifts is only accessed with "ADRL xx, PageShifts-1"; adjust the
alignment so that PageShifts-1 is word aligned, to try and avoid us
hitting any ADRL range limits (which has happened with the runtime
ShortDesc vs. LongDesc selection from future commits)

Remove the lazy initialisation of PhysIllegalMask and instead manually
initialise it during MMU init. This fixes some situations where the lazy
initialisation doesn't work (PhysIllegalMask isn't in a zero-initialised
area of workspace, so if the HAL isn't doing a RAM clear then it could
be garbage)