1. 21 Feb, 2018 1 commit
    • Jeffrey Lee's avatar
      Make it easier to debug aborts that were triggered by ABT/UND code · ed1b4b5b
      Jeffrey Lee authored
      Detail:
        s/Middle - Tweak register dump generation so that it'll attempt to provide sensible R13 & R14 values if the abort came from the same mode that we're handling the abort in. R13 will be adjusted by however much data we've pushed onto the stack, and R14 will be set to &DEADDEAD to indicate that the CPU has corrupted it and we don't know what the original value was.
      Admin:
        Tested on BB-xM
      
      
      Version 5.98. Tagged as 'Kernel-5_98'
      ed1b4b5b
  2. 11 Feb, 2018 1 commit
    • Robert Sprowson's avatar
      Adapt A15 KnownCPUFlags to account for LDREX and friends · 5bc10832
      Robert Sprowson authored
      When SyncLib-0_04 is used in conjunction with SDIODriver, the exclusive access instructions (instead of SWP) abort when the cache is off, causing the machine to hang if *Cache Off is used.
      See A15 TRM section 6.4.5 for the logic.
      Copy the A53's known CPU flags to prevent the D cache being turned off.
      
      Version 5.97. Tagged as 'Kernel-5_97'
      5bc10832
  3. 04 Feb, 2018 1 commit
    • Jeffrey Lee's avatar
      Fix some pointer colour issues. Fix PaletteV 6 (blank screen) return value. · 96e8fff1
      Jeffrey Lee authored
      Detail:
        s/vdu/vdudriver - On startup, initialise all palettes to 0, not just Pal_Blank. Ensures that entries which might not always be explicitly initialised (e.g. pointer) are self-consistent. Also make sure InitialiseMode communicates the pointer palette to the new GV driver, since some components tend to program it in a lazy manner (e.g. Hourglass)
        s/vdu/vdupalxx - Fix UpdateAllPalette setting R4 to 0 on exit. Fix PV_BlankScreen R0 return value to be 0/1 as the comment suggests instead of always being 0 due to GraphicsV calls.
      Admin:
        Tested on wandboard
        Fixes incorrect hourglass colours after reset, due to software RAM clear not wiping the kernel's palette (kernel + Hourglass thought old colours were still in use, but IMXVideo hadn't been told any colours yet so was using defaults of 0)
      
      
      Version 5.96. Tagged as 'Kernel-5_96'
      96e8fff1
  4. 03 Feb, 2018 1 commit
    • Robert Sprowson's avatar
      Recover gracefully from a completely blank set of CMOS · 1033074e
      Robert Sprowson authored
      Newly born boards have all 0xFF's in their CMOS (EEPROM), but the new order of keyboard scan did
        Init -> Scan keyboard -> Check (or wipe) CMOS
      and would therefore leave 0xFF's in a select few kernel workspace areas and OS_Byte values.
      Defer the init which reads CMOS until after the check/wipe step. Only the screen area size is now done early, but MassageScreenSize clamps that properly anyway.
      
      Arthur3.s: Relocate stranded function SetupPrinterBuffer to osinit.
      PMF/key.s: Drop support for SoftReset.
      PMF/osinit.s: Stuff in hardcoded defaults at early init. Retrieve the proper ones later. Take ownership of SystemSprite/RamFS/Font Manager dynamic areas (deferrable).
      vdudriver.s: Use symbolic name.
      NewReset.s: Defer SystemSprite/RamFS/Font Manager area creation, MouseInit, Read(Hard)CMOSDefaults until later.
      hdr/Options: Delete unused IgnoreVRAM. Remove MaxRAMFS_Size now PMPs make it not useful. Shuffle ARM6Support/XScaleMiniCache/XScaleJTAGDebug to be adjacent to their definitions.
      
      Tested by filling first 256 bytes with 0xFF and powering up. Reset now completes, OS_Byte variables look sensible.
      
      Version 5.95. Tagged as 'Kernel-5_95'
      1033074e
  5. 26 Jan, 2018 1 commit
    • Jeffrey Lee's avatar
      Teletext fixes · 155897b8
      Jeffrey Lee authored
      Detail:
        s/vdu/vdugrafl - Disable hardware scrolling if we're in a teletext mode with a border. Quick fix in lieu of adding some code to make sure the relevant border areas are cleared when scrolling.
        s/vdu/vduttx - Ignore VDU 23,18,<n> sequences when outside of teletext. Fixes a crash when screen update suspend/resume sequences are used.
      Admin:
        Tested on RiscPC
      
      
      Version 5.94. Tagged as 'Kernel-5_94'
      155897b8
  6. 08 Dec, 2017 1 commit
    • Robert Sprowson's avatar
      Unplug/RMInsert with podule module fix · 7b7cb6d9
      Robert Sprowson authored
      During the first pass keyboard scan the ROM module nodes are built off the anchor ROMModuleChain.
      During the second pass the whole set of ROM module nodes are temporarily constructed anchored on the stack, then switched over.
      This caused a problem when a duplicate name module was encountered on a podule (eg. MbufManager in a NIC) because FindROMModule searches from the ROMModuleChain anchor, didn't find a match, so created a new node rather than linking it to the NewerVersion/OlderVersion linked list on the existing node.
      Then *Unplug and *RMInsert would say "Module is not in ROM" if the optional podule specifier was given, because the search stopped at the first node with the right name.
      
      Swap round the second pass so it anchors directly on ROMModuleChain, and keeps the first pass anchor on the stack (needed only occasionally to copy over details of modules already initialised).
      
      Tested on a Risc PC with NIC, can now selectively unplug MbufManager again.
      
      Version 5.93. Tagged as 'Kernel-5_93'
      7b7cb6d9
  7. 02 Dec, 2017 1 commit
    • Jeffrey Lee's avatar
      Fix 2x output stream redirection bugs · 101d144f
      Jeffrey Lee authored
      Detail:
        s/Oscli:
        - Reorder RemoveOscliCharJobs to avoid WrchV being left claimed while the output stream is being closed, to resolve ticket #420.
        - Register usage also tweaked a bit to make the code a bit shorter & easier to read
        - Fix RedirectWrch to deal with errors correctly. PSR save/restore macros were added to the routine during the 32bit conversion process, but (a) they were inadvertantly causing all errors to be ignored, and (b) they were redundant since WrchV has no special in/out requirements for the PSR flags
      Admin:
        Tested on Pandaboard
        Ticket #420 fix based around Colin's fix from https://www.riscosopen.org/forum/forums/4/topics/5269
      
      
      Version 5.92. Tagged as 'Kernel-5_92'
      101d144f
  8. 12 Nov, 2017 1 commit
    • Jeffrey Lee's avatar
      Fix initial OS_ResyncTime to occur before Service_PostInit · a5c907f8
      Jeffrey Lee authored
      Detail:
        s/NewReset - In Kernel-5_89, the initial OS_ResyncTime call was erroneously moved to after Service_PostInit, which had the side-effect of causing TerritoryManager's initial evaluation of AutoDST rules to be performed using an uninitialised RTC, with varying side effects depending on the user's timezone (e.g. UK stuck in DST all year round due to lack of BST in 1970). Move the call back to its original location so that TerritoryManager and any other PostInit claimants can see the correct time.
      Admin:
        Tested in Iyonix ROM
        Resolves ticket #441
      
      
      Version 5.91. Tagged as 'Kernel-5_91'
      a5c907f8
  9. 07 Oct, 2017 1 commit
    • Jeffrey Lee's avatar
      Tweak handling of zero page compatibility page · 36062ff5
      Jeffrey Lee authored
      Detail:
        s/MemInfo, hdr/KernelWS - Rather than peeking L2PT to determine if the compatibility page is enabled, use a workspace var to track its state. This ensures we won't get confused if other software decides to map something of its own to &0.
        s/NewReset - Ensure the CompatibilityPageEnabled flag is initialised correctly
      Admin:
        Tested in Iyonix ROM softload
      
      
      Version 5.90. Tagged as 'Kernel-5_90'
      36062ff5
  10. 09 Sep, 2017 1 commit
    • ROOL's avatar
      Change module initialisation to be a two pass scheme · ac1ea0f5
      ROOL authored
      Detail:
        To make it easier to support arbitrary complexity keyboard controllers (eg. USB via DWCDriver on the Pi) have the kernel do the early keyboard recovery key press detection instead of the HAL.
        During the first pass those modules used for reading the keyboard are started, ignoring the CMOS frugal bits.
        The keyboard is then scanned for 3s, during which time the RAM is cleared (unless the HAL indicated it has already been done).
        During the second pass the remaining modules are started respecting the CMOS frugal bits. Any which were already started in the first pass are inserted into the new chain, so the keyboard is reset once and only once.
      
        Boot times, with a 300cs key scan time in NewReset.
        Risc PC with 160MB RAM (128+32+0).
        Times from turning on power to initial "beep", using a stopwatch.
                      RISC OS 3.70 RISC OS 5.22 This OS
        ARM610        12.5         10.4         10.3
        ARM710        11.8         10.2         9.7
        StrongARM 233 11.1         9.5          8.4
      
        In NewReset.s:
        Remove old KbdScan code (leave Reset_IRQ_Handler for IIC only)
        If HAL_KbdScanDependencies returns a null string then present KbdDone flag and skip to full init.
        A few vestiges of soft resets removed.
        Do RAM clear when waiting for INKEY (being careful not to trash the running modules...).
        Clearing just the freepool on a 2GB Titanium cleared 7EFD6 pages (99.2%).
      
        In ModHand.s:
        2nd pass need to sneaky renumber the nodes (so *ROMModules is in the right order, frugal bits line up) without resetting the chain
      
        In HAL.s:
        Change ClearPhysRAM to ClearWkspRAM, such that it only clears the kernel workspace rather than all RAM. The bulk of the RAM is cleared during the keyboard scan by new function ClearFreePoolSection.
        Add a variant of Init_MapInRAM which clears the mapped in RAM too (as these very early claims will not be in the free pool when the RAM is cleared later).
        Remove HAL keyboard scan setup & IRQ handler.
        Fix bug in HALDebugHexTX2, the input value needs pre-shifting by 16b before continuing.
      
        In GetAll.s, PMF/osbyte.s:
        Use Hdr:Countries and Hdr:OsBytes for constants.
      
        In PMF/key.s, PMF/osinit.s:
        Relocate the key post init from PostInit to KeyPostInit.
        Changed PostInit to not tail call KeyPostInit so they can be called independently.
      
        In hdr/KernelWs:
        Improve comments, add InitWsStart label to refer to.
      
        In hdr/HALEntries:
        Add HAL_KbdScanDependencies.
        Delete KbdFlag exports.
        Took the opportunity to reorder some of the higher numbered HAL entries and re-grouping, specifically (112,120) (84,106,108,117).
      Admin:
        Tested on an ARM6/ARM7/SA Risc PC, BeagleBoard xM, Iyonix, Pandaboard ES, Wandboard Quad, IPEGv5, Titanium, Pi 2 and 3.
        Requires corresponding HAL change.
        Submission for USB bounty.
      
      Version 5.89. Tagged as 'Kernel-5_89'
      ac1ea0f5
  11. 27 Aug, 2017 1 commit
  12. 25 Aug, 2017 1 commit
  13. 19 Aug, 2017 1 commit
    • Jeffrey Lee's avatar
      Add a compatibility page zero for high processor vectors / zero page relocation builds · ffac5791
      Jeffrey Lee authored
      Detail:
        When HiProcVecs is enabled, there will now be a read-only page located at &0 in order to ease compatibility with buggy software which reads from null pointers
        Although most of the page is zero-filled, the start of the page contains a few words which are invalid pointers, discouraging dereferencing them, and a warning message if the memory is interpreted as a string.
        On ARMv6+ the page is also made non-executable, to deal with branch-through-zero type situations
        OS_Memory 20 has been introduced as a way of determining whether the compatibility page is present, and also to enable/disable it
        File changes:
        - hdr/Options - Add CompatibilityPage option
        - hdr/OSMem - Declare OS_Memory reason code 20
        - hdr/KernelWS - When CompatibilityPage is enabled, make sure nothing else is located at &0
        - s/NewReset - Enable compatibility page just before Service_PostInit (try and keep zero-tolerance policy for null pointer dereferencing during ROM init)
        - s/MemInfo - OS_Memory 20 implementation. Add knowledge of the compatibility page to OS_Memory 16 and 24.
      Admin:
        Tested on BB-xM
      
      
      Version 5.87. Tagged as 'Kernel-5_87'
      ffac5791
  14. 18 Jul, 2017 1 commit
  15. 18 Jun, 2017 1 commit
    • ROOL's avatar
      Fix to OS_ReadSysInfo 1 · 698e5e6d
      ROOL authored
      Detail:
        Prior to ScreenModes starting (when CurrentMonitorType becaomes 7) this SWI would return Auto as 31 for EDID rather than -1, as would be the case had ReadMultiField been called.
        Change to use -1 for consistency and so it gets translated to type 3 (VGA).
      Admin:
        Submission from Willi Theiss.
      
      Version 5.85. Tagged as 'Kernel-5_85'
      698e5e6d
  16. 15 Jun, 2017 1 commit
    • Jeffrey Lee's avatar
      Fix software pointer when ExtraBytes is in use · 03b66d46
      Jeffrey Lee authored
      Detail:
        s/vdu/vdupointer - The software pointer code was calculating LineLength manually, due to previous kernel versions not storing a copy of the value that would be safe to use during screen redirection.
        Fix the code to use the new DisplayLineLength variable, so that the software pointer will be correct in modes which have row padding.
      Admin:
        Tested on Raspberry Pi 3
      
      
      Version 5.84. Tagged as 'Kernel-5_84'
      03b66d46
  17. 13 Jun, 2017 1 commit
    • Jeffrey Lee's avatar
      Tweak OS_ReadModeVariable optimisations · af1f546b
      Jeffrey Lee authored
      Detail:
        s/vdu/vduswis - Don't use RMVForCurrentMode when R0 = ModeNo, only use it if R0 is -1. This ensures that results for explicitly-specified modes will always represent the base properties of the mode and won't be influenced by any unusual properties of the current mode, e.g. LineLength/ScreenSize alterations caused by driver-specific framebuffer padding.
      Admin:
        Tested on Raspberry Pi 3
      
      
      Version 5.83. Tagged as 'Kernel-5_83'
      af1f546b
  18. 07 Jun, 2017 1 commit
    • Jeffrey Lee's avatar
      Initial support for the ExtraBytes VIDC control list item · 90cc1d38
      Jeffrey Lee authored
      Detail:
        The ExtraBytes control list item can be used to add padding between framebuffer rows.
        When the kernel sees a VIDC list containing this item, it will now adjust the LineLength and ScreenSize mode variables accordingly, with the end result that the correct amount of memory will be allocated for the framebuffer and the OS will render into it correctly.
        Files changed:
        - hdr/KernelWS - Add DisplayLineLength variable to allow the correct LineLength value to be preserved when screen output is redirected to a sprite
        - s/vdu/vdudriver - Make ModeChangeSub initialise DisplayLineLength before calling SwitchOutputToSprite. Update PushModeInfo to take ExtraBytes into account when calculating LineLength and ScreenSize.
        - s/vdu/vdugrafl - Adjust SwitchOutputToSprite to use DisplayLineLength when restoring screen output
        - s/vdu/vduwrch - Fix full-screen CLS to not write to the padding bytes
      Admin:
        Tested on Raspberry Pi 3
      
      
      Version 5.82. Tagged as 'Kernel-5_82'
      90cc1d38
  19. 03 Jun, 2017 1 commit
  20. 05 Mar, 2017 1 commit
    • ROOL's avatar
      Extend MonitorType configure keyword · 4d017eb3
      ROOL authored
      Detail:
        Accept a monitortype of 'EDID' (as distinct from 'Auto', which uses the ID pins) to force the kernel, via ScrModes, to use the native screen mode prior to executing the boot sequence.
        Required for discless boot, this also helps if the boot sequence fails, the desktop will be entered in the monitor's native resolution, or a fallback if GraphicsV rejects that.
        The allocation of the EDID monitor type has been carefully selected to degrade to 'Auto' when used with an older OS. That way the configuration in CMOS is safe to use with softloads on top of older physical ROMs.
        When OS_ScreenMode is queried return the 'Auto' type, ie. at an API level there's no distinction.
      Admin:
        Requires HdrSrc-2_67.
        Submission for the EDID bounty.
      
      Version 5.80. Tagged as 'Kernel-5_80'
      4d017eb3
  21. 17 Feb, 2017 1 commit
    • Jeffrey Lee's avatar
      Streamline PL310 ARMops · 79699513
      Jeffrey Lee authored
      Detail:
        Some closer examination of the PL310 TRM reveals that there's no need to poll for completion of maintenance operations if we only use atomic ops.
        Since there's no particular need for us to use the background ops, just rewrite everything to use the atomic ops and get rid of the polling.
        This should also avoid the need for any costly locking in SMP setups.
        File changes:
        - s/ARMops - Updated as above
      Admin:
        Tested on Pandaboard, iMx6
      
      
      Version 5.79. Tagged as 'Kernel-5_79'
      79699513
  22. 11 Feb, 2017 1 commit
    • Jeffrey Lee's avatar
      Fix incorrect OS_SynchroniseCodeAreas call · f1802d76
      Jeffrey Lee authored
      Detail:
        s/Arthur2 - When installing a code system variable, a register fumble resulted in OS_SynchroniseCodeAreas being called with a bogus address range. Fix it.
      Admin:
        Tested on Pandaboard
      
      
      Version 5.78. Tagged as 'Kernel-5_78'
      f1802d76
  23. 09 Feb, 2017 1 commit
    • Robert Sprowson's avatar
      Expose CLREX via OS_PlatformFeatures · a7892833
      Robert Sprowson authored
      To account for ARM changing their minds about how to clear the exclusive lock on different architectures, provide a function pointer with a known good implementation. This is similar to the run of NOPs returned by OS_PlatformFeatures 0 for those that need it.
      If in the future any errata or similar are needed, then there's only 1 place to change it, plus clients don't need their own CPU type detection logic.
      
      Version 5.77. Tagged as 'Kernel-5_77'
      a7892833
  24. 11 Jan, 2017 1 commit
  25. 17 Dec, 2016 1 commit
    • Jeffrey Lee's avatar
      Fix screen redirection when in teletext modes. Fix *ScreenLoad buffer overflow. · 06079048
      Jeffrey Lee authored
      Detail:
        s/vdu/vdugrafl, s/vdu/vduttx - Adjust initialisation & shutdown of TTX workspace to fix workspace being erroneously freed/reinitialised when redirecting output to a sprite
        s/vdu/vdugrafk - If ScreenLoad needs to load one row at a time (e.g. when graphics window width != sprite width), allocate a block from the RMA instead of assuming that ScrLoaBuffer is large enough
        hdr/KernelWS - Get rid of ScrLoaBuffer, and shrink LargeCommon to a suitable size. Frees about 2K of VDU workspace.
        s/GetAll - Move Hdr:Sprite earlier in list of GETs
      Admin:
        Tested on Raspberry Pi
      
      
      Version 5.75. Tagged as 'Kernel-5_75'
      06079048
  26. 15 Dec, 2016 1 commit
    • Jeffrey Lee's avatar
      Add support for custom teletext modes · 92e90b01
      Jeffrey Lee authored
      Detail:
        This set of changes:
        * Adds support for the T, TX and TY mode string elements (as per RISCOS Ltd)
        * Adds support for entering arbitrary-resolution teletext modes by using mode selector blocks with the Teletext mode flag set
        * ScrRCol and ScrBRow mode variables can be provided in the mode selector in order to restrict the number of text rows/columns in teletext modes (as per RISCOS Ltd)
        * If the rows / columns are restricted in this manner then the text window will be centered on the screen, to try and avoid things looking too ugly (no variable text scaling implemented)
        * For HiResTTX, all colour depths >= 4bpp are now supported by teletext. This essentially makes the TTX256 switch obsolete.
        * If the "native" mode 7 is unavailable then the kernel will try a series of fallback resolutions & colour depths in an effort to find a combination that works
        Known bugs/issues:
        * Teletext column count has a max limit of 255 due to TTXDoubleCounts being a byte array
        * If there's a border around the text window, the border will not be refreshed when changing transparency modes using a VDU 23,18,0 sequence
        * ScreenLoad looks like it can overflow the LargeCommon buffer (no buffer size check) - needs fixing before LargeCommon can be safely shrunk below (Old)TTXMapSize
        File changes:
        - hdr/KernelWS - Make CharWidth non-conditional. Adjust handling of teletext workspace; it's now allocated from the system heap to allow it to cope with arbitrary screen sizes
        - s/vdu/vdu23 - Make CharWidth non-conditional
        - s/vdu/vducursoft - Make CursorTeletext cope with arbitrary colour depths, make CharWidth non-conditional, remove hard-coded teletext values
        - s/vdu/vdudriver - Deal with teletext workspace allocation during ModeChangeSub. Deal with selecting teletext modes (and validating colour depth) in GenerateModeSelectorVars.
        - s/vdu/vdugrafl - Make CharWidth non-conditional. Calculate offset required for text window centering.
        - s/vdu/vdumodes - Remove TTX256
        - s/vdu/vduswis - Try other teletext modes if native mode 7 not available. Extend OS_ScreenMode reason codes to cope with teletext mode strings.
        - s/vdu/vduttx - Update to use dynamic workspace. Replace various hardcoded values with variable lookups. Update character plotting + colour/palette selection to work with true-colour modes if HiResTTX.
        - s/vdu/vduwrch - Move some useful code into a subroutine. Update FastCLS to cope with true-colour teletext. Update AddressR0R1 to cope with text window centering offset. Make CharWidth non-conditional.
      Admin:
        Tested on Raspberry Pi, BB-xM
        VDU 23,18,0 in 256-colour teletext now works correctly (previously 64-colour mode was in use, causing palette update to be ruined by VIDC1-mangling)
      
      
      Version 5.74. Tagged as 'Kernel-5_74'
      92e90b01
  27. 13 Dec, 2016 8 commits
    • Jeffrey Lee's avatar
      Disable public use of new ARMops until ready · 5cfe8f63
      Jeffrey Lee authored
      Detail:
        hdr/OSMisc, s/ARMops - Don't expose the new ARMops via OS_MMUControl 2, they haven't been fully tested/developed yet
      Admin:
        Builds, untested
      
      
      Version 5.73. Tagged as 'Kernel-5_73'
      5cfe8f63
    • Jeffrey Lee's avatar
      Implement some ARM11 errata workarounds · bfd65b5c
      Jeffrey Lee authored
      Detail:
        s/ARMops, s/HAL - Add workarounds for some of the scary errata that were previously weren't dealing with (720013, 716151, 714068)
      Admin:
        Tested on Raspberry Pi 1
      
      
      Version 5.72. Tagged as 'Kernel-5_72'
      bfd65b5c
    • Jeffrey Lee's avatar
      Implement support for cacheable pagetables · 65fa6a28
      Jeffrey Lee authored
      Detail:
        Modern ARMs (ARMv6+) introduce the possibility for the page table walk hardware to make use of the data cache(s) when performing memory accesses. This can significantly reduce the cost of a TLB miss on the system, and since the accesses are cache-coherent with the CPU it allows us to make the page tables cacheable for CPU (program) accesses also, improving the performance of page table manipulation by the OS.
        Even on ARMs where the page table walk can't use the data cache, it's been measured that page table manipulation operations can still benefit from placing the page tables in write-through or bufferable memory.
        So with that in mind, this set of changes updates the OS to allow cacheable/bufferable page tables to be used by the OS + MMU, using a system-appropriate cache policy.
        File changes:
        - hdr/KernelWS - Allocate workspace for storing the page flags that are to be used by the page tables
        - hdr/OSMem - Re-specify CP_CB_AlternativeDCache as having a different behaviour on ARMv6+ (inner write-through, outer write-back)
        - hdr/Options - Add CacheablePageTables option to allow switching back to non-cacheable page tables if necessary. Add SyncPageTables var which will be set {TRUE} if either the OS or the architecture requires a DSB after writing to a faulting page table entry.
        - s/ARM600, s/VMSAv6 - Add new SetTTBR & GetPageFlagsForCacheablePageTables functions. Update VMSAv6 for wider XCBTable (now 2 bytes per element)
        - s/ARMops - Update pre-ARMv7 MMU_Changing ARMops to drain the write buffer on entry if cacheable pagetables are in use (ARMv7+ already has this behaviour due to architectural requirements). For VMSAv6 Normal memory, change the way that the OS encodes the cache policy in the page table entries so that it's more compatible with the encoding used in the TTBR.
        - s/ChangeDyn - Update page table page flag handling to use PageTable_PageFlags. Make use of new PageTableSync macro.
        - s/Exceptions, s/AMBControl/memmap - Make use of new PageTableSync macro.
        - s/HAL - Update MMU initialisation sequence to make use of PageTable_PageFlags + SetTTBR
        - s/Kernel - Add PageTableSync macro, to be used after any write to a faulting page table entry
        - s/MemInfo - Update OS_Memory 0 page flag conversion. Update OS_Memory 24 to use new symbol for page table access permissions.
        - s/MemMap2 - Use PageTableSync. Add routines to enable/disable cacheable pagetables
        - s/NewReset - Enable cacheable pagetables once we're fully clear of the MMU initialision sequence (doing earlier would be trickier due to potential double-mapping)
      Admin:
        Tested on pretty much everything currently supported
        Delivers moderate performance benefits to page table ops on old systems (e.g. 10% faster), astronomical benefits on some new systems (up to 8x faster)
        Stats: https://www.riscosopen.org/forum/forums/3/topics/2728?page=2#posts-58015
      
      
      Version 5.71. Tagged as 'Kernel-5_71'
      65fa6a28
    • Jeffrey Lee's avatar
      Make MMU_Changing ARMops perform the sub-operations in a sensible order · 9a96263a
      Jeffrey Lee authored
      Detail:
        For a while we've known that the correct way of doing cache maintenance on ARMv6+ (e.g. when converting a page from cacheable to non-cacheable) is as follows:
        1. Write new page table entry
        2. Flush old entry from TLB
        3. Clean cache + drain write buffer
        The MMU_Changing ARMops (e.g. MMU_ChangingEntry) implement the last two items, but in the wrong order. This has caused the operations to fall out of favour and cease to be used, even in pre-ARMv6 code paths where the effects of improper cache/TLB management perhaps weren't as readily visible.
        This change re-specifies the relevant ARMops so that they perform their sub-operations in the correct order to make them useful on modern ARMs, updates the implementations, and updates the kernel to make use of the ops whereever relevant.
        File changes:
        - Docs/HAL/ARMop_API - Re-specify all the MMU_Changing ARMops to state that they are for use just after a page table entry has been changed (as opposed to before - e.g. 5.00 kernel behaviour). Re-specify the cacheable ones to state that the TLB invalidatation comes first.
        - s/ARM600, s/ChangeDyn, s/HAL, s/MemInfo, s/VMSAv6, s/AMBControl/memmap - Replace MMU_ChangingUncached + Cache_CleanInvalidate pairs with equivalent MMU_Changing op
        - s/ARMops - Update ARMop implementations to do everything in the correct order
        - s/MemMap2 - Update ARMop usage, and get rid of some lingering sledgehammer logic from ShuffleDoublyMappedRegionForGrow
      Admin:
        Tested on pretty much everything currently supported
      
      
      Version 5.70. Tagged as 'Kernel-5_70'
      9a96263a
    • Jeffrey Lee's avatar
      Place restrictions on the use of cacheable doubly-mapped DAs · 2704c756
      Jeffrey Lee authored
      Detail:
        The kernel has always allowed software to create cacheable doubly-mapped DAs, despite the fact that the VIVT caches used on ARMv5 and below would have no way of keeping both of the mappings coherent
        This change places restrictions the following restrictions on doubly-mapped areas, to ensure that cache settings which can't be supported by the cache architecture of the CPU can't be selected:
        * On ARMv6 and below, cacheable doubly-mapped areas aren't supported.
          * Although ARMv6 has VIPT data caches, it's also subject to page colouring constraints which would require us to force the DA size to be a multiple of 16k. So for now keep things simple and disallow cacheable doubly-mapped areas on ARMv6.
        * On ARMv7 and above, cacheable doubly-mapped areas are allowed, but only if they are marked non-executable
          * The blocker to allowing executable cacheable doubly-mapped areas are the VIPT instruction caches; OS_SynchroniseCodeAreas (or callers of it) would need to know that a doubly-mapped area is in use so that they can flush both mappings from the I-cache. Although some chips do have PIPT instruction caches, again it isn't really worth supporting executable cacheable doubly-mapped areas at the moment.
        These changes also allow us to get rid of the expensive 'sledgehammer' logic when dealing with doubly-mapped areas
        File changes:
        - s/ARM600, s/VMSAv6 - Remove the sledgehammer logic, only perform cache/TLB maintenance for the required areas
        - s/ChangeDyn - Implement the required checks
        - s/MemMap2 - Move some cache maintenance logic into RemoveCacheabilityR0ByMinusR2, which previously would have had to be performed by the caller due to the sledgehammer paranoia
      Admin:
        Cacheable doubly-mapped DAs tested on iMx6 (tried making screen memory write-through cacheable; decent performance gain seen)
        Note OS_Memory 0 "make temporarily uncacheable" doesn't work on doubly-mapped areas, so cacheable doubly-mapped areas are not yet safe for general DMA
      
      
      Version 5.69. Tagged as 'Kernel-5_69'
      2704c756
    • Jeffrey Lee's avatar
      Add new ARMops. Add macros which map the ARMv7/v8 cache/TLB maintenance... · 48485eee
      Jeffrey Lee authored
      Add new ARMops. Add macros which map the ARMv7/v8 cache/TLB maintenance mnemonics (as featured in recent ARM ARMs) to MCR ops.
      
      Detail:
        - Docs/HAL/ARMop_API - Document the new ARMops. These ops are intended to help with future work (DMA without OS_Memory 0 "make temp uncacheable", and minimising cache maintenance when unmapping pages) and aren't in use just yet.
        - hdr/Copro15ops - Add new macros for ARMv7+ which map the mnemonics seen in recent ARM ARMs to the corresponding MCR ops. This should make things easier when cross-referencing docs and reduce the risk of typos.
        - hdr/KernelWS - Shuffle kernel workspace a bit to make room for the new ARMops
        - hdr/OSMisc - Expose new ARMops via OS_MMUControl 2
        - s/ARMops - Implement the new ARMops. Change the ARMv7+ ARMops to use the new mnemonic macros. Also get rid of myDSB / myISB usage from ARMv7+ code paths; use DSB/ISB/etc. directly to ensure correct behaviour
        - s/HAL - Mnemonic + ISB/DSB updates. Change software RAM clear to do 16 bytes at a time for kernel workspace instead of 32 to allow the kernel workspace tweaks to work.
      Admin:
        Binary diff shows that mnemonics map to the original MCR ops correctly
        Note: Raspberry Pi builds will now emit lots of warnings due to increased DSB/ISB instruction use. However it should be safe to ignore these as they should only be present in v7+ code paths.
        Note: New ARMops haven't been tested yet, will be disabled (or at least hidden from user code) in a future checkin
      
      
      Version 5.68. Tagged as 'Kernel-5_68'
      48485eee
    • Jeffrey Lee's avatar
      Make s/ChangeDyn slightly more readable by splitting some routines out into a separate file · 4a6150dc
      Jeffrey Lee authored
      Detail:
        s/MemMap2 - New file containing assorted low-level memory mapping routines taken from s/ChangeDyn. N.B. There's no special significance to this being named "MemMap2", it's just a name that stuck due to some earlier (abandoned) changes which added a file named "MemMap".
        s/ChangeDyn - Remove the routines/chunks of code that were moved to s/MemMap2. Also some duplicate code removal (Regular DA grow code and DoTheGrowNotSpecified are now rely on the new DoTheGrowCommon routine for doing the actual grow)
        s/GetAll - GET s/MemMap2 at an appropriate time
      Admin:
        Tested on pretty much everything currently supported
      
      
      Version 5.67. Tagged as 'Kernel-5_67'
      4a6150dc
    • Jeffrey Lee's avatar
      Reimplement AMBControl ontop of the PMP system · cefb4815
      Jeffrey Lee authored
      Detail:
        With this set of changes, each AMB node is now the owner of a fake DANode which is linked to a PMP.
        From a user's perspective the behaviour of AMBControl is the same as before, but rewriting it to use PMPs internally offers the following (potential) benefits:
        * Reduction in the amount of code which messes with the CAM & page tables, simplifying future work/maintenance. Some of the AMB ops (grow, shrink) now just call through to OS_ChangeDynamicArea. However all of the old AMB routines were well-optimised, so to avoid a big performance hit for common operations not all of them have been removed (e.g. mapslot / mapsome). Maybe one day these optimal routines will be made available for use by regular PMP DAs.
        * Removal of the slow Service_MemoryMoved / Service_PagesSafe handlers that had to do page list fixup after the core kernel had reclaimed/moved pages. Since everything is a PMP, the kernel will now deal with this on behalf of AMB.
        * Removal of a couple of other slow code paths (e.g. Do_AMB_MakeUnsparse calls from OS_ChangeDynamicArea)
        * Potential for more flexible mapping of application space in future, e.g. sparse allocation of memory to the wimp slot
        * Simpler transition to an ASID-based task swapping scheme on ARMv6+?
        Other changes of note:
        * AMB_LazyMapIn switch has been fixed up to work correctly (i.e. turning it off now disables lazy task swapping and all associated code instead of producing a build error)
        * The DANode for the current app should be accessed via the GetAppSpaceDANode macro. This will either return the current AMB DANode, or AppSpaceDANode (if e.g. pre-Wimp). However be aware that AppSpaceDANode retains the legacy behaviour of having a base + size relative to &0, while the AMB DANodes (identifiable via the PMP flag) are sane and have their base + size relative to &8000.
        * Mostly-useless DebugAborts switch removed
        * AMBPhysBin (page number -> phys addr lookup table) removed. Didn't seem to give any tangible performance benefit, and was imposing hidden restrictions on memory usage (all phys RAM fragments in PhysRamTable must be multiple of 512k). And if it really was a good optimisation, surely it should have been applied to all areas of the kernel, not just AMB!
        Other potential future improvements:
        * Turn the fake DANodes into real dynamic areas, reducing the amount of special code needed in some places, but allow the DAs to be hidden from OS_DynamicArea 3 so that apps/users won't get too confused
        * Add a generic abort trapping system to PMPs/DAs (lazy task swapping abort handler is still a special case)
        File changes:
        - s/ARM600, s/VMSAv6, s/ExtraSWIs - Remove DebugAborts
        - s/ArthurSWIs - Remove AMB service call handler dispatch
        - s/ChangeDyn - AMB_LazyMapIn switch fixes. Add alternate internal entry points for some PMP ops to allow the DANode to be specified (used by AMB)
        - s/Exceptions - Remove DebugAborts, AMB_LazyMapIn switch fixes
        - s/Kernel - Define GetAppSpaceDANode macro, AMB_LazyMapIn switch fix
        - s/MemInfo - AMB_LazyMapIn switch fixes
        - s/AMBControl/AMB - Update GETs
        - s/AMBControl/Memory - Remove block size quantisation, AMB_BlockResize (page list blocks are now allocated by PMP code)
        - s/AMBControl/Options - Remove PhysBin definitions, AMBMIRegWords (moved to Workspace file), AMB_LimpidFreePool switch. Add AMB_Debug switch.
        - s/AMBControl/Workspace - Update AMBNode to contain an embedded DANode. Move AMBMIRegWords here from Options file.
        - s/AMBControl/allocate - Fake DA node initialisation
        - s/AMBControl/deallocate - Add debug output
        - s/AMBControl/growp, growshrink, mapslot, mapsome, shrinkp - Rewrite to use PMP ops where possible, add debug output
        - s/AMBControl/main - Remove PhysBin initialisation. Update the enumerate/mjs_info call.
        - s/AMBControl/memmap - Low-level memory mapping routines updated or rewritten as appropriate.
        - s/AMBControl/readinfo - Update to cope with DANode
        - s/AMBControl/service - Remove old service call handlers
        - s/AMBControl/handler - DA handler for responding to PMP calls from OS_ChangeDynamicArea; just calls through to growpages/shrinkpages as appropriate.
      Admin:
        Tested on pretty much everything currently supported
      
      
      Version 5.66. Tagged as 'Kernel-5_66'
      cefb4815
  28. 04 Dec, 2016 1 commit
  29. 25 Nov, 2016 1 commit
    • Robert Sprowson's avatar
      Issue Service_ModulePostInit when really post init · fc32d45b
      Robert Sprowson authored
      Previously, the service call was sent when the module was in the service call chain/command table hash/SWI table hash, but not actually in the list of modules - so any recipient trying to look something up with OS_Module would get denial that the module existed.
      Move the service call issue step to *after* it's linked into the module list.
      
      Version 5.64. Tagged as 'Kernel-5_64'
      fc32d45b
  30. 26 Oct, 2016 1 commit
  31. 17 Oct, 2016 1 commit
    • Jeffrey Lee's avatar
      Prevent disabling of the D-cache on Cortex-A53. Other OS_MMUControl 0 fixes. · d7299988
      Jeffrey Lee authored
      Detail:
        On Cortex-A53, a load/store exclusive instruction will abort if it targets non-cacheable memory or if the D-cache is disabled. Since the correct operation of these instructions is important to the OS and apps, it makes sense to prevent *Cache Off / OS_MMUControl 0 from being able to disable the D-cache on such systems.
        hdr/OSMisc, s/ARMops - Add new OS_PlatformFeatures 0 flag to indicate when disabling of the D-cache isn't allowed
        s/VMSAv6 - Update MMUControl_ModifyControl to force the D-cache to always be on when the "unsafe to disable D-cache" PlatformFeatures flag is set. Also, disallow mismatched I+D cache settings if we have an L2 cache (causes issues due to IMB ops only flushing to PoU), and fix dangerous D-cache invalidation when it's only the I-cache which is being disabled
        s/ARM600 - Clean up MMUControl_ModifyControl a bit so that it's a closer match to the VMSAv6 version, and fix the dangerous D-cache invalidation.
      Admin:
        Tested on ARM11, Cortex-A7, Cortex-A53
      
      
      Version 5.62. Tagged as 'Kernel-5_62'
      d7299988
  32. 09 Oct, 2016 1 commit
    • Jeffrey Lee's avatar
      Fix wrong XCBTable being used for pre-rev T StrongARMs. Update HAL UART API docs. · fe59a83a
      Jeffrey Lee authored
      Detail:
        s/ARMops - Fix pre-rev T StrongARMs using the wrong XCBTable, causing invalid page flags to be used for the write-through cache policy
        Docs/HAL/Serial - Update HAL UART API docs. Mostly filling in some blanks, but also correcting a couple of things, and documenting new Features bit 4, LineStatus bit 8, and the effect on InterruptID.
      Admin:
        Tested on pre-rev T StrongARM RiscPC
      
      
      Version 5.61. Tagged as 'Kernel-5_61'
      fe59a83a
  33. 13 Sep, 2016 1 commit
    • Jeffrey Lee's avatar
      Fix CAM indexing in DoTheGrowPageUnavailable · f6403cd5
      Jeffrey Lee authored
      Detail:
        s/ChangeDyn - A routine that was missed during the upgrade from 8 byte CAM entries to 16 byte CAM entries, DoTheGrowPageUnavailable was using still using the old CAM entry size, potentially corrupting the CAM whenever it was called (i.e. if a DA grow requested a page that had already been claimed for exclusive use by someone else)
      Admin:
        Tested on BB-xM
      
      
      Version 5.60. Tagged as 'Kernel-5_60'
      f6403cd5