RISC OS on IGEPv2

WPB how did you get on with that NIC driver?

Gotta rebuild the ROM first for Jeffrey’s GPIO init code fixes. Box is out of action today, so it’ll have to wait ‘til tomorrow. (Unless anyone feels like uploading the latest OMAP3 ROM somewhere?)

I’ll email you my ROM now. Should really have bundled it with the driver thinking about it.

Is there anything useful I can do to debug this, Jeffrey? If not, I could send you the device if you were interested.

If you look in the OMAP components file then you should see a few commented out lines that build debug versions of the USB modules. Swap those lines for the current ones, and enable the DADebug module (should be a few lines above), and you’ll have working debug versions of the modules. Since the problem you’re encountering occurs at boot, you may need to fiddle with the default debug level a bit in the module initialisation functions. If modules initialise at a rate of one every five seconds, then I’d wager something that tsleep() is waiting on keeps timing out.

If you use the debug terminal, and don’t have any other USB devices connected, then you should hopefully be able to find where it’s getting stuck just by comparing the working log with the non-working log.

I’ve finally added a wiki page with some technical notes about the drivers – hopefully that will provide some more help: https://www.riscosopen.org/wiki/documentation/pages/RISC+OS+5+USB+stack+overview

WPB how did you get on with that NIC driver?

Tried running EtherS briefly tonight. It didn’t want to initialise most of the time and hung after ‘device_start(completed)’. Ctrl-Break worked, though.

I did get it to start up once, and got as far as configuring things ready to try a ping, but then my screen died. Argh! I was capturing the output though. Here it is:

 *ethers
GPMC revision 5.0
NIC BASE Address: f7c00000
device_open
Creating device
Base Address: f7c00000
device_start
PHY:0 = phy[0,1] 0,0
PHY:1 = phy[0,1] 7,c0c3
Found PHY: 1
USING PHY:1 = phy[0,1] 7,c0c3
loopback test: read status 0
loopback test: read status 400000
Successfully verified loopback packet
SCANNING FOR NICs
Claiming the device vector
Activating the device
Activated device: -2147483614
device_start(start interface)
device_start(all interrupts enabled
device_start(MAC_CR 0)
device_start(install callback)
device_start(completed)

*esinfo
EtherS driver for 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          10            RX frames   8           
    TX bytes           589           RX bytes    915         
    TX errors          0             RX errors   0           
    TX queue length    0             RX unwanted 0           
    TX queue overflows 0           

Looks reasonable to me. I’ll give things another go tomorrow once it’s cooled down. Wish we could fix this screen issue!

I’ve finally added a wiki page with some technical notes about the drivers

This is cool. Thanks, Jeffrey. I’ll try to build a USB debug version soon and get back to you. I’m fighting problems with my USB->RS232 converter on Windows. I can receive, but I can’t transmit, so I can’t interrupt U-Boot, for example. Very annoying. Think it has to do with me buying a ridiculously cheap device from Hong Kong! Thinking about it, that’s probably the problem with the USB stick that doesn’t work well, too ;)

Tonight I got another USB (SCSI) error. When trying to copy largish (> 2MB, say) files from USB stick to USB stick, or USB stick to RAM disc, the transfer was starting but then failing with ‘Target error – No sense’. It was completely repeatable. Following the error, I could still copy small files without any trouble. (In other words, nothing had died completely.)

It might be a heat issue again. The screen was starting to die at about the same time. Purely from observation, it definitely seems like a DMA issue brought on by heat. I’ll try copy the same files tomorrow when the system’s cold.

Wish we could fix this screen issue!

Do you know where the source code is for the Linux distribution they use? We could check to see if they’re using the original OMAP video driver (which uses DPLL4 for the pixel clock) or the newer “DSS2” driver (which uses the DSI PLL, like RISC OS). Plus we can check if they’ve got anything to dynamically scale the CPU frequency (although I have a feeling most Linux distros leave the CPU frequency alone and just rely on u-boot to do any relevant setup). There has to be a reason why their code works but ours doesn’t!

Tonight I got another USB (SCSI) error. When trying to copy largish (> 2MB, say) files from USB stick to USB stick, or USB stick to RAM disc, the transfer was starting but then failing with ‘Target error – No sense’. It was completely repeatable. Following the error, I could still copy small files without any trouble. (In other words, nothing had died completely.)

That’s the same kind of thing I’ve seen with one of my USB sticks. On both my Iyonix and Beagleboard, large transfers would fail with the ‘Target error – No sense’ error, but small transfers, interactive filer copies, etc. would work fine (although this was before my SCSISoftUSB optimisations – it’s possible large interactive copies might cause it to fail now as well). I didn’t try and find the cause of the error (it looked like a fairly generic message that could have come from several places in the source code), but I did discover a few weeks ago that reformatting the stick in Windows would fix the problem (it was, and still is, FAT formatted).

I occasionally see this hang issue. I generally run it from the filer as the issue doesnt seem to happen when run from there. I know that the version i sent out doesnt rmkill properly. I traced this to a bug in the EtherUSB/util.c file where LINKEDLIST_REMOVE(s_callback_list, s_callback_list) should be changed to LINKEDLIST_REMOVE(s_callback_list, c)

I’ve no idea why the startup is a bit flakey when run from the commandline. Very odd.

I’ll hunt down that linux code for you in a moment. firing up the beast in linux now. I’ve never seen a single screen issue with linux. I have a small heatsink on my igep now just to smooth out the overheating caused by spins.

I have a small heatsink on my igep now just to smooth out the overheating caused by spins.

Does it help much?

not a huge amount but it does make a difference.. The screen still goes blank but does come back after a second or two. I would love to get rid of the issue to be honest.

For anyone interested i took a chipset heatsink (fanless) and cut it with a hacksaw into 2 rectangular bits. I then cut one of these pieces in half, removed the sticky back label and stuck it onto the sound chip. I wedged the longer piece over the cpu between the NIC socket and the usb port. It helps but its not great.

Ok.. i could be reading this wrong but i think the linux driver uses DPLL4.

it uses the omapdss driver which in the kernel sources i have here (linux-omap-2.6.28.10-igep0020b-1) are in drivers/video/omap2/dss/

the dispc.c file has this struct…

static struct {
        void __iomem    *base;

        struct clk      *dpll4_m4_ck;

        unsigned long   cache_req_pck;
        unsigned long   cache_prate;
        struct dispc_clock_info cache_cinfo;

        spinlock_t irq_lock;
        u32 irq_error_mask;
        struct omap_dispc_isr_data registered_isr[DISPC_MAX_NR_ISRS];
        u32 error_irqs;
        struct work_struct error_work;

        u32             ctx[DISPC_SZ_REGS / sizeof(u32)];
} dispc;

Which isnt conclusive but does suggest dpll4.

Jeffrey,

It would be trivial for me to setup my linux kernel code to print the dispc register reads and writes out to the console during igep boot. At least this would give you an idea of whats going on.

Would this help?

That would be useful, yes – either that or just a register dump once the system is running.

i’ll do the former first. How big is the register window and i could dump it from linux (i think)?

There are a couple of register windows that would be useful. 0×48050040 – 0×4805004C are the main DSS registers and will show whether they’re using DPLL4 or the DSI PLL. 0×48050440 – 0×48050638 are the DISPC registers with the overlay setup, display timings & FIFO setup – there might be something different there if we’re lucky. However I have a feeling that there may be some undefined registers in there which will abort if you try reading them.

jeffrey, I Emailed you with the full read/write dump.

Sorry Jeffrey, i forgot to put in checks for DSS. Adding now and will email.

Looking at this im 99% sure its running dpll4.

[   11.313873] DSS: (REG_READ) REG(0x00000040) VALUE(0x00000000)
[   11.313903] DSS: dss_init has set DSS_CONTROL to 0x00000000
[   11.313934] DSS: (REG_READ) REG(0x00000048) VALUE(0x00000000)
[   11.313934] DSS: dss_init has set DSS_PLL_CONTROL to 0x00000000

Nope – they are using the DSI PLL. They switch to it right at the end, just before they program the mode timings:

[   18.858306] DSS: (REG_WRITE) REG(0x00000040) VALUE(0x00000001)
[   18.865997] DISPC: (REG_WRITE) REG(0x00000070) VALUE(0x00010002)
[   18.873931] DISPC: (REG_WRITE) REG(0x00000064) VALUE(0x02f04f1f)
[   18.881835] DISPC: (REG_WRITE) REG(0x00000068) VALUE(0x00f00303)
[   18.889801] DISPC: (REG_WRITE) REG(0x0000007c) VALUE(0x02ff03ff)

I don’t suppose you could get a dump of the DSI PLL registers? It would save me the hassle of trying to work my way through the source code.

On both my Iyonix and Beagleboard, large transfers would fail with the ‘Target error – No sense’ error, but small transfers, interactive filer copies, etc. would work fine (although this was before my SCSISoftUSB optimisations – it’s possible large interactive copies might cause it to fail now as well). I didn’t try and find the cause of the error (it looked like a fairly generic message that could have come from several places in the source code), but I did discover a few weeks ago that reformatting the stick in Windows would fix the problem (it was, and still is, FAT formatted).

I still have the same problem this morning – I don’t think in this case it’s related to the heat of the chip. I was having the problem with interactive copies, but, as I said, only with large files. I’m still getting the same thing. Interestingly, it’s the same MicroSD card I was using before in a different USB card reader. So the format of the card hasn’t changed. In the one card reader it works fine (but this is the same card reader that makes everything run slowly if plugged in at time of boot), in the other card reader I get these SCSI errors!

Once I get a debug USB version built, maybe I’ll be able to give some more useful debug info! (I hope…)

I’ll get the DSI registers for you this morning.

I dont think the IGEP gets much hotter under RiscOS than it does in linux. Hopefully if we can see what Linux does differently we can solve the screen issue and that will be us sorted.

I just got some patches from James Peacock which should help get this driver a bit more stable. Progress all round. One thing i’d like to see is a sort of sourceforge for riscos where we could centrally keep all the code/bugs/project management.

Hey Stephen. If you get the chance, chuck your updated driver my way and I’ll try using it.