GitLab

Detail:
Admin:


Version 5.35, 4.79.2.246. Tagged as 'Kernel-5_35-4_79_2_246'

Detail:
  s/Arthur2 - OS_GSTrans now uses the same rules as OS_SetVarValue when deciding whether text within angle brackets is a valid system variable name or not. In particular spaces in the middle of a variable name are no longer considered valid, so expressions such as "*If 0<1 AND 1>0 then echo true" now have the expected result
  Also replaced the magic constant used for the name buffer length with a proper symbolic value, and tweaked its handling a bit in order to increase the maximum permissible variable name length from 253 chars to 255 (although OS_SetVarVal allows longer)
Admin:
  Tested on Iyonix
  Fixes issue reported on forums:
  https://www.riscosopen.org/forum/forums/4/topics/2912


Version 5.35, 4.79.2.245. Tagged as 'Kernel-5_35-4_79_2_245'

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'

Add an extra entry for a revised power control/overcurrent monitoring API, more closely following the model that HAL_TimerIRQStatus and HAL_TimerIRQClear uses.

Version 5.35, 4.79.2.243. Tagged as 'Kernel-5_35-4_79_2_243'

Version 5.35, 4.79.2.242. Tagged as 'Kernel-5_35-4_79_2_242'

Detail:
  hdr/HALDevice - Added some extra HAL device IDs
Admin:
  Tested by building BCM2835 ROM


Version 5.35, 4.79.2.241. Tagged as 'Kernel-5_35-4_79_2_241'

Detail:
Recent kernal changes appear to have enabled lazy task swapping, which brought
up a data alignment abort whilst compiling the source tree using a rom compiled
from this tree. Simple change added
to AMB_MakeHonestLA and PN routines to avoid this.

Admin:
  (highlight level of testing that has taken place)
  (bugfix number if appropriate)


Version 5.35, 4.79.2.240. Tagged as 'Kernel-5_35-4_79_2_240'

When HAL_NVMemoryType reports NVMemoryFlag_MaybeIIC the kernel tries to probe a number of common/known addresses on startup, however the result of the probe is stored around line 1346 without a value value for zero page in R2.
This is sufficiently early on that the default data abort handler (from when probing the ARM's abort model) is still in place so the stores are silently skipped.
Due to the RAM clear the NVRamBase (and size) are 0, which later on in ValChecksum result in a zero length IIC probe to address &01.
Now, R2 is initialised.

Version 5.35, 4.79.2.239. Tagged as 'Kernel-5_35-4_79_2_239'

Detail:
  s/vdu/vdudecl - Add a couple more optimisations to LoadCoordPair - use SXTH where possible, and use LDRSH if data is halfword aligned (not currently the case, but may be in future)
  s/vdu/vdugrafj - Fix PreCreateHeader to allow <=256 colour RISC OS 5 sprites to have palettes
Admin:
  Tested on Pandaboard


Version 5.35, 4.79.2.238. Tagged as 'Kernel-5_35-4_79_2_238'

Detail:
  s/vdu/vdugrafk - When saving a new format sprite that would otherwise contain lefthand wastage, copy each screen row to a temporary buffer before saving it out in order to allow the wastage to be removed
Admin:
  Tested on Pandaboard
  Fixes issue reported on forums:
  https://www.riscosopen.org/forum/forums/4/topics/2802


Version 5.35, 4.79.2.237. Tagged as 'Kernel-5_35-4_79_2_237'

Detail:
  hdr/KernelWS - Enlarge the SkippedTables area to encompass IICBus_Base
  s/PMF/IIC - Manually set IICBus_Status of each bus to 0 within IICInit
Admin:
  Bug was introduced in Kernel-5_35-4_79_2_168 when IIC initialisation was moved to earlier in the ROM init sequence, but has gone unnoticed due to it only really affecting the high-level API (and none of the relevant HALs were relying on the kernel for the RAM clear)
  Tested on BB-xM with kernel RAM clear


Version 5.35, 4.79.2.236. Tagged as 'Kernel-5_35-4_79_2_236'

Add more HAL USB definitions to hdr/HALEntries. Add debug option for calling HangWatch_Dump on serious errors.

Detail:
  hdr/HALEntries - Added definition of the struct returned by HAL_USBControllerInfo
  hdr/Options, s/Middle - Added the option to call HangWatch_Dump on serious errors
Admin:
  Tested on BB-xM


Version 5.35, 4.79.2.235. Tagged as 'Kernel-5_35-4_79_2_235'

Detail:
  s.NewReset line 1304 amended to use this variable. It was
  hard codede to 128MB as a compromise between address space reservation and size.
Admin:
  Tested OK to expand to 511MB in task manager. At 512MB the taskmanager window fails.
JB

Version 5.35, 4.79.2.234. Tagged as 'Kernel-5_35-4_79_2_234'

  Admin:
JB

Version 5.35, 4.79.2.233. Tagged as 'Kernel-5_35-4_79_2_233'

JB

Version 5.35, 4.79.2.232. Tagged as 'Kernel-5_35-4_79_2_232'

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'

Detail:
  hdr/VIDCList - ControlList_Interlaced is no longer deprecated, instead the sync/pol flags are.
  See discussion on forums for context:
  https://www.riscosopen.org/forum/forums/3/topics/309?page=9#posts-34152
Admin:
  Tested on BB-xM


Version 5.35, 4.79.2.230. Tagged as 'Kernel-5_35-4_79_2_230'

Detail:
  Also added model A for completeness.
Admin:
  Required by new version of BCM2835 HAL.


Version 5.35, 4.79.2.229. Tagged as 'Kernel-5_35-4_79_2_229'

Need a custom ROM stage as the Kernel is linked as a binary, and a custom exports phase as the AAsmModule makefile tops out at 3 exported headers, but otherwise the rest can be shared.
Tested in an IOMD ROM build.

Version 5.35, 4.79.2.228. Tagged as 'Kernel-5_35-4_79_2_228'

Detail:
  hdr/HALEntries - Added definitions for the different USB controller types reported by HAL_USBControllerInfo
Admin:
  Tested on Raspberry Pi


Version 5.35, 4.79.2.227. Tagged as 'Kernel-5_35-4_79_2_227'

Detail:
  s/MemInfo - Fixed typo causing build error with HiProcVecs/zero page relocated kernel
  s/PMF/osinit - Fix the call to GraphicsV_StartupMode to work correctly with non-zero driver numbers
Admin:
  Tested on BB-xM with high processor vectors


Version 5.35, 4.79.2.226. Tagged as 'Kernel-5_35-4_79_2_226'

Detail:
  s/NewReset - During ROM init, keep application space mostly empty instead of attempting to move all RAM into it. This prevents the page order from being reversed, ensuring that in systems with two or more memory speeds the ROM modules get to use the fast RAM instead of the slow RAM (see free pool initialisation logic in InitDynamicAreas)
  After ROM module init, rebalance memory between the free pool and application space so that they each get 50%. This will provide plenty of memory for the boot sequence and any single-tasking stuff (e.g. booting into BASIC), without starving the free pool of memory and breaking any background processes like USB.
Admin:
  Tested on BB-xM
  Fixes issue where USB devices would fail to initialise properly on some systems due to the boot sequence temporarily locking application space while the free pool is empty


Version 5.35, 4.79.2.225. Tagged as 'Kernel-5_35-4_79_2_225'

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'

Detail:
  s/ARM600, s/VMSAv6 - Disable ProcessTransfer code for all kernel configurations.
  For VMSAv6 it was definitely broken (needs to be taught about VMSAv6 page tables and ARMv6+ unaligned loads).
  For ARM600 it seems to work OK, but is of no real use as (a) we're always running in 32bit mode and so don't need to worry about processor vector writes and (b) OS_AbortTrap isn't implemented so there's no way for anyone to register an abort handling routine.
  Code is being kept around instead of deleting it straight away just in case there are some hidden knock-ons to disabling it, or we decide to implement our own OS_AbortTrap some day.
Admin:
  Tested on Iyonix, BB-xM


Version 5.35, 4.79.2.223. Tagged as 'Kernel-5_35-4_79_2_223'

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 compatibility, Service_ValidateAddress is still issued for any areas which the kernel doesn't recognise (currently, OS_Memory 24 doesn't issue any service calls itself)
  s/Convrsions - ADR -> ADRL to keep things happy
  s/HAL - Fix L2PT page allocation and RAM clear to release the physical access region once they're done with it
  s/Kernel - Make the error dispatcher validate the error handler code ptr & error buffer using OS_Memory 24 before attempting to use them. If they look bad, reset to default. Should prevent getting stuck in an infinite abort loop in some situations (e.g. as was the case with ticket 279). The system might not fully recover, but it's better than a hard crash.
  s/Middle - Rework data/prefetch/etc. abort handlers so that DumpyTheRegisters can validate the exception dump area via OS_Memory 24 before anything gets written to it. Should also help to prevent some infinite abort loops. Strip 26bit/pre-HAL code to make things a bit more readable.
  hdr/KernelWS - Update comment
Admin:
  Tested on BB-xM, Raspberry Pi


Version 5.35, 4.79.2.222. Tagged as 'Kernel-5_35-4_79_2_222'

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'

Detail:
  s/PMF/osinit, s/vdu/vdudriver - Move GraphicsV_StartupMode call from InitialiseMode to TranslateMonitorLeadType. This means (a) it'll only be used if the CMOS mode is set to 'auto' and (b) the returned mode can more easily be read by other modules via OS_ReadSysInfo 1.
  s/vdu/vduswis - Make OS_CheckModeValid act as if we have practically unlimited screen memory if using a GraphcisV driver with variable external framestore. In this case it's the driver should have already OK'd the memory requirements from within the VetMode call issued by FindOKMode - although the check won't be fully valid if we're checking for a shadow mode as the driver currently isn't told how many screen banks are required.
Admin:
  Tested on Raspberry Pi
  OS_CheckModeValid fix ensures valid modes which require large amounts of VRAM are reported correctly when we're currently in a low-memory mode


Version 5.35, 4.79.2.220. Tagged as 'Kernel-5_35-4_79_2_220'

Detail:
  s/vdu/vdumodes - Redefine VgaX_7 to be VLM_7 if HiResTTX/TTX256 in use
Admin:
  Tested on Raspberry Pi
  Fixes nasty crash when selecting mode 7 without an MDF loaded due to VIDC list being mismatched with code/VWSTAB


Version 5.35, 4.79.2.219. Tagged as 'Kernel-5_35-4_79_2_219'

The only function to use the abandoned extensions to OS_ClaimDeviceVector, the 2nd & 3rd members of the structure never got used.
Change uses of HAL_IICDevice to pass in the bus, and expect the device number back.
Docs updated accordingly.

Version 5.35, 4.79.2.218. Tagged as 'Kernel-5_35-4_79_2_218'

Detail:
Admin:


Version 5.35, 4.79.2.217. Tagged as 'Kernel-5_35-4_79_2_217'

Detail:
  hdr/VduExt - Define new Service_DisplayChanged reason code for us to issue before anything actually happens. Define new Service_DisplayStatus reason codes for drivers to issue when they change their configuration/capabilities in some way.
  s/Utility - Listen out for Service_DisplayStatus
  s/vdu/vdudriver - When DisplayStatus_Changing/DisplayStatus_Changed is received for the current driver, translate into the appropriate DisplayChanged reason codes so that software which only cares about the current driver doesn't have two sets of service calls to listen out for
  s/vdu/vduswis - When switching driver in OS_ScreenMode 11, issue the new Service_DisplayChanged PreChanging reason code before we update the current GraphicsV driver VDU variable
Admin:
  Tested in Iyonix ROM softload


Version 5.35, 4.79.2.216. Tagged as 'Kernel-5_35-4_79_2_216'

  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'

ClearPhysRAM runs after ARM_Analyse and would wipe out the RAM copies of the various CP15 registers defining which caches are present, leading to the IMB_Full and IMB_Range operations skipping most of their job.
Space freed below DebuggerSpace by moving the RAM copies of the processor vectors up a bit.
Tested with a nobbled HAL which doesn't do the RAM clear, inspecting the workspace in a debugger to see it's preserved (only affects VSMAv6 models).

Version 5.35, 4.79.2.214. Tagged as 'Kernel-5_35-4_79_2_214'

Fix OS_SpriteOp 41 (read pixel) for 4K colour sprites. Update ECF patterns to work sensibly in true colour modes.

Detail:
  s/vdu/vdugrafg - Change SetupSprModeData to calculate SprReadNColour from log2bpp instead of the NColour mode variable - fixes the alpha component being lost when using OS_SpriteOp 41 to read from 4K colour sprites with alpha channels
  s/vdu/vdudriver - Change SetCol30 to generate more sensible ECF colour blocks when in true colour modes. Previously it would treat each byte of the 8 byte ECF pattern as a separate row, and replicate the byte 4 times to produce one colour word per row. However this isn't so great for true colour modes, especially if you have an alpha channel which needs specific values. So to fix the issue, take inspiration from how Paint assumed the ECF patterns worked, and treat 16bpp modes as being a 1x4 pattern and 32bpp modes as being a 1x2 pattern
Admin:
  Tested on BB-xM
  OS_SpriteOp 41 fix fixes Paint colour picker always returning 0 alpha when picking from 4K ARGB sprites
  ECF change fixes Paint's masked sprite background ECF pattern to display properly in true colour modes


Version 5.35, 4.79.2.213. Tagged as 'Kernel-5_35-4_79_2_213'

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'

Detail:
  s/ARM600, s/VMSAv6 - When processing an LDM which wasn't the "user mode registers" form, the initialisation of lr was being skipped, resulting in the registers being loaded from garbage addresses. Shuffle things around slightly so that the branch to label 34 works as intended.
Admin:
  Issue spotted by Willi Theiss
  Builds, but untested


Version 5.35, 4.79.2.211. Tagged as 'Kernel-5_35-4_79_2_211'

ModeFlag_GreyscalePalette handling improvements. Issue service calls on certain GraphicsV events. Sprite tweaks and fixes.

Detail:
  hdr/VduExt - Add reason codes used by Service_DisplayChanged & Service_DisplayStatus
  s/vdu/vdugrafg - Remove dependency on SpriteReason_BadReasonCode; just use the size of our lookup table instead. Alter SpriteOp lookup table so that unimplemented ops return an error instead of doing nothing. Fix PutSprite incorrectly using the slow GCOL action plotter if a request was made to plot a sprite using its mask but the sprite has none.
  s/vdu/vdugrafl - Update screen redirection handling to set ModeFlag_GreyscalePalette if switching output to a sprite with a greyscale palette or a RISC OS Select alpha mask. Restore the flag to its correct value when restoring screen output.
  s/vdu/vdupalxx - Update ModeFlag_GreyscalePalette in realtime as the palette is changed
  s/vdu/vduswis - Issue Service_DisplayChanged during OS_ScreenMode 11. Issue Service_DisplayStatus during OS_ScreenMode 65 & 66.
Admin:
  Tested on Iyonix, BB-xM


Version 5.35, 4.79.2.210. Tagged as 'Kernel-5_35-4_79_2_210'

ARM600:
Decode LDRSB, do the sign extend, and fault all the other loads and stores not understood.
VMSAv6:
As the loads and stores not understood are now vetted properly, it should be safe to UseProcessTransfer (previously they'd have been disassembled incorrectly).
Paste in LDRSB code from ARM600.
Fix dubious looking access of CurrentGraphicsVDriver from WsPtr.

Tested briefly on StrongARM.

Version 5.35, 4.79.2.209. Tagged as 'Kernel-5_35-4_79_2_209'

Detail:
  s/Kernel - UndPreVeneer, PAbPreVeneer and AdXPreVeneer all need to take into account the location of ZeroPage. In reality UndPreVeneer is the only one that matters, as the other two aren't really used.
Admin:
  Tested on Raspberry Pi with high processor vectors
  Undefined instructions now generate errors correctly


Version 5.35, 4.79.2.208. Tagged as 'Kernel-5_35-4_79_2_208'

Fix dodgy mode changes on Raspberry Pi. Fix crash when switching to a driver which uses DA 2 if DA 2 isn't already large enough.

Detail:
  s/vdu/vdudriver:
  - Fix bug in ModeChangeSub which caused the VariableFramestore flag to be ignored, resulting in unreliable mode changes on the Raspberry Pi.
  - Changed InitialiseMode to reset a few more variables when preparing to use a driver which uses DA 2. Without this the screen DA handler will likely crash when attempting to resize the DA for the initial mode change.
Admin:
  Tested on Raspberry Pi


Version 5.35, 4.79.2.207. Tagged as 'Kernel-5_35-4_79_2_207'