- 13 Dec, 2016 4 commits
-
-
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'
-
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'
-
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'
-
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'
-
- 02 Aug, 2016 1 commit
-
-
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'
-
- 30 Jun, 2016 2 commits
-
-
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'
-
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'
-
- 15 Jun, 2016 1 commit
-
-
Jeffrey Lee authored
Detail: s/Kernel - Add macro for CLREX, which uses a dummy STREX on basic ARMv6 machines. Clear the exclusive monitor after issuing transient callbacks, to cope with callbacks being triggered on exit from IRQ s/ArthurSWIs, s/HAL, s/NewIRQs - Clear the exclusive monitor on exit from IRQ handlers & default FIQ handler s/VMSAv6 - Clear the exclusive monitor on entry to the data abort pre-veneer Admin: Tested on Raspberry Pi Non-transient callback handlers, custom abort handlers, FIQ handlers, and anything else which returns directly to interrupted user code is responsible for issuing its own CLREX if the code has done something that could have left the local monitor in the exclusive state (e.g. calling a SWI counts towards this, as there's no guarantee the monitor will be open on exit from the SWI) Version 5.35, 4.79.2.327. Tagged as 'Kernel-5_35-4_79_2_327'
-
- 20 May, 2016 1 commit
-
-
Jeffrey Lee authored
Detail: s/ARMops, s/HAL - Move CPU feature init to after the RAM clear, to prevent the cached values being clobbered on platforms where the HAL doesn't perform the RAM clear s/CPUFeatures - Update/clarify comment Admin: Tested on Raspberry Pi Fixes issue spotted by Sprow Version 5.35, 4.79.2.320. Tagged as 'Kernel-5_35-4_79_2_320'
-
- 10 Mar, 2016 1 commit
-
-
Jeffrey Lee authored
Detail: This set of changes tackles two main issues: * Before mapping out a cacheable page or making it uncacheable, the OS performs a cache clean+invalidate op. However this leaves a small window where data may be fetched back into the cache, either accidentally (dodgy interrupt handler) or via agressive prefetch (as allowed for by the architecture). This rogue data can then result in coherency issues once the pages are mapped out or made uncacheable a short time later. The fix for this is to make the page uncacheable before performing the cache maintenance (although this isn't ideal, as prior to ARMv7 it's implementation defined whether address-based cache maintenance ops affect uncacheable pages or not - and on ARM11 it seems that they don't, so for that CPU we currently force a full cache clean instead) * Modern ARMs generally ignore unexpected cache hits, so there's an interrupt hole in the current OS_Memory 0 "make temporarily uncacheable" implementation where the cache is being flushed after the page has been made uncacheable (consider the case of a page that's being used by an interrupt handler, but the page is being made uncacheable so it can also be used by DMA). As well as affecting ARMv7+ devices this was found to affect XScale (and ARM11, although untested for this issue, would have presumably suffered from the "can't clean uncacheable pages" limitation) The fix for this is to disable IRQs around the uncache sequence - however FIQs are currently not being dealt with, so there's still a potential issue there. File changes: - Docs/HAL/ARMop_API, hdr/KernelWS, hdr/OSMisc - Add new Cache_CleanInvalidateRange ARMop - s/ARM600, s/VMSAv6 - BangCam updated to make the page uncacheable prior to flushing the cache. Add GetTempUncache macro to help with calculating the page flags required for making pages uncacheable. Fix abort in OS_MMUControl on Raspberry Pi - MCR-based ISB was resetting ZeroPage pointer to 0 - s/ARMops - Cache_CleanInvalidateRange implementations. PL310 MMU_ChangingEntry/MMU_ChangingEntries refactored to rely on Cache_CleanInvalidateRange_PL310, which should be a more optimal implementation of the cache cleaning code that was previously in MMU_ChangingEntry_PL310. - s/ChangeDyn - Rename FastCDA_UpFront to FastCDA_Bulk, since the cache maintenance is no longer performed upfront. CheckCacheabilityR0ByMinusR2 now becomes RemoveCacheabilityR0ByMinusR2. PMP LogOp implementation refactored quite a bit to perform cache/TLB maintenance after making page table changes instead of before. One flaw with this new implementation is that mapping out large areas of cacheable pages will result in multiple full cache cleans while the old implementation would have (generally) only performed one - a two-pass approach over the page list would be needed to solve this. - s/GetAll - Change file ordering so GetTempUncache macro is available earlier - s/HAL - ROM decompression changed to do full MMU_Changing instead of MMU_ChangingEntries, to make sure earlier cached data is truly gone from the cache. ClearPhysRAM changed to make page uncacheable before flushing cache. - s/MemInfo - OS_Memory 0 interrupt hole fix - s/AMBControl/memmap - AMB_movepagesout_L2PT now split into cacheable+non-cacheable variants. Sparse map out operation now does two passes through the page list so that they can all be made uncacheable prior to the cache flush + map out. Admin: Tested on StrongARM, XScale, ARM11, Cortex-A7, Cortex-A9, Cortex-A15, Cortex-A53 Appears to fix the major issues plaguing SATA on IGEPv5 Version 5.35, 4.79.2.306. Tagged as 'Kernel-5_35-4_79_2_306'
-
- 29 Feb, 2016 2 commits
-
-
Jeffrey Lee authored
Detail: s/HAL - Change RISCOS_AccessPhysicalAddress & RISCOS_ReleasePhysicalAddress (aka OS_Memory 14 & 15) to use the MMU_ChangingUncached ARMop instead of TLB_InvalidateEntry, as on ARMv6+ the MMU version ensures the write has been flushed to be visible by the TLB, while the TLB invalidate call doesn't. Fix RISCOS_MapInIO (aka OS_Memory 13) not detecting regions which have already been mapped in due to L1_XN flag masking issue. Also issue DSB+ISB after the page table write(s) to ensure it's visible by the TLB hardware. Admin: Tested on IGEPv5 Version 5.35, 4.79.2.305. Tagged as 'Kernel-5_35-4_79_2_305'
-
Ben Avison authored
Detail: * Filled in CPU tables for publicly documented ARMv8 cores (Cortex-A53,57,72). * Recent ARM ARMs (e.g. section B1.9.2 of the ARMv7AR ARM) permit the core to take an undefined instruction exception upon encountering even not-taken conditional undefined instructions. This option is exercised by the Cortex-A53, unlike all ARMv7 cores previously supported by RISC OS. This unfortunately trips up a lot of kernel code that adapts to different architectures at runtime. These have now all been replaced with branches over the affected code on the opposite condition. * Fixed bug in HAL_InvalidateCache_ARMvF: for the main body of the loop, which was written as though to act on the CLIDR register, r8 actually contained the CTR register instead. Admin: Tested on Raspberry Pi 3 Version 5.35, 4.79.2.304. Tagged as 'Kernel-5_35-4_79_2_304'
-
- 31 Aug, 2015 1 commit
-
-
Jeffrey Lee authored
Detail: This set of changes adds support for "physical memory pools" (aka PMPs), a new type of dynamic area which allow physical pages to be claimed/allocated without mapping them in to the logical address space. PMPs have full control over which physical pages they use (similar to DAs which request specific physical pages), and also have full control over the logical mapping of their pages (which pages go where, and per-page access/cacheability control). Currently the OS makes use of two PMPs: one for the free pool (which now has a logical size of zero - freeing up gigabytes of logical space), and one for the RAM disc (logical size of 1MB, allowing for a physical size limited only by the amount of free memory) Implementing these changes has required a number of other changes to be made: * The CAM has been expanded from 8 bytes per entry to 16 bytes per entry, in order to allow each RAM page to store information about its PMP association * The system heap has been expanded to 32MB in size (from just under 4MB), in order to allow it to be used to store PMP page lists (1 word needed per page, but PMP pages may not always have physical pages assigned to them - so to allow multiple large PMPs to exist we need more than just 1 word per RAM page) * The &FA000000-&FBFFFFFF area of fixed kernel workspace has been shuffled around to accomodate the larger CAM, and the system heap is now located just above the RMA. * SoftResets code stripped out (unlikely we'll ever want to fix and re-enable it) * A couple of FastCDA options are now permanently on * Internal page flags shuffled around a bit. PageFlags_Unavailable now publicly exposed so that PMP clients can lock/unlock pages at will. * When OS_ChangeDynamicArea is asked to grow or shrink the free pool, it now implicitly converts it into a shrink or grow of application space (which is what would happen anyway). This simplifies the implementation; during a grow, pages (or replacement pages) are always sourced from the free pool, and during a shrink pages are always sent to the free pool. File changes: - hdr/KernelWS - Extend DANode structure. Describe CAM format. Adjust kernel workspace. - hdr/OSRSI6, s/Middle - Add new item to expose the CAM format - hdr/Options - Remove SoftResets switch. Add some PMP switches. - s/ARM600, s/VMSAv6 - Updated for new CAM format. Note that although the CAM stores PMP information, BangCamUpdate currently doesn't deal with updating that data - it's the caller's responsibility to do so where appropriate. - s/ChangeDyn - Lots of changes to implement PMP support, and to cope with the new CAM format. - s/HAL - Updated to cope with new CAM format, and lack of logical mapping of free pool. - s/MemInfo - Updated to cope with new CAM format. OS_Memory 0 updated to cope with converting PPN to PA for pages which are mapped out. OS_Memory 24 updated to decode the access permissions on a per-page basis for PMPs, and fixed its HWM usage for sparse DAs. - s/NewReset - Soft reset code and unused AddCamEntries function removed. Updated to cope with new CAM format, PMP free pool, PMP RAMFS - s/AMBControl/allocate - Update comment (RMA hasn't been used for AMBControl nodes for a long time) - s/AMBControl/growp, s/AMBControl/memmap, s/AMBControl/shrinkp - Update for new CAM format + PMP free pool - s/vdu/vdudriver - Strip out soft reset code. Admin: Tested on Pandaboard This is just a first iteration of the PMP feature, with any luck future changes will improve functionality. This means APIs are subject to change as well. Version 5.35, 4.79.2.284. Tagged as 'Kernel-5_35-4_79_2_284'
-
- 06 Aug, 2015 1 commit
-
-
Jeffrey Lee authored
Detail: s/HAL - A typo seems to have resulted in the HiProcVecs DebuggerSpace page being mapped in as NCB instead of CB. Fix it. Admin: Untested. Version 5.35, 4.79.2.274. Tagged as 'Kernel-5_35-4_79_2_274'
-
- 05 Aug, 2015 1 commit
-
-
Jeffrey Lee authored
Improve support for VMSAv6 cache policies & memory types. Expose raw ARMops via OS_MMUControl & cache information via OS_PlatformFeatures. Detail: Docs/HAL/ARMop_API - Document two new ARMops: Cache_Examine and IMB_List hdr/KernelWS - Shuffle workspace round a bit to allow space for the two new ARMops. IOSystemType now deleted (has been deprecated and fixed at 0 for some time) s/ARM600 - Cosmetic changes to BangCam to make it clearer what's going on. Add OS_MMUControl 2 (get ARMop) implementation. s/ARMops - Switch out different ARMop implementations and XCB tables depending on MMU model - helps reduce assembler warnings and make it clearer what code paths are and aren't possible. Add implementations of the two new ARMops. Simplify ARM_Analyse_Fancy by removing some tests which we know will have certain results. Use CCSIDR constants in ARMv7 ARMops instead of magic numbers. Update XCB table comments, and add a new table for VMSAv6 s/ChangeDyn - Define constant for the new NCB 'idempotent' cache policy (VMSAv6 normal, non-cacheable memory) s/HAL - Use CCSIDR constants instead of magic numbers. Extend RISCOS_MapInIO to allow the TEX bits to be specified. s/Kernel - OS_PlatformFeatures 33 (read cache information) implementation (actually, just calls through to an ARMop) s/MemInfo - Modify VMSAv6 OS_Memory 0 cache/uncache implementation to use the XCB table instead of modifying L2_C directly. This allows the cacheability to be changed without affecting the memory type - important for e.g. unaligned accesses to work correctly. Implement cache policy support for OS_Memory 13. s/Middle - Remove IOSystemType from OS_ReadSysInfo 6. s/VMSAv6 - Make sure BangCam uses the XCB table for working out the attributes of temp-uncacheable pages instead of manipulating L2_C directly. Add OS_MMUControl 2 implementation. s/AMBControl/memmap - Update VMSAv6 page table pokeing to use XCB table s/PMF/osinit - Remove IOSystemType reference, and switch out some pre-HAL code that was trying to use IOSystemType. Admin: Tested on Iyonix, ARM11, Cortex-A7, -A8, -A9, -A15 Note that contrary to the comments in the source the default NCB policy currently maps to VMSAv6 Device memory type (as per previous kernel versions). This is just a temporary measure, and it will be switched over to Normal, non-cacheable once appropriate memory barriers have been added to the affected IO code. Version 5.35, 4.79.2.273. Tagged as 'Kernel-5_35-4_79_2_273'
-
- 14 Jun, 2015 1 commit
-
-
Jeffrey Lee authored
Detail: s/HAL - The VMSAv6/v7 memory model allows speculative instruction fetches from any memory (including device/strongly-ordered), unless the memory is marked as non-executable. So to prevent interference with read-sensitive devices we must make sure all appropriate IO memory is marked as non-executable. Admin: Tested on IGEPv5 Fixes data corruption seen when reading from SD card Version 5.35, 4.79.2.265. Tagged as 'Kernel-5_35-4_79_2_265'
-
- 07 Feb, 2015 1 commit
-
-
Jeffrey Lee authored
Detail: s/ARMops, s/HAL - Errata 814220 states that the Cortex-A7 set/way cache maintenance operations violate the usual operation ordering rules, such that an L2 maintenance operation which is started after an L1 operation may actually complete before it, causing data corruption if the L1 data was to be evicted to the L2 entry. Implement the suggested workaround of performing a DSB when switching cache levels, rather than just at the end of the combined L1+L2 group of operations. Admin: Tested on Raspberry Pi 2 Version 5.35, 4.79.2.257. Tagged as 'Kernel-5_35-4_79_2_257'
-
- 27 Oct, 2014 1 commit
-
-
Robert Sprowson authored
Following hot on the heels of revision 1.1.2.39, when there's more than one block in existance the shuffle up loop trashes v3 & v4, which we need in the calculation just below. Could just use other registers in the shuffle loop, but we only have ip free at that point, so be lazy and just reload & reextract the flags. Tested on a softload Kinetic, now the RAM speed flags look sensible and the RAM clear doesn't fall off the end. Version 5.35, 4.79.2.244. Tagged as 'Kernel-5_35-4_79_2_244'
-
- 23 Jul, 2014 1 commit
-
-
Jeffrey Lee authored
Detail: s/HAL - Change ClearPhysRAM to always map in memory as cacheable + bufferable instead of only on StrongARM, as it's an optimisation that can help other platforms as well. Admin: Tested on BB-xM, StrongARM RiscPC Version 5.35, 4.79.2.231. Tagged as 'Kernel-5_35-4_79_2_231'
-
- 30 Apr, 2014 1 commit
-
-
Robert Sprowson authored
When Subtractv1v2fromRAMtable is called to remove a region that results in one of the RAM blocks being split in the middle the resulting size was incorrect. The shuffle up loop was reusing v6 as an iterator not realising that it's needed to calculate the size of the 2nd half later, the error introduced was the difference between the physical address where PhysRamTable is located and the block being split - these could be a long way apart for example when there are two SDRAM banks. Even if the PhysRamTable is nearby (eg. 1 SDRAM bank) the result would be some weird sized entries which ultimately mean some dynamic area address space is "leaked". Fixed by swapping to v7, and for symmetry also adjusted the shuffle down loop to match. Version 5.35, 4.79.2.224. Tagged as 'Kernel-5_35-4_79_2_224'
-
- 20 Apr, 2014 1 commit
-
-
Jeffrey Lee authored
Add OS_Memory 24 implementation. Change OS_ValidateAddress to use it. Fix kernel leaving the physical access MB in a messy state. Try and protect against infinite abort loops caused by bad environment handlers. Detail: s/MemInfo - Added an implementation of ROL's OS_Memory 24 call. Unlike the old OS_ValidateAddress call, this call should successfully report the presence of all memory areas known to the kernel. It should also correctly indicate which parts of a sparse DA are mapped in, unlike the old OS_ValidateAddress implementation. s/ChangeDyn - Update dynamic area handling to construct a lookup table for mapping logical addresses to dynamic areas; this is used by OS_Memory 24 to quickly locate which DA(s) hit a given region s/AMBControl/main - Make sure lazy task swapping is marked as disabled when AMB_LazyMapIn is {FALSE} - required so that OS_Memory 24 will give application space the correct flags s/ArthurSWIs - Switch OS_ValidateAddress over to using OS_Memory 24, as per ROL. For compatibili...
-
- 19 Apr, 2014 1 commit
-
-
Jeffrey Lee authored
Detail: s/ARMops - If extended pages aren't supported, make sure we use a PCBTrans table which doesn't use L2_X, otherwise the AP flags for some of the sub-pages will be corrupted when the PCB flags get merged in. Add some more comments to the PCBTrans tables so it's easier to see what the different columns are. s/ARM600 - Fix BangCam to use extended pages if they're supported; otherwise (assuming ARMops has selected the right PCBTrans table) we'll end up corrupting the AP flags again s/HAL - Fix ConstructCAMfromPageTables using the wrong register for ZeroPage when looking up MMU_PCBTrans. Correct a few comments. Admin: Tested on Iyonix Page table examination now shows that all subpages have the correct (i.e. identical) AP flags. Previously some pages would have incorrect access (e.g. every 4th subpage in some FileCore disc map/dir buffer DAs were writable in user mode) ARMops fix will presumably mean extended pages will now work correctly on IOP 80200, as before it would have been using small pages with corrupt AP flags Version 5.35, 4.79.2.221. Tagged as 'Kernel-5_35-4_79_2_221'
-
- 04 Apr, 2014 1 commit
-
-
John Ballance authored
HAL graphics driver calls. Added further debug capability Detail: Added additional HAL call. minor code correction in hal graphicsv dispatcher Added DebugReg macro to aid debugging Admin: (highlight level of testing that has taken place) (bugfix number if appropriate) Version 5.35, 4.79.2.215. Tagged as 'Kernel-5_35-4_79_2_215'
-
- 25 Mar, 2014 1 commit
-
-
Ben Avison authored
Detail: Early in OS startup, certain kernel memory areas (zero page, the privileged mode stacks, system heap, etc) are initially allocated only in the L2PT. The soft CAM is initialised later, using the L2PT as it is at that point. However, the pointer to the table that maps from page table cache policy bit layouts for the current CPU back to the platform-independent (OS_DynamicArea style) flags was corrupted, meaning that the CAM entries for these memory areas were initialised with a default value, which was non-cacheable non-bufferable. Application slots and most dynamic areas were unaffected, because once enough of the kernel was initialised to be able to use AMBControl or OS_ChangeDynamicArea, this function was no longer used. The problem comes when those pages come to be remapped; this could be due to requests for specific physical RAM pages, or (what I was actually investigating) DDT changing the access permissions on them. The problem was that as far as the CPU was concerned, the pages were cacheable/bufferable, but BangCam examined the soft CAM to decide what cache management operations to perform, and so got it wrong. The subsequent poke of the L2PT resulted in undefined CPU behaviour; in particular it seems to cause L2 caches to throw a strop (enough so that disabling the L2 cache was enough to make DDT significantly more reliable). Admin: It looks like this bug has been present on all HAL versions of RISC OS. Tested with DDT on a Beagleboard, previously the most crashy platform. There remains an IRQ (and FIQ) hole in OS_SetMemMapEntries when changing permissions on the page containing the processor vectors, which I haven't attempted to fix. Arguably, it should also issue Service_PagesSafe/Unsafe, in case anyone is DMAing to/from the remapped pages. Version 5.35, 4.79.2.212. Tagged as 'Kernel-5_35-4_79_2_212'
-
- 28 Sep, 2013 1 commit
-
-
Robert Sprowson authored
No longer returns a RISC OS specific error block to the HAL, instead uses a platform agnostic IICStatus value. Version 5.35, 4.79.2.196. Tagged as 'Kernel-5_35-4_79_2_196'
-
- 27 May, 2013 1 commit
-
-
Robert Sprowson authored
The StrongARM TRM (and hints from ARM600.s revision 4.3.2.2) show that the StrongARM will only do burst writes to memory marked as C=1 B=1, but by default RISCOS_AccessPhysicalAddress only allows bufferable. So, checking for StrongARM first, two extra snippets are enabled - first mark as C=1 B=1, then afterwards clean the cache before moving onto the next 1MB. On a StrongARM Kinetic these burst writes improve the RAM clear from ~60ms per MB to 40ms per MB. For a 256MB SODIMM that's over 5s knocked off the boot time. Other memory configurations will be similarly improved, though 256MB is of course the maximum the motherboard can hold. Tested in ROM on a Risc PC with StrongARM and ARM710. Version 5.35, 4.79.2.189. Tagged as 'Kernel-5_35-4_79_2_189'
-
- 28 Mar, 2013 1 commit
-
-
Jeffrey Lee authored
Detail: Briefly, this set of changes: * Adjusts PhysRamTable so that it retains the flags passed in by the HAL from OS_AddRAM (by storing them in the lower 12 bits of the size field) * Sorts the non-VRAM entries of PhysRamTable by speed and DMA capability, to ensure optimal memory allocation during OS startup. * Adjust the initial memory allocation logic to allow the cursor/sound chunk and HAL noncacheable workspace to come from DMA capable memory * Extends OS_Memory 12 to accept a 'must be DMA capable' flag in bit 8 of R0. This is the same as available in ROL's OS. * Extends OS_DynamicArea 0 to allow the creation of dynamic areas that automatically allocate from DMA capable memory. In ROL's OS this was done by setting bit 12 of R4, but we're using bits 12-14 for specifying the cache policy, so instead bit 15 is used. * Fixes OS_ReadSysInfo 6 to return the correct DevicesEnd value now that the IRQ/device limit is computed at runtime File changes: * hdr/OSEntries - Add definitions of the various flags passed to OS_AddRAM by the HAL. Add a new flag, NoDMA, for memory which can't be used for DMA. * hdr/KernelWS - Tidy PhysRamTable definition a bit by removing all the DRAM bank definitions except the first - this makes it easier to search for code which is interacting with the table. Remove VRAMFlags, it's redundant now that the flags are kept in the table. Add DMA allocation info to InitWs. * s/AMBControl/memmap - Updated to mask out the flags from PhysRamTable when reading RAM block sizes. * s/ARM600 - Strip out a lot of IOMD specific pre-HAL code. * s/ChangeDyn - Updated to cope with the flags stored in PhysRamTable. Implement support for DMA-capable dynamic areas. Rewrite InitDynamicAreas to insert pages into the free pool in the right order so that the fastest memory will be taken from it first. * s/GetAll, s/Middle - Fix OS_ReadSysInfo 6 to return the correct HAL-specific DevicesEnd value * s/HAL - Significant rework of initial RAM allocation code to allow the kernel workspace to come from the fastest DMA incapable RAM, while also allowing allocation of DMA capable memory for HAL NCNB workspace & kernel cursor/sound chunks. ClearPhysRAM rewritten as part of this. * s/MemInfo - Updated to cope with the flags stored in PhysRamTable. Add support for the new OS_Memory 12 flag. Update OS_Memory 7 to not assume PhysRamTable entries are sorted in address order, and rip out the old pre-HAL IOMD implementation. * s/NewReset - Remove GetPagesFromFreePool option, assume TRUE (as this has been the case for the past 10+ years). Revise a few comments and strip dead code. Update to cope with PhysRamTable flags. * s/VMSAv6 - Remove a couple of unused definitions * s/vdu/vdudriver - Update to cope with PhysRamTable flags Admin: Tested in Kinetic RiscPC ROM softload, Iyonix softload, & OMAP3 Version 5.35, 4.79.2.186. Tagged as 'Kernel-5_35-4_79_2_186'
-
- 24 Mar, 2013 1 commit
-
-
Robert Sprowson authored
Not tagged.
-
- 22 Jan, 2013 1 commit
-
-
Jeffrey Lee authored
Add new HAL call, HAL_IRQMax, to allow the kernel to determine the number of IRQ lines/devices at runtime Detail: hdr/HALEntries - Reuse the old HAL_MonitorLeadID call number for HAL_IRQMax hdr/KernelWS - Rearrange CursorChunkAddress workspace a bit. Removed unused OldOscliBuffs and a couple of pre-HAL allocations, and made DefIRQ1Vspace the same size for all build configs. Add an IRQMax var to zero page workspace to cache the value returned by HAL_IRQMax. s/HAL - Initialise IRQMax shortly after HAL initialisation. Revise ClearPhysRAM comment to reflect which vars are preserved in the current version of the code. s/NewIRQs - Strip out a fair bit of pre-HAL code to make the file more readable. Update OS_ClaimDeviceVector/OS_ReleaseDeviceVector to check against IRQMax instead of the MaxInterrupts compile-time limit. Admin: Tested on BB-xM, Iyonix, RiscPC, Pi Although the OS will now nominally adapt at runtime to how many IRQ devices there are, it's still using MaxInterrupts as an upper limit as the device claimant table has a fixed memory allocation. Version 5.35, 4.79.2.182. Tagged as 'Kernel-5_35-4_79_2_182'
-
- 30 Sep, 2012 1 commit
-
-
Jeffrey Lee authored
Detail: s/HAL, s/NewReset - Moved IIC initialisation to just after timer initialisation, and crucially, before keyboard scan initialisation. This makes things a lot easier for the HAL if it wants to use IIC during the keyboard scan (previously IIC would be enabled inbetween HAL_KbdScanSetup and the first call to HAL_KbdScan) hdr/HALDevice - Added a device ID for the Pandora audio controller Admin: Tested on Pandora Version 5.35, 4.79.2.168. Tagged as 'Kernel-5_35-4_79_2_168'
-
- 07 Sep, 2012 1 commit
-
-
Jeffrey Lee authored
Detail: Docs/RPiNotes - Deleted, contents no longer relevant s/HAL, s/Kernel, s/vdu/vduswis, s/pmf/key - Cleaned up debug code s/NewIRQs - No need to piggy back on timer 0 IRQ to generate a fake VSync; PushModeInfo already claims/releases TickerV as appropriate if video driver doesn't provide a VSync IRQ. s/NewReset - Re-enable LookForHALRTC call, the stack imbalance bug was fixed before the Pi changes were merged in s/vdu/vducursoft - Streamline PostWrchCursor a bit by only preserving R14 around RestorePointer if the software pointer is in use s/vdu/vdudriver - Amend ModeChangeSub improvements to ensure old external framestore handling logic is used if driver doesn't support framestore growth/realloc Admin: Tested on Raspberry Pi with high processor vectors Kernel now looks to be in a good state for merging back into HAL branch Note - Software mouse pointer support in vducursoft only checks HALVideoFeatures, so doesn't take into account the capabilities of any GraphicsV driver that may be in use. Version 5.35, 4.79.2.147.2.20. Tagged as 'Kernel-5_35-4_79_2_147_2_20'
-
- 02 Sep, 2012 1 commit
-
-
Jeffrey Lee authored
Detail: hdr/HALEntries - Add new HAL_Video_StartupMode HAL entry to allow the HAL to specify a startup mode s/HAL, s/Kernel - Tweaked debug routines s/vdu/vdudriver - Make use of HAL_Video_StartupMode in InitialiseMode to decide what initial mode should be. Clean up some hacks & debug. Improve handling of external framestores; if bit 5 of GraphicsV_DisplayFeatures r0 is set, the kernel will now allow the display driver to grow/shrink/move its framestore in response to mode changes. s/vdu/vdugrafv - Adjust default GV_FramestoreAddress implementation to only claim vector if HAL returns a framestore s/vdu/vduswis - Re-enable FindOKMode Admin: Tested on Raspberry Pi with high processor vectors Version 5.35, 4.79.2.147.2.18. Tagged as 'Kernel-5_35-4_79_2_147_2_18'
-
- 14 Aug, 2012 2 commits
-
-
Jeffrey Lee authored
Detail: s/HAL - Fix crash in OS_Hardware 4/5 when encountering devices which are newer than the caller supports Admin: Untested, but same fix as Pi branch Version 5.35, 4.79.2.163. Tagged as 'Kernel-5_35-4_79_2_163'
-
Jeffrey Lee authored
Fix crash in OS_Hardware 4 when encountering devices which are newer than the caller supports. Add new device IDs for Raspberry Pi audio devices. Detail: s/HAL - Fixed crash in OS_Hardware 4 when encountering devices which are newer than the caller supports hdr/HALDevice - Added new HAL devices for Raspberry Pi audio devices Admin: Tested on Raspberry Pi with high processor vectors Version 5.35, 4.79.2.147.2.17. Tagged as 'Kernel-5_35-4_79_2_147_2_17'
-
- 06 Jul, 2012 1 commit
-
-
Ben Avison authored
Detail: This functions like OS_Hardware 4, but enumerates devices in the chronological order of registration. Admin: Builds, but untested. Version 5.35, 4.79.2.160. Tagged as 'Kernel-5_35-4_79_2_160'
-
- 21 Jun, 2012 1 commit
-
-
Robert Sprowson authored
With no VRAM, in Kernerl.s.HAL line 370, the less than 16M case sets aside half the RAM as available for video (more than, it uses no more than 32M) but the exactly equals 16M case set aside none. Add some exports to hdr.HALEntries to define the subreasons to OS_Hardware. Version 5.35, 4.79.2.154. Tagged as 'Kernel-5_35-4_79_2_154'
-
- 21 May, 2012 1 commit
-
-
Robert Sprowson authored
While the HAL and kernel were being split some temporary macros were used for the bits being worked on, after 12 years of use they're probably safe to adopt. mjsCallHAL -> CallHAL; mjsAddressHAL -> AddressHAL; mjsHAL -> HAL. OS_VIDCDividerSWI code now always does NoSuchSWI (had been switched out previously). File vduhint.s no longer assembled (was empty). Version 5.35, 4.79.2.150. Tagged as 'Kernel-5_35-4_79_2_150'
-
- 18 May, 2012 1 commit
-
-
Ben Avison authored
Detail: This one evaded the cull in my last commit Admin: Still works on a Raspberry Pi Version 5.35, 4.79.2.147.2.3. Tagged as 'Kernel-5_35-4_79_2_147_2_3'
-
- 10 May, 2012 1 commit
-
-
Ben Avison authored
Detail: This is a new branch from the current tip of the HAL branch, incorporating the changes received from Adrian Lees. The same caveats apply - this is a work in progress and will not work on any other platform at present. Admin: Builds, but not tested. Version 5.35, 4.79.2.147.2.1. Tagged as 'Kernel-5_35-4_79_2_147_2_1'
-
- 25 Feb, 2012 1 commit
-
-
Jeffrey Lee authored
Detail: hdr/OSEntries, s/HAL, s/Kernel - Add compressed ROM support. With the current scheme, a compressed ROM will have everything except the HAL and kernel compressed. During the keyboard scan period the kernel will allocate some temporary decompression workspace and call the decompression stub that was appended to the ROM. The decompression stub is expected to perform in-place decompression of the ROM. Once decompression is complete the workspace will be freed and the page tables updated to make the ROM image readonly. It's the HAL's responsibility to make sure any compressed ROM is located in an area of physically contiguous RAM large enough to hold the uncompressed image. More info here: http://www.riscosopen.org/wiki/documentation/show/Compressed%20ROMs Makefile, h/OSEntries - Add C export of hdr/OSEntries hdr/HALDevice - Add device ID for Tungsten video device. Convert tabs to spaces for consistency. hdr/HALEntries, s/NewReset - Moved KbdFlag_* definitions to hdr/HALEntries so HALs can use them in their keyboard scan code s/ArthurSWIs, S/HAL, s/HeapSort, s/Kernel, s/MemInfo, s/Middle, s/NewIRQs, s/TickEvents, s/vdu/vdugrafb - Make use of BLX, BFI and long multiplies if the CPU supports them. Don't support SWI calls from thumb mode if the CPU doesn't support thumb. s/HAL - Made the LDMIA in Init_MapInRAM more sensible (register order was backwards). The old code did work, but wasn't doing what the comments described. Removed unused/unfinished HAL_Write0 function. Improve RISCOS_LogToPhys to check L1PT for any section mappings if the logical_to_physical call fails s/ModHand - Save one instruction by using ADR instead of MOV+ADD to compute lr s/NewReset, s/PMF/key - Pass L1PT to HAL_Reset to allow machines without hardware reset (e.g. IOMD) to perform resets by manually disabling the MMU and restarting the ROM s/vdu/vdudriver, s/vdu/vdugrafv - Use GVEntry macro borrowed from NVidia module for setting up the GraphicsV jump table. Make GraphicsV_ReadPaletteEntry call HAL_Video_ReadPaletteEntry if left unclaimed. Fixup GV_Render to only call HAL_Video_Render if the HAL call is implemented. Admin: Tested with OMAP3, IOMD & Tungsten ROMs/softloads. Version 5.35, 4.79.2.138. Tagged as 'Kernel-5_35-4_79_2_138'
-