RISC OS on IGEPv2

havent been able to reproduce WPB’s problem now. Perhaps my minimal cooling is helping?

Before when i exited the desktop the display became corrupted. Now it works perfect.

Have you tried checking the serial output to see if any FIFO underflow errors are being reported? (IIRC it’ll just show up as a message like “OMAPVideo: dispc_irq: Cause XXXXXXXX”)

Nothing. When the display glitches, there’s no extra output on the serial. In fact, after the initial setup I haven’t noticed any debug output (with the exception of mode changes of course).

can you please provide a copy of the *videoregs output

*videoregs
f9e50010: 00000001 dss.sysconfig
f9e50014: 00000001 dss.sysstatus
f9e50018: 00000000 dss.irqstatus
f9e50040: 00000001 dss.control
f9e50044: 00000000 dss.sdi_control
f9e50048: 00000000 dss.pll_control
f9e5005c: 00000082 dss.sdi_status
f9e50410: 00000001 dispc.sysconfig
f9e50414: 00000001 dispc.sysstatus
f9e50418: 000021ad dispc.irqstatus
f9e5041c: 00005642 dispc.irqenable
f9e50440: 00018309 dispc.control
f9e50444: 0000be00 dispc.config
f9e5044c: 00000000 dispc.default_color[0]
f9e50450: 00000000 dispc.default_color[1]
f9e50454: 00000001 dispc.trans_color[0]
f9e50458: 00000001 dispc.trans_color[1]
f9e5045c: 00000069 dispc.line_status
f9e50460: 00000000 dispc.line_number
f9e50464: 0230237f dispc.timing_h
f9e50468: 01d00305 dispc.timing_v
f9e5046c: 00000000 dispc.pol_freq
f9e50470: 00010002 dispc.divisor
f9e50474: 00000000 dispc.global_alpha
f9e50478: 00000000 dispc.size_dig
f9e5047c: 02ff03ff dispc.size_lcd
f9e50480: 80000000 dispc.gfx.ba[0]
f9e50484: 80000000 dispc.gfx.ba[1]
f9e50488: 00000000 dispc.gfx.position
f9e5048c: 02ff03ff dispc.gfx.size
f9e504a0: 00004087 dispc.gfx.attributes
f9e504a4: 03ff03c0 dispc.gfx.fifo_threshold
f9e504a8: 00000400 dispc.gfx.fifo_size_status
f9e504ac: 00000001 dispc.gfx.row_inc
f9e504b0: 00000001 dispc.gfx.pixel_inc
f9e504b4: 00000000 dispc.gfx.window_skip
f9e504b8: 82400020 dispc.gfx.table_ba
f9e504bc: 00000000 dispc.vid1.ba[0]
f9e504c0: 00000000 dispc.vid1.ba[1]
f9e504c4: 00000000 dispc.vid1.position
f9e504c8: 00000000 dispc.vid1.size
f9e504cc: 00000000 dispc.vid1.attributes
f9e504d0: 03ff03c0 dispc.vid1.fifo_threshold
f9e504d4: 00000400 dispc.vid1.fifo_size_status
f9e504d8: 00000001 dispc.vid1.row_inc
f9e504dc: 00000001 dispc.vid1.pixel_inc
f9e504e0: 00000000 dispc.vid1.fir
f9e504e4: 00000000 dispc.vid1.picture_size
f9e5054c: 82400420 dispc.vid2.ba[0]
f9e50550: 82400420 dispc.vid2.ba[1]
f9e50554: 01ba0223 dispc.vid2.position
f9e50558: 001f001f dispc.vid2.size
f9e5055c: 00008011 dispc.vid2.attributes
f9e50560: 03ff03c0 dispc.vid2.fifo_threshold
f9e50564: 00000400 dispc.vid2.fifo_size_status
f9e50568: 00000001 dispc.vid2.row_inc
f9e5056c: 00000001 dispc.vid2.pixel_inc
f9e50570: 00000000 dispc.vid2.fir
f9e50574: 001f001f dispc.vid2.picture_size
f9e505d4: 00000000 dispc.data_cycle[0]
f9e505d8: 00000000 dispc.data_cycle[1]
f9e505dc: 00000000 dispc.data_cycle[2]
f9e50620: 00000100 dispc.cpr_coef_r
f9e50624: 00080000 dispc.cpr_coef_g
f9e50628: 40000000 dispc.cpr_coef_b
f9e5062c: 00000100 dispc.gfx_preload
f9e50630: 00000100 dispc.vid_preload[0]
f9e50634: 00000100 dispc.vid_preload[1]
f9e4ff00: 00000000 dsi_pll.control
f9e4ff04: 00000282 dsi_pll.status
f9e4ff08: 00000000 dsi_pll.go
f9e4ff0c: 0080230d dsi_pll.configuration1
f9e4ff10: 0001210e dsi_pll.configuration2
Ban state: 00000000

Also – are you using the USB host port or the OTG port?

USB host.

Perhaps Stephen’s right and this is down to his heatsink…

I managed to start getting screen problems too. Shame.

OK, I guess I’ll have to take another look.

If we’re left completely stumped then we could always try porting the Linux driver to RISC OS. Obviously the GPL licensing would prevent us from being able to link it into a ROM image, but it would allow us to rule out any differences in the drivers as being the culprit.

Jeffrey, if there’s anything else specific I can do to help debug this, please let me know.

Did your investigations so far touch on the DMA setup? I wonder if there are any significant Linux<>RISC OS differences there…

I think before you do much more work with the driver we should try working the IGEPv2 very hard under linux for an hour or two to see if the problem can be reproduced there.

Sounds good to me!

I think before you do much more work with the driver we should try working the IGEPv2 very hard under linux for an hour or two to see if the problem can be reproduced there.

Agreed. Though I’d have thought it would have been reported already on the ISEE forums. You never know, though! It’d be interesting to see if the new hardware revision suffers from this.

I have used an infrared thermometer (TI 880) to measure the temperature of the omap chip under RISCOS and under Ubuntu 0.04 and after one hour of operation they both were 48 C. The processor was only displaying the desktop.

A more useful test would be to measure the temperature after the machine has been playing movies for an hour while recompiling a kernel.

Under RISC OS I exit the desktop and started a simple BASIC program that prints lines all the time. I hoped to disable the ‘sleep mode’ by exiting the desktop and use the processor 100%. The temperature also became 48 C.

It might be helpful if The ARM Club’s CPUload works, or can be recompiled to do so. Presumably there’s a similar linux app too.

Does TaskUsage work? No-one has let me know of any problems, but I would try and fix any that are reported. Available from http://www.avisoft.f9.co.uk

If all you’re interested in is stopping the CPU from going to sleep you can just RMKill the Portable module.

Does TaskUsage work?

If you’d care to look in the Software Compatibility List, you’ll see it’s in there, listed as OK without reservations. (I put it there after I tried it.)

However, if I understand things correctly, it’s only showing which application tasks are using CPU time. I didn’t think that RISC OS ever idled the CPU?

However, if I understand things correctly, it’s only showing which application tasks are using CPU time. I didn’t think that RISC OS ever idled the CPU?

Depends on whether you’re using a version of RISC OS that comes with the Portable module. Since power consumption/heat of ARM chips has never been a major issue, I think the only machines that have used a version of the module are the A4, the (cancelled) Stork, and now also the OMAP3 machines. Luckily the code that calls Portable_Idle was never removed from the OS, so even machines that don’t have the module could be made to idle the CPU (assuming the CPU supports it). This also includes emulators, where fake versions of the module can be used to allow the CPU to yield its threads when it knows that the emulated CPU is idle.

TaskUsage…

I wasn’t aware of that, although it’s obvious enough from its name so I should’ve seen it in the compatability list

Under RISC OS I exit the desktop and started a simple BASIC program that prints lines all the time. I hoped to disable the ‘sleep mode’ by exiting the desktop and use the processor 100%. The temperature also became 48 C.

The trouble with that is you are only working one chip on the board. You need to be working the NIC, Video, CPU and audio chips to really get the IGEP warm. As i keep saying playing a video over the network is the best way to achieve this.

As i keep saying playing a video over the network is the best way to achieve this.

Problem is, I don’t have the network running yet.Even !Boot doesn’t work because it can not do something. Have to look into that.

But TaskUsage works without problems. Simple desktop : 0%. Running a BASIC program in a taskwindow gets it to 100%. The temperature stays 48 C.

After this I killed Portable and this seems to work. After two hours the temperature rose to 57 C so the Portable module is working.

After two hours the temperature rose to 57 C so the Portable module is working.

And presumably the temperature starts to drop when the portable module is restarted again?

I’ve uploaded a simple app here that displays the current CPU temperature on the iconbar. It’s shamefully lacking in any kind of UI (you have to quit it from the Task Manager!) and it’s implementation of the temperature-reading procedure is not particularly clean to say the least, but it does (for me at least) work. I’d be interested in other people’s temperature readings, and whether they notice any correlation between temperature and the screen dying on the IGEP. For me, anything below 40 Celius is usually okay, but once the temperature goes above that, the screen usually starts blanking. Thomas, I wonder what your fan-cooled IGEP board reports? I’d also be interested to know what the Beagleboard reports.

Please be warned that this is a minimally tested beta release, so it could lock up your machine if I’ve done something silly! But if you’re feeling brave, please give it a go!

This should prove useful – thanks. On my revC BB it wavers around 60-70 (with a very idle CPU). The BB is housed in an unvented acrylic case. I’ve not yet checked how long after a cold start it takes to reach this temp.

That’s a bit hotter than I was expecting. Do you live in a sauna? ;)

In a fairly well ventilated LEGO case, my 500MHz beagleboard idles at around 48.4/49.8 degrees. Killing the Portable module brought it up to 59.5 degrees, and then playing a video over the network caused it to eventually reach to 66.4 degrees.

Whenever I’ve had a spare few minutes I’ve been trying to track down all the relevant documentation for controlling the CPU frequency. So maybe in a week or two I’ll be able to do some more tests at 600MHz (or maybe higher if it remains stable at >600MHz)

Not exactly, and the heating’s not on either. But on reflection my setup wasn’t ideal – although perhaps not too atypical either (tucked away with no air able to circulate.) I presume the revC4 is running at 600MHz, although perhaps I can get it to 720MHz if I research it properly. The temp was consistently 70 while writing data to an SD card. (I hope it’ll be OK all day today, as I now decided I really ought to soak test the card!)

If it’s any interest, I could possibly try in a 30/40C-ish climate in July, provided I can find access to a DVI monitor.

Edit: The OMAP3530 data sheet seems to indicate it’ll be OK up to 90C.

The C4’s should all run at 720MHz by default. Although I’m not sure how much difference the clock speed would make if the CPU is spending most of its time idle.

Also the chips have automatic cutoffs for if the internal temperature gets dangerously high (somewhere around 120 degrees IIRC), so unless you put it in an oven it shouldn’t be possible to damage it through overheating :)

I’m very tempted to buy a BB XM when they come out; if I get one it will be interesting to see what temperature it runs at, and whether it shows any display issues similar to the IGEP.