GitLab

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)

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'

Somewhere along the way, BangCam became redundant. Get rid of it.

RISCOS_LogToPhys and OS_Memory 20 (compatibility page) changed to use
suitable subroutines for reading the page tables instead of accessing
them directly.

Change the DecodeL1/L2Entry routines so that instead of accepting a page
table entry as input, they accept a (suitable-aligned) logical address
and fetch the page table entry themselves. This helps insulate the
calling code from the finer details of the page table format.

GetPageFlagsForR0IntoR6 & MoveCAMatR0toR3 changed to use
logical_to_physical & physical_to_ppn, to reduce the number of routines
which are performing direct page table access.

Reduce the number of routines which directly examine the page tables, by
changing OS_FindMemMapEntries to use logical_to_physical.

In preparation for the addition of long descriptor page table support,
start moving low-level page table routines into their own file
(s.ShortDesc) so that we can add a corresponding long descriptor
implementation in the future.

* logical_to_physical, MakePageTablesCacheable,
MakePageTablesNonCacheable, AllocateBackingLevel2, AMB_movepagesin_L2PT,
AMB_movecacheablepagesout_L2PT, AMB_moveuncacheablepagesout_L2PT
routines, and PageNumToL2PT macros, all moved to s.ShortDesc with no
changes.
* Add new UpdateL1PTForPageReplacement routine (by splitting some code
out of s.ChangeDyn)

ppn_to_physical, logical_to_physical, physical_to_ppn & ppn_to_physical
have now all been changed to accept/receive 64bit physical addresses in
R8,R9 instead of a 32bit address in R5. However, where a phys addr is
being provided as an input, they may currently only pay attention to the
bottom 32 bits of the address.

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'

    *BASIC
    *SetMacro Macro Test
    SYS "OS_GSTrans", """<Macro>""", &10000, &100

Would result in an erroneous "String not recognised" error as the
end of macro variable was reached before closing quote.
Fix by reordering the checks.

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.

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

Check now works if ROMLimit is precisely at the end
of ROM causing ROMLimit to not be a valid immediate.

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.

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'