RISC OS on IGEPv2

And another congratz from me :-)

Stephen, keep up the good work! You may have gotten me to buy a IGEPv2..

Jeffrey, Where are the HAL_EnableIRQ/HAL_DisableIRQ values defined? i’ve grep’d the source and come up dry.

My mistake – it’s HAL_IRQEnable and HAL_IRQDisable.

:) thanks. just found it. incase you hadnt guessed im trying to wire up interrupts.

On #riscos if you’re online for a bit.

Jeffrey,

I’ve setup an interrupt handler to catch all interrupts as described by your previous posts. Basically im not getting any interrupts (and nothing is appearing on the serial debug console).

My code sets up a vector handler (in cmhg) and uses the following setup code…

vector-handlers: smsc911x_irq_entry/smsc911x_irq_handler

_kernel_oserror *smsc911x_setup_irq_handler(void *dev_pw)
{
    ws_t *ws = dev_pw;
    ws->nic_device =0;
    ws->irq_count = 0;
    /* Hunt for the HAL device */
    SMSC_TRACE("SCANNING FOR NICs\n");
    _kernel_oserror *e;
    int pos=0;
    do {
        e = _swix(OS_Hardware, _INR(0,1) | _IN(8) | _OUTR(1,2), HALDeviceType_Comms + HALDeviceComms_EtherNIC,pos,4,&pos,&ws->nic_device);

        if(e) return e;
        if(pos == -1)
        {
            return (_kernel_oserror*) "\0\0\0\0No OMAP NIC devices found";
        }
    } while(ws->nic_device->dev.id != HALDeviceID_EtherNIC_SMSC9221);

    SMSC_TRACE("Claiming the device vector\n");
    /* Claim & enable */
      e = _swix (OS_ClaimDeviceVector, _INR(0,4), ws->nic_device->dev.devicenumber, smsc911x_irq_entry, dev_pw, 0, 0);
    if (e) return e;

    SMSC_TRACE("Activating the device\n");
    // if we got here then we can register the card.

    if(!(ws->nic_device->dev.Activate)(&ws->nic_device->dev))
    {
           return (_kernel_oserror*) "\0\0\0\0NIC device failed to activate";
    }

    e = _swix (OS_Hardware, _IN(0) | _INR(8,9), ws->nic_device->dev.devicenumber&~(1u<<31), 0, EntryNo_HAL_IRQEnable);

    if (e) return e;

    SMSC_TRACE("Activated device: %i\n", ws->nic_device->dev.devicenumber);

    return NULL;
}

which gets run during device startup and completes as expected. The handler is

    printf("INTERRUPT!\n");
    ws_t *ws = pw;
    ws->irq_count++;

    return 0;

i have other code which polls and prints the value of ws->irq_count… always 0.

Any ideas? I’m pretty sure i’ve switched interrupts on in the hardware.

Looks like there were a couple of bugs in my GPIO setup code (and one bug in objasm, naturally!) This commit should fix everything – it certainly looked like it was working when I tested it on my board.

Thanks for looking at that Jeffrey,

I’ll do a ROM rebuild and report back later.

after the rom rebuild my machine locked up after activating the device. So looks like you fixed it.

Are interrupt inputs active high or low? the NIC lets me choose. I’ve assumed active low.

My code configures the GPIO controller to respond to the NIC’s default setting – so for the SMSC it’s active low and for the DM9000 it’s active high. Really this is something that the HAL device should expose to the driver (e.g. in case the IRQ controller isn’t as flexible as the OMAP GPIO controller), but for now just using the defaults should do.

Ok i have interrupts firing now. But i dont seem to be getting the correct private word from the operating system.

I’m going to tripple check this once i manage to link against debuglib but it seems i dont get passed the same value i pass into OS_ClaimDeviceVector. I also notice that you ignore the pw value in the dispc.c file. I’m actually happy to work around this but if that doesnt work then iit should be mentioned in the documentation.

It may be a C interop issue thinking about it. As R12 gets passed the value it might not be easy for C to put that into a specific variable. Again this should be mentioned if this is the case.

Seems i mostly get the correct word but occasionally get crap?

The private word pointer should work. Admittedly I don’t think it gets used very often with modules written in C, but I’d be very surprised if it was broken.

Does the crap you get look anything like a pointer, or is it pure crap? What about the value of the other registers that the CMHG veneer provides? (I’d expect their values to be pretty much identical each time the interrupt handler gets called)

I’ll do some digging myself and see if I can turn anything up. I’d expect that the code that CMHG produces is fine, but that there’ll be some other piece of code going wrong elsewhere and either corrupting memory or improperly saving/restoring registers during an interrupt routine.

i’ve added a guard at the start of the routine to return 1 if i dont get my private word. I still have interrupt issues. Is there a way to make the GPIO on the OMAP boards interrupt on a high to low transition only?

I still have interrupt issues. Is there a way to make the GPIO on the OMAP boards interrupt on a high to low transition only?

Yes – if you look in hdr.GPIO and s.NIC then you should see that there’s a field in the HAL device prototypes that contains a set of flags indicating how the GPIO IRQ should be configured. To get it to work reliably you may also have to write some code to configure the GPIO debounce timer (this may also be true with the level-based interrupts).

I’m assuming your code goes through the correct sequence once it services the interrupt? (calling the HAL device ClearIRQ entry, then HAL_IRQClear)

i think i may have missed the ClearIRQ entry. I’ll try that later on and see how we go.

Current handler….

http://pastebin.com/yqxGYWLK

I wonder if calling a SWI from an IRQ needs more setting up. I vaguely recall that the stack is not setup for calling SWIs. It could be however that the cmgh already caters for this.

Does that code even compile? I can count at least 3 things wrong with it :)

Corrected version here: pastebin.com/82PJbQdb (oops, missed one of the mistakes. This one is good: http://pastebin.com/iitAFi8z. Ignore the typos in the comments, I can’t be bothered fixing those ;))

I wonder if calling a SWI from an IRQ needs more setting up. I vaguely recall that the stack is not setup for calling SWIs. It could be however that the cmgh already caters for this.

Yes, the cmhg veneers will look after this for you. (for the uninitiated – if you were writing this in 100% assembler you’d have to make sure you save R14_svc before calling a SWI, otherwise the ARM will clobber it when it switches into SVC mode to call the SWI processor vector)

Jeffrey, thanks for pointing that out.

Also I wonder if the HAL has setup dev.ClearIRQ if the swi with EntryNo_HAL_IRQClear still needs to be called.

It would be nice if the HAL caters for this since it is responsible for setting up dev.ClearIRQ?

Your pastebin helps a lot in getting more insight in how to do IRQ handling in conjunction with the HAL.

Also I wonder if the HAL has setup dev.ClearIRQ if the swi with EntryNo_HAL_IRQClear still needs to be called.

Currently they do both need to be called. It would be easy to change it so that ClearIRQ automatically calls HAL_IRQClear, but I’m not sure if either method is able to offer any particular gain over the other. About the only thing I can think of is that keeping them seperate makes it slightly easier to use FIQs instead of IRQs (I think it’s now fairly standard for the systems main IRQ controller to allow the programmer to select whether each interrupt source generates an ARM IRQ or an ARM FIQ. So as it is currently most/all HAL devices would function correctly irrespective of whether IRQs or FIQs are in use for that particular device – but if ClearIRQ called HAL_IRQClear then it could cause problems if you tried using that device with FIQs instead.)

code probably doesnt compile but thats the workflow i’m working with at the moment. I’m not at a machine that can compile it at present.

Is there anyone working on something that could replace cmhg so we could cross compile these modules with linux?

Stephen, there seems to be source code for cmunge at http://www.riscos.info/downloads/gccsdk/latest/

not sure if that is what you need.

cmunge encrypts and compresses code. CMHG produces a C wrapper for modules.

If you’re interested in proper cross-compilation (i.e. producing a RISC OS module, not native x86 code sitting in a test harness) then you should be able to use GCCSDK on Linux. There might be a few teething problems to work through if you’re going to try and maintain a makefile that can be used with both GCCSDK and Norcroft (particularly if it’s going to be used in the RISC OS build system), but there shouldn’t be any major hurdles. I’d say that the bigger problem is that the last time I checked the documentation wasn’t that great – there are examples on how to use the autobuilder to build common unix stuff like wget, but no examples on how to use the compiler outside of the autobuilder environment for regular development stuff.

http://www.riscos.info/index.php/GCCSDK#GCC_Software_Development_Kit