GitLab

Detail:
  s/vdu/vduswis - Add an extra LTORG that's within range of LDR r14,=&1FFF instruction
Admin:
  Tested in Iyonix softload
  Fixes build errors for Tungsten ROM, should fix IOMD + BCM2835 too.


Version 5.35, 4.79.2.195. Tagged as 'Kernel-5_35-4_79_2_195'

Add support for the new RISC OS 5 style sprite mode word. Add partial support for alpha channel sprite masks. Implement OS_ScreenMode reasons 13-15

Detail:
  ECFShift/ECFYOffset:
  - hdr/PublicWS - Add ECFShift and ECFYOffset to list of public exports (SpriteExtend was using hardcoded values). Rearrange exports so that VduWorkspace exports are now labelled as such.
  - hdr/KernelWS - Make sure ECFShift & ECFYOffset match their exported locations
  - hdr/OSRSI6, s/Middle - Add OS_ReadSysInfo 6 items 83 & 84, for reading ECFYOffset and ECFShift locations
  Mode flags/VDU variables:
  - Makefile - Add hdr/VduExt to the C header exports
  - hdr/VduExt - Get rid of NotRVVTBarWobblyBits macro and defined VDU variables manually so that Hdr2H will handle them. Begin replacing overly generic 'Flag_*' mode flag definitions with 'ModeFlag_*' instead. Define new flags as required by the new screen/sprite modes. Add OS_ScreenMode reason codes and mode selector format (from s.vdu.vdudecl)
  - NewModes/NEWF2, NewModes/O...

Step changes in RealTime are now accompanied by a service call. Note the initial read isn't announced, mainly because this is before the module chain is started so nobody's listening anyway.

Version 5.35, 4.79.2.193. Tagged as 'Kernel-5_35-4_79_2_193'

Version 5.35, 4.79.2.192. Tagged as 'Kernel-5_35-4_79_2_192'

Version 5.35, 4.79.2.191. Tagged as 'Kernel-5_35-4_79_2_191'

Version 5.35, 4.79.2.190. Tagged as 'Kernel-5_35-4_79_2_190'

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'

Detail:
  s/Middle - If the HAL provides an extended machine ID, make sure OS_ReadSysInfo 4 doesn't return a MAC address. This is because the old-style machine ID which the MAC is extracted from will be completely synthetic and is so known not to contain a MAC (even if it may look like it does)
Admin:
  Tested on BB-xM, Raspberry Pi


Version 5.35, 4.79.2.188. Tagged as 'Kernel-5_35-4_79_2_188'

GPIODevice: defines for OMAP4 targets
KernelWS: bump up the IICBus_Count from 3 to 4

Version 5.35, 4.79.2.187. Tagged as 'Kernel-5_35-4_79_2_187'

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'

The three subreasons were being dealt with as follows

8  - time only => convert time; read clock & convert that; mix; to UTC; set
15 - date only => convert date; to UTC; set
24 - both      => convert both; to UTC; set

So subreason 15 ended up setting the clock with the UTC date not taking into account any rollover/under due to the timezone. Now, the behaviour is

15 - date only => convert date; read clock & convert that; mix; to UTC; set

An example program to illustrate this is

 DIM block 128
 REM Example boundary case for -ve timezone
 REM *config.timezone -5
 REM TIME$="Sun,01 Jan 2013.19:01:00"

 REM Example boundary case for +ve timezone
 *config.timezone 5
 TIME$="Sun,01 Jan 2013.04:59:00"

 PRINT"Local => ";TIME$
 FOR i = 1 TO 31
  block?0=15
  $(block+1)="Sun,"+RIGHT$("0"+STR$i,2)+" Jan 2013"+CHR$0
  SYS"OS_Word",15,block
  OSCLI"echo <sys$time> <sys$date> <sys$year>"
 NEXT

Fault originates in Kernel-4_63-1_1_2_2.
Fixes ticket #230.

Version 5.35, 4.79.2.185. Tagged as 'Kernel-5_35-4_79_2_185'

hdr/Options: Switch removed
s/Modhand: Switch removed, now considered equivalent to DebugROMInit. DebugROMInit changed so that the callback ordering is as expected, batched up until "callbacks" is hit after Service_PostInit.
PMF/osbyte: Redundant RISC OS 2.01 code deleted

Version 5.35, 4.79.2.184. Tagged as 'Kernel-5_35-4_79_2_184'

Not tagged.

Not tagged.

SystemName, ROMSizeOffset, HAL32, HAL26 only used here, moved here.
Remove uses of "M_" booleans, apparently that's bad form.
Fix SWIDespatch_Size for the non thumb capable case (was ASSERTing).
Swapped UserMemStart for AppSpaceStart.
Removed last use of OldComboSupport (pre Medusa!).
Removed switch 'CDVPoduleIRQs', a correction to the machine definitions mean this can now simply be switched on NumberOfPodules (previously, IOMD couldn't chain podule interrupts).
Take out disabled sub interrupt support - it's in CVS if you want to try to get it working.
Moved ConfiguredLang to 11 for everyone, it only matters if !Boot fails, and no harm in making it common for 5.xx onwards.

Version 5.35, 4.79.2.183. Tagged as 'Kernel-5_35-4_79_2_183'

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'

OS_CallAfter and OS_CallEvery were treating the delay in R0 as a signed number, limiting its possible range. The PRM didn't require this (a -ve delay doesn't make sense, so implicitly times are unsigned), reworked to allow times up to 0xFFFFFBFF.
Aside:
  OSLib exports these functions as 'int', but it doesn't seem to make a distinction for unsigned versus signed anyway (other unsigned arguments are plain int too)
  The 'callx' library was already prototyped with unsigned times back in 1997

Added comment to hdr/Options about FirstUnpluggableModule - since the keyboard and mouse drivers got moved out of the kernel in 3.50, the original intent (to not allow you to unplug vital modules) has long since been lost, and really the only use of this value is to save 8 bits of CMOS frugal bits.

Version 5.35, 4.79.2.181. Tagged as 'Kernel-5_35-4_79_2_181'

Permits applications to query what value would be used in the event of a CMOS reset for a given configure value. Notably, the configure plugins will use this in favour of 'ResetCMOS'.
hdr/Options: retire the 'Select16BitSound' switch, add comment for ChecksumCMOS switch
hdr/KernelWS: DuffEntry and Nowhere moved here
Kernel.s: Unused OSMD removed, retire single use of SPIRQ in favour of r13_irq
Middle.s: Retire SPIRQ
NewReset.s: Trim out 300+ lines of CMOS reset defaults, call OS_NVMemory 6 instead
PMF/i2cutils.s: CMOS reset default code and table moved here with refactoring
Note, the previous code preserved YearCMOS during the zeroing, only to unconditionally write it later - so have removed it from the zeroing step.
Note, the locations 80-111 are now considered as system CMOS in the allocations hence are now wiped too (previously they got skipped as user CMOS during R-power-on).

Tested on OMAP3 ROM with delete-power-on and R-power-on variants, and a simple BASIC program to read locations 0-255 via OS_NVMemory.

Version 5.35, 4.79.2.180. Tagged as 'Kernel-5_35-4_79_2_180'

Detail:
  s/vdu/vducursoft - TeletextFlashTest now stores the updated TeletextCount before calling SetVinit. This provides some protection against getting stuck in an infinite loop (+ stack overflow) if SetVinit takes longer than 1 VSync to complete (or some other catastrophe occurs)
Admin:
  Tested on Raspberry Pi


Version 5.35, 4.79.2.179. Tagged as 'Kernel-5_35-4_79_2_179'

Detail:
  s/Middle - Added OS_ReadSysInfo 13 to allow the kernel to validate a key handler before the owner attempts to install it
  Resources/UK/Messages - Text for new "Bad key handler" error
  s/GetAll, s/PMF/Def - Get rid of now obsolete s/PMF/Def file. It only contained definitions for pre-HAL hardware, and for the key handler layout (now in Hdr:Keyboard)
  hdr/KeyWS - Increased size of KeysDown array so it can hold 768 keys instead of 160. Trim a couple of obsolete variables, and increase CurrKey/OldKey from 1 byte to 4 bytes.
  s/PMF/key, s/PMF/osbyte - Main bulk of the changes for the new key handling. All the important interfaces are now able to deal with extended (i.e. > 8 bit) internal key numbers, and the kernel is able to cope with key handlers which use 16 bit internal/low level key numbers instead of 8 bit.
Admin:
  Tested on Pandora & BB-xM
  Requires HdrSrc-2_20


Version 5.35, 4.79.2.178. Tagged as 'Kernel-5_35-4_79_2_178'

Detail:
  hdr/HALDevice - Added HALDeviceSysPeri_BMU device type and some device IDs for the BMUs in the Pandora & TouchBook
Admin:
  Tested in OMAP3 ROM build


Version 5.35, 4.79.2.177. Tagged as 'Kernel-5_35-4_79_2_177'

Temporary assignment changed to one from Hdr:NewErrors.

Version 5.35, 4.79.2.176. Tagged as 'Kernel-5_35-4_79_2_176'

More haste, less speed. Retagged as Kernel-5_35-4_79_2_175.

Version 5.35, 4.79.2.175. Tagged as 'Kernel-5_35-4_79_2_175'

Variously the call to TranslateError was either followed (outside the switch) by an unnecessary SETV, or missing SETV for the non international case.
Added DMA controller HAL device for IOMD.

Version 5.35, 4.79.2.174. Tagged as 'Kernel-5_35-4_79_2_174'

Detail:
  s/ARMops - Added branch predictor maintenance to WB_CR7_LDa ARMops. If the entire instruction cache is being invalidated then the branch predictors will be invalidated for us, but for ranged invalidation we need to handle it ourselves.
Admin:
  Tested briefly on Raspberry Pi with high processor vectors
  Appears to fix Configure and its plugins misbehaving in various ways


Version 5.35, 4.79.2.173. Tagged as 'Kernel-5_35-4_79_2_173'

Detail:
  s/NewReset - WimpIconiseButton is bit 7 of WimpDragMoveLimitCMOS, not bit 2
Admin:
  Tested on Raspberry Pi


Version 5.35, 4.79.2.172. Tagged as 'Kernel-5_35-4_79_2_172'

Default CMOS tweaks now apply for the RPi hardware. Was missed in
the previous commit.

You can now build the Kernel without the ROM debug output stuff
that's enabled for odd-numbered builds, by passing FREEZE_DEV_REL=TRUE
into the makefile. For example, in the Components file, you'd add:

  -options FREEZE_DEV_REL=TRUE

onto the Kernel line.

Version 5.35, 4.79.2.171. Tagged as 'Kernel-5_35-4_79_2_171'

The kernel recently took back ownership of the *CACHE command and it's configure counterpart, but wasn't reading the CMOS value on startup.
Spotted while looking at bus transactions on IOMD, and wondering where they all are, then realising it's all running from the cache.

Version 5.35, 4.79.2.170. Tagged as 'Kernel-5_35-4_79_2_170'

- LMTransport IP (was NetBEUI)
- FreewayAutoAddress now "off"
- WimpIconiseButton now "on"
- CDROMDrives now 0 for RPi (was 1)

Version 5.35, 4.79.2.169. Tagged as 'Kernel-5_35-4_79_2_169'

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'

STB default = off, desktop default = on.
Collapsed single use of 'ErrorsInR0' switch.

Version 5.35, 4.79.2.167. Tagged as 'Kernel-5_35-4_79_2_167'

Detail:
  hdr/HALDevice - Added new HID device type, Keyboard sub-type, and Pandora keyboard device ID
Admin:
  Tested on Pandora, rev C2 BB, rev A2 BB-xM, rev C1 TouchBook


Version 5.35, 4.79.2.166. Tagged as 'Kernel-5_35-4_79_2_166'

Detail:
  Merge the RPi branch with the HAL branch, ending RPi branch development
  Brief summary of changes brought in:
  * Added HAL_VideoStartupMode to allow the HAL to specify a startup mode for the OS
  * Fixed addresses being sent to GraphicsV_SetDMAAddress being wrong for external framestores (addresses were given as if internal framestore was in use)
  * Add InverseTextTransparency option for limited compile-time support for targets where framebuffer alpha channel is important
  * Fix ConfiguredLanguage for non-Tungsten builds
  * Update ARMv6 CPU detection to read cache parameters from cache type register instead of using KnownCPUTable
  * Add HALDebugHexTX/TX2/TX4 debug routines for writing out numbers via HAL
  * Use HAL_TimerIRQClear when clearing timer 0 interrupt instead of just HAL_IRQClear
  * Initialise FileLangCMOS using defines from Hdr:FSNumbers instead of magic numbers. Use SDFS on M_ARM11ZF.
  * Improved software mouse pointer support; software pointer now removed & restored in some of the same places the text cursor is
  * Improve support for external framestores; driver is now able to grow/shrink/move the framestore on mode changes if bit 5 of GraphicsV_DisplayFeatures R0 is set
  * GraphicsV_FramestoreAddress now has a default claimant which calls HAL_VideoFramestoreAddress
Admin:
  Tested on Raspberry Pi, Iyonix, OMAP3, IOMD


Version 5.35, 4.79.2.165. Tagged as 'Kernel-5_35-4_79_2_165'

Detail:
  Merge the HAL branch into the RPi branch, prior to merging RPi to HAL
  Brief summary of main changes brought in:
  * Added *cache functionality previously provided by ARM module
  * Added "CMOS RAM reset" message on startup when CMOS has been wiped by keypress
  * Renamed HAL Video entries from HAL_Video_XXX to HAL_VideoXXX
  * Dropped mjsHAL macros, GRAB/STASH macros
  * Fixed pseudo-VRAM allocation when machine has exactly 16MB of RAM
  * Added OS_Hardware 5
  * Use OS_SerialOp GetDeviceName for getting serial device name
  * Drop HAL_MonitorLeadID
  * Rework default GraphicsV_IICOp handler
Admin:
  Tested on Raspberry Pi with high processor vectors


Version 5.35, 4.79.2.147.2.23. Tagged as 'Kernel-5_35-4_79_2_147_2_23'

Fix addresses sent to GraphicsV_SetDMAAddress when external framestore in use. Add ID for BCM2835 VDU HAL device.

Detail:
  hdr/KernelWS, s/vdu/vdudriver, s/vdu/vduwrch - Fixed wrong addresses being sent to GraphicsV_SetDMAAddress when an external framestore is in use. Previously VideoPhysAddr was being treated as if it was the base of screen memory, but that's only the case if an internal framestore is in use. Since VideoPhysAddr is part of PhysRamTable it's not possible to change it to point to an external framestore, so a new workspace variable, TrueVideoPhysAddr, is used instead.
  hdr/HALDevice - Added device ID for BCM2835 VDU device
  s/PMF/IIC - Corrected an incorrect comment in IICDoOp
Admin:
  Tested on Raspberry Pi with high processor vectors


Version 5.35, 4.79.2.147.2.22. Tagged as 'Kernel-5_35-4_79_2_147_2_22'

Detail:
  hdr/GPIODevice - Removed existing 'unknown' revision and added 'B rev 1' and 'B rev 2' in its place, ready for new HAL that can report the board revision.
Admin:
  Tested on Raspberry Pi (B rev 1)


Version 5.35, 4.79.2.147.2.21. Tagged as 'Kernel-5_35-4_79_2_147_2_21'

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'

Version 5.35, 4.79.2.147.2.19. Tagged as 'Kernel-5_35-4_79_2_147_2_19'