Software testing help wanted for Raspberry Pi

Although since it’s somewhat reliant on the ROM being able to boot into a high-res, true-colour mode it might be a bit fiddly on machines where you can’t read EDID data or might have limited VRAM.

Why does it need very hires or high colour?

Can’t there be an alternate graphic?

Can’t it just believe the configured mode or wimpmode if it isn’t told better?

Why does it need very hires or high colour?

It needs to be high res so that there’s enough space for the splash image to fit around the terminal window. Remember that a few posts back you asked for the terminal window to be bigger!

High colour is just a nicety, I guess a 256 colour splash using a custom palette could look OK as well.

Can’t there be an alternate graphic?

Can’t it just believe the configured mode or wimpmode if it isn’t told better?

Yes and yes. Note that I said it was “somewhat reliant” on high-res/true-colour, not “100% dependent” :-)

Part of the problem is that the more screen modes it needs to support, the more splash screens that may end up being needed. It may be worth using drawfiles for the splash screens instead of JPEGs, at least that way you’ll get crisp lines and text, whatever the resolution. But since it’s Steve who’s working on this and not me I think I’ll leave all these fun discussions for him ;-)

With the testing of the screen modes, is anyone using a later Start/elf?
When I try (for example to get more memory) I get 1280×1024 to the monitor, so setting any other mode means it’s scaled, which in the case of 1920×1080 means it’s letter-box, squashed and blurred.

The reason I ask is I’m using a HDMI-DVI cable, so was wondering if that is the cause.

It needs to be high res so that there’s enough space for the splash image to fit around the terminal window. Remember that a few posts back you asked for the terminal window to be bigger!

On further inspection, I think what I want is for it not to be scaled.

I occurs to me that the image could be the configured background, if the filesystem is available in time. That would give the impression of a really fast start-up.

Jess, regarding your HDMI/SPDIF. Please email me (webmaster@tankstage.co.uk) as I have a 4 input HDMI switch that has TOSLink and Coax out as well as the original HDMI surplus to requirements.
P.S. Sorry for the advertising noise!!

I have had to edit Boot.Choices.Boot.PreDesk.Configure.Monitor manually to remember my (RISC OS) screen resolution:
|oadModeFile BootResources:Configure.Monitors.HP.HP-LP2465
WimpMode X1920 Y1080 C16M
Note the ‘|’ on the first line (not a lower case ‘L’).

The ‘|’ replacing the L at a start of MDF setting is a strange one. From RISC OS 3.5 onwards you will normally have an ‘L’ i.e. ‘LoadModeFile’ but if you did a power on delete you will find it has changed to the ‘|’

I have had to edit Boot.Choices.Boot.PreDesk.Configure.Monitor manually to remember my (RISC OS) screen resolution:
|oadModeFile BootResources:Configure.Monitors.HP.HP-LP2465
WimpMode X1920 Y1080 C16M
Note the ‘|’ on the first line (not a lower case ‘L’).

I’ve updated by BBxM to the ROM from 06-Sep-2012 and after some time eventually found this issue was causing my screen choices to be ignored on reboot.

The ‘|’ replacing the L at a start of MDF setting is a strange one. From RISC OS 3.5 onwards you will normally have an ‘L’ i.e. ‘LoadModeFile’ but if you did a power on delete you will find it has changed to the ‘|’

My BBxM does not have a RTC battery so will essentially be doing a delete power on each time. Is this the reason for the ‘|’ being written? Can this be fixed/removed please?
It never happened on the previous ROm image I was using.

Cheers,

Mike.

My BBxM does not have a RTC battery so will essentially be doing a delete power on each time. Is this the reason for the ‘|’ being written?

The RTC battery is a red herring in this situation as the RTC clock on the BBxM really is just a clock and nothing else (as it was on the Iyonix) compare with the RiscPC (where it also has battery backed memory).

As mentioned by Chris it would appear you’re doing endless delete-power-ons. The 4 solutions to this are

1. If you’re a member of the ARMini support scheme, contact RComp to arrange receipt of a CMOS memory upgrade which pushes onto a header on the BBxM board
2. If you’re loading your CMOS settings from disc (eg. written with SDCreate, or otherwise, to the micro SD card) make sure you didn’t create/save the ‘cmos’ file with the delete-power-on flag set!
3. If you already have a CMOS memory upgrade fitted, with more recent ROMs be sure to either *UNPLUG SDCMOS or delete the file called ‘cmos’ off the micro SD card
4. If neither of the above apply, visit the ROOL store for some retail therapy

In the case of (2), to check/clear the bit manually use

SYS"OS_Byte",161,&C3 TO,,value%
PRINT ~value%
SYS"OS_Byte",162,&C3,value% ANDNOT4
*SAVECMOS filename_you_choose

Is the memory split likely to be sorted soon?

AFAIK it’s sorted already, you just need to select an appropriate start.elf. But I haven’t had time to check it myself.

The arm224_start.elf seems to work OK. I’d assume arm192_start.elf works too.

arm240_start.elf has a few issues – it looks like the VideoCore doesn’t have enough memory for both 1080p @ 32bpp and sound, so you’ll either have to stop the VCHIQ softload from *RMReiniting BCMSound, or make sure your boot sequence switches to a lower res screen mode before the VCHIQ softload/sound reinit (and make sure you don’t switch back to 1080p @ 32bp afterwards). I’m not sure how much we can do about this from RISC OS; I suspect the GPU returns some error codes which were not paying attention to, so hopefully we can at least stop the OS from crashing if the VideoCore doesn’t have enough memory for a specific screen mode/feature.

Has anyone tried the new firmware with a HDMI→DVI setup?
Was wondering if it is the connector or not, or I need a new monitor with HDMI for later firmware versions (if so I’ll get a 16:10 one, but they ain’t so cheap)
Mine doesn’t work very well, as I said before it get’s 1600×1200 reported by the monitor and ends up scaled in a small section of the screen!
I tried the firmware on my TV, direct HDMI and it worked fine, sound worked too which I was happy about.
So at the moment I’m stuck on the firmware that came with the alpha disc, any fiddling with the hdmi settings makes things worse not better as well :-(

The latest firmware seems a bit flaky to me – often hanging on reset or power on, before the RISC OS ROM gets started. The previous firmware I was using from a week or two ago seems fine.

So far I’ve only used the new firmware with HDMI→HDMI, but the previous one (which I’ve now gone back to due to the reset issues) worked OK with both HDMI→HDMI and HDMI→DVI.

For me it’s been flaky for the start with reset/poweron/poweroff.
I’m fairly sure this is a problem with the USB driver. Possibly not with it directly though.
I have a filecore formated USB drive, when I shutdown I get the hourglass and I have to press Esc to get it to pass that, then it shutsdown [that’s always]
It sometimes throws an absolute wobbly on shutdown, exceptions etc. but that’s happened twice so far, so not much – could have been a number of things.
I’ve ordered a new 320Gb USB disc, so I’m hoping that will perform better than my USB stick.
Hanging on reset/power on seems to be when you update or downgrade the firmware for me.
It looks like I’m going to have to stick debian on a stick and see if the new firmware issue with HDMI→DVI is a firmware issue or a RISC OS issue.
If it’s a firmware issue then it’s likely to either be a broken firmware update, in which case it will be fixed, or a problem with my HDMI→DVI cable that didn’t show before – in which case it should show with other people, and there maybe a work around.
Getting a new monitor seems a good idea, but at the moment I’ll be spending around 500+ on getting my Pi working as I want.
I am very picky though ;-) and a nice monitor is always a bonus.

No problems using a HDMI→DVI even with the latest ROM (9-SEP)
(I have this cable anyway http://www.amazon.co.uk/gp/product/B000GDI6FC)

I’m not talking about the ROM, that works fine.
It’s the new start/elf i.e. the firmware.

Anyway Cheers, I’ve ordered the cable. For the cost of a couple of quid it’s worth trying.

@ sprow

In the case of (2), to check/clear the bit manually use

SYS"OS_Byte",161,&C3 TO,,value%
PRINT ~value%
SYS"OS_Byte",162,&C3,value% ANDNOT4
*SAVECMOS filename_you_choose

I have been having the same problem with unsaved settings for some while and regarded it as a minor item – however testing the code above and copying the cmos file to the SD card root directory still has the beagle re-writing the Monitor file at boot time.
I have edited the Monitor file and now set it as write protected to eliminate the problem.

I note that making changes via the configure plugins appears to have stopped producing an update to the cmos file in recent ROM releases – I think it may have been the ROM release that had the change to the default language setting where this first showed.

@Malcolm , well, I just booted the RPi with the new start.elf without any display issues

@Chris xc8
What date on the ROM?

I’m currently on a BBxM with the Sep02 labelled ROM with matching Boot.

I suspect that if people have an issue it would be very helpful if they state the date of the Boot install and the ROM

@Chris xc8
Great, at least I’m narrowing it down.
Either monitor or cable, I’m suspecting it’s the monitor, or maybe hoping for an excuse to get a reasonable ratio screen, the 16:9 is horrible.
If you could post your config.txt that would be great!
I’m sure that’s not the problem, I’ve been through various combinations – all attempts make it worse, but it’s worth a shot.

here is my config.txt

#hdmi_group=2
#hdmi_mode=39
arm_freq=800
sdtv_mode=2
disable_overscan=1
framebuffer_ignore_alpha=1
framebuffer_align=0×100000
init_emmc_clock=100000000
kernel=riscos.img

riscos.img → 2012-09-09
start.elf → what’s on the github (ie. the more recent)

my monitor is an AOC E950SWDA (D-SUB and DVI inputs only)

hm.. it seems I have now that USB bug (keyboard stuck sometimes when I type),

I’m seeing something that looks like that keyboard stuck USB issue having just updated. However, I also got a new wireless mouse and the problem seems to go away when I unplug the mouse from the hub and gradually comes back when I plug it back in. I was ready to blame the mouse…

arm240_start.elf has a few issues – it looks like the VideoCore doesn’t have enough memory for both 1080p @ 32bpp and sound, so you’ll either have to stop the VCHIQ softload from *RMReiniting BCMSound, or make sure your boot sequence switches to a lower res screen mode before the VCHIQ softload/sound reinit (and make sure you don’t switch back to 1080p @ 32bp afterwards). I’m not sure how much we can do about this from RISC OS; I suspect the GPU returns some error codes which were not paying attention to, so hopefully we can at least stop the OS from crashing if the VideoCore doesn’t have enough memory for a specific screen mode/feature.

So we should have the choice of 224MB RAM, without compromise or 240MB RAM with reduced screen modes? Presumably 1080p in 256 colours.
(Would we need more taken if we had GPU video decoding?)

When RISC OS can handle them correctly, would it be sensible to have a configure plug-in that switches between them?

Theo:
Would it be possible for the 224 version to be packaged?

the problem seems to go away when I unplug the mouse from the hub and gradually comes back when I plug it back in.

The consistent feature of this bug is that it’s inconsistent. I see it sometimes; there are also long periods when it doesn’t seem to happen. I’ve not yet noticed any pattern in when/why it happens.

Which means it could be a nightmare to find the source.

@Sprow

2.If you’re loading your CMOS settings from disc (eg. written with SDCreate, or otherwise, to the micro SD card) make sure you didn’t create/save the ‘cmos’ file with the delete-power-on flag set!

Thanks for the tip. The delete-power-on flag set was set each time the machine booted even though the CMOS file on the SD card did not have it set. I removed all CMOS and BB_CMOS files from the boot sequence and still the flag was set after boot.
I wrote a new CMOS file (with the flag not set) to the SD card and updated to the latest ROM and now I have finally got the BBxM behaving itself.
I’m not entirely sure which step made it work, but it is working. However I still can’t understand why the 1st byte of the Monitor file is changed to a ‘|’ on a delete-power on.

Thanks for your help,

Mike.

I still can’t understand why the 1st byte of the Monitor file is changed to a ‘|’ on a delete-power on.

This is the work of the ‘ClrMonitor’ utility, which (IIRC) is hidden in !Boot.Resources.Configure. I think the intention is to make sure the desktop starts in a safe mode, much like it would have done on pre-OS 3.5 machines after a CMOS reset.