RE: [ECOS] "packets eaten" with AT91 EMAC Ethernet driver

RE: [ECOS] "packets eaten" with AT91 EMAC Ethernet driver

[Lambrecht Jürgen]

> -----Original Message-----
> From: Andrew Lunn [mailto:andrew@lunn.ch]
> Sent: maandag 9 juni 2008 17:32
> To: Lambrecht Jürgen
> Cc: ecos-discuss@ecos.sourceware.org; I-Yanaslov
> Subject: Re: [ECOS] "packets eaten" with AT91 EMAC Ethernet driver
> 
> On Mon, Jun 09, 2008 at 05:19:02PM +0200, J?rgen Lambrecht wrote:
> > Hello,
> >
> > Since I solved the bugs in the AT91 EMAC driver
> > (RX: reset of ?bytes_in_list? (position in current sg_list))(TX: at
> > TXERR IRQ, reset SW pointer; set all used bits to 0 instead of 1),
> > I always had the same problem: after a while of communicating over
> > Ethernet with the AT91 EMAC, packets get ?eaten?.
> >
> > TX Packets get stuck, and they need an RX packet to get out.
> 
> It sounds like missed interrupts, or a race condition in the interrupt
> handling.
Yes indeed.
The original driver does not mask interrupts at the start of the ISR and unmask them at the end of the DSR.
Is it correct that this mask/unmask is not needed because it is an internal interrupt and at the end of the ISR 'cyg_interrupt_acknowledge(vector)' is called - this acknowledge clears the interrupt? So this should be ok.

Maybe there is a sort of race condition with can_send()?


> 
> You might be interested in looking at the Linux drivers/net/macb.c
> file. This is i think the Linux driver for the EMAC. It might give you
Indeed. I'll do.

> some clues. It is interesting that they initialize all the TX buffers
> as being used, the opposite to what you do.

Yes, the original driver did the same.
But the datasheet (section 36.4.1.3 for SAM9260 vG and 37.4.1.3 for SAM7 vG point 2) is clear about this. 
I actually think it is an error in the datasheet, because my driver causes an "error" (TXERR IRQ with BEX (buffers exhausted)). With all TX buffers marked being used (original driver), you only get an UND (underrun) "warning" (UND in TSR is set, but no TXERR IRQ).
But Atmel will have to clarify this.
> 
>      Andrew

Thanks,
Jürgen

--
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

Re: [ECOS] "packets eaten" with AT91 EMAC Ethernet driver

[Jürgen Lambrecht]

Lambrecht Jürgen wrote:
>   
>> -----Original Message-----
>> From: Andrew Lunn [mailto:andrew@lunn.ch]
>> Sent: maandag 9 juni 2008 17:32
>> To: Lambrecht Jürgen
>> Cc: ecos-discuss@ecos.sourceware.org; I-Yanaslov
>> Subject: Re: [ECOS] "packets eaten" with AT91 EMAC Ethernet driver
>>
>> On Mon, Jun 09, 2008 at 05:19:02PM +0200, J?rgen Lambrecht wrote:
>>     
>>> Hello,
>>>
>>> Since I solved the bugs in the AT91 EMAC driver
>>> (RX: reset of ?bytes_in_list? (position in current sg_list))(TX: at
>>> TXERR IRQ, reset SW pointer; set all used bits to 0 instead of 1),
>>> I always had the same problem: after a while of communicating over
>>> Ethernet with the AT91 EMAC, packets get ?eaten?.
>>>
>>> TX Packets get stuck, and they need an RX packet to get out.
>>>       
>> It sounds like missed interrupts, or a race condition in the interrupt
>> handling.
>>     
> Yes indeed.
> The original driver does not mask interrupts at the start of the ISR and unmask them at the end of the DSR.
> Is it correct that this mask/unmask is not needed because it is an internal interrupt and at the end of the ISR 'cyg_interrupt_acknowledge(vector)' is called - this acknowledge clears the interrupt? So this should be ok.
>
> Maybe there is a sort of race condition with can_send()?
>
>   
Indeed, that was the problem:
Wrong code in at91_eth_deliver():

   if (tsr&AT91_EMAC_TSR_COMP) //5
   {
      at91_reset_tbd(priv);
      _eth_drv_tx_done(sc,priv->curr_tx_key,0);
      priv->tx_busy = false;
   }

Correct code:
   {
      at91_reset_tbd(priv, b_reset_tbd_idx);
      priv->tx_busy = false;
      _eth_drv_tx_done(sc,priv->curr_tx_key,0);
   }

Aparantly very few people know how the complete TCP/IP stack works in 
eCos.... I also did not knew it, now I know:
The high-level TCP/IP stack puts al its data in a buffer, and calls once 
the "middleware" /io/eth/current/src/net/eth_drv.c::eth_drv_send() function.
If the low-level driver is available (can_send() returns not zero) then 
the first packet is sent.
If the low-level driver is not available it stops here. It is supposed 
that the low-level driver will inform then the middleware when it is 
ready by calling tx_done.
eth_drv_tx_done on its turn calls eth_drv_send() which then checks again 
can_send()

The AT91 driver first called tx_done, calling send calling can_send 
which returns 0 of course.
And afterwards - too late - busy is set to true, so that can_send can 
return 1...

Missing a TX interrupt is fatal..
Then the option CYGPKG_NET_FAST_THREAD_TICKLE_DEVS is very handy 
(default on option!)! But this unblocks only an already blocked driver..
Mark that for LW-IP and Redboot there are other drivers there.

Kind regards,
Jürgen

P.S.: my troubles are not yet finished; I have RX BNA problems now..



-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

Re: [ECOS] "packets eaten" with AT91 EMAC Ethernet driver

[I-Yanaslov]

----- Original Message ----- 
From: "Jürgen Lambrecht" <J.Lambrecht@televic.com>
To: <ecos-discuss@ecos.sourceware.org>
Cc: "Andrew Lunn" <andrew@lunn.ch>; "I-Yanaslov" <yanaslov_iv@ic-bresler.ru>
Sent: Tuesday, June 10, 2008 8:11 PM
Subject: Re: [ECOS] "packets eaten" with AT91 EMAC Ethernet driver


> Lambrecht Jürgen wrote:

> Indeed, that was the problem:
> Wrong code in at91_eth_deliver():
>
>   if (tsr&AT91_EMAC_TSR_COMP) //5
>   {
>      at91_reset_tbd(priv);
>      _eth_drv_tx_done(sc,priv->curr_tx_key,0);
>      priv->tx_busy = false;
>   }
>
> Correct code:
>   {
>      at91_reset_tbd(priv, b_reset_tbd_idx);
>      priv->tx_busy = false;
>      _eth_drv_tx_done(sc,priv->curr_tx_key,0);
>   }
>
> If the low-level driver is available (can_send() returns not zero) then 
> the first packet is sent.
> If the low-level driver is not available it stops here. It is supposed 
> that the low-level driver will inform then the middleware when it is ready 
> by calling tx_done.
> eth_drv_tx_done on its turn calls eth_drv_send() which then checks again 
> can_send()
>
> The AT91 driver first called tx_done, calling send calling can_send which 
> returns 0 of course.
> And afterwards - too late - busy is set to true, so that can_send can 
> return 1...

"priv->tx_busy = false;" is not consumes many time.
So, ISR is better place to do it.
Than, TX driver becomes to ready (can_send() returns 1 ) just at moment whan 
a HW becomes to ready, even if DSR and __eth_drv_tx_done() is still running.

Ivan.


-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

[ECOS] `

[Jürgen Lambrecht]

I-Yanaslov wrote:
>
> ----- Original Message ----- From: "Jürgen Lambrecht" 
> <J.Lambrecht@televic.com>
> To: <ecos-discuss@ecos.sourceware.org>
> Cc: "Andrew Lunn" <andrew@lunn.ch>; "I-Yanaslov" 
> <yanaslov_iv@ic-bresler.ru>
> Sent: Tuesday, June 10, 2008 8:11 PM
> Subject: Re: [ECOS] "packets eaten" with AT91 EMAC Ethernet driver
>
>
>> Lambrecht Jürgen wrote:
>
>> Indeed, that was the problem:
>> Wrong code in at91_eth_deliver():
>>
>>   if (tsr&AT91_EMAC_TSR_COMP) //5
>>   {
>>      at91_reset_tbd(priv);
>>      _eth_drv_tx_done(sc,priv->curr_tx_key,0);
>>      priv->tx_busy = false;
>>   }
>>
>> Correct code:
>>   {
>>      at91_reset_tbd(priv, b_reset_tbd_idx);
>>      priv->tx_busy = false;
>>      _eth_drv_tx_done(sc,priv->curr_tx_key,0);
>>   }
>>
>> If the low-level driver is available (can_send() returns not zero) 
>> then the first packet is sent.
>> If the low-level driver is not available it stops here. It is 
>> supposed that the low-level driver will inform then the middleware 
>> when it is ready by calling tx_done.
>> eth_drv_tx_done on its turn calls eth_drv_send() which then checks 
>> again can_send()
>>
>> The AT91 driver first called tx_done, calling send calling can_send 
>> which returns 0 of course.
>> And afterwards - too late - busy is set to true, so that can_send can 
>> return 1...
>
> "priv->tx_busy = false;" is not consumes many time.
indeed
> So, ISR is better place to do it.
> Than, TX driver becomes to ready (can_send() returns 1 ) just at 
> moment whan a HW becomes to ready, even if DSR and __eth_drv_tx_done() 
> is still running.
>
Yes, that could be a good idea.
I can only think of 1 problem:

The moment you set "priv->tx_busy = false;", packets can be sent. And if 
the TCP/IP stack has new data to send (e.g. because of a new RX), it 
will call send(), and then finally the transmit status bits in the TSR 
register can be overwritten before at91_eth_deliver() has read out the 
TSR register for the previous packet.
This should not be possible, if at91_eth_deliver() runs in DSR context, 
because a DSR will always run before "normal" functions.
But I don't think at91_eth_deliver() is called under DSR context.

This is the call stack:
The DSR is /io/eth/current/src/net/eth_drv.c::eth_drv_dsr() ->
/net/bsd_tcpip/current/src/ecos/timeout.c::ecos_synch_eth_drv_dsr() 
{cyg_flag_setbits( &alarm_flag, 2 ); }
This flags the alarm-flag of the alarm_thread() (cyg_flag_wait(..)) ->
/io/eth/current/src/net/eth_drv_run_deliveries() -> at91_eth_deliver()

When the alarm-flag is flagged by the DSR function, the scheduler wakes 
up the alarm thread, but is this alarm_thread() still run under DSR 
context???

I don't think so.
deliver() is meant to run under thread context and not DSR context, 
because all the copying and buffer handling takes too long for DSR 
context (?).

Kind regards,
Jürgen

> Ivan.
>
>
>



-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

[ECOS] ÄãÏëÔÚÊé³ÇÅÔÓиöÕÐÉúµã»ò°ìÊ´¦Âð£¿

[any]

[-- Attachment #1: Type: text/plain, Size: 258 bytes --]

    ÄãÏëÔÚÊé³ÇÅÔÓиöÕÐÉúµã»ò°ìÊ´¦Âð£¿Ç뾡¿ìÓëÎÒ¹«Ë¾ÁªÏµ£¬ÊʺÏÕÐÉú¡¢×Éѯ¡¢Æ±Îñ¡¢¹«Ë¾°ìÊ´¦µÈ£¬½»Í¨Ê®·Ö·½±ã£¬ÓÐн¨µÄµØÌú£¬ºóÃæÊÇÍòÏó³Ç£¬¶ÔÃæÊǵØÍõ£¬ÓµÓÐСС°ì¹«µã£¬´´ÔìÎÞÏÞÉÌ»ú£¡Ã¿¸öС°ì¹«ÊÒÖ»ÐèÒª2000Ôª/Ô£¬³¬Öµ£¡£¡Ãû¶îÓÐÏÞ£¬Ïȵ½Ïȵã¡    ÁªÏµ£º13631681932

[-- Attachment #2: Type: text/plain, Size: 148 bytes --]

-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

[ECOS]

[Piteir]

Hi,

I always failed to download hello example in srec
format the hello example that I compile in cygwin size
is 1029KB and I create srec format using

arm-elf-objcopy -O hello.exe hello.srec

the hello.srec size only 178KB from hello.exe 1029KB
Is the arm-elf-objcopy produce an error result?

Thanks
Piteir

__________________________________________________
Do You Yahoo!?
Get personalized email addresses from Yahoo! Mail - only $35 
a year!  http://personal.mail.yahoo.com/

RE: [ECOS]

[Robert Cragie]

> -----Original Message-----
> From: ecos-discuss-owner@sources.redhat.com
> [ mailto:ecos-discuss-owner@sources.redhat.com]On Behalf Of Piteir
> Sent: 13 June 2001 05:51
> To: ECOS
> Subject: [ECOS]
> 
> 
> Hi,
> 
> I always failed to download hello example in srec
> format the hello example that I compile in cygwin size
> is 1029KB and I create srec format using
> 
> arm-elf-objcopy -O hello.exe hello.srec

Shouldn't that be:

arm-elf-objcopy -S -O srec hello.exe hello.srec

> 
> the hello.srec size only 178KB from hello.exe 1029KB
> Is the arm-elf-objcopy produce an error result?
> 
> Thanks
> Piteir
> 
> __________________________________________________
> Do You Yahoo!?
> Get personalized email addresses from Yahoo! Mail - only $35 
> a year!  http://personal.mail.yahoo.com/

-- 
Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos
and search the list archive: http://sources.redhat.com/ml/ecos-discuss