Ethernet subsystem programming issues on the OMAP-L137 EVM

Steve,

The ARM and DSP have equal write access to the EMAC registers so there should be no programming differences there.  However, you may want to check the SYSCFG->SUSPSRC register to see which CPU has emulation halt control over the EMAC module.  If the DSP is the suspend source for EMAC and the DSP is halted in CCS, the EMAC module will also remain halted.  You can address this in one of three ways:

1. Update the suspend source to ARM, or
2. Free-run the DSP in CCS, or
3. Set the EMAC emulation setting to FREE run

This applies to any other peripheral that supports emulation halt too.

-Tommy

Hi Tommy -

And thanks! OK -- tried setting the FREE bit of EMAC->EMCONTROL after resetting the EMAC. Didn't help. Feel the issue is related to this as the code is so similar. Have also stepped through the code in case there are timing issues since there are spin loops that may differ a lot between the DSP and the ARM. This made no difference either.

Any ideas - or someplace I can get know code specific to the OMAP-L137. I'm not sure if there is a working Linux for this platform - and to be honest looking for something easier to sift through...

Is there a possibility of the NDK for the ARM around and available?

Any help is appreciated - be stuck here for awhile. Had a similar issue with an OMAP-L138...

Thanks for your time and effort,

Steve Speier

Steve,

There is a MontaVista linux build that is included with the OMAPL137 EVM that supports ethernet.  UBOOT also has ethernet support.

I'm still confused as to why your setup is not working.  The EMAC module is agnostic about who is writing to its registers.  I see that I2C is also used to configure the EMAC PHY too.  Perhaps that module is halted with DSP too.  To simplify things, can you change the entire SUSPSRC register to be ARM-controlled (*0x01C14170 &= 0xE400ED80) and/or free-run the DSP?

-Tommy

Hi (again!)Tommy,

Yeah -- I'm really puzzled by this one. Have also had the same thing happen on the OMAP-L138, but I simply pushed on to the OMAP-L137 because I needed to anyway - plus was wondering if it would behave the exact same way. Which it has. On the OMAP-L138 the ARM boot 1st and there shouldn't be the same issues in regards to suspend...

I did set SYSCFG->SUSPSRC in the DSP UBL before transferring all control to the ARM. Also I simply keep the DSP in a tight loop - as it will be doing work after the ARM setups a bit more. This didn't seem to help. Also the SYSCFG registers are left unlocked by the UBL and so guessing certain changes should be taking affect. I know a bit about that - locked the kick registers at 1st and had failures in the bootstrap...

I tried to force a ARM GEL file init shortly after ARM app startup in CCS thinking it might provide something missing. No go there...

Also wanted to mention en passant that I couldn't get the UART to initialize in work I had done much earlier on the ARM. Thought it odd since I was using the same code as written for the DSP BSL - all that the board folks provide. I *didn't* verify if that code worked on the DSP, and now wondering if it has the same issues as the EMAC/PHY system(?) If there isn't some systemic issues... I really feel there is some setup missing. The initialization of the peripheral system is the same. I've had no trouble with the timer and the AINTC. Should mention that I'm using CodeSourcery EABI for the ARM code...

Will look into MontaVista linux code. Have seen a bit of UBOOT. Have more than 1 EMAC/PHY initialization routine borrowing from all I've read -- code and docs. Best I've been able to do is get an ethernet packet to write and loopback at the EMAC level. Have never been able to get an ethernet packet or loopback at the PHY...

Any thoughts are most welcome! Thanks for your time and effort,

Steve Speier

Steve,

I just thought of something.  Are you putting the ARM into the supervisor privilege mode?  I think the CCS ARM library puts the ARM in user mode by default so you won't be able to write to most of the SYSCFG registers.

-Tommy

Hi Tommy,

Thanks - actually do leave the ARM in a privileged state from booting up. Did finally seem to get it the ethernet problem fixed. I say that a bit preliminarily, but I do see ethernet packet reception and so thinking the rest will work. Will post further too...

The problem was a Spectrum Digital 137 EVM specific: You need I2C0 to write to an onboard Micrel ethernet switch. This was in black & white in the board reference (on schematic too) and missed this. After configuring pinmux register 8 correctly for I2C0_SCL and I2C0_SDA that particular piece of hardware gets configured and everything seems to be working. The EMAC, MDIO, PHY all come up using the standard documented procedures...

Thanks for all of the advice (suspend mastering, etc.), as that has been incorporated and the bootstrap all the better for it...

As mentioned I will make one more post to tie up loose ends - should be Hollywood Happy Ending right? :-)

Thanks again for all the help!

Steve Speier