GitLab

R4 contains the offset to adjust the PC value to use in the error message,
but was being corrupted by changes in Kernel 6.62 (commit 6baad1bc).

Version 6.64. Tagged as 'Kernel-6_64'

Was trying to use SYS mode to access user registers, which was introduced
in ARMv4. Fix by using STM and LDM instead.

Also support reading and writing registers for 26-bit modes.

Tested on RPCEmu.

Version 6.63. Not tagged

If lazy task swapping is disabled, and appspace is an AMB node, it was
possible to map out the page at &7000 and trigger an abort by attempting
to shrink application space to a negative size, e.g. by using
"*ChangeDyn -RamFSSize" to create a RAM disc larger than the amount of
available RAM.

Fix it by sanity checking the DA/AMBNode size within AMBDAHandler before
passing on the request to the lower-level growpages/shrinkpages calls
(shrinkpages requires the input to be valid and will break if given a
negative size).

Version 6.63. Tagged as 'Kernel-6_63'

Version 6.62. Tagged as 'Kernel-6_62'

Version 6.61. Tagged as 'Kernel-6_61'

Deleting a non-existent system variable resulted in the error
message: System variable '%0' not found.

Version 6.60. Tagged as 'Kernel-6_60'

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

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'

Version 6.58. Tagged as 'Kernel-6_58'

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'

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'

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'

Historically many commands of BBC Micro heritage were not included
in UitilyModules, but were separated out into a separate pseudo-module,
SysCommsModule, to allow for them to be terminated by any non-letter
for compatibility with the BBC Micro.

However with the introduction of `Oscli_HashedCommands` in August 1999
(and earlier in Ursula branch) this was broken except for *FX, *KEY,
*OPT and *TV, which are handled by a special case making SysCommsModule
redundant.

SysCommsModule is an obsitcle to making the kernel assemble to relocatable
AOF as it requires Module_BaseAddr to have 2 different values and therefore
be a absolute varaible instead of a section relative symbol.

This commit does not change behaviour with `Oscli_HashedCommands` enabled
which is the default, except for listing the command under UtilityModule
in *Help output. Which `Oscli_HashedCommands` disable this change removes
the special behaviour.

Version 6.53. Tagged as 'Kernel-6_53'

Currently RISCOS_AccessPhysicalAddress allows the caller to specify the
permissions/properties of the mapped memory by directly specifying some
of the L1 page table entry flags. This will complicate things when
adding support for more page table formats, so change it so that
standard RISC OS page flags are used instead (like the alternate entry
point, RISCOS_AccessPhysicalAddressUnchecked, already uses).

Also, drop the "RISCOS_" prefix from RISCOS_AccessPhysicalAddress and
RISCOS_ReleasePhysicalAddress, and remove the references to these
routines from the HAL docs. These routines have never been exposed to
the HAL, so renaming them and removing them from the docs should make
their status clearer.

Version 6.52. Tagged as 'Kernel-6_52'

OS_EvaluateExpression is documented as applying GSTrans to any strings
within the expression, but did instead GSTrans the entire expression.

This would result in a sequence such as:

    *Set Alias$@RunType_FD1 "Basic -quit ""%0"" %*1"
    *If "<Alias$@RunType_FD1>"="" Then Set Alias$@RunType_FD1 @RunType_FFB %*0

raising a "Unknown operand" error as the quote in the variable
were interpreted as expression syntax. See
https://www.riscosopen.org/forum/forums/5/topics/16127

Unfortunately skipping the initial GSTrans breaks common code such as:

    If "<StrED_cfg$Dir>" = "" AND <Ctrl$Pressed> = 0 Then ...
    If "<Zap$OSVsn>" <> "" Then SetEval ZapFonts$OSVsn <Zap$OSVsn>

Fix by applying a GSTrans transformation over unquoted parts of the
expression, then applying GSTrans over the quoted strings.

Version 6.51. Tagged as 'Kernel-6_51'

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'

This ensures that the debug macros may be freeley placed without
concern for if LR and CPSR contain important values, and avoid the
of code only working because the debug code changes the flags with
the effect of a bug appearing when debugging is enabled.

Version 6.49. Tagged as 'Kernel-6_49'

Previously the supervisor stack was read-only in user mode, but since
the supervisor stack is typically empty when the CPU is in user mode,
it's questionable whether any software actually makes use of this
facility.

To simplify support for the long descriptor page table format (which
doesn't support the user-RO + privileged-RW access mode), let's
try and remove usermode SVC stack access completely.

Tested on Raspberry Pi 4

Version 6.48. Tagged as 'Kernel-6_48'

Change ZeroPage calculation so that ZeroPage can be at
any 64K aligned address.


Version 6.47. Not tagged

In HandleServiceModeTranslation, make sure WsPtr is initialised
correctly before trying to use it. Fixes system heap corruption when
responding to Service_ModeTranslation (most likely overwriting part of
ChocolateMABlocks, and causing a crash when loading future modules)

Fixes issue reported on forums:
https://www.riscosopen.org/forum/forums/11/topics/15973

Version 6.47. Tagged as 'Kernel-6_47'

Detail:
RamFS now supports disc sizes up to 2GB-4KB, so raise the dynamic area limit from 508MB.

Admin:
Tested with a disc size up to 928MB

Version 6.46. Tagged as 'Kernel-6_46'

Changes in Kernel-6_44 left an undefined symbol in s.HAL in DebugTerminal_Rdch. These mods resolve that, and also add a note in s.Kernel to reflect this usage.

Version 6.45. Tagged as 'Kernel-6_45'

Previously both `RdchInkey` and `PageTest` enabled interrupts after
running callbacks before calling Portable_Idle with the result that
callback could be delayed until the next interrupt.

* Change `process_callback_chain` to leave interrupts disabled, and
  rename accordingly.
* Remove redundant check of CallBack_Flag.
* In `PageTest` move running calbacks into `CtrlShiftTest`, so that
  it is immediately before the test.
* Re-enable interrupts at appropriate locations.

Tested on StrongARM Risc PC.

Version 6.44. Tagged as 'Kernel-6_44'

Version 6.43. Not tagged

Multiple fixes, mostly related to error handling.

1. Ensure R1 is initialised correctly when generating BadPageNumber
errors (labels 94 & 95). Generally this involves setting it to zero to
indicate that no call to LogOp_MapOut is required. Failing to do this
would typically result in a crash.
2. When branching back to the start of the loop after calling
GetNonReservedPage, ensure R0 is reset to zero. Failing to do this would
have a performance impact on LogOp_MapOut, but shouldn't be fatal.
3. In the main routine, postpone writing back DANode_Size until after
the call to physical_to_ppn (because we may decide to abort the op
and return an error without moving a page).
4. Fix stack offset when accessing PMPLogOp_GlobalTBLFlushNeeded.
Getting this wrong could potentially result in some TLB maintenance
being skipped when moving uncacheable pages.
5. Fix stack imbalance at label 94

Version 6.43. Tagged as 'Kernel-6_43'

This ensures that on exit from OS_ReadC / INKEY either
a character is returned or the input buffer is empty,
and that Portable_Idle is only called when the input
buffer is empty.

This avoids a 10 microsecond delay and relying on timer
interrupts to make progress and allows reliably waiting
for input and another event by:

Disable Interrupts
Repeat
  Call INKEY(0), exit loop if key pressed
  Check other event, exit loop if key pressed
  Call Portable_Idle

Version 6.42. Tagged as 'Kernel-6_42'

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'

Fix GrowFreePoolFromAppSpace (i.e. appspace shrink operation) to issue
UpCall_MemoryMoving / Service_Memory when attempting to shrink PMP-based
appspace (i.e. AMBControl nodes). This fixes (e.g.) BASIC getting stuck
in an abort loop if you try and use OS_ChangeDynamicArea to grow the
free pool.

Version 6.40. Tagged as 'Kernel-6_40'

Despite never being properly documented in the RISC OS PRMs, there's
evidence that Acorn were recommending that third-parties used OS_Byte
166 for locating the OS_Byte variables well into the mid-1990's:

https://www.riscosopen.org/forum/forums/5/topics/14676#posts-94080

Currently OS builds which use zero page relocation will only return the
low 16 bits of the address from OS_Byte 166, most likely breaking any
third-party software which is trying to use it. Attempt to restore
compatibility by having OS_Byte 166 add the missing high address bits
into the "next location" value returned in R2, and fix OS_Byte 167 in a
similar manner (adding into R1).

Additionally, make the values read-only, because the kernel is littered
with code that uses hard-coded OsbyteVars addresses and so is unlikely
to do anything sensible if someone was to modify the OsbyteVars address
that's stored in workspace.

Version 6.39. Tagged as 'Kernel-6_39'

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

During ModHandReason_ClaimAligned care is taken to start on a multiple of 32 and end on a multiple of 32 + 16 (such that the next block in the heap would be at +20 same as plain ModHandReason_Claim would do). However, during a ModHandReason_ExtendBlock there's a possibility that those criteria can't be retained, due to having to move to a larger gap elsewhere, leaving the end at an inconvenient +36.
Similar allocation functions in other OS' don't guarantee to return an extended block with the same alignment, so take the position that for extends we always allocate a fresh block, copy the contents, and free the original. Shrinks are left in place.
Tested with a random allocator which juggles 16 aligned allocations 50,000 times.

Version 6.36. Tagged as 'Kernel-6_36'

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

Dynamic area PostGrow handlers aren't able to return errors, so the V
flag is likely undefined. Fix AreaGrow so that it ignores any V-set
condition returned by the call (especially since the CallPostGrow rapper
will have clobbered any error pointer).

Fixes issue reported on forums:
https://www.riscosopen.org/forum/forums/4/topics/14662

Version 6.34. Tagged as 'Kernel-6_34'

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'

Special case for empty files was crashing, fix by removing
which also supports files which report a size of zero but
actually contain data such as Unix device nodes and
Linux procfs.

Error where start outside file adjusted to permit a start
exactly at the end of a file to permit (apparently) empty
files with no output. Doing likewise for non-empty files
is consistent.

Also fix closing file in case of error reading GS format
from CMOS.

Version 6.32. Tagged as 'Kernel-6_32'