New GPIO module

I have noticed that the CVS log shows changes to include GPIO as a ROM module:

By delegating the hardware access element to the underlying HAL, the GPIO module becomes much simpler.
A new SWI, GPIO_Features is added, though the returned flags are currently 0 the presence of the SWI demarks the HAL variant.
A new command, *GPIODevices lists the GPIO controller(s) known and their basic input/output state at a glance.

However I have built the 12 Feb (Raspberry Pi) ROM and it does not recognise SYS “GPIO_Features” or the * command GPIOdevices.

So where is the GPIO module – the build log refers to ‘GPIO’ in several places but does not seem to include it in the rom. Am I missing something please?

Seem to have answered my own question. Adding a blank directory ‘h’ in ‘SCSI::HardD4.4.testnew.bcmLV.BCM2835Dev.bsd.RiscOS.Sources.ThirdParty.TankStage.HWSupport.GPIO’ (to overcome an error ‘cmhg: can’t create #definitions file h.GPIOHdr’) and adding ‘GPIO’ between ‘DOSFS’ and ‘SCSISwitch’ in ‘SCSI::HardD4.4.testnew.bcmLV.BCM2835Dev.BuildSys.Components.ROOL.BCM2835’ I seem to have built a 13-Feb-2017 low vector rom for the Raspberry Pi which includes the GPIO module version 1.00 in ROM. I have tested it on a model A+ and it controls GPIO pins OK.

The problem at the moment is that this update (18 Oct 2016 firmware and 13-Feb-2017 ROM) has (no doubt inter alia) changed the way RISC OS changes modes. If you try to select 1920×1080 it only offers 30Hz, knows my 1920×1080 monitor requires 60Hz, forgets that the GPU can handle this and refuses to allow me to use RISC OS at 1920×1080 (which messes up horribly the start up splash screens). Any ideas please? I am using a standard RC14 build, updated with Update 6L above running RISC OS 5.23L (13-Feb-2017).

The problem at the moment is that this update (18 Oct 2016 firmware and 13-Feb-2017 ROM) has (no doubt inter alia) changed the way RISC OS changes modes.

Are you using EDID or an MDF? What pixel rate does the 1920×1080 @ 60 mode require? BCMVideo 0.40 and newer will read the following limits from the GPU and filter the available modes appropriately:

• max_framebuffer_width, default 1920
• max_framebuffer_height, default 1200
• hdmi_pixel_freq_limit, default 162000000 (162MHz)
• hdmi_pixel_freq_limit_min, default 25000000 (25MHz)

All of these can be set in config.txt to override the defaults.

You probably also want to update to the latest firmware. A couple of weeks ago a bug fix was made to the firmware which broke one of the assumptions that BCMVideo was making for how multiple screen banks are handled. BCMVideo 0.43 has been fixed to use the same logic as the new firmware, but it isn’t fully backwards-compatible with the old firmware (since there isn’t a convenient way of getting a firmware version number).

Firstly with the October 2016 firmware and a 26 October 2016 ROM I can add commands to the CONFIG/TXT (hdmi_group=1; hdmi_mode=16) to force 1920×1080 16M 60Hz, whereas with the 13-Feb-2017 ROM this just causes a blank screen. Without these extra commands both roms start up OK.

With the 26 Oct ROM, if I double-click !Boot and ‘Try’ 1920×1080 30Hz the screen blanks.

Are you using EDID or an MDF?

Both, I think (not sure how to tell).

Updating to the new firmware (5 days ago) makes no difference.

Firstly with the October 2016 firmware and a 26 October 2016 ROM I can add commands to the CONFIG/TXT (hdmi_group=1; hdmi_mode=16) to force 1920×1080 16M 60Hz, whereas with the 13-Feb-2017 ROM this just causes a blank screen.

Confirmed; that does appear to be a bug.

With the 26 Oct ROM, if I double-click !Boot and ‘Try’ 1920×1080 30Hz the screen blanks.

13 Feb ROM?

Are you using EDID or an MDF?

Both, I think (not sure how to tell).

If I install RC14 + Update6L then the machine starts in a state with neither MDF nor EDID (display manager doesn’t list any modes, screen setup plugin in Configure shows monitor type “auto”).

If you’ve got modes available then you’ve either (a) selected an MDF (what does screen setup say for “Monitor type”?) or (b) added a *ReadEDID command to your boot sequence somewhere.

If you’ve selected an MDF, does it actually contain an entry for 60Hz? (if it’s a standard MDF you should be able to find it in !Boot.Resources.Configure.Monitors)

Does your monitor support 30Hz?

With BCMVideo 0.40 and newer, RISC OS will attempt to tell the GPU what mode timings to use, so the days of using MDFs containing bogus mode timings which your monitor doesn’t support are over. Although if you really want you can create a “cmdline.txt” file in the FAT partition containing the text “disable_mode_changes” (without the quotes) to force the old behaviour.

13 Feb ROM?

Yes, typo, sorry.

RC14 + Update6L then the machine starts in a state with neither MDF nor EDID

Agreed. It used to say ‘Auto’ but list three modes including 1920×1080. Never understood what ‘Auto’ meant in practical terms. To get some modes available (apart from 640×480) I selected ‘Generic’ and chose the max resolution that worked (1024×720). I’ll try ReadEDID. My monitor does not support 30Hz. I’ll look more closely at my MDF…

the days of using MDFs containing bogus mode timings which your monitor doesn’t support are over

Ouch! Many thanks for the explanation.

Have added a 1080p 57Hz mode to Boot:Resources.Configure.Monitors.Other.Generic and then use !Boot/Configure/Screen to select Generic/1920×1080/16M/57Hz, Try/Confirm/Keep/Set but then get error ‘failed to open <PreDesk$Configure> for writing’. Omitting the ‘Set’ and updating Boot:Choices.PreDesk.Configure.Monitors manually to X1920 Y1080 C16M F57 causes the desktop to be 640×480. Copying Boot:Choices.Boot.PreDesk.Configure.Monitors manually to Boot:Choices.Boot.PreDesk.Monitors and restarting does end up with a 1920×1080 desktop (Phew!). The splash screen is a horrible mess though.

Didn’t get anywhere with *ReadEDID.

I have the same Pi3 issue with ROMS later than 26th Oct 2016", so I’ve stuck with October ROM.

The “26th Oct 2016” ROM names the display manager as “RasPi-Builtin”, subsequent ROMs from November (when I started to use my Pi3) gives the display manager the name “Auto” and has a default of “640×480”. The display can then be changed with an Obey file on the desktop. This was using the latest Pi firmware around November / December and of last week.

My basic tests revealed that the HardDisc4.util builds are OK, it is just the later ROM images that appear to be causing the issue – splash screen(s) looks odd and a default resolution of “640×480”. The tests just involved trying the HardDisc4 builds and swapping from the Oct ROM to a later ROM build.

In relation to the ROM builds from November, a further observation is no matter what you set the screen mode to be in “CONFIG.TXT” it is ignored by the ROM, other settings do work.

A quick test on my RPi3 running the 12-Feb-17 ROM shows that selecting ‘Auto’ in Screen configuration results in an empty PreDesk.Configure.Monitor file and a very vanilla 640×480 256colours desktop. This has come up before but helpfully I have forgotten what the reasoning was.

Edit. Found it

*ReadEDID works as expected with this HP 2229h monitor, and has a useable 1920×1080 60Hz mode.

IIRC “RasPi-Builtin” has been ‘built out’ now, gone that is.

There have been changes to the ScreenModes module, I now run with :-

*configure mode 28
*configure monitortype 1

The MDF is a saved EDID generated file. (And nothing relevant in CONFIG/TXT.)

It all works well here, it is just a simple matter of ignoring the splash screen start up mess.

‘failed to open <PreDesk$Configure> for writing’.

That is indicative of a failure within PreDesk, I have managed to replicate that here inadvertently, and more than once.

Boot:Choices.PreDesk.Configure.PreDesk.Monitors
Boot:Choices.Boot.PreDesk.Configure.Monitors
Boot:Choices.Boot.PreDesk.Monitors

That’s two more filenames than I’d expect. I’ll have to check what’s going on when I get home (and check exactly what <PreDesk$Configure> is – I can see that the screen setup plugin does use it for the filename, but that’s an incredibly generic variable name for something specific to screen configuration)

The splash screen is a horrible mess though.

Once hell freezes over the EDID bounty is complete that shouldn’t be so much of a problem, since I’d hope most people would be able to use EDID to get a sensible screen mode by the time the splash screen is first displayed. Or maybe things will get 10x worse due to all the odd screen modes people will end up using. Either way, ROOL are aware of the limitations of the current splash screen (a 1920×1080 JPEG can only be squashed and stretched so much)

Didn’t get anywhere with *ReadEDID.

Didn’t get anywhere, how? Did it report an error? (if so, what?) Did it fail to detect modes that you’d expect to be available? (if so, the hex dump from the end of the *CreateModeFile output would be useful)

The way I’d expect EDID to be used (prior to the ROM gaining proper “*Configure MonitorType EDID” support) is to replace the contents of PreDesk.Configure.Monitor (or whatever the correct file is) with a single *ReadEDID command. The initial portion of the boot sequence will still run in 640×480, but you should get a sensible screen mode on entry to the desktop. If necessary you can add a WimpMode command after the ReadEDID to force a specific mode. Also note that once you’ve made this change, making changes via ScrnSetup should probably be avoided since it’ll just make a mess of the file.

In relation to the ROM builds from November, a further observation is no matter what you set the screen mode to be in “CONFIG.TXT” it is ignored by the ROM, other settings do work.

Yes, that’s the intended behaviour. With BCMVideo 0.40 and newer (which should have first appeared in ROMs on 11th December), and with suitably recent firmware (10th August and newer) the default behaviour for the Pi should be the same as any other RISC OS machine – i.e. the OS will tell the GPU what mode timings to use and the GPU will use those to drive the monitor.

If you’ve configured a rotated display in config.txt or have ‘disable_mode_changes’ in cmdline.txt then the OS will revert back to the old behaviour (leave the GPU mode alone, allow bogus mode timings in MDFs). The only omission is that the builtin MDF still won’t be there (although I might be able to bring that back if people really miss it)

The only known issue at the moment with the GPU mode changes is that having ‘hdmi_group=1’ in config.txt seems to cause it to hang at boot. Not sure why yet.

what <PreDesk$Configure> is

PreDesk$Configure is set in !Boot.Choices.Boot.PreDesk.Configure.!Run :-

Set Alias$VIDCBandLimit X VIDCBandwidthLimit 2000000000 2000000000 2000000000
VIDCBandLimit
Set PreDesk$Configure <Obey$Dir>.Monitor
/BootResources:Configure.ClrMonitor
/<PreDesk$Configure>

!Boot.Choices.Boot.PreDesk.Configure.Monitor has the MDF selection, e.g. :-

LoadModeFile BootResources:Configure.Monitors.HP2229.EDID059Pi3
WimpMode X1680 Y1050 C16M F60

With new a perspective (thank you). I ran the commands *ReadEDID and then *CreateModeFile (with file path), edited the new file and its name to show that I have a Samsung SyncMaster 2493HM. Placed the file in !Boot.Resources.Configure.Monitors.Samsung folder. Amended my original Obey file to point at the new MDF, put it in new a folder and configured boot to run the Obey file at start-up. :-))

Bye the way, some of the the modes created by the CreateModeFile command work really well and a few don’t. The type of issues are border related, either the desktop is outside of the screen bounds or the borders encroach upon the desktop area.

Observations on the start-up screens, my overall opinion is that there are too many stages. 1. Modules, 2. Boot, 3. Final Banner. In contrast the Raspbian start-up screen seems more Acorn like and minimalist than the one in use on the current builds <- Replies to this should probably go into a new thread.

Amended my original Obey file to point at the new MDF, put it in new a folder and configured boot to run the Obey file at start-up. :-)

Wot :-)

Why not simply select the new MDF using the Screen configuration tool?

1. Modules, 2. Boot, 3. Final Banner. In contrast the Raspbian start-up screen seems more Acorn like and minimalist than the one in use on the current builds

The list of modules only appears on the dev builds. Proper releases don’t do that. The boot junk is normal, only better looking, and the final banner replaces the desktop start up message while the Wimp is initialising.

Successful boot takes what, 10-15 seconds? Not enough time to read what the screens say. ;-)

Why not simply select the new MDF using the Screen configuration tool?

Tried that, the settings are lost after a reboot. Following a reboot the screen configuration tool just displays “Auto”. My work around is to use an Obey file and the run at boot time setting.

Tried that, the settings are lost after a reboot.

This seems to be getting a common fault!!

Do you also see the “Failed to open <PreDesk$Configure> for writing” error on attempting to save a Screen configuration.

What happens if !!ZeroPain is removed? That is a diagnostic only.

I can provoke this sort of error with a deliberately installed fault in PreDesk.

The PreDesk messages really do need to be readable or preserved.

Tried that, the settings are lost after a reboot.

Sounds like the same question/solution as here from thje 11th, my panda has a cmos widget but the pi doesn’t have

This seems to be getting a common fault!!

With all of the ROM builds that I’ve used from November it has been the only consistent thing.

Monitor file contents seem suspicious: (!Boot…Choices.Boot.PreDesk.Configure.Monitor)

|oadModeFile BootResources:Configure.Monitors.Samsung.SM2493HM
|impMode X1920 Y1200 C64K F60 LTRGB

I have attempted to uncomment the lines, but the comments just keeping coming back.

ZeroPain removal, not sure how to unpick it from my boot sequence, but this time I’ve noticed that Zero Pain isn’t inhibiting the contents of PreDesk from being run, as Fat32 is running. Which might suggest that ZP isn’t an issue.

Do you also see the “Failed to open <PreDesk$Congirue> for writing” error on attempting to save a Screen configuration"

No.

**Inserted the following to reflect Mike Freestone post above

Sounds like the same question/solution as here from the 11th …

That worked – thank you.

My CMOS settings were already saving so I just added the two ramfs lines to CONFIG/TXT and reconfigured the monitor:

ramfsfile=CMOS
ramfsaddr=0x508000

P.S. What text commands are you using to get the grey quote box?

The PreDesk messages really do need to be readable or preserved.

http://www.heyrick.co.uk/software/harinezumi/

limitations of the current splash screen (a 1920×1080 JPEG can only be squashed and stretched so much)

The problem is that the PreDesk setting has not kicked in by the time the splash screen is first displayed, so it appears with the picture in the top half, rather blurred, and the text in the bottom half (probably 640×480 but difficult to be sure).

Previously the GPU knew the preferred monitor setting was 1920×1080 from EDID and used that in the early stages of booting. By the time the 1920×1080 has been adopted in PreDesk, the boot process still thinks the splash screen needs to be shrunk so it appears in the top LH corner.

When the configure.monitor file is opened for writing is it OPENUP or OPENOUT? (Bug that deletes it may be the cause). Now I know what is happening I’ll try ReadEDID again.

Monitor file contents seem suspicious: (!Boot…Choices.Boot.PreDesk.Configure.Monitor)
|oadModeFile BootResources:Configure.Monitors.Samsung.SM2493HM
|impMode X1920 Y1200 C64K F60 LTRGB
I have attempted to uncomment the lines, but the comments just keeping coming back.

That issue has come up before, but then so has my forgetfulness.

A search for ‘|oadfile’ found it

What text commands are you using to get the grey quote box?

pre tags.

Leave a blank line here else the pre content gets double spaced.

<pre>
stuff
</pre>

I have attempted to uncomment the lines, but the comments just keeping coming back.

Try:
Uncomment the lines, make the file read only, reboot, save settings, reboot, make sure you’re happy with the effect, copy the file somewhere handy and unprotect the file in the boot sequence and reboot.

pre tags.

Thank you. My issue has now been resolved by this post as suggested by Mike Freestone above.

Some digging through the sources for the different Configure plugins suggests that they all write to <Choices$Write>.Boot.[PreDesk|Tasks].Whatever, apart from ScrnSetup (uses <PreDesk$Configure> for monitor settings) and InetSetup (uses <Boot$ToBeLoaded>.SetUpNet for the SetUpNet file). So those two plugins are probably due for a trip to the re-education centre to get them to read/write their settings in the correct manner. That should get rid of the “cannot open <PreDesk$Configure> for writing” errors, although as David says the root cause of that error is most likely the boot sequence failing half-way through, so any new settings which it does save may well be ignored anyway. So a built-in solution for logging and reporting boot errors (and CMOS resets) would certainly be desirable.

When the configure.monitor file is opened for writing is it OPENUP or OPENOUT? (Bug that deletes it may be the cause). Now I know what is happening I’ll try ReadEDID again.

It’s opened for writing. It also explicitly sets the file attributes, so if the file is originally read-only then that shouldn’t stop it from replacing it.

https://www.riscosopen.org/viewer/view/castle/RiscOS/Sources/SystemRes/Configure2/PlugIns/ScrnSetup/c/monitor?rev=1.18#l1364