1. 17 Mar, 2021 2 commits
    • Jeffrey Lee's avatar
      Remove CAM size limit · 79bc3343
      Jeffrey Lee authored
      Previously the CAM sat inside a fixed 16MB window, restricting it to
      storing the details of 1 million pages, i.e. 4GB of RAM. Shuffle things
      around a bit to allow this restriction to be removed: the CAM is now
      located just above the IO region, and the CAM start address /
      IO top will calculated appropriately during kernel init. This change
      paves the way for us to support machines with over 4GB of RAM.
      
      FixedAreasTable has also been removed, since it's no longer really
      necessary (DAs can only be created between the top of application space
      and the bottom of the used IO space, and it's been a long time since
      we've had any fixed bits in the middle of there)
      79bc3343
    • Jeffrey Lee's avatar
      Initial long descriptor support · b51b5540
      Jeffrey Lee authored
      This adds initial support for the "long descriptor" MMU page table
      format, which allows the CPU to (flexibly) use a 40-bit physical address
      space.
      
      There are still some features that need fixing (e.g. RISCOS_MapInIO
      flags), and the OS doesn't yet support RAM above the 32bit limit, but
      this set of changes is enough to allow for working ROMs to be produced.
      
      Also, move MMUControlSoftCopy initialisation out of ClearWkspRAM, since
      it's unrelated to whether the HAL has cleared the RAM or not.
      b51b5540
  2. 13 Feb, 2021 4 commits
    • Jeffrey Lee's avatar
      [RISCOS_]AccessPhysicalAddress uses page flags · 7924aae2
      Jeffrey Lee authored
      Currently RISCOS_AccessPhysicalAddress allows the caller to specify the
      permissions/properties of the mapped memory by directly specifying some
      of the L1 page table entry flags. This will complicate things when
      adding support for more page table formats, so change it so that
      standard RISC OS page flags are used instead (like the alternate entry
      point, RISCOS_AccessPhysicalAddressUnchecked, already uses).
      
      Also, drop the "RISCOS_" prefix from RISCOS_AccessPhysicalAddress and
      RISCOS_ReleasePhysicalAddress, and remove the references to these
      routines from the HAL docs. These routines have never been exposed to
      the HAL, so renaming them and removing them from the docs should make
      their status clearer.
      
      Version 6.52. Tagged as 'Kernel-6_52'
      7924aae2
    • Jeffrey Lee's avatar
      OS_FindMemMapEntries now uses logical_to_physical · b60d3a70
      Jeffrey Lee authored
      Reduce the number of routines which directly examine the page tables, by
      changing OS_FindMemMapEntries to use logical_to_physical.
      b60d3a70
    • Jeffrey Lee's avatar
      Start moving page table code into s.ShortDesc · ca69793c
      Jeffrey Lee authored
      In preparation for the addition of long descriptor page table support,
      start moving low-level page table routines into their own file
      (s.ShortDesc) so that we can add a corresponding long descriptor
      implementation in the future.
      
      * logical_to_physical, MakePageTablesCacheable,
      MakePageTablesNonCacheable, AllocateBackingLevel2, AMB_movepagesin_L2PT,
      AMB_movecacheablepagesout_L2PT, AMB_moveuncacheablepagesout_L2PT
      routines, and PageNumToL2PT macros, all moved to s.ShortDesc with no
      changes.
      * Add new UpdateL1PTForPageReplacement routine (by splitting some code
      out of s.ChangeDyn)
      ca69793c
    • Jeffrey Lee's avatar
      Prepare logical_to_physical for 64bit phys addrs · 4fd2dd01
      Jeffrey Lee authored
      ppn_to_physical, logical_to_physical, physical_to_ppn & ppn_to_physical
      have now all been changed to accept/receive 64bit physical addresses in
      R8,R9 instead of a 32bit address in R5. However, where a phys addr is
      being provided as an input, they may currently only pay attention to the
      bottom 32 bits of the address.
      4fd2dd01
  3. 16 Jan, 2021 1 commit
    • Jeffrey Lee's avatar
      Make supervisor stack inaccessible to user mode · bbc7ad20
      Jeffrey Lee authored
      Previously the supervisor stack was read-only in user mode, but since
      the supervisor stack is typically empty when the CPU is in user mode,
      it's questionable whether any software actually makes use of this
      facility.
      
      To simplify support for the long descriptor page table format (which
      doesn't support the user-RO + privileged-RW access mode), let's
      try and remove usermode SVC stack access completely.
      
      Tested on Raspberry Pi 4
      
      Version 6.48. Tagged as 'Kernel-6_48'
      bbc7ad20
  4. 23 Nov, 2020 1 commit
    • Julie Stamp's avatar
      Increase RamFS limit to 2GB · a81fa868
      Julie Stamp authored
      Detail:
      RamFS now supports disc sizes up to 2GB-4KB, so raise the dynamic area limit from 508MB.
      
      Admin:
      Tested with a disc size up to 928MB
      
      Version 6.46. Tagged as 'Kernel-6_46'
      a81fa868
  5. 19 Sep, 2020 1 commit
    • Jeffrey Lee's avatar
      OS_DynamicArea 22 fixes · 88219988
      Jeffrey Lee authored
      Multiple fixes, mostly related to error handling.
      
      1. Ensure R1 is initialised correctly when generating BadPageNumber
      errors (labels 94 & 95). Generally this involves setting it to zero to
      indicate that no call to LogOp_MapOut is required. Failing to do this
      would typically result in a crash.
      2. When branching back to the start of the loop after calling
      GetNonReservedPage, ensure R0 is reset to zero. Failing to do this would
      have a performance impact on LogOp_MapOut, but shouldn't be fatal.
      3. In the main routine, postpone writing back DANode_Size until after
      the call to physical_to_ppn (because we may decide to abort the op
      and return an error without moving a page).
      4. Fix stack offset when accessing PMPLogOp_GlobalTBLFlushNeeded.
      Getting this wrong could potentially result in some TLB maintenance
      being skipped when moving uncacheable pages.
      5. Fix stack imbalance at label 94
      
      Version 6.43. Tagged as 'Kernel-6_43'
      88219988
  6. 01 Jul, 2020 6 commits
    • Jeffrey Lee's avatar
      Add missing AMBControl appspace shrink check · 0634b535
      Jeffrey Lee authored
      Fix GrowFreePoolFromAppSpace (i.e. appspace shrink operation) to issue
      UpCall_MemoryMoving / Service_Memory when attempting to shrink PMP-based
      appspace (i.e. AMBControl nodes). This fixes (e.g.) BASIC getting stuck
      in an abort loop if you try and use OS_ChangeDynamicArea to grow the
      free pool.
      
      Version 6.40. Tagged as 'Kernel-6_40'
      0634b535
    • Jeffrey Lee's avatar
      Fix PMP appspace size check · 5014117d
      Jeffrey Lee authored
      Fix AreaGrow to read appspace size correctly when appspace is a PMP
      (i.e. an AMBControl node). Reading DANode_Size will only report the
      amount of memory currently paged in (e.g. by lazy task swapping),
      causing AreaGrow to underestimate how much it can potentially take from
      the area.
      5014117d
    • Jeffrey Lee's avatar
      Fix GrowFreePool · 1a3c927f
      Jeffrey Lee authored
      Buggy since its introduction in Kernel-5_35-4_79_2_284, GrowFreePool was
      attempting to grow the free pool by shrinking application space, an
      operation which OS_ChangeDynamicArea doesn't support. Change it to grow
      the free pool instead, and fix a couple of other issues that would have
      caused it to work incorrectly (register corruption causing it to request
      a size change of zero, and incorrect assumption that
      OS_ChangeDynamicArea returns the amount unmoved, when really it returns
      the amount moved)
      1a3c927f
    • Jeffrey Lee's avatar
      Fix combined freepool + appspace shrink · 76d04b25
      Jeffrey Lee authored
      When a DA tries to grow by more than the free pool size, the kernel
      should try to take the necessary remaining amount from application
      space. Historically this was handled as a combined "take from freepool
      and appspace" operation, but with Kernel-5_35-4_79_2_284 this was
      changed to use a nested call to OS_ChangeDynamicArea, so first appspace
      is shrunk into the free pool and then the target DA is grown using just
      the free pool.
      
      However the code was foolishly trying to use ChangeDyn_AplSpace as the
      argument to OS_ChangeDynamicArea, which that call doesn't recognise as a
      valid DA number. Change it to use ChangeDyn_FreePool ("grow free pool
      from appspace"), and also fix up a stack imbalance that would have
      caused it to misbehave regardless of the outcome.
      76d04b25
    • Jeffrey Lee's avatar
      Fix shrinkables check in AreaGrow · 86fe0712
      Jeffrey Lee authored
      TryToShrinkShrinkables_Bytes expected both R1 and R2 to be byte counts,
      but AreaGrow was calling with R1 as a byte count and R2 as a page count.
      This would have caused it to request the first-found shrinkable to
      shrink more than necessary, and also confuse the rest of AreaGrow when
      the page-based R2 result of TryToShrinkShrinkables gets converted to a
      byte count (when AreaGrow wants it as a page count)
      86fe0712
    • Jeffrey Lee's avatar
      Fix Service_Memory when shrinking appspace · 323e88c6
      Jeffrey Lee authored
      Update AreaShrink so that (when shrinking appspace) CheckAppSpace is
      passed the change amount as a negative number, so that Service_Memory is
      issued with the correct sign.
      
      Fixes issue reported on the forums, where BASIC was getting confused
      because appspace shrinks were being reported as if they were a grow
      operation:
      
      https://www.riscosopen.org/forum/forums/4/topics/15067
      
      It looks like this bug was introduced in Kernel-5_35-4_79_2_284
      (introduction of PMPs), where the logic for appspace shrinks (which must
      be performed via a grow of the free pool or some other DA) were moved
      out of AreaGrow and into AreaShrink (because appspace shrinks are now
      internally treated as "shrink appspace into free pool")
      323e88c6
  7. 27 Feb, 2020 1 commit
  8. 12 Feb, 2020 3 commits
    • Jeffrey Lee's avatar
      Fixes for zero-size PMPs · 0830af41
      Jeffrey Lee authored
      OS_DynamicArea 21, 22 & 25 were using the value of the PMP page list
      pointer (DANode_PMP) to determine whether the dynamic area is a PMP or
      not. However, PMPs which have had their max physical size set to zero
      will don't have the page list allocated, which will cause the test to
      fail. Normally this won't matter (those calls can't do anything useful
      when used on PMPs with zero max size), except for the edge case of where
      the SWI has been given a zero-length page list as input. By checking the
      value of DANode_PMP, this would result in the calls incorrectly
      returning an error.
      
      Fix this by having the code check the DA flags instead. Also, add a
      check to OS_DynamicArea 23 (PMP resize), otherwise non-PMP DAs could end
      up having page lists allocated for them.
      0830af41
    • Jeffrey Lee's avatar
      Fix stack imbalance in DA release · 3a26f20e
      Jeffrey Lee authored
      In OS_DynamicArea 2, a stack imbalance would occur if an error is
      encountered while releasing the physical pages of a PMP (R1-R8 pushed,
      but only R1-R7 pulled). Fix it, but also don't bother storing R1, since
      it's never modified.
      3a26f20e
    • Jeffrey Lee's avatar
      PMP LogOp_MapOut fixes · a4ab6171
      Jeffrey Lee authored
      * Fix caching of page table entry flags (was never updating R9, so the
      flags would be recalculated for every page)
      * Fix use of flag in bottom bit of R6; if the flag was set, the
      early-exit case for having made all the cacheable pages uncacheable will
      never be hit, forcing it to loop through the full page list instead
      a4ab6171
  9. 18 Jan, 2020 1 commit
    • Jeffrey Lee's avatar
      Fix OS_DynamicArea 21 handling of MaxCamEntry · 5f7b9b37
      Jeffrey Lee authored
      OS_DynamicArea 21 was treating MaxCamEntry as if it was the exclusive
      upper bound, when really it's the inclusive bound. The consequence of
      this was that PMPs were unable to explicitly claim the highest-numbered
      RAM page in the system.
      
      Version 6.31. Tagged as 'Kernel-6_31'
      5f7b9b37
  10. 24 Nov, 2019 1 commit
    • Jeffrey Lee's avatar
      Add OS_DynamicArea 27+28, for supporting lots of RAM · 9224a6ca
      Jeffrey Lee authored
      OS_DynamicArea 27 is the same as OS_DynamicArea 5 ("return free
      memory"), except the result is measured in pages instead of bytes,
      allowing it to behave sensibly on machines with many gigabytes of RAM.
      
      Similarly, OS_DynamicArea 28 is the same as OS_DynamicArea 7 (internal
      DA enumeration call used by TaskManager), except the returned size
      values are measured in pages instead of bytes. A flags word has also
      been added to allow for more expansion in the future.
      
      Hdr:OSMem now also contains some more definitions which external code
      will find useful.
      
      Version 6.29. Tagged as 'Kernel-6_29'
      9224a6ca
  11. 19 Nov, 2019 1 commit
    • Jeffrey Lee's avatar
      Allow reservation of memory pages · 1f84ad9f
      Jeffrey Lee authored
      This change adds a new OS_Memory reason code, 23, for reserving memory
      without actually assigning it to a dynamic area. Other dynamic areas can
      still use the memory, but only the code that reserved it will be allowed
      to claim exclusive use over it (i.e. PageFlags_Unavailable).
      
      This is useful for systems such as the PCI heap, where physically
      contiguous memory is required, but the memory isn't needed all of the
      time. By reserving the pages, it allows other regular DAs to make use of
      the memory when the PCI heap is small. But when the PCI heap needs to
      grow, it guarantees that (if there's enough free memory in the system)
      the previously reserved pages can be allocated to the PCI heap.
      
      Notes:
      
      * Reservations are handled on an honour system; there's no checking that
      the program that reserved the memory is the one attempting to map it in.
      
      * For regular NeedsSpecificPages DAs, reserved pages can only be used if
      the special "RESV" R0 return value is used.
      
      * For PMP DAs, reserved pages can only be made Unavailable if the entry
      in the page block also specifies the Reserved page flag. The actual
      state of the Reserved flag can't be modified via PMP DA ops, the flag is
      only used to indicate the caller's permission/intent to make the page
      Unavailable.
      
      * If a PMP DA tries to make a Reserved page Unavailable without
      specifying the Reserved flag, the kernel will try to swap it out for a
      replacement page taken from the free pool (preserving the contents and
      generating Service_PagesUnsafe / Service_PagesSafe, as if another DA
      had claimed the page)
      
      Version 6.28. Tagged as 'Kernel-6_28'
      1f84ad9f
  12. 30 Sep, 2019 1 commit
    • Jeffrey Lee's avatar
      Allow runtime adjustment of AplWorkMaxSize · 0aeea07f
      Jeffrey Lee authored
      Detail:
      This adds a new OS_DynamicArea reason code, 26, for adjusting
      AplWorkMaxSize at runtime. This allows compatibility tools such as
      Aemulor to adjust the limit without resorting to patching the kernel.
      Any adjustment made to the value will affect the upper limit of
      application space, and the lower limit of dynamic area placement.
      Attempting to adjust beyond the compile-time upper/default limit, or
      such that it will interfere with existing dynamic areas / wimpslots,
      will result in an error.
      
      Relevant forum thread:
      https://www.riscosopen.org/forum/forums/11/topics/14734
      
      Admin:
      Tested on BB-xM, desktop active & inactive
      
      Version 6.24. Tagged as 'Kernel-6_24'
      0aeea07f
  13. 16 Aug, 2019 2 commits
    • Ben Avison's avatar
      Support supersection-mapped memory in OS_Memory 24 · bd294cf9
      Ben Avison authored
      To achieve this:
      * DecodeL1Entry and DecodeL2Entry return 64-bit physical addresses in
        r0 and r1, with additional return values shuffled up to r2 and r3
      * DecodeL1Entry now returns the section size, so callers can distinguish
        section- from supersection-mapped memory
      * PhysAddrToPageNo now accepts a 64-bit address (though since the physical
        RAM table is currently still all 32-bit, it will report any top-word-set
        addresses as being not in RAM)
      
      Version 6.22. Tagged as 'Kernel-6_22'
      bd294cf9
    • Ben Avison's avatar
      Support temporary mapping of IO above 4GB using supersections · 96913c1f
      Ben Avison authored
      Add a new reason code, OS_Memory 22, equivalent to OS_Memory 14, but
      accepting a 64-bit physical address in r1/r2. Current ARM architectures can
      only express 40-bit or 32-bit physical addresses in their page tables
      (depending on whether they feature the LPAE extension or not) so unlike
      OS_Memory 14, OS_Memory 22 can return an error if an invalid physical
      address has been supplied. OS_Memory 15 should still be used to release a
      temporary mapping, whether you claimed it using OS_Memory 14 or OS_Memory 22.
      
      The logical memory map has had to change to accommodate supersection mapping
      of the physical access window, which needs to be 16MB wide and aligned to a
      16MB boundary. This results in there being 16MB less logical address space
      available for dynamic areas on all platforms (sorry) and there is now a 1MB
      hole spare in the system address range (above IO).
      
      The internal function RISCOS_AccessPhysicalAddress has been changed to
      accept a 64-bit physical address. This function has been a candidate for
      adding to the kernel entry points from the HAL for a long time - enough that
      it features in the original HAL documentation - but has not been so added
      (at least not yet) so there are no API compatibility issues there.
      
      Requires RiscOS/Sources/Programmer/HdrSrc!2
      96913c1f
  14. 30 Jun, 2018 1 commit
    • ROOL's avatar
      Simplify initial AplSpace claim · 526764e1
      ROOL authored
      Detail:
        As the application slot is now a normal dynamic area, there's no need to manipulate the CAM directly. Convert FudgeSomeAppSpace into a OS_ChangeDynamicArea SWI followed by memset().
        ChangeDyn.s: Offset by 32k to account for the -32k that dynamic area -1 has.
        NewReset.s: Delete FudgeSomeAppSpace and replace as above.
      Admin:
        Submission from Timothy Baldwin.
      
      Version 6.08. Tagged as 'Kernel-6_08'
      526764e1
  15. 14 Apr, 2018 1 commit
    • Jeffrey Lee's avatar
      Fix ability for PMPs to claim specific pages · 5e3e9d38
      Jeffrey Lee authored
      Detail:
        s/ChangeDyn - Due to the way that some page flags map to the same bits as (different) DA flags, the Batcall that PMP_PreGrow makes in order to claim the requested page was getting confused and thinking that the special DMA PreGrow handler should be used instead of the DA-specific one (which in this case is a custom one responsible for claiming the right page). Modify PMP_PreGrow so that it only supplies DA flags to the Batcall, and patches in any custom page flags afterwards.
        Also swap magic number for appropriate symbol in PMPGrowHandler.
      Admin:
        Tested on BB-xM
        Fixes CAM corruption when a PMP claims a specific page, due to the PMP code and DA code disagreeing about which page should be used
      
      
      Version 6.00. Tagged as 'Kernel-6_00'
      5e3e9d38
  16. 11 Jan, 2017 1 commit
  17. 13 Dec, 2016 5 commits
    • 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
      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
  18. 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
  19. 07 Sep, 2016 1 commit
    • Jeffrey Lee's avatar
      Misc memory management fixes · 2f224a37
      Jeffrey Lee authored
      Detail:
        s/ChangeDyn - Fix register corruption in PMP_LogOp when mapping a page into a location that already contains a page. Fix excessive TLB flush in AreaShrink.
        s/ARM600, s/VMSAv6 - Add asserts to GetTempUncache to detect invalid register combinations
      Admin:
        Tested on BB-xM
      
      
      Version 5.59. Tagged as 'Kernel-5_59'
      2f224a37
  20. 23 Aug, 2016 1 commit
    • Jeffrey Lee's avatar
      Fix stack imbalance and incorrect return value in OS_DynamicArea 23 (PMP resize) · d181963e
      Jeffrey Lee authored
      Detail:
        s/ChangeDyn - When OS_DynamicArea 23 returned an error, R2 wasn't being set to zero correctly, incorrectly suggesting that a change had been made. And when a non-error resize of zero was being performed, registers were being pulled twice, resulting in a stack imbalance and crash.
      Admin:
        Tested on BB-xM
      
      
      Version 5.58. Tagged as 'Kernel-5_58'
      d181963e
  21. 18 Aug, 2016 1 commit
    • Jeffrey Lee's avatar
      Fix OS_FindMemMapEntries · d5e09872
      Jeffrey Lee authored
      Detail:
        s/ChangeDyn - Since the introduction of the 16 byte CAM entry format, OS_FindMemMapEntries has contained a bug where requesting the details for an address which does not have an L2PT page allocated for it (e.g. a location in ROM) would result in a misaligned CAM entry pointer being generated, resulting in either a crash or incorrect data being returned
      Admin:
        Tested on Raspberry Pi 2
        Fixes issue reported on forums:
        https://www.riscosopen.org/forum/forums/4/topics/6393
      
      
      Version 5.57. Tagged as 'Kernel-5_57'
      d5e09872
  22. 02 Aug, 2016 1 commit
    • Jeffrey Lee's avatar
      Add support for shareable pages and additional access privileges · 9cd4cbe4
      Jeffrey Lee authored
      Detail:
        This set of changes:
        * Refactors page table entry encoding/decoding so that it's (mostly) performed via functions in the MMU files (s.ARM600, s.VMSAv6) rather than on an ad-hoc basis as was the case previously
        * Page table entry encoding/decoding performed during ROM init is also handled via the MMU functions, which resolves some cases where the wrong cache policy was in use on ARMv6+
        * Adds basic support for shareable pages - on non-uniprocessor systems all pages will be marked as shareable (however, we are currently lacking ARMops which broadcast cache maintenance operations to other cores, so safe sharing of cacheable regions isn't possible yet)
        * Adds support for the VMSA XN flag and the "privileged ROM" access permission. These are exposed via RISC OS access privileges 4 and above, taking advantage of the fact that 4 bits have always been reserved for AP values but only 4 values were defined
        * Adds OS_Memory 17 and 18 to convert RWX-style access flags to and from RISC OS access privelege numbers; this allows us to make arbitrary changes to the mappings of AP values 4+ between different OS/hardware versions, and allows software to more easily cope with cases where the most precise AP isn't available (e.g. no XN on <=ARMv5)
        * Extends OS_Memory 24 (CheckMemoryAccess) to return executability information
        * Adds exported OSMem header containing definitions for OS_Memory and OS_DynamicArea
        File changes:
        - Makefile - export C and assembler versions of hdr/OSMem
        - Resources/UK/Messages - Add more text for OS_Memory errors
        - hdr/KernelWS - Correct comment regarding DCacheCleanAddress. Allocate workspace for MMU_PPLTrans and MMU_PPLAccess.
        - hdr/OSMem - New file containing exported OS_Memory and OS_DynamicArea constants, and public page flags
        - hdr/Options - Reduce scope of ARM6support to only cover builds which require ARMv3 support
        - s/AMBControl/Workspace - Clarify AMBNode_PPL usage
        - s/AMBControl/growp, mapslot, mapsome, memmap - Use AreaFlags_ instead of AP_
        - s/AMBControl/main, memmap - Use GetPTE instead of generating page table entry manually
        - s/ARM600 - Remove old coments relating to lack of stack. Update BangCam to use GetPTE. Update PPL tables, removing PPLTransL1 (L1 entries are now derived from L2 table on demand) and adding a separate table for ARM6. Implement the ARM600 versions of the Get*PTE ('get page table entry') and Decode*Entry functions
        - s/ARMops - Add Init_PCBTrans function to allow relevant MMU_PPLTrans/MMU_PCBTrans pointers to be set up during the pre-MMU stage of ROM init. Update ARM_Analyse to set up the pointers that are used post MMU init.
        - s/ChangeDyn - Move a bunch of flags to hdr/OSMem. Rename the AP_ dynamic area flags to AreaFlags_ to avoid name clashes and confusion with the page table AP_ values exported by Hdr:MEMM.ARM600/Hdr:MEMM.VMSAv6. Also generate the relevant flags for OS_Memory 24 so that it can refer to the fixed areas by their name instead of hardcoding the permissions.
        - s/GetAll - GET Hdr:OSMem
        - s/HAL - Change initial page table setup to use DA/page flags and GetPTE instead of building page table entries manually. Simplify AllocateL2PT by removing the requirement for the user to supply the access perimssions that will be used for the area; instead for ARM6 we just assume that cacheable memory is the norm and set L1_U for any L1 entry we create here.
        - s/Kernel - Add GetPTE macro (for easier integration of Get*PTE functions) and GenPPLAccess macro (for easy generation of OS_Memory 24 flags)
        - s/MemInfo - Fixup OS_Memory 0 to not fail on seeing non-executable pages. Implement OS_Memory 17 & 18. Tidy up some error generation. Make OS_Memory 13 use GetPTE. Extend OS_Memory 24 to return (non-) executability information, to use the named CMA_ constants generated by s/ChangeDyn, and to use the Decode*Entry functions when it's necessary to decode page table entries.
        - s/NewReset - Use AreaFlags_ instead of AP_
        - s/VMSAv6 - Remove old comments relating to lack of stack. Update BangCam to use GetPTE. Update PPL tables, removing PPLTransL1 (L1 entries are now derived from L2 table on demand) and adding a separate table for shareable pages. Implement the VMSAv6 versions of the Get*PTE and Decode*Entry functions.
      Admin:
        Tested on Raspberry Pi 1, Raspberry Pi 3, Iyonix, RPCEmu (ARM6 & ARM7), comparing before and after CAM and page table dumps to check for any unexpected differences
      
      
      Version 5.55. Tagged as 'Kernel-5_55'
      9cd4cbe4
  23. 30 Jun, 2016 2 commits
    • Jeffrey Lee's avatar
      Delete lots of old switches · f655fcf6
      Jeffrey Lee authored
      Detail:
        This change gets rid of the following switches from the source (picking appropriate code paths for a 32bit HAL build):
        * FixCallBacks
        * UseProcessTransfer
        * CanLiveOnROMCard
        * BleedinDaveBell
        * NewStyleEcfs
        * DoVdu23_0_12
        * LCDPowerCtrl
        * HostVdu
        * Print
        * EmulatorSupport
        * TubeInfo
        * AddTubeBashers
        * TubeChar, TubeString, TubeDumpNoStack, TubeNewlNoStack macros
        * FIQDebug
        * VCOstartfix
        * AssemblingArthur (n.b. still defined for safety with anything in Hdr: which uses it, but not used explicitly by the kernel)
        * MouseBufferFix
        * LCDInvert
        * LCDSupport
        * DoInitialiseMode
        * Interruptible32bitModes
        * MouseBufferManager
        * StrongARM (new CacheCleanerHack and InterruptDelay switches added to hdr/Options to cover some functionality that StrongARM previously covered)
        * SAcleanflushbroken
        * StrongARM_POST
        * IrqsInClaimRelease
        * CheckProtectionLink
        * GSWorkspaceInKernelBuffers
        * EarlierReentrancyInDAShrink
        * LongCommandLines
        * ECC
        * NoSPSRcorruption
        * RMTidyDoesNowt
        * RogerEXEY
        * StorkPowerSave
        * DebugForcedReset
        * AssembleKEYV
        * AssemblePointerV
        * ProcessorVectors
        * Keyboard_Type
        Assorted old files have also been deleted.
      Admin:
        Identical binary to previous revision for IOMD & Raspberry Pi builds
      
      
      Version 5.51. Tagged as 'Kernel-5_51'
      f655fcf6
    • Jeffrey Lee's avatar
      Delete pre-HAL and 26bit code · 7d5bfc66
      Jeffrey Lee authored
      Detail:
        This change gets rid of the following switches from the source (picking appropriate code paths for a 32bit HAL build):
        * HAL
        * HAL26
        * HAL32
        * No26bitCode
        * No32bitCode
        * IncludeTestSrc
        * FixR9CorruptionInExtensionSWI
        Various old files have also been removed (POST code, Arc/STB keyboard drivers, etc.)
      Admin:
        Identical binary to previous revision for IOMD & Raspberry Pi builds
      
      
      Version 5.49. Tagged as 'Kernel-5_49'
      7d5bfc66