GitLab

Detail:
  s/vdu/vdupointer - For any mode where the software pointer is usable, RestorePointer was restoring the software pointer regardless of whether it was in use at the time RemovePointer was called. This would cause both the software & hardware pointers to be briefly enabled at the same time, potentially causing flickering or other glitches. Fix the issue by making sure RestorePointer only restores if the software pointer was actually in use at the time RemovePointer was called. Also, attempt to deal with the situation where the pointer might have moved to a location where the software pointer is no longer required.
  s/Middle - Improve integration of HangWatch with the abort handler - avoid overwriting the top of the SVC stack so that it can be preserved for the HangWatch dump.
Admin:
  Tested on Raspberry Pi


Version 5.35, 4.79.2.270. Tagged as 'Kernel-5_35-4_79_2_270'

Detail:
  This set of changes adds support for rendering software mouse pointers directly in the kernel, rather than requiring graphics drivers to render them themselves as was the case previously.
  If a driver returns from GraphicsV_Features with the 'hardware pointer' bit clear, and a call to GraphicsV_UpdatePointer is returned unclaimed, then the kernel will step in and render a software pointer. This allows selective control over which areas of the screen the software pointer is used (e.g. if hardware only supports its use in some areas)
  hdr/KernelWS - Shrink PointerXEigFactor to 1 byte to free up some space for tracking the display log2bpp. Use 8 words of space for tracking software pointer state.
  s/vdu/vducursoft - Adjust existing the existing calls to the software pointer RemovePointer/RestorePointer functions so that they're called with IRQs enabled
  s/vdu/vdudriver - Keep track of display log2bpp. Claim/release memory needed for restoring pixels under software pointer.
  s/vdu/vdugrafhal - Update HAL_VideoUpdatePointer handling so that 0 can be returned in a1 to indicate the GraphicsV call should be left unclaimed.
  s/vdu/vdupalxx - Trigger updates of the cached software pointer palette whenever it's likely to become invalidated.
  s/vdu/vdupointer - Add software pointer implementation. Relying on a SpriteExtend OS_SpriteOp would be nice, but we're in the background so have to do plotting & unplotting manually. ColourTrans is used to cache the pointer palette colours for the current mode, although we're limited to calling it from a callback.
Admin:
  Tested on Raspberry Pi & BB-xM
  Pointer is very flickery under some circumstances (e.g. running !CloseUp) due to needing to plot/unplot around any VDU driver screen access (as per text cursor). So code may need revising in future once we can trap reads/writes from specific screen memory pages.


Version 5.35, 4.79.2.269. Tagged as 'Kernel-5_35-4_79_2_269'

Detail:
  Makefile, hdr/Options - By default enable high processor vectors/zero page relocation for compatible machines, but also allow the components file to override the setting if required
  s/ChangeDyn - Fix OS_DynamicArea 20 to check the correct range for doubly mapped areas, and to correctly localise its error message
Admin:
  Tested on Iyonix


Version 5.35, 4.79.2.268. Tagged as 'Kernel-5_35-4_79_2_268'

Subreason 20 takes a logical address and tells you which area it lies in, including system areas (ie. those returned by OS_Memory 16.
This allows areas to change type in future without the caller needing to care where the kernel put it.

Version 5.35, 4.79.2.267. Tagged as 'Kernel-5_35-4_79_2_267'

Detail:
  s/ARMops - Added extra LTORG to fix HiProcVecs build error for some platforms
  hdr/PublicWS - Remove the old (non-Legacy_) workspace exports, and add a comment explaining how the newer Legacy_ exports should be used.
Admin:
  HiProcVecs ROMs for various platforms now appear to build OK
  Untested at runtime


Version 5.35, 4.79.2.266. Tagged as 'Kernel-5_35-4_79_2_266'

Detail:
  s/HAL - The VMSAv6/v7 memory model allows speculative instruction fetches from any memory (including device/strongly-ordered), unless the memory is marked as non-executable. So to prevent interference with read-sensitive devices we must make sure all appropriate IO memory is marked as non-executable.
Admin:
  Tested on IGEPv5
  Fixes data corruption seen when reading from SD card


Version 5.35, 4.79.2.265. Tagged as 'Kernel-5_35-4_79_2_265'

Detail:
  s/VMSAv6 - After AMB_LazyFixUp has modified the page tables, perform a DSB + ISB to ensure the page table write has completed before we return from the abort handler.
Admin:
  Tested on IGEPv5
  Fixes aborts seen in desktop, e.g. when !CloseUp is rebuilding its sprite (heavy RAM write activity delaying pagetable write?)


Version 5.35, 4.79.2.262. Tagged as 'Kernel-5_35-4_79_2_262'

Fix OS_Byte 19 getting stuck if it's called just before the screen blanker activates. Add new OS_ReadSysInfo reason code for determining IIC bus count.

Detail:
  s/PMF/osbyte - For OS_Byte 19, move screen blanker check (and current GraphicsV driver check) inside the WFI loop so that the loop will terminate if the screen should blank (or current GraphicsV driver should die) before the next VSync occurs. Also move the Portable_Idle call to before the interrupt trigger - the old location meant that if the screen blanked we'd continue on to the Portable_Idle call and end up pointlessly stalling the system
  s/Middle - Add OS_ReadSysInfo 14, as a legitimate way of finding the number of IIC buses present on the system
Admin:
  Tested on Pandaboard


Version 5.35, 4.79.2.261. Tagged as 'Kernel-5_35-4_79_2_261'

Detail:
  s/PMF/IIC - OS_IICOp now does some basic validation of its parameters, to help avoid crashes, memory corruption, or bad IIC transfers being performed when invalid parameters are supplied
Admin:
  Tested on Pandaboard
  Fixes ticket #404
  https://www.riscosopen.org/tracker/tickets/404


Version 5.35, 4.79.2.260. Tagged as 'Kernel-5_35-4_79_2_260'

The Cache_HALDevice is in the RAM clear skip table, so when there's no controller found and the kernel is doing the RAM clear it's unset, leading to probable aborts when typing *CACHE Om|Off.

Version 5.35, 4.79.2.259. Tagged as 'Kernel-5_35-4_79_2_259'

Detail:
  s/ARMops, s/HAL - Errata 814220 states that the Cortex-A7 set/way cache maintenance operations violate the usual operation ordering rules, such that an L2 maintenance operation which is started after an L1 operation may actually complete before it, causing data corruption if the L1 data was to be evicted to the L2 entry. Implement the suggested workaround of performing a DSB when switching cache levels, rather than just at the end of the combined L1+L2 group of operations.
Admin:
  Tested on Raspberry Pi 2


Version 5.35, 4.79.2.257. Tagged as 'Kernel-5_35-4_79_2_257'

Detail:
  The Raspberry Pi ROM now joins the IOMD ROM in supporting multiple
  architectures, in this case ARMv6 and ARMv7. This has been achieved by
  creating a new machine type specific for Raspberry Pi. The old ARM11ZF
  machine type remains for builds that are ARM11-only.

Version 5.35, 4.79.2.256. Tagged as 'Kernel-5_35-4_79_2_256'

Detail:
  s/ARMops - Implement Cache_RangeThreshold for PL310 (helps AMBControl to decide what type of TLB maintenance is best). Fix MMU_ChangingEntry_PL310 doing more work than is necessary; was attempting to flush all ways for a given address tag, when really it should have only been flushing all the lines within a page and letting the cache worry about the tags/indices they correspond to.
  s/ChangeDyn, s/VMSAv6, s/AMBControl/memmap - Do extra TLB maintenance following writes to the page tables, as mandated by the ARMv6+ memory order model. Fixes frequent crashes on Cortex-A9 when running with lazy task swapping disabled (and presumably fixes other crashes too)
  s/MemInfo - Fix OS_Memory cache/uncache so that it does cache/TLB maintenance on a per-page basis instead of a global basis. Vastly improves performance when you have a large cache, but may need tweaking again in future to do a global op if large numbers of pages are being modified.
Admin:
  Tested on Pandaboard


Version 5.35, 4.79.2.255. Tagged as 'Kernel-5_35-4_79_2_255'

Detail:
  s/VMSAv6 - Modify OS_MMUControl to ensure any HAL-based cache is disabled when either the ARM I or D cache is disabled. This emulates the behaviour of an integrated L2 cache controller.
Admin:
  Tested on Pandaboard


Version 5.35, 4.79.2.254. Tagged as 'Kernel-5_35-4_79_2_254'

Detail:
  s/NewReset, s/Super1 - Escape some dollars contained in strings to avoid warnings from objasm
Admin:
  Resulting binary unchanged


Version 5.35, 4.79.2.253. Tagged as 'Kernel-5_35-4_79_2_253'

Detail:
  Unlike on the Cortex-A8 or Cortex-A15, the L2 cache that's used with the Cortex-A9 isn't hooked up to the standard ARMv7 CP15 cache maintenance ops. Instead, memory-mapped registers must be used to program and maintain the cache.
  Since the PL310 can't be detected automatically, this change adds support for a 'cache controller' HAL device which the HAL can use to advertise the presence of any external caches. If a cache device is registered during HAL_InitDevices the kernel will then check it against a list of known cache types and replace the appropriate ARMop routines with the alternatives for that controller.
  File changes:
  - hdr/PL310 - New header containing PL310 register listing
  - Makefile - Add export for PL310 header. Reorder exports to be alphabetical
  - hdr/HALDevice - Add cache controller device type, PL310 device
  - hdr/KernelWS - Allocate some workspace for storing a pointer to the current cache HAL device
  - s/ARMops - Add code for searching for known cache types, and implementation of PL310-specific ARMops
  - s/GetAll - Get Hdr:PL310
  - s/NewReset - Look for a cache controller after calling HAL_InitDevices
Admin:
  Tested on Pandaboard
  Fixes various assorted instability issues


Version 5.35, 4.79.2.252. Tagged as 'Kernel-5_35-4_79_2_252'

Detail:
  s/ARMops - Replace the code to calculate the minimum cache line lengths with something much simpler which reads the values directly from the cache type register.
  The old code was buggy in two ways:
  (a) the cache size identification register stores the line length as log2(num words)-2, whereas the code throughout the kernel was expecting it to be log2(num bytes)-2
  (b) the loop is structured so that it will try and read the details of a non-existent cache level. although it doesn't read anything from CP15, it does result in the minimum cache line length values getting clobbered
  The net result of the above two bugs being that the OS would treat the CPU as if the minimum line length was just 4 bytes (although other than slowing down cache maintenance ops, this shouldn't have had any bad side-effects)
  The cache type register directly contains the minimum line lengths as log2(num bytes)-2, so by switching over to use that everything is now fine.
Admin:
  Tested on BB-xM, Pandaboard
  Fixes issue spotted by Willi Theiss


Version 5.35, 4.79.2.251. Tagged as 'Kernel-5_35-4_79_2_251'

Historically the kernel looked after all aspects of cache control since they were common across all ARMs. However, not all cache controllers are created equal, and sometimes more complex initialisation steps are needed than fit the generic coprocessor ops - for example the PL310 attached to a Cortex-A9 has memory mapped control registers.
Rather than clutter the kernel with one shot init code for every cache controller invented, we delegate that step to the HAL in HAL_Init. This is only a few hundred instructions later than where it was already being set. The kernel remains responsible for subsequent maintenance, this is just init which is being handed off.
A quick survey of the Cortex-A TRMs shows:
A5 - optional, for example ARM's PL310, ref TRM section 8.1.7.
A7 - optional, C bit of SCTLR, ref TRM section 1.1.
A8 - L2EN bit of ACTLR, note this bit has been recycled for other uses on other cores, ref TRM section 8.3.
A9 - not integrated, ARM's PL310 uses bit 0 of control register 1, ref PL310 TRM section 3.1.1.
A12 - see A17
A15 - integrated, C bit of SCTLR, ref TRM section 7.2.3.
A17 - integrated, bit 18 of L2CTLR & C bit of SCTLR, ref TRM section 7.2.
and while we've got the TRMs open, back fill the CPU id register table.

Version 5.35, 4.79.2.250. Tagged as 'Kernel-5_35-4_79_2_250'

MemInfo.s:
 Several places in this code called the HAL or other ATPCS defined functions like memset() and hoped that the overall result was V clear. If any of them accidentally set V (for example a CMP that straddles 0x80000000) you ended up trying to look up an international error at the address of the reason code to OS_Memory.
 Now, explicitly clear V in the non error cases where an ATPCS function was called.
 Change the HAL_PhysInfo call to expect a physical ROM size back as an inclusive range, to match the RAM range subreason code. Add 1 to correct for this. A value of 0 & 0 is taken to mean "no physical ROM" as before.
Middle.s:
 Document that 255 means "no IOMD" or "no VIDC", that's what the HALs have been using since year dot.

Version 5.35, 4.79.2.248. Tagged as 'Kernel-5_35-4_79_2_248'

With ProtectStationID turned on there are no routes to writing the Econet station (or bottom octect of the IP address), a function previously fulfilled by the SetStation utility which pokes the hardware directly and doesn't fit into a HAL model.
Add a new subreason to OS_NVMemory to perform this role. This SWI appeared for RISC OS 5.00, and errors unsupported subreasons, so there's a means of run tim selecting its use by checking the platform class and trying the SWI. All RISC OS 5 based platforms can always be upgraded to this version, since they're all still being maintained.

hdr/Options: move the switch with the other options from osinit.s
i2cutils.c: new subreason

Ditch the 'ObsoleteNC1CMOS' switch, if it was obsolete for NC1, it's certainly obsolete now.
Ditch unmaintained messages files for Morris4/Omega/Ursula projects.
Tested on a Risc PC.

Version 5.35, 4.79.2.247. Tagged as 'Kernel-5_35-4_79_2_247'

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'

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'

Not tagged.

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'

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'

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