RISC OS on IGEPv2

Been very busy with other things, so off all things RO for a while. Just wanted to say great work to Stephen for getting the LAN driver going reliably. Looking forward to browsing the source! And here’s another vote for interest in getting WiFi going!

Sorry for the delay in getting 0.3 released… insanely busy summer holiday period. Will try to find time to bundle the release together before the weekend but if not i’ll get it sorted next week.

Just have to write the release notes.

Looking forward to it, Stephen. Hey, we’re all busy! Don’t worry about it!

Right… finally a day to get something riscos-y done.. will get to finishing the driver and publishing it.

Has anyone considered putting together an IGEP/Beagleboard RiscOS website?

Release 0.31 of EtherGEP with all the RiscOS allocated strings.

Enjoy.

<a href="http://www.vavi.co.uk/~sleary/EtherGEP031.zip">http://www.vavi.co.uk/~sleary/EtherGEP031.zip</a>

Many thanks stephen I’ll try it out later!

Has anyone considered putting together an IGEP/Beagleboard RiscOS website?

Considered: yes. Implemented: no.

Am thinking of a Drupal site with FAQ etc. – I have a couple of relevant domain names. Would like to appeal generally to people interested in ARM hardware in GB/EU. Some RISC OS-relevant stuff would be on the site, with links off-site to ROOL and other usual suspects. Links to other OSes (off-site) would be included, so search engines could suggest the site and people would see RISC OS on their way. Therefore, intention would be to attract new users/developers to RISC OS.

...However, don’t hold your breath on this.

Fair one.

Jeffrey, any progress with the IGEPv2 video? I’ve had some mails form WPB on the subject but not seen any updates here for a while.

Jeffrey, any progress with the IGEPv2 video?

Not yet, no. I sent WPB an email last week with some information about how to get a dump of the TPS registers from within Linux, but he was about to go away for a week so I haven’t heard back from him yet. But hopefully there’ll be some discrepancy between RISC OS and Linux that explains why the video is failing (e.g. the TPS GPIO pull up/down resistors, which RISC OS currently doesn’t touch, but Linux does). If there’s no discrepancy with the TPS registers then we’ll have to work out how to get a dump of the OMAP registers from within Linux, so we can start comparing those against RISC OS.

A couple of months ago I did have a quick go at porting the Linux DSS2 driver to RISC OS, but the code relies on too many Linux headers and functionality for a quick port to be feasable. So instead we’d have to go through file-by-file, checking over the code to understand how it works, and rewriting the relevant bits to work under RISC OS. Which is something I’m not particularly eager to do, considering how much other work I’ve got, and that I think there’s very little chance that porting the driver would fix the issue (it’s more likely to be something else like an obscure GPIO setting).

I think i dumped the TPS registers at one point and found there was no difference? Might not have been all the TPS registers though.

At this point i’m inclined to strip down the linux kernel to the bones and log all io writes.

Stephen, any news on releasing the source for your EtherGEP ?

I’m not releasing the source any time soon. I’ve made sure that someone else in the RISC OS world has a copy in the event i drop off the radar.

Look at EtherUSB source if you want some code to look at. My code is a backend of that architecture.

That’s a shame as on the 25 May you said

Driver works perfectly when it starts. Which is 1 in 3 for me. I have some bug somewhere with startup that i need track down. Once I have that done i’ll release the source. If you want a binary update let me know.

If its just a general release you don’t want, would you consider sending me a copy, so I can see if I can add the Devkit NIC ?

If i released the source now i’d have to release it under the GPL and I wouldnt be able to change the license later. I dont want to do this. I want to release it under the BSD license. I hope this answers your question.

There will not be any reusable code in my source that you cannot already get from EtherUSB. Its all in C code and the structure is identical.

S

... Devkit NIC

Tank – do you think there’s anything in these sources of any use?

I’d write the DevKit Nic for you myself if there was an emulator available that I could use.

Trevor, I have a couple of C source files for the DM9000 used on the Devkit, but as my C skills are minuscule, I was hoping to just graft into a known working setup. I thought having Stephens source might give me more pointers than the USB driven code.

Stephen, are you based in the UK? If so, maybe I could send you my board. If this is of interest please email me webmaster@tankstage.co.uk .

Did you know the EtherK sources are also available here https://www.riscosopen.org/viewer/view/mixed/RiscOS/Sources/Networking/Ethernet/EtherK/ – this is the driver for the nic in the Iyonix.

Progress with DM9000 NIC.

Have received the DevKit board from Tank. Have added a backend to EtherGEP and thanks to Jeffrey for the foresight to put the GMPC init stuff into the HAL. I have a broken driver that recognises the DM9000’s presence. Incidentally the DevKit is a very nice board.

S

Update.

Have the phy read/write code in, have the DCI code in and the device detection code in. I havent confirmed that my IO writes are actually working yet but we’ll get there. Next step will be to get the beasty sending data. I havent actually tried to set an ip address yet.

Won’t be able to get anything done on this on tuesday/wednesday but should be able to get back to it thursday.

I appear to have RX working but TX is not working yet. After i get that working its time to tackle interrupts.

Weirdly the phy is reporting wrong polarity to DCI.

its alive!!!

C:\Windows\system32>ping 192.168.0.22

Pinging 192.168.0.22 with 32 bytes of data:
Reply from 192.168.0.22: bytes=32 time=2470ms TTL=255
Reply from 192.168.0.22: bytes=32 time=1998ms TTL=255
Reply from 192.168.0.22: bytes=32 time=2000ms TTL=255
Reply from 192.168.0.22: bytes=32 time=1998ms TTL=255

Ping statistics for 192.168.0.22:
    Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 1998ms, Maximum = 2470ms, Average = 2116ms

Now interupts.

Great stuff! Has Tank had a ping to say hello too?

We had a chat yesterday.

Driver is now in a state where it can connect to NFS server. Its polling on a callback timer at the moment but it’s working.