GitLab

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'

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'

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'

Detail:
  s/ARMops - Added extra LTORG to fix HiProcVecs build error for some platforms
  hdr/PublicWS - Remove the old (non-Legacy_) workspace exports, and add a comment explaining how the newer Legacy_ exports should be used.
Admin:
  HiProcVecs ROMs for various platforms now appear to build OK
  Untested at runtime


Version 5.35, 4.79.2.266. Tagged as 'Kernel-5_35-4_79_2_266'

The Cache_HALDevice is in the RAM clear skip table, so when there's no controller found and the kernel is doing the RAM clear it's unset, leading to probable aborts when typing *CACHE Om|Off.

Version 5.35, 4.79.2.259. Tagged as 'Kernel-5_35-4_79_2_259'

Detail:
  s/ARMops, s/HAL - Errata 814220 states that the Cortex-A7 set/way cache maintenance operations violate the usual operation ordering rules, such that an L2 maintenance operation which is started after an L1 operation may actually complete before it, causing data corruption if the L1 data was to be evicted to the L2 entry. Implement the suggested workaround of performing a DSB when switching cache levels, rather than just at the end of the combined L1+L2 group of operations.
Admin:
  Tested on Raspberry Pi 2


Version 5.35, 4.79.2.257. Tagged as 'Kernel-5_35-4_79_2_257'

Detail:
  s/ARMops - Implement Cache_RangeThreshold for PL310 (helps AMBControl to decide what type of TLB maintenance is best). Fix MMU_ChangingEntry_PL310 doing more work than is necessary; was attempting to flush all ways for a given address tag, when really it should have only been flushing all the lines within a page and letting the cache worry about the tags/indices they correspond to.
  s/ChangeDyn, s/VMSAv6, s/AMBControl/memmap - Do extra TLB maintenance following writes to the page tables, as mandated by the ARMv6+ memory order model. Fixes frequent crashes on Cortex-A9 when running with lazy task swapping disabled (and presumably fixes other crashes too)
  s/MemInfo - Fix OS_Memory cache/uncache so that it does cache/TLB maintenance on a per-page basis instead of a global basis. Vastly improves performance when you have a large cache, but may need tweaking again in future to do a global op if large numbers of pages are being modified.
Admin:
  Tested on Pandaboard


Version 5.35, 4.79.2.255. Tagged as 'Kernel-5_35-4_79_2_255'

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:
  s/ARMops - Replace the code to calculate the minimum cache line lengths with something much simpler which reads the values directly from the cache type register.
  The old code was buggy in two ways:
  (a) the cache size identification register stores the line length as log2(num words)-2, whereas the code throughout the kernel was expecting it to be log2(num bytes)-2
  (b) the loop is structured so that it will try and read the details of a non-existent cache level. although it doesn't read anything from CP15, it does result in the minimum cache line length values getting clobbered
  The net result of the above two bugs being that the OS would treat the CPU as if the minimum line length was just 4 bytes (although other than slowing down cache maintenance ops, this shouldn't have had any bad side-effects)
  The cache type register directly contains the minimum line lengths as log2(num bytes)-2, so by switching over to use that everything is now fine.
Admin:
  Tested on BB-xM, Pandaboard
  Fixes issue spotted by Willi Theiss


Version 5.35, 4.79.2.251. Tagged as 'Kernel-5_35-4_79_2_251'

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:
  s/ARMops - If extended pages aren't supported, make sure we use a PCBTrans table which doesn't use L2_X, otherwise the AP flags for some of the sub-pages will be corrupted when the PCB flags get merged in. Add some more comments to the PCBTrans tables so it's easier to see what the different columns are.
  s/ARM600 - Fix BangCam to use extended pages if they're supported; otherwise (assuming ARMops has selected the right PCBTrans table) we'll end up corrupting the AP flags again
  s/HAL - Fix ConstructCAMfromPageTables using the wrong register for ZeroPage when looking up MMU_PCBTrans. Correct a few comments.
Admin:
  Tested on Iyonix
  Page table examination now shows that all subpages have the correct (i.e. identical) AP flags. Previously some pages would have incorrect access (e.g. every 4th subpage in some FileCore disc map/dir buffer DAs were writable in user mode)
  ARMops fix will presumably mean extended pages will now work correctly on IOP 80200, as before it would have been using small pages with corrupt AP flags


Version 5.35, 4.79.2.221. Tagged as 'Kernel-5_35-4_79_2_221'

The StrongARM TRM (and hints from ARM600.s revision 4.3.2.2) show that the StrongARM will only do burst writes to memory marked as C=1 B=1, but by default RISCOS_AccessPhysicalAddress only allows bufferable.
So, checking for StrongARM first, two extra snippets are enabled - first mark as C=1 B=1, then afterwards clean the cache before moving onto the next 1MB.

On a StrongARM Kinetic these burst writes improve the RAM clear from ~60ms per MB to 40ms per MB. For a 256MB SODIMM that's over 5s knocked off the boot time.
Other memory configurations will be similarly improved, though 256MB is of course the maximum the motherboard can hold.

Tested in ROM on a Risc PC with StrongARM and ARM710.

Version 5.35, 4.79.2.189. Tagged as 'Kernel-5_35-4_79_2_189'

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'

Variously the call to TranslateError was either followed (outside the switch) by an unnecessary SETV, or missing SETV for the non international case.
Added DMA controller HAL device for IOMD.

Version 5.35, 4.79.2.174. Tagged as 'Kernel-5_35-4_79_2_174'

Detail:
  s/ARMops - Added branch predictor maintenance to WB_CR7_LDa ARMops. If the entire instruction cache is being invalidated then the branch predictors will be invalidated for us, but for ranged invalidation we need to handle it ourselves.
Admin:
  Tested briefly on Raspberry Pi with high processor vectors
  Appears to fix Configure and its plugins misbehaving in various ways


Version 5.35, 4.79.2.173. Tagged as 'Kernel-5_35-4_79_2_173'

Version 5.35, 4.79.2.149. Tagged as 'Kernel-5_35-4_79_2_149'

Detail:
  The cache details were previously fixed in a look-up table based upon the
  CPU as determined from the Main ID register for "fancy" ARMv6 CPUs (that is,
  ARMv6K, ARMv6Z, ARMv6T2). So the details for the S3C6410 were being used
  for all ARM1176JZF-S CPUs, which isn't correct for the BCM2835, which has
  the same CPU. Adrian's original stopgap solution was to override the
  settings with a bunch of MOV instructions, which had the effect of making
  the kernel useless on any other CPU. Now the details are read from the ARM
  cache type register for fancy ARMv6 CPUs. This necessitated adding support
  for an extra cache type: writeback, with cache cleaning using R7, and cache
  lockdown format C. Since we don't actually do cache lockdown, this follows
  the same code path as cache lockdown type A, which was originally written
  for ARM9 CPUs.
Admin:
  Tested in a Raspberry Pi build

Version 5.35, 4.79.2.147.2.2. Tagged as 'Kernel-5_35-4_79_2_147_2_2'

Detail:
  This is a new branch from the current tip of the HAL branch, incorporating
  the changes received from Adrian Lees. The same caveats apply - this is a
  work in progress and will not work on any other platform at present.
Admin:
  Builds, but not tested.

Version 5.35, 4.79.2.147.2.1. Tagged as 'Kernel-5_35-4_79_2_147_2_1'

Expand tabs.
Swap DCI for instructions now Objasm 4 is out.
Symbols for FSControl_CAT/RUN/OPT changed to non Arthur definitions.
Still boots on IOMD class, no other testing.

Version 5.35, 4.79.2.124. Tagged as 'Kernel-5_35-4_79_2_124'

Detail:
  s/ARMops - My previous checkin mistakenly changed Cache_InvalidateAll_WB_CR7_Lx so that it cleans and invalidates the cache instead of just invalidating it. This fixes that.
  Also fixed a warning caused by the trailing space going AWOL from the 'cache type register fields' comment.
Admin:
  Tested on rev A2 BB-xM


Version 5.35, 4.79.2.98.2.52. Tagged as 'Kernel-5_35-4_79_2_98_2_52'

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:
  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 - 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'

Detail:
  hdr/Options - ARM6support and GetKernelMEMC values are now derived from the value of MEMM_Type
  s/ARMops, s/HAL - Code to detect and handle ARMv7 CPUs is now only enabled when using VMSAv6 MMU model. Saves us from having to deal with lack of myIMB, myDSB, etc. implementations on pre-ARMv6.
  s/HAL - Removed some debug code
  s/NewReset - Fix bug spotted by Tom Walker where R12 wasn't being restored by LookForHALRTC if a non-HAL RTC had already been found
  s/AMBControl/memmap - correct the assert clause that was checking that &FFE are the correct L2PT protection bits for non-VMSAv6 machines
Admin:
  Tested this kernel on a rev C2 beagleboard & Iyonix softload. Also compiled it into an IOMD ROM, but didn't try running it.


Version 5.35, 4.79.2.98.2.32. Tagged as 'Kernel-5_35-4_79_2_98_2_32'

Detail:
  s/ARMops - Fixed an instance of 'invalidate branch predictor entry' that should have been 'invalidate all branch predictors'
  s/ChangeDyn - Avoid cleaning the Nowhere page when reallocating memory, to avoid incurring the performance hit of the abort handler, and to avoid AMBControl screwing things up by mapping in pages that we're trying to modify
  s/VMSAv6 - Move MVA cache/TLB abort handler to before ChocolateAMB code, to ensure AMBControl doesn't try mapping in pages for harmless cache/TLB op aborts. Also tweaked code to be a little bit faster.
Admin:
  Tested on rev C2 beagleboard. No more lockups when moving screen memory around, for now at least.


Version 5.35, 4.79.2.98.2.30. Tagged as 'Kernel-5_35-4_79_2_98_2_30'

Detail:
  s/ARMops - previous version of MMU_ChangingEntries_WB_CR7_Lx would behave improperly if cleaning the last page of the address map by neglecting to flush any more than one TLB entry
Admin:
  Untested!


Version 5.35, 4.79.2.98.2.28. Tagged as 'Kernel-5_35-4_79_2_98_2_28'

Update Cortex kernel to use correct instruction/memory barriers and to perform branch target predictor maintenance. Plus tweak default CMOS settings.

Detail:
  hdr/Copro15ops - Added myISB, myDSB, myDMB macros to provide barrier functionality on ARMv6+
  s/ARMops, s/HAL, s/VMSAv6, s/AMBControl/memmap - Correct barrier operations are now performed on ARMv6+ following CP15 writes. Branch predictors are now also maintained properly.
  s/NewReset - Change default CMOS settings so number of CDFS drives is 0 in Cortex builds. Fixes rogue CDFS icon on iconbar.
Admin:
  Tested on rev C2 beagleboard


Version 5.35, 4.79.2.98.2.27. Tagged as 'Kernel-5_35-4_79_2_98_2_27'

Detail:
  s/ARMops - Fix IMB_Range_WB_CR7_Lx to clean the correct number of cache lines
  s/HAL - Change CP15 control register flags so unaligned loads are enabled on ARMv6 (to simplify support for ARMv7 where unaligned loads are always enabled, and to match the behaviour expected by the example code in Hdr:CPU.Arch)
  s/AMBControl/memmap - Make AMB_LazyFixUp use the correct L2PT protection flags depending on ARM600/VMSAv6 MMU model. Also guard against problems caused by future L2PT flag changes.
  s/vdu/vdugrafj - Fix previously undiscovered 32bit incompatability in GetSprite (OS_SpriteOp 14/16)
Admin:
  Tested on rev C2 beagleboard


Version 5.35, 4.79.2.98.2.5. Tagged as 'Kernel-5_35-4_79_2_98_2_5'

Detail:
  s/ARMops - Fix set/way-based cache ops for cache type WB_CR7_Lx to iterate sets/ways/cache levels properly
  s/HAL - Fix HAL_InvalidateCache_ARMvF to iterate sets/ways/cache levels properly
Admin:
  Tested on rev C2 beagleboard


Version 5.35, 4.79.2.98.2.4. Tagged as 'Kernel-5_35-4_79_2_98_2_4'

Detail:
  s/ARM600 - fix to SyncCodeAreasRange to correctly read cache line length for WB_CR7_Lx caches
  s/ARMops - Cortex cache handling fixes. Enable L2 cache for Cortex.
  s/ChangeDyn - VMSAv6 support in AllocateBackingLevel2
  s/HAL - Improve RISCOS_InitARM to set/clear correct CP15 flags for ARMv6/v7. VMSAv6 support in code to generate initial page tables.
  s/NewReset - Extra DebugTX calls during OS startup. Disable pre-HAL Processor_Type for HAL builds.
  s/VMSAv6 - Main VMSAv6 MMU code - stripped down version of s/ARM600 with support for basic VMSAv6 features.
  hdr/Options - Use VMSAv6 MMU code, not ARM600. Disable ARM6support since current VMSAv6 code will conflict with it.
Admin:
  Tested basic OS functionality under qemu-omap3 and revision B6 beagleboard.


Version 5.35, 4.79.2.98.2.3. Tagged as 'Kernel-5_35-4_79_2_98_2_3'

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'

* Kernel puts sensible default FIQ handler in through the HAL.
* Fix to temporary page uncaching code.

Version 5.35, 4.79.2.30. Tagged as 'Kernel-5_35-4_79_2_30'

Version 5.35, 4.79.2.27. Tagged as 'Kernel-5_35-4_79_2_27'