Pi 3 shutting down-ish

Is this something that others have found too?
When using a Riscos version later than ~Jan 15, 2019, with the latest Bootcode.bin and Start/elf (both Nov 12, 2018) on RaspberryPi 1 or 3B+, it seems no more possible to choose a 256-colour desktop mode. Entering a numbered mode like ‘21’ and choosing ‘256 colours’ or ‘256 greys’ both leave me with a black screen; mousepointer is visible. Only pressing F12 and entering X1280 Y1024 C16M makes the desktop visible again.
Recent Riscos’es (Feb 6 ‘19) on Iyonix or Beagleboard give no problems; also choosing 65K or 16M colour desktops in RPi is unproblematic.
When I replace Start/elf with a version older than Nov 12, 2018 (and keeping the recent Bootcode.bin and fixup.dat) this enables 256-colour screens again.
The other way round, recent Start/elf and old Bootcode.bin, gives the black screen again.
Modefiles derived from current monitor or standard modefiles, or having CMDLINE/TXT in ’Loader’, or not, make no difference, in all occasions 256-colour modes leave the screen black. A riscos rom earlier than januari also solves the problem.
In summary: RaspberryPi only (all versions probably), recent start/elf and recent Riscos seem to result in a black screen when choosing 8bpp screenmodes.

re 8bpp My Pi Zero was upgraded to the most recent ROM, HD4 and Firmware within the last week. It is running happily in 256 colours. I have it set to that because it’s running headless with VNC serer auto starting at boot.

Now I’ve typed that, it occurs to me that even if the HDMI were to go black, there is a likelihood it wouldn’t affect VNC.

Thanks Tristan for the idea! Tried this out with vncserver on a pi3b+, Avalanche on iyonix, from iyonix I can see the 256-colour desktop on the rpi3b+ but the rpi-attached monitor is black, pointer is visible and can be moved. From iyonix the resolution can be changed to 65K or 16M and the image on rpi-monitor is good again. Something between screenmemory-GPU-HDMI, related to start/elf and recent rom?

When using a Riscos version later than ~Jan 15, 2019, with the latest Bootcode.bin and Start/elf (both Nov 12, 2018) on RaspberryPi 1 or 3B+, it seems no more possible to choose a 256-colour desktop mode.

Nov 12 2018 is far from the latest firmware which is 22 Jan 2019 as I type. You will need to be running a fairly recent Pi firmware if using the latest RISCOS nightly build, as it makes use of the gamma mailbox which was recently added to the firmware for us.

I’ve just tested RISCOS 5.27 (05 Feb 2019) with Pi firmware dated 14 Jan 2019 and have no issue with mode 28. I do have disable_mode_changes in CMDLINE.TXT, not sure if that makes a difference or not, but EDID will block most legacy modes if you don’t.

I do have disable_mode_changes in CMDLINE.TXT, not sure if that makes a difference or not,

If you run !ScrnHelp (available from !Store) it will show you whether the GPU is translating the mode or not. With disable_mode_changes RISC OS lets the GPU talk to the monitor and use the monitor’s default resolution and RISC OS uses the resolution you set it to with the magic being done by the GPU in between. Without disable_mode_changes the GPU is instructed to use the mode RISC OS is using which the monitor might not be able to handle on its own.

Thanks Jon, this works. I had done update and upgrade in Raspbian and copied those files but the newer files you pointed me to did the trick.

VCHIQ still hasn’t been ruled out, it is possible to get the machine into a locked state due to its reliance on RTSupport, but that’s a seperate issue that I reported previously and Jeffrey is aware of. We don’t believe it’s related, but as the pointer changes are handled by VCHIQ it can’t be totally ruled out as the cause.

I’ve started work on converting VCHIQ to use synclib to see if that resolves the deadlock issue – it looks pretty straightforward, so I should hopefully have something to share in a day or two.

New test ROM containing those changes:

http://www.phlamethrower.co.uk/misc2/bcm2835dev.zip

I’m not sure if the change over to using synclib helped things, but when testing I did find one bug in the RISC OS code that was causing deadlocks when higher-priority threads use VCHIQ, so there’s at least some good which has come from this. With this new version I’m able to run the BCMVideo and BCMSound VCHIQ threads at high priorities without any obvious issues.

Excellent, I’ll get testing. I’ll test both the blanking issue and if I can repro it, the VCHIQ locking I was previously seeing with certain RTSupport priorities.

I have been testing this new rom all day on Pi3+ with no blanking issue so far, before if i ran !shanghai the screen would blank after a couple seconds been running all day so far will leave it on testing all software and report any issues.

New test ROM containing those changes

Unfortunately it doesn’t fix the blanking issue, the desktop blanked with a few seconds.

if I can repro it, the VCHIQ locking I was previously seeing with certain RTSupport priorities.

This is going to take me a while as I need to go back to a build of ADFFS that produced the issue and then get it working with all the OS changes that now break it.

So it still blanks randomly at the desktop? Or did you never manage to get to the desktop?

It randomly blanks at the desktop. With your CPU and GPU settings I did get a desktop, but my Pi3B had part of it stretched and the other part had a haze around the edges of everything.

Test ROM – 9th Feb and 23rd Jan 2019 firmware – GPU=128

Disable Mode Changes (DMC) set – blank screen occurs at around 3 mins; 2nd test issue occurs at around 30 mins and 3rd test around the same time.

DMC disabled – blank screen occured at around 40 mins, 2nd test ran for about 7.5 hours before a manual shutdown.

With your CPU and GPU settings I did get a desktop, but my Pi3B had part of it stretched and the other part had a haze around the edges of everything.

Did you try increasing them until this problem went away?

New test ROM containing those changes

I’ve been running it since you put it up and haven’t seen any issues. I’ve not tested overlays, but sound and pointer updates appear to be as before.

I’m struggling to reproduce the VCHIQ locking I was getting last year (using an old RO build), so I’ve not tested that yet. My issues however are more related to getting an old version of ADFFS working with the new mode change process.

Given this has no effect on the blanking issue, are we going to try pointer updates via mailbox? Question is, do overlays trigger the issue? Do you have something I can use to test overlays?

What’s the plan with this build? Are you going to push the VCHIQ rewrite to the nightly build?

Yes (now done) – I was just waiting to see if you or anyone else had any feedback.

Given this has no effect on the blanking issue, are we going to try pointer updates via mailbox? Question is, do overlays trigger the issue? Do you have something I can use to test overlays?

Yeah, I can make a test BCMVideo version that uses the mailbox for the pointer instead.

There’s a simple overlay test app in the VideoOverlay sources – or you can use the latest version of KinoAmp (the player stats section of the film info window will indicate whether an overlay is being used by reporting e.g. “YV16 colours”. Or if the desktop isn’t in an alpha-channel mode you can do the much simpler test of opening a menu and seeing if the overlay is appearing ontop of it :-P).

VideoOverlay binaries are in the hard disc image (!System.500.Modules), and remember that the GPU resolution must be <= 2048×2048 for overlays to be available.

I have been running the test rom you posted since you posted it without any problems so far.
Not a single blank screen yet.

Could the blanking issue be related to this:

if you use more than 64 dispmanx elements. The elements seem to get added without error, but the system refuses to remove them, and ultimately dispmanx becomes unstable and the display shuts down.

Only if the some code went crazy and started creating lots of elements (i.e. the rogue mouse pointer bug from a few weeks ago). But in my experience, when that happens the failure mode is different to the “shutting down-ish” failure.

You can always try checking the output of *vcgencmd dispmanx_list after it’s blanked (i.e. via VNC) – although I can’t remember offhand if *vcgencmd still responds once it’s in that state.

checking the output of *vcgencmd dispmanx_list after it’s blanked

The output is identical to before it blanks, so it does at least respond.

Here’s a slightly rough version of BCMVideo that uses the mailbox interface for the pointer.

https://www.phlamethrower.co.uk/misc2/bcm2835dev.zip

The pointer shape doesn’t always update when it should (laziness), and it’ll fall back to using the software pointer in a few cases which could be avoided with more work (e.g. pointer against left edge of screen), but it should be sufficient to test if you still get screen blanking issues.

Here’s a slightly rough version of BCMVideo that uses the mailbox interface for the pointer.

I’m getting a Trust error, followed by a 404 trying to download the test build.

Don’t waste any time fixing the issues, we only want to know if it resolves the blanking to confirm its isolated to VCHIQ.

I’m getting a Trust error, followed by a 404 trying to download the test build.

http, no ‘s’, works here, http://www.phlamethrower.co.uk/misc2/bcm2835dev.zip

Just to check it is the intended ROM :-

*FX0
RISC OS 5.27 (25 Feb 2019)

Build date    : Mon,25 Feb 2019.21:41:25

Just tried Jeffrey’s test build, but got the ‘shutting down-ish’ after about 10 minutes of web browsing.

If I can just check that I went about it in the correct way;

Renamed riscos/img (dated 15 Feb) to o-riscos-o/img
Changed “disable_gamma disable_mode_changes” to “disable_mode_changes” in CMDLINE/TXT
Reboot
Checked *FX0 – shows 25 Feb

Here’s a slightly rough version of BCMVideo that uses the mailbox interface for the pointer.

It blanked within seconds of getting to the desktop, which rules out VCHIQ. The issue surely has to be either timing related or a problem within BCMVideo.

I’ve just retested my pointer via mailbox code and see no blanking issues. I’m setting the pointer in a task though, not within GraphicsV, so I’ll try moving the code into a GraphicsV driver to see if it blanks.

I’ve tried moving the mailbox call to various locations in my GraphicsV driver, they all blank:

• In GraphicsV 5
• Via a callback raised in GraphicsV 5
• At GPU GraphicsV 1
• A 50Hz RTSupport routine

I’ve also tried setting the pointer every VSync, regardless of it moving or not and with BCMSupport both blocking and non-blocking. They all blank.

The difference between all these and my BASIC code is I turn the pointer off via *POINTER 0 and then track it with OS_Mouse instead. This method doesn’t appear to work with GraphicsV as with *POINTER 0, I’m not sure GraphicsV 5 is ever issued.

What occurs with *POINTER 1 that doesn’t occur with *POINTER 0?

EDIT: I’ve now tried it with *POINTER 0 and using OS_Mouse at VSync, which also blanks. Do it from BASIC however and it doesn’t blank.

Has there been any progress with this? I think I’m hitting this problem on my Pi3B+ which I got a few days ago. I immediately upgraded to the latest nightly ROM build and !Boot so I can’t say if this happened with 5.24 or not.

The Pi is connected via HDMI to an LCD display. No converters involved. Randomly the screen goes black and then a few seconds later the display goes in to sleep mode (no signal). The Pi still seems to be working but I need to confirm this (e.g. see if I can still ping it, see if VNC responds). The only way to get the display back is to Shift+Break to restart the Pi.

I can’t find a way to reproduce the problem. Sometimes it can happen a few minutes after booting. Sometimes it can be over an hour before it happens. I don’t need to be doing anything in particular like causing a load of disk IO, doing anything CPU intensive. It has happened whilst the Pi has been idle.

The only thing I have changed is created CMDLINE/TXT with “disable_mode_changes” for ADFFS.

Edit: Stuart Painting pointed me to this in another thread which clearly says that I need disable_gamma in CMDLINE/TXT. I’ll give this a shot and hope it fixes the issue.