RISC OS on IGEPv2

Yes thanks Trevor, Stephen has been keeping me informed.

Okay,

So the machine is locking up when i activate the HAL interrupts. To figure out whats going on I need to see whats happening on the debug console. But i’m getting nothing. Once this bit is debugged its job done.

Jeffrey,

I’ve been having trouble with interupts on the DevKit8000. I seem to be getting a lockup after enabling IRQs even when i have all the DM9000 interupts off. Is it possible there is a bug the HAL?

Looks like the kernel is sulking because i’m not reseting the interrupt but I cant confirm this because i cant get the DevKits serial console to work. I more or less copied the code i had for the SMSC9XXX interrupt handler.

I’ve pastebin’d the code incase there is an obvious mistake. The lockup happens when i enable IRQs in dm9000_setup_irqhandler.

i.e. the line…

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

Im pretty sure all interrupt sources are off. I’ve even disabled the internal interrupt to wraparound the fifo buffer.

http://pastebin.com/SVEXXedU

Ok..

For future reference, the IGEP and the DevKit have completely different serial console pinouts. The IGEP followes the IDC spec for numbering pins whereas the DevKit doesnt. One solder job later….

Not seeing any interrupt errors on the debug console when the machine locks up. So either: -

1. my routines are calling something they shouldnt that causes the lock. 2. there is a problem with the veneers

or

3. there is a bug with the HAL.

ideas?

The problem occurs when trying to keep the HAL happing following the if (intsts == 0) { } code path.

I’m not sure but maybe i’m being handed an interrupt I shouldnt be getting and therefore am not clearing in hardware (but I am clearning in software) which causes an interrupt loop?

I’m not quite sure where I got the original settings from (probably from the DM9000 datasheet), but by looking at the linux sources it looks like the GPIO IRQ is set to respond to the wrong level. Try the following and see if it fixes it:

*memorya p 48310040 02000000
*memorya p 48310044 0

Otherwise I can’t see anything wrong with your code.

Thanks Jeffrey,

Had been about to try that this afternoon when my server expired. :(

Will report back with a result tomorrow.

Confirmed. The HAL had the wrong interrupt polarity. Getting RX interrupts properly now yay.

Jeffrey, Can you patch the HAL? In the meantime i’ll roll out a ROM with the driver.

S

Its possible that u-boot sets the interrupt polarity to active low for consistency with the rest of linux. Active Low is more usual.

s

Jeffrey, Can you patch the HAL?

Now done.

Its possible that u-boot sets the interrupt polarity to active low for consistency with the rest of linux. Active Low is more usual.

I did have a quick look at u-boot but didn’t spot anything obvious. Oh well, it’s no big problem – just a one line fix.

Thanks Jeffrey,

One little bug to hunt down and we’re good. Looks like i’ve got something set up non-reentrant.

I’ve blown the dust off my IGEPv2, with the intention of trying out some NEON stuff. The video is still flaky however once it heats up a bit.

When the board temperature hits 35-37degC I start to get video breakup. At first it’s sparkles then after a bit the screen just blinks on and off. Blowing across the board brought the temperature back down and the video became stable again.

I rebuilt my LEGO case to allow more airflow and mounted a 12V 80mm fan directly above the board. This seems to have stopped the misbehaviour for now.

Yeah i’d really like to nail this IGEPv2 screen issue. Its very likely to be a PLL drifting with temperature.

I think I’ve just found the issue. Try this: http://www.phlamethrower.co.uk/misc2/riscos.zip

I’m testing this now. So far so good…!

Running at 41.3 degC and no glitches! That would normally be impossible. I think I’m safe to say…Bug NAILED! Thanks, Jeffrey!

I’ll give this a go later. What was the change?

Jeffrey,

I need to do the equiv of spin_lock_irqsave(); and spin_lock_irqrestore(); in riscos. Would that involve a call to kernel_irq_on/off() or a call to deacivate/activate? Any other suggestions welcome.

There’s a small chance that Ian Griffiths of Interact Software may possibly have some long lost knowledge relating to spinlocks and RISC OS.

Thanks Trevor. I can do the spinlock fine its the “irqsave” bit i need advice with.

I’ll give this a go later. What was the change?

There’s a GPIO that controls power to the DVI framer, which the HAL didn’t know about. So the GPIO was being left at its default configuration – as an input, causing the value to float somewhere between “on” and “off” depending on temperature, prevailing wind, the price of tea in China, etc. Somehow the “todo” note about this that was in HAL.OMAP3.s.board managed to go unnoticed all this time!

I checked the fix into CVS last night, so people shouldn’t have any problems building their own ROMs.

I need to do the equiv of spin_lock_irqsave(); and spin_lock_irqrestore(); in riscos. Would that involve a call to kernel_irq_on/off() or a call to deacivate/activate? Any other suggestions welcome.

I’d suggest using kernel_irq_on/off. Although for OMAPVideo I have the concept of “quick” updates (which just disable interrupts globally via kernel_irq_on/off) and “slow” updates (which disable just the video IRQ, so other parts of the system aren’t impacted by the slow operation). You might want to do a similar thing in your own code, depending on how long you need to keep IRQs disabled. If you want to do that then let me know and I’ll add some new HAL calls to allow the IRQ to be enabled/disabled. In the time being you can just use the device activate/deactivate calls (all the code does at the moment is enable/disable the IRQ in the GPIO controller), but obviously there’s no guarantee that those calls won’t do something more destructive in future (e.g. fiddle with reset signals or power)

There’s a small chance that Ian Griffiths of Interact Software may possibly have some long lost knowledge relating to spinlocks and RISC OS.

Knowledge like “you must be joking”? :) Spinlocks only work if your code is running inside a preemptive thread scheduler, which last time I checked isn’t the case with RISC OS ;)

Knowledge like “you must be joking”?

Hmmm – that’s probably about right. And a search of his site reveals no recent RISC OS references anyway.

Thanks Jeffrey,

I just need to be sure nothing interrupts me while I’m tx’ing or rx’ing because of the really cheap way the DM9000 register addressing works. I’ve been getting issues when flood pinging the card. Once i get the card to stand up to 20 mins of flood ping and transferring 600Mb files quickly its all good.

Genius. Just had the board running at 39.9degC (lots of copies of StarFighter 3000) with no video problems observed. Thanks!

yup. confirmed, all working. Nice one.