Invisible boot

My ARM6 boots with nothing visible on screen. The desktop eventually appears, until then nothing.
Mode and Wimpmode are both configured to 31.

While this isn’t in itself a problem, occasionally the machine never gets to the desktop, and with no output, it’s difficult to see what’s happening. In this situation the shares don’t appear to other RISC OS machines, and Avalanche can’t connect. It doesn’t respond to ctrl-shift-F12. It can take several power-off/on cycles to get it to boot. I’ve tried taking the lid off and wriggling various connectors, which doesn’t seem to make a difference.

I’ve got Reporter logging the boot, but as the desktop doesn’t appear this isn’t as useful as I would have hoped.

I have now installed harinezumi, which logs to file. However I’m not sure how to get to this log before the next boot attempt overwrites it.

Any suggestions?

You could try checking what *status monitortype reports (should be 4 for MODE 31/32 to work). I’d also tend to use 32 (256 colours) rather than 31 (16 colours). Indeed, that could be your problem.

Finally, you could set mode/wimpmode to auto and monitortype to EDID which should give some kind of EDID-based picture during predesk.

Thanks. Unfortunately none of those made a difference.

It may be because of my setup – The ARMX6 output goes to an HDMI-VGA converter, which then goes to a 4-way KVM switch. Since two of the computers connected to the switch don’t support HDMI/DVI, I don’t have much choice.

(I did try sending HDMI direct to the monitor, and the other computers using VGA via the switch. However the monitor doesn’t switch inputs automatically, because it has active signals on both inputs all the time, and it takes 4 or 5 button presses to switch manually, which I don’t find acceptable. I switch a lot.)

The monitor is a large BENQ, running at 2560 × 1440, framerate 46 or 48hz. With 60Hz it simply reports “out of range”. During boot I initially get “No signal detected” , then a black screen. It does not report “out of range”.

However something’s changed, as a couple of years ago I did get output using this setup. I don’t know when it stopped. It could have been an OS update.

However I’m not sure how to get to this log before the next boot attempt overwrites it.

From the Versions file: So what Harinezumi does now is that if the boot should fail, then the boot log (either the default $.!Boot.BootLog or a custom filename) will be copied with the date and time suffixed, for instance BootLog → BootLog_20170710-213017 [ yyyymmdd hhmmss ] In this way, you can always refer back to see what went wrong.

So, if something went wrong you would see it logged. If there is no such log, then either the boot makes it to starting the desktop, or something went so badly wrong that it messed up hard (in which case you should have either an empty or partial log).

So, if something went wrong you would see it logged. If there is no such log, then either the boot makes it to starting the desktop, or something went so badly wrong that it messed up hard (in which case you should have either an empty or partial log).

Excellent. Now I just need to wait for a failed boot. Could be a few days.

I would also point out that Reporter will optionally log to disc, so that even if the machine locks up everything will be written up to that point. See Help → Configuration → Logging. It can be used from !Boot, and can avoid overwriting old log files.

Excellent. Now I just need to wait for a failed boot. Could be a few days.

Uh… Be careful what you wish for… ;-)

so that even if the machine locks up everything will be written up to that point

Do you flush the file after every modification?

[disclaimer: Harinezumi doesn’t, but then it uses the C file functions which add their own complications and layer of buffering; I ought to do something about that, but I’ve not yet run into a situation where the machine locked solid with pending data…]

I would also point out that Reporter will optionally log to disc,

Horses for courses Martin.
Harinezumi actually runs the Boot for you and unlike the default build doesn’t allow the system to quietly collapse in a heap.
While Reporter passively monitors and logs what happened Harinezumi actively aims to ensure the Boot actually completes despite any errors in the sequence.
The descriptions to date have suggested something early in the boot, before apps are run resulting in a system that’s difficult to use to locate the source of the fault on the boot because the boot didn’t complete – that’s where the “force it to continue” aspect of Harinezumi works so well.

I dare say that Reporter added to a Harinezumi boot might well log more information than either on its own.

I ought to do something about that

Harinezumi actively aims to ensure the Boot actually completes despite any errors in the sequence.

Thanks Steve, that’s a nice succinct summary of the difference.

It also aims to be friendly/useful enough that it can just “do it for you” all the time, not just when something seems wrong.
All my machines (real and emulated) boot with Harinezumi, it’s intended to be “set it and forget it”.

Do you flush the file after every modification?

Yup. Reporter basically does:

SWI       "OS_GBPB"    ; Write 
MOV       r0,#255      ; Flush data
SWI       "XOS_Args"

Thanks Steve, that’s a nice succinct summary of the difference.

Agreed. Both have advantages and disadvantages, but both have their uses!

OK, so I have found out a bit more about the issue.

The monitor, a large BENQ (2560×1440) has the annoying characteristic of blanking for betwween 10 and 15 seconds each time the video characteristics change, e.g. screen mode change or screen blanking.

I connected an older, less capable monitor, and did see the final part of the init_mod messages before that too blanked for a mode change.

So the reason for the lack of display is that the screen mode keeps changing during boot, at intervals of less than 10 seconds. I assume the reason why I used to see the messages, and now don’t, is that an upgrade has speeded up the boot. Maybe setting Reporter to log to disc would slow it down enough, if it starts early enough in the sequence. One thing it does tell me is that the boot is not stopping with anything on screen, otherwise, after 10 seconds or so, I would see it.

I haven’t recently had a failure to boot – not since I installed Harinezumi, so I don’t know whether it’s because that is fixing the freeze, or it just hasn’t occurred yet.

When it does, I have one more test to apply – I’ve reported elsewhere that the Printer Manager process freezes the machine, but it does respond to alt-break. If I get a failed boot, I will try alt-break, ret to see whether the lockup is the printer manager.

I still don’t know why Printer Manager freezes though.

I have recently discovered that the Raspberry Pi Zero W will also do an “invisible boot” when connected to some (all?) TV sets: no picture appears until the desktop is running. The same SD card in a Raspberry Pi 3B will produce the normal boot-up display.

Witnessed with RISC OS 5.27 (Feb 2020 build) and RISC OS 5.24.

Workaround: Connect the Pi Zero W to a “real” monitor.

has the annoying characteristic of blanking for betwween 10 and 15 seconds each time the video characteristics change, e.g. screen mode change or screen blanking.

Yeah, it’s amazing how long it takes modern monitors to lock into a signal. My 1280×1024 LCD panel used to take about 6-10 seconds upon every mode change (which was also returning to the Desktop from the command line).
I “fixed” it by reverting to the earlier behaviour of disabling all mode changes and informing the GPU that my display is 1280×1024@60Hz. Now? Now RISC OS can try anything from MODE 7 to FullHD and the GPU scales it to fit. Mode changes are near instant as the Pi is actually outputting the exact same thing all the time, it’s the GPU fiddling things to fit.

I connected an older, less capable monitor, and did see the final part of the init_mod messages before that too blanked for a mode change.

Yes, it looks like the mode is initialised between two and four (usually three) times:

• [possibly: Does the boot loader bring the display to a known state, or does it leave that to the OS? Probably depends upon the hardware. Wasn’t there one device (Pi 1?) that booted up with a coloured square before the OS was started?]

• After bringing up the system enough to switch on IRQs, in preparation for the module initialisation outputting something. This may be something like MODE 28 (SVGA); but note that a GraphicsV driver can specify any custom mode that is known to RISC OS. The Pi specifies 1920×1080 (in BCMVideo, I hacked mine to start up in 1280×1024).

• After post-init and callbacks ready, prior to outputting the traditional message of RISC OS, how much memory, and what sort of processor. This will be the same as before.

• [optional, but usual] By !Boot.Choices.Boot.PreDesk.Configure to set up your desired screen mode as set in the system configuration.

So the reason for the lack of display is that the screen mode keeps changing during boot, at intervals of less than 10 seconds.

It’s worth pointing out that starting XP is much the same, only it doesn’t lead to the “nothing on the screen” because it takes so damn long for everything to happen. Namely:

• Whatever (16 col VGA?) the BIOS starts up in.
• That weird low-quality mode that is used to display the initial “I’m starting” display.
• A better quality display where you can either log in, or it says it is loading your settings.
• The configured Windows resolution, once it has finally started.
• Though I have one PC that insists on refreshing the screen (and reselecting the same mode) twice more as the system boots. Once when the graphics widget is put into the SysTray, and once more because it hasn’t quite trolled me enough.

But I can see what’s going on because Windows startup is slow. Hell, getting past the BIOS takes longer than it takes RISC OS to boot to desktop. :-/

I haven’t recently had a failure to boot – not since I installed Harinezumi, so I don’t know whether it’s because that is fixing the freeze,

Is there any saved Harinezumi log?

Alternatively, are you using static IP or DHCP? The latter can, sometimes, stall the system while it is doing its thing.

I’ve reported elsewhere that the Printer Manager process freezes the machine, but it does respond to alt-break. […] I still don’t know why Printer Manager freezes though.

Is this when you’re trying to print, or not?

If when trying to print, that is normal. RISC OS is, at heart, a single process single context operating system. So what the Printer Manager does, when printing, is claim all of the display output (drawing, fonts, colours, all of it). This simplifies the printing mechanism because it simply sits in a loop drawing bits of the output in the same manner as it draws windows on the screen (namely: here’s a rectangle, fill it, loop until done).
But because RISC OS doesn’t have application specific graphics contexts, the printer driver will block the entire machine for the duration of the print job.

If it is happening elsewhere, you should check your printer settings because nothing should be hanging up the machine like that. The files for controlling Printers are in !Boot.Choices.Printers in case you want to move them out of the way and set things up again.

I have recently discovered that the Raspberry Pi Zero W will also do an “invisible boot” when connected to some (all?) TV sets: no picture appears until the desktop is running.

Probably all those mode changes. :-)
If you fix the output resolution to your monitor/TV and force the GPU to use it, you will see the init text.

Probably all those mode changes. :-)

I have – belatedly – realised what the real issue is. When booting-up a Pi 3B, the TV doesn’t show the boot-up screen until the “Waiting for DHCP server” message is already being displayed. The Pi Zero W hasn’t got an Ethernet port, so boot-up happens that little bit faster: fast enough that the TV doesn’t have time to display the boot-up screen before the next mode change (for the desktop) happens.

Panic over :-)

Is there any saved Harinezumi log?

I keep the previous log, but unless i think something went wrong, I haven’t looked at it. The next reboot replaces it.

Alternatively, are you using static IP or DHCP? The latter can, sometimes, stall the system while it is doing its thing.

It’s all static IP

Is there any saved Harinezumi log?

I rename the existing log before starting Harinezumi, so there is one previous one. I haven’t looked at it in detail yet.

If it is happening elsewhere, you should check your printer settings because nothing should be hanging up the machine like that. The files for controlling Printers are in !Boot.Choices.Printers in case you want to move them out of the way and set things up again.

I can switch the machine on, walk away, have breakfast and come back to find it frozen. Other times it will go for a week without doing it.

I’m using two network printers, connecting via NetPrint 1.01. I noticed today that the current version is 2.02, about 10 years newer, so I’ve ordered that. Other suspects (i.e. things not part of a default printer setup) are PS3 and a duplex add-on for postscript printers.

My suspicion is that the printer manager freeze is not related to the failed bootups, because I’d expect to see a desktop is it was. However until the boot fails I can’t test it. If that is the problem, I’ll probably remove Printers from startup, and put a file on the desktop to start them when needed.

If you fix the output resolution to your monitor/TV and force the GPU to use it, you will see the init text.

I don’t know of a way to do that on an ARMX6. I can, and do, do that on the rpi’s.

One other thing that confuses me – what do Mode and Wimpmode do? I’d sort of assumed the non-desktop output used Mode and the desktop used Wimpmode, but the desktop setting is way different from Wimpmode, so what does that do, if anything?

I’d sort of assumed the non-desktop output used Mode and the desktop used Wimpmode, but the desktop setting is way different from Wimpmode, so what does that do, if anything?

*Configure Mode did do something different at RISC OS 2, but since RISC OS 3 it’s been an alias for *Configure WimpMode.

*Configure WimpMode itself is pretty much useless these days, as only a handful of the numbered modes are supported on modern hardware. There is also the risk that you’d run into this bug so current advice is to use *Configure WimpMode Auto (and choose the desktop screen mode via “Configuration > Screen”).

*Configure Mode did do something different at RISC OS 2

Yes, as Stuart has said, RISC OS 2 had the idea of being able to boot in one mode, and run the desktop in a different mode. No idea why they made the distinction – perhaps Acorn thought people might want to boot in MODE 7 or something?

These days it’s just a bit of legacy cruft like *Ignore and the corresponding *Configure Ignore…

bq *Configure WimpMode itself is pretty much useless these days

Pretty much anything that refers to “numbered modes” is more or less useless. The only one you’re likely to find much call for is MODE 28 which is 256 colour VGA (640×480) or MODE 32 which is 256 colour SVGA (800×600); or MODE 7 to which I don’t think there’s a textual way to select this…

For anything else, anything more modern, or anything with more than 256 colours, you’ll need to refer to a mode by description.

I haven’t looked at it. The next reboot replaces it.

I meant one copied by Harinezumi itself with a date/time suffix. If that doesn’t exist, then it didn’t notice anything wrong so the boot log it provides is just an account of what is actually happening at boot.
Do you get all that stuff on-screen, or do you use Quiet mode?

I can switch the machine on, walk away, have breakfast and come back to find it frozen. Other times it will go for a week without doing it.

Ah, the annoying intermittant bug.

I’m using two network printers, connecting via NetPrint 1.01

NetPrint?!? Wasn’t that something to do with Econet?

My suspicion is that the printer manager freeze is not related to the failed bootups

Tell me more about NetPrint. I don’t want to blame it, but I’m wondering if some sort of underlying protocol module that deals with printing and is probably loaded at boot might be worth looking into. After all, it might be the link between boot and Printers?
Just pure guesswork, of course.

I don’t know of a way to do that on an ARMX6. I can, and do, do that on the rpi’s.

You can’t. Most GPUs need to be told what to display and how, the Pi’s GPU is quite a lot more capable in that it can either do it like that, or it can output a steady fixed signal and resize everything that the OS thinks it is using on-the-fly to fit. It’s pretty smart, and it does it without horrible scaling artefacts.

I’ll probably remove Printers from startup, and put a file on the desktop to start them when needed.

Are they not in the “Apps” thing on the iconbar? If not, Configure → Boot → Add to Apps.

I haven’t recently had a failure to boot – not since I installed Harinezumi, so I don’t know whether it’s because that is fixing the freeze,

Is there any saved Harinezumi log?

Tonight I had a failure. After three power-cycles it booted. I checked the logs. There is a bootlog from the current successful boot, and a last_bootlog from 10am this morning. The two failed attempts haven’t created a log.

When it was sitting silently, but powered on, I tried a ping – no response, so it definitely hadn’t completed internet startup.

Alternatively, are you using static IP or DHCP? The latter can, sometimes, stall the system while it is doing its thing.

It’s statically addressed, and see above – it’s not getting that far.