GitLab

* Update OS_ScreenMode 11's handling of drivers which fail to
initialise. If there was no previous driver, then instead of trying to
restore that nonexistant driver, stick with the new one. This is mainly
to help with the case where the kernel's built in modes aren't accepted
by the driver, and valid modes only become available once an MDF is
loaded (this can happen with early OMAP3 chip revisions, which have very
tight sync & porch limits, causing 90% of the kernel's modes to be
rejected). If the kernel was to revert to the "no driver" state, then
loading the MDF would still leave you with no video output.
* Since we can now end up in a state where a driver is selected but
hasn't been programmed yet, update OS_Byte 19 to detect this (via the
magic ScreenBlankDPMSState value of 255) and avoid waiting for VSync
* Update RemovePages & InsertRemovePagesExit (screen DA handlers) to
avoid infinite loops if the screen DA gets shrunk to zero size (was seen
while attempting to complete the !Boot sequence while no driver was
active)

Version 6.33. Tagged as 'Kernel-6_33'

ControlList_Interlaced is taken to have meant "output interlaced sync on H/V" and "configure DMA to show alternate lines in the framestore on alternate fields", therefore SyncPol flags mean:
b43
 00 = 'normal' progressive scan
 01 = interlaced sync, but both fields show the same image
 10 = (invalid)
 11 = interlaced sync, fields use alternate lines from the image

Version 6.21. Tagged as 'Kernel-6_21'

Detail:
  s/vdu/vdudriver - When mapping external framestores, only double-map them if the driver supports hardware scrolling. Avoids wasting IO address space, and reduces IO space fragmentation if the framestore address changes
Admin:
  Tested on Raspberry Pi 3


Version 6.19. Tagged as 'Kernel-6_19'

Detail:
  s/vdu/vduswis - Fix 18 year old register corruption bug in FindOKMode which would prevent it from falling back to Service_ModeTranslation if Service_ModeExtension returned a VIDC list but the VIDC list was rejected by the GraphicsV driver
  s/vdu/vdudriver - Also, change a couple of error cases in ModeChangeSub so that they use the "Screen mode not available" error instead of the incorrect "Not enough screen memory" error.
Admin:
  Tested on Raspberry Pi 3
  Fixes issue reported on forums where if AnyMode is loaded, numbered modes in unsupported colour depths weren't being replaced with substitutes (although note that there are still some AnyMode-related issues to resolve)
  https://www.riscosopen.org/forum/forums/4/topics/12773


Version 6.16. Tagged as 'Kernel-6_16'

Detail:
  Over the years the OS's substitute screen mode selection logic has grown to be a tangled mess, and the logic it does implement isn't always very useful. Additionally, the kernel is structured in such a way that it can be hard for modules to override it.
  This set of changes aims to fix the many of the problems, by doing the following:
  - Moving all substitute mode selection logic out of the core VDU driver code and into a Service_ModeTranslation handler. This means you now only have one place in the kernel to look instead of several, and modules can override the behaviour by claiming/blocking the service call as appropriate.
  - Moving handling of the built-in VIDC lists out of the core VDU driver code and into a Service_ModeExtension handler. This means programs can now inspect these VIDC lists by issuing the right service call (although you are essentially limited to lists which the GraphicsV driver is OK with)
  - Moving *TV interlace & offset adjustment logic into the Service_ModeExtension handler, since they're legacy things which can be handled more cleanly for MDF/EDID (and the old code was poking memory the kernel didn't own)
  - Adding a Service_EnumerateScreenModes implementation, so that if you end up in the desktop with ScreenModes non-functional, the display manager at least has something useful to show you
  - Enhancing the handling of the built-in numbered modes so that they are now available in any colour depth; the Service_ModeExtension handler (and related handlers) treat the builtin VIDC lists as a set of mode timings, not a discrete set of modes
  - Substitute mode selection logic is a complete re-write. Instead of trying a handful of numbered fallback modes, it now tries:
    - Same mode but at higher colour depths
    - Same mode but at lower colour depths
    - Alternate resolutions (half-width mode with no double-pixel if original request was for double-pixel, and default resolution for monitor type)
  - Combined with the logic to allow the builtin VIDC lists to be used at any colour depth, this means that the kernel should now be able to find substitute modes for machines which lack support for <=8bpp modes (e.g. OMAP5)
  - Additionally the mode substitution code will attempt to retain as many properties of the originally requested mode as possible (eigen values, gap mode type, etc.)
  Other improvements:
  - The kernel now actually vets the builtin VIDC lists instead of assuming that they'll work (which also means they'll have the correct ExtraBytes value, where applicable)
  - The kernel now uses GraphicsV 19 (VetMode2) to vet the mode during the mode switch process, using the result to detect where the framebuffer will be placed. This allows for GraphicsV drivers to switch between DA 2 and external framestores on a per-mode basis.
  - The kernel now supports mode selectors which specify LineLength values which are larger than necessary; this will get translated to a suitable ExtraBytes control list item (+ combined with whatever padding the driver indicates is necessary via the VetMode2 result)
  File changes:
  - hdr/KernelWS - Reserve space for a VIDC list, since the Service_ModeExtension implementation typically can't use the built-in list as-is
  - s/Arthur3 - Issue Service_ModeFileChanged when the configured monitor type is changed, so that DisplayManager + friends are aware that the set of available modes has changed
  - s/GetAll - Fiddle with GETs a bit
  - s/MemMap2 - Extra LTORG
  - s/NewIRQs - Small routine to install/uninstall false VSync routine (previously from PushModeInfo, which wasn't really the appropriate place for it)
  - s/Utility - Hook up the extra service call handlers
  - s/vdu/legacymodes - New file containing the new service call implementations, and some related code
  - s/vdu/vdudecl - Move mode workspace definition here, from vdumodes
  - s/vdu/vdudriver - Remove assorted bits of mode substitution code. Plug in new bits for calling GraphicsV 19 during mode set, and deal with ExtraBytes/LineLength during PushModeInfo
  - s/vdu/vdumodes - Move some workspace definitions to s/vdu/vdudecl. Tweak how the builtin VIDC lists are stored.
  - s/vdu/vduswis - Rip out more mode substitution code. Issue Service_ModeFileChanged when monitor type is changed by OS_ScreenMode.
Admin:
  Tested on Raspberry Pi 3, Iyonix, IGEPv5


Version 6.14. Tagged as 'Kernel-6_14'

Detail:
  s/vdu/vdudriver - When using mode selector blocks, don't allow the system to switch into double-vertical, double-pixel, or BBC-gap modes which are in colour depths unsupported by the kernel
Admin:
  Tested on BB-xM


Version 6.13. Tagged as 'Kernel-6_13'

Detail:
  ECFIndex and PalIndex claim to be mode variables, but it's impossible for extension modes to specify their values.
  Since they're easy to calculate from the ModeFlags and Log2BPP values, drop them from the mode workspace (+ table of builtin modes) and calculate them on the fly instead.
  File changes:
  - hdr/KernelWS - Drop ECFIndex & PalIndex from workspace
  - s/vdu/vdumodes - Adjust workspace definition, drop ECFIndex & PalIndex values from VWSTAB
  - s/vdu/vdudriver - Remove now-redundant copy loop from ModeChangeSub. Remove code from GenerateModeSelectorVars that sets up the ECFIndex & PalIndex values on the stack
  - s/vdu/vdugrafl - Adjust copy loop in SwitchOutputToSprite/Mask
  - s/vdu/vdupalette, s/vdu/vdupalxx - Add GetPalIndex routine to generate PalIndex on the fly. Drop the obsolete 16bpp palette/gamma table and shuffle the other entries to simplify GetPalIndex a bit.
  - s/vdu/vduplot - Add GetECFIndex routine to generate ECFIndex on the fly. Also, fix things so that mode 0 isn't the only rectangular-pixel mode which uses the special rectangular-pixel ECF patterns (index 0 vs. index 4). Fiddle with ExportedHLine a bit to avoid an out-of-range ADR.
  - s/NewReset - Fix UAL warning for MOV R0, AppSpaceStart. Adjust memset to not assume 512KB is the correct amount
Admin:
  Tested on Raspberry Pi 3


Version 6.11. Tagged as 'Kernel-6_11'

Detail:
  s/vdu/vdudriver - On startup, initialise all palettes to 0, not just Pal_Blank. Ensures that entries which might not always be explicitly initialised (e.g. pointer) are self-consistent. Also make sure InitialiseMode communicates the pointer palette to the new GV driver, since some components tend to program it in a lazy manner (e.g. Hourglass)
  s/vdu/vdupalxx - Fix UpdateAllPalette setting R4 to 0 on exit. Fix PV_BlankScreen R0 return value to be 0/1 as the comment suggests instead of always being 0 due to GraphicsV calls.
Admin:
  Tested on wandboard
  Fixes incorrect hourglass colours after reset, due to software RAM clear not wiping the kernel's palette (kernel + Hourglass thought old colours were still in use, but IMXVideo hadn't been told any colours yet so was using defaults of 0)


Version 5.96. Tagged as 'Kernel-5_96'

Newly born boards have all 0xFF's in their CMOS (EEPROM), but the new order of keyboard scan did
  Init -> Scan keyboard -> Check (or wipe) CMOS
and would therefore leave 0xFF's in a select few kernel workspace areas and OS_Byte values.
Defer the init which reads CMOS until after the check/wipe step. Only the screen area size is now done early, but MassageScreenSize clamps that properly anyway.

Arthur3.s: Relocate stranded function SetupPrinterBuffer to osinit.
PMF/key.s: Drop support for SoftReset.
PMF/osinit.s: Stuff in hardcoded defaults at early init. Retrieve the proper ones later. Take ownership of SystemSprite/RamFS/Font Manager dynamic areas (deferrable).
vdudriver.s: Use symbolic name.
NewReset.s: Defer SystemSprite/RamFS/Font Manager area creation, MouseInit, Read(Hard)CMOSDefaults until later.
hdr/Options: Delete unused IgnoreVRAM. Remove MaxRAMFS_Size now PMPs make it not useful. Shuffle ARM6Support/XScaleMiniCache/XScaleJTAGDebug to be adjacent to their definitions.

Tested by filling first 256 bytes with 0xFF and powering up. Reset now completes, OS_Byte variables look sensible.

Version 5.95. Tagged as 'Kernel-5_95'

Detail:
  The ExtraBytes control list item can be used to add padding between framebuffer rows.
  When the kernel sees a VIDC list containing this item, it will now adjust the LineLength and ScreenSize mode variables accordingly, with the end result that the correct amount of memory will be allocated for the framebuffer and the OS will render into it correctly.
  Files changed:
  - hdr/KernelWS - Add DisplayLineLength variable to allow the correct LineLength value to be preserved when screen output is redirected to a sprite
  - s/vdu/vdudriver - Make ModeChangeSub initialise DisplayLineLength before calling SwitchOutputToSprite. Update PushModeInfo to take ExtraBytes into account when calculating LineLength and ScreenSize.
  - s/vdu/vdugrafl - Adjust SwitchOutputToSprite to use DisplayLineLength when restoring screen output
  - s/vdu/vduwrch - Fix full-screen CLS to not write to the padding bytes
Admin:
  Tested on Raspberry Pi 3


Version 5.82. Tagged as 'Kernel-5_82'

Detail:
  s/vdu/vdudriver, s/vdu/vdumodes - Re-introduce TTX256 so that 8bpp teletext will be used if no MDF is loaded
  s/vdu/vdudriver - If the video driver didn't support the native mode 7 colour depth, ModePromoTable was swapping it for another mode number, preventing the AltTTX code in FindOKMode from operating. So, skip the ModePromoTable check for mode 7.
  s/vdu/vduswis - Minor correction to alternate teletext mode search; 1<<5 = 32bpp, so stop search at log2bpp of 6
Admin:
  Tested on Raspberry Pi


Version 5.74. Retagged as 'Kernel-5_74'

Detail:
  This set of changes:
  * Adds support for the T, TX and TY mode string elements (as per RISCOS Ltd)
  * Adds support for entering arbitrary-resolution teletext modes by using mode selector blocks with the Teletext mode flag set
  * ScrRCol and ScrBRow mode variables can be provided in the mode selector in order to restrict the number of text rows/columns in teletext modes (as per RISCOS Ltd)
  * If the rows / columns are restricted in this manner then the text window will be centered on the screen, to try and avoid things looking too ugly (no variable text scaling implemented)
  * For HiResTTX, all colour depths >= 4bpp are now supported by teletext. This essentially makes the TTX256 switch obsolete.
  * If the "native" mode 7 is unavailable then the kernel will try a series of fallback resolutions & colour depths in an effort to find a combination that works
  Known bugs/issues:
  * Teletext column count has a max limit of 255 due to TTXDoubleCounts being a byte array
  * If there's a border around the text window, the border will not be refreshed when changing transparency modes using a VDU 23,18,0 sequence
  * ScreenLoad looks like it can overflow the LargeCommon buffer (no buffer size check) - needs fixing before LargeCommon can be safely shrunk below (Old)TTXMapSize
  File changes:
  - hdr/KernelWS - Make CharWidth non-conditional. Adjust handling of teletext workspace; it's now allocated from the system heap to allow it to cope with arbitrary screen sizes
  - s/vdu/vdu23 - Make CharWidth non-conditional
  - s/vdu/vducursoft - Make CursorTeletext cope with arbitrary colour depths, make CharWidth non-conditional, remove hard-coded teletext values
  - s/vdu/vdudriver - Deal with teletext workspace allocation during ModeChangeSub. Deal with selecting teletext modes (and validating colour depth) in GenerateModeSelectorVars.
  - s/vdu/vdugrafl - Make CharWidth non-conditional. Calculate offset required for text window centering.
  - s/vdu/vdumodes - Remove TTX256
  - s/vdu/vduswis - Try other teletext modes if native mode 7 not available. Extend OS_ScreenMode reason codes to cope with teletext mode strings.
  - s/vdu/vduttx - Update to use dynamic workspace. Replace various hardcoded values with variable lookups. Update character plotting + colour/palette selection to work with true-colour modes if HiResTTX.
  - s/vdu/vduwrch - Move some useful code into a subroutine. Update FastCLS to cope with true-colour teletext. Update AddressR0R1 to cope with text window centering offset. Make CharWidth non-conditional.
Admin:
  Tested on Raspberry Pi, BB-xM
  VDU 23,18,0 in 256-colour teletext now works correctly (previously 64-colour mode was in use, causing palette update to be ruined by VIDC1-mangling)


Version 5.74. Tagged as 'Kernel-5_74'

Detail:
  This change gets rid of the following switches from the source (picking appropriate code paths for a 32bit HAL build):
  * FixCallBacks
  * UseProcessTransfer
  * CanLiveOnROMCard
  * BleedinDaveBell
  * NewStyleEcfs
  * DoVdu23_0_12
  * LCDPowerCtrl
  * HostVdu
  * Print
  * EmulatorSupport
  * TubeInfo
  * AddTubeBashers
  * TubeChar, TubeString, TubeDumpNoStack, TubeNewlNoStack macros
  * FIQDebug
  * VCOstartfix
  * AssemblingArthur (n.b. still defined for safety with anything in Hdr: which uses it, but not used explicitly by the kernel)
  * MouseBufferFix
  * LCDInvert
  * LCDSupport
  * DoInitialiseMode
  * Interruptible32bitModes
  * MouseBufferManager
  * StrongARM (new CacheCleanerHack and InterruptDelay switches added to hdr/Options to cover some functionality that StrongARM previously covered)
  * SAcleanflushbroken
  * StrongARM_POST
  * IrqsInClaimRelease
  * CheckProtectionLink
  * GSWorkspaceInKernelBuffers
  * EarlierReentrancyInDAShrink
  * LongCommandLines
  * ECC
  * NoSPSRcorruption
  * RMTidyDoesNowt
  * RogerEXEY
  * StorkPowerSave
  * DebugForcedReset
  * AssembleKEYV
  * AssemblePointerV
  * ProcessorVectors
  * Keyboard_Type
  Assorted old files have also been deleted.
Admin:
  Identical binary to previous revision for IOMD & Raspberry Pi builds


Version 5.51. Tagged as 'Kernel-5_51'

Detail:
  This change gets rid of the following switches from the source (picking appropriate code paths for a desktop build):
  * STB
  * RO371Timings
  * NormalSpeedROMS
  * AutoSpeedROMS
  * RISCPCBurstMode
  * InterlacedPointer
  * ParallelFlashUpgrade (and s/FlashROM file)
  * Embedded_UI
  Some of the deleted code might be worth revisiting in future:
  * OS_ReadSysInfo 4 support for storing the MAC in alternate CMOS locations (including 2nd copy for error checking) or fetching via Service_MachineAddress
  * Mouse handling changes, possibly aimed at hiding the mouse pointer if a mouse isn't connected
  * More strict CMOS validation in s/NewReset
Admin:
  Identical binary to previous revision for IOMD & Raspberry Pi builds


Version 5.50. Tagged as 'Kernel-5_50'

Detail:
  This change gets rid of the following switches from the source (picking appropriate code paths for a 32bit HAL build):
  * HAL
  * HAL26
  * HAL32
  * No26bitCode
  * No32bitCode
  * IncludeTestSrc
  * FixR9CorruptionInExtensionSWI
  Various old files have also been removed (POST code, Arc/STB keyboard drivers, etc.)
Admin:
  Identical binary to previous revision for IOMD & Raspberry Pi builds


Version 5.49. Tagged as 'Kernel-5_49'

Detail:
  This set of changes adds support for "physical memory pools" (aka PMPs), a new type of dynamic area which allow physical pages to be claimed/allocated without mapping them in to the logical address space. PMPs have full control over which physical pages they use (similar to DAs which request specific physical pages), and also have full control over the logical mapping of their pages (which pages go where, and per-page access/cacheability control).
  Currently the OS makes use of two PMPs: one for the free pool (which now has a logical size of zero - freeing up gigabytes of logical space), and one for the RAM disc (logical size of 1MB, allowing for a physical size limited only by the amount of free memory)
  Implementing these changes has required a number of other changes to be made:
  * The CAM has been expanded from 8 bytes per entry to 16 bytes per entry, in order to allow each RAM page to store information about its PMP association
  * The system heap has been expanded to 32MB in size (from just under 4MB), in order to allow it to be used to store PMP page lists (1 word needed per page, but PMP pages may not always have physical pages assigned to them - so to allow multiple large PMPs to exist we need more than just 1 word per RAM page)
  * The &FA000000-&FBFFFFFF area of fixed kernel workspace has been shuffled around to accomodate the larger CAM, and the system heap is now located just above the RMA.
  * SoftResets code stripped out (unlikely we'll ever want to fix and re-enable it)
  * A couple of FastCDA options are now permanently on
  * Internal page flags shuffled around a bit. PageFlags_Unavailable now publicly exposed so that PMP clients can lock/unlock pages at will.
  * When OS_ChangeDynamicArea is asked to grow or shrink the free pool, it now implicitly converts it into a shrink or grow of application space (which is what would happen anyway). This simplifies the implementation; during a grow, pages (or replacement pages) are always sourced from the free pool, and during a shrink pages are always sent to the free pool.
  File changes:
  - hdr/KernelWS - Extend DANode structure. Describe CAM format. Adjust kernel workspace.
  - hdr/OSRSI6, s/Middle - Add new item to expose the CAM format
  - hdr/Options - Remove SoftResets switch. Add some PMP switches.
  - s/ARM600, s/VMSAv6 - Updated for new CAM format. Note that although the CAM stores PMP information, BangCamUpdate currently doesn't deal with updating that data - it's the caller's responsibility to do so where appropriate.
  - s/ChangeDyn - Lots of changes to implement PMP support, and to cope with the new CAM format.
  - s/HAL - Updated to cope with new CAM format, and lack of logical mapping of free pool.
  - s/MemInfo - Updated to cope with new CAM format. OS_Memory 0 updated to cope with converting PPN to PA for pages which are mapped out. OS_Memory 24 updated to decode the access permissions on a per-page basis for PMPs, and fixed its HWM usage for sparse DAs.
  - s/NewReset - Soft reset code and unused AddCamEntries function removed. Updated to cope with new CAM format, PMP free pool, PMP RAMFS
  - s/AMBControl/allocate - Update comment (RMA hasn't been used for AMBControl nodes for a long time)
  - s/AMBControl/growp, s/AMBControl/memmap, s/AMBControl/shrinkp - Update for new CAM format + PMP free pool
  - s/vdu/vdudriver - Strip out soft reset code.
Admin:
  Tested on Pandaboard
  This is just a first iteration of the PMP feature, with any luck future changes will improve functionality. This means APIs are subject to change as well.


Version 5.35, 4.79.2.284. Tagged as 'Kernel-5_35-4_79_2_284'

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

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'

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'

Detail:
  s/MemInfo - Fix OS_Memory 0 physical-to-logical conversion returning bad addresses for most cases due to R5 being modified by physical_to_ppn (bug introduced in revision 4.4.2.20)
  s/vdu/vdudriver - Fix some VDU driver variables not being initialised correctly when switching GraphicsV driver
  s/vdu/vdugrafv - Fix handling of VSync events from GraphicsV drivers other than driver zero
  s/vdu/vduswis - Fix abort when OS_ScreenMode 11 is passed a bad driver number
Admin:
  Tested on Raspberry Pi
  There still seems to be a bug lurking somewhere when switching to a GraphicsV driver that uses DA2; the system will crash horribly unless DA2 is already a suitable size for the initial mode change


Version 5.35, 4.79.2.206. Tagged as 'Kernel-5_35-4_79_2_206'

Detail:
  This set of changes:
  * Adds basic support for multiple GraphicsV drivers, by way of some new OS_ScreenMode reason codes for registering/deregistering, selecting and enumerating drivers (11, 64-68)
  * Tidies up handling of HAL video calls so that the HAL calls will be transformed into a bona fide GraphicsV driver if they're implemented
  * Changes handling of 16bpp gamma table entries so that they're sent to GraphicsV in a generic form instead of in a VIDC-specific form
  * Adds a new GraphicsV call and defines new VIDC list items to allow GraphicsV drivers to utilise the new pixel formats
  File changes:
  * h/VIDCList, hdr/VIDCList, Makefile - Add new header export containing VIDC list type 3 definitions, to avoid repeated definitions in other components
  * Resources/UK/Messages - Add new GraphicsV/OS_ScreenMode error strings and some missing processor type strings
  * hdr/KernelWS - Clean up some pre-GraphicsV definitions, and add new workspace locations for storing the current GraphicsV driver number and the driver list
  * hdr/Options - Remove obsolete InverseTextTransparency option
  * hdr/VduExt - Add VDU variable 192 for storing GraphicsV driver number (same as ROL's VideoV driver number). Remove old 'Flag_*' mode flag definitions (use new 'ModeFlag_*' defintions instead). Add new OS_ScreenMode reason codes.
  * s/ARM600, s/VMSAv6, s/vdu/vdu23, s/vdu/vdugrafa, s/vdu/vdugrafd, s/vdu/vdupalxx, s/vdu/vdupointer, s/vdu/vduwrch - Strip out pre-GraphicsV code. Update GraphicsV code to use correct driver number.
  * s/ArthurSWIs - Pass the default GraphicsV claimant the VduDriverWorkSpace instead of ZeroPage
  * s/Getall - Add Hdr:VIDCList and s/vdu/VduGrafHAL to list of GETs
  * s/NewIRQs - Remove HAL VSync IRQ initialisation, is now handled by grafvhal. Remove old HAL VsyncIRQ entry point, all VSyncs are now handled by VsyncIRQ_ExtEntry.
  * s/PMF/osbyte - Stop OS_Byte 19 waiting forever if no video driver is active
  * s/PMF/osinit - Remove HAL VSync IRQ initialisation, is now handled by grafvhal
  * s/vdu/vducursoft - Use new workspace variable names and flag names
  * s/vdu/vdudecl - Remove old HALDAG_* definitions, GVDAG_* definitions are used instead. Add definition of the per-driver workspace structure and flags.
  * s/vdu/vdudriver - Remove pre-GraphicsV code. Update InitialiseMode to check for and initialise a HAL driver. Use cached driver features word in a few places instead of calling GraphicsV each time. Update PalIndexTable to disable VIDC mangling of 16bpp gamma tables.
  * s/vdu/vdugrafv, s/vdu/vdugrafhal - HAL<->GraphicsV code split off into its own file (vdugrafhal). Default GraphicsV claimant now only deals with VSync events for the active driver.
  * s/vdu/vdumodes - Get rid of old VIDC List type 3 definiton; now in hdr/VIDCList
  * s/vdu/vduswis - Added OS_ScreenMode reason codes 11 and 64-68 for registering, deregistering, selecting and enumerating GraphicsV drivers. Update mode set code to not bother checking if the driver supports the pixel format; instead we assume that the driver's vet mode call will do the check for us.
Admin:
  Tested in Tungsten, IOMD, OMAP3 & BCM2835 ROMs
  Requires HdrSrc-2_38 and updated video driver modes


Version 5.35, 4.79.2.203. Tagged as 'Kernel-5_35-4_79_2_203'

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/OldPSSrc, NewModes/PSSrc, s.vdu.vdu23, s.vdu.vducursoft, s.vdu.vdudriver, s.vdu.vdugrafg, s.vdu.vdugrafj, s.vdu.vdugrafl, s.vdu.vdumodes, s.vdu.vdupal10, s.vdu.vdupal20, s.vdu.vdupalette, s.vdu.vdupalxx, s.vdu.vduwrch - Renaming Flag_* to ModeFlag_*
  - s.vdu.vdudecl - Remove OS_ScreenMode reason codes & mode selector format definitions; these are now in hdr/VduExt. Flag_* -> ModeFlag_* renaming.
  - s.vdu.vdupalxx - Apply a greyscale palette in PV_SetDefaultPalette if the greyscale mode flag is set
  New sprite types:
  - s.vdu.vdudriver - Extend GenerateModeSelectorVars to deal with the wide mask flag, 64K sprites, and the new RISC OS 5 sprite mode word format.
  - s.vdu.vdugrafdec - Store more information about the sprite in the SprReadNColour ... SprLog2BPC block.
  - s.vdu.vdugrafg - Update SpriteVecHandler to be able to detect whether RISC OS 5 format sprites are allowed palettes. Update SetupSprModeData to store the extra sprite info that's defined in vdugrafdec. Update PutSprite to fault any sprites with wide masks - SpriteExtend must be used for that (once implemented!)
  - s.vdu.vdugrafh - Update WritePixelColour to avoid temporary poking of NColour VDU variable for 8bpp sprites. Correctly replicate data when writing to RISC OS 5 format sprites. Update ReadPixelMask, WritePixelMask, SpriteMaskAddr, GetMaskspWidth to deal with wide masks. Delete obsolete bounce_new_format_masks routine.
  - s.vdu.vdugrafi - Comment updated to reflect new reality
  - s.vdu.vdugrafj - Get rid of unused code block in CreateHeader/PostCreateHeader. Update SanitizeSGetMode to generate RISC OS 5 style sprite mode words where applicable. Update DecideMaskSize to rely on GetMaskspWidth for calculating mask width.
  - s.vdu.vdugrafl - Update SwitchOutputToSprite/SwitchOutputToMask to deal with the new sprite formats. Allow PushModeInfoAnyMonitor to fail.
  - s.vdu.vduswis - Extended OS_ReadModeVariable to cope with new sprite types
  Misc:
  - s.vdu.vdudriver - Fixed bug with VIDCList copying where any -1 value in the structure would terminate the copy, instead of only -1 as a control item number
  - s.vdu.vduswis - Implemented OS_ScreenMode 13 (Mode string to specifier), 14 (mode specifier to string), and 15 (set mode by string). Mostly as per ROL's specs, but minus support for teletext attributes, and plus support for new RISC OS 5 attributes (L... layout specifier, 4096 & 24bpp packed modes, etc.)
  - s.vdu.vduwrch - Pick correct default text colours for the new modes
Admin:
  Tested on BB-xM
  Part of an implementation of the Extended Framebuffer Format spec:
  http://www.riscosopen.org/wiki/documentation/show/Extended%20Framebuffer%20Format%20Specification


Version 5.35, 4.79.2.194. Tagged as 'Kernel-5_35-4_79_2_194'

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'

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'

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

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'

No accepts  r0 = b31-24 set 0
                 b23-16 fully qualified IIC address
                 b15-0  starting offset
            r1 = buffer pointer
            r2 = number of bytes to tranfer
            r4 = b31-24 display number
                 b23-16 head
                 b15-0  reason code (=14)
Now returns r0 = result codes as per HAL_IICTransfer()
            r1 = buffer pointer incremented by number of bytes transferred
            r2 = number of bytes *not* transferred
            r4 = 0
Removed '_' after Video in entry numbers to be consistent with other HAL entry naming, and HAL_VideoFlybackDevice.
Added IICStatus return numbers to Hdr:HALEntries.
Stop calling HAL_MonitorLeadID as only IOMD implemented it - just guess VGA until the graphics driver says otherwise.

Version 5.35, 4.79.2.159. Tagged as 'Kernel-5_35-4_79_2_159'

While the HAL and kernel were being split some temporary macros were used for the bits being worked on, after 12 years of use they're probably safe to adopt.
mjsCallHAL -> CallHAL; mjsAddressHAL -> AddressHAL; mjsHAL -> HAL.
OS_VIDCDividerSWI code now always does NoSuchSWI (had been switched out previously).
File vduhint.s no longer assembled (was empty).


Version 5.35, 4.79.2.150. Tagged as 'Kernel-5_35-4_79_2_150'

  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'

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

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:
  s/Arthur3, s/ChangeDyn, s/HAL, s/HeapMan, s/Middle, s/MoreSWIs, s/NewIRQs, s/Utility, s/VMSAv6, s/PMF/key, s/PMF/osbyte, s/PMF/osword, s/vdu/vdudecl, s/vdu/vdudriver, s/vdu/vduplot, s/vdu/vduwrch - Tweaked lots of LDM/STM instructions in order to get rid of the depracation/performance warnings
Admin:
  Tested on rev A2 BB-xM


Version 5.35, 4.79.2.98.2.53. Tagged as 'Kernel-5_35-4_79_2_98_2_53'

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'

Update VDU HAL device for new OMAPVideo driver, fix MVA-based cache/TLB maintenance ops aborting on ARMv7, add warning to VDU driver about inconsistent state variables during screen mode changes

Detail:
  hdr/VideoDevice - removed Address2 and Device2 fields as it makes more sense for them to be in the device specific field (which for OMAP3 is a pointer to an OMAP3-specific struct)
  s/VMSAv6 - Modify data abort handler to ignore aborts that are generated by MVA-based cache/TLB maintenance ops. Unlike earlier ARM architectures, MVA-based ops can abort under ARMv7 if the page has no mapping to a physical address.
  s/vdu/vdudriver - Add a warning about VDU driver state variables (particularly CursorAddr) being left in invalid states during the execution of mode changes. This can cause problems if any attempt is made to output to the screen during the mode change (e.g. as a result of an abort)
Admin:
  Tested on rev C2 beagleboard. Video device changes mean that OMAP3 HAL 0.23 will be needed for ROM compilation to succeed.


Version 5.35, 4.79.2.98.2.24. Tagged as 'Kernel-5_35-4_79_2_98_2_24'

     1: default ticker based vsync generated whenever no device present to do so
     2: graphicsv handling and spec updated to use the hi 8 bits in the
        reason code (R4) to define the display number. Kernel only knows
        of display 0
Detail:
Admin:
     tested castle  castle added ip


Version 5.35, 4.79.2.81. Tagged as 'Kernel-5_35-4_79_2_81'

Detail:
  174: left border size
  175: bottom border size
  176: right border size
  177: top border size
Admin:
  Not tested.

Version 5.35, 4.79.2.68. Tagged as 'Kernel-5_35-4_79_2_68'