Raspberry-Pi boots up without Loader in !Boot

@Doug

EDID is not a module so will not appear in a listing.

But ScreenModes is, just got the wrong name and so missed it in the Verma listing. It is there.

Also isn’t the monitor you mentioned DVI/VGA only with no HDMI port.

It’s not that old! It has has HDMI.

@Colin
Help Screenmodes gives “Module is: ScreenModes 0.61 (05 Mar 2017)”. So that looks right.
readEDID gave “File ReadEDID not found”. :-(
savemodefile ram:$.modefile saved out an MDF for “Iiyama ProLite B2409HDS” although I was using the Motorola Lapdock, but using an MDF for the Iiyama. Presumably, the screen modes produced are for the Lapdock as many were not the same as for the Iiyama ProLite B2409HDS MDF in Resources.Configure.Monitors.
I still don’t see “Native” as one of the resolutions listed in the Configure application.

Since you didn’t say whether you had re-enabled RTC before doing the Kill on NetTime

No … but I did say the Restart had worked! So both would be re-enabled.

No … but I did say the Restart had worked! So both would be re-enabled.

To me that indicates the problem is probably an interaction between the RTC and NetTime.

The problem doesn’t always occur for everyone. We tried replicating it with a ROM and disc image from about 10 days ago and the error didn’t occur for us. Could someone who is solidly seeing the problem. Set their time to not be nettime and see if the problem goes away?

I would have thought 0.61 would work but the version in the rom I’m using is 0.63 (12 Mar 2017) does ‘* status’ show ‘mode auto’

Entry in CVS mentions that ReadEDID was restored in 0.62 and cmhg file put back in for version 0.63.

Might be worth a try.

Also have you tried it with a new Choices set up as I had similar issues with low resolution screen mode start ups on one upgrade that was due to some issues in my Choices folder.

Doug

I should add that the monitor being used is an Iiyama ProLite B2409HDS.

I think that should be E2409HDS, a HD monitor which has both HDMI and DVI inputs – I have one myself!

The problem doesn’t always occur for everyone.

That why I’m not testing it myself. I get it from time to time (self-built low vector ROM from early Feb), but it is usually after a crash has wiped out everything else. :-)

I doesn’t happen regularly enough to try to pin down to a reason, but the more interesting thing to me is what is trying to call OS_ChangeDynamicArea after the machine has gone through the usual shutdown sequence? And what is bugged enough that calling that just results in a load of them endlessly scrolling (instead of, you know, checking V flag…).

@John Williams
You may have an E2409HDS, but I have an B2409HDS, so there! :-)

“We shall not be moved” after “Restart” problem ;-)

I thought I would do another “Restart” after upgrading to Upgrade8H and putting the RTC back in and without doing the suggested RMKill commands just to see whether the upgrade got rid of the problem. Guess what? Memory can be moved or whatever – problem gone. And, yes, it’s on Net time according to Configure application.

Monitor resolutioons problem/EDID.
After following Chris Hall’s suggested commands, “Configure MonitorType EDID” and *Configure WimpMode Auto ", I now see the “Native” entry in the resolutions menu of the Configure application; but guess what, choosing that gave the worst resolution of 640×480 256 colours, not the best. :-((
In fact the Lapdock will do 1920×1080 with 16 million colours. Application ScreenHelp says it’s running at 1024×768 and “Monitor received or understood 1366×768 at 60Hz”.

David

Firstly if you are trying to use EDID with a Lapdock then the resolution of the screen does not conform to the RISC OS standard i.e the 1366 element. RISC OS can manage 1360 × 768.

I had issues on my Lapdock trying to use the EDID data in the past.

Does your set up now work with your monitor as opposed to the Lapdock as you have now added another variable.

In particular for the Lapdock I have the following additional lines in my Config/txt file over the one in Chris’s 8H:

disable_overscan=1
hdmi_drive=2

Also I notice the time stamp on the CMOS file in Chris’s 8H update is 1st Jan 1980 and you seem to indicate you upgraded from 6L/5L?.

If you had to use the configure commands then this suggests it wasn’t set in the CMOS file you had. How did you upgrade to 8H did you use the force option to overwrite things?

What happens if you get a clean card and upgrade a clean RC14 set up to Chris’s 8H?

Doug

OK, I’ve upgraded my Pi2 with Chris’s 8H and get screen resolution issues with it attached to the Lapdock.

In Auto setting it gives 640x 480 rather than the previous 1920 × 1080 option. It also gives a rather poor screen resolution on the splash screen as well before it hits the desktopm.

I then updated the ROM to the latest, 19th March 17, which enables ReadEdid and get the same issue. Also the MotoAttach selection gives an error when trying to set the colours and shows nothing in the resolution options. The error states component,0xffffffff, is missing.

Using ReadEdid in the monitor icon allows you to set a resolution of 720 × 576 but no 1920 × 1080 options are shown.

SaveModeFile does give the a higher resolution of 1366 × 768 option in the resultant file but of course RISCOS can’t use the 1366 resolution due to restrictions which mean it must be divisable by 4/16? .

So there does seem to be an issue with the Lapdock and the latest ROM’s.

I then attached the Pi2 to my LG M2380 monitor and I can set the screen resolution correctly to 1920 × 1080 , 16M colours using the M2380 screen set up generated in Screen Set up. It still gives a poor screen splash resolution before it hits the Desktop.

So some work still required to get the RISC OS Raspberry Pi set up working with the latest image and ROMs.

Doug

In Auto setting it gives 640x 480 rather than the previous 1920 × 1080 option. It also gives a rather poor screen resolution on the splash screen as well before it hits the desktopm.

Don’t pick auto, your monitor isn’t called auto is it? I followed these instructions and my panda’s all set up nicely

Mike

Thanks for the advice but as I also said if I pick the EDID produced option, i.e. MotoAttach, below the Auto option in the new screen mode configure plugin then it gives an error when I try to select the resolution/colour depth.

I then updated the ROM to the latest, 19th March 17, which enables ReadEdid and get the same issue. Also the MotoAttach selection gives an error when trying to set the colours and shows nothing in the resolution options. The error states component,0xffffffff, is missing.

The Pi2 does work OK when attached to my LG M2380 monitor as does my Panda to the LG M2380 with the latest ROM’s so it is something to do with the fact that the Lapdock screens highest resolution is not a standard type that RISCOS can use.

The top resolution the MotoAttach gives is 1366 × 768 and I think it is the fact that 1366 is not divisable by 4 or is it 16 that RISCOS will not accept in it’s screen resolutions.

Best I can do with the lapdock is 720 × 576 and only via the display icon not the screen configure plugin due to the error message I get.

One possibility is that the EDID data produced by your monitor is flawed. For that reason the SaveModeFile option allows a MDF to be created from the EDID data, which can then be examined and corrected. You would then save the corrected MDF and select that from the screen configure plug-in and not use MonitorType EDID.

Chris,

As I and you thought if I save out the EDID information and then replace the 1366 × 768 modes with a 1360 × 768 mode then use that new MDF I now can get a higher screen than 720 × 576.

Initial Pi splash screen is still low res so something in the boot sequence needs altering and also !AcornMode doesn’t run as it does not have a suitabke MDF entry and also Aemulor doesn’t.

I think as far as the Lapdock is concerned I’ll stick with the older ROM as it at least gives a easier experience at this stage.

So the new EDID for RISC OS isn’t quite as magical and automatic as we were led to believe.

I need my Raspberry-Pis to use my Lapdock as this is more portable than carrying around a 22" or 24" monitor, for example, taking to club nights (SAS AUG and ROUGOL) by public transport.

I have been trying to find out where the Raspberry-Pi splash screen/banner resides, but can’t find it. It can’t be stored in the firmware, surely? But I can’t find it in plingBoot.

Also, where do the Raspberry-Pi ‘Builtin’ in modes live? The only way I have found to get them is to remove the directory, Choices.Boot.PreDesk.Configure or alter the full pathname of the MDF in the first line of the Monitor file inside Configure to a non-existent MDF file. ¹ Regarding the latter, in a Raspberry-Pi that was running the Built-in resolutions I found that this line contained the pathname
BootResources:Configure.Monitors.AKF60 ,
where notice the absence of “Acorn.” I didn’t do it, honestly! What a kludge!

¹ This worked with a ‘pre-EDID’ version of the OS, but hasn’t worked with the’EDID’ version.

David

I don’t see it as a negative having EDID support as in the vast amount of cases it should work out of the box.

Th issue is what happens when it does not and the old RISCOS/Pi set up of using the GPU to scale makes it easier in that case.

In the case of the Lapdock then you should be able to set things to MotoAttach + Native and it will do 720x 576 but no more as the 1366 × 768 resolution is not a valid recognised resolution.

I can send you my modified MotoAttach MDF which will do 1360 × 768 if you want.

Also hopefully with this feedback ROOL may be able to improve the ScreenMode/EDID set up as this is the first iteration and is as I said for the majority of cases a great addition.

This is worrying. It is still possible to bypass EDID properly right?
Although if it’s not it might explain why the startup screens on my Pi Zero are so messed up. It goes from a super low resolution boot splash to a small splash image in the bottom left after initial boot with the rest of the screen grey (at the right res I think) while everything is loading. Relying on EDID causes absolute havoc for me. While the PC can detect the monitors, pretty much any SoC based device is problematic.

On my Zero I have a monitor definition file I made myself from the specs, and use AnyMode and the config file (I forgot the name sorry) to force the resolution to 1600×1200. If I don’t RISC OS runs at the wrong resolution.

I have been trying to find out where the Raspberry-Pi splash screen/banner resides, but can’t find it. It can’t be stored in the firmware, surely? But I can’t find it in plingBoot.

It can be found in Resources:$.Resources.BootFX, so is presumably loaded in the module.

Also, the backdrops are, rather unintuitively, located in the HD image in the folder Documents.Images -it took me a while to work that out!

And I think I can be forgiven for thinking you might have mistaken an E for a B in your monitor title. They have a lot in common!

Answering various questions: I have started from scratch with a new micro SD card, formatted with HForm, set up !Boot with Loader using SystemDisc, copied in Chris Hall’s Upgrade8H and copied in all the software from the latest build of ‘HardDisc4’ from this website and still there is a large black border round the pinboard on my Iiyama Prolite B2409HDS with a 640×480 resolution. In the configure application, although Iiyama appears in the list of MDFs, my model doesn’t and there is no “Native” entry anywhere.
I have not done a “Configure MonitorType EDID” and *Configure WimpMode Auto” this time round as it didn’t solve any resolution problems before (see above). Is this necessary for EDID to function?
If it is necessary to issue these two commands, I don’t see it mentioned anywhere under the “Using it on your computer” section of Latest news (the full version).

I could experiment further, but am getting fed up with trying stuff and getting nowhere.

Experimenting with RC14 + Update8H reveals the following:

• The CMOS file supplied in Update8H has the configured mode set to 7. This appeared to upset NetSurf a bit when it tried rendering the “Welcome to RISC OS Pi” page (corrupt rendering). Looks like this could be a bug in the Wimp (OS_ScreenMode 1 says the mode is 28, which is correct, but Wimp_ReadSysInfo 1 claims the mode is 27). Manually switching to mode 28 (or any other sensible mode) fixes things.
• Black borders around the screen are typically due to the default overscan settings used by the Pi’s GPU. Add disable_overscan=1 to config.txt and they should go away.
• In the screen setup plugin, if you’re looking in the Iiyama sub-menu of the monitor list then you’re looking in the wrong place. The EDID setting should appear directly under the “Auto” setting at the top of the list. (I’m not sure why we’ve ended up with a confusing way of selecting EDID)
• Once you’ve selected the EDID entry, “Native” should appear under the Resolution menu. When selected this will grey out the Colours and Frame rate options.
• After selecting EDID + Native, the “Try” button doesn’t do anything useful for me because my monitor’s preferred mode is outside the default limits enforced by the Pi’s GPU, and ScreenModes won’t try falling back to other modes. This is solvable by adding appropriate max_framebuffer_width, max_framebuffer_height and hdmi_pixel_freq_limit settings to config.txt (although since the screen setup plugin won’t tell you what the native mode is, you’re on your own for working out what limits to set).
• Trying to save the settings is resulting in the “Not found”, “Failed to open <PreDesk$Configure> for writing” error that other people have been reporting every so often. For this case, at least, it looks like the problem was caused by installing Update8H onto a virgin boot sequence (i.e. before the appropriate hook folder had been used to initialise Choices). Installing Update8H created a Choices folder in order to install ZeroPain, which then fooled the boot sequence into thinking you’ve got a full boot sequence present, thereby preventing the seeding of Choices from the hook folder. Curiously, Choices$Path does include the hook folder, so the default choices can be found by the OS (along with ancilliary files like Choices.Boot.PreDesk and Choices.Boot.Desktop), but the “Do Repeat” commands that are responsible for PreDesk use Boot$ToBeLoaded which is set to Boot:Choices.Boot.PreDesk, i.e. skipping the hook PreDesk altogether. (the Repeat commands in Choices.Boot.Desktop use Choices:Boot.Tasks, so it seems like a bug/oversight that PreDesk isn’t handled in the same way). Manually copying the contents of !Boot.RO520Hook.Boot into !Boot.Choices.Boot fixes this, and fixes other things like the default network configuration not being applied.

I have not done a “Configure MonitorType EDID” and *Configure WimpMode Auto” this time round as it didn’t solve any resolution problems before (see above). Is this necessary for EDID to function?

Changing the configured monitor type + wimpmode is only necessary if you want EDID to function for the early parts of the boot sequence (or if you have no boot sequence at all). In particular, for Raspberry Pi this should avoid the splash screens looking ugly (e.g. it should avoid the vertical offset that’s applied when the splash is used in 4:3 modes)

Changing the configured monitor type + wimpmode is only necessary if you want EDID to function for the early parts of the boot sequence

Actually, I take that back. The saved “native” settings don’t appear to take effect properly.

After rebooting, the EDID is being read, but the desktop is entered in mode 28. !Boot.Choices.PreDesk.Configure.Monitor has the expected content (LoadModeFile of the EDID + no WimpMode command). *Status shows that monitor type and mode are Auto. OS_ReadSysInfo 1 (which is what the Wimp should use to read the default mode) is reporting the mode I’d expect, but for some reason the Wimp is deciding to start in mode 28 instead.

*Configure MonitorType EDID makes things work properly.

The CMOS file supplied in Update8H has the configured mode set to 7

Yes, I just used CMOS from the ‘Pico’ build. I did say that you need to do a *Configure monitortype EDID and a *Configure WimpMode Auto.

Immediately below the ‘Auto’ setting in the screen configure plug-in is the name of the monitor read by EDID. Didn’t know about ‘Native’. I was OK with ‘Try’ but my monitor will only do 1080p at 24Hz not anything near 60Hz so has trouble with almost any MDFs. Update8H is only for use on a working RISC OS RC14 set up, it won’t work on an unused RC14, as you note.

One problem I found when testing a set up that sometimes had an HDMI monitor attached (during debugging) otherwise used an OLED display (to cut power consumption down from 450mA to 150mA and then to 18mAh/h by time slicing) was that with the MonitorType set to EDID, the boot sequence would hang if no monitor was attached. I had to use the old method and put up with a crappy splash screen (unless the hdmi_group=2 command has now been fixed).

Principally it is to allow a user with RC14 to (i) try out the latest ROM and (ii) not have to start with a fresh install (such as for example with RC15 when finished). It also has the GPIO module rolled into the ROM as I haven’t worked out how to make a stand alone GPIO module, despite hints from Sprow. With any luck it will prompt a few more ZeroPain reports – I think the latest version of !Zap (1.48.7) downloaded from !Store still reports ZeroPain errors for example, but as the supplier is ‘Unknown Supplier’ it is not clear where those reports should be sent.

Any suggestions how to improve Update8H or the instructions as to how to use it would be most welcome.

If I followed Jeffrey’s comments correctly, then it might be prudent to alter your update so you don’t include an incomplete Choices.Boot folder. Or at least warn the use that they must have booted up at least once beforehand.

On a related point, does anyone know the deal with distributing your own complete image? An SD image with the Pi firmware, RISC OS ROM and HardDisc4 ready-to-go might make things easier for people. The extra goodies like NetSurf and StromgEd can be obtained by the end-user can’t they?

then it might be prudent to alter your update so you don’t include an incomplete Choices.Boot folder

Completely wrong. It is to update a working RISC OS RC14-based set up.

The whole point of the RC14 SD card image was to provide a complete, working image.

The whole point of the RC14 SD card image was to provide a complete, working image.

And the image does work. But because the boot sequence is in the “virgin” state, making certain changes to it before booting the image can cause complications.

The differences in how Choices.Boot.PreDesk and Choices.Boot.Tasks are handled are probably a bug in the boot sequence. Once that bug has been fixed there shouldn’t be any problems with installing ZeroPain into the !Boot.Choices of a virgin image.