GitLab

The poor documentation of OS_Exit in the PRMs means there could be many
pieces of software which are using it in a dangerous way. E.g. the
famous issue of "OS_Exit generates a garbage error if the return code is
out of range" that's documented in the OS StrongHelp manuals - where
people (quite rightly) assumed that the OS would generate the "return
code out of range" error, when in reality the OS has only ever used the
error pointer that was supplied by the caller.

Try and improve on things slightly by having OS_Exit sanity check the
supplied error pointer before it tries to use it. This doesn't alter the
cases where OS_Exit decides to silently ignore the supplied error
pointer / return code (if R0 isn't word aligned, or historically, if R0
wasn't word aligned and wasn't in the low 64MB of address space), it
just alters the logic for what error pointer gets sent to
OS_GenerateError when it does decide to raise an error.

If the error pointer looks bad (it's below &4000 or not pointing to at
least 8 bytes of readable memory) then it will get swapped out for one
of the "return code out of range" errors which get used when you *Set
Sys$ReturnCode.

Version 6.70. Tagged as 'Kernel-6_70'

Although it's never been officially documented, RISC OS has historically
used the following values for R0-R2 when calling the exit environment
handler:

R0 = 0 (or some other "safe" value)
R1 = R1 from OS_Exit
R2 = Return code

Some exit handlers were relying on this (e.g. Shared C Library /
ANSILib). Changing OS_Exit to use TaskControl_ResetStacks was causing R1
& R2 to be corrupt, with the result that non-zero, non-error-generating
return codes from C programs were being lost and reset to zero.

Document things more clearly and ensure R0-R2 have acceptable values so
that software which relies on the old behaviour will work again.

OSExitArgs checks how OS_Exit handles its arguments, whether it passes
the call on to the error or exit handler, and the register state on
entry to those handlers.

It will currently fail on this version of the kernel due to a register
corruption bug introduced when OS_Exit was changed to use
TaskControl_ResetStacks (the state of R0-R2 on entry to exit handlers
has never been documented, and some handlers rely on R0-R2 being in a
valid state to pass into another OS_Exit call, but TaskControl was
corrupting R1-R2, preventing the return code from being passed on)

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'

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.

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.

The current OS_Memory 7 implementation uses an address range structure
returned by HAL_PhysInfo to decide which part of the physical address
arrangement table to overwrite with RAM information. I suspect the
original intention was for OS_Memory to use this address range to avoid
marking the VRAM as DRAM (HAL_PhysInfo is expected to fill in the VRAM
itself). But by overwriting everything between the start and the end
address, OS_Memory will also overwrite any non-RAM areas which are
sandwiched between RAM banks, e.g. the VideoCore-owned RAM on Pi models
with >1GB RAM. There's also the problem that the address range returned
by the HAL is using 32bit addresses, so it won't work as-is for RAM
located above the 4GB barrier.

Fix these issues by reworking the routine so that it ignores the address
range returned by the HAL and instead detects VRAM by checking the
IsVRAM flag in the PhysRamTable entry. And for detecting if the ROM is
running from RAM, instead of using the address range we can rely on the
flag available via OS_ReadSysInfo 8 (i.e. HAL_PlatformInfo), like
OS_Memory 8 does.

Also add a simple BASIC program (Dev.PhysInfo) to allow easy checking of
HAL & OS physical address arrangement tables.

Version 6.41. Tagged as 'Kernel-6_41'

Version 6.26. Tagged as 'Kernel-6_26'

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:
Kernel-5_44 tweaked the heap manager to try and avoid creating small
free blocks. Adjust HeapTest's block size checks so that it allows for
this behaviour.

Admin:
Tested briefly

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

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:
  TestSrc/HeapTest/c/testbed - Added missing semicolon
  TestSrc/HeapTest/s/asm - Include Hdr:MsgTrans for XMessageTrans_CopyError
Admin:
  Now compiles and runs properly!


Version 5.35, 4.79.2.129. Tagged as 'Kernel-5_35-4_79_2_129'

Improve heap manager. Add heap testbed. Add dummy implementation of some OS_ScreenMode reason codes.

Detail:
  s/HeapMan, hdr/KernelWS - Heap manager improvements:
    - Errors generated by interrupted heap operations that are forced to complete by a OS_Heap call from the background are now cached in kernel workspace until the foreground task is resumed. This prevents them from being potentially overwritten by MessageTrans running out of background error buffers.
    - Added new OS_Heap reason code, #7 - Get area aligned. This allows areas of memory to be allocated at specific (power-of-2) alignments, and optionally without crossing a given (power-of-2) boundary. Alignment & boundary calculations are performed using logical addresses.
    - Removed the limitation that all free and allocated blocks must be a multiple of 8 bytes in length. This change was required in order to allow OS_Heap 7 to function correctly. Now the only requirements are that blocks must be multiples of 4 bytes in length, at 4 byte alignment, with a minimum length of 8 bytes. 4 extra padding bytes may still be added to the end of allocations in order to avoid creating 4-byte free blocks.
  s/HeapMan, TestSrc/HeapTest/Makefile, TestSrc/HeapTest/c/testbed, TestSrc/HeapTest/s/asm - Added heap testbed program. Can either use the OS_Heap SWI or directly include a copy of the Kernel's heap manager sources.
  s/vdudecl, s/vduswis - Added dummy implementations of OS_ScreenMode 4, 5 and 6. This prevents the Wimp generating lots of "Unknown OS_ScreenMode reason code" errors when redrawing the screen.
  s/Arthur3, s/Oscli - Moved dotstring closer to where it's used to avoid "ADRL out of range" errors in Tungsten build
Admin:
  Tested in OMAP3 ROM & Tungsten ROM softload.
  Heap testbed successfully performed over 400 million heap ops, so there shouldn't be any serious bugs in the new code (touch wood)


Version 5.35, 4.79.2.128. Tagged as 'Kernel-5_35-4_79_2_128'

Implement OS_ConvertVariform, internally the other conversions now just call it.
Add tester for Variform to 'Dev'.
Made block copy weirdness for XScale dependent on XScale arch flag.

Version 5.35, 4.79.2.126. Tagged as 'Kernel-5_35-4_79_2_126'

Bandwidth limit for 7500FE fixed.
RO371Timings flag set to :LNOT:STB

Version 4.64. Tagged as 'Kernel-4_64'

Clean reimport of hdr.RISCOS (real commit date 2008-03-28 by bavison), without any of the 3rd party allocations.