Hi,

I am currently developing an Ethernet device driver for ThreadX and NetX. The board I am using is AT91RM9200 Development Kit that has AT91RM9200 and DAVICOM’s DM9161 PHY chip.

I have been looking both (ATMEL sample driver and Linux driver), since the sample code from ATMEL does not use any interrupt and some part of the code contradicts to the document and it was recommended to use the Linux driver as a reference. I obtained two versions of Linux drivers. They were different, especially in setting up the PHY interrupt. By tracing the schematics, I am convinced that the version that uses the PIOC PC4 is the right one. Unfortunately, that is the end of the trace due to the functions without implementation (see below).

However, I have the problem and am seeking for help. The most urgent one is the last one.
- The document is not as detail as some other CPU/Ether device document I have seen. Is there any other place/person I can go to get some more information?
- I don’t use Linux and I don’t have the Linux source code, so when I look at the Linux driver, there are routines that are called but driver related files do not have their implementation. I am guessing those might be the functions supported by Linux. What will be the best way to get either actual function codes or description on what they do?
- The code I wrote works in an interrupt mode, but sometimes it does not use the descriptors in a sequential order and turns on the BNA/OVR bits even when buffer descriptors and buffers are available. Worse, sometimes system writes the address field (first word) of the buffer descriptor with packet size info, overwriting the buffer address. Then code would not recognize that the buffer is filled with incoming packet. Pretty soon after that EMAC’s ISR register becomes 0x6 and 0x4.

Here is my current setting:
- I was told by ATMEL that each descriptor takes 16 bytes and they have to be aligned at 16-byte boundary. The manual shows as 8 bytes per descriptor. I tried to align at 8-byte boundary as well as 16-byte boundary. These different alignments did not make any difference.
- I have 8 descriptors, each pointing to a buffer of 0x600 bytes. The last one has WRAP bit turned on.
- Buffers are also 16-byte aligned.
- RMII is selected.
- 100MHz and Full duplex is detected from the PHY (after auto negotiation). So EMAC is also set to match that.
- I use Green Hills Muti Tools.

Hi Soon Ko

You can find the last driver for linux we have tested http://www.arm.linux.org.uk/developer/v ... 21-rmk1.gz.
This driver handles the PHY interrupt and have all the functions required.
An update exist on http://maxim.org.za/AT91RM9200/ . You can refer to this page to download the last work.

The descriptor are 2 words long (1 word for the address and the second for the size).
Only the address in the EMAC_RBQP register has to be aligned (ref errata sheet on atmel web site).
Concerning the OVR/RBNA:
If the EMAC is unable to write the data at a rate to match the incoming
frame, then an interrupt receive overrun is set.
If there is no receive buffer available, i.e. the next buffer is still owned
by software, the interrupt receive buffer not available(RBNA) is set.

-So take care that variables used by the driver are not cached and updated correctly. All the variables used to access AT91RM9200 registers must be declared as volatile to force their update.
-The memory allocated for the receive buffers(accessed by the DMA) must not be cached.

-Take take that the memory used to store the frames is not slow because:
The EMAC receive FIFO depths is seven words (28 bytes).
Data is typically transferred into and out of the FIFO in bursts of four
words. For receive, a bus request is asserted when the FIFO contains four words and has space for three more.
This means that the bus latency must be less than the time it takes to load
the FIFO and receive three words (12 bytes) of data.
At 100Mbit/s it takes 960ns to receive 12 bytes of data. In addition six
hclk cycles should be allowed for data to be loaded from the bus and to
propagate through the FIFOs. For a 60Mhz hclk this takes 100ns making the bus latency requirement 860ns.

Hamid

Dear Hamid

Thank you for taking time to reply. I have added my comments below. Please let me know if you can help me further on these issues.


Hi Soon Ko

You can find the last driver for linux we have tested http://www.arm.linux.org.uk/developer/v ... 21-rmk1.gz.

==> This site is not valid (“The page cannot be found” message popped up), So I went to “http://www.arm.linux.org.uk/developer/v2.4/” instead. There were multiple versions after the 2.4.21-rmk1. They are mostly correspond to the ones on the “http://maxim.org.za/AT91RM9200/ .”

2.4.26-vrs1 23 April 2004 gzip bzip2
2.4.25-vrs2 07 March 2004 gzip bzip2
2.4.25-vrs1 29 February 2004 gzip bzip2
2.4.24-vrs1 23 February 2004 gzip bzip2
2.4.21-rmk2 18 December 2003 gzip bzip2
2.4.21-rmk1 16 July 2003 gzip bzip2

Here are the questions:

?? When I looked at the unzipped file, it has + and – signs in front of the lines. I am assuming that these indicate the differences – i.e. added and deleted. I am wondering which version was the base line for these changes. What is the automatic tool that incorporates these changes once I find the base version?

?? Do I need to get all these updates?

?? The code refers functions whose implementations are not found from. Some of them are:
- barrier
- netif_carrier_off
- netif_carrier_on
- spin_lock_irq
- request_irq
- ether_setup
From where can I find these?


This driver handles the PHY interrupt and have all the functions required.
An update exist on http://maxim.org.za/AT91RM9200/ . You can refer to this page to download the last work.

==> See above comment. These are the listed items.
2.4.26-vrs1 update for AT91RM9200 (03/05/2004)
2.4.26-vrs1 update for AT91RM9200 (26/04/2004)
2.4.25-vrs2 update for AT91RM9200 (08/03/2004)
2.4.21-rmk2 update for AT91RM9200 (08/03/2004)



The descriptor are 2 words long (1 word for the address and the second for the size).

==> I validated that I use 2 words (i.e. 8 bytes) and stick with it even after ATMEL told me it should be 16 bytes.


Only the address in the EMAC_RBQP register has to be aligned (ref errata sheet on atmel web site).

==> Yes, I read the errata.


Concerning the OVR/RBNA:
If the EMAC is unable to write the data at a rate to match the incoming
frame, then an interrupt receive overrun is set.
If there is no receive buffer available, i.e. the next buffer is still owned
by software, the interrupt receive buffer not available(RBNA) is set.

==> My driver works fine sometime, but not all the time. The strange thing is that it changes from build to build. It seems it depends on the size of the code and/or the size of the data. I tried to see what my build file was doing, but I could not see anything obviously wrong. These are some behaviors when it does not work right:
- The RBNA bit turns on even when there are buffers are available (I check the descriptor censored).
- The RBQP does not move from 0-th to first, to second and so on (eventually wrap around). But it rather moves, for example, from 0th, 1st, 0th, first, then 5th, 6th, 5-th, 6-th and so on.
- The RBNA bit on RSR turns on first, then ISR indicates the same problem a bit later.


-So take care that variables used by the driver are not cached and updated correctly. All the variables used to access AT91RM9200 registers must be declared as volatile to force their update.

==>Yes, they were. I double checked them after you posted this note.


-The memory allocated for the receive buffers(accessed by the DMA) must not be cached.

==> I don’t do any caching. I was wondering about that so I checked CP15 Control register to make sure the default is not “cache on” They were off.


-Take take that the memory used to store the frames is not slow because:
The EMAC receive FIFO depths is seven words (28 bytes).
Data is typically transferred into and out of the FIFO in bursts of four
words. For receive, a bus request is asserted when the FIFO contains four words and has space for three more.
This means that the bus latency must be less than the time it takes to load
the FIFO and receive three words (12 bytes) of data.
At 100Mbit/s it takes 960ns to receive 12 bytes of data. In addition six
hclk cycles should be allowed for data to be loaded from the bus and to
propagate through the FIFOs. For a 60Mhz hclk this takes 100ns making the bus latency requirement 860ns.

==>I am using the AT91RM9200 development kit. I assume it comes with memory that is fast enough memory. I left alone the clock speed control bits as default. I believe that is the Linux driver does.

I would really like to know why the RBQP pointer moves in a strange pattern causing the RBNA. Also any suggestions or ideas are all welcomed.


Hamid