2010-07-29 01:29:01 Asynch memory access in ucLinux kernel

Wojtek Skulski (UNITED STATES)

Message: 91835

I am back with a weird problem. Under the kernel I cannot successfully read/write a peripheral memory-mapped in asynch memory AMS3. The peripheral is AX88180 (you guessed) which programming-wise is like a small RAM. The chip select is tied to AMS3. The chip works wonderfully under U-Boot after I fixed the U-Boot driver. I can download the uImage from the TFTP server using this chip, what is proving again and again that it is working. After booting Linux the thing is dead.

I boiled the problem down to the inability to read/write to the chip in the driver code. The code snippet is attached. There are two tests in this snippet. One is using the macros WRITE_MACREG and READ_MACREG, which are #defined the Linux driver drivers/net/ax88180.c. The next test is doing the write/read more directly with "outw" and "read_short". The "outw" is defined somewhere in the Linux guts, not sure where. The "read_short" I ported from U-Boot, where it worked under the name "readw".

Either way, writing the memory-mapped register and then reading back fails. For this test I chose the "hash table" registers in the chip. According to the data sheet, all 15 bits of these are read/write. So whatever I put in, I should be able to get back. But I do not.

Concerning the second test, one can say it is my fault. But the first one is calling macros which were supplied in the driver. I did not touch these. They are expected to work.

So the question is, what can be wrong with asynch memory access in the Linux driver code? I changed the bank timing back to the default from the HRM.These settings work under U-Boot. Should be OK also under Linux. I turned off the dcache. The bank AMS3 is enabled. Packing is 32-bit. What else can be wrong? Writing and reading the asynch memory is a pretty fundamental thing. It works under U-Boot but not under Linux kernel. Any suggestions, why?

The kernel is the following one: Linux version 2.6.28.10-ADI-2009R1.1 (uclinux@colinux) (gcc version 4.1.2 (ADI s

vn)) #68 PREEMPT Thu Jul 29 00:44:54 EDT 2010

--- the result of the two tests under Linux -----------------

ax88180_mdio_read: read 0x0 back from MAC mem location 0xfcc0

ax88180_mdio_read: read 0x0 back from MAC mem location 0x2c00fcc4

----- the code which did the tests -----

unsigned long regdata = 0;

unsigned short retval;

unsigned long tmp, k;

unsigned long mem_regaddr; /* Bfin memory addresses are 32-bit */

/* for debugging, write and read back a register to see if reading/writing works */

regdata = 0xbeef;

mem_regaddr = 0xfcc0; /* Hash table 0 register read/write */

WRITE_MACREG(mem_regaddr, regdata); /* use "official" macro (it adds Log_MemBase)*/

READ_MACREG ( mem_regaddr, tmp ); /* use "official" macro */

PRINTK(ERROR_MSG,"\nax88180_mdio_read: read 0x%x back from MAC mem location 0x%x\n",

tmp, mem_regaddr);

regdata = 0xdead;

mem_regaddr = Log_MemBase + 0xfcc4; /* HASH table 0 register read/write */

outw (regdata, mem_regaddr); /* outw will not add mem base, we had to do it*/

tmp = read_short ( mem_regaddr ); /* read back from register */

PRINTK(ERROR_MSG,"\nax88180_mdio_read: read 0x%x back from MAC mem location 0x%x\n",

tmp, mem_regaddr);

-------------- function read_short was ported from U-Boot ------

/* readw copied from U-Boot <asm/io.h>. Renamed read_short. */

static inline unsigned short read_short (const volatile void __iomem *addr)

{ /*reads 16-bit word, but uses 32-bit memory address */

unsigned int val;

int tmp;

__asm__ __volatile__ (

"cli %1;"

"NOP; NOP; SSYNC;"

"%0 = w [%2] (z);"

"sti %1;"

: "=d"(val), "=d"(tmp)

: "a"(addr)

);

return (unsigned short) val;

} // read_short

QuoteReplyEditDelete

2010-07-29 02:06:23 Re: Asynch memory access in ucLinux kernel

Mike Frysinger (UNITED STATES)

Message: 91836

ths is a good example of the driver only existing in the 2009R1 branch. we punted it a while ago and it wont be in the 2010R1 release. bugging asix.com.tw to get their driver mainlined because it is directly hindering your use of their part would be good feedback for them.

at any rate, the io.h macros are defined for the Blackfin u-boot port the same way as for the Blackfin Linux port. look at arch/blackfin/include/asm/io.h for their definition.

dcache should not affect async memory in any ways. those banks are always declared as uncacheable.

you should be able to read/write the async banks directly from userspace. so try disabling the driver completely and poke the memory mapped registers from a simple userspace app.

presumably you found the extended debugging knobs in the driver. does it look like it is able to read any of the device registers ? you've made sure that you dont have CONFIG_AX88180_16BIT enabled ?

QuoteReplyEditDelete

2010-07-29 09:52:32 Re: Asynch memory access in ucLinux kernel

Wojtek Skulski (UNITED STATES)

Message: 91872

Mike:

of course I made sure that I unchecked the CONFIG_AX88180_16BIT in the menuconfig. I will now insert the debug printout to make sure it did not sneak in. If it did then it would be a bug in menuconfig. I will make sure it is not defined.

Before I start blaming/bugging ASIX Corp, let me ask about your policies. Let's take this example. The header by its author Allan Chou <allan@asix.com.tw> says it is version 1.0.1. Then the header lists two other contributors: 3) Port to Blackfin (16-bit Mode) Phil Wilshire and 4) Michael Hennerich <michael.hennerich@analog.com>. The latter claims port to Blackfin 16-bit Mode, restore 32-bit Mode, add to platfrom device, port to linux-2.6.22, remove useless debug info, various bug fixes, coding style cleanups, etc.

Meanwhile, the original author released driver 1.1.2, which is available on the ASIX website. But it is in no way "ported to Blackfin", because you guys decided to branch off rather than collaborate with the original developer. It now appears you want to "punt the driver" because of the mess which is no way related to ASIX, who were doing their job.

It appears that Analog Devices developer (Michael Hennrich), contrbuted many changes, but did not coordinate those back. It is Analog Devices, who made many changes and thus claimed partial ownership of this driver. If Analog Devices chose to develop this code, then why Analog Devices chose not to talk to the orinal author?

And if Analog Devices has created such a mess that this code does not work anymore, then why is Analog Devices dumping this on the customer's head? My use of YOUR product will be "directly hindered". From my perspective, Blackfin is YOUR product and Blackfin ucLinux is YOUR product rather than ASIX's. Following your own advice, I am now bugging YOU. If there is anybody to blame for this bad situation, it is Analog Devices rather than ASIX. They did their job. Analog Devices created the mess. The evidence for this statement is in the source code: names and dates.

I am your customer. My use of Blackfin will be directly hindered. This fall I will be presenting this project to the scientific community in one of major National Laboratories. I wish I could put words such as "excellent" and "superb" next to the "Analog Devices". But I will not be able to.

I hope you are not offended. Following your own advice, I am bugging the appropriate persons, who are Analog Devices rather than someone else.

QuoteReplyEditDelete

2010-07-29 13:16:16 Re: Asynch memory access in ucLinux kernel

Wojtek Skulski (UNITED STATES)

Message: 91879

I will fix that **** driver. Below is the evidence that I will be able to. I will have to change the macros and it will work. Something has been apparently changed in the low-level memory access code which has made MAC register macros not work.

I will then try to learn about "patches" and submit the new driver to you with the copy sent to the original developer. I am also asking you to rethink your policies. I am trying to help both Analog Devices and myself. I am hoping that we will move forward and expand the Blackfin uCLinux rather than otherwise.

ax88180_mdio_read: read 0x0 back from MAC mem location 0xfcc0 <---- original macros, now broken

ax88180_mdio_read: read 0xdead back from MAC mem location 0x2c00fcc4 <--- primitives from io.h do work

unsigned int regdata;

unsigned short retval;

unsigned long tmp, k;

unsigned int mem_regaddr; /* Bfin memory addresses are 32-bit */

/* for debugging, write and read back a register to see if reading/writing works */

regdata = 0xbeef;

mem_regaddr = 0xfcc0; /* Hash table 0 register read/write */

WRITE_MACREG(mem_regaddr, regdata); /* use "official" macro (it adds Log_MemBase)*/

READ_MACREG ( mem_regaddr, tmp ); /* use "official" macro */

PRINTK(ERROR_MSG,"\nax88180_mdio_read: read 0x%x back from MAC mem location 0x%x\n",

tmp, mem_regaddr);

regdata = 0xdead;

mem_regaddr = Log_MemBase + 0xfcc4; /* HASH table 1 register read/write */

writel (regdata, mem_regaddr); /* will not add mem base, we had to do it*/

tmp = readl ( mem_regaddr ); /* read back from register */

PRINTK(ERROR_MSG,"\nax88180_mdio_read: read 0x%x back from MAC mem location 0x%x\n",

tmp, mem_regaddr);

QuoteReplyEditDelete

2010-07-29 14:34:08 Re: Asynch memory access in ucLinux kernel

Michael Hennerich (GERMANY)

Message: 91883 >It appears that Analog Devicesdeveloper (Michael Hennrich), contrbuted many changes, but did not coordinate those back.

Wrong! - we did that more than once.

>If Analog Devices chose to develop this code, then why Analog Devices chose not to talk to the orinal author?

Wrong! - We talked to the author.

But they failed to accept our patches - and decided to further release messy tarball releases.

- That fail to work on recent kernels.

>I will then try to learn about "patches" and submit the new driver to you with the copy sent to the original developer.

Well - I wish you more luck than we had!

We decided to punt this driver due to failure of the original author or its company to get this driver mainlined.

-Michael

QuoteReplyEditDelete

2010-07-29 21:04:29 Re: Asynch memory access in ucLinux kernel

Robin Getz (UNITED STATES)

Message: 91894

Wojtek:

I don't know what you are looking at that leads you to believe these things - but your thoughts about what happened in the past does not reflect the reality of the interaction between Analog Device developers and ASIX developers.

>I hope you are not offended.

I am extremly offended. You are calling us liars. How could I not be offended?

QuoteReplyEditDelete

2010-07-29 22:32:25 Re: Asynch memory access in ucLinux kernel

Wojtek Skulski (UNITED STATES)

Message: 91896

Robin:

please accept my apology. I should have had sent my thoughts to you directly and get more info about the past, which of course I do not know. On the other hand, I never said you were liars. I said that based on available information, it looks like the decision to punt the driver is not justified. Please do not read more than I meant to say. In any case, I apologise to you all. Esp.to Michael. I am sorry to hear, that you did a good job and it was not accepted.

I made a change to the driver as follows. The PHY chip is now detected. I am seeing ARP packets sent to the other host. This is not the end of the problem, because ping is now crashing on NETDEV WATCHDOG timeout. I do not know whether this is related to the driver. I rather suspect that it is a bug in ping.

The change to the driver consists of changing inw and outw to readl and writel. That's all. There are four such places. I changed only the 32-bit branch of #ifdef, because the 16-bit branch is not compiled anyway.

#define READ_RXBUF(data) data = readl((void __iomem *)(Log_MemBase + RXBUFFER_START))

#define WRITE_TXBUF(data) writel(data, Log_MemBase + TXBUFFER_START)

#define READ_MACREG(regaddr, regdata) regdata = readl((void __iomem *)(Log_MemBase+regaddr))

#define WRITE_MACREG(regaddr, regdata) writel(regdata, Log_MemBase + regaddr)

After making these changes, the PHY is now correctly detected.

root:/> ifconfig eth0 hw ether 02:80:ad:20:31:b8

root:/> ifconfig eth0 169.254.144.145 netmask 255.255.255.0 up

ax88180: The MAC address is 02:80:ad:20:31:b8

ax88180: Found Marvell 88E1111 PHY chipset. (PHY Addr=0x18)

ax88180: Waiting for auto-negotiation completion......

ax88180: Set to 100Mbps Full-duplex mode.

ax88180: name=eth0, Phy_MemBase=0x2c000000, IRQ=83, media=0, jumbo=1

ax88180: The AX88180 driver is loaded successfully.

QuoteReplyEditDelete

2010-07-30 00:27:05 Re: Asynch memory access in ucLinux kernel

Wojtek Skulski (UNITED STATES)

Message: 91899

I cannot say that network is working after I made those changes to the AX88180 driver, but it looks as if the driver itself is working. There is now a constant ARP dialog between the Blackfin card and the PC host. One is asking and the other is responding. So the packets are flowing. The fact that the ICMP packets do not follow the ARP packets probably is not due to the chip driver. In any case, the memory addressing problem seems under control. BTW, it would be helpful if there were some comments in the io.h file. Why is writel working while outw is not? Would be good to know for the future.

I am attaching the Wireshark record because it shows that the AX88180 driver has been fixed. Now I need to understand what is involved in "mainlining" the driver.

ARP_dialog.gif

QuoteReplyEditDelete

2010-07-30 08:23:03 Re: Asynch memory access in ucLinux kernel

Robin Getz (UNITED STATES)

Message: 91920

Wojtek:

apology accepted - The bottom line is:

- we will not add this driver back to the kernel or U-Boot which is maintained here.

- we aren't going to look into any issues - we can provide some basic debugging tips (like Mike was doing) - but we aren't going to review patches, or take things back, or review detailed wireshark logs. Networking works in the kernel, but there is no stable API - there could be many things that need updating in the driver to get networking to work beyond just simple register read/writes. The vendor should take care of this in their latest release.

- we will pull updates from mainline kernel and U-Boot (kernel.org, and denx.de). If someone (AXIS or you or someone else) goes through the effort of re-writing the drivers, and getting them accepted upstream - they will re-appear in our distributions eventually. If you are interested see ./Documentation/SubmittingDrivers in the kernel source, and subscribe to netdev on vger.kernel.org/vger-lists.html

- If you get it to work - that is great - but like we stated - both the vendor and ourselves could not get the performance at the same level as the on-board 10/100 MAC. The vendor said this was expected.

Thanks for understanding.

-Robin

QuoteReplyEditDelete

2010-07-30 09:13:04 Re: Asynch memory access in ucLinux kernel

Mike Frysinger (UNITED STATES)

Message: 91922

netdev watchdog timeouts are most likely due to the driver. everytime we've seen it in the past, it was the driver. i vaguely recall it being along the lines of the network stack sending the driver some work, but the driver never signaled back that it was done, and the common net layers have some watchdog timers to catch this semi-common problem.

QuoteReplyEditDelete

2010-07-30 10:59:46 Re: Asynch memory access in ucLinux kernel

Robin Getz (UNITED STATES)

Message: 91924

Mike pointed out that AXIS did mainline things in U-Boot in Jul 2008.

git.denx.de/cgi-bin/gitweb.cgi?p=u-boot.git;a=commit;h=30f574717277238b9014b8136c90eea77196490f

but they have not done this in the kernel yet.

git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=tree;f=drivers/net;hb=HEAD

The only AXIS driver in mainline is the ax88796, which is only a 10/100 part, contributed and maintained by a non-AXIS person.

-Robin

QuoteReplyEditDelete

2010-07-30 11:16:09 Re: Asynch memory access in ucLinux kernel

Wojtek Skulski (UNITED STATES)

Message: 91925

Robin:

I regret that all this information was not available at the time of our design decisions. The performance figures were known, but the prospect of losing support was not. If it was known then the design decision would have been different. I apologise one more time for overreacting to a blow that came from the blue sky without prior warning.

Do you have any recommendation concerning another gigabit chipset which you would be willing to add to your distribution?

QuoteReplyEditDelete

2010-07-30 13:12:47 Re: Asynch memory access in ucLinux kernel

Robin Getz (UNITED STATES)

Message: 91927

Wojtek:

We don't add things specifically to our distribution - this is how we ended up in this mess to begin with, we aren't going to do it again. Things get added to the netdev tree, which Linus pulls ethernet drivers from, and we pull/merge from that.

I don't know of any other Gigabit chip with an async interface. (all in mainline today are PCI, PCIe, or build into the Soc).

-Robin

QuoteReplyEditDelete

2010-07-30 13:27:53 Re: Asynch memory access in ucLinux kernel

Wojtek Skulski (UNITED STATES)

Message: 91929

Robin,

thank you for the info. It is all new to me. I was always thinking that you just release software and then maintain it. I was not aware of the details.

I wrote to ASIX and my fingers are crossed. Concerning the MAC with asynch interface, we can always make one from an FPGA, but then the software... grrh.

QuoteReplyEditDelete

2010-07-30 13:42:59 Re: Asynch memory access in ucLinux kernel

Robin Getz (UNITED STATES)

Message: 91930

Wojtek:

Look in the kernel source for Xilinx support MACs - you should find (in ./drivers/net/Kconfig):

config XILINX_LL_TEMAC

tristate "Xilinx LL TEMAC (LocalLink Tri-mode Ethernet MAC) driver"

select PHYLIB

depends on PPC_DCR_NATIVE

help

This driver supports the Xilinx 10/100/1000 LocalLink TEMAC

core used in Xilinx Spartan and Virtex FPGAs

Don't know if this will help or not - hopefully AXIS is more responsive to you (since you are a customer buying things) that they have been in the past to us (who don't purchase anything).

-Robin

QuoteReplyEditDelete

2010-07-30 13:55:01 Re: Asynch memory access in ucLinux kernel

Wojtek Skulski (UNITED STATES)

Message: 91931

Robin, thanks a lot. We are aware of the Xilinx cores. That's why I said "FPGA". But I am hoping for a positive response from ASIX. Fingers crossed.

QuoteReplyEditDelete

2010-08-01 22:22:36 Re: Asynch memory access in ucLinux kernel

Wojtek Skulski (UNITED STATES)

Message: 91989

Robin and Mike:

I fixed the problem. The AX88180 is now working under Linux. Well, at least it is pinging. The last remaining issue was the interrupt. I used both a wrong number and wrong polarity. I have no clear idea where the IRQ=83 came from. Probably I mistyped in the menuconfig. It should have been 82. Also the polarity has to be active low. After fixing these issues the driver came to life.

So it was a multitude of small problems all conspiring to look like one big problem.

QuoteReplyEditDelete

2010-08-01 22:46:17 Re: Asynch memory access in ucLinux kernel

Mike Frysinger (UNITED STATES)

Message: 91991

i would avoid hardcoding #'s into your board resources. if you want an IRQ on PF9, then please use the IRQ_PF9 define.

QuoteReplyEditDelete

2010-08-01 22:59:26 Re: Asynch memory access in ucLinux kernel

Wojtek Skulski (UNITED STATES)

Message: 91992

Mike: yes of course. Last night I did just that. But menuconfig is asking for numbers. I vaguely recall that "83" stuck into my mind from some wiki page when I was answering the menuconfig question. From then on it looked just right every time I saw it.

If menuconfig asked for the PFx then I would not have made the mistake because I remember perfectly well that I connected PF9 to this chip. But "83" versus "82" was not obvious. So it stayed in place until I started thinking "aha, what is the interrupt actually doing". And from there it was just one small step... for a person...

QuoteReplyEditDelete

2010-08-01 23:05:18 Re: Asynch memory access in ucLinux kernel

Mike Frysinger (UNITED STATES)

Message: 91993

oh, i was thinking that info was in the board resources and not menuconfig. in that case, you need the raw number and in the future, that info should all be in the board resources.

mabye if asix ever gets around to mainlining, we can look at that.

QuoteReplyEditDelete

2010-08-01 23:24:03 Re: Asynch memory access in ucLinux kernel

Wojtek Skulski (UNITED STATES)

Message: 91994

Mike: I looked at that.Maybe I should not reveal this, but I used their latest driver which I just got from them. It is a different kind of a beast. Very neatly written. Very, very. There is a place for the IRQ, a place for the base address, and you can insmod it. Cool stuff. I ported it to Blackfin in two days. I am not using the old one anymore. If only the new one made it into the uClinux. That would be great.

QuoteReplyEditDelete

2010-08-01 23:53:03 Re: Asynch memory access in ucLinux kernel

Mike Frysinger (UNITED STATES)

Message: 91995

post it as an attachment for people to look at

QuoteReplyEditDelete

2010-08-02 01:01:28 Re: Asynch memory access in ucLinux kernel

Wojtek Skulski (UNITED STATES)

Message: 91997

Mike:

here is the ported Linux driver with a detailed readme. I apologise for my crude fixes. The archive contains both the original received from ASIX and the version ported to Blackfin. ASIX has nothing against releasing this stuff while they are also looking at it.

I also added the fixed U-Boot driver for the record. It is nowhere near the Linux one as far as coding style is concerned. Obviously ASIX have been working on their code. The main value of this U-Boot stuff is the readme where I summarized the fix, which by itself is trivial.

AX88180_Linux_v2.0.0_Blackfin.zip

AX88180_U-Boot_2010_06_Blackfin.zip

QuoteReplyEditDelete

2010-08-02 08:45:07 Re: Asynch memory access in ucLinux kernel

Robin Getz (UNITED STATES)

Message: 92048

Wojtek:

Checkpatch says:

ERROR: trailing whitespace

ERROR: do not use C99 // comments

ERROR: trailing whitespace

ERROR: do not use C99 // comments

ERROR: trailing whitespace

ERROR: do not initialise externals to 0 or NULL

ERROR: trailing whitespace

ERROR: do not use C99 // comments

ERROR: trailing whitespace

ERROR: space prohibited before open square bracket '['

ERROR: trailing whitespace

ERROR: space prohibited before open square bracket '['

ERROR: trailing whitespace

ERROR: space prohibited before open square bracket '['

ERROR: trailing whitespace

ERROR: space prohibited before open square bracket '['

ERROR: do not use C99 // comments

ERROR: trailing whitespace

ERROR: space prohibited before that close parenthesis ')'

ERROR: code indent should use tabs where possible

ERROR: trailing whitespace

ERROR: code indent should use tabs where possible

ERROR: do not use C99 // comments

ERROR: space prohibited after that open parenthesis '('

ERROR: space required before the open parenthesis '('

ERROR: trailing whitespace

[snip]

Well, you get the idea -- total: 153 errors, 375 warnings, 2069 lines checked (1 in every 4 lines has a problem).

Doesn't look very well done to me... We are certainly not going to include it.

-Robin

QuoteReplyEditDelete

2010-08-02 09:37:55 Re: Asynch memory access in ucLinux kernel

Wojtek Skulski (UNITED STATES)

Message: 92050

Robin:

I was not aware of "checkpatch". If there is such a tool, then how about "fixpatch"? Code beautifyiers and pretty printers are pretty common tools. Is there a tool available which remove those "errors" consisting of trailing space?

From my perspective the "right" solution is not the one which does not have trailing space, but the one which runs on my board. I asked ASIX about performance. They said that when driven with a 32-bit ARM, the chip achieves in excess of 200 Mbps, and when driven by the FPGA (no programming overhead) it achieves in excess of 400 Mbps. I would thus say, that Blackfin being such a wonderful dual-core processor, we can perhaps achieve 300 Mbps if we activate the burst mode and do the timing right. That would be a factor of three improvement over the 100 Mbps ethernet. Are you suggesting that we should resign from designing such high-performance instrumentation because some software tool does not like trailing space which nobody can see anyway?

It would be plain ridiculous if we had to resign from data acquisition because some software tool does not like white space before a parenthesis.The compiler is the king. If the program compiles and it runs, then it is a perfectly legal program. The rest is logistics which should not be getting in the way. An automatic text formatter must be available somewhere which can take care of this. And if not then we can find a student.

QuoteReplyEditDelete

2010-08-02 09:46:38 Re: Asynch memory access in ucLinux kernel

Robin Getz (UNITED STATES)

Message: 92051

Wojtek:

>I was not aware of "checkpatch".

Then you should read the docs that I pointed you to previously. 2010-07-30 08:23:03

>From my perspective the "right" solution is not the one which does not have trailing space, but the one which runs on my board.

That is your opinion - not mine, and not mainline. Like I said - things go to netdev, then Linus, then us.

-Robin

QuoteReplyEditDelete

2010-08-02 09:55:58 Re: Asynch memory access in ucLinux kernel

Michael Hennerich (GERMANY)

Message: 92052 > I was not aware of "checkpatch". If there is such a tool, then how

> about "fixpatch"? Code beautifyiers and pretty printers are pretty

> common tools. Is therea tool availablewhich remove those "errors"

> consisting of trailing space?

Try linux-2.6.x/scripts/Lindent

For the performance analysis:

Try to take a calculator and add the number of wait states you need to insert to the Blackfin

bus cycle in order to not violate the AD88180 timing spec.

You will notice that you have two options. Either run Blackfin SCLK at 100MHz,

Or use an external crystal to supply a BUS CLK <= 100MHz clock and use the async timing.

This will get you the max theoretical Mbps you can achieve which is below the 400Mbps.

Now consider that the kernel will not just service the AX88180 FIFOs it will also run the kernel and your

applications.

Given the fact that writing and receiving data to and from the AX88180 is slower than compared to many other 10/100 MACPHYs

- your overall performance is slower.

(The max theoretical 400 Mbps are generated with something that generates exactly the AX88180 preferred bus cycle.

And it does nothing else than writing packets as fast it can do)

QuoteReplyEditDelete

2010-08-02 10:20:55 Re: Asynch memory access in ucLinux kernel

Wojtek Skulski (UNITED STATES)

Message: 92054

Michael:

I am aware of the timing. On my board I am using a separate 100 MHz crystal in order to free myself from the fixed timing on the BF bus. Therefore the chip will need one extra cycle. This limits the performance in single register access. But the chip has a burst mode and we will try that. Blackfin has a highly autonomous bus controller with DMA and all that, and we will try using it to feed the data as fast as possible. Concerning the OS overhead, in some applications we may go to bare metal and use Blackfin like a classic DSP. All this will be tried when we need to. Your website provides all these wonderful programming tools which we can apply in this case.

The ASIX performance figures are "typical best" benchmarks and we are of course aware of that. We do not believe each and every number we hear from a chip manufacturer. But it is good to know some numbers. Otherwise we would start believing that 100 Mbps hardware is faster than 1000 Mbps hardware. The numbers from the chip vendor are providing some sort of rough indication what is achievable, and what is not.

At this point my expectation is that 200 Mbps will be achievable, while 300 Mbps may be achievable, if we do everything right (including the whitespace). I do not need to know more in order to move ahead. We will know more after our system is off the ground and collecting data. This will happen in about two years from now. That's enough time to perhaps choose another MAC, if necessary.

Please note that the only reason I chose this chip was its software support in the Analog Devices distribution. I simply had no other choice. I wish other MACs were supported to choose from. But since this was the only one, I had to accept it with all the reservations.

QuoteReplyEditDelete

2010-08-02 13:45:58 Re: Asynch memory access in ucLinux kernel

Wojtek Skulski (UNITED STATES)

Message: 92061

Robin:

I am hoping that ASIX will follow the proper procedure and their chip will stay in the distribution. But let me ask another question: what is the advantage to keep upgrading the ucLinux? Is there anything wrong if we stay with the version of ucLinux which still has this chip included? Maybe this is a good solution. What do you think?

QuoteReplyEditDelete

2010-08-02 14:26:25 Re: Asynch memory access in ucLinux kernel

Robin Getz (UNITED STATES)

Message: 92063

Wojtek:

Just to be clear - There is no doubt - it is not in mainline, it is not in the trunk kernel. It will not be in the 2010 release.

As for sticking with old releases - that is a choice only you can make (I don't recommend it) - per our support policy - we don't support old releases.

https://docs.blackfin.uclinux.org/doku.php?id=processes#supporting_releases

QuoteReplyEditDelete

2010-08-02 23:02:24 Re: Asynch memory access in ucLinux kernel

Wojtek Skulski (UNITED STATES)

Message: 92079

Michael:

I was poking around to learn about gigabit performance, and I found some interesting FAQ www.dssnetworks.com/v3/FAQs.asp. There is a definite suggestion to go to lower-level protocols. This may become our solution because we will be running a point-to-point data acquisition where low level datagrams may suffice. From this point of view the simplicity of the ASIX chip may be good, because it gives us better control over the data stream. All depends on the Blackfin software which we can change. I am not saying I like the idea of limited performance, but what other choices do we have?

As soon as some other more efficient MAC finds its way into ucLinux, we will give it a look. Right now we have to use what is available.

Attachments:

AX88180_U-Boot_2010_06_Blackfin.zip

AX88180_Linux_v2.0.0_Blackfin.zip