GitLab

Detail:
  This change gets rid of the following switches from the source (picking appropriate code paths for a 32bit HAL build):
  * HAL
  * HAL26
  * HAL32
  * No26bitCode
  * No32bitCode
  * IncludeTestSrc
  * FixR9CorruptionInExtensionSWI
  Various old files have also been removed (POST code, Arc/STB keyboard drivers, etc.)
Admin:
  Identical binary to previous revision for IOMD & Raspberry Pi builds


Version 5.49. Tagged as 'Kernel-5_49'

Add new OS_PlatformFeatures reason code for reading CPU features (inspired by ARMv6+ CPUID scheme). Add OS_ReadSysInfo 8 flags for indicating the alignment mode the ROM was built with. Fix long-standing bug with OS_PlatformFeatures when an unknown reason code is used.

Detail:
  s/CPUFeatures, hdr/OSMisc, hdr/KernelWS - Code and definitions for reading CPU features and reporting them via OS_PlatformFeatures 34. All the instruction set features which are exposed by the CPUID scheme and which are relevant to RISC OS are exposed, along with a few extra flags which we derive ourselves (e.g. things relating to < ARMv4, and some register usage restrictions in instructions). s/CPUFeatures is designed to be easily copyable into a future version of CallASWI without requiring any changes.
  s/ARMops - Read and cache CPU features during ARMop initialisation
  s/GetAll - GET new file
  s/Kernel - Hook up the CPU features code to OS_PlatformFeatures. Fix a long standing stack imbalance bug (fixed in RISC OS 3.8, but never merged back to our main branch) which meant that calling OS_PlatformFeatures with an invalid reason code would raise an error, even if it was the X form of the SWI that was called. Similar fix also applied to the unused service call code, along with a fix for the user's R1-R9 being corrupt (shuffled up one place) should an error have been generated.
  s/MemInfo - Extra LTORG needed to keep things happy
  s/Middle - Extend OS_ReadSysInfo 8 to include flags for indicating what memory alignment mode (if any) the OS relies upon. Together with OS_PlatformFeatures 34 this could e.g. be used by !CPUSetup to determine which options should be offered to the user.
Admin:
  Tested on Raspberry Pi 1, 2, 3


Version 5.35, 4.79.2.319. Tagged as 'Kernel-5_35-4_79_2_319'

Detail:
  s/Kernel, hdr/KernelWS - Avoid performing error pointer checks for XOS_GenerateError, since (a) it's a no-op as far as errors are concerned, and (b) many programs take advantage of that fact and abuse the SWI for other purposes (triggering callbacks, BASIC string conversion, etc.)
Admin:
  Tested on Raspberry Pi
  Fixes issue reported on forums with Sunfish crashing:
  https://www.riscosopen.org/forum/forums/5/topics/4060


Version 5.35, 4.79.2.314. Tagged as 'Kernel-5_35-4_79_2_314'

Detail:
  Resources/UK/Messages, hdr/KernelWS, s/Kernel - On return from a SWI with V set, do some basic validity checks on the error pointer in order to try and catch buggy SWIs that return bad pointers or invalid error blocks. If a bad pointer is found we'll substitute it with a pointer to a different error block, which has the SWI number in the error message, to allow the user to identify the source of the problem. (There's also a chance we'll crash when investigating a bad pointer, but crashing here in the kernel is preferable to crashing elsewhere because R12 should still contain the SWI number)
  hdr/OSMisc - Define SeriousErrorV reason codes and extended ROM footer entry IDs
  hdr/Options - Remove HangWatch integration flag, obsolete now that SeriousErrorV is available
  s/ArthurSWIs - Keep defaultvectab up to date with vector allocations
  s/Middle - Update serious error handling to call SeriousErrorV at several key points. This allows for accurate crash dumps to be obtained, along with a mechanism to warn low-level components such as RTSupport that the privileged mode stacks are being flattened.
  s/Middle - Add OS_ReadSysInfo 15, for enumerating extended ROM footer entries
  s/PMF/osbyte - Update InitNewFX0Error to use the ROM footer entry ID defined in hdr/OSMisc
Admin:
  Tested on Pi 1B, 2B, 3B


Version 5.35, 4.79.2.313. Tagged as 'Kernel-5_35-4_79_2_313'

Detail:
  This set of changes tackles two main issues:
  * Before mapping out a cacheable page or making it uncacheable, the OS performs a cache clean+invalidate op. However this leaves a small window where data may be fetched back into the cache, either accidentally (dodgy interrupt handler) or via agressive prefetch (as allowed for by the architecture). This rogue data can then result in coherency issues once the pages are mapped out or made uncacheable a short time later.
    The fix for this is to make the page uncacheable before performing the cache maintenance (although this isn't ideal, as prior to ARMv7 it's implementation defined whether address-based cache maintenance ops affect uncacheable pages or not - and on ARM11 it seems that they don't, so for that CPU we currently force a full cache clean instead)
  * Modern ARMs generally ignore unexpected cache hits, so there's an interrupt hole in the current OS_Memory 0 "make temporarily uncacheable" implementation where the cache is being flushed after the page has been made uncacheable (consider the case of a page that's being used by an interrupt handler, but the page is being made uncacheable so it can also be used by DMA). As well as affecting ARMv7+ devices this was found to affect XScale (and ARM11, although untested for this issue, would have presumably suffered from the "can't clean uncacheable pages" limitation)
    The fix for this is to disable IRQs around the uncache sequence - however FIQs are currently not being dealt with, so there's still a potential issue there.
  File changes:
  - Docs/HAL/ARMop_API, hdr/KernelWS, hdr/OSMisc - Add new Cache_CleanInvalidateRange ARMop
  - s/ARM600, s/VMSAv6 - BangCam updated to make the page uncacheable prior to flushing the cache. Add GetTempUncache macro to help with calculating the page flags required for making pages uncacheable. Fix abort in OS_MMUControl on Raspberry Pi - MCR-based ISB was resetting ZeroPage pointer to 0
  - s/ARMops - Cache_CleanInvalidateRange implementations. PL310 MMU_ChangingEntry/MMU_ChangingEntries refactored to rely on Cache_CleanInvalidateRange_PL310, which should be a more optimal implementation of the cache cleaning code that was previously in MMU_ChangingEntry_PL310.
  - s/ChangeDyn - Rename FastCDA_UpFront to FastCDA_Bulk, since the cache maintenance is no longer performed upfront. CheckCacheabilityR0ByMinusR2 now becomes RemoveCacheabilityR0ByMinusR2. PMP LogOp implementation refactored quite a bit to perform cache/TLB maintenance after making page table changes instead of before. One flaw with this new implementation is that mapping out large areas of cacheable pages will result in multiple full cache cleans while the old implementation would have (generally) only performed one - a two-pass approach over the page list would be needed to solve this.
  - s/GetAll - Change file ordering so GetTempUncache macro is available earlier
  - s/HAL - ROM decompression changed to do full MMU_Changing instead of MMU_ChangingEntries, to make sure earlier cached data is truly gone from the cache. ClearPhysRAM changed to make page uncacheable before flushing cache.
  - s/MemInfo - OS_Memory 0 interrupt hole fix
  - s/AMBControl/memmap - AMB_movepagesout_L2PT now split into cacheable+non-cacheable variants. Sparse map out operation now does two passes through the page list so that they can all be made uncacheable prior to the cache flush + map out.
Admin:
  Tested on StrongARM, XScale, ARM11, Cortex-A7, Cortex-A9, Cortex-A15, Cortex-A53
  Appears to fix the major issues plaguing SATA on IGEPv5


Version 5.35, 4.79.2.306. Tagged as 'Kernel-5_35-4_79_2_306'

Detail:
  Raise the maximum number of interrupts and IIC buses acceptable, to account for the OMAP5 port.
  Add TLV320/TLV320/SDMA/SDMA/AM572x/GC320/CPSW/SynopsisDWC for Titanium.
  Add OMAP5/OMAP5/OMAP5/TWL6037/OMAP5/OMAP5/SynopsisDWC for OMAP5.
Admin:
  There's likely some rationalisation to be had here, these controllers especially across the OMAP3/4/5 are probably the same thing really and don't merit individual allocations.

Version 5.35, 4.79.2.297. Tagged as 'Kernel-5_35-4_79_2_297'

Detail:
  s/MemInfo - Remove OS_Memory 10 (free pool locking). Locking the free pool has never been a very nice thing to do, so now that there's no logical mapping of the free pool it seems like it's a good time to outlaw the behaviour altogether.
  s/ChangeDyn - No free pool locking means one less thing to check when claiming the OS_ChangeDynamicArea mutex.
  hdr/KernelWS - VRAMRescue_control workspace variable is no longer needed
Admin:
  Tested on Pandaboard


Version 5.35, 4.79.2.285. Tagged as 'Kernel-5_35-4_79_2_285'

Detail:
  This set of changes adds support for "physical memory pools" (aka PMPs), a new type of dynamic area which allow physical pages to be claimed/allocated without mapping them in to the logical address space. PMPs have full control over which physical pages they use (similar to DAs which request specific physical pages), and also have full control over the logical mapping of their pages (which pages go where, and per-page access/cacheability control).
  Currently the OS makes use of two PMPs: one for the free pool (which now has a logical size of zero - freeing up gigabytes of logical space), and one for the RAM disc (logical size of 1MB, allowing for a physical size limited only by the amount of free memory)
  Implementing these changes has required a number of other changes to be made:
  * The CAM has been expanded from 8 bytes per entry to 16 bytes per entry, in order to allow each RAM page to store information about its PMP association
  * The system heap has been expanded to 32MB in size (from just under 4MB), in order to allow it to be used to store PMP page lists (1 word needed per page, but PMP pages may not always have physical pages assigned to them - so to allow multiple large PMPs to exist we need more than just 1 word per RAM page)
  * The &FA000000-&FBFFFFFF area of fixed kernel workspace has been shuffled around to accomodate the larger CAM, and the system heap is now located just above the RMA.
  * SoftResets code stripped out (unlikely we'll ever want to fix and re-enable it)
  * A couple of FastCDA options are now permanently on
  * Internal page flags shuffled around a bit. PageFlags_Unavailable now publicly exposed so that PMP clients can lock/unlock pages at will.
  * When OS_ChangeDynamicArea is asked to grow or shrink the free pool, it now implicitly converts it into a shrink or grow of application space (which is what would happen anyway). This simplifies the implementation; during a grow, pages (or replacement pages) are always sourced from the free pool, and during a shrink pages are always sent to the free pool.
  File changes:
  - hdr/KernelWS - Extend DANode structure. Describe CAM format. Adjust kernel workspace.
  - hdr/OSRSI6, s/Middle - Add new item to expose the CAM format
  - hdr/Options - Remove SoftResets switch. Add some PMP switches.
  - s/ARM600, s/VMSAv6 - Updated for new CAM format. Note that although the CAM stores PMP information, BangCamUpdate currently doesn't deal with updating that data - it's the caller's responsibility to do so where appropriate.
  - s/ChangeDyn - Lots of changes to implement PMP support, and to cope with the new CAM format.
  - s/HAL - Updated to cope with new CAM format, and lack of logical mapping of free pool.
  - s/MemInfo - Updated to cope with new CAM format. OS_Memory 0 updated to cope with converting PPN to PA for pages which are mapped out. OS_Memory 24 updated to decode the access permissions on a per-page basis for PMPs, and fixed its HWM usage for sparse DAs.
  - s/NewReset - Soft reset code and unused AddCamEntries function removed. Updated to cope with new CAM format, PMP free pool, PMP RAMFS
  - s/AMBControl/allocate - Update comment (RMA hasn't been used for AMBControl nodes for a long time)
  - s/AMBControl/growp, s/AMBControl/memmap, s/AMBControl/shrinkp - Update for new CAM format + PMP free pool
  - s/vdu/vdudriver - Strip out soft reset code.
Admin:
  Tested on Pandaboard
  This is just a first iteration of the PMP feature, with any luck future changes will improve functionality. This means APIs are subject to change as well.


Version 5.35, 4.79.2.284. Tagged as 'Kernel-5_35-4_79_2_284'

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'

Improve support for VMSAv6 cache policies & memory types. Expose raw ARMops via OS_MMUControl & cache information via OS_PlatformFeatures.

Detail:
  Docs/HAL/ARMop_API - Document two new ARMops: Cache_Examine and IMB_List
  hdr/KernelWS - Shuffle workspace round a bit to allow space for the two new ARMops. IOSystemType now deleted (has been deprecated and fixed at 0 for some time)
  s/ARM600 - Cosmetic changes to BangCam to make it clearer what's going on. Add OS_MMUControl 2 (get ARMop) implementation.
  s/ARMops - Switch out different ARMop implementations and XCB tables depending on MMU model - helps reduce assembler warnings and make it clearer what code paths are and aren't possible. Add implementations of the two new ARMops. Simplify ARM_Analyse_Fancy by removing some tests which we know will have certain results. Use CCSIDR constants in ARMv7 ARMops instead of magic numbers. Update XCB table comments, and add a new table for VMSAv6
  s/ChangeDyn - Define constant for the new NCB 'idempotent' cache policy (VMSAv6 normal, non-cacheable memory)
  s/HAL - Use CCSIDR constants instead of magic numbers. Extend RISCOS_MapInIO to allow the TEX bits to be specified.
  s/Kernel - OS_PlatformFeatures 33 (read cache information) implementation (actually, just calls through to an ARMop)
  s/MemInfo - Modify VMSAv6 OS_Memory 0 cache/uncache implementation to use the XCB table instead of modifying L2_C directly. This allows the cacheability to be changed without affecting the memory type - important for e.g. unaligned accesses to work correctly. Implement cache policy support for OS_Memory 13.
  s/Middle - Remove IOSystemType from OS_ReadSysInfo 6.
  s/VMSAv6 - Make sure BangCam uses the XCB table for working out the attributes of temp-uncacheable pages instead of manipulating L2_C directly. Add OS_MMUControl 2 implementation.
  s/AMBControl/memmap - Update VMSAv6 page table pokeing to use XCB table
  s/PMF/osinit - Remove IOSystemType reference, and switch out some pre-HAL code that was trying to use IOSystemType.
Admin:
  Tested on Iyonix, ARM11, Cortex-A7, -A8, -A9, -A15
  Note that contrary to the comments in the source the default NCB policy currently maps to VMSAv6 Device memory type (as per previous kernel versions). This is just a temporary measure, and it will be switched over to Normal, non-cacheable once appropriate memory barriers have been added to the affected IO code.


Version 5.35, 4.79.2.273. Tagged as 'Kernel-5_35-4_79_2_273'

Expose more areas via OS_ReadSysInfo 6 & OS_Memory 16. Expose processor vectors base + size via OS_PlatformFeatures.

Detail:
  hdr/KernelWS - Define processor vectors address. Currently same as ZeroPage, but in the future will differ for some machines.
  hdr/OSRSI6, s/Middle - Expose VecPtrTab & NVECTORS via OS_ReadSysInfo items 85 & 86
  s/Kernel - Add OS_PlatformFeatures 32, for returning the base + size of the processor vectors
  s/MemInfo - Add areas 12 thru 15 to OS_Memory 16, for reporting ZeroPage, ProcVecs, DebuggerSpace and ScratchSpace. The task manager can now use these for calculating memory usage instead of assuming 32K workspace from &0-&8000.
Admin:
  Tested on Raspberry Pi


Version 5.35, 4.79.2.271. Tagged as 'Kernel-5_35-4_79_2_271'

Detail:
  This set of changes adds support for rendering software mouse pointers directly in the kernel, rather than requiring graphics drivers to render them themselves as was the case previously.
  If a driver returns from GraphicsV_Features with the 'hardware pointer' bit clear, and a call to GraphicsV_UpdatePointer is returned unclaimed, then the kernel will step in and render a software pointer. This allows selective control over which areas of the screen the software pointer is used (e.g. if hardware only supports its use in some areas)
  hdr/KernelWS - Shrink PointerXEigFactor to 1 byte to free up some space for tracking the display log2bpp. Use 8 words of space for tracking software pointer state.
  s/vdu/vducursoft - Adjust existing the existing calls to the software pointer RemovePointer/RestorePointer functions so that they're called with IRQs enabled
  s/vdu/vdudriver - Keep track of display log2bpp. Claim/release memory needed for restoring pixels under software pointer.
  s/vdu/vdugrafhal - Update HAL_VideoUpdatePointer handling so that 0 can be returned in a1 to indicate the GraphicsV call should be left unclaimed.
  s/vdu/vdupalxx - Trigger updates of the cached software pointer palette whenever it's likely to become invalidated.
  s/vdu/vdupointer - Add software pointer implementation. Relying on a SpriteExtend OS_SpriteOp would be nice, but we're in the background so have to do plotting & unplotting manually. ColourTrans is used to cache the pointer palette colours for the current mode, although we're limited to calling it from a callback.
Admin:
  Tested on Raspberry Pi & BB-xM
  Pointer is very flickery under some circumstances (e.g. running !CloseUp) due to needing to plot/unplot around any VDU driver screen access (as per text cursor). So code may need revising in future once we can trap reads/writes from specific screen memory pages.


Version 5.35, 4.79.2.269. Tagged as 'Kernel-5_35-4_79_2_269'

Detail:
  Unlike on the Cortex-A8 or Cortex-A15, the L2 cache that's used with the Cortex-A9 isn't hooked up to the standard ARMv7 CP15 cache maintenance ops. Instead, memory-mapped registers must be used to program and maintain the cache.
  Since the PL310 can't be detected automatically, this change adds support for a 'cache controller' HAL device which the HAL can use to advertise the presence of any external caches. If a cache device is registered during HAL_InitDevices the kernel will then check it against a list of known cache types and replace the appropriate ARMop routines with the alternatives for that controller.
  File changes:
  - hdr/PL310 - New header containing PL310 register listing
  - Makefile - Add export for PL310 header. Reorder exports to be alphabetical
  - hdr/HALDevice - Add cache controller device type, PL310 device
  - hdr/KernelWS - Allocate some workspace for storing a pointer to the current cache HAL device
  - s/ARMops - Add code for searching for known cache types, and implementation of PL310-specific ARMops
  - s/GetAll - Get Hdr:PL310
  - s/NewReset - Look for a cache controller after calling HAL_InitDevices
Admin:
  Tested on Pandaboard
  Fixes various assorted instability issues


Version 5.35, 4.79.2.252. Tagged as 'Kernel-5_35-4_79_2_252'

Detail:
  hdr/KernelWS - Enlarge the SkippedTables area to encompass IICBus_Base
  s/PMF/IIC - Manually set IICBus_Status of each bus to 0 within IICInit
Admin:
  Bug was introduced in Kernel-5_35-4_79_2_168 when IIC initialisation was moved to earlier in the ROM init sequence, but has gone unnoticed due to it only really affecting the high-level API (and none of the relevant HALs were relying on the kernel for the RAM clear)
  Tested on BB-xM with kernel RAM clear


Version 5.35, 4.79.2.236. Tagged as 'Kernel-5_35-4_79_2_236'

Add OS_Memory 24 implementation. Change OS_ValidateAddress to use it. Fix kernel leaving the physical access MB in a messy state. Try and protect against infinite abort loops caused by bad environment handlers.

Detail:
  s/MemInfo - Added an implementation of ROL's OS_Memory 24 call. Unlike the old OS_ValidateAddress call, this call should successfully report the presence of all memory areas known to the kernel. It should also correctly indicate which parts of a sparse DA are mapped in, unlike the old OS_ValidateAddress implementation.
  s/ChangeDyn - Update dynamic area handling to construct a lookup table for mapping logical addresses to dynamic areas; this is used by OS_Memory 24 to quickly locate which DA(s) hit a given region
  s/AMBControl/main - Make sure lazy task swapping is marked as disabled when AMB_LazyMapIn is {FALSE} - required so that OS_Memory 24 will give application space the correct flags
  s/ArthurSWIs - Switch OS_ValidateAddress over to using OS_Memory 24, as per ROL. For compatibility, Service_ValidateAddress is still issued for any areas which the kernel doesn't recognise (currently, OS_Memory 24 doesn't issue any service calls itself)
  s/Convrsions - ADR -> ADRL to keep things happy
  s/HAL - Fix L2PT page allocation and RAM clear to release the physical access region once they're done with it
  s/Kernel - Make the error dispatcher validate the error handler code ptr & error buffer using OS_Memory 24 before attempting to use them. If they look bad, reset to default. Should prevent getting stuck in an infinite abort loop in some situations (e.g. as was the case with ticket 279). The system might not fully recover, but it's better than a hard crash.
  s/Middle - Rework data/prefetch/etc. abort handlers so that DumpyTheRegisters can validate the exception dump area via OS_Memory 24 before anything gets written to it. Should also help to prevent some infinite abort loops. Strip 26bit/pre-HAL code to make things a bit more readable.
  hdr/KernelWS - Update comment
Admin:
  Tested on BB-xM, Raspberry Pi


Version 5.35, 4.79.2.222. Tagged as 'Kernel-5_35-4_79_2_222'

ClearPhysRAM runs after ARM_Analyse and would wipe out the RAM copies of the various CP15 registers defining which caches are present, leading to the IMB_Full and IMB_Range operations skipping most of their job.
Space freed below DebuggerSpace by moving the RAM copies of the processor vectors up a bit.
Tested with a nobbled HAL which doesn't do the RAM clear, inspecting the workspace in a debugger to see it's preserved (only affects VSMAv6 models).

Version 5.35, 4.79.2.214. Tagged as 'Kernel-5_35-4_79_2_214'

Detail:
  This set of changes:
  * Adds basic support for multiple GraphicsV drivers, by way of some new OS_ScreenMode reason codes for registering/deregistering, selecting and enumerating drivers (11, 64-68)
  * Tidies up handling of HAL video calls so that the HAL calls will be transformed into a bona fide GraphicsV driver if they're implemented
  * Changes handling of 16bpp gamma table entries so that they're sent to GraphicsV in a generic form instead of in a VIDC-specific form
  * Adds a new GraphicsV call and defines new VIDC list items to allow GraphicsV drivers to utilise the new pixel formats
  File changes:
  * h/VIDCList, hdr/VIDCList, Makefile - Add new header export containing VIDC list type 3 definitions, to avoid repeated definitions in other components
  * Resources/UK/Messages - Add new GraphicsV/OS_ScreenMode error strings and some missing processor type strings
  * hdr/KernelWS - Clean up some pre-GraphicsV definitions, and add new workspace locations for storing the current GraphicsV driver number and the driver list
  * hdr/Options - Remove obsolete InverseTextTransparency option
  * hdr/VduExt - Add VDU variable 192 for storing GraphicsV driver number (same as ROL's VideoV driver number). Remove old 'Flag_*' mode flag definitions (use new 'ModeFlag_*' defintions instead). Add new OS_ScreenMode reason codes.
  * s/ARM600, s/VMSAv6, s/vdu/vdu23, s/vdu/vdugrafa, s/vdu/vdugrafd, s/vdu/vdupalxx, s/vdu/vdupointer, s/vdu/vduwrch - Strip out pre-GraphicsV code. Update GraphicsV code to use correct driver number.
  * s/ArthurSWIs - Pass the default GraphicsV claimant the VduDriverWorkSpace instead of ZeroPage
  * s/Getall - Add Hdr:VIDCList and s/vdu/VduGrafHAL to list of GETs
  * s/NewIRQs - Remove HAL VSync IRQ initialisation, is now handled by grafvhal. Remove old HAL VsyncIRQ entry point, all VSyncs are now handled by VsyncIRQ_ExtEntry.
  * s/PMF/osbyte - Stop OS_Byte 19 waiting forever if no video driver is active
  * s/PMF/osinit - Remove HAL VSync IRQ initialisation, is now handled by grafvhal
  * s/vdu/vducursoft - Use new workspace variable names and flag names
  * s/vdu/vdudecl - Remove old HALDAG_* definitions, GVDAG_* definitions are used instead. Add definition of the per-driver workspace structure and flags.
  * s/vdu/vdudriver - Remove pre-GraphicsV code. Update InitialiseMode to check for and initialise a HAL driver. Use cached driver features word in a few places instead of calling GraphicsV each time. Update PalIndexTable to disable VIDC mangling of 16bpp gamma tables.
  * s/vdu/vdugrafv, s/vdu/vdugrafhal - HAL<->GraphicsV code split off into its own file (vdugrafhal). Default GraphicsV claimant now only deals with VSync events for the active driver.
  * s/vdu/vdumodes - Get rid of old VIDC List type 3 definiton; now in hdr/VIDCList
  * s/vdu/vduswis - Added OS_ScreenMode reason codes 11 and 64-68 for registering, deregistering, selecting and enumerating GraphicsV drivers. Update mode set code to not bother checking if the driver supports the pixel format; instead we assume that the driver's vet mode call will do the check for us.
Admin:
  Tested in Tungsten, IOMD, OMAP3 & BCM2835 ROMs
  Requires HdrSrc-2_38 and updated video driver modes


Version 5.35, 4.79.2.203. Tagged as 'Kernel-5_35-4_79_2_203'

The kernel will use RTC_Read and RTC_Write to access the hardware clock, while maintaining the software clock as before.
Makefile: header export is now in the RTC module's sources
KernelWS: remove RTCFitted flag
NewReset: sync the time after the module init
i2cutils: deleted clock chip code
osinit: move OS_ResyncTime into PMF/realtime
realtime: mostly packages up ordinals and calls the respective SWI

Tested on IOMD softload.

Version 5.35, 4.79.2.202. Tagged as 'Kernel-5_35-4_79_2_202'

Add support for the new RISC OS 5 style sprite mode word. Add partial support for alpha channel sprite masks. Implement OS_ScreenMode reasons 13-15

Detail:
  ECFShift/ECFYOffset:
  - hdr/PublicWS - Add ECFShift and ECFYOffset to list of public exports (SpriteExtend was using hardcoded values). Rearrange exports so that VduWorkspace exports are now labelled as such.
  - hdr/KernelWS - Make sure ECFShift & ECFYOffset match their exported locations
  - hdr/OSRSI6, s/Middle - Add OS_ReadSysInfo 6 items 83 & 84, for reading ECFYOffset and ECFShift locations
  Mode flags/VDU variables:
  - Makefile - Add hdr/VduExt to the C header exports
  - hdr/VduExt - Get rid of NotRVVTBarWobblyBits macro and defined VDU variables manually so that Hdr2H will handle them. Begin replacing overly generic 'Flag_*' mode flag definitions with 'ModeFlag_*' instead. Define new flags as required by the new screen/sprite modes. Add OS_ScreenMode reason codes and mode selector format (from s.vdu.vdudecl)
  - NewModes/NEWF2, NewModes/OldPSSrc, NewModes/PSSrc, s.vdu.vdu23, s.vdu.vducursoft, s.vdu.vdudriver, s.vdu.vdugrafg, s.vdu.vdugrafj, s.vdu.vdugrafl, s.vdu.vdumodes, s.vdu.vdupal10, s.vdu.vdupal20, s.vdu.vdupalette, s.vdu.vdupalxx, s.vdu.vduwrch - Renaming Flag_* to ModeFlag_*
  - s.vdu.vdudecl - Remove OS_ScreenMode reason codes & mode selector format definitions; these are now in hdr/VduExt. Flag_* -> ModeFlag_* renaming.
  - s.vdu.vdupalxx - Apply a greyscale palette in PV_SetDefaultPalette if the greyscale mode flag is set
  New sprite types:
  - s.vdu.vdudriver - Extend GenerateModeSelectorVars to deal with the wide mask flag, 64K sprites, and the new RISC OS 5 sprite mode word format.
  - s.vdu.vdugrafdec - Store more information about the sprite in the SprReadNColour ... SprLog2BPC block.
  - s.vdu.vdugrafg - Update SpriteVecHandler to be able to detect whether RISC OS 5 format sprites are allowed palettes. Update SetupSprModeData to store the extra sprite info that's defined in vdugrafdec. Update PutSprite to fault any sprites with wide masks - SpriteExtend must be used for that (once implemented!)
  - s.vdu.vdugrafh - Update WritePixelColour to avoid temporary poking of NColour VDU variable for 8bpp sprites. Correctly replicate data when writing to RISC OS 5 format sprites. Update ReadPixelMask, WritePixelMask, SpriteMaskAddr, GetMaskspWidth to deal with wide masks. Delete obsolete bounce_new_format_masks routine.
  - s.vdu.vdugrafi - Comment updated to reflect new reality
  - s.vdu.vdugrafj - Get rid of unused code block in CreateHeader/PostCreateHeader. Update SanitizeSGetMode to generate RISC OS 5 style sprite mode words where applicable. Update DecideMaskSize to rely on GetMaskspWidth for calculating mask width.
  - s.vdu.vdugrafl - Update SwitchOutputToSprite/SwitchOutputToMask to deal with the new sprite formats. Allow PushModeInfoAnyMonitor to fail.
  - s.vdu.vduswis - Extended OS_ReadModeVariable to cope with new sprite types
  Misc:
  - s.vdu.vdudriver - Fixed bug with VIDCList copying where any -1 value in the structure would terminate the copy, instead of only -1 as a control item number
  - s.vdu.vduswis - Implemented OS_ScreenMode 13 (Mode string to specifier), 14 (mode specifier to string), and 15 (set mode by string). Mostly as per ROL's specs, but minus support for teletext attributes, and plus support for new RISC OS 5 attributes (L... layout specifier, 4096 & 24bpp packed modes, etc.)
  - s.vdu.vduwrch - Pick correct default text colours for the new modes
Admin:
  Tested on BB-xM
  Part of an implementation of the Extended Framebuffer Format spec:
  http://www.riscosopen.org/wiki/documentation/show/Extended%20Framebuffer%20Format%20Specification


Version 5.35, 4.79.2.194. Tagged as 'Kernel-5_35-4_79_2_194'

GPIODevice: defines for OMAP4 targets
KernelWS: bump up the IICBus_Count from 3 to 4

Version 5.35, 4.79.2.187. Tagged as 'Kernel-5_35-4_79_2_187'

Detail:
  Briefly, this set of changes:
  * Adjusts PhysRamTable so that it retains the flags passed in by the HAL from OS_AddRAM (by storing them in the lower 12 bits of the size field)
  * Sorts the non-VRAM entries of PhysRamTable by speed and DMA capability, to ensure optimal memory allocation during OS startup.
  * Adjust the initial memory allocation logic to allow the cursor/sound chunk and HAL noncacheable workspace to come from DMA capable memory
  * Extends OS_Memory 12 to accept a 'must be DMA capable' flag in bit 8 of R0. This is the same as available in ROL's OS.
  * Extends OS_DynamicArea 0 to allow the creation of dynamic areas that automatically allocate from DMA capable memory. In ROL's OS this was done by setting bit 12 of R4, but we're using bits 12-14 for specifying the cache policy, so instead bit 15 is used.
  * Fixes OS_ReadSysInfo 6 to return the correct DevicesEnd value now that the IRQ/device limit is computed at runtime
  File changes:
  * hdr/OSEntries - Add definitions of the various flags passed to OS_AddRAM by the HAL. Add a new flag, NoDMA, for memory which can't be used for DMA.
  * hdr/KernelWS - Tidy PhysRamTable definition a bit by removing all the DRAM bank definitions except the first - this makes it easier to search for code which is interacting with the table. Remove VRAMFlags, it's redundant now that the flags are kept in the table. Add DMA allocation info to InitWs.
  * s/AMBControl/memmap - Updated to mask out the flags from PhysRamTable when reading RAM block sizes.
  * s/ARM600 - Strip out a lot of IOMD specific pre-HAL code.
  * s/ChangeDyn - Updated to cope with the flags stored in PhysRamTable. Implement support for DMA-capable dynamic areas. Rewrite InitDynamicAreas to insert pages into the free pool in the right order so that the fastest memory will be taken from it first.
  * s/GetAll, s/Middle - Fix OS_ReadSysInfo 6 to return the correct HAL-specific DevicesEnd value
  * s/HAL - Significant rework of initial RAM allocation code to allow the kernel workspace to come from the fastest DMA incapable RAM, while also allowing allocation of DMA capable memory for HAL NCNB workspace & kernel cursor/sound chunks. ClearPhysRAM rewritten as part of this.
  * s/MemInfo - Updated to cope with the flags stored in PhysRamTable. Add support for the new OS_Memory 12 flag. Update OS_Memory 7 to not assume PhysRamTable entries are sorted in address order, and rip out the old pre-HAL IOMD implementation.
  * s/NewReset - Remove GetPagesFromFreePool option, assume TRUE (as this has been the case for the past 10+ years). Revise a few comments and strip dead code. Update to cope with PhysRamTable flags.
  * s/VMSAv6 - Remove a couple of unused definitions
  * s/vdu/vdudriver - Update to cope with PhysRamTable flags
Admin:
  Tested in Kinetic RiscPC ROM softload, Iyonix softload, & OMAP3


Version 5.35, 4.79.2.186. Tagged as 'Kernel-5_35-4_79_2_186'

SystemName, ROMSizeOffset, HAL32, HAL26 only used here, moved here.
Remove uses of "M_" booleans, apparently that's bad form.
Fix SWIDespatch_Size for the non thumb capable case (was ASSERTing).
Swapped UserMemStart for AppSpaceStart.
Removed last use of OldComboSupport (pre Medusa!).
Removed switch 'CDVPoduleIRQs', a correction to the machine definitions mean this can now simply be switched on NumberOfPodules (previously, IOMD couldn't chain podule interrupts).
Take out disabled sub interrupt support - it's in CVS if you want to try to get it working.
Moved ConfiguredLang to 11 for everyone, it only matters if !Boot fails, and no harm in making it common for 5.xx onwards.

Version 5.35, 4.79.2.183. Tagged as 'Kernel-5_35-4_79_2_183'

Add new HAL call, HAL_IRQMax, to allow the kernel to determine the number of IRQ lines/devices at runtime

Detail:
  hdr/HALEntries - Reuse the old HAL_MonitorLeadID call number for HAL_IRQMax
  hdr/KernelWS - Rearrange CursorChunkAddress workspace a bit. Removed unused OldOscliBuffs and a couple of pre-HAL allocations, and made DefIRQ1Vspace the same size for all build configs. Add an IRQMax var to zero page workspace to cache the value returned by HAL_IRQMax.
  s/HAL - Initialise IRQMax shortly after HAL initialisation. Revise ClearPhysRAM comment to reflect which vars are preserved in the current version of the code.
  s/NewIRQs - Strip out a fair bit of pre-HAL code to make the file more readable. Update OS_ClaimDeviceVector/OS_ReleaseDeviceVector to check against IRQMax instead of the MaxInterrupts compile-time limit.
Admin:
  Tested on BB-xM, Iyonix, RiscPC, Pi
  Although the OS will now nominally adapt at runtime to how many IRQ devices there are, it's still using MaxInterrupts as an upper limit as the device claimant table has a fixed memory allocation.


Version 5.35, 4.79.2.182. Tagged as 'Kernel-5_35-4_79_2_182'

Permits applications to query what value would be used in the event of a CMOS reset for a given configure value. Notably, the configure plugins will use this in favour of 'ResetCMOS'.
hdr/Options: retire the 'Select16BitSound' switch, add comment for ChecksumCMOS switch
hdr/KernelWS: DuffEntry and Nowhere moved here
Kernel.s: Unused OSMD removed, retire single use of SPIRQ in favour of r13_irq
Middle.s: Retire SPIRQ
NewReset.s: Trim out 300+ lines of CMOS reset defaults, call OS_NVMemory 6 instead
PMF/i2cutils.s: CMOS reset default code and table moved here with refactoring
Note, the previous code preserved YearCMOS during the zeroing, only to unconditionally write it later - so have removed it from the zeroing step.
Note, the locations 80-111 are now considered as system CMOS in the allocations hence are now wiped too (previously they got skipped as user CMOS during R-power-on).

Tested on OMAP3 ROM with delete-power-on and R-power-on variants, and a simple BASIC program to read locations 0-255 via OS_NVMemory.

Version 5.35, 4.79.2.180. Tagged as 'Kernel-5_35-4_79_2_180'

Fix addresses sent to GraphicsV_SetDMAAddress when external framestore in use. Add ID for BCM2835 VDU HAL device.

Detail:
  hdr/KernelWS, s/vdu/vdudriver, s/vdu/vduwrch - Fixed wrong addresses being sent to GraphicsV_SetDMAAddress when an external framestore is in use. Previously VideoPhysAddr was being treated as if it was the base of screen memory, but that's only the case if an internal framestore is in use. Since VideoPhysAddr is part of PhysRamTable it's not possible to change it to point to an external framestore, so a new workspace variable, TrueVideoPhysAddr, is used instead.
  hdr/HALDevice - Added device ID for BCM2835 VDU device
  s/PMF/IIC - Corrected an incorrect comment in IICDoOp
Admin:
  Tested on Raspberry Pi with high processor vectors


Version 5.35, 4.79.2.147.2.22. Tagged as 'Kernel-5_35-4_79_2_147_2_22'

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'

NewReset.s:
The one remaining use of SetBorder was to denote the user asked for and got a CMOS reset, which in the HAL case emitted a warning because setting the border is potentially complicated/slow.
To solve this, the reset is noted and replaces the normal RISC OS banner with a warning message. The behaviour and text for this comes from the BBC Master, though the escape key is used in place of break since a reset isn't actually needed.
Moved the unused cputable inside its corresponding switch.
Two occurrences of WriteS_Translated would have executed the message in the V=1 case.
KernelWS/Resources:
Flag added to workspace, translation added to messages files.
Heapman.s:
Commented out use of SetBorder removed.
Kernel.s:
SetBorder macro removed.
Middle.s:
Switched out use of SetBorder removed.
Super1.s:
Conditional WriteS_Translated would try to execute the message in the opposite condition case.


Version 5.35, 4.79.2.157. Tagged as 'Kernel-5_35-4_79_2_157'

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'

While the HAL and kernel were being split some temporary macros were used for the bits being worked on, after 12 years of use they're probably safe to adopt.
mjsCallHAL -> CallHAL; mjsAddressHAL -> AddressHAL; mjsHAL -> HAL.
OS_VIDCDividerSWI code now always does NoSuchSWI (had been switched out previously).
File vduhint.s no longer assembled (was empty).


Version 5.35, 4.79.2.150. Tagged as 'Kernel-5_35-4_79_2_150'

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'

Detail:
  hdr/Copro15ops:
    - Fixed incorrect encodings of ISH/ISHST variants of DMB/DSB instructions
  s/ARMops, s/HAL, hdr/KernelWS:
    - Replace the ARMv7 cache maintenance code with the example code from the ARMv7 ARM. This allows it to deal with caches with non power-of-two set/way counts, and caches with only one way.
    - Fixed Analyse_WB_CR7_Lx to use the cache level ID register to work out how many caches to query instead of just looking for a 0 result from CSSIDR.
    - Also only look for 7 cache levels, since level 8 doesn't exist according to the ARMv7 ARM.
  s/NewReset:
    - Removed some incorrect/misleading debug output
Admin:
  Tested on rev A2 BB-xM


Version 5.35, 4.79.2.98.2.51. Tagged as 'Kernel-5_35-4_79_2_98_2_51'

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:
  s/Middle - Added some new OS_ReadSysInfo 6 items which are needed by the zero page relocation kernel. Also duplicated some existing entries to avoid conflicts with ROL's allocations.
  hdr/OSRSI6, Makefile - New header listing OS_ReadSysInfo 6 items
  hdr/PublicWS - Duplicated the workspace definitions for &0-&4000, but with a 'Legacy_' prefix to their names. Also added some new entries as needed by the zero page relocation kernel. Once existing modules have been updated to use OS_ReadSysInfo 6 & the Legacy_ definitions, the old defs will be removed.
  hdr/KernelWS - Removed 'Export_' prefix from all the exported workspace values, since the kernel can now use the original names directly
  hdr/Options - Dummy HiProcVecs option so merging things will be a bit cleaner
Admin:
  Tested on rev A2 BB-xM


Version 5.35, 4.79.2.98.2.44. Tagged as 'Kernel-5_35-4_79_2_98_2_44'

Detail:
  s/Middle - Added some new OS_ReadSysInfo 6 items which are needed by the zero page relocation kernel. Also duplicated some existing entries to avoid conflicts with ROL's allocations.
  hdr/OSRSI6, Makefile - New header listing OS_ReadSysInfo 6 items
  hdr/PublicWS - Duplicated the workspace definitions for &0-&4000, but with a 'Legacy_' prefix to their names. Also added some new entries as needed by the zero page relocation kernel. Once existing modules have been updated to use OS_ReadSysInfo & the Legacy_ definitions, the old defs will be removed.
  hdr/KernelWS - Removed 'Export_' prefix from all the exported workspace values, since the kernel can now use the original names directly
  hdr/Options - Dummy HiProcVecs option so merging things will be a bit cleaner
Admin:
  Tested in ROM softload on Iyonix


Version 5.35, 4.79.2.118. Tagged as 'Kernel-5_35-4_79_2_118'

Detail:
  Three main changes:
  * On odd-numbered (i.e. development) versions of the module, the UtilityModule will now take its date from the VersionNum file instead of using a hard-coded date
  * All build versions now look for the new "extended ROM footer" (as created by romlinker 0.04+) at the end of the ROM image and use it to determine the ROM build date for return by OS_ReadSysInfo 9,2. Failing to find the build date in the footer will cause OS_ReadSysInfo 9,2 to return 0.
  * On odd-numbered versions, OS_Byte 0 will now use the ROM build date (as found in the extended footer) to generate the error block that's returned to the user. This seems OK as the PRM describes OS_Byte 0 as returning the "creation date of the operating system". Plus it's a convenient way of getting the ROM build date into the Switcher, since the switcher uses OS_Byte 0. If the extended footer can't be found (or if the string isn't initialised yet, e.g. before Service_PostInit) the code falls back to a hard-coded string containing the date from the VersionNum file.
  File changes:
  Makefile - Updated to not create the obsolete Time+Date file (previously used for the ROM build date)
  Version - Use date from VersionNum file for development builds
  hdr/Options - New UseNewFX0Error variable/option to make it easy to check which OS_Byte 0 variant should be enabled
  hdr/KernelWS - Added new string buffers & extended ROM footer pointer to workspace
  s/Middle - Updated OS_ReadSysInfo 9 code, and added utility functions for searching the extended ROM footer for certain tags
  s/NewReset - Added a couple of calls to initialise the new string buffers just prior to Service_PostInit. This is required since OS_Byte/OS_ReadSysInfo shouldn't enable interrupts, but date conversion relies on the Territory module, which may enable interrupts.
  s/PMF/osbyte - Updated OS_Byte 0 code
Admin:
  Tested in Tungsten ROM, with and without the extended footer present.


Version 5.35, 4.79.2.115. Tagged as 'Kernel-5_35-4_79_2_115'

Detail:
  Three main changes:
  * On odd-numbered (i.e. development) versions of the module, the UtilityModule will now take its date from the VersionNum file instead of using a hard-coded date.
  * All build versions now look for the new "extended ROM footer" (as created by romlinker 0.04+) at the end of the ROM image and use it to determine the ROM build date for return by OS_ReadSysInfo 9,2. Failing to find the build date in the footer will cause OS_ReadSysInfo 9,2 to return 0.
  * On odd-numbered versions, OS_Byte 0 will now use the ROM build date (as found in the extended footer) to generate the error block that's returned to the user. This seems OK as the PRM describes OS_Byte 0 as returning the "creation date of the operation system". Plus it's a convenient way of getting the ROM build date into the Switcher, since the switcher uses OS_Byte 0. If the extended footer can't be found (or if the string hasn't been initialised yet, e.g. before Service_PostInit) the code falls back to a hard-coded string containing the date from the VersionNum file.
  File changes:
  Makefile - Updated to not create the obsolete Time+Date file (previously used for the ROM build date)
  Version - Use date from VersionNum file for development builds
  hdr/Options - New UseNewFX0Error variable/option to make it easy to check which OS_Byte 0 variant should be enabled
  hdr/KernelWS - Added new string buffers & extended ROM footer pointer to workspace
  s/Middle - Updated OS_ReadSysInfo 9 code, and added utility functions for searching the extended ROM footer for certain tags
  s/NewReset - Added a couple of calls to initialise the new string buffers just prior to Service_PostInit. This is required since OS_Byte/OS_ReadSysInfo shouldn't enable interrupts, but date conversion relies on the Territory module, which may enable interrupts.
  s/PMF/osbyte - Updated OS_Byte 0 code
Admin:
  Tested in OMAP ROM, with and without the extended footer present.


Version 5.35, 4.79.2.98.2.41. Tagged as 'Kernel-5_35-4_79_2_98_2_41'

Detail:
  OS_IICOp (and in turn, RISCOS_IICOpV) now treat the top byte of R1 as containing the IIC bus number, allowing multiple buses to be used.
  hdr/KernelWS - Changed workspace a bit so that the kernel can support up to IICBus_Count buses (currently 3), each with its own IICBus_* block.
  s/HAL - Update Reset_IRQ_Handler to cope with interrupts from all IIC buses instead of just the first. Fix/update RISCOS_IICOpV description.
  s/NewIRQs - Update InitialiseIRQ1Vtable to set up interrupt handlers for all IRQ-supporting IIC buses
  s/NewReset - Get rid of the IICAbort call that was just before IICInit. IICInit now calls IICAbort itself.
  s/PMF/IIC - Bulk of the changes. Code now uses the IICBus_ structures instead of the IICStatus and IICType variables. Re-entrancy code has been updated to take into account the possiblity of multiple buses; when OS_IICOp calls are nested, the IIC transfers will be added to bus-specific queues instead of all going in the same queue. However only one queue will be processed at a time.
  s/ChangeDyn - Workspace shuffling means a couple of MOV's needed to be swapped with LDR's when getting immediate constants
Admin:
  Tested with OMAP & IOMD ROM builds.
  Both high & low-level bus types seem to work OK, along with re-entrancy, both on the same bus and on a different bus.


Version 5.35, 4.79.2.98.2.33. Tagged as 'Kernel-5_35-4_79_2_98_2_33'

Detail:
  HAL kernels (on the Cortex branch at least) now support HALDevice-based RTCs. If the kernels own RTC code is disabled or fails to detect an RTC, then after HAL_InitDevices is called the HALDevice list will be scanned for any HAL-resident RTC devices.
  Additionally, the RTCSupport flag (in Hdr:Machine.Machine), which was previously TRUE for all HAL kernels, can now be set to FALSE in HAL kernels to disable the kernels own IIC RTC code. This allows the unwanted legacy RTC code to be disabled for machines which are known to use HAL RTCs instead.
  hdr/RTCDevice - new header describing data structures used for HAL RTC device
  hdr/HALDevice - added RTCDevice device type, IIC serial bus type
  hdr/KernelWS - upgraded RTCFitted from a 1 byte field to 4 byte. It now stores either a null value (for no RTC), a value <2048 for an IIC RTC address, or a value >= 2048 for a RTCDevice ptr
  Makefile - added header export of hdr/RTCDevice
  s/GetAll - include hdr/RTCDevice
  s/NewReset - initialise HAL RTC after HAL_InitDevices if required
  s/PMF/i2cutils, s/PMF/osinit, s/PMF/osword - modifications to allow use of HAL RTC (and disallow use of builtin IIC RTC)
Admin:
  Tested on rev C2 beagleboard


Version 5.35, 4.79.2.98.2.11. Tagged as 'Kernel-5_35-4_79_2_98_2_11'

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:
  174: left border size
  175: bottom border size
  176: right border size
  177: top border size
Admin:
  Not tested.

Version 5.35, 4.79.2.68. Tagged as 'Kernel-5_35-4_79_2_68'