RISC OS on IGEPv2

I’m very tempted to buy a BB XM when they come out.

The minimum order for boards is 250 pieces… The current code should run on the -xM board with minor modification. Of course to take advantage of the new features will require additional work. If [...], getting you an early -xM board should not be an issue.

The minimum order for boards is 250 pieces…

The same restriction applies to the current BeagleBoard, surely? TI/beagleboard.org don’t sell them straight to individuals; they just sell them in batches to retailers like DigiKey & Special Computing.

getting you an early -xM board should not be an issue.

I think I’d rather wait until they’re officially available. With the integrated hub & NIC the XM is far more suitable for use as a “proper” computer than my current BB. So I don’t really want to end up with a potentially faulty one from a prototype revision!

The same restriction applies to the current BeagleBoard, surely? ...sell them in batches to retailers…

That’s my understanding too.

I think I’d rather wait until they’re officially available… potentially faulty one from a prototype…

Sounds quite wise.

WPB: Nice little program! With cooling my IGEP runs at 24.4°C when idle. I got it up to 31.8°C when running as many programs as I could before crashing it. No network or video yet. (sorry stephen I haven’t had the time to test your nic driver)

I have a little video problem that I don’t know if it is a bug or my incompetence!Bear with me.

When I boot my igep and just type desktop, i can play all sorts of games requiring low screenmodes. When I boot to !Boot. I always get “Input not supported” . Even if I have the screen in lowly 640×480.I tried to make my own MDF’s for the screen but I never got a lowres to work. How come I can get these old games to run without !boot but not with it. I’m using the latest built and if you want some games to test the following works on the omap from the acornarcade.com revolver, big bang(after disabling the z15 module) and cool santa

When I boot my igep and just type desktop, i can play all sorts of games requiring low screenmodes. When I boot to !Boot. I always get “Input not supported”

Similar problems on the Beagle. I don’t get the “Input not supported” error but the display is more as I’d expect when bypassing !Boot.

• Best results using *desktop (although some irregularities in display)
• Standard MDFs = worst case
• BeagleBoard modes MDF = promising although screen split in two vertically for Revolver (alternate scanlines in either half?)

Jeffrey,

Were you able to set the CPU speed? I was thinking it might be possible to have a CPUspeed module for the OMAP class chips and give people a commandline app to let them set the speed themselves? i’d happily downclock mine to 600Mhz if it would be more stable and im sure others would do the same. My main interest in the IGEP has been the extra integrated hardware and ram rather than the pure straightline speed.

Ok…

12 hour soak tests playing movies, compiling and generally working the igep very hard in Linux. The igep is very hot but there are no screen issues. it may be that Linux sleeps just enough to make the difference (but i doubt it). I’ll continue testing.

Were you able to set the CPU speed? I was thinking it might be possible to have a CPUspeed module for the OMAP class chips and give people a commandline app to let them set the speed themselves?

Not yet, no. I haven’t found enough time to track down the reamining bits of documentation. Once it’s working I’ll work out some kind of HAL interface for it so it can be controlled from RISC OS.

12 hour soak tests playing movies, compiling and generally working the igep very hard in Linux. The igep is very hot but there are no screen issues.

Bah :(

If anyone has an oscilloscope or multimeter then it might be worth trying to work out what exactly happens to the video signal when it dies, or whether any key components have slightly different voltages supplied to them when running under RISC OS instead of Linux. If we can find something different in the signals then it might help us to track down where the problem is.

I dont have any equipment sensitive enough. I’ll ask around and see if anyone has a scope.

I think im going to try one or two more work-hard tests before i give up completely but i thought i’d keep you up to date on what i’ve been doing.

I’ve been tracking down the remaining documentation I needed to control the CPU frequency and I’ve found a few interesting things. I still need to check everything against the actual u-boot and Linux sources, but it looks like u-boot alone might not do sufficient setup in order to guarantee correct operation of the SoC for a 720MHz CPU clock.

If you look at the docs you’ll find that the OMAP has several “operating performance points”, OPP1-OPP6. For each OPP there’s a pair of maximum clock frequencies (for the ARM core and the DSP), along with the VDD1 voltage level required for the CPU cores to correctly operate at those voltages. OPP3, which TI refer to as “nominal”, appears to be the default setting, allowing for a max ARM core frequency of 500MHz, and requiring a VDD1 of 1.2V. OPP6 is the “overdrive” OPP used by the 720MHz OMAPs, requiring a VDD1 of 1.35V. Now the crucial bit is how VDD1 is controlled – it can either be adjusted automatically by the SmartReflex hardware, or it can be controlled manually (through a plethora of different methods, which is one of the reasons why the documentation is so confusing). SmartReflex appears to be off on boot, so u-boot adjusts VDD1 manually by using I2C to write to the corresponding registers in the TWL/TPS. And one of the interesting things is that it looks like the default VDD1 voltage is 1.3V, 0.1V above the nominal voltage needed for OPP3, whereas the 720MHz patch sets the voltage to 1.4V – only 0.05V above nominal. So with SmartReflex off, it’s conceivable that as the components heat up, and as the VDD1 load changes, a voltage somewhere could fluctuate and lead to disruption to the supply of one of the components (i.e. the display subsystem, or maybe the DVI framer). (Note that VDD1 doesn’t supply the display subsystem with power, VDD2 does. But both VDD1 & VDD2 can be controlled by SmartReflex, so if SmartReflex is off then it’s still conceivable that VDD2 could fluctuate in some unacceptable manner depending on the load on one or both)

How this relates to Linux’s stability is that it looks like the Linux kernel supplied with the IGEP is based around the OMAP-PM branch, which contains a SmartReflex driver. So, long story short, it looks like I’ll need to wade through even more documentation until I can work out what’s involved with enabling SmartReflex (a quick google reveals some discussions about SmartReflex-related instabilities on the N900, so it isn’t something I want to rush into enabling without doing plenty of research beforehand!). And in the short-term I’ll knock up some code to exert manual control over VDD1 (and the CPU frequency), so IGEP owners can try downclocking to OPP3/500MHz.

If anyone has an oscilloscope or multimeter then it might be worth trying to work out what exactly happens to the video signal when it dies

If you mean the DVI/HDMI signal, you’ll need quite a high spec oscilloscope. The DVI bit rate is ten times the pixel rate, so, if you have an 86 MHz pixel clock, each DVI stream will be at 860 Mb/s. Maximum frequency 430 MHz. I still have access to a ‘scope like that, but of course it belongs to the company I work for (I couldn’t afford one on a personal basis).

I can’t imagine that a multimeter would be much use on the DVI/HDMI video signal either – or did you mean something else?

A multimeter or an ordinary ‘scope would show if the DVI signal flat lines, of course.

By the sounds of it the smart reflex driver is the way to go. And might even let you clock up the Beagle to higher speeds safely. Embedding this in the HAL would be ideal but a 500MHz patch for now would be ace.

The work we did on getting the video driver more stable has been worth it in my opinion though as we have made things more stable for sure.

And one of the interesting things is that it looks like the default VDD1 voltage is 1.3V, 0.1V above the nominal voltage needed for OPP3

Checking my beagleboard last night, it looks like VDD1 was actually programmed for 1.2V. I’m not sure how much that affects my earlier theory (maybe the TWL defaults to 1.2 and the TPS to 1.3?), but I’ll try and get some code ready tonight for adjusting the VDD1 levels/CPU frequency.

If you mean the DVI/HDMI signal, you’ll need quite a high spec oscilloscope.

Good point! Maybe that request wasn’t as easy as I thought.

I can’t imagine that a multimeter would be much use on the DVI/HDMI video signal either – or did you mean something else?

If you’ve got a steady enough hand you should be able to measure the supply voltage of the DVI framer, and the VDD1 & VDD2 supplies being fed to the OMAP by the TPS.

To be honest though the error on most normal multimeters is bigger than the difference you are looking for. ~0.2 – 0.3 of a volt typically unless calibrated.

To be honest though the error on most normal multimeters is bigger than the difference you are looking for. ~0.2 – 0.3 of a volt typically unless calibrated.

The situation should be much better than you describe; a 3.5 digit digital multimeter on the 2 V range has a resolution of 1 millivolt, and the accuracy should be within +/- 1% of reading.

Here we go.

http://www.phlamethrower.co.uk/misc2/opp.bas (it’s a BASIC file)

It should allow you to select any CPU frequency between 125MHz and 720MHz, adjusting VDD1 to match the OPPs defined in the OMAP data sheet. Although it doesn’t do as much sanity/error checking as it probably should (e.g. it doesn’t check if the DSP is running), it will report any strange things it sees and fail gracefully in a couple of cases. It also doesn’t check if it’s a 720MHz OMAP or not, so people with 600MHz OMAPs can try clocking at 720MHz if they want (it runs at the same voltage as 600MHz, so won’t damage the CPU, but may lead to instability since the CPU wasn’t certified for that speed). I’m currently running my beagleboard at 720MHz and nothing strange has happened so far (Although I’m obviously hoping I’ll start seeing some IGEP-style display issues!) Although since it programs the correct voltage of 1.35V instead of the 1.4V that u-boot programs, maybe that will be enough to make the display problems go away.

My RevB6 Beagleboard seems to be happy with 720MHz! Though the processor is now definitely warmer than my finger .. didn’t we have a temperature sensing program… i’ll see… hmm i can’t find it… but jeffrey’s current.bin claims 340mA of consumption. can this be correct? The tool was intended for the RevC2 Board…

WPB’s temperature sensor program is on his website here (usage notes here). Idling in the desktop at 720MHz, my beagleboard seemed to reach a temperature of 63-65 degrees – which is pretty much the same temperature as when it was fully stressed at 500MHz. No signs of display issues, but I wasn’t able to stress test it much further since the USB EHCI died soon after I started playing a video! I’ll probably have another go tomorrow, using the OTG port. According to the datasheet the maximum operating junction temperature for a standard OMAP is 90 degrees, so it looks like I should be able to run it at full load at 720MHz without exceeding the temperature specification.

Good work guys,

I’ll try this beasty out later tonight. Wont be in until 8pm at the earliest but hopefully i’ll have time to do one or two tests.

Ok the 500Mhz patch helps a bit but here is some interesting results.

I decided i really wanted to break things in linux. So i…

1. filled a hot water bottle up with boiling hot water. 2. Sat the IGEP on top of this and ran Linux for a bit. 3. It all seemed stable despite the whole board being too hot to touch so i worked it hard. 4. No issues at all. Perfectly stable.

So i removed the hot water bottle and rebooted it into RISCOS. I heard the start up beep but no screen activity came up so i went off and made a cup of tea and started replying to emails etc on the laptop…. IGEP still on with a blank screen.

After 3-4 mins the screen started flickering back into life as the igep cooled. Becoming more and more stable. while this was going on I ran the opp program and jammed the machine into 500MHz mode… things improved very fast then.

My conclusions from this are we shouldnt worry too much about the CPU speed as Linux is managing to cope with the temperature being high somehow. Possibly an X driver configuration? I hadnt traced the pll reg calls as far as X11 so im not sure what goes on there.

I do not recommend doing what i did with the hot water bottle unless you are ready to pay up for a new board. I also have heat sinks.

Four hours of streaming video over the network at 720MHz with the Portable module killed and nothing to report. Peak temperature seemed to be around 77 degrees. I guess I’d better start reading up on SmartReflex!

It should allow you to select any CPU frequency between 125MHz and 720MHz, adjusting VDD1 to match the OPPs defined in the OMAP data sheet.

• 720MHz is default for BB revC4
• At 600MHz or higher OMAP35x is considered to be ‘overdrive’ and it does not have the same life expectancy – Higher than 600MHz is out of spec and no guarantee it will work at all (This statement has remained since the 17:30, 14 July 2008 doc revision )

Jeffrey,

I’m going to try disabling smartreflex in a kernel build and see if that reproduces the problem. From what i can gather though from further tests the IGEPv2 screen issues are purely thermal related. The linux smartreflex driver doesnt look majorly complex just a fair bit too it. Perhaps it would be possible to write it up as a basic program first off?

Perhaps it would be possible to write it up as a basic program first off?

Possibly, yes. I’ll start having a look at all the docs today and see how far I get.

Of course, there is the slight problem that the SmartReflex documentation is only available under NDA (Plus other ancilliary problems like the OMAP3 chips on the Beagle apparently don’t have their eFuses programmed with the SmartReflex configuration settings).

I’ve contacted TI to see about the NDA; I guess we’ll just have to wait and see what their terms are for handing out the information.