Ethernet Driver

[Joel Sherrill <joel@OARcorp.com>]

Doyle, Bryon Thomas (Bryon) wrote:
> Hello, Thanks for clearing up the issue on old vs. new
 > exception handling. I think the problem is with the stack
 > overrunning its boundaries; when we initially loaded RTEMS
 > onto our board we had to make several adjustments to the
 > underlying boot monitor program in order for RTEMS to properly
 > run. I think perhaps RTEMS is configured to use more ram
 > than actually is on the board, or possibly conflicting with
 > the space reserved for the boot monitor program. I was
 > wondering where RTEMS's memory map is defined, more specifically
 > where are the RAM boundaries defined?

The BSP's linkcmds in startup.  You can define the memory map
to stay away from any memory that the ROM monitor uses.  I know
that is a common issue.  MVMEBug and PPCBug tend to reserve some
RAM that you have to avoid.

> Also, I was wondering exactly what it means when a 
 > "host unreachable" error is produced, because I get
 > those errors during the initialization of the Routing Table
 > prior CPU crashing. Both the send and receive tasks start up
 > and block waiting for an event from the ISR routine, then
 > the error message comes up. I'm assuming there may be a
 > problem in my send packet function since RTEMS says
 > it is unable to talk to the network.

Grep the source and see precisely what trips it but
likely it is a misconfigured route.  Try to put
ethereal on the connection and see if a packet of any
sort leaves the board.

> In response to your other question I have the UART 
 > running on the board for terminal output to my PC as
 >  well as a BDI2000 for JTAG debugging.

If the serial port is not polled, then interrupts for
it are working.  It must then just be a matter of
properly handshaking the eth one.

> Thanks Again and any help is greatly appreciated.
> 
> Bryon Doyle
> Bell Labs Summer Intern
> Lucent Technologies
> 
> 
> -----Original Message-----
> From: Thomas Doerfler (nt) [mailto:Thomas.Doerfler at imd-systems.de]
> Sent: Friday, July 22, 2005 1:41 PM
> To: Doyle, Bryon Thomas (Bryon)
> Cc: rtems-users at rtems.com
> Subject: Re: Ethernet Driver
> 
> 
> Hi,
> 
> if you look at the gen68360 BSP (m68k architecture, always using the old
> exception handling), you will see that ethernet is "compatible" with
> both exception handling methods. The API of the two exception handling
> models differs, but I think you are aware of this.
> 
> The crashes of your CPU can have a lot of reasons. Since the LED on your
> board is on, you might experience a "checkstop" condition, which means,
> you get an exception while the processing of machine check exceptions is
> disabled. Typically this is caused by a stack overrun or a severe bug in
> the exception handling code.
> 
> Where is the interrupt line of the ethernet controller connected to? And
> what kind of debugging capabilities do you have on this board
> (JTAG/UART/LEDs/???).
> 
> wkr,
> Thomas.
> 
> 
> Doyle, Bryon Thomas (Bryon) schrieb:
> 
>>Hello, Over the past week or so my task has been to add Ethernet functionality to the CSB472, a slightly modified version of the gen405 BSP package. I have created an Ethernet driver using other RTEMS Ethernet drivers and a Ethernet driver for the board that was designed for another RTOS. The problem that I am having now I believe is with the exception handling; I know that the gen405 BSP is still using the old exception handling model, and from looking around in the other BSP that also still uses the old exception handling model I see that it does not offer Ethernet support.  My question is can the old exception handling model support the burden of an Ethernet driver? I am inclined to think so, but the absence of any other BSP that uses old exception handling and has an Ethernet driver built in, begs me to ask the question. Also I have traced through the initialization of my driver and RTEMS crashes with a CPU error (SYSERR LED on the board lighting up, which I believe is
> 
>  m!
> 
>> apped to several machine check exception's happening back to back) as soon as the Ethernet interrupts are enabled through the universal interrupt controller. Which leads me to think that the problem is somewhere within the RTEMS exception handling code.  If anybody has any insight it would be greatly appreciated, thanks again.
>>
>>
>>
>>Bryon Doyle
>>Summer Intern, Bell Labs
>>Lucent Technologies
> 
> 
> 


-- 
Joel Sherrill, Ph.D.             Director of Research & Development
joel at OARcorp.com                 On-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
    Support Available             (256) 722-9985