RISC OS on IGEPv2

Or paste the code into a text file, prepend with AUTO and then *EXEC the file from BASIC.

Nice. Never thought of that!

At the bottom of this page there’s an MDF file containing modes which work well on the beagleboard.

Thanks, Jeffrey!

Thanks Jeffrey, I figured it all out know! Got a nice running desktop with boot! Only the heat remains a big problem. I hope it can be figured out soonish. In any case I tip my hat of to you,rool and all others involved. The dream has come true a cheapish,working,modern Risc OS computer! Hooray!

Hi All, I tested all the Beagleboard modes from the MDF file and there are three who don’t work on the IGEPv2: 720×576

1280X1024

1920X1080

32K colours messes up the screen aswell strangely 16 million does not.

On boot I also get an error:

It is when the Pinapple Software virus thingy is launching:

APPLICATION MAY HAVE GONE WRONG

INT ERROR:ABORT ON DATA TRANSFER AT &FC16A5E0

Hi again, Today I installed a coolingfan under my IGEPv2 board. This allows the board to remain usable.I can leave it on for hours now launching several applications (Blocks,Patience,paint) without the screen flickering. I have installed the regular autobuild rom instead of the rom Jeffrey gave us in this thread, and with*Speaker off it runs nicely!If I leave the speakers on the screen still fails after a couple of minuts. The good thing is that the error I’ve posted in the post above,is now gone with the autobuild rom.

I would love to hear from David Thomas and WPB if they are still having heat related problems!

Two more questions:

1)I am unable to unzip anything.I’ve only been able to install ArcFS and Sparkplug.

Infozip self expanding archive gives me an error (error zipfile is probably corrupt (segmentation violation.

Sparkplug gives me an internal error type=E with each zipfile I’ve tried.

ArcFS always gives me “This file is not an archive that is compatible with ArcFS.” On zip,arc and spk files.

What am I missing here? I must be doing something wrong. (all files have been downloaded on a Mac OSX10.4 or Windows Vista PC)

2)Can I format a 8GB FAT pendrive with SCSIform ?

INT ERROR:ABORT ON DATA TRANSFER AT &FC16A5E0

Do you know which ROM image you were using at the time? I’ll try grabbing a copy of the latest disc image and see if I can recreate it.

32K colours messes up the screen

Yes, this is a known issue. The OMAP doesn’t support the 5:5:5 RGB format that RISC OS has traditionally used, so we’ll have to expand RISC OS to support the formats that it does support.

1) I am unable to unzip anything.

Have you tried this command line unzip tool? Just set the filetype to Absolute and it should work. I think it’s the only unzip tool that works properly on ARMv7 at the moment.

2)Can I format a 8GB FAT pendrive with SCSIform ?

Yes. I’ve been able to format an 8GB SD card without problems, and other people are using >100GB USB hard drives.

The first version of the new video driver is in a fairly stable state now – in a few days time I should be able to check it into CVS. It doesn’t do much new and exciting stuff yet, but it does contain a few bugfixes, so with any luck it will help solve some of the issues people are having with their IGEPv2 boards.

I was using the rom image you advised me to use (downloaded from your webspace) with sound already turned off. with the self extracting HardDisc4 Boot. I have tried to run the run the commandline unzip. It works in commandline mode but not in Taskwindow mode.

Yaaay I got !Revolver to run It does looks a bit garbled but playable

I would love to hear from David Thomas and WPB if they are still having heat related problems!

Sorry, Thomas, I’ve been a bit distracted with other things, and my IGEPv2 is still in its box! I’ll get around to plugging it in soon, I’m sure, so I’ll let you know what my experiences are. Nice case, by the way!

The thing that surprises me is that turning off speakers seems to fix the display outages. The excessive heat generated due to the audio was because the TPS65950 was driving impossibly hard into speakers that weren’t there. But I’m not sure why that would affect the display, which as far as I’m aware has nothing to do with the power management/audio chip. Is it just that heat was affecting surrounding components, or is it that the excessive power draw was causing other problems? Jeffrey, do you have any theories?

No sweat, I just wanted to know if there is something wrong with my board are if you are stullhaving the same problems. Turning off the speaker alone doesn’t help without the fan. It still needs the cooling fan.

Just been trying this out to see if I can add anything of value. My IGEPv2 board does lose video after around 10 mins of booting RISC OS and idling. The screen goes blank, then comes back on but with random horizontal breakup.

It’s a recent-ish ROM I built myself with the WFI fix, etc., in. *Speaker is off. The CPU and the TPS don’t seem /that/ warm…

I see you have the same problems as me. So it is not our individual boards but a problem that all IGEPv2 have. I seem to have fixed it with *speaker off and adding a cooling fan. It didn’t seem that hot to me either but since the cooling fan works it seems the problem is heat related.

Thomas: I’ve now taken a look at those issues you’ve raised.

The internal error on boot was caused by ADFSFiler not working properly without the ADFS module being present. Although I haven’t fixed ADFSFiler (there’s little point since it would never get used for anything), I have checked in some changes to remove SCSIFiler’s dependency on ADFSFiler’s resources, which has allowed me to get rid of ADFSFiler form the ROM build (saving about 17k, which might be useful one day!).

Also, if the problem you’re having with using the command-line unzip tool from within a taskwindow is a “No writeable memroy at this address” error, then you can fix it by increasing the wimpslot size (anything over 700k should do), or by making sure my Absolutely module is loaded (e.g. at boot). At some point I’ll try merging Absolutely’s code into the OS source, but for now you’ll have to put up with the manual fix :)

I was going to write a bug report for ADFSFiler – until I realised that the code was written with the intention of reporting an error and stopping the WIMP task if the ADFS module wasn’t present, but a silly bug was preventing it from doing so and it was instead leaving the WIMP task running (with half-initialised workspace, which would sometimes result in data aborts like Thomas was seeing). That bug’s now been fixed, so we shouldn’t have to worry about any other problems with ADFSFiler/SCSIFiler misbehaving if their underlying FS module is missing.

Jeffrey: I downloaded and installed your Absolutely module. Which sure is a handy piece of software. Thanks!

One more question:I bought a 4GB stick but is seems that SCSIform has some troubles with it. It keeps telling me DISC is empty at line 130 when I try to format it. Anything I’m doing wrong?

This probably should be put in Wishlists: Is the Shared Sounds module already 32bittified? I can’t seem to find it on ROOL’s website. and the one CASTLE’s website is 26bit.

Otherwise I had no system problems yet, just waiting for the next autobuild to check the videodrivers.

One more question:I bought a 4GB stick but is seems that SCSIform has some troubles with it. It keeps telling me DISC is empty at line 130 when I try to format it. Anything I’m doing wrong?

I’ve never had that problem myself – but so far I’ve been formatting everything on my Iyonix with a potentially older version of SCSIForm. I’ll have a play around tonight and see what I can find out.

This probably should be put in Wishlists: Is the Shared Sounds module already 32bittified? I can’t seem to find it on ROOL’s website. and the one CASTLE’s website is 26bit.

There’s a copy of SharedSound 1.04 on Castle’s site here which I think is the same version I’m using on my Iyonix and so should be 32bit compatible. However I haven’t tried it on my BeagleBoard yet, so I’m not sure if it’s ARMv7 compatible.

I’m not sure who’s actually developing Shared Sound at the moment – originally it was developed by ESP, but they seem to have moved away from the RISC OS scene. I believe RISC OS 6 comes with version 1.10 of the module, and contains more features than 1.04, so it’s possible ROL have the source code now – and I’m not sure how forthcoming they’d be with any requests to release it! (slightly more info about this here and here)

It is that version I downloaded (I took the link from your website). When I tried to launch Deathdawn (:-)) it told me it was not 32bit compatible.

You’re right – the version I linked to isn’t 32bit compatible. But the version that came with my Iyonix (also version 1.04, but dated 31 March 2003) is compatible (and seems to work fine on my BeagleBoard). Time to start that thread in the wishlist forum, I guess!

Also, I wouldn’t bother trying DeathDawn if I were you – it needs recompiling with the latest version of GCC, and even if it did run it would need some fairly significant changes making to the rendering code (since it was all written for the traditional 5:5:5 16bpp format, which the OMAP3 lacks). Plus the version on my website is missing 12 months worth of fairly intensive development (the changelog doubled has doubled in size!) On closer inspection, only 9 months of development, and 25% changelog growth within that time. Bah! ;)

Thomas: It looks like you might have to debug this SCSIForm bug yourself. Line 130 doesn’t really do much interesting – in fact, the only bits that could produce an error message are done after the formatting is complete! It’s possible that you’ve bought a device that isn’t fully compatible with the current driver, or maybe there’s an obscure bug that makes SCSIForm fail if the device is exactly 4GB in size.

As an example of an obscure bug – I have a 1GB FAT formatted stick that worked fine for interactive copies in the WIMP, but would fail with “Target error – No sense” for any large block write operations. However after reformatting it everything seems to be fine (both for FileCore & FAT32 format). So maybe it was just an obscure bug to do with the way the stick was originally formatted. If I’d considered that reformatting might fix it I would have made a note of the FAT variant & disc layout so I could have investigated further at some point!

Hi Jeffrey,

Thanks for doing all that investigating work!

I got some good news! I just installed the new rom posted by Rob Heaton in thread above. And I can play music now. I don’t have to use *speaker off anymore. The new videodriver seems to work flawlessly. No more overheating for the IGEPv2. I’ll test it more tomorrow and report back.

Jeffrey, since I’m not really a programmer (I just ordered C for dummies on friday and the Norcroft Suite on saturday). I simply returned the stick to the store and got another one. The new works flawlessly it was exactly the same form factor as the old one but a different brand. I’ll guess I’ll just update the hardware compatible list.

I want to get the ethernet port going but is there something that a regular guy like me (currently without norcroft) can do?

Another question: I tried to get darkwood going but the game informed me that the gamemodes module is not 32bit compatible. I then proceded to download Gamemodes2 module from the ROOL site, renamed it Gamemodes and replaced it in game, but it still said it wasn’t 32bit compatible. Is it possible that some of the modules in binary form on the ROOL website are only 26bit?

I want to get the ethernet port going but is there something that a regular guy like me (currently without norcroft) can do?

I’m sure that someone recently said they were going to work on writing an IGEP ethernet driver, but I can’t find a reference to it now :(

So if you’ve got no knowledge of C or assembler then there isn’t really anything you can do at the moment. Except concentrate on reading your C for dummies book, of course :)

Another question: I tried to get darkwood going but the game informed me that the gamemodes module is not 32bit compatible. I then proceded to download Gamemodes2 module from the ROOL site, renamed it Gamemodes and replaced it in game, but it still said it wasn’t 32bit compatible. Is it possible that some of the modules in binary form on the ROOL website are only 26bit?

Are you sure it’s not Darkwood itself that RISC OS is complaining about? As far as I know it isn’t 32bit compatible, so would probably only run under Aemulor (and you’d have to wait for Adrian to finish the new version of Aemulor first).

Won’t the EtherUSB module work on the IGEP board with a suitable USB Ethernet dongle, like it does on the BeagleBoard? i.e. not the built-in Ethernet port, but it gets you connected?

Yes, EtherUSB should work fine.

I’m sure that someone recently said they were going to work on writing an IGEP ethernet driver, but I can’t find a reference to it now :(

That was probably me. It’s something I’d really like to get working, too, but I’ve been way too busy just recently to do anything RO-related. The IGEP uses an SMSC 9221 ethernet controller, and I suspect its interconnections with the OMAP can be gleaned by asking on the ISEE forums. (That’s not documented anywhere that I can find.) But I’ve never written an ethernet driver before, so it’ll probably take me ages. Jeffrey or someone else familiar with the source tree, could you possibly point me at the Iyonix NIC driver code?

The IGEP uses an SMSC 9221 ethernet controller, and I suspect its interconnections with the OMAP can be gleaned by asking on the ISEE forums. (That’s not documented anywhere that I can find.)

It’ll be connected via the GPMC bus, I know that much – but yes, you may have to ask around a bit or check the Linux source code to find the specifics (which chip select, clock speed, IRQ line, etc.)

But I’ve never written an ethernet driver before, so it’ll probably take me ages. Jeffrey or someone else familiar with the source tree, could you possibly point me at the Iyonix NIC driver code?

mixed/RiscOS/Sources/Networking/Ethernet/EtherK

Writing an ethernet driver for a modern NIC isn’t too hard (or at least it wasn’t too hard to add the Pegasus driver to EtherUSB). Once the NIC is set up all you need to worry about is reading & writing packets from the FIFOs and passing them on to the internet stack. Apart from the NIC datasheet you’ll also probably want to track down the MII specification (The MII - not to be confused with the Wii avatar of the same name – is a standard interface/chip that sits between the NIC and the RJ45 socket, and handles things like speed negotiation, cable detection, etc.)

Depending on which source license you opt for you could probably copy most of the generic bits of the driver (RISC OS DCI interface, generic MII management, etc.) from either EtherK or EtherUSB and then all you’d have to worry about is writing the bits for talking to the SMSC chip.

Thanks as ever, Jeffrey.

Once the NIC is set up all you need to worry about is reading & writing packets from the FIFOs and passing them on to the internet stack.

I expect the NIC is set up by U-Boot – hopefully RISC OS could inherit that. It looks like the 9221 is mapped to address &2C000000 in the GPMC memory space, just as the DM9000 is in the DevKit8000, on CS5. Its interrupt line appears to be connected to GPIO 176, provided by GPIO controller 5, I think. Clock speed, I don’t know.

Apart from the NIC datasheet you’ll also probably want to track down the MII specification.

Do you mean this? I have the datasheet for the NIC already.

Looks like a mountain of reading as usual!