GitLab

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'

Version 5.35, 4.79.2.312. Tagged as 'Kernel-5_35-4_79_2_312'

Detail:
  s/MemInfo - Wrap OS_Memory 0 in some code which will temporarily claim the FIQ vector when making pages temporarily uncacheable, to avoid any issues caused by modern ARMs ignoring unexpected cache hits
  s/VMSAv6 - Claim FIQs when OS_MMUControl is asked to make a change to the SCTLR, to avoid similar issues on modern ARMs. Also make the stack temporarily uncacheable before disabling the cache, so that we don't run into any problems using the stack inbetween disabling the cache and completing the clean+invalidate.
Admin:
  Tested on Pi 2B, 3B
  *Cache off now works reliably on Pi 2B, although there is sometimes a pause of a few seconds while things sort themselves out (USB?)
  *Cache off "works" on Pi 3B but everything will fall over soon afterwards due to the Cortex-A53 not supporting LDREX/STREX to non-cacheable pages (or when the page is effectively non-cacheable, i.e. cacheable page with cache disabled)


Version 5.35, 4.79.2.311. Tagged as 'Kernel-5_35-4_79_2_311'

Detail:
  hdr/HALDevice - Reserve device IDs for BCM283x CPU clock device and GPU mailbox device
Admin:
  Tested on Raspberry Pi 1B/2B/3B


Version 5.35, 4.79.2.310. Tagged as 'Kernel-5_35-4_79_2_310'

Detail:
  (remove reference to SPIDevice in makefile)


Version 5.35, 4.79.2.309. Tagged as 'Kernel-5_35-4_79_2_309'

Version 5.35, 4.79.2.308. Tagged as 'Kernel-5_35-4_79_2_308'

Detail:
  s/MemInfo - To avoid cache coherency issues when the current SVC stack page is being made uncacheable, shift SP somewhere else by temporarily dropping into IRQ mode
  s/ARMops - Change default VMSAv6 cache policy to writeback, write allocate. Unlike other CPUs we've supported so far, Cortex-A53 suffers very badly from writes to read-allocate pages, with performance being roughly equivalent to writes to non-cacheable memory. Using a write (+read) allocate policy seems to be needed to get the expected performance, and may help boost other CPUs too.
Admin:
  Tested on IGEPv5, Pi 3


Version 5.35, 4.79.2.307. Tagged as 'Kernel-5_35-4_79_2_307'

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:
  s/HAL - Change RISCOS_AccessPhysicalAddress & RISCOS_ReleasePhysicalAddress (aka OS_Memory 14 & 15) to use the MMU_ChangingUncached ARMop instead of TLB_InvalidateEntry, as on ARMv6+ the MMU version ensures the write has been flushed to be visible by the TLB, while the TLB invalidate call doesn't.
  Fix RISCOS_MapInIO (aka OS_Memory 13) not detecting regions which have already been mapped in due to L1_XN flag masking issue. Also issue DSB+ISB after the page table write(s) to ensure it's visible by the TLB hardware.
Admin:
  Tested on IGEPv5


Version 5.35, 4.79.2.305. Tagged as 'Kernel-5_35-4_79_2_305'

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'

For disc based applications (ie. those that don't know the architecture at build time, like a ROM would) we have OS_PlatformFeatures to provide an abstract way of seeing when new chunks of instructions get added. Back at ARMv6 ARM deprecated SWP, but currently we have no way of knowing that at runtime without grubbing round the coprocessor registers.
Add 3 new flags
* One to say LDR/STREX is (not) available
* One to say that SWP/SWPB is (not) available
* One to say that CLREX and LDR/STREX[B|H|D] is (not) available
shame it took a few goes for ARM to bring in these variants, requiring 3 flags not 1.

Also:
Condition the exception on vector read code on No32bitCode, rather than just having it permanently disabled.
Improve the HAL device docs.

Tested on a StrongARM Risc PC, Model B Pi, and Titanium.

Version 5.35, 4.79.2.303. Tagged as 'Kernel-5_35-4_79_2_303'

The HAL device APIs are modelled around the C APCS, and furthermore can be implemented either in a HAL (with SB) or RISC OS module (with R12). Therefore, exporting SB or requiring its use as a function argument precludes implementing the device in a normal module.
For examples of how to keep track of SB for the HAL case, see AudC or BMU or CPUClk or DMA or GPIO or IDE or Mixer or RTC or SDHCI or CacheC devices, which typically keep it in their HAL workspace referenced relative to the device pointer passed in a1/R0.

Detail:
  s/vdu/vduswis - Fix conversion of mode specifier to mode string so that the X eigen value is only reported in the mode string if it was included in the mode specifier; previously was erroneously basing the decision on whether the Y eigen was specified, resulting in e.g. "EX4294967295" if only the Y eigen was included
  - Fix a stack imbalance causing the conversion of mode string to mode specifier crashing (typically with branch through zero) if an invalid eigen value is specified in the string (e.g. EX-1 as above)
Admin:
  Tested on Raspberry Pi


Version 5.35, 4.79.2.302. Tagged as 'Kernel-5_35-4_79_2_302'

Subreason 7 returns a string naming the HAL platform. Use HAL entry 97 to get this, and obsolete 97/98/99 in favour of using a HAL device. Line up the HAL video entries to match the others.
Subreason 6 is just back filling one ROL added, testing this on RISC OS Select just returned the OS name so we do the same now (same as subreason 0, not sure what ROL's distinction was for).
Allocate a HAL device for PATA IDE controllers, and the 2 known ones to date - Tungsten and IOMD systems.

Version 5.35, 4.79.2.301. Tagged as 'Kernel-5_35-4_79_2_301'

Detail:
  hdr/HALDevice - Allocate device IDs for iMX6 HDMI audio controller, and a generic software mixer
Admin:
  Tested in iMX6 ROM build


Version 5.35, 4.79.2.300. Tagged as 'Kernel-5_35-4_79_2_300'

Fix overriding of default CMOS settings. Reserve HAL device ID for the official Raspberry Pi touchscreen/display.

Detail:
  s/PMF/i2cutils - Move $CMOS_Override to the start of DefaultCMOSTable, so that it can be used to override values which are already in the table (since NVMemory_ResetValue stops its search on the first address match)
  hdr/HALDevice - Add new Touchscreen device type and reserve an ID for the official Pi touchscreen controller
Admin:
  Tested on Raspberry Pi
  Fixes filesystem incorrectly defaulting to ADFS


Version 5.35, 4.79.2.299. Tagged as 'Kernel-5_35-4_79_2_299'

Detail:
  Rather than fill the Kernel sources with an ever-increasing number of
  platform-specific switches to control the default CMOS settings, this
  change introduces a variable which passes the requirements direct from
  the Components file to the Kernel. Since it uses a comma-separated list
  of address/value pairs, it is inherently extensible. All the symbolic
  names of addresses from Hdr:CMOS are available, and any valid objasm
  expression can be used for the value.
Admin:
  This removes the need for the EnforceSCSI4 switch, and leaves almost
  no uses of the Machine variable in the Kernel either.


Version 5.35, 4.79.2.298. Tagged as 'Kernel-5_35-4_79_2_298'

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'

The kernel has no place holding this header export, since it doesn't use it nor implement any of its interfaces.

Version 5.35, 4.79.2.296. Tagged as 'Kernel-5_35-4_79_2_296'

Version 5.35, 4.79.2.295. Tagged as 'Kernel-5_35-4_79_2_295'

Detail:
  s/vdu/vdugrafj - Rewrite WritePaletteFromSprite to fix some issues with the logic which decides whether to change screen mode:
  - ModeNo was always being treated as if it was a mode selector block, causing bad pointer dereferences if it was actually a numbered mode. Prior to zero page protection the code would have eventually stumbled its way through to the mode change code.
  - For checking the pixel format, only the Log2BPP was being compared, resulting in code deciding that (e.g.) modes with differing RGB order were the same
  - However the eigen value checking was also broken (checking wrong part of generated mode selector block), causing the mode change logic to always be taken
  s/vdu/vdugrafdec - Increase size of SloadModeSel so it's actually large enough to hold the generated mode selector - old code would have run off the end a bit (thankfully, it was the last thing in that particular workspace block)
Admin:
  Tested on BB-xM, *ScreenLoad'ing sprites from various modes
  Fixes issue reported on forums:
  https://www.riscosopen.org/forum/forums/4/topics/3649


Version 5.35, 4.79.2.294. Tagged as 'Kernel-5_35-4_79_2_294'

Detail:
  s/ChangeDyn - Fix a couple of places where registers were being clobbered, preventing application space & shrinkable DA shrinking logic from being invoked correctly when performing a PMP PhysOp call
Admin:
  Tested on Raspberry Pi


Version 5.35, 4.79.2.293. Tagged as 'Kernel-5_35-4_79_2_293'

Detail:
  s/Middle - When handling an FIQ-mode exception, protect the register dump pointer around the call to HAL_FIQDisableAll
Admin:
  Tested on Raspberry Pi
  Fixes data abort within kernel when an abort occurs is FIQ mode


Version 5.35, 4.79.2.292. Tagged as 'Kernel-5_35-4_79_2_292'

Detail:
  s/ChangeDyn - A few fixes to make behaviour be a closer match for the pre-PMP code, and a bit of tidying to get rid of redundant code paths:
  - Remove shrinkable DA checks from AreaShrink - the source of the op is never the free pool, so TryToShrinkShrinkables wouldn't have done anything anyway
  - Fix ShrinkFreePoolToAppSpace to behave more like old OS_ChangeDynamicArea when it was asked to shrink the free pool - allow partial moves (if move amount too large to fit in app space), shrink shrinkables if free pool is unable to satisfy request, and call CheckAppSpace to make sure app space is OK with being changed
  - Remove redundant logic from AreaGrow for clamping grow size to free pool max size (if dest was free pool - dest will never be free pool with current implementation). "Dest is apl space, moving reduced amount" comment was also inaccurate.
  - Fix AreaGrow logic for taking memory from application space to only do so if the dest isn't application space (I can't see anything in the old implementation to protect against this - but, then again, the old implementation didn't seem to fully deal with grows of application space properly anyway, e.g. MemLimit would be updated on a free pool shrink, but not on an app space grow)
  - Add extra sanity check to AreaGrow after taking memory from application space
Admin:
  Tested on iMx6
  Fixes issue with application space having little or no memory if not booting to desktop (due to free pool shrink performed by kernel failing due to shrink amount being larger than app space max size)


Version 5.35, 4.79.2.291. Tagged as 'Kernel-5_35-4_79_2_291'

Detail:
  Default to SCSI::4 for boot driver is custom switch at buildtime
  (EnforceSCSI4) is defined. 2 fontcache items also defaulted with this switch
Admin:
  tested on iMx6


Version 5.35, 4.79.2.290. Tagged as 'Kernel-5_35-4_79_2_290'

Detail:
  s/PMF/IIC - when dealing with IIC transfers which use the high-level HAL API, take into account the bus speed when calculating the max retry count. Otherwise if (e.g.) writing to CMOS we may give up before the device has recovered from the previous write (which is typically listed as a max time of 5ms)
Admin:
  Fixes issues with CMOS checksum not being updated correctly if using IIC bus speeds > 100khz


Version 5.35, 4.79.2.289. Tagged as 'Kernel-5_35-4_79_2_289'

Detail:
  Ideally, $Machine would only exist within Hdr:Machine, they define a class of machines which in turn requires the lowest common denominator. It doesn't encode any capabilities about the class (eg. amount of memory, screen capabilities, peripherals).
Admin:
  Fixes report of Pandaboard no longer booting, since it has no drive 4.

Detail:
  default SCSIFSDrive to 4, and both FontMax and FontSize to their
  max values. (the machines in question have a min of 512Meg of ram -
  being miserly with font caches is unhelpful)
Admin:
  tested on iMx6

Version 5.35, 4.79.2.288. Tagged as 'Kernel-5_35-4_79_2_288'

Detail:
  s/ChangeDyn - Fix OS_DynamicArea 20 to work properly with sparse & PMP DAs. It now checks against the max extent of the area rather than the current size; this matches the logic used for checking fixed system workspace areas. The call only determines the ownership of a logical address, and it's considered the caller's responsibility to check if there's actually a page at the given address.
  s/ChangeDyn - Revise OS_DynamicArea 25 to remove the redundant 'PMP page flags' entry, and to allow pages to be looked up by either PMP page index, phys page number, or DA page index
  s/ChangeDyn - Tidy up InitDynamicAreas by adding the NextFreePage routine to help determine the next page to be added to the free pool.
  s/AMBControl/Workspace, s/AMBControl/main, s/AMBControl/memmap - Fix lazy mapping in of pages to use the correct L2PT flags for the default CB cache policy
  s/AMBControl/allocate - Get rid of magic constant when extracting page flags from DA flags, and make note of the fact that assorted bits of code ignore the flags
  s/AMBControl/growp, s/AMBControl/shrinkp - Reverse the page order when growing/shrinking areas, to match OS_ChangeDynamicArea. This helps both DAs and application space to have pages allocated to them in contiguous physical order - which in turn helps produce shorter, more optimal scatter lists for DMA
Admin:
  Tested on Pandaboard


Version 5.35, 4.79.2.287. Tagged as 'Kernel-5_35-4_79_2_287'

Detail:
  s/ChangeDyn - Differing zero page workspace layout between HiProcVecs {TRUE} and {FALSE} means the difference between FreePoolDANode being a valid 8 bit immediate constant or not. Just use a long-form LDR instead since the code in question isn't performance-critical.
Admin:
  Tested briefly under RPCEmu


Version 5.35, 4.79.2.286. Tagged as 'Kernel-5_35-4_79_2_286'

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'

  Removed errant tab characters from EtherDevice header
Detail:
Admin:


Version 5.35, 4.79.2.283. Tagged as 'Kernel-5_35-4_79_2_283'

Detail:
Admin:


Version 5.35, 4.79.2.282. Tagged as 'Kernel-5_35-4_79_2_282'

Detail:
  s/ARMops - In Analyse_WB_CR7_Lx, we need to check against Cache_Lx_MaxLevel*2, because the cache size selection register counts I + D caches separately
Admin:
  Tested on IGEPv5


Version 5.35, 4.79.2.281. Tagged as 'Kernel-5_35-4_79_2_281'

Detail:
  s/ARMops - Change VMSAv6 cache policy mapping so that default NCB policy maps to Normal, non-cacheable memory rather than Device memory. This allows unaligned accesses to work, and also delivers some major performance improvements for some activities (write performance seems about 2x better than Device)
  Docs/HAL/ARMop_API - Wrap the new barrier ARMop description text to match the rest of the file
Admin:
  Tested on ARM11, Cortex-A7, -A8, -A9
  Note - relaxed memory consistency rules for Normal vs. Device mean that now more than ever, developers authoring device drivers for ARMv6+ need to be careful to use memory barriers in all the right places (preferably the new ARMop barriers exposed by OS_MMUControl 2 to ensure compatibility with all machines)


Version 5.35, 4.79.2.280. Tagged as 'Kernel-5_35-4_79_2_280'

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'

Detail:
  s/TickEvents:
  - Change initial TickNodeLeft check in ProcessTickEventChain to exit on HI rather than NE. This fixes a case where the ticker event chain can become corrupted if ProcessTickEventChain is re-entered while in the middle of processing multiple nodes which are due to fire at the same time (after initial node is removed from the list, head node will be left with a TickNodeLeft value of 0)
  - Move "IRQ's off again" PSR write to be after the 10 label, to ensure that IRQs are off before we examine/process the next node (naughty CallEvery may have exited with IRQs enabled)
  - Stop using crusty old WritePSRc macro (currently generates 4 instructions for something that should be 1)
  - Also get rid of ARM2-era NOPs
  - Optimise CallEvery check to be MOVS rather than LDR + CMP
Admin:
  Tested on Pandaboard
  Should fix problem reported on forums with apparent wrap-around of TickNodeLeft value of first node: https://www.riscosopen.org/forum/forums/5/topics/3544
  May also fix other ticker corruption problems: https://www.riscosopen.org/forum/forums/4/topics/2708


Version 5.35, 4.79.2.278. Tagged as 'Kernel-5_35-4_79_2_278'

Detail:
Admin:


Version 5.35, 4.79.2.277. Tagged as 'Kernel-5_35-4_79_2_277'