GitLab

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/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'

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'

Expand tabs.
Swap DCI for instructions now Objasm 4 is out.
Symbols for FSControl_CAT/RUN/OPT changed to non Arthur definitions.
Still boots on IOMD class, no other testing.

Version 5.35, 4.79.2.124. Tagged as 'Kernel-5_35-4_79_2_124'

Detail:
  A whole mass of changes to add high processor vectors + zero page relocation support to the Cortex branch of the kernel
  At the moment the code can only cope with two ZeroPage locations, &0 and &FFFF0000. But with a bit more tweaking those restrictions can probably be lifted, allowing ZeroPage to be hidden at almost any address (assuming it's fixed at compile time). If I've done my job right, these restrictions should all be enforced by asserts.
  There's a new option, HiProcVecs, in hdr/Options to control whether high processor vectors are used. When enabling it and building a ROM, remember:
  * FPEmulator needs to be built with the FPEAnchor=High option specified in the components file (not FPEAnchorType=High as my FPEmulator commit comments suggested)
  * ShareFS needs unplugging/removing since it can't cope with it yet
  * Iyonix users will need to use the latest ROOL boot sequence, to ensure the softloaded modules are compatible (OMAP, etc. don't really softload much so they're OK with older sequences)
  * However VProtect also needs patching to fix a nasty bug there - http://www.riscosopen.org/tracker/tickets/294
  The only other notable thing I can think of is that the ProcessTransfer code in s/ARM600 & s/VMSAv6 is disabled if high processor vectors are in use (it's fairly safe to say that code is obsolete in HAL builds anyway?)
  Fun challenge for my successor: Try setting ZeroPage to &FFFF00FF (or similar) so its value can be loaded with MVN instead of LDR. Then use positive/negative address offsets to access the contents.
  File changes:
  - hdr/ARMops - Modified ARMop macro to take the ZeroPage pointer as a parameter instead of 'zero'
  - hdr/Copro15ops - Corrected $quick handling in myISB macro
  - hdr/Options - Added ideal setting for us to use for HiProcVecs
  - s/AMBControl/allocate, s/AMBControl/growp, s/AMBControl/mapslot, s/AMBControl/memmap, s/AMBControl/service, s/AMBControl/shrinkp, s/Arthur2, s/Arthur3, s/ArthurSWIs, s/ChangeDyn, s/ExtraSWIs, s/HAL, s/HeapMan, s/Kernel, s/MemInfo, s/Middle, s/ModHand, s/MoreSWIs, s/MsgCode, s/NewIRQs, s/NewReset, s/Oscli, s/PMF/buffer, s/PMF/IIC, s/PMF/i2cutils, s/PMF/key, s/PMF/mouse, s/PMF/osbyte, s/PMF/oseven, s/PMF/osinit, s/PMF/osword, s/PMF/oswrch, s/SWINaming, s/Super1, s/SysComms, s/TickEvents, s/Utility, s/vdu/vdu23, s/vdu/vdudriver, s/vdu/vdugrafl, s/vdu/vdugrafv, s/vdu/vdupalxx, s/vdu/vdupointer, s/vdu/vduswis, s/vdu/vduwrch - Lots of updates to deal with zero page relocation
  - s/ARM600 - UseProcessTransfer option. Zero page relocation support. Deleted pre-HAL ClearPhysRAM code to tidy the file up a bit.
  - s/ARMops - Zero page relocation support. Set CPUFlag_HiProcVecs when high vectors are in use.
  - s/KbdResPC - Disable compilation of dead code
  - s/VMSAv6 - UseProcessTransfer option. Zero page relocation support.
Admin:
  Tested with OMAP & Iyonix ROM softloads, both with high & low zero page.
  High zero page hasn't had extensive testing, but boot sequence + ROM apps seem to work.


Version 5.35, 4.79.2.98.2.48. Tagged as 'Kernel-5_35-4_79_2_98_2_48'

Detail:
  hdr/ARMops - Reserve OS_PlatformFeatures 0 bit 20 for indicating whether high processor vectors are in use
  s/Kernel - Add local definitions of BYTEWS, LDROSB, STROSB, VDWS macros (previously in Hdr:Macros)
  s/MoreComms - Fix potential buffer overflow when filling error buffer (although GSTrans shouldn't overflow the buffer in the first place?)
  s/Arthur2 - GSRead number detection fix
  s/ArthurSWIs - Updated OS_ReadUnsigned to support reading 64bit numbers
  Docs/ReadUnsigned - Docs for the updated OS_ReadUnsigned interface
Admin:
  Untested!
  Needs HdrSrc 1.86


Version 5.35, 4.79.2.120. Tagged as 'Kernel-5_35-4_79_2_120'

Detail:
 * Stopped calling the broken abort fixup code when running under VMSAv6.
   Might be desirable to update it, possibly farmed out to a separate module -
   still need to think about this.
 * Unaligned load optimisations can now be disabled by the global NoUnaligned
   flag for testing purposes.
 * Extended OS_ReadUnsigned to permit reading of 64-bit unsigned integers.
   See Docs.ReadUnsigned for more details. Also sped it up by using MLA
   (or UMLAL) for most digits rather than repeated addition.
 * Bugfix is OS_GSRead: an uninitialised r0 was being passed to
   OS_ReadUnsigned, causing undesirable effects on rare occasions.
Admin:
  Tested on a rev B7 beagleboard.

Version 5.35, 4.79.2.98.2.8. Tagged as 'Kernel-5_35-4_79_2_98_2_8'

Detail:

Admin:
  Tested in ROM at Castle


Version 5.35, 4.79.2.73. Tagged as 'Kernel-5_35-4_79_2_73'

Added UnthreadV (vector &2B). Called near the end of despatch of the outermost interrupt, in IRQ32/26 mode with IRQs disabled, just before transient and non-transient callback checking is performed. Suitable for implementing a CBAI replacement.

Version 5.35, 4.79.2.69. Tagged as 'Kernel-5_35-4_79_2_69'

OSDelink/RelinkApp now work on the list in opposite orders so that the order of vector claims doesn't get toggled.

Fix for *FX5 not working due to a TST having been swapped for CMP.
Checkprotectionlink option added to HAL version so CMOS lock is
implemented.
Updated HAL docs.

Version 5.35, 4.79.2.58. Tagged as 'Kernel-5_35-4_79_2_58'

Detail:
  Lots of changes since last version, at least the following:
  * Updated OS timestamp, removed alpha status
  * Negative INKEY OS version changed to &AA
  * GraphicsV is now alocated vector number &2A
  * ROM moved up to &FC000000
  * Max application slot increased to 512 Mbytes (for now)
  * Max size of RMA increased to 256 Mbytes
  * RMA is now first-created dynamic area (so it gets lowest address after
    top of application slot)
  * OS_Memory 10 reimplemeted
  * New OS_ReadSysInfo 6 values 18-22 added
  * OS_ReadSysInfo 8 gains flag bit to indicate soft power-off
  * Misc internal top-bit-set-address fixes
  * *ChangeDynamicArea can take sizes in megabytes or gigabytes
  * Magic word "&off" in R0 passed to OS_Reset powers down if possible
  * Added acceleration: block copy; CLS; text window scroll up; rectangle
    fill
  * Disabled LED flashing in page mode (liable to crash)
  * Masked sprite plot and VDU 5 text avoids reading the screen if possible
  * Framestore made USR mode accessible
  * Fix for VDU 5,127 bug - now relies on font definitions being in extreme
    quarters of memory, rather than bottom half
  * Allocated 64-bit OS_Convert... SWIs
  * IIC errors use allocated error numbers
  * Looks for Dallas RTC before Philips RTC because we're using a Philips
    NVRAM device with the same ID
  * Fix to bug that meant the oscillator in the Dallas RTC wasn't enabled
  * Default mouse type (USB) changed to allocated number
  * Ram disc max size increased to 128 Mbytes (Ursula merge) and made
    cacheable for StrongARMs (not XScale)
  * Branch through zero handler now works in USR mode, by use of a
    trampoline in the system stack to allow PC-relative register storage
  * Address exception handler changed to not use 0 as workspace
  * OS_Memory 13 extended to allow specification of cacheability and access
    privileges
  * Added OS_Memory 16 to return important memory addresses
  * RISCOS_MapInIO() takes cacheable flag in bit 3, access permissions in
    bits 10 and 11, doubly-mapped flag in bit 20, and access permissions
    specified flag in bit 21
  * Bug fix in last version for application abort handlers didn't quite
    work; register shuffle required
  * "Module is not 32-bit compatible" error now reports the module name
  * Default configured language changed from 10 to 11 (now Desktop again)

Version 5.35, 4.79.2.51. Tagged as 'Kernel-5_35-4_79_2_51'

Version 5.35, 4.79.2.48. Tagged as 'Kernel-5_35-4_79_2_48'

* Allows HAL-driven software resets.
* Sound buffers corrected to be uncacheable.

Version 5.35, 4.79.2.33. Tagged as 'Kernel-5_35-4_79_2_33'

* Kernel puts sensible default FIQ handler in through the HAL.
* Fix to temporary page uncaching code.

Version 5.35, 4.79.2.30. Tagged as 'Kernel-5_35-4_79_2_30'

More stuff. Up to the desktop now; cache on, working keyboard. Some source restructuring to start to make splitting it up into several object files more feasible.

* Added ARM_IMB and ARM_IMBRange SWIs as recommended by ARMv5.
* Some early prototype HAL bits popped in - a lot of source restructuring still
  to come.
* New debug target creates an AIF image with debug information, and translates
  this into an ASCII object file for the 16702B logic analyser.

Version 5.35, 4.79.2.1. Tagged as 'Kernel-5_35-4_79_2_1'

Detail:
	It is often the case that modules fail on receipt of a PostInit
cervice call. The Kernel already has an option to display debugging on module
initialisation (DebugROMInit), but this does not help if a module crashes
during the PostInit stage.
	To aid debugging of the PostInit stage of module initialisation, a
new flag (DebugROMPostInit) has been added to the vanilla service call
handler. This flag displays the name of each module that the PostInit is
being dispatched to, and then displays whether control has passed back to the
kernel. Hence crashes of a module during PostInit can be detected.

Admin:
	Note that this debug option only works in the vanilla service call
handler. If your build uses the chocolate handler and you wish to debug
PostInit of modules, then set it temporarilly to use vanilla handlers.
	Tested in Lazarus builds both with and without the option switched.

Version 5.26. Not tagged

Had one of those weekend brainstorms - managed to speed up SWI despatcher _and_ add Thumb support to it.

Fixed OS_BreakPt - was confused by PC/PSR split.

Version 5.24. Not tagged

Details:
  The Kernel will now compile to produce a pure 32-bit system if No26bitCode is
  set to TRUE.
  If No26bitCode is FALSE, then the Kernel will be a standard 26-bit Kernel,
  although some internal changes have taken place to minimise compile
  switches between the two cases. See Docs.32bit for more technical info.

  The hardest part was the flood-fill...

Other changes:
  Pointer shape changes now take place on the next VSync, rather than actually
  WAITING for the VSync. Turning the Hourglass on shouldn't slow your machine
  down by 5% now :)

  Lots of really crusty pre-IOMD code removed.

Admin:
  Tested in 32 and 26-bit forms in a limited desktop build. Basically, this
  will need to see a lot of use to iron out difficulties. I'd like anyone who
  has a non-frozen project to at least attempt using this Kernel.

Version 5.23. Tagged as 'Kernel-5_23'

Version 4.93. Tagged as 'Kernel-4_93'

Version 4.83. Tagged as 'Kernel-4_83'

* Integrated Ursula fast service call dispatch code.
* Added Interruptible32bitModes from Ursula.
* Stopped allowing ROM modules (other than the Kernel/UtilityModule) to write
  to the hardware vectors in 26-bit mode.

Version 4.81. Tagged as 'Kernel-4_81'