RISC OS on IGEPv2

Well you can always do like me and install a fan on you IGEP. I havent had any problems since then.

Just to add my 2 pence… I find that the video drivers fail to initialise around 1 in 4 times i do a full poweroff/poweron. I can see that Module_Init has been called from the serial output but the machine seems to be stuck in a hang.

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.

After doing a bit of digging, it looks like the CPU-readable temperature sensor may only be present on OMAP34xx devices, not 35xx. The 35xx TRM makes a few vague references to temperature sensing, but the copy of the 34xx TRM I’ve got goes into much more detail and explains the feature fully. However, after going through the programming sequence on my beagleboard, it looks like the temperature sensor is returning plausible values (~54 degrees while the debug terminal hammers Debug_RX)

To save people tracking down the relevant info, here’s something quick and dirty for you to try:

*memorya p 48004a08 6
*memorya p 48002524 100
*memorya p 48002524 0

If it worked, the last *memorya should display a message similar to ”... altered to &000000XX”, where XX is the ADC value. There’s a big table in the 34xx TRM listing how the ADC values map to temperatures, but for ADC values between &05 and &7A it looks like it’s an almost exactly linear mapping from -40 degrees to +125 degrees. Note that the ADC value is 7 bit; if bit 7 is set then it means the ADC is still busy and you may have to examine the memory again (it looks like the sensing should take about 54 clock cycles of the 32kHz clock, so if you run the above from a script then I guess there’s a chance it’ll be too quick for the result to be ready)

If you fancy a 35MB download, then it looks like the latest 34xx TRM is available on this page. The section to look at is 7.4.6, “Band Gap Voltage and Temparature sensor”, along with the details for the CM_FCLKEN3_CORE register to enable the clock to the temperature sensor. Interestingly the OMAP35xx TRM does list the register as having the required EN_TS bit, so maybe it’s just an oversight that the temperature sensor details are missing from the rest of the manual (especially since it seems to work fine on my board).

Just to add my 2 pence… I find that the video drivers fail to initialise around 1 in 4 times i do a full poweroff/poweron. I can see that Module_Init has been called from the serial output but the machine seems to be stuck in a hang.

That’s a problem I see myself sometimes – although the machine shouldn’t hang (the startup beep should still be audible, and keyboard LED’s, etc. should continue to respond). The video driver receives the “synclost” IRQ that indicates a FIFO underflow or other problem has occured, but the reset-and-reprogram action doesn’t seem to resolve the issue. I’ve tried adding some delays to various places to see if it’s a timing specific thing, but it doesn’t seem to have fixed it. However the current reset code merely resets the video controller using the reset bits; it may be worth going one step further and turning the power off and on again in the PRCM (you’d need to tweak the relevant HAL code a bit if you wanted to try this, e.g. implement VideoDevice_Deactivate)

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.

This stuff is now in CVS. I’ve also updated the components file to enable video debugging by default, which should hopefully increase the chances of something useful being discovered. Also although I didn’t mention it here at the time, the wiki’s now been updated for the new HAL device stuff, and with the OMAP HAL overview (this this and this being the main bits)

Also, for people looking into power/heat stuff – Portable_Idle won’t get called by OS_ReadC if the debug terminal is enabled, so power consumption when sat idle at a command prompt is likely to be higher than normal. If this increased power consumption is a serious problem then it may be possible to rework the code, but it might not be particularly easy to get a solution that works well with the current HAL_DebugRX interface.

•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.

Thinking about this point further, I’ve realised that the simplistic sdma_sync() implementation could cause problems as well. At the moment it just sits in a loop polling the DMA status, which could easily add a lot more load to the bus depending on how large the DMA operation was and how long RISC OS waits until asking for synchronisation. Changing the code to use interrupts and WFI could be a big help (although the extra overhead would hurt the performance of small transfers).

Just like to confirm that when accidentally overpolling the rx fifo port on the igep’s NIC i get graphics glitches.

NIC driver update: I’m currently having issues receiving data. I think havent got the MAC/PHY talking to each other properly. more soon

Minor update. Not had so much time to work on this this week but i’ve managed to get the link/data LEDs working nicely. This is useful as I can then see whats happening. I’m still not seeing any RX’d packets at the receiver so i think i may need to see what linux actually sends to the phy during setup. I’ll get this setup later tonight.

Also, when i rmreinit i get a ”% in module name” error. Any ideas what this is about?

To save people tracking down the relevant info, here’s something quick and dirty for you to try:

I tried this and got &3E and &3F as values (between 42 and 45 degrees C according to the datasheet). Doesn’t sound overly hot to me, but the display was really losing it.

Jeffrey, I can’t for the life of me figure out what register the 48004108 is. Is it something to do with configuring the L4 interconnect? If you could point me to the right place in the TRM, that would be great.

Jeffrey, I can’t for the life of me figure out what register the 48004108 is. Is it something to do with configuring the L4 interconnect? If you could point me to the right place in the TRM, that would be great.

It’s the CM_FCLKEN3_CORE register in the PRCM. A quick search through the manual should find it :)

It’s the CM_FCLKEN3_CORE register in the PRCM. A quick search through the manual should find it :)

Found that one (bit 1, EN_TS being the pertinent field), but isn’t it at 48004A08, not 48004108, or are there multiple instantiations?

Ah, that’s possibly just a typo on my part then.

Ah, that’s possibly just a typo on my part then.

No worries. At the moment, given my unfamiliarity with the 3.5k page TRM (!), the chances of me misreading something are a lot higher than you making a typo, so I thought it best to check!

So it seems that my reports of 42-45 degrees a couple of posts ago where done in the absence of the BGAPTS module’s clock being enabled! That’s a bit odd. Maybe on the OMAP35xx, it’s always running, and doesn’t need to explicitly be enabled?

Having tried again with the correct CM_FCLKEN3_CORE register address, I got 30-32 deg C when I first switched on, and then about 30 mins. later, after minimal activity, the screen started to flicker on and off, and the same procedure gave me 45-46 deg C. That’s at least a decent size temperature jump to be a believable cause of problems.

Its alive! RX-ing packets. Now to string it all together.

Its alive! RX-ing packets. Now to string it all together.

Great stuff, Stephen! Well done. Was it a MAC - PHY interconnection problem like you thought?

It seems you need to tx at least one loopback packet during setup before you can accept incoming packets. rather odd. there may be a workaround but for now im happy.

Had to stop testing last night but i hope to get the card pinging in a polling mode tonight. Then i’ll start working on reliablity/interrupts. Its been too much to try and debug interrupts and the card at the same time so i’ve basically got the module doing polling on the read_state() callback. Cant work like that when we run it for real but its a good way to debug.

I’ll need an alpha tester next week. I presume WPB will volunteer?

Hooray! Here is another tester if you need one.

Stephen, congratz!

nice to see all this work being done on the second OMAP based development board.

Stephen, for sure I’ll help with testing. Just let me know when you’re ready to hand something off to me.

I have managed to see properly formed ping packets from the igepv2 internal nic. I think i still have an rx packet parsing issue. more soon

Status: driver working but pretty unstable.

I’m going to email a version to WPB.

Release notes:

Basically this version doesnt use interrupts at all. it polls the rx and tx buffers on the read state callback so latency is hellish. There is no support for large packets. Receiver is jammeed in promiscous mode (havent worked out how to turn that off yet) It seems most stable if you click EtherS from the filer window then configure via a task window. rmkill causes a data transfer abort problem.

Little demo of our baby working….

*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: AC:DE:48:00:02:54
  Link status:      Up, Unknown, full duplex, correct polarity
  Controller mode:  Promiscuous

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

  Statistics summary:
    TX frames          80            RX frames   71          
    TX bytes           7353          RX bytes    10404       
    TX errors          0             RX errors   0           
    TX queue length    0             RX unwanted 0           
    TX queue overflows 0           
Warning unit 72 has no backend
*ifconfig -a
lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> mtu 16384
        inet 127.0.0.1 netmask 0xff000000 
es0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
        inet 192.168.0.22 netmask 0xffffff00 broadcast 192.168.0.255
        ether ac:de:48:00:02:54 
*ping 192.168.0.2
PING 192.168.0.2 (192.168.0.2): 56 data bytes
64 bytes from 192.168.0.2: icmp_seq=0 ttl=64 time=659.529 ms
64 bytes from 192.168.0.2: icmp_seq=1 ttl=64 time=1660.154 ms
64 bytes from 192.168.0.2: icmp_seq=2 ttl=64 time=685.941 ms

--- 192.168.0.2 ping statistics ---
4 packets transmitted, 3 packets received, 25% packet loss
round-trip min/avg/max = 659.529/1001.874/1660.154 ms
*ping <a href="http://www.google.com">www.google.com</a>
ping: unknown host <a href="http://www.google.com">www.google.com</a>
*arp -a
? (1.255.255.255) at (incomplete)
? (192.168.0.2) at 0:1c:c0:b4:dd:85
? (192.168.0.255) at (incomplete)

and one of linux pinging our riscos box…

$ ping 192.168.0.22
PING 192.168.0.22 (192.168.0.22) 56(84) bytes of data.
64 bytes from 192.168.0.22: icmp_seq=1 ttl=255 time=1069 ms
64 bytes from 192.168.0.22: icmp_seq=2 ttl=255 time=70.1 ms
64 bytes from 192.168.0.22: icmp_seq=3 ttl=255 time=1069 ms
64 bytes from 192.168.0.22: icmp_seq=4 ttl=255 time=62.7 ms
64 bytes from 192.168.0.22: icmp_seq=5 ttl=255 time=1060 ms
64 bytes from 192.168.0.22: icmp_seq=6 ttl=255 time=52.7 ms
--- 192.168.0.22 ping statistics ---
7 packets transmitted, 6 received, 14% packet loss, time 6018ms
rtt min/avg/max/mdev = 52.704/564.190/1069.623/502.348 ms, pipe 2

As you can see our ping times are quite high. I’ll get things a bit more stable then i’ll start work on getting interrupts working.

I’ve managed to use sunfish to transfer files from my linux server with the IGEPv2 internal NIC. It was very very slow but it worked.

Congrats :-)