- 18 Jan, 2020 1 commit
-
-
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'
-
- 24 Nov, 2019 3 commits
-
-
Timothy E Baldwin authored
OS_CLI permits commands to be prefixed with a temporary filing system, for example "ADFS:Format" It also passes commands unrecognised to FileSwitch to be executed, so "ADFS::HardDisc4.$.!Boot" first sets the temporary filing to ADFS then executes ":HardDisc4.$.!Boot". This does not work if the path contains a special field, currently this results in an error as the special filed would be lost. Unfortunately many programs, including the RISC OS source fail because of this. Instead if a filing system prefix with special field is found switch to the Temporary filing system and treat the whole command as a path to execute. For example passing "IXFS#W:$.HardDisc4.!Boot" sets the temporary filing system to "IXFS" then executes "IXFS#W:$.HardDisc4.!Boot". Version 6.30. Tagged as 'Kernel-6_30'
-
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'
-
Robert Sprowson authored
Version 6.28. Not tagged
-
- 19 Nov, 2019 2 commits
-
-
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'
-
Timothy E Baldwin authored
* MinAplWork isn't used. * SuperMode isn't used and is less well known than "SWI OS_EnterOS". * MEMCADR is now only a magic value returned by OS_UpdateMEMC, so it is clearer to include it literally with comment. Added a comment to explain the baffling combination of the MEMC1 control register's address with it's value. Version 6.27. Not tagged
-
- 09 Nov, 2019 1 commit
-
-
Timothy E Baldwin authored
This makes SVLK and NVECTORS available. Version 6.27. Tagged as 'Kernel-6_27'
-
- 05 Nov, 2019 3 commits
-
-
Jeffrey Lee authored
Version 6.26. Tagged as 'Kernel-6_26'
-
Jeffrey Lee authored
Detail: Similar to HeapReason_GetAligned, GetSkewAligned is used for allocating aligned blocks (with optional boundary limit). However instead of using the logical address of the user portion of the block for the alignment calculation, it uses an arbitrary offset specified in R5. This makes it useful for clients such as the PCI module, which care about the physical alignment of blocks rather than logical alignment. Admin: Tested with heaptest
-
Jeffrey Lee authored
Detail: Kernel-5_44 tweaked the heap manager to try and avoid creating small free blocks. Adjust HeapTest's block size checks so that it allows for this behaviour. Admin: Tested briefly
-
- 20 Oct, 2019 3 commits
-
-
Timothy E Baldwin authored
Version 6.25. Tagged as 'Kernel-6_25'
-
Timothy E Baldwin authored
Detail: Add offset parameter to DumpyTheRegisters in R4 Shuffle internal register use up one Set R4 to offset before calling. Arbitrary offset of 0 for unreachable address exception handler. Admin: Tested in RPCEmu.
-
Timothy E Baldwin authored
Between RISC OS 3.6 and 3.7 the directory was renamed from Doc to Docs and was duplicated during CVS import. Fix by deleting Doc. Identical files remain in Docs. Version 6.24. Not tagged
-
- 30 Sep, 2019 1 commit
-
-
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'
-
- 21 Sep, 2019 1 commit
-
-
Jeffrey Lee authored
Detail: - s/HAL - Fix ADD v. SUB muddle that could prevent addresses from being rounded down correctly. Fix incorrect logical address being returned to caller on pre-ARMv6 machines due to PageTableSync corrupting a1. - s/NewReset - Initialising the CMOS RAM cache while in the middle of setting up the processor vectors feels a bit silly. Move the code to just afterwards so that it feels a bit safer, and so that early crashes are easier to debug (processor vectors in stable state) Admin: Tested on Iyonix. Fixes ROM softload failure reported on forums: https://www.riscosopen.org/forum/forums/11/topics/14749 Version 6.23. Tagged as 'Kernel-6_23'
-
- 16 Aug, 2019 3 commits
-
-
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'
-
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
-
Ben Avison authored
This is facilitated by two extended calls. From the HAL: * RISCOS_MapInIO64 allows the physical address to be specified as 64-bit From the OS: * OS_Memory 21 acts like OS_Memory 13, but takes a 64-bit physical address There is no need to extend RISCOS_LogToPhys, instead we change its return type to uint64_t. Any existing HALs will only read the a1 register, thereby narrowing the result to 32 bits, which is fine because all existing HALs only expected a 32-bit physical address space anyway. Internally, RISCOS_MapInIO has been rewritten to detect and use supersections for IO regions that end above 4GB. Areas that straddle the 4GB boundary should also work, although if you then search for a sub-area that doesn't, it won't find a match and will instead map it in again using vanilla sections - this is enough of an edge case that I don't think we need to worry about it too much. The rewrite also conveniently fixes a bug in the old code: if the area being mapped in went all the way up to physical address 0xFFFFFFFF (inclusive) then only the first megabyte of the area was actually mapped in due to a loop termination issue. Requires RiscOS/Sources/Programmer/HdrSrc!2
-
- 29 Jun, 2019 1 commit
-
-
Robert Sprowson authored
ControlList_Interlaced is taken to have meant "output interlaced sync on H/V" and "configure DMA to show alternate lines in the framestore on alternate fields", therefore SyncPol flags mean: b43 00 = 'normal' progressive scan 01 = interlaced sync, but both fields show the same image 10 = (invalid) 11 = interlaced sync, fields use alternate lines from the image Version 6.21. Tagged as 'Kernel-6_21'
-
- 23 Jun, 2019 1 commit
-
-
Ben Avison authored
Without this, some CPUs (including Cortex-A72) take the undefined instruction trap when encountering any CP15-encoded barrier instructions. Requires RiscOS/Sources/Programmer/HdrSrc!1 Version 6.20. Tagged as 'Kernel-6_20'
-
- 24 Feb, 2019 1 commit
-
-
Jeffrey Lee authored
Detail: s/vdu/vdudriver - When mapping external framestores, only double-map them if the driver supports hardware scrolling. Avoids wasting IO address space, and reduces IO space fragmentation if the framestore address changes Admin: Tested on Raspberry Pi 3 Version 6.19. Tagged as 'Kernel-6_19'
-
- 20 Jan, 2019 1 commit
-
-
Jeffrey Lee authored
Detail: s/vdu/vdupalxx: - Fix conditional code sequence in PV_BulkWrite which meant that the greyscale palette flag was being recalculated when the border or pointer colour was changed. - Change PV_1stFlashState / PV_2ndFlashState to act as NOPs in true colour modes, which helps to avoid regular redundant gamma table updates (due to the flashing colour logic in the VSync handler). Admin: Tested on Raspberry Pi 3 Version 6.18. Tagged as 'Kernel-6_18'
-
- 29 Nov, 2018 1 commit
-
-
Jeffrey Lee authored
Detail: s/vdu/legacymodes - Make the Service_ModeExtension implementation automatically use ExtraBytes to request that the row length is a multiple of a word (since things fail with non-word aligned rows) hdr/VIDCList - Un-deprecate SyncPol bits 2 & 3 and improve the comments to indicate the difference between SyncPol interlace and control list interlace Admin: Tested on BB-xM Version 6.17. Tagged as 'Kernel-6_17'
-
- 19 Nov, 2018 1 commit
-
-
Jeffrey Lee authored
Detail: s/vdu/vduswis - Fix 18 year old register corruption bug in FindOKMode which would prevent it from falling back to Service_ModeTranslation if Service_ModeExtension returned a VIDC list but the VIDC list was rejected by the GraphicsV driver s/vdu/vdudriver - Also, change a couple of error cases in ModeChangeSub so that they use the "Screen mode not available" error instead of the incorrect "Not enough screen memory" error. Admin: Tested on Raspberry Pi 3 Fixes issue reported on forums where if AnyMode is loaded, numbered modes in unsupported colour depths weren't being replaced with substitutes (although note that there are still some AnyMode-related issues to resolve) https://www.riscosopen.org/forum/forums/4/topics/12773 Version 6.16. Tagged as 'Kernel-6_16'
-
- 14 Nov, 2018 1 commit
-
-
Jeffrey Lee authored
Detail: s/ARMops - If the ICacheInvalidate macro was told to pull a2, it would pull it before invoking ICache_InvalidateRange, causing the end address of the range to be lost. Avoid this by only pulling the registers after the ranged call. Also optimise MMU_ChangingEntry to go straight to ICache_InvalidateRange instead of doing a redundant range size check. Admin: Tested on OMAP5 Potentially fixes lockup/long stall seen when using PhotoDesk, reported by Willi Theiss Version 6.15. Tagged as 'Kernel-6_15'
-
- 07 Nov, 2018 1 commit
-
-
Jeffrey Lee authored
Detail: Over the years the OS's substitute screen mode selection logic has grown to be a tangled mess, and the logic it does implement isn't always very useful. Additionally, the kernel is structured in such a way that it can be hard for modules to override it. This set of changes aims to fix the many of the problems, by doing the following: - Moving all substitute mode selection logic out of the core VDU driver code and into a Service_ModeTranslation handler. This means you now only have one place in the kernel to look instead of several, and modules can override the behaviour by claiming/blocking the service call as appropriate. - Moving handling of the built-in VIDC lists out of the core VDU driver code and into a Service_ModeExtension handler. This means programs can now inspect these VIDC lists by issuing the right service call (although you are essentially limited to lists which the GraphicsV driver is OK with) - Moving *TV interlace & offset adjustment logic into the Service_ModeExtension handler, since they're legacy things which can be handled more cleanly for MDF/EDID (and the old code was poking memory the kernel didn't own) - Adding a Service_EnumerateScreenModes implementation, so that if you end up in the desktop with ScreenModes non-functional, the display manager at least has something useful to show you - Enhancing the handling of the built-in numbered modes so that they are now available in any colour depth; the Service_ModeExtension handler (and related handlers) treat the builtin VIDC lists as a set of mode timings, not a discrete set of modes - Substitute mode selection logic is a complete re-write. Instead of trying a handful of numbered fallback modes, it now tries: - Same mode but at higher colour depths - Same mode but at lower colour depths - Alternate resolutions (half-width mode with no double-pixel if original request was for double-pixel, and default resolution for monitor type) - Combined with the logic to allow the builtin VIDC lists to be used at any colour depth, this means that the kernel should now be able to find substitute modes for machines which lack support for <=8bpp modes (e.g. OMAP5) - Additionally the mode substitution code will attempt to retain as many properties of the originally requested mode as possible (eigen values, gap mode type, etc.) Other improvements: - The kernel now actually vets the builtin VIDC lists instead of assuming that they'll work (which also means they'll have the correct ExtraBytes value, where applicable) - The kernel now uses GraphicsV 19 (VetMode2) to vet the mode during the mode switch process, using the result to detect where the framebuffer will be placed. This allows for GraphicsV drivers to switch between DA 2 and external framestores on a per-mode basis. - The kernel now supports mode selectors which specify LineLength values which are larger than necessary; this will get translated to a suitable ExtraBytes control list item (+ combined with whatever padding the driver indicates is necessary via the VetMode2 result) File changes: - hdr/KernelWS - Reserve space for a VIDC list, since the Service_ModeExtension implementation typically can't use the built-in list as-is - s/Arthur3 - Issue Service_ModeFileChanged when the configured monitor type is changed, so that DisplayManager + friends are aware that the set of available modes has changed - s/GetAll - Fiddle with GETs a bit - s/MemMap2 - Extra LTORG - s/NewIRQs - Small routine to install/uninstall false VSync routine (previously from PushModeInfo, which wasn't really the appropriate place for it) - s/Utility - Hook up the extra service call handlers - s/vdu/legacymodes - New file containing the new service call implementations, and some related code - s/vdu/vdudecl - Move mode workspace definition here, from vdumodes - s/vdu/vdudriver - Remove assorted bits of mode substitution code. Plug in new bits for calling GraphicsV 19 during mode set, and deal with ExtraBytes/LineLength during PushModeInfo - s/vdu/vdumodes - Move some workspace definitions to s/vdu/vdudecl. Tweak how the builtin VIDC lists are stored. - s/vdu/vduswis - Rip out more mode substitution code. Issue Service_ModeFileChanged when monitor type is changed by OS_ScreenMode. Admin: Tested on Raspberry Pi 3, Iyonix, IGEPv5 Version 6.14. Tagged as 'Kernel-6_14'
-
- 26 Oct, 2018 1 commit
-
-
Ben Avison authored
-
- 16 Sep, 2018 1 commit
-
-
Jeffrey Lee authored
Detail: s/vdu/vdudriver - When using mode selector blocks, don't allow the system to switch into double-vertical, double-pixel, or BBC-gap modes which are in colour depths unsupported by the kernel Admin: Tested on BB-xM Version 6.13. Tagged as 'Kernel-6_13'
-
- 04 Aug, 2018 1 commit
-
-
Jeffrey Lee authored
Detail: s/HAL - OS_Hardware 3 (remove HAL device) will now re-scan the device list for the device following the Service_Hardware call, so that the device list won't become corrupt if the service call triggers addition/removal of devices. Admin: Tested on iMX6 *HDMIOff now correctly removes the HDMI audio device and SoundDMA's software mixer device (SoundDMA removes mixer in response to the HDMI audio device vanishing, but re-entrancy bug meant that the HDMI device was left on the list) Note that this only covers re-entrancy via Service_Hardware. OS_Hardware 2/3/4/5 are not re-entrant from other locations (e.g. IRQ handlers or memory allocation service calls). Version 6.12. Tagged as 'Kernel-6_12'
-
- 14 Jul, 2018 1 commit
-
-
Jeffrey Lee authored
Detail: ECFIndex and PalIndex claim to be mode variables, but it's impossible for extension modes to specify their values. Since they're easy to calculate from the ModeFlags and Log2BPP values, drop them from the mode workspace (+ table of builtin modes) and calculate them on the fly instead. File changes: - hdr/KernelWS - Drop ECFIndex & PalIndex from workspace - s/vdu/vdumodes - Adjust workspace definition, drop ECFIndex & PalIndex values from VWSTAB - s/vdu/vdudriver - Remove now-redundant copy loop from ModeChangeSub. Remove code from GenerateModeSelectorVars that sets up the ECFIndex & PalIndex values on the stack - s/vdu/vdugrafl - Adjust copy loop in SwitchOutputToSprite/Mask - s/vdu/vdupalette, s/vdu/vdupalxx - Add GetPalIndex routine to generate PalIndex on the fly. Drop the obsolete 16bpp palette/gamma table and shuffle the other entries to simplify GetPalIndex a bit. - s/vdu/vduplot - Add GetECFIndex routine to generate ECFIndex on the fly. Also, fix things so that mode 0 isn't the only rectangular-pixel mode which uses the special rectangular-pixel ECF patterns (index 0 vs. index 4). Fiddle with ExportedHLine a bit to avoid an out-of-range ADR. - s/NewReset - Fix UAL warning for MOV R0, AppSpaceStart. Adjust memset to not assume 512KB is the correct amount Admin: Tested on Raspberry Pi 3 Version 6.11. Tagged as 'Kernel-6_11'
-
- 08 Jul, 2018 1 commit
-
-
Jeffrey Lee authored
Detail: s/MemInfo - The wrapper around OS_Memory 0 introduced in Kernel-5_35-4_79_2_311 was preserving the wrong PSR field on exit, causing any error generated by the core code to be lost. Admin: Tested on Iyonix Fixes *screensave saving mostly white pixels (address translation for "external" VRAM should have failed and caused ADFS to fall back to a bounce buffer) Is also likely to be the cause of https://www.riscosopen.org/forum/forums/5/topics/11713 (address translation should have failed for soft ROM) Version 6.10. Tagged as 'Kernel-6_10'
-
- 07 Jul, 2018 3 commits
-
-
Jeffrey Lee authored
Detail: Since the current SMP changes are fairly minor, and the trunk is seeing most development, from a maintenance perspective it makes sense to merge the changes to trunk. This will also make sure they get some wider testing ready for when the next round of SMP development takes place. Changes: - Docs/SMP - New docs folder describing SMP-related changes to the HAL and interrupt handling. Some of the IRQ changes can also be taken advantage of by single-core devices, since it introduces a way to describe which interrupt sources can be routed to IRQ & FIQ - Makefile, hdr/DBellDevice, hdr/HALDevice - New HAL device for an inter-processor software-generated interrupt source ("doorbell") - hdr/HALEntries - Reuse the unused matrix keyboard & touchscreen HAL entry points for the new IRQ handling & SMP-related HAL calls - hdr/KernelWS - Bump up MaxInterrupts - hdr/OSMem, s/MemInfo - Introduce OS_Memory 19, to allow for DMA to/from cacheable memory without actually altering the cacheability of the pages (which can be even more tricky in SMP systems than it is in uniprocessor systems) - hdr/Options - Introduce SMP build switch. Currently this controls whether the ARMops will operate in "SMP-friendly" mode or not (when running on MP processors) - s/ARMops, s/MemMap2 - Introduce the ARMv7MP ARMop implementation. Simplify DCache_LineLen / ICache_LineLen handling for WB_CR7_Lx so that it's the plain value rather than log2(n)-2 - s/ExtraSWIs - If ARMops are in SMP-friendly mode, global OS_SynchroniseCodeAreas now only syncs application space and the RMA. This is because there is no trivial MP-safe global IMB operation available. This will also make global OS_SynchroniseCodeAreas significantly slower, but the documentation has always warned against performing a global IMB for just that reason, so code that suffers performance penalties should really try and switch to a ranged IMB. - s/NewIRQs - Update some comments regarding IRQ handler entry/exit conditions Admin: Untested Version 6.09. Tagged as 'Kernel-6_09'
-
Jeffrey Lee authored
Detail: hdr/Options - The setting of the SMP switch can now be controlled by specifying the correct ASFLAGS, e.g. ASFLAGS="-PD \"SMP SETL {FALSE}\"" Admin: Untested Version 6.08, 4.129.2.10. Tagged as 'Kernel-6_08-4_129_2_10'
-
Jeffrey Lee authored
Version 6.08, 4.129.2.9. Tagged as 'Kernel-6_08-4_129_2_9'
-
- 30 Jun, 2018 1 commit
-
-
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'
-
- 16 Jun, 2018 1 commit
-
-
ROOL authored
Detail: NewReset.s: Remove warning about soft reset, this is not supported any longer MsgCode.s: Reload LR after potentially changing mode PMF/osinit.s: Delete vestiges of soft reset support Admin: Submission from Timothy Baldwin. Version 6.07. Tagged as 'Kernel-6_07'
-
- 31 May, 2018 1 commit
-
-
Jeffrey Lee authored
Detail: hdr/VduExt: - Introduce mode variable 13, for specifying the minimum number of screen banks that are guaranteed to be available. Eventually the kernel will make use of this during mode vetting & selection, to give programs a simple and reliable way of selecting banked screen modes. Currently however it's only supported by VideoOverlay and the corresponding GraphicsV overlay APIs. - Extend the mode flags to allow display rotation & flipping to be specified. This is used to indicate that the framebuffer accessed by the CPU is not in the same orientation as what the user is seeing. Again, currently this is only supported by VideoOverlay and the corresponding GraphicsV overlay APIs. Admin: Tested on OMAP3, OMAP4 Version 6.06. Tagged as 'Kernel-6_06'
-
- 14 May, 2018 1 commit
-
-
Jeffrey Lee authored
Version 6.05, 4.129.2.8. Tagged as 'Kernel-6_05-4_129_2_8'
-
- 13 May, 2018 1 commit
-
-
John Ballance authored
Detail: Admin: Version 6.05. Tagged as 'Kernel-6_05'
-
- 24 Apr, 2018 1 commit
-
-
Jeffrey Lee authored
Detail: The error block checks introduced in Kernel-5_35-4_79_2_313 are generating a few too many false positives and edge cases, so take the safe option of just disabling them rather than trying to tweak the rules further. Error pointers will still be checked, but the content of the error blocks will not. hdr/Options - Add CheckErrorBlocks switch so we can easily turn the code back on again in the future if necessary s/Kernel - Switch out all the code relating to error number checks, except for the dummy load of the first word of the error block, since that's still useful as a pointer validity check hdr/KernelWS - Revise SWIDespatch_Size definition so it's easier for it to cope with the various factors which may affect the despatcher size Admin: Tested on PandaBoard Relevant discussion: https://www.riscosopen.org/forum/forums/11/topics/11133 Version 6.04. Tagged as 'Kernel-6_04'
-