RISC OS on IGEPv2

Jeffrey, you’re a star. Thanks so much for taking the time to spell all this out.

No problem. Answering questions on the forum is much easier than trying to spec out my GraphicsV extensions ;)

I can’t believe you figured most of this stuff out yourself from the sources

I’ll tell you now that grep (or anything like it) is an invaluable tool for finding out how everything fits together. Apart from its obvious uses for finding where SWIs/functions are implemented/called/documented, I’ve also made use of it as a rough-and-ready way of finding which source lines correspond to particular addresses in ROM (e.g. after a crash), by searching the relevant source files for ‘rare’ opcodes spotted near the site of the crash.

I can’t believe you have time to do as much coding as you do AND keep the forums and wiki going!

I have a feeling that not having much of a social life has been some help here!

Speaking of which, I think the above post would be really valuable information to add to the wiki.

Perhaps – I suppose it wouldn’t hurt to have an explanation of which parts of the HAL do what. Although I’d like to think that most of it was self-explanatory (Audio code in Audio.s? Who would have guessed!)

I’ve also made use of [grep] as a rough-and-ready way of finding which source lines correspond to particular addresses in ROM

For the record, the output of “amu gpa_debug” provides an alternative to this, and one which doesn’t rely on locating nearby rare opcodes.

The only trouble with invoking AMU is that it sometimes causes the code to (a) be recompiled, and (b) be recompiled with different options. E.g. the MkGPA script for the WIMP, which just runs “amu_machine gpa_debug” results in the code being recompiled with “debugging SETL {TRUE}”, which makes the resulting GPA file rather useless for converting address offsets to source lines if you’re trying to track down a crash in a non-debug version of the module :(

It would be nice if !Builder/srcbuild had an extra option that allows accurate GPA data for all components to be generated at compile time. But I’m not sure how much time/effort would be needed to go through and fix all the makefiles so they don’t do silly things when asked to generate the GPA files.

Hey Guys,

The IGEPv2 has a smsc911x ethernet controller for which there already exists a RiscOS driver. All that would be required is to 32bit-ify it and to implement the correct bus.

I took a look at the linux driver and the codebases are very close.

Driver is EtherY http://usenet.gerph.org/CTL/EtherY/

This version has had some 32bit updates added already but at present my ARM assembly language coding isnt so good.

p.s. does nobody hang out on #beagle or #riscos on freenode?

Ah, that should save a lot of work.

Of course the only downside is that it’s GPL, so it we’ll have to distribute it on disc instead of as part of the ROM image :( (Although that in itself isn’t a big deal, since the network setup and various critical utilities are stored as part of the !Boot sequence anyway)

Also, it might be worth asking ROOL if they can add Castle’s original sources to CVS (so we can get the full history of the module) – although the fact that it isn’t listed in the ModuleDB suggests that it was never in CVS to begin with.

I’d be inclined to keep the driver out of ROM anyway for exactly the reason you say, but also because i could then grab GPMC bus drivers (which i assume is what the ethernet card uses) from either the BSD or linux kernels.

I may look and see what BSD uses to talk to smsc911x. If GPL is a big issue it might be worth starting from that codebase instead?

On a side note… Has anyone else noticed that zap’s overlay buffer doesnt work? is there a fix i can add to my ROM?

I have just managed to get my RiscPC to build the ROM. Hurrah!

I think taking the GPMC drivers from Linux/BSD would be more hassle than it’s worth. For one, there’d be the GPL issues with Linux (which could be a big problem if we ever want to put the GPMC code in the HAL - which we almost certainly do). For two, I’m not even sure if there are any BSD drivers available. And for three, it should only take a few lines of code (if any at all) to set up the bus for NIC access anyway :)

Fair enough. But the s.io code in EtherY is not very nice, nor is it 32 bit clean. Compiler is doing a good job of telling me what is wrong. Fixing it is another matter. TEQPs used all over the place.

I have found the base addresses now so i’ll try that and see how far i get before things die.

The s.io code in EtherY is not very nice, nor is it 32 bit clean.

All very true, but nothing that importing linux/BSD GPMC drivers is likely to fix. 99% of hardware is based around memory-mapped registers, and in my experience hardware drivers always access the registers directly – they don’t ask the bus driver to do it for them. The overheads of calling external routines wouldn’t be worth it, since there are very few cases where you need to do bus-specific things to access the hardware correctly – the bus hardware usually takes care of it all for you. Consequently, I doubt any GPMC drivers provide any routines similar to those in s.io.

I’ve found some SMC91C111 code with a NetBSD licence (I think) at:

http://ring.nict.go.jp/archives/NetBSD/NetBSD-release-4-0/src/sys/dev/ic/

I hope it may turn out to be useful.

The IGEPv2 has a smsc911x ethernet controller for which there already exists a RiscOS driver.

Mine has a LAN9221 on board. I don’t know if they’re exactly compatible, but I guess there’s a good chance. I’ll take a good look at the EtherY sources for sure! I’d still like to implement a HAL device-based driver if poss.

That might be what is there at a hardware level. But the linux driver that was running was smsc911x. Try running linux and lsmod.

Sources for EtherY are truely terrible. A HAL based driver would be nice but we should be able to get this up and running reasonably quickly.

Current status: I have the module started but the register read and write functions need 32bit-ified. Im good with C but not so good with ARM assembler. The ToSVCE and FromSVCE macros in the need modified.

After that i need to deal with IRQs. The base address for the GPMC for this chip appears to be 0×2c000000 and the IRQ is 176 (from what i can tell from linux/bsd)

Im good with C but not so good with ARM assembler.

This will probably be a bit of a learning experience then ;)

After that i need to deal with IRQs. The base address for the GPMC for this chip appears to be 0×2c000000 and the IRQ is 176 (from what i can tell from linux/bsd)

Be warned – the 0×2c000000 is a physical address, so will need mapping in. And the 176 is the pin it’s attached to on the GPIO controller, not the device number that you need to pass to OS_ClaimDeviceVector. In fact at the moment there’s not much code at all to deal with GPIO interrupts – see this post for some more info about what needs to be done.

If you wanted to save yourself some time and hassle then you could just hack the driver to set everything up specifically for the IGEP - it shouldn’t take too much time for someone more familiar with the code base to move the relevant bits into the HAL.

Also, to answer your question from earlier…

p.s. does nobody hang out on #beagle or #riscos on freenode?

I don’t usually hang around on IRC, but I could easily be there tonight to help answer your questions. Probably on #riscos, unless the beagleboard channel doesn’t mind us waffling on about RISC OS all the time ;)

Yeah im currently just attemping the minimal hack to get things working for now… Thanks for the tip on needing to map in 0×2c000000, i was wondering why things were dying in a nasty way when i “inw” from those addresses.

Everything is new right now but i’ll get there.

Ok im really struggling here…

https://www.riscosopen.org/wiki/documentation/pages/RISC+OS+entry+points+from+HAL

Says that the HAL’s RISCOS_AccessPhysicalAddress function is broken.

I’m really not wanting to start poking around with OS_SetMemMapEntries unless i have to.

So how do i map a physical to logical address? The Archies all had flat IO space!

RISCOS_MapInIO :)

At the risk of sounding really thick.. How do you call that from outside the HAL?

You don’t :) The call basically just boils down to a call to OS_Memory 13

I’ve managed to now get a call which gives me 0xF7D00000 as a logical address. However the buffer seems to be mainly zero and the register base addresses which are supposed to indicate the bank register does not cause any changes when written to.

I guess either i have the wrong physical address, wrong logical address or i’m just plain trying to talk to the wrong kind of chip.

... or thinking about it GPMC may just simply not be set up.

I have managed to get a dump of what the linux kernel does to setup the ethernet GPMC. There is quite alot happening there. I basically inserted printk() statements on all gpmc_ commands in the kernel, compiled it and ran it. I took the dump of the kernel startup messages from the serial console.

I’m now going to write a C program to do setup the GPMC. Once I have this i’ll pass it to whoever is intersted in integrating it into the HAL.

Great work, Stephen. Would you mind sending me a copy of the dump? Either directly to willblatchley AT yahoo DOT com or post it here?

I sent you it directly. I’ve managed to ioremap the gpmc area but im having trouble getting into supervisor mode in C!

os_swi0(OS_EnterOS) is crashing. Ideas?

That’s a SWI which won’t really work when called from C, since each processor mode has its own stack. There are a couple of workarounds:

• Stick the code in the EtherY module, e.g. in the initialisation function. The CMHG veneers make sure that module code is always in supervisor mode (except if the module gets started as a task, in which case it’ll be user mode – but that wouldn’t happen for the ethernet driver)
• Use an assembler wrapper/veneer to get into supervisor mode, fix everything so C will work, call a function which does all your work, and then drop back into user mode. This is somewhat fiddly due to the way the shared C library/APCS works.
• Stop using C and just use assembler ;)

As you can see the first option is probably the easiest.

FYI: I’ve decided to help out a bit by implementing all the HAL-side bits required for the IGEP/DevKit NICs. This means:

• Modifying HAL_InitDevices to behave differently for each board
• Adding some basic GPMC setup code
• Adding code to create & register the NIC HAL devices
• Putting in the right values to (hopefully) make it work properly on IGEPs/DevKits

There are only a couple of bits left to do, so the code should be checked in sometime ‘tomorrow’ (i.e. Friday). The HAL device will work pretty much as I described it in this post – exposing the NIC type, address & IRQ along with TestIRQ & ClearIRQ functions. This should be enough for people to implement their DM9000/SMSC9221 NIC drivers without having to worry about fiddling with the innards of the HAL.