GitLab

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

Detail:
  * Filled in CPU tables for publicly documented ARMv8 cores (Cortex-A53,57,72).
  * Recent ARM ARMs (e.g. section B1.9.2 of the ARMv7AR ARM) permit the core to
    take an undefined instruction exception upon encountering even not-taken
    conditional undefined instructions. This option is exercised by the
    Cortex-A53, unlike all ARMv7 cores previously supported by RISC OS. This
    unfortunately trips up a lot of kernel code that adapts to different
    architectures at runtime. These have now all been replaced with branches
    over the affected code on the opposite condition.
  * Fixed bug in HAL_InvalidateCache_ARMvF: for the main body of the loop,
    which was written as though to act on the CLIDR register, r8 actually
    contained the CTR register instead.
Admin:
  Tested on Raspberry Pi 3

Version 5.35, 4.79.2.304. Tagged as 'Kernel-5_35-4_79_2_304'

Detail:
  - Docs/HAL/ARMop_API - Updated with documentation for the new ARMops.
  - s/ARMops - Set up pointers for the new memory barrier ARMops. Add full implementations for ARMv6 & ARMv7; older architectures should be able to get by with a mix of null ops & write buffer drain ops. Update ARMopPtrTable to validate structure against the list in hdr/OSMisc
  - hdr/KernelWS - Reserve workspace for new ARMops. Free up a bit of space by limiting ourselves to 2 cache levels with ARMv7. Remove some unused definitions.
  - hdr/OSMisc - New header defining OS_PlatformFeatures & OS_MMUControl reason codes, OS_PlatformFeatures 0 flags, and OS_MMUControl 2 ARMop indices
  - Makefile - Add export rules for OSMisc header
  - hdr/ARMops, s/ARM600, s/VMSAv6 - Remove CPUFlag_* and MMUCReason_* definitions. Update OS_MMUControl write buffer drain to use DSB_ReadWrite ARMop (which is what most existing write buffer drain implementations have been renamed to).
  - s/GetAll - Get Hdr:OSMisc
  - s/Kernel - Use OS_PlatformFeatures reason code symbols
  - s/vdu/vdudecl - Remove unused definition
Admin:
  Tested on ARM11, Cortex-A8, Cortex-A9


Version 5.35, 4.79.2.279. Tagged as 'Kernel-5_35-4_79_2_279'

Historically the kernel looked after all aspects of cache control since they were common across all ARMs. However, not all cache controllers are created equal, and sometimes more complex initialisation steps are needed than fit the generic coprocessor ops - for example the PL310 attached to a Cortex-A9 has memory mapped control registers.
Rather than clutter the kernel with one shot init code for every cache controller invented, we delegate that step to the HAL in HAL_Init. This is only a few hundred instructions later than where it was already being set. The kernel remains responsible for subsequent maintenance, this is just init which is being handed off.
A quick survey of the Cortex-A TRMs shows:
A5 - optional, for example ARM's PL310, ref TRM section 8.1.7.
A7 - optional, C bit of SCTLR, ref TRM section 1.1.
A8 - L2EN bit of ACTLR, note this bit has been recycled for other uses on other cores, ref TRM section 8.3.
A9 - not integrated, ARM's PL310 uses bit 0 of control register 1, ref PL310 TRM section 3.1.1.
A12 - see A17
A15 - integrated, C bit of SCTLR, ref TRM section 7.2.3.
A17 - integrated, bit 18 of L2CTLR & C bit of SCTLR, ref TRM section 7.2.
and while we've got the TRMs open, back fill the CPU id register table.

Version 5.35, 4.79.2.250. Tagged as 'Kernel-5_35-4_79_2_250'

Detail:
  hdr.ARMops
    added Cortex_A9
  hdr.HALDevice
    added OMAP4 specific device IDs
  hdr.KernelWS
    changed definition of DefIRQ1Vspace for M_CortexA9
  s.ARMops
    added CortexA9 specific code for enabling L2 cache
    added CPUDesc Cortex_A9
  s.NewIRQs
    added CortexA9 specific definition of MaxInterrupts
  s.NewReset
    added M_CortexA9 options
    line 1444: corrected typo
    line 187: commented out unnecessary operation
Admin:
  Submission from Willi Theiß

Version 5.35, 4.79.2.98.2.50. Tagged as 'Kernel-5_35-4_79_2_98_2_50'

Detail:
  A whole mass of changes to add high processor vectors + zero page relocation support to the Cortex branch of the kernel
  At the moment the code can only cope with two ZeroPage locations, &0 and &FFFF0000. But with a bit more tweaking those restrictions can probably be lifted, allowing ZeroPage to be hidden at almost any address (assuming it's fixed at compile time). If I've done my job right, these restrictions should all be enforced by asserts.
  There's a new option, HiProcVecs, in hdr/Options to control whether high processor vectors are used. When enabling it and building a ROM, remember:
  * FPEmulator needs to be built with the FPEAnchor=High option specified in the components file (not FPEAnchorType=High as my FPEmulator commit comments suggested)
  * ShareFS needs unplugging/removing since it can't cope with it yet
  * Iyonix users will need to use the latest ROOL boot sequence, to ensure the softloaded modules are compatible (OMAP, etc. don't really softload much so they're OK with older sequences)
  * However VProtect also needs patching to fix a nasty bug there - http://www.riscosopen.org/tracker/tickets/294
  The only other notable thing I can think of is that the ProcessTransfer code in s/ARM600 & s/VMSAv6 is disabled if high processor vectors are in use (it's fairly safe to say that code is obsolete in HAL builds anyway?)
  Fun challenge for my successor: Try setting ZeroPage to &FFFF00FF (or similar) so its value can be loaded with MVN instead of LDR. Then use positive/negative address offsets to access the contents.
  File changes:
  - hdr/ARMops - Modified ARMop macro to take the ZeroPage pointer as a parameter instead of 'zero'
  - hdr/Copro15ops - Corrected $quick handling in myISB macro
  - hdr/Options - Added ideal setting for us to use for HiProcVecs
  - s/AMBControl/allocate, s/AMBControl/growp, s/AMBControl/mapslot, s/AMBControl/memmap, s/AMBControl/service, s/AMBControl/shrinkp, s/Arthur2, s/Arthur3, s/ArthurSWIs, s/ChangeDyn, s/ExtraSWIs, s/HAL, s/HeapMan, s/Kernel, s/MemInfo, s/Middle, s/ModHand, s/MoreSWIs, s/MsgCode, s/NewIRQs, s/NewReset, s/Oscli, s/PMF/buffer, s/PMF/IIC, s/PMF/i2cutils, s/PMF/key, s/PMF/mouse, s/PMF/osbyte, s/PMF/oseven, s/PMF/osinit, s/PMF/osword, s/PMF/oswrch, s/SWINaming, s/Super1, s/SysComms, s/TickEvents, s/Utility, s/vdu/vdu23, s/vdu/vdudriver, s/vdu/vdugrafl, s/vdu/vdugrafv, s/vdu/vdupalxx, s/vdu/vdupointer, s/vdu/vduswis, s/vdu/vduwrch - Lots of updates to deal with zero page relocation
  - s/ARM600 - UseProcessTransfer option. Zero page relocation support. Deleted pre-HAL ClearPhysRAM code to tidy the file up a bit.
  - s/ARMops - Zero page relocation support. Set CPUFlag_HiProcVecs when high vectors are in use.
  - s/KbdResPC - Disable compilation of dead code
  - s/VMSAv6 - UseProcessTransfer option. Zero page relocation support.
Admin:
  Tested with OMAP & Iyonix ROM softloads, both with high & low zero page.
  High zero page hasn't had extensive testing, but boot sequence + ROM apps seem to work.


Version 5.35, 4.79.2.98.2.48. Tagged as 'Kernel-5_35-4_79_2_98_2_48'

Detail:
  hdr/ARMops - Reserve OS_PlatformFeatures 0 bit 20 for indicating whether high processor vectors are in use
  s/Kernel - Add local definitions of BYTEWS, LDROSB, STROSB, VDWS macros (previously in Hdr:Macros)
  s/MoreComms - Fix potential buffer overflow when filling error buffer (although GSTrans shouldn't overflow the buffer in the first place?)
  s/Arthur2 - GSRead number detection fix
  s/ArthurSWIs - Updated OS_ReadUnsigned to support reading 64bit numbers
  Docs/ReadUnsigned - Docs for the updated OS_ReadUnsigned interface
Admin:
  Untested!
  Needs HdrSrc 1.86


Version 5.35, 4.79.2.120. Tagged as 'Kernel-5_35-4_79_2_120'

Detail:
  hdr/ARMops - Reserve OS_PlatformFeatures 0 bit 20 for indicating whether high processor vectors are in use
  s/Kernel - Add local definitions of BYTEWS, LDROSB, STROSB, VDWS macros (previously in Hdr:Macros)
  s/MoreComms - Fix potential buffer overflow when filling error buffer (although GSTrans shouldn't overflow the buffer in the first place?)
Admin:
  Tested on rev A2 BB-xM
  Requires HdrSrc 1.86


Version 5.35, 4.79.2.98.2.46. Tagged as 'Kernel-5_35-4_79_2_98_2_46'

Detail:
  hdr/ARMops - Amended ARMvF description to state that an ARMvF CPU can be ARMv6 or ARMv7
  s/ARMops - Move ARM11JZF_S CPUDesc to KnownCPUTable_Fancy, since it's ARMvF. Update ARM_Analyse_Fancy to detect whether ARMv6 or ARMv7 style cache control is in use, and react accordingly.
  s/HAL - Simplified system control register/MMUC initialisation. There are now just two types of setup - one for ARMv3-ARMv5 and one for ARMv6-ARMv7. Modified HAL_InvalidateCache_ARMvF to use the appropriate cache flush instructions depending on whether it's an ARMv6 or ARMv7 style cache.
Admin:
  S3C6410 and other ARMv6 machines should work now.
  Tested on BB-xM rev A2.


Version 5.35, 4.79.2.98.2.39. Tagged as 'Kernel-5_35-4_79_2_98_2_39'

Detail:
  Makefile - Added hdr.Variables to the C header export list
  hdr/ARMops, s/ARMops - Added ARM1176JZF-S to the list of known CPUs
  s/ARMops - Fix unaligned memory access in ARM_PrintProcessorType
  hdr/Copro15ops, s/ARMops, s/HAL, s/VMSAv6, s/AMBControl/memmap - Fixed all myDSB/myISB/etc. macro instances to specify a temp register, so that they work properly when building an ARMv6 version of the kernel
Admin:
  Fixes build errors with the latest Draw module.
  Should also allow the kernel to work properly with the new S3C6410 port.
  ARMv6 version builds OK, but no other builds or runtime tests have been made.


Version 5.35, 4.79.2.98.2.38. Tagged as 'Kernel-5_35-4_79_2_98_2_38'

Add support for Cortex cache type. Extend ARM_Analyse to, where appropriate, use CPU feature registers to identify CPU capabilities.

Detail:
  s/ARMops - Support for Cortex multi-level cache (CT_ctype_WB_CR7_Lx). New ARM_Analyse_Fancy to identify CPU capabilities using feature registers.
  s/HAL - Modify pre-ARMop cache code to handle Cortex-syle caches.
  s/MemInfo - Replace ARM_flush_TLB macro call with appropriate ARMop to provide Cortex compatability
  hdr/ARMops - Update list of ARM architectures
  hdr/CoPro15ops - Deprecate ARM_flush_* macros for HAL kernels, as they are no longer capable of flushing all cache types. ARMops should be used instead.
  hdr/KernelWS - Add storage space for multi-level cache properties required for new cache cleaning code.
Admin:
  Tested under qemu-omap3. Still unable to verify on real hardware due to lack of appropriate MMU code. However new OMAP3 HAL code that uses similar cache management functions appears to work fine on real hardware.


Version 5.35, 4.79.2.98.2.2. Tagged as 'Kernel-5_35-4_79_2_98_2_2'

Detail:
  hdr/ARMops - Added Cortex_A8 processor type, new ARM architecture number
  hdr/Options - Enabled various kernel debug options
  s/ARMops - Added Cortex-A8/OMAP3530 to known CPUs list. Ignore cache type register for ARM architecture &F.
  s/NewIRQs - Increase MaxInterrupts to 96
Admin:
  Brief testing under qemu-omap3.



Version 5.35, 4.79.2.98.2.1. Tagged as 'Kernel-5_35-4_79_2_98_2_1'

Version 5.35, 4.79.2.48. Tagged as 'Kernel-5_35-4_79_2_48'

IOMD HAL:
  enables fast clock for StrongARM on Medusa h/w

Kernel:
  ARMops for StrongARM implemented. Tested moderately on
  HAL/32-bit minimal desktop build for Risc PC. Could do
  with more testing later. eg. does reentrant cache
  cleaning support really work?
  Lazy task swapping is enabled for revT or later, wahey.

Version 5.35, 4.79.2.42. Tagged as 'Kernel-5_35-4_79_2_42'

more use of ARMops in page manipulation, change register usage of ARmops tested by kernel boot to star prompt only

Version 5.35, 4.79.2.11. Tagged as 'Kernel-5_35-4_79_2_11'

More stuff. Up to the desktop now; cache on, working keyboard. Some source restructuring to start to make splitting it up into several object files more feasible.