Subject: Re: About cyg_drv_dsr_lock and cyg_drv_cond_wait. - msg#00178

Previous Message by Date: (click to view message preview)

Re: Difficulty finding 82559-based cards

"Paul van Zyl" <pvz@xxxxxxxxxxxxxxxxx> writes: > Hello, please help? > > I am reading the eCos book of Anthony Massa, and am now at chapter11, and > want to set up the development platform with two 82559 based network cards. > I tried to get the Intel PRO/100+ adapter, which has the 82559.(Code > PILA8460B) However, this card has been discontinued by Intel in April 2001, > with Intel recommending the use of the Intel Pro/100S (order code > PILA8460C3) However, the /S does not have an 82559, but rather an 82550. > Several places still advertize the PILA8460B, with the IT sales people > swearing that it will have an 82559 on, but when I order and it arrives, its > got the 82550. (Happened 2x now!) I could not find other suppliers of > 82559-based network cards. Can I use the Pro/100S, or should I order an > industrial motherboard with an 82559 onboard? (At least when you order > something industrial, you get exactly what you have ordered.) > Anything that claims to be an Intel PRO/100 should have a suitable controller on it. I have a PRO/100S which has what purports to be a 82550 on the board. It works fine with both eCos and Linux 82559 drivers. The important thing is the device ID it advertises on the PCI bus. So long as it is one of the values looked for in the device driver it will work. It is possible that a very new device will have an ID that we do not recognize, but the 82550 is already in there. -- Nick Garnett eCos Kernel Architect http://www.ecoscentric.com/ The eCos and RedBoot experts -- Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos and search the list archive: http://sources.redhat.com/ml/ecos-discuss

Next Message by Date: click to view message preview

Re: Debugging from ROM

>>>>> "Rich" == Rich LeGrand <rich@xxxxxxxxxxxxxxx> writes: Rich> I'm not sure if debugging from ROM is something that has Rich> been done very often with eCos and gdb -- perhaps Rich> targets/processors with hardware breakpoints allow this. <snip> Rich> Is this reasonable? It's likely that I've overlooked Rich> something or somethings. Or maybe this has been done Rich> before.. REgardless, any comments would be greatly Rich> appreciated. It is theoretically possible, but not exactly mainstream. When doing software development you don't want to change the contents of the ROM all the time because usually that is much slower than downloading an executable into RAM via a ROM monitor - unless you have special hardware such as a PROM ICE or a gameboy advance linker. Also, although some processors do support facilities like hardware breakpoints these tend to be rather limited, e.g. a maximum of four. I don't know how well gdb would cope with such limitations - remember that some debug operations like single-stepping are also usually implemented via breakpoints. However, it should be possible to get something working by modifying the existing stubs code. If you are thinking of experimenting with this, I would suggest using a dedicated communication channel for gdb traffic - at least initially. Later on you can think about sharing the serial line between gdb and the application. Bart -- Bart Veer eCos Configuration Architect http://www.ecoscentric.com/ The eCos and RedBoot experts -- Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos and search the list archive: http://sources.redhat.com/ml/ecos-discuss

Previous Message by Thread: click to view message preview

About cyg_drv_dsr_lock and cyg_drv_cond_wait.

Hi, The call cyg_drv_dsr_lock is to prevent DSRs running until the call cyg_drv_dsr_unlock is made. One use of cyg_drv_cond_wait is to wait (block) for input from a device. To wake up a thread that is waiting on a condition variable a DSR can call cyg_drv_cond_signal. My question is - A call to cyg_drv_cond_wait in most of the devices (e.g.. serial_read of serial.c) is between the calls cyg_drv_dsr_lock and cyg_drv_dsr_unlock. This happens when a thread is waiting for input from a device, waiting for the corresponding DSR to run. But DSRs can not run because of dsr_lock. How is this happening? My analysis may be missing something, what is that? Thanks in advance, chandra -- Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos and search the list archive: http://sources.redhat.com/ml/ecos-discuss

Next Message by Thread: click to view message preview

Difficulty finding 82559-based cards

Hello, please help? I am reading the eCos book of Anthony Massa, and am now at chapter11, and want to set up the development platform with two 82559 based network cards. I tried to get the Intel PRO/100+ adapter, which has the 82559.(Code PILA8460B) However, this card has been discontinued by Intel in April 2001, with Intel recommending the use of the Intel Pro/100S (order code PILA8460C3) However, the /S does not have an 82559, but rather an 82550. Several places still advertize the PILA8460B, with the IT sales people swearing that it will have an 82559 on, but when I order and it arrives, its got the 82550. (Happened 2x now!) I could not find other suppliers of 82559-based network cards. Can I use the Pro/100S, or should I order an industrial motherboard with an 82559 onboard? (At least when you order something industrial, you get exactly what you have ordered.) Thanks Paul van Zyl -- Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos and search the list archive: http://sources.redhat.com/ml/ecos-discuss