Software testing help wanted for Raspberry Pi

Chris xc8: Thanks again, at least that confirms it’s not the config.txt that’s at fault.
I have a samsung P2370.
HDMI→DVI cable has been dispatched…
I got some heat syncs too, not sure if there’s a point – but they looked kind of cool ;-)

I read somewhere (RPi forum maybe..) that some HDMI→DVI cables are problematic … anyway heat sinks? seems you are going for serious o/clocking there! ;-) mine runs @ 800 Mhz into a “modmyPi” case, well its a bit “warm” but I don’t worry so much…

I came across something mentioning some cables are duff, but it’s strange how it worked fine on earlier firmware.
I got the clear case, and the green heat syncs would look nice in the case.
Case is warm, so i’m not 100% happy with the case – was thinking of drilling some holes in a raspberry shape, but not sure about drilling it in case I crack it.
I have a habit of hammering hardware, don’t want to overclock it.

On another note, I’m trying to get hold of memphis (dynamic ram disc) can’t seem to get it anywhere and all the links seem dead….

Memphis 3.02, fresh from my RPCEmu

Chris ‘xc8’: Looks like the problem is either firmware or my monitor, new cable didn’t make any difference :-(

Paul: Thanks for Memphis, great!

oh Malcolm.. sorry to hear this!

You may put ‘manually’ the monitor modes on your config.txt (guide here: http://elinux.org/RPi_config.txt), I know that with the recent riscos.img is not necessary to do this… what is the model of your monitor?
also, did you try the composite out, just to make sure the RISC OS boots ok

Chris xc8: I’ve tried the manual method, strangely that makes things way worse. It boots fine on my TV with a straight HDMI, and the issue is that the Pi is not picking up the right monitor and forcing **** down it by the looks of it. See my previous posts.
The latest firmware I can use is Aug 10th, after that it is knackered.
But at least I’ve now got 192MB ram, so a little more ram.
My monitor is in previous post: samsung P2370

as I see the specs for your monitor:

Horizontal 30 ~ 81 kHz
Vertical 56 ~ 60 Hz

mine is :

Horizontal 30 kHz – 60 kHz
Vertical 50 Hz – 76 Hz

Chris xc8: Could be that it’s RISC OS at fault then?
If it’s supposed to auto-detect it, then it isn’t!
RISC OS is showing 72Hz on the auto setting.
I’ve set my monitor to a 60Hz, but it doesn’t seem to make any difference to the result, if I try and force the resolution in boot it should be (16) then I get a crappy resolution. From what I can see Risc OS isn’t looking at the screen resolution at all that is set on boot.

If it is a RISC OS fault, which I really don’t know. I’m sure someone else will notice it if they have a lower spec’ed monitor.
I’m happy to use older firmware for the moment and get a new monitor in a month or so.
I think it’s time to give up on this, it’s not worth the time and aggrevation banging my head against the wall.

hm…

I have an idea :

power-on the RPI, then (as you don’t have any signal) wait 5-6sec then press 5-6 times the ESC (to bypass the DHCP procedure and the error message after it), now you supposed to be at the Desktop…

then (blind type) F12 → wimpmmode 28 → Enter → Enter
this will change the resolution to 640×480 , so IMHO if you can see the desktop now that means that the RPi starts with a resolution settings that is not compatible with your monitor, its just an idea ….

Chris xc8: I get a signal no problem, the issue is that the Pi output’s it at the wrong resolution.
If I force the resolution to anything, it comes out at 640×480 on the monitor.
If I leave it as automatic, it comes out at 1600×1200 which causes it to be letterboxed on my screen and with unreadable fonts.

Another problem is that sftp and scp don’t work!

sftp gives “protocol not supported” and scp doesn’t seem to do anything… :-(
ssh works ok though

Excuse the plug! Theo will be at ROUGOL on Monday 17th September to talk about his work on software packaging and distribution for the Raspberry Pi.

http://www.rougol.jellybaby.net/

Chris xc8: I got my monitor working :-D
I ran a tool to extract the edid info, it seems my monitor doesn’t support 1080p according to the edid info, and the maximum mode is 1600×1200 – which it doesn’t actually support properly anyway!
I assumed a samsung monitor would be of reasonable quality, well you live and learn!

So using:
hdmi_ignore_edid=0xa5000080
hdmi_group=2
hdmi_mode=82

in config.txt solves my problem, it looks like the hdmi_group=1 only seem to work with edid info?

As regards overclocking, I’m waiting for the UK version. From what I can see that will have better RAM and allow better overclocking :-D
900MHz isn’t bad though

As regards overclocking, I’m waiting for the UK version. From what I can see that will have better RAM and allow better overclocking :-D

Interesting, were did you get that information?

Chris Evans: it was on my look for a solution to my monitor problem.

Maybe it’s not the UK ones, as they aren’t avaliable yet
See:

http://www.raspberrypi.org/phpBB3/viewtopic.php?f=29&t=6201&p=159188&hilit=hynix

Malcolm: that’s fantastic! I used the hdmi_group=2 too (before the new ROM), my monitor is just 720p…
as for o/clocking….pushing the limits of the RPi’s CPU won’t give you too much (has limited RAM anyway).
better look for a BB or Panda (my PandaES gives 2.1m Drhystone (using the 900Mhz MLO…can go even to 1.2/1.5Ghz I just don’t want to blow up the thing..)

Chris xc8: I’m hoping that there will be a proper A9 version for RISC OS sooner or later, it’s working fine for me at 900Mhz.
All the apps I need (netsurf, ovation pro, messenger pro, ROOL Compiler and Easiwriter and digital CD) work fine with 192MB memory.
If I really need ram I have a 12GB quad core i7 with a nice PCI SSD for real grunt work ;-)

Malcolm: a bit OOT, I assume you changed the voltages on your RPi, as in my case (Samsung RAM) when I just change the CPU freq to 900Mhz is not stable and freezes after around 5min..

Chris: No I haven’t altered the voltages, I didn’t want to mess with voltages really. If I wanted to get to 1GHz I figure I’d need to alter them though.
Not had any stability issues at all at 900MHz, guess I’m just lucky there.
Altering the GPU speed looks like it needs overvoltage though.

A9 1.5 GHz would be lovely though, that would be quick.

http://armdevices.net/2012/07/12/129-exynos4412-quad-core-arm-cortex-a9-development-board/

It’s quad core, which is a bit of a waste at the moment for RISC OS, but for $129 for a 1.4GHz Arm A9…with a Mali based GPU…

is there any way of seeing the ram vendor in riscos?

is there any way of seeing the ram vendor in riscos?

AFAIK no, but its the big IC in the middle of the RPi, labelled as Samsung or Hynix

is there any way of seeing the ram vendor in riscos?

Why do you want to know?

What progress bar?

Now I have updated the boot structure I see it – looks good:

I have had to edit Boot.Choices.Boot.PreDesk.Configure.Monitor manually to remember my (RISC OS) screen resolution:

This still seems to be necessary…

Chris, thanks for posting the animated GIF – I’ve not seen this before. It looks fantastic. (That’s Steve’s work, I believe? What a great job you’re all doing. Truly amazing. Thanks so much.)

I have had to edit Boot.Choices.Boot.PreDesk.Configure.Monitor manually to remember my (RISC OS) screen resolution:

This still seems to be necessary…

Is this all the time, or only after ROM updates? Since the CMOS is held in the ROM, any fresh ROM will be considered a CMOS reset, causing the ClrMonitor utility to comment out the loadmodefile command (but for some reason it doesn’t bother to comment out the wimpmode line as well!). As long as you’re using a split FAT+Filecore partitioned SD card with the ROM in the usual place, SDCMOS should kick in and update the CMOS within the ROM so that a CMOS reset won’t be triggered next time you boot.