GitLab

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'

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'

Detail:
  hdr/HALDevice - Add new inter-processor communications device type. Add device IDs for Pi/BCM2835 GPIO interface & VCHIQ
  hdr/GPIODevice - Add Raspberry Pi GPIO type & interface revision (currently 'unknown')
Admin:
  Tested in Raspberry Pi ROM with high processor vectors
  New IDs required for BCM2835-0_17


Version 5.35, 4.79.2.147.2.16. Tagged as 'Kernel-5_35-4_79_2_147_2_16'

Detail:
  Revisions Kernel-5_35-4_79_2_153 and Kernel-5_35-4_79_2_161 merged with one
  trivial conflict.
Admin:
  Confirmed that this builds, but not tested on hardware.

Version 5.35, 4.79.2.147.2.15. Tagged as 'Kernel-5_35-4_79_2_147_2_15'

Detail:
  s/NewReset - Change default filesystem to SDFS for ARM11 builds, as that's somewhat more appropriate than ADFS when on the Pi. Also now using filesystem numbers from Hdr:FSNumbers instead of magic numbers.
Admin:
  Builds, but untested


Version 5.35, 4.79.2.147.2.14. Tagged as 'Kernel-5_35-4_79_2_147_2_14'

Detail:
  hdr/HALDevice - Added new device IDs used by BCM2835 DMA controller & DMA channels
Admin:
  Tested in BCM2835 ROM


Version 5.35, 4.79.2.147.2.13. Tagged as 'Kernel-5_35-4_79_2_147_2_13'

Detail:
  s/VMSAv6 - Prefetch abort handler address now looked up as ZeroPage-relative
Admin:
  Tested on Raspberry Pi with high processor vectors
  Previous commit was a harmless, unintentional merge from HAL branch to RPi branch due to folder mixup


Version 5.35, 4.79.2.147.2.12. Tagged as 'Kernel-5_35-4_79_2_147_2_12'

Detail:
  s/VMSAv6 - Prefetch abort handler address now looked up as ZeroPage-relative
Admin:
  Tested on Raspberry Pi with high processor vectors


Version 5.35, 4.79.2.147.2.11. Tagged as 'Kernel-5_35-4_79_2_147_2_11'

Detail:
  s/Middle - Callback and breakpoint environment handler workspace is now specified as being ZeroPage relative
Admin:
  Tested on Raspberry Pi with high processor vectors


Version 5.35, 4.79.2.147.2.10. Tagged as 'Kernel-5_35-4_79_2_147_2_10'

Detail:
  Hdr/HALEntries - Added HAL_UARTDefault entry, as per HAL branch
Admin:
  Untested


Version 5.35, 4.79.2.147.2.9. Tagged as 'Kernel-5_35-4_79_2_147_2_9'

Detail:
  An undocumented entry condition of TickOne is that r0 contains the device
  number corresponding to Timer0. This must be passed to HAL_IRQClear on
  some platforms.
Admin:
  Tested only on a Raspberry Pi. Also added enumeration of entry numbers in
  comments in Hdr:HALEntries - a handy reference when debugging from the
  command line!

Version 5.35, 4.79.2.147.2.8. Tagged as 'Kernel-5_35-4_79_2_147_2_8'

Detail:
  (list files and functions that have changed)
Admin:
  shown running in system
  (highlight level of testing that has taken place)
  (bugfix number if appropriate)


Version 5.35, 4.79.2.147.2.7. Tagged as 'Kernel-5_35-4_79_2_147_2_7'

Detail:
  (list files and functions that have changed)
Admin:
  (highlight level of testing that has taken place)
  (bugfix number if appropriate)


Version 5.35, 4.79.2.147.2.6. Tagged as 'Kernel-5_35-4_79_2_147_2_6'

  1: Added HAL_FramebufferAddress entry.
  2: Minor mod the NoIrqVecSwiDispatch mods recently submitted. Improved coverage
  3: Added compile time switch InverseTextTransparency to toggle sense of text
  (pre-wimp) for use until correct transparency behaviour is introduced in the RPi
  start.elf.
  4: Ensured that if a non aligned frame buffer is reported, ALL of the space
  is actually mapped in.
Detail:
  (list files and functions that have changed)
Admin:
  builds and runs .. Still needs service_mode extension work to replace hard
  coded mode definition files
  (highlight level of testing that has taken place)
  (bugfix number if appropriate)


Version 5.35, 4.79.2.147.2.5. Tagged as 'Kernel-5_35-4_79_2_147_2_5'

Version 5.35, 4.79.2.147.2.4. Tagged as 'Kernel-5_35-4_79_2_147_2_4'

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'

Detail:
  The cache details were previously fixed in a look-up table based upon the
  CPU as determined from the Main ID register for "fancy" ARMv6 CPUs (that is,
  ARMv6K, ARMv6Z, ARMv6T2). So the details for the S3C6410 were being used
  for all ARM1176JZF-S CPUs, which isn't correct for the BCM2835, which has
  the same CPU. Adrian's original stopgap solution was to override the
  settings with a bunch of MOV instructions, which had the effect of making
  the kernel useless on any other CPU. Now the details are read from the ARM
  cache type register for fancy ARMv6 CPUs. This necessitated adding support
  for an extra cache type: writeback, with cache cleaning using R7, and cache
  lockdown format C. Since we don't actually do cache lockdown, this follows
  the same code path as cache lockdown type A, which was originally written
  for ARM9 CPUs.
Admin:
  Tested in a Raspberry Pi build

Version 5.35, 4.79.2.147.2.2. Tagged as 'Kernel-5_35-4_79_2_147_2_2'

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'

Detail:
  In a couple of early exits from LookForHALRTC, R12 was missing from the
  pull macros.
Admin:
  Fix received from John Ballance.

Version 5.35, 4.79.2.147. Tagged as 'Kernel-5_35-4_79_2_147'

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


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

Detail:
  hdr/HALDevice - Add device ID for new SmartReflex-based CPUClk device that takes over from the current OMAP3 one on AM/DM37x devices
Admin:
  Tested in OMAP3 ROM


Version 5.35, 4.79.2.145. Tagged as 'Kernel-5_35-4_79_2_145'

Convrsions.s:
Don't trash R4 in OS_ConvertDateAndTime
Reject buffer sizes > 2G (seems reasonable for a time string, and allows us to claw back a flag bit).
PMF/osword.s:
Just call Territory_ConvertDateAndTime directly since that's all OS_ConvertDateAndTime does.
Trim some now irrelevant comments and switched out code.

Version 5.35, 4.79.2.144. Tagged as 'Kernel-5_35-4_79_2_144'

Detail:
  * As noted in recent commits to ADFS, the *Configure options Dir and NoDir
    haven't done anything since RISC OS 2, so ADFS has stopped reading the
    CMOS bit. Unusually, these options are implemented by the kernel, so this
    is the accompanying change to remove the *Configure options. This frees
    up a bit of CMOS for future re-use.
  * Now exports a C version of Hdr:ModHand.
Admin:
  Builds OK, but not tested in a ROM build yet (should be fairly safe though)

Version 5.35, 4.79.2.143. Tagged as 'Kernel-5_35-4_79_2_143'

Detail:
  s/AMBControl/service - Fix missing colon on end of :OR: operator
Admin:
  Identical binary under objasm


Version 5.35, 4.79.2.142. Tagged as 'Kernel-5_35-4_79_2_142'

On odd numbered versions was coming out as 7F not F7.

Version 5.35, 4.79.2.141. Tagged as 'Kernel-5_35-4_79_2_141'

Detail:
  s/vdu/vdumodes - Mode 47 is 360 pixels wide, so should be 45 text columns, not 90
Admin:
  Tested in Iyonix ROM softload


Version 5.35, 4.79.2.140. Tagged as 'Kernel-5_35-4_79_2_140'

Detail:
  s/NewReset - When resetting the mouse type, for M_32 builds, check what IOMD version is fitted and select Quadrature/PS2 as appropriate
  Falls back to USB if no IOMD/unrecognised IOMD
Admin:
  Tested in IOMD softload on RiscPC


Version 5.35, 4.79.2.139. Tagged as 'Kernel-5_35-4_79_2_139'

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'

The text had cunning hardspaces in it so that the *HELP text lines up nicely using OS_PrettyPrint, but not taking into account that internationalised syntax errors don't use OS_PrettyPrint so output VDU31,31,31 and jumped all over the place.
Syntax message rephrased to fit on one line.
Syntax and help for *TV cleared up since the help text contained all the syntax information.
Spotted 2 wasted instructions in Oscli.s while investigating, added some comments too.

Version 5.35, 4.79.2.137. Tagged as 'Kernel-5_35-4_79_2_137'

When in DebugROMInit=TRUE mode each call to XOS_NewLine also checks and
processes pending callbacks (in VduLF). This makes the USB enumeration
come out in a different order because they're all collected at the end.
As an intermediate step, collect callbacks for DebugROMInit=FALSE too.
Note: developers should not rely on this behaviour, this will be phased
out before the next stable release.

Version 5.35, 4.79.2.136. Tagged as 'Kernel-5_35-4_79_2_136'

Detail:
  s/Oscli - In SysCommsHashedLookup and UtilCommsHashedLookup, check for null hash table entries instead of just blindly calling ModCommsLookUp_AltEntry.
  This fixes an issue where a crash will occur iff:
  (a) You enter a command which has no entry in one of the two hash tables
  (b) The command is a valid command (with a code entry point) if you reinterpret the corresponding module header as a command table
  In reality, for recent versions of RISC OS 5, you'll get a crash only when trying to execute the command 's'. Some previous OS versions (e.g. 5.12) appear to have been immune to the crash.
  If (a) was true but (b) was false the bug would have also resulted in a small performance hit caused by attempting to scan the module headers for matching commands.
Admin:
  Tested in Tungsten & OMAP ROM builds
  's' no longer crashes, and commands included in the two hash tables still seem to function as normal.
  Fixes issue reported on forums:
  http://www.riscosopen.org/forum/forums/4/topics/902


Version 5.35, 4.79.2.135. Tagged as 'Kernel-5_35-4_79_2_135'

Version 5.35, 4.79.2.134. Tagged as 'Kernel-5_35-4_79_2_134'

Add two more DebugTX in the reset sequence to announce power on reset and CMOS reset code paths.
In STB land the range of permitted dates is extended from 2020 (a bit close!) to 2037 when Unix time wraps.

Version 5.35, 4.79.2.133. Tagged as 'Kernel-5_35-4_79_2_133'

Version 5.35, 4.79.2.132. Tagged as 'Kernel-5_35-4_79_2_132'

Version 5.35, 4.79.2.131. Tagged as 'Kernel-5_35-4_79_2_131'

Detail:
  s/HeapMan - The code to check if it's safe to shrink a block by 4 bytes assumed 'addr' was the address of the block, when in reality it's just an offset. This was causing the "OK to shrink?" check to always ignore the shrink request on heaps located below the 2G limit, but fail with "heap corrupt" errors in heaps located above the 2G limit.
  s/ArthurSWIs - Fix stack imbalance causing a crash if OS_Heap returns an unexpected error in DoSysHeapOpWithExtension/ClaimSysHeapNode
Admin:
  Tested in Iyonix ROM softload
  Testbed didn't pick up heap shrink bug due to the sanity checks it performs not being vigorous enough.


Version 5.35, 4.79.2.130. Tagged as 'Kernel-5_35-4_79_2_130'

Detail:
  TestSrc/HeapTest/c/testbed - Added missing semicolon
  TestSrc/HeapTest/s/asm - Include Hdr:MsgTrans for XMessageTrans_CopyError
Admin:
  Now compiles and runs properly!


Version 5.35, 4.79.2.129. Tagged as 'Kernel-5_35-4_79_2_129'

Improve heap manager. Add heap testbed. Add dummy implementation of some OS_ScreenMode reason codes.

Detail:
  s/HeapMan, hdr/KernelWS - Heap manager improvements:
    - Errors generated by interrupted heap operations that are forced to complete by a OS_Heap call from the background are now cached in kernel workspace until the foreground task is resumed. This prevents them from being potentially overwritten by MessageTrans running out of background error buffers.
    - Added new OS_Heap reason code, #7 - Get area aligned. This allows areas of memory to be allocated at specific (power-of-2) alignments, and optionally without crossing a given (power-of-2) boundary. Alignment & boundary calculations are performed using logical addresses.
    - Removed the limitation that all free and allocated blocks must be a multiple of 8 bytes in length. This change was required in order to allow OS_Heap 7 to function correctly. Now the only requirements are that blocks must be multiples of 4 bytes in length, at 4 byte alignment, with a minimum length of 8 bytes. 4 extra padding bytes may still be added to the end of allocations in order to avoid creating 4-byte free blocks.
  s/HeapMan, TestSrc/HeapTest/Makefile, TestSrc/HeapTest/c/testbed, TestSrc/HeapTest/s/asm - Added heap testbed program. Can either use the OS_Heap SWI or directly include a copy of the Kernel's heap manager sources.
  s/vdudecl, s/vduswis - Added dummy implementations of OS_ScreenMode 4, 5 and 6. This prevents the Wimp generating lots of "Unknown OS_ScreenMode reason code" errors when redrawing the screen.
  s/Arthur3, s/Oscli - Moved dotstring closer to where it's used to avoid "ADRL out of range" errors in Tungsten build
Admin:
  Tested in OMAP3 ROM & Tungsten ROM softload.
  Heap testbed successfully performed over 400 million heap ops, so there shouldn't be any serious bugs in the new code (touch wood)


Version 5.35, 4.79.2.128. Tagged as 'Kernel-5_35-4_79_2_128'

Export less in hdr:RISCOS.
Delete unused GetDecimalPair routine.
Move CheckYear with other RTC stuff out of PMF/osword.
Hide DebugROMInit and DebugROMErrors in release (even numbered) versions.

Version 5.35, 4.79.2.127. Tagged as 'Kernel-5_35-4_79_2_127'