GitLab

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'

This was introduced on 2002-10-07 in Kernel-5_35-4_79_2_48
the removed on 2002-11-30 in Kernel-5_35-4_79_2_51 as it
was "liable to crash".

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'

Move .gitignore file to root and populate with all temporary paths.
This fixes .gitignore files being deleted during a ROM build.


Version 6.42. Not tagged

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 a...

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'

Fix AreaGrow to read appspace size correctly when appspace is a PMP
(i.e. an AMBControl node). Reading DANode_Size will only report the
amount of memory currently paged in (e.g. by lazy task swapping),
causing AreaGrow to underestimate how much it can potentially take from
the area.

Buggy since its introduction in Kernel-5_35-4_79_2_284, GrowFreePool was
attempting to grow the free pool by shrinking application space, an
operation which OS_ChangeDynamicArea doesn't support. Change it to grow
the free pool instead, and fix a couple of other issues that would have
caused it to work incorrectly (register corruption causing it to request
a size change of zero, and incorrect assumption that
OS_ChangeDynamicArea returns the amount unmoved, when really it returns
the amount moved)

When a DA tries to grow by more than the free pool size, the kernel
should try to take the necessary remaining amount from application
space. Historically this was handled as a combined "take from freepool
and appspace" operation, but with Kernel-5_35-4_79_2_284 this was
changed to use a nested call to OS_ChangeDynamicArea, so first appspace
is shrunk into the free pool and then the target DA is grown using just
the free pool.

However the code was foolishly trying to use ChangeDyn_AplSpace as the
argument to OS_ChangeDynamicArea, which that call doesn't recognise as a
valid DA number. Change it to use ChangeDyn_FreePool ("grow free pool
from appspace"), and also fix up a stack imbalance that would have
caused it to misbehave regardless of the outcome.

TryToShrinkShrinkables_Bytes expected both R1 and R2 to be byte counts,
but AreaGrow was calling with R1 as a byte count and R2 as a page count.
This would have caused it to request the first-found shrinkable to
shrink more than necessary, and also confuse the rest of AreaGrow when
the page-based R2 result of TryToShrinkShrinkables gets converted to a
byte count (when AreaGrow wants it as a page count)

Update AreaShrink so that (when shrinking appspace) CheckAppSpace is
passed the change amount as a negative number, so that Service_Memory is
issued with the correct sign.

Fixes issue reported on the forums, where BASIC was getting confused
because appspace shrinks were being reported as if they were a grow
operation:

https://www.riscosopen.org/forum/forums/4/topics/15067

It looks like this bug was introduced in Kernel-5_35-4_79_2_284
(introduction of PMPs), where the logic for appspace shrinks (which must
be performed via a grow of the free pool or some other DA) were moved
out of AreaGrow and into AreaShrink (because appspace shrinks are now
internally treated as "shrink appspace into free pool")

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'

Very much like OS_Module 12, but returns the pointer to the PW rather than its contents (or NULL if the module died during init).

Trying to dump a file larger than 2GB starting from an offset below 2GB would fail because the compare checking whether PTR#han > EXT#han accidentally set V which was taken as an error (but with R0 not really being an error block).

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'

Reporting invalid parameters to OS_Pointer and OS_ConvertDateAndTime could wander off to bad places due to corrupt LR and/or stack imbalance.

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'

* Don't wait for VSync if we're in IRQ context, since (a) IRQ handlers
shouldn't take lots of time, and (b) it may hang the system. Fixes
https://www.riscosopen.org/tracker/tickets/424
* Extend the DPMSUtils-inherited "don't wait for VSync if HSync output
is off" fix to also deal with the case where VSync output is off, since
it's reasonable to assume that turning off VSync output could also
prevent the CPU from receiving the associated interrupts.

OS_DynamicArea 21, 22 & 25 were using the value of the PMP page list
pointer (DANode_PMP) to determine whether the dynamic area is a PMP or
not. However, PMPs which have had their max physical size set to zero
will don't have the page list allocated, which will cause the test to
fail. Normally this won't matter (those calls can't do anything useful
when used on PMPs with zero max size), except for the edge case of where
the SWI has been given a zero-length page list as input. By checking the
value of DANode_PMP, this would result in the calls incorrectly
returning an error.

Fix this by having the code check the DA flags instead. Also, add a
check to OS_DynamicArea 23 (PMP resize), otherwise non-PMP DAs could end
up having page lists allocated for them.

In OS_DynamicArea 2, a stack imbalance would occur if an error is
encountered while releasing the physical pages of a PMP (R1-R8 pushed,
but only R1-R7 pulled). Fix it, but also don't bother storing R1, since
it's never modified.

* Fix caching of page table entry flags (was never updating R9, so the
flags would be recalculated for every page)
* Fix use of flag in bottom bit of R6; if the flag was set, the
early-exit case for having made all the cacheable pages uncacheable will
never be hit, forcing it to loop through the full page list instead

If HAL+OS are contiguous, the combined image is initially mapped as
OSAP_None in order to allow for decompression. Fix the discontiguous
case to use the same permissions

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'

OS_DynamicArea 21 was treating MaxCamEntry as if it was the exclusive
upper bound, when really it's the inclusive bound. The consequence of
this was that PMPs were unable to explicitly claim the highest-numbered
RAM page in the system.

Version 6.31. Tagged as 'Kernel-6_31'

OS_CLI permits commands to be prefixed with a temporary filing
system, for example "ADFS:Format"

It also passes commands unrecognised to FileSwitch to be executed,
so "ADFS::HardDisc4.$.!Boot" first sets the temporary filing to
ADFS then executes ":HardDisc4.$.!Boot".

This does not work if the path contains a special field,
currently this results in an error as the special filed
would be lost.

Unfortunately many programs, including the RISC OS source
fail because of this.

Instead if a filing system prefix with special field
is found switch to the Temporary filing system and
treat the whole command as a path to execute. For example
passing "IXFS#W:$.HardDisc4.!Boot" sets the temporary filing
system to "IXFS" then executes "IXFS#W:$.HardDisc4.!Boot".

Version 6.30. Tagged as 'Kernel-6_30'

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'