RISC OS on IGEPv2

As usual, it seems I’m just too slow! ;( It’s really good of you to do this, Jeffrey, especially as it won’t directly benefit you (at least not yet!) At least I’ll be able to study the changes you’ve made and learn so that hopefully next time I can move a bit faster!

It was a bit cheeky of me to rush ahead and do it myself, but one thing kind of led to another once Stephen worked out that the Linux kernel wasn’t really doing much GPMC setup at all (most of it had already been done in u-boot). In the end it was quicker for me to write the HAL code myself since I already knew how to do most of what was required, and it would save everyone else the hassle of learning things that they’d probably never need of knowledge again (GPMC/GPIO configuration, which bits were/weren’t already implemented in the HAL, all the little bits that need doing when adding the ClearIRQ entry to the base HAL device struct, etc.)

I don’t mind cheeky, especially when you’ve been so good at explaining things. But I definitely want to get to grips with the HAL, so I’ll be checking out your changes! Will you be updating the HAL wiki docs, too? (He asks, cheekily!)

Will you be updating the HAL wiki docs, too?

Yes. I’ll also try and add a page giving an overview of the OMAP HAL (i.e. what I posted here a while ago).

I’ve managed to determine that the EtherY is a smc911x driver and the linux driver is an smsc911x driver, which is completely different. Doh!

So i’ve been working on getting the init code for the smsc911x to run in riscos. Basically im getting a about on data transfer after the first write to the card. Anyone know if i have to set any the privilages bits in my OS_Memory13 call?

So far so good anyway. I have a module that recognises the card on the right hardware and aborts nicely on a RISCPC. I guess i can remove my GPMC startup code once i update to the latest HAL.

while im here… is there a microsecond delay call in RISCos anywhere? Im looking to replace some udelay(x) calls in this driver i have with something sane.

#include "swis.h" 
#define EntryNo_HAL_CounterDelay 22

// will not work on RISCOS 4
void io_udelay(int d)
{
    _swix(OS_Hardware, _IN(0)|_INR(8,9), d, 0, EntryNo_HAL_CounterDelay);
}

Although you should get the EntryNo_HAL_CounterDelay value from the appropriate header file.

I have a feeling you could have done with some <code> tags around that :)

My HAL changes are now in CVS - WPB will want to look at this, this and this changelog to see what I’ve done.

No wiki updates yet, but as a brief guide:

• Take a look at module_init in the OMAPVideo module for an example of how to search for a specific HAL device.
• In the case of the NIC drivers, you’ll want to look for device type ‘HALDeviceType_Comms + HALDeviceComms_EtherNIC’, and either device IDs HALDeviceID_EtherNIC_SMSC9221 or HALDeviceID_EtherNIC_DM9000 (depending on which driver you’re writing, obviously)
• At the moment the HAL device is just a basic one which should be typecast to the ‘device’ struct that’s defined in Global/HALDevice.h (which is hidden away in RiscOS.Export.APCS-32.C.Global.h in a working build tree)
• The address field is the logical address of the NIC
• The devicenumber field is the device number to use with OS_ClaimDeviceVector. Try and write your code so that it behaves properly whether the IRQ is shared or not (although for this instance, they are marked as shared IRQs)
• The Activate entry point will enable the IRQ in the GPIO controller, the Deactivate entry point will deactivate it. So to keep RISC OS happy, it’s probably best to register your interrupt handler before calling Activate.
• Also, once you’ve registered your interrupt handler, remember to call HAL_EnableIRQ to make sure the IRQ is actually enabled in the main interrupt controller. You can do this before or after calling Activate, it doesn’t really matter. But make sure you clear the ‘shared’ bit from the number, because the HAL isn’t expected to deal with that.
• When you deactivate the device & deregister your interrupt handler, only call HAL_DisableIRQ if it was a non-shared interrupt, otherwise you’ll kill someone else’s driver :)
• TestIRQ should be self-explanatory if you’ve read the HAL docs ;)
• ClearIRQ should be called once you’ve stopped the NIC from asserting its IRQ line. This will clear the IRQ state in the GPIO controller. Note that ClearIRQ is an optional entry point, so don’t go calling it if it’s a null pointer ;)
• After you’ve called ClearIRQ, you then call HAL_ClearIRQ to clear the IRQ from the main interrupt controller.
• Then, and only then, is it safe to re-enable IRQs in the PSR. Otherwise you’ll get stuck in an infinite loop of interrupts. You can tell if you’ve done this by mistake by all the warning spam the HAL sends out over the serial port.

I think that’s about it. Have fun!

Not sure if this helps, I’ve just built another OMAP ROM today, that contains Jeffreys latest updates.

http://robheaton.co.uk/devel/rom-omap.5.17.zip

Thanks Rob.

I now have a USB NIC i can use to transfer data onto the IGEP .. makes testing alot faster.

For anyone interested I have found the best setup is to have an NFS share with all my C files in it, those files are hard linked (ln, without the -s) to posix style filenames in the top level dir.. e.g.

c/example → example.c

I then use VS2008 (or i suppose you could use eclipse or emacs) to edit the files. I use MSVC++ compiler to compile the code (and produces a binary too!) then i run my makefile on the RISCOS machine to build the target.

This gives me a nice editor and intellisense while editing, keeps the code files off the development platform and allows me to run valgrind or purify against the windows binary to find issues.

Not everyone’s cup of tea but i thought i’d share.

Sounds like a nice setup, I’ve never thought of using VS2008 for RISC OS work!

EtherS is breathing… She’s transmitting crap at the moment.. but she is transmitting :)

Quick question. I bascially modified EtherUSB to use GPMC. The driver is waaaaay cleaner than any linux stuff i’ve seen. So how do i choose module SWI bases and module error code bases?

Current progress

*ESInfoEtherS driver for USB ethernet adapters
DCI version: 4.04
Driver prefix: es

Supported backends:
  SMSC911X             - SMSC911X GPMC Ethernet Adapter

Unit 0 (location: GPMC address: 4156555264, Devices:$.GPM):

  Backend:          SMSC911X
  Ethernet address: 00:EE:33:02:AA:01
  Link status:      Up, Unknown, full duplex, correct polarity
  Controller mode:  Promiscuous

  Frame types claimed:
    IEEE 802.3                handler=(FC317B1C,FB407504)
    Ethernet 8035 (normal)     handler=(FC2D59FC,FB407414)
    Ethernet 0806 (normal)     handler=(FC2D59FC,FB407414)
    Ethernet 0800 (multicast)  handler=(FC2D59FC,FB407414)

  Statistics summary:
    TX frames          13            RX frames   0           
    TX bytes           813           RX bytes    0           
    TX errors          0             RX errors   0           
    TX queue length    0             RX unwanted 0           
    TX queue overflows 0           

Unit 71 (location: ):
  Backend:          
Internal error: abort on data transfer at &FC13C31C

Press SPACE or click mouse to continue

My HAL changes are now in CVS - WPB will want to look at this, this and this changelog to see what I’ve done.

Jeffrey, thanks for pointing me in the right direction. I’ve already had a brief skim over your code. It makes a fair amount of sense to me, I’m relieved to say! That said, it would’ve taken me about ten times longer to write, probably!

Stephen, looks like you’re making progress. Great stuff!

So how do i choose module SWI bases and module error code bases?

For module names, SWI/error bases, etc. you need to send an allocation request to ROOL. See here for full details.

Sounds like you’re making good progress on the driver.

Now attaching the interrupts to the RX system. Needed a new build of RO5 for this so slllllooooowwww.. anyone know how to build RO5 with the CVS stuff intact?

anyone know how to build RO5 with the CVS stuff intact?

Stephen, I brought this up a while ago. (See here) At the moment, it’s not possible, not least because the format of the sources in CVS and the format for building are not the same – you have to merge some directories together to get the build tree ready. But also, the CVS special files have to be stripped out for building, too. Steve Revill is working on changing the first point. As for the CVS files, I was wondering if they could be “moved” before building into a temporary equivalent directory structure, and then “restored” after building ready for CVS update, etc. Anyway, right now, it can’t be done.

Sadly, despite RMA-ing my IGEPv2 due to display problems, the new board still suffers from the same issue under RISC OS, albeit far less frequently. I thought I was okay, because I left the thing on all day a few times, both at the CLI and in the desktop, and it looked like the display was solid. But then I noticed a couple of times in a 1024×768 256 colour mode (60Hz) the display blanked out momentarily. It seems like it happens mostly when there’s input going on. Perhaps the USB transfers are interferring with the screen transfers somehow?

Does no one else with an IGEP see this? It’s strange that two boards have the same problem, and I’ve tried three different displays, too…

Re:CVS yeah i was just wanting a way to do cvs update then to a partial rebuild instead of recreating everything on my SA RiscPC.

Re:IGEPv2 Screen issues… yes i see this. My current theory is that it a heat issue which happens when the operating system spinlocks when the system is already hot. We really need to make the IGEP run either a slower speed, sleep more or stop spins!

Alternatively we could try tweating the CPU thermal settings and add this code to the HAL. I’ll maybe look into this once i get this driver finished.

If I understand correctly, there is no dedicated screen RAM, so all screen refresh data have to be taken from main memory by DMA. Is there any chance that some other process is stopping screen DMA?

I dont think a process itself can stop the DMA unless the USB drivers are disabling the screen dma controller somehow. Which is possible. I saw this happening when i had an a relatively long spin. The DMA should interrupt the processor to get access to memory though so im not sure why this could be happening unless it is heat related.

I dont think a process itself can stop the DMA unless the USB drivers are disabling the screen dma controller somehow. Which is possible.

That’s what I was thinking.

But then I noticed a couple of times in a 1024×768 256 colour mode (60Hz) the display blanked out momentarily. It seems like it happens mostly when there’s input going on. Perhaps the USB transfers are interferring with the screen transfers somehow?

Hmm, that’s not great. By “input” I assume you mean typing something into a text editor? If so, then I doubt it’s the USB transfers to blame – it would be a low volume of traffic, probably less than the amount you get just by moving the mouse around. If it was high volume traffic then there’s a possibility it could cause a FIFO underflow, but I wouldn’t expect that to be possible with a relatively low bandwidth mode like the one you were using.

If you were using a text editor, is it one that hides the mouse pointer when you start typing? If so then there’s a slim chance that could cause it (changes to the video hardware go via shadow registers that the hardware reads at the end of each frame. The current video driver doesn’t make any attempt to avoid updating the shadow registers during the narrow window in which the hardware uses them to update its internal state, so there’s a very slim chance that RISC OS could try changing a video setting at the same time as the hardware updates itself, potentially causing the hardware to see invalid settings and causing the output to fail)

My current theory is that it a heat issue which happens when the operating system spinlocks when the system is already hot. We really need to make the IGEP run either a slower speed, sleep more or stop spins!

To be honest if it’s a heat issue caused by the CPU stressing the system then it’s clearly a design or manufacturing flaw with the board. I’m not sure how much extra heat the 720MHz OMAPs generate compared to the 600MHz ones (Which, in the case of the beagleboard, typically runs at 500MHz), but I’d be surprised if it was reaching the 85 degree temperature that the IGEP is (supposedly) rated for. The only time I’ve had problems with my beagleboard being too hot was when the audio code was attempting to drive the speaker output, causing the TWL to reach 80+ degrees, spreading heat to much of the rest of the board – but apart from the heat and the high power drain the board seemed to be running fine.

Having said that, it would obviously be a good idea to try and stop some of the spinlocking that occurs, as well as introducing some code to control the CPU frequency, and attempt to make better use of Portable_Idle. Portable_Idle does get called automatically by the wimp (IIRC once the frequency of Wimp_PollIdle calls reaches a certain threshold), but I’m not sure if it’s tweaked to the state where it will happily go to sleep for a few centiseconds inbetween individual keystrokes being sent to a text editor.

Alternatively we could try tweating the CPU thermal settings and add this code to the HAL. I’ll maybe look into this once i get this driver finished.

I don’t think there’s any way for software to read the temperature of either the OMAP or the TWL/TPS. They do both contain temperature sensors, but I think the signals are kept internal to the thermal cutoff hardware in the TWL/TPS. The thermal cutoff is also quite high (somewhere above 100 degrees, IIRC) – although I suppose it would be a good idea if we had some way of responding to the “you’re getting too hot” warning that the TWL/TPS sends off before it cuts off the power. But as I say, I’d be surprised if the thermal limits were reached while running at full load in an ordinary environment (i.e. average room temperature).

If I understand correctly, there is no dedicated screen RAM, so all screen refresh data have to be taken from main memory by DMA. Is there any chance that some other process is stopping screen DMA?

Correct, there’s no dedicated screen memory. The only way to stop the screen DMA outright is to turn off the overlay(s). However if there’s too much bus activity, or if the FIFO settings have been set up wrong (as with the first version of the video driver) then a FIFO underflow could occur. Although some FIFO underflows don’t cause any long-lasting problems, other ones can seemingly corrupt the internal state of the controller (this was the cause of the ‘pointer turns into flickering second copy of the desktop bug’ with the first video driver). So whenever the new driver detects that an underflow occurs it follows the recovery procedure outlined in the TRM, which is to reset the display controller (unfortunately I don’t think there’s any way for the driver to determine if an underflow is serious or not, so at the moment it performs the recovery for all underflow occurences). And although I haven’t (yet) been able to deliberately trigger a FIFO underflow with the new driver, a couple of days ago an IGEP user suffering from display cut-outs did show me a video of what looked like a repeatable way of triggering FIFO underflows (or display cut-outs, at least). He opened an image in Private Eye, enlarged the window to full screen, then scrolled it from side to side using the scroll bar. The scroll operations would be accelerated using the video driver, but the current implementation of the algorithm that’s used when moving the scrollbar to the left (and thus moving the image to the right) isn’t able to make use of burst memory reads/writes. This could easily cause the DMA controller to hammer the memory bus, starving the video controller of data.

At the moment there are a few things I can think of that need doing to either solve or help diagnose the display problems. If anyone wants to take a look at what I’ve listed below, let me know and I can go into a bit more detail about what needs doing.

• Improve DebugLib to allow output via HAL_DebugTX, and/or work out what’s wrong with serial output (at the moment the video driver uses the output that’s equivalent to printf, which isn’t that useful if the printf causes the screen to scroll, causing more debug output, etc.) (now done)
• The SDMA priority arbitration value(s) need tweaking.
• Make sure nothing else (e.g. USB) is capable of starving the video DMA. Video (and potentially audio) DMA are the only two that should be high priority!
• Need to investigate ways of rewriting the left-to-right copy code to be faster and not hammer the bus. Splitting into non-overlapping vertical strips might be a good approach; other ones are likely to rely on using an intermediate off-screen buffer and so may not be advantageous. It would be a good idea to write a simple testbed to measure performance of different techniques and check whether any video problems are caused.
• Find a sensible way to eliminate the possibility of the hardware reading invalid register settings
• Add some method for regular ROM builds of the video driver to detect and log FIFO underflows/other hardware errors
• Make sure there aren’t any other error conditions that need to be detected
• I’m not sure offhand if there are any hardware registers to allow you to read the current FIFO levels – but if there are, it could be interesting to add some logging code which polls those every so often to see if any interesting information is revealed. (just checked, no such registers exist)
• Plus 101 other things that could be done to improve power management/heat production Note: OS_ReadC, etc. usually calls Portable_Idle, but a different routine is used if the debug terminal is enabled. Thus when using the debug terminal, power/heat levels when sat idle at a command prompt may be significantly higher.
• And someone with a faulty IGEP could do with using a thermocouple/temperature sensor/etc. to measure the temperature of the key components under different situations :) (i.e. under Linux, which from what I’ve heard so far always works fine, and under RISC OS)
• It may also be interesting to revive the ‘passive video’ code and see if that makes any difference. It would be nice if this could be done in the OMAPVideo module instead of in the old HAL code due to the OMAPVideo code containing the FIFO fixes; although I’m not sure how easy it would be to get working without making the source code a mess.

By “input” I assume you mean typing something into a text editor?

Sorry to be so unspecific ;) Typing into a text editor does it, yes. (!Edit, for example – not hiding the mouse pointer; I don’t think that’s related in this instance.) Just moving the mouse pointer is much less likely to do it, it seems, but resizing a window almost certainly does cause the display to go down. When you stop this ‘input’, the display usually recovers. When it’s misbehaving, it’s basically just a total blanking of the screen, but as it blanks, I think I can see a split second of dodgily synced image.

I’m almost sure this is heat-related, which is sad, because as you say, Jeffrey, that basically means a board fault. And not just a one-off defect, but a flaw in the design. As it doesn’t seem to affect the boards when running Linux, I doubt if we’ll ever persuade ISEE to do anything about it. There’s a chance the new IGEPv2 hardware revision won’t exhibit the same problem, but I’m not overly hopeful about that. I suppose our only hope is to get RISC OS running as cooly (no pun here, I assure you) as Linux does.

The problem is definitely more likely to show up after prolonged periods of use, either pointing to heat or some tiny drift in a clock or PLL signal somewhere. But when it goes wrong, a reboot doesn’t fix it, so it’s got to be heat. Also, given that it doesn’t seem to affect the BB, all fingers are pointing at an inherent design problem with the board.

This thread on the IGEPv2 hardware forum suggests that Linux can get at the OMAP temperature sensor, so there must be a way of probing it somehow. I’ll try to get a thermocouple on it and the TPS in the meantime.

Improve DebugLib to allow output via HAL_DebugTX, and/or work out what’s wrong with serial output (at the moment the video driver uses the output that’s equivalent to printf, which isn’t that useful if the printf causes the screen to scroll, causing more debug output, etc.)

Jeffrey, I didn’t realise there was a problem here. The HAL outputs successfully over the serial, right? What’s stopping the video driver doing the same?

Jeffrey, I didn’t realise there was a problem here. The HAL outputs successfully over the serial, right? What’s stopping the video driver doing the same?

The HAL outputs successfully using its own routines, but I haven’t yet had any luck with getting serial output working via the usual RISC OS methods. Although it has to be said that I haven’t tried very hard to get it working (basically just trying the SERIAL_OUTPUT option in DebugLib), and I’ve never had a particularly great success rate with RISC OS’s serial I/O anyway ;)

Anyway, I’m almost done with adding HAL_DebugTX-based output to DebugLib, so in a little while we should be able to get debug output from the video driver without it messing with the screen output in the process.