GitLab

Detail:
  s/ChangeDyn:
    - Apply various optimisations to OS_ChangeDynamicArea to reduce the execution time when performing large grows/shrinks.
    - Optimisations can be toggled on/off with FastCDA_* flags for debugging.
    - On a 1GHz 512MB BB-xM, the initial *FreePool call now takes 0.15s instead of 13.46s. On a 512MB Iyonix the time has dropped from 1.18s to 0.23s.
    - Growing screen memory (on BB-xM) has also seen significant gains - between 2x and 4x speedup, depending on what state the source pages are in.
    - Added/updated documentation for a few functions and made more use of ROUTs for safety
  s/ARM600, s/VMSAv6:
    - Update BangCamUpdate, etc. to add support for the PageFlags_Unsafe flag that OS_ChangeDynamicArea uses to bypass cache/TLB maintenance in some situations
    - Avoid BangCamUpdate calling BangL2PT to map out the page if the page isn't mapped in (avoids unnecessary cache/TLB flush)
  s/ArthurSWIs:
    - Add extra ASSERT for safety
  s/AMBcontrol/memory
    - Fix incorrect assumption that the usable size of a heap block is always 8 less than the value stored in the header. Even with the old 8 byte aligned allocations the usable size will always be 4 bytes less than the value in the header. This code would have resulted in some slight memory wasteage, as AMBcontrol will have always tried growing the block four bytes bigger than needed.
Admin:
  Tested on Iyonix & BB-xM


Version 5.35, 4.79.2.146. Tagged as 'Kernel-5_35-4_79_2_146'

Detail:
  s/Arthur3, s/ChangeDyn, s/HAL, s/HeapMan, s/Middle, s/MoreSWIs, s/NewIRQs, s/Utility, s/VMSAv6, s/PMF/key, s/PMF/osbyte, s/PMF/osword, s/vdu/vdudecl, s/vdu/vdudriver, s/vdu/vduplot, s/vdu/vduwrch - Tweaked lots of LDM/STM instructions in order to get rid of the depracation/performance warnings
Admin:
  Tested on rev A2 BB-xM


Version 5.35, 4.79.2.98.2.53. Tagged as 'Kernel-5_35-4_79_2_98_2_53'

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:
  s/VMSAv6 - The code to detect aborting MVA ops now only runs if the aborting instruction wasn't located in application space.
  This is a workaround for an issue where:
  (a) The aborting instruction is in application space
  (b) The aborting instruction is attempting to access memory located in the same page as itself
  (c) That page is not mapped in (despite the fact that code is being executed from it)
  Originally attempting to load the aborting the instruction would have triggered another abort, causing AMBControl to map in the page and resume the first abort handler. The first abort handler would then have determined that it wasn't an MVA op and called AMBControl, only to be told by AMBControl that it wasn't a lazy fixup abort (even though it really was), thus triggering the abort environment handler.
  By ignoring instructions located in application space the second abort is avoided, allowing AMBControl to correctly process the abort.
Admin:
  Tested on rev A2 BB-xM.
  Fixes issue with DPScan crashing - http://www.freelists.org/post/davidpilling/DPScan-ARMini-crash
  Still need to determine how the ICache is able to become so out of sync with the DCache & page tables.


Version 5.35, 4.79.2.98.2.40. Tagged as 'Kernel-5_35-4_79_2_98_2_40'

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:
  Makefile - Now exports a C version of hdr.OSEntries, for use by the new HAL USB drivers
  s/GetAll, s/Kernel - The HALSize env variable is now used in place of hard-coded values for the HAL size
  s/HAL - Reset_IRQ_Handler now switches to SVC mode before calling HAL_KbdScanInterrupt, to allow the HAL USB drivers to re-enable interrupts if they wish.
  s/VMSAv6 - Deleted some obsolete definitions
Admin:
  Tested on rev C2 BB, A2 BB-xM, C1 TouchBook
  Needs latest BuildSys, Env, HdrSrc


Version 5.35, 4.79.2.98.2.37. Tagged as 'Kernel-5_35-4_79_2_98_2_37'

Detail:
  s/VMSAv6 - The code in DAbPreVeneer that checks for aborting MVA-based cache/TLB ops is now re-entrant.
  This is to cope with the "strange but true" case where a data abort was being triggered by a load/store
  instruction that itself was in an unmapped page.
Admin:
  Tested on rev C2 beagleboard. Fixes issue with StrongED crashing on load (see http://www.riscosopen.org/forum/forums/5/topics/453)
  Still need to work out why CPU was able to execute code from the unmapped page without triggering a prefetch abort (stale cache entries?)


Version 5.35, 4.79.2.98.2.31. Tagged as 'Kernel-5_35-4_79_2_98_2_31'

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'

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'

Update VDU HAL device for new OMAPVideo driver, fix MVA-based cache/TLB maintenance ops aborting on ARMv7, add warning to VDU driver about inconsistent state variables during screen mode changes

Detail:
  hdr/VideoDevice - removed Address2 and Device2 fields as it makes more sense for them to be in the device specific field (which for OMAP3 is a pointer to an OMAP3-specific struct)
  s/VMSAv6 - Modify data abort handler to ignore aborts that are generated by MVA-based cache/TLB maintenance ops. Unlike earlier ARM architectures, MVA-based ops can abort under ARMv7 if the page has no mapping to a physical address.
  s/vdu/vdudriver - Add a warning about VDU driver state variables (particularly CursorAddr) being left in invalid states during the execution of mode changes. This can cause problems if any attempt is made to output to the screen during the mode change (e.g. as a result of an abort)
Admin:
  Tested on rev C2 beagleboard. Video device changes mean that OMAP3 HAL 0.23 will be needed for ROM compilation to succeed.


Version 5.35, 4.79.2.98.2.24. Tagged as 'Kernel-5_35-4_79_2_98_2_24'

Detail:
 * Stopped calling the broken abort fixup code when running under VMSAv6.
   Might be desirable to update it, possibly farmed out to a separate module -
   still need to think about this.
 * Unaligned load optimisations can now be disabled by the global NoUnaligned
   flag for testing purposes.
 * Extended OS_ReadUnsigned to permit reading of 64-bit unsigned integers.
   See Docs.ReadUnsigned for more details. Also sped it up by using MLA
   (or UMLAL) for most digits rather than repeated addition.
 * Bugfix is OS_GSRead: an uninitialised r0 was being passed to
   OS_ReadUnsigned, causing undesirable effects on rare occasions.
Admin:
  Tested on a rev B7 beagleboard.

Version 5.35, 4.79.2.98.2.8. Tagged as 'Kernel-5_35-4_79_2_98_2_8'

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'