RISC OS on IGEPv2

Just wanted to report that I have successfully booted to a supervisor prompt on my IGEPv2 board. I’m using the ROM image with sound support that Jeffrey posted a day or two ago, not the most recent auto-built ROM, though I don’t expect that would work any differently.

One thing to note, the default shipped firmware expects the U-Boot script to be called boot.ini, not boot.scr, so any other IGEPv2 users out there, take note!

I will try to format a USB stick and put on a !Boot sequence tomorrow and see how far I get. Can’t quite remember how to go about that – need to trawl these pages!

WPB

Just wanted to report that I have successfully booted to a supervisor prompt on my IGEPv2 board.

Glad to hear it!

I’m using the ROM image with sound support that Jeffrey posted a day or two ago, not the most recent auto-built ROM, though I don’t expect that would work any differently.

Can you try the latest autobuilt ROM when you get a chance? And also the right boot script as mentioned in this post. It would be good to get confirmation that everything works properly with the IGEP board config.

I will try to format a USB stick and put on a !Boot sequence tomorrow and see how far I get. Can’t quite remember how to go about that – need to trawl these pages!

If you’ve got an Iyonix then you should be able to format the USB stick using !SCSIForm. Then just extract the HardDisk4 zipfile from the downloads page

If you don’t have an Iyonix, there’s an ARMv7-safe unzip program here (set type to absolute). That should allow you to extract the !SCSIForm zipfile to a ramdisc and then format the USB stick. (Although there is the bug that causes a data abort when creating a ramdisc, so you’ll have to disable alignment exceptions first)

Thanks for the pointers, Jeffrey. I’ll try the latest auto-built ROM tonight, hopefully, with the updated boot script.

I don’t have an Iyonix, unfortunately. I do have a RISC PC with a Castle USB podule in it, but I’m not sure that !SCSIForm will work with that. I could give it a go.

If not, do you mean I should put the ARMv7-safe unzip program and the HardDisk4 archive on a FAT-formatted USB stick and then create a RAM disk at the supervisor prompt to extract into, and then format another USB stick from there? Will the OS be able to read from a FAT-formatted USB stick without having loaded modules from !Boot? My apologies if I’m being slow here…!

Yeah, you’ll want to put the unzip program and HardDisk4 archive on a FAT-formatted stick. Then extract HardDisk4 into a RAM disc (I’m not sure how big it is when extracted – I’d guess no bigger than 50MB), use !SCSIForm to reformat the stick (or format a second one), and copy it all out from the RAM disc.

Will the OS be able to read from a FAT-formatted USB stick without having loaded modules from !Boot?

Yes, should be able to read it without the help of !Boot. The only thing to remember is there’s still the 2GB limit on FAT formatted devices – so if you wanted to use a >2GB stick you may have to figure out a way of formatting it to a smaller size (Linux will let you do this, but I’m not sure about Windows), or you’ll have to find a <=2GB stick to extract the disc image from.

The auto-built 5.17 ROM is working fine here on my IGEPv2.

Like WPB I needed to name the boot script boot.ini for the ROM to boot.

I used SCSIForm to reformat a 512M MicroSD card to FileCore format and have plugged that in via a USB adaptor. Once at the star prompt, *SCSI then *!Boot got things going.

Something I’ve noticed is that the OMAP runs noticeably hotter when running RISC OS rather than Linux. I’ve mounted a small copper RAM heatsink I had spare from a VGA cooler on the OMAP, but even with that it gets worryingly hot.

Is RISC OS not idling the CPU? Do we need the Portable SWIs?

I haven’t done any real investigation into this yet, but I think there are two things causing the heat – the fact that we aren’t idling the CPU, and the way that the audio is set up (for some reason, it seems like one of the two available audio paths generates a lot more heat than the other).

I don’t think the heat is in danger of damaging the components (certainly not the OMAP - TI would have stress-tested them at full load for days or weeks on end). But I’ll certainly be looking at reducing the heat produced sometime soon.

Fixing the audio should be easy (assuming I’m not imagining the problem), fixing the CPU might be a bit trickier. There’s a new “wait for interrupt” instruction which will put the CPU to sleep until an IRQ/FIQ occurs – so whenever we use it, we’ve got to be careful that we are waiting on something which will generate an interrupt. For example, we don’t want to use it when we’re doing polling I/O on the serial port, because with the current code (which doesn’t use interrupts AFAIK) we could easily go to sleep for so long that the serial port FIFO overflows.

We could also add some code to switch to lower CPU frequencies, but I’m not sure how much of a power saving that generates. IIRC there were some studies by Intel a year or so ago that showed that running a CPU at full speed and completing a job quickly, and then going to sleep (i.e. via the WFI instruction), resulted in a lower net power drain than running the CPU at low speed and completing the job slowly. Of course the orignal study was on x86, so it might be a bit different on ARM - I’ll have to do some research.

I have seen that the Portable SWIs do still get called from a few places throughout the OS source, so hopefully they’ll be getting called from places that are still relevant/useful for the OMAP port.

There are also lots of other little powersaving bits in the OMAP that will automatically disable clocks for components that aren’t being used/accessed – I’ll have to check through the HAL source to make sure everything gets configured properly from a power-saving perspective.

I’ve been playing around a bit more with my IGEPv2 board. Unfortunately I’ve hit a snag in that after about 5 minutes, the video starts to flicker and eventually it dies. I’ve tried it on two different displays with the same results. It’s pretty weird. The fact that it happens after a certain amount of time like that suggests something temperature-related to me, but that’s just a guess…

David, did you experience anything like this with your board?

I’m trying to get a !Boot sequence set up on a flash drive, but I haven’t quite managed to disable alignment exceptions, make a RAM disk, unzip !SCSIForm and the HardDisk4 archive, format the drive, and copy !Boot onto it all before my screen packs in!!! Must keep practicing until I can do it fast enough!

I’ve not seen that. Do you have the 720MHz version of the board? I think I’ve had it running for more than five minutes, but the temperature problem does concern me enough to shut the board down whenever it’s not in use.

I take it that this is not the “usual” problems with mode changes?

I might have a theory as for why the display keeps going. The PLLs (which generate the different clock frequencies used by the board) require re-locking if the temperature drifts too far from when they were first enabled. Most of them are able to automatically recalibrate, but the video one seemingly can’t. At the moment I don’t think I’ve got any code to handle that, so if RISC OS causes the IGEPv2 boards to get as hot as you describe then I guess that could be what’s causing the problem.

In theory changing the screen mode should be all that’s needed to re-lock the PLL (since it would have to change to a new frequency for the new mode), so you can try that if the screen goes blank. If you’re able to connect a serial cable to the board then that would help as well – the video driver tries to be smart and only changes the PLL settings if it needs to change frequency, so you might find that some screen modes will fix it while others won’t (With the current ROM it should print out “Performing DISPC shutdown” when it’s about to re-lock the PLL).

It might also be worth trying *audio off to turn off sound. The TWL4030 power management/etc. companion IC that’s used on my beagleboard can generate a lot of heat (and currently does when sound is enabled in RISC OS), which is why they’ve newer beagleboards use the much better TPS65950. But from what I can tell the IGEPv2 already uses the TPS, so I’m not sure how much of a saving disabling audio will give you.

In fact, you could also try using the passive video ROM, which uses a different PLL for the video clock, one which can automatically re-lock (The reason we don’t use that PLL for video with RISC OS is that it’s shared by other devices, making changing the frequency trickier, and it’s rather restrictive in the range of frequencies it can generate)

I’ll take a look at the video code and see if I can add something to automatically re-lock the PLL when it goes out of sync, but I have a feeling it will have to be an ugly hack due to the limitations of the HAL video API :( It’ll certainly be something to get fixed properly when I write the new driver.

Thanks for the brainstorm, people.

Do you have the 720MHz version of the board?

Embarrassingly I’m not sure! My board has an “RB69” sticker on the underside, but I can’t find out on the ISEE site if that’s a revision number or what. I expect it is, but I don’t know what it means! Any pointers?

As for the display problem, I forgot to mention that I haven’t noticed the same thing with the supplied POKY Linux firmware. However it’s quite dull, and I haven’t had it on for that long – certainly not under load – so I doubt I’ve ever managed to get the chips hot with it!

Anyway, yesterday I discovered that finger pressure on the OMAP/memory POP is generally enough to persuade the video to come back on! I can only assume that there’s a dodgy contact on a clock pin that’s feeding the DVI framer from the OMAP or something, and that with enough heat, it fails. It certainly doesn’t seem like RISC OS is entirely to blame and it possibly isn’t to blame at all. That said, as the board heats up, it does seem to become slightly harder to get the video back. Whether that’s just because the dodgy contact gets worse, or because of the PLL drifting you mentioned, Jeffrey, is hard to say. Now I know the PLL is relocked on mode changes, I could try that to find out.

The TPS65950 gets too hot to touch after about 10 minutes of use. Is RISC OS using this for the audio at this stage or not? I know you’ve checked in audio code, Jeffrey, but seeing as the Beagle and the IGEPv2 have different chips, I was assuming the audio code wouldn’t be working on my board if it wasn’t all being handled by the OMAP itself. Or are the interfaces to the two chips the same? I’ll try a session starting with ”*audio off” and see if that makes a difference for an empirical answer!

I did manage to get a proper !Boot sequence going though now, by poking the board whenever the video went off! So I can now boot into a “real” desktop (albeit with one exception thrown!) and it looks great! Thanks, Jeffrey, for all your hard work – it’s an extraordinary achievement.

(As an aside, I am trying to hook up a serial cable, but my cheapo USB->RS232 converter just seems to give garbled characters in the terminal program (all MSB set – probably timing issues again), despite being set to the correct 115200/8N1. I’m hoping to try with a “real” serial port today if I have time. Really need that debug output!)

The TPS65950 gets too hot to touch after about 10 minutes of use. Is RISC OS using this for the audio at this stage or not?

The TWL4030 and TPS65950 are equivalent from a programmer’s perspective. In fact, it’s the TPS manual that I’ve been using to write all the relevant drivers so far, even though my Beagle has a TWL. So if sound isn’t working, let me know :)

I also tried touching my TWL last night when audio was on – it’s definitely not something I’d recommend!

I also knocked up a quick BASIC program to measure the board current, and it looked like enabling audio increases the power consumption of the board from 350mA to somewhere between 800mA and 1A. I’m not really sure how much to trust these figures (the measurement method isn’t entirely accurate), but it does suggest that the TWL is a major power hog. When I get home I’ll upload the BASIC program somewhere, but I’m not sure if it works on anything other than rev C2+ beagleboards since it requires the right circuits to be connected to the ADC pins on the TWL/TPS. In any case it would be good to get some comparison readings from someone with a TPS chip – as I understand it they’re meant to use less power/generate less heat. I may also buy a multimeter so I can do some proper testing with my board.

Over the past couple of days I’ve had a play with the audio settings a bit. It looks like it’s helped to reduce the power consumption, but in one of the setups the power readings seemed to fluctuate quite a bit so it’s hard to tell. I’ve also had a quick look at the Portable module – Portable_Idle performs the “wait for interrupt” functionality, and code still exists to call it from the most common places (idling in the wimp, waiting for keyboard input, and waiting for vsync). So if I write a 32bit safe version of the module that uses the WFI instruction then it could provide an easy win with regards to power/heat. A full reworking of the Portable module would take significantly longer, so I’m hoping I can just do a quick fix with WFI and the audio tweaks and then get onto doing the new video driver.

I’ll test out audio as soon as I get the chance. (How long does it take to plug in some headphones and press CTRL-G, you ask!)

I’d be very interested in your BASIC program to measure the current on the BB, Jeffrey. Maybe I can figure out how to modify it to work on the IGEPv2. Would you be able to upload it somewhere?

I like the look of the Portable module. Is the RO Select version of this module the same as the ROOL one, or have they forked?

I’d be very interested in your BASIC program to measure the current on the BB, Jeffrey. Maybe I can figure out how to modify it to work on the IGEPv2. Would you be able to upload it somewhere?

I’ll be able to upload it when I get home tonight. Basically it just uses the technique described by horse_dung in this thread. In particular there’s his results .PDF that contains equations to map the ADC values to the board current.

I like the look of the Portable module. Is the RO Select version of this module the same as the ROOL one, or have they forked?

I guess they must have forked it at some point; the one in ROOL’s CVS looks like it would have only worked on an A4, whereas (I guess) ROL’s one is primarily designed to interact with VirtualAcorn.

Embarrassingly I’m not sure! My board has an “RB69” sticker on the underside, but I can’t find out on the ISEE site if that’s a revision number or what. I expect it is, but I don’t know what it means! Any pointers?

The 720MHz version of the board should say “720 MHz” on a small green sticker on the bottom of the board.

Here’s the BASIC app – just download and set type to BASIC. It prints out the raw ADC values, the fairly accurate current calculated from the ADCIN5 value, and the less accurate current generated from the difference of the ADCIN3 and ADCIN5 values, as described in the newsgroup thread/PDF.

Many thanks for the app, Jeffrey. I’ll study it and the BB documentation about why it works and see if I can figure out how to implement a similar thing on the IGEPv2. I’d like to be able to monitor current consumption – it would be very handy.

I didn’t have much time to play around with the board this evening, but I did try a few brief experiments with ”*audio off”, and it definitely seems to stop the power management chip getting so hot. If your measurements are right, Jeffrey, a 600mA or so jump in power consumption is huge. I’ll be very interested to see what it is that you’ve targetted in order to increase efficiency.

I also managed to get debug output from the board for the first time today using a built-in serial port on a desktop PC, thus proving that my USB->RS232 converter I was using with my laptop is messing things up. I’ll have to buy another one from a different manufacturer. Out of interest, what serial terminal programs do people use on RISC OS? I was wondering if I could get the debug output into my a9home via its (probably flakey!) serial port…

And the fix for the stupidly hot audio/power chip is …. *speaker off.

Although the beagleboard and IGEP don’t make use of the speaker output of the TPS, my sound driver does allow the speaker output to be configured. So on boot RISC OS does its usual thing and tries enabling the speaker, but because the speaker output pins aren’t connected to anything it seems to just result in a big power drain and a load of heat being generated. With the speaker output turned off, audio only uses about 30mA of current, which is a much more sensible value!

There are still a couple of extra register settings that I want to try tweaking, but in a day or two I should be able to check in some changes which will lock out the mixer settings for features which don’t exist on the active board type. Last night I also knocked up the cut-down version of the Portable module – RISC OS seems to be calling it at the appropriate times, but until I get a multimeter I won’t really be able to tell whether it’s saving a significant amount of power or not.

I’ll be very interested to see what it is that you’ve targetted in order to increase efficiency.

Here’s a brief rundown:

• Audio settings (although I think I’ve cracked those now). The TWL/TPS has quite a number of different amplifiers and audio paths, and the TRM doesn’t always give good explanations of how stuff works. Until I realised that RISC OS was turning on the speaker output I think I’ve just been chasing shadows with most of the tweaks I’ve been doing to tidy up the register settings.
• The WFI-based Portable_Idle implementation – This is mostly done now. There are a few extra places I can think of where Portable_Idle could come in handy (when RISC OS waits for interrupt-based IIC, SCSI or USB transfers to complete), but those additions probably won’t make much of an impact compared to what’s already there (idling in the wimp, waiting for keyboard input, waiting for vsync)
• Power-saving settings of the OMAP subsystems – Making sure that interface clocks are set to auto-idle, and making sure that functional clocks are turned off when the module isn’t needed for long periods of time. This one could take a while to sort out, especially since there aren’t any guarantees that modules that we don’t use at all will be in sensible states when RISC OS boots.

There’s also likely to be some longer-term stuff happening, mainly reimplementation of the other Portable module features. Suspend-to-RAM and other sleep states which involve turning peripherals on/off are probably going to be the toughest to get right (i.e. so they give the greatest power saving possible)

Out of interest, what serial terminal programs do people use on RISC OS? I was wondering if I could get the debug output into my a9home via its (probably flakey!) serial port…

There is supposedly a 32bit version of !Connector available somewhere, but after trying the 26bit version in Aemulor and not being able to spot a simple way to get it to open a simple serial connection (either that or not being able to get it to use the right settings – I can’t remember), I just falled back to tweaking one of the serial block driver sample programs and running it from a task window. It’s not a perfect solution (Escape quits the BASIC program instead of sending the character to the beagleboard, and closing the task window without quitting the program will leave the serial port stuck in a “claimed” state), but it does aloww me to easily save logs or drag-and-drop scripts into the window for execution. With a bit of work it could probably be fixed to send escape codes and to not break if the taskwindow gets closed, but now I’ve learnt not to break it I haven’t bothered to tweak it any further.

My power management improvements (so far) are now in CVS - the audio fix, basic Portable module, and where possible all the OMAP subsystems that we use have been set to autoidle their interface clocks when there’s no interface activity. Autoidling the interface clocks doesn’t save a lot of power (or at least not at the level of individual modules), but once enabled it doesn’t require any extra management in software or result in any performance penalties, so it’s a good idea for us to use it whenever possible.

Most of them are able to automatically recalibrate, but the video one seemingly can’t.

This is a lie – the DSI PLL, which we use for video, does support auto-recalibration; it just wasn’t enabled.

Hopefully all the above tweaks will make your IGEP boards a bit happier :)

The sources for Connector were released by Andreas some time ago (didn’t know it myself, just googled it a few minutes ago!):

http://connector.a-m-z.org/download.html

I know that Stefan Bellon 32bitted it some time ago, but it was a bit flakey, since it was quite a hack to move it from Desk to DeskLib IIRC.

My power management improvements (so far) are now in CVS

Thanks for these fixes and improvements, Jeffrey. I’ve had to send my IGEPv2 board back to ISEE for investigation about the heat-induced contact issue with the processor. Hopefully they’ll send me a replacement soon. Once I get a board back, I’ll certainly try out the latest ROM and see how it runs.

And the fix for the stupidly hot audio/power chip is …. *speaker off.

Ah ha! So it was trying to raise the voltage across some unbelievably low-impedance phantom speakers, and pumping as much current out to do so as it could! I’m surprised there isn’t some hardware protection against that!

I haven’t looked at your BASIC current-measuring program yet, Jeffrey, but I did post on the IGEPv2 hardware forum to ask if there was a similar series resistor in the power train of my board across some of the ADC pins on the TPS65950, and there isn’t! So without me wiring up something with the GPIO pins, I guess this won’t be something we can do on the IGEPv2. I’ll just have to use a multimeter!

There is supposedly a 32bit version of !Connector available somewhere

I’m surprised there aren’t more options available. Shame !Nettle can’t do it!

Ah ha! So it was trying to raise the voltage across some unbelievably low-impedance phantom speakers, and pumping as much current out to do so as it could! I’m surprised there isn’t some hardware protection against that!

The TPS does protect against overheating (both of itself and the OMAP), but the temperature threshold is set quite high – around 150 degrees, IIRC. I’m not sure how many outputs I’d have to turn on at once to reach that temperature ;)

Around 150 degrees, IIRC. I’m not sure how many outputs I’d have to turn on at once to reach that temperature ;)

Let’s not find out. The burn on the end of my finger still hasn’t healed! ;-)

I’ve had it pointed out, that IGEPv2 is on sale sans WiFi and Bluetooth for 105 EUR:

http://www.igep-platform.com/

That was me guys, I already bought one. SO my A7000 finally gets an update!