GigE NIC (Was: Who is RobertF?)

Joel Sherrill joel.sherrill at OARcorp.com
Tue Nov 25 18:39:51 UTC 2008


Till Straumann wrote:
> Robert Fu wrote:
>   
>> Hi Joel,
>>  
>>     
>>> Which GigE NIC is it?
>>>       
>>  
>> Realtek RTL8111C is on the kit I'm interested most, and Intel 82574L 
>> is on
>> other kits I'm also interested. I really wish they were supported in 
>> RTEMS.
>>     
> I have a port of intel's 'em-6.5.3' covering many intel GigE chips but the
> 82574L is not among them. Shouldn't be very hard to port their latest
> FreeBSD driver. em-6.9.5 seems to support the 82574L.
>   
Till.. we missed getting your ported drivers into 4.9.  Can we
take a stab at merging them now? 

It will likely be easier for someone to at least update to the
latest from there.

--joel
> FWIW
> -- Till
>   
>> As I mentioned before, for new hardware kits with this kind of gigabit 
>> ethernet cards
>> and without GPIO, it seems that serial port becomes the only supported 
>> bi-directional
>> link that can be used to interact with external systems. I think 
>> that for most cases,
>> a RTOS must be able to retrieve information from external systems, and 
>> present
>> processing result back to external systems, otherwise there is no need 
>> for such
>> RTOS+Hardware. Due to limited capability of serial ports, coping with 
>> only serial
>> communication is not a good situation.
>>  
>> Thanks a lot,
>> Robert Fu
>>
>>
>>     
>>> Date: Mon, 24 Nov 2008 09:52:30 -0600
>>> From: joel.sherrill at oarcorp.com
>>> To: wendell.silva at compsisnet.com.br
>>> CC: robert.fu at live.com; rtems-users at rtems.org
>>> Subject: Re: RES: RES: Who is RobertF?
>>>
>>> Wendell Pereira da Silva wrote:
>>>       
>>>> *De:* Robert Fu [mailto:robert.fu at live.com]
>>>> *Enviada em:* sábado, 22 de novembro de 2008 17:19
>>>> *Para:* Wendell Pereira da Silva
>>>> *Cc:* rtems-users at rtems.org
>>>> *Assunto:* RE: RES: Who is RobertF?
>>>>
>>>>
>>>>
>>>> Hi Wendell,
>>>>
>>>> Thanks a lot for your information about VMWare. It increases my
>>>> confidence about VMWare.
>>>>
>>>>
>>>>         
>>> Although they haven't spoke up, I know of another project that is 
>>>       
>> doing all
>>     
>>> development inside VMWare. This lets all team members have exactly
>>> the same host environment. When there are tool upgrades, a new OS
>>> image is released and everyone switches to it.
>>>       
>>>> In your short message, you actually mentioned something interested to
>>>> me. Using Google translator, I briefly browsed COMPSIS website. With
>>>> 19 years of history, I guess COMPSIS is a big company with a lot of
>>>> resource and is involved in activities important to your country. I'm
>>>> new to RTEMS, and have very limited resource: just some spare time
>>>> outside working hours and limited personal funding, so I'll need a 
>>>>         
>> lot
>>     
>>>> of help from RTEMS community on various RTEMS issues down the road.
>>>>
>>>>
>>>>
>>>> Not at all. J
>>>>
>>>>
>>>>
>>>> Limited available resource is one of the reasons I'm using VMWare 
>>>>         
>> now.
>>     
>>>> In the past I abandoned some hardware (a waste to already limited
>>>> funding), either after finding out it's unsuitable or outdated due to
>>>> the limited time I can work on it. This time I hope using VMWare 
>>>>         
>> first
>>     
>>>> can help me avoid some of such costs. For example, like you mentioned
>>>> about 2 UARTs, since I already use one UART for remote debugging, I
>>>> better select hardware kit with more than 2 UARTs (for sensor
>>>> interface). Now with Eclipse plug-in and GDB working in my
>>>> environment, I plan to shift focus to hardware part.
>>>>
>>>>
>>>>
>>>> Although RTEMS currently does not support the gigabit ethernet on the
>>>> hardware kit that I have in mind, I'm still interested in how you 
>>>>         
>> made
>>     
>>>> GDB server interface via TCP/IP work in RTEMS. To my understanding,
>>>> RTEMS is a system with single process, and GDB server is another
>>>> process, so how do you launch GDB server in RTEMS?
>>>>
>>>>         
>>> It runs as a thread. There is another way of doing things using CEXP
>>> and dynamic loading
>>> of your application. This ends up working a lot like people are used to
>>> with VxWorks.
>>>
>>> Network drivers are often ported over from NetBSD or FreeBSD since the
>>> RTEMS TCP/IP
>>> stack is an old FreeBSD one. Till Straumann has mentioned having a
>>> kit/procedure for
>>> making this moderately painless.
>>>
>>> Which GigE NIC is it?
>>>       
>>>> Robert, what we did was a custom implementation of a GDB Server
>>>> interface inside SIS (SPARC Instruction Simulator) through a TCP/IP
>>>> socket. So the RTEMS program (running on the SIS) is not aware about
>>>> this interface. RTEMS already has a glue code to implement the GDB
>>>> interface for some targets, including i386, but not for SPARC 
>>>>         
>> processors.
>>     
>>>> You also mentioned GPIO simulation with PC's parallel port. For the
>>>> hardware kits I have in mind, some have 4-bit In/4-bit OUT GPIO, some
>>>> don't. I checked Discrete Driver chapter in RTEMS BSP and Device
>>>> Driver Development Guide. There are descriptions about the driver, 
>>>>         
>> but
>>     
>>>> no concrete example code is given. Do you know where I can find 
>>>>         
>> such a
>>     
>>>> concrete example? Also in 
>>>>         
>> c\src\lib\libbsp\i386\shared\comm\i386_io.h,
>>     
>>>> there some macros like outp(port, val) and inp(port) calling assembly
>>>> code directly. May such macros be used to access GPIO pins directly
>>>> without using the discrete driver?
>>>>
>>>>
>>>>
>>>>         
>>> The RTEMS powerpc gdb has psim which can map UNIX shared memory into
>>> simulated PowerPC
>>> processor address space. When using this, you can do all IO into shared
>>> memory and let a UNIX
>>> process mirror IO in and out.
>>>
>>> --joel
>>>       
>>>> In the same way, we implemented the GPIO code inside SIS. That is,
>>>> when the RTEMS program access the address of the GPIO registers it
>>>> redirects such access to the PC’s parallel port mapped through VMWare.
>>>>
>>>> Thanks a lot for your help, and have a nice weekend!
>>>>
>>>>
>>>>
>>>> No problem.
>>>>
>>>>
>>>> Robert Fu
>>>>
>>>> Wendell.
>>>>
>>>>
>>>>
>>>>
>>>>         
>> ------------------------------------------------------------------------
>>     
>>>> Subject: RES: Who is RobertF?
>>>> Date: Fri, 21 Nov 2008 11:01:15 -0300
>>>> From: wendell.silva at compsisnet.com.br
>>>> To: robert.fu at live.com
>>>> CC: rtems-users at rtems.org
>>>>
>>>> Hi Robert Fu,
>>>>
>>>>
>>>>
>>>> This is just to complement your information.
>>>>
>>>> Here, at COMPSIS (Brazil), our development environment includes 
>>>>         
>> VMWare
>>     
>>>> 6.0 playing Fedora 7, RTEMS 4.8.0, Eclipse 3.3 CDT and a customized
>>>> (home made) version of SIS (with GPIO emulation with the PC’s 
>>>>         
>> parallel
>>     
>>>> port and a GDB Server interface via TCP/IP – which allow us to use
>>>> both UARTs to run our protocols). Everything has worked very well
>>>> since its implementation (6 month ago). VMWare have worked very well
>>>> in Windows Vista 32 in our case. None of our problems (in the
>>>> beginning) wasn’t regarding to the VMWare.
>>>>
>>>>
>>>>
>>>> Att.
>>>>
>>>> Wendell P. Silva.
>>>>
>>>>
>>>>
>>>>
>>>>         
>> ------------------------------------------------------------------------
>>     
>>>> *De:* rtems-users-bounces at rtems.org
>>>> [mailto:rtems-users-bounces at rtems.org] *Em nome de *Robert Fu
>>>> *Enviada em:* sexta-feira, 21 de novembro de 2008 04:33
>>>> *Para:* daronchabot at gmail.com
>>>> *Cc:* rtems-users at rtems.org
>>>> *Assunto:* RE: Who is RobertF?
>>>>
>>>>
>>>>
>>>> Hi Daron,
>>>>
>>>> Thanks for clarify Option --enable-rdbg and --enable-rtems-debug.
>>>> The RTEMS version I used is 4.9.0. I'm not sure if the problem has
>>>> anything to do with VMWare, or some of my heap configurations
>>>> were not right. I'll keep eye on it in the future.
>>>>
>>>> Thanks,
>>>> Robert Fu
>>>>
>>>>         
>>>>> From: daronchabot at gmail.com
>>>>> Subject: Re: Who is RobertF?
>>>>> Date: Thu, 20 Nov 2008 07:10:53 -0600
>>>>> To: robert.fu at live.com
>>>>> CC: rtems-users at rtems.org
>>>>>
>>>>>
>>>>> On 20-Nov-08, at 4:24 AM, Robert Fu wrote:
>>>>>
>>>>>           
>>>>>> Hi Jeol,
>>>>>>
>>>>>> It's me. Last night I uploaded screen shots while 
>>>>>>             
>> writing/previewing
>>     
>>>>>> "RTEMS Eclipse Plug-In" wiki page. Although some files were 
>>>>>>             
>> uploaded,
>>     
>>>>>> error page (HTTP 500 Internal Server Error or Could not create
>>>>>> directory)
>>>>>> came up for almost every uploading, and later I could not access
>>>>>> the wiki site.
>>>>>>
>>>>>> I developed an Eclipse plug-in for RTEMS 
>>>>>>             
>> (http://www.rtems.com/wiki/
>>     
>>>>>> index.php/RTEMS_Eclipse_Plug-in).
>>>>>> Please take a look. I'm new to RTEMS, and also new to Eclipse 
>>>>>>             
>> plug-in
>>     
>>>>>> development. This is the 1st plug-in that I ever developed. So 
>>>>>>             
>> please
>>     
>>>>>> be patient if you encounter problems while using it.
>>>>>>             
>>>>> Well done! Thanks for your contribution.
>>>>>
>>>>> However, as Sebastian pointed out the plugin is not accessible 
>>>>>           
>> on the
>>     
>>>>> FTP site. I'd really like to check out your work.
>>>>>
>>>>>           
>>>>>> While working on the GDB part of the plug-in, I initially used --
>>>>>> enable-rdbg in
>>>>>> configure. Later I found --enable-rtems-debug was mentioned in a
>>>>>> wiki page.
>>>>>> When I used both --enable-rdbg and --enable-rtems-debug in
>>>>>> configure, during startup
>>>>>> my application hang at "_HAssert(_Heap_Is_prev_used
>>>>>> ( next_block ));" in
>>>>>> cpukit\score\src\heapsizeofuserarea.c. I went back to use 
>>>>>>             
>> --enable-
>>     
>>>>>> rdbg. So my
>>>>>> question is: which configure option should be used to enable 
>>>>>>             
>> remote
>>     
>>>>>> debugging?
>>>>>>             
>>>>> Option --enable-rdbg is the one to use to enable remote debugging.
>>>>>
>>>>> Option --enable-rtems-debug activates some instrumentation within
>>>>> RTEMS itself (malloc statistics at least...).
>>>>>
>>>>> I use both switches simultaneously and have not seen the problem you
>>>>> reported. What version of RTEMS are you using ??
>>>>>
>>>>>
>>>>> -- dc
>>>>> _______________________________________________
>>>>> rtems-users mailing list
>>>>> rtems-users at rtems.com
>>>>> http://rtems.rtems.org/mailman/listinfo/rtems-users
>>>>>           
>>>>         
>> ------------------------------------------------------------------------
>>     
>>>> Get more done, have more fun, and stay more connected with Windows
>>>> Mobile®. See how. <http://clk.atdmt.com/MRT/go/119642556/direct/01/>
>>>>
>>>>
>>>>
>>>>
>>>>         
>> ------------------------------------------------------------------------
>>     
>>>> Color coding for safety: Windows Live Hotmail alerts you to 
>>>>         
>> suspicious
>>     
>>>> email. Sign up today.
>>>>
>>>>         
>> <http://windowslive.com/Explore/Hotmail?ocid=TXT_TAGLM_WL_hotmail_acq_safety_112008%20>
>>     
>>> --
>>> Joel Sherrill, Ph.D. Director of Research & Development
>>> joel.sherrill at OARcorp.com On-Line Applications Research
>>> Ask me about RTEMS: a free RTOS Huntsville AL 35805
>>> Support Available (256) 722-9985
>>>
>>>
>>>       
>> ------------------------------------------------------------------------
>> Access your email online and on the go with Windows Live Hotmail. Sign 
>> up today. 
>> <http://windowslive.com/Explore/Hotmail?ocid=TXT_TAGLM_WL_hotmail_acq_access_112008> 
>>
>> ------------------------------------------------------------------------
>>
>> _______________________________________________
>> rtems-users mailing list
>> rtems-users at rtems.com
>> http://rtems.rtems.org/mailman/listinfo/rtems-users
>>   
>>     
>
>   


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





More information about the users mailing list