Re: some problems on the SystemACE driver.

Hi Ming,
Instead of bouncing emails to and forth, lets do all at one place:

1. Which TEMAC patch are you using?
(http://source.mvista.com/~ank/paulus-powerpc/20060309/ppc32_xilinx_edk_temac.patch)
2. After applying the patch, is the driver getting compiled directly
without having to select it via "make menuconfig"?
3. I don't see a Makefile in the drivers/net/xilinx_temac/ folder?

Ofcourse, I can work my way to compile the driver. But is there any doc.
present explaining this?

-Ameet

Ming Liu wrote:

Dear Ameet,
Unfortunately, I tried the new patch and the same problem happened. Here 
is the information:

 CC      drivers/xilinx_edk/xdmav2_simple.o
 LD      drivers/xilinx_edk/built-in.o
 LD      drivers/built-in.o
drivers/xilinx_edk/built-in.o(.sdata+0x0): In function `XAssert':
drivers/xilinx_edk/xbasic_types.c:105: multiple definition of 
`XWaitInAssert'
drivers/block/built-in.o(.sdata+0x4):drivers/block/rd.c:103: first 
defined here
drivers/xilinx_edk/built-in.o(.sbss+0x4): In function `XAssert':
drivers/xilinx_edk/xbasic_types.c:105: multiple definition of 
`XAssertStatus'
drivers/block/built-in.o(.sbss+0x3c):include/asm-generic/bitops/non-atomic.h:108 


: first defined here
drivers/xilinx_edk/built-in.o(.text+0x44): In function 
`XAssertSetCallback':
drivers/xilinx_edk/xbasic_types.c:134: multiple definition of 
`XAssertSetCallbac
k'
drivers/block/built-in.o(.text+0x38d0):drivers/block/xilinx_sysace/xbasic_types. 


c:117: first defined here
drivers/xilinx_edk/built-in.o(.text+0x0): In function `XAssert':
drivers/xilinx_edk/xbasic_types.c:105: multiple definition of `XAssert'
drivers/block/built-in.o(.text+0x388c):drivers/block/xilinx_sysace/xbasic_types. 


c:87: first defined here
drivers/xilinx_edk/built-in.o(.text+0x50): In function `XNullHandler':
drivers/xilinx_edk/xbasic_types.c:153: multiple definition of 
`XNullHandler'
drivers/block/built-in.o(.text+0x38dc):drivers/block/xilinx_sysace/xbasic_types. 


c:136: first defined here
make[1]: *** [drivers/built-in.o] Error 1
make: *** [drivers] Error 2

This time I only tried on linux 2.6.17.1 version. Please check again and 
modify it. Thank you.

Regards
Ming

quoted

From: Ameet Patil <redacted>
To: Ming Liu <redacted>
CC: akonovalov@ru.mvista.com,  linuxppc-embedded@ozlabs.org
Subject: Re: some problems on the SystemACE driver.
Date: Wed, 12 Jul 2006 19:22:08 +0100

Hi Ming,
   Thanks for testing the driver patch! The errors you get when
compiling both - SysAce and TEMAC are reasonable. My ignorance or call
it me being lazy. I recollect now... I was also working on the Xilinx
Ethernet driver and forgot to cleanup that code before creating the
patch for the SysAce driver. Thus, it so happens that code for the
ethernet driver in my patch also gets compiled along with the TEMAC. I
have deleted the unnecessary code files and updated the patch (name
changed). Find the new one here:
https://www.cs.york.ac.uk/rtslab/demos/amos/xupv2pro/patches/linuxppc-2.6.17.1-sysace-1.1.patch 

quoted

Let me know if it works for you now?

-Ameet

Ming Liu wrote:

quoted

Dear Ameet (and Andrei),
I have tested the new patch for SystemACE driver. With respect to the
single SystemACE driver, it works well. I can boot my linux in ML403
board. (I tried both 2.6.16-rc5 and 2.6.17.1 versions) So first
congratulations and thanks for your hard work!

However, when I tried to implemented Temac (with and without SystemACE.
TWO conditions.), some errors happened. Here is the compilation
information:

 CC      init/do_mounts.o
 LD      init/mounts.o
 CC      init/initramfs.o
 LD      init/built-in.o
 LD      .tmp_vmlinux1
drivers/built-in.o(.sdata+0x2c): multiple definition of `XWaitInAssert'
arch/ppc/platforms/4xx/built-in.o(.sdata+0x0): first defined here
drivers/built-in.o(.text+0x3e480): In function 

`XPacketFifoV200a_WriteDre':

quoted

quoted

: multiple definition of `XPacketFifoV200a_WriteDre'
arch/ppc/platforms/4xx/built-in.o(.text+0x1b14): first defined here
drivers/built-in.o(.text+0x3e158): In function 

`XPacketFifoV200a_SelfTest':

quoted

quoted

: multiple definition of `XPacketFifoV200a_SelfTest'
arch/ppc/platforms/4xx/built-in.o(.text+0x17ec): first defined here
drivers/built-in.o(.sbss+0x18c): multiple definition of `XAssertStatus'
arch/ppc/platforms/4xx/built-in.o(.sbss+0x8): first defined here
drivers/built-in.o(.text+0x3e798): In function 

`XPacketFifoV200a_L0Write':

quoted

quoted

: multiple definition of `XPacketFifoV200a_L0Write'
arch/ppc/platforms/4xx/built-in.o(.text+0x1e2c): first defined here
drivers/built-in.o(.text+0x3e280): In function `XPacketFifoV200a_Read':
: multiple definition of `XPacketFifoV200a_Read'
arch/ppc/platforms/4xx/built-in.o(.text+0x1914): first defined here
drivers/built-in.o(.text+0x3e55c): In function 

`XPacketFifoV200a_L0Read':

quoted

quoted

: multiple definition of `XPacketFifoV200a_L0Read'
arch/ppc/platforms/4xx/built-in.o(.text+0x1bf0): first defined here
drivers/built-in.o(.text+0x3e380): In function 

`XPacketFifoV200a_Write':

quoted

quoted

: multiple definition of `XPacketFifoV200a_Write'
arch/ppc/platforms/4xx/built-in.o(.text+0x1a14): first defined here
drivers/built-in.o(.text+0x3e0cc): In function `XAssertSetCallback':
: multiple definition of `XAssertSetCallback'
arch/ppc/platforms/4xx/built-in.o(.text+0x44): first defined here
drivers/built-in.o(.text+0x3e9fc): In function
`XPacketFifoV200a_L0WriteDre':
: multiple definition of `XPacketFifoV200a_L0WriteDre'
arch/ppc/platforms/4xx/built-in.o(.text+0x2090): first defined here
drivers/built-in.o(.text+0x3e0dc): In function
`XPacketFifoV200a_Initialize':
: multiple definition of `XPacketFifoV200a_Initialize'
arch/ppc/platforms/4xx/built-in.o(.text+0x1770): first defined here
drivers/built-in.o(.text+0x3e088): In function `XAssert':
: multiple definition of `XAssert'
arch/ppc/platforms/4xx/built-in.o(.text+0x0): first defined here
drivers/built-in.o(.text+0x3e0d8): In function `XNullHandler':
: multiple definition of `XNullHandler'
arch/ppc/platforms/4xx/built-in.o(.text+0x50): first defined here
make: *** [.tmp_vmlinux1] Error 1

It looks like that your patch affect some symbols which are used by
Temac. (When I use the old patch for SystemACE, there is no problem 

like

quoted

quoted

this if I only choose Temac. ) So let's find out the problem together.
Also, I don't know if this is a problem from SystemACE or Temac , I
would like to invite Andrei to look at this altogether. If any
suggestion, please feel free to announce. Thanks for both your help.
Regards
Ming

quoted

From: Ameet Patil <redacted>
To: Ming Liu <redacted>
CC: linuxppc-embedded@ozlabs.org
Subject: Re: some problems on the SystemACE driver.
Date: Wed, 12 Jul 2006 10:54:13 +0100

Hi Ming,

quoted

I heard that you have tested this driver. Have you got this problem?
Why there are so many strange problems for me while you have tested
without problem?

Yes, that is right! When I say... I have tested - "it really means I
have tested". So what's the problem? It works for me but not you? The
obvious difference: mine is a ML300 configuration and yours ML403.

There were some files which unknowing were made dependant on ML300
target. I have now made them compile for both targets. It should work
fine for you now (Hopefully!). Download the updated patch from the 

same

quoted

quoted

quoted

location.

http://www.cs.york.ac.uk/rtslab/demos/amos/xupv2pro/patches/linuxppc-2.6.17_sysace.patch 

quoted

quoted

quoted

quoted

Since I don't have ML403 board, theres no way I can test this patch on
it. I rely on you in doing this... and thanks for letting me know the
issues.

WARNING: There might be more issues. :-)

Please DONOT hesitate to raise any issues with the driver. I am more
than happy to fix them.

-Ameet

Ming Liu wrote:

quoted

Dear Ameet,
Sorry to bother you again but I am totally confused on the systemACE
driver. First let me show you the problem.

1. I downloaded the linux kernel of 2.6.17.1, also the patch for
SystemACE driver. Applied the patch to the kernel. Replaced the
xparameters_ml403.h with the generated file xparameters_ml300.h from
Xilinx EDK. Make menuconfig, make dep and make zImage. Then the 

error

quoted

quoted

quoted

quoted

shows like this:

drivers/block/xilinx_sysace/xsysace.c:120:6: warning:
"XPAR_XSYSACE_MEM_WIDTH" is not defined
drivers/block/xilinx_sysace/xsysace.c: In function

`XSysAce_LookupConfig':

quoted

quoted

drivers/block/xilinx_sysace/xsysace.c:366: error:
`XPAR_XSYSACE_NUM_INSTANCES' undeclared (first use in this function)
drivers/block/xilinx_sysace/xsysace.c:366: error: (Each undeclared
identifier is reported only once
drivers/block/xilinx_sysace/xsysace.c:366: error: for each function 

it

quoted

quoted

quoted

quoted

appears in.)
make[3]: *** [drivers/block/xilinx_sysace/xsysace.o] Error 1
make[2]: *** [drivers/block/xilinx_sysace] Error 2
make[1]: *** [drivers/block] Error 2
make: *** [drivers] Error 2

I think this is because of the no inclusion of the xparameters 

header

quoted

quoted

quoted

quoted

file. So I change #include "xparameters.h" into  #include "

/home/mingliu/linux-2.6.17.1/arch/ppc/platforms/4xx/xparameters/xparameters.h" 

quoted

quoted

quoted

quoted

in the files of xsysace.c and xsysace_g.c, using the full address to
specify the header file. In fact, this is not a serious problem and 

it

quoted

quoted

quoted

quoted

often happens. But, after the modification, another problem 

happened:

quoted

quoted

quoted

quoted

 GEN     .version
 CHK     include/linux/compile.h
 UPD     include/linux/compile.h
 CC      init/version.o
 LD      init/built-in.o
 LD      .tmp_vmlinux1
drivers/built-in.o(.text+0x2234a): In function `XSysAce_GetCfgAddr':
: undefined reference to `XAssertStatus'
drivers/built-in.o(.text+0x2235e): In function `XSysAce_GetCfgAddr':
: undefined reference to `XAssertStatus'
drivers/built-in.o(.text+0x22364): In function `XSysAce_GetCfgAddr':
: undefined reference to `XAssert'
drivers/built-in.o(.text+0x22372): In function `XSysAce_GetCfgAddr':
: undefined reference to `XAssertStatus'
drivers/built-in.o(.text+0x2237a): In function `XSysAce_GetCfgAddr':
: undefined reference to `XAssertStatus'
drivers/built-in.o(.text+0x22394): In function `XSysAce_GetCfgAddr':
: undefined reference to `XAssert'
drivers/built-in.o(.text+0x223a2): In function `XSysAce_GetCfgAddr':
: undefined reference to `XAssertStatus'
drivers/built-in.o(.text+0x223aa): In function `XSysAce_GetCfgAddr':
: undefined reference to `XAssertStatus'
drivers/built-in.o(.text+0x22cd6): In function `XSysAce_Initialize':
: undefined reference to `XAssertStatus'
drivers/built-in.o(.text+0x22cdc): In function `XSysAce_Initialize':
: undefined reference to `XAssert'
drivers/built-in.o(.text+0x22cea): In function `XSysAce_Initialize':
: undefined reference to `XAssertStatus'

......( a long information to say that undefined reference to the
XAssert things.)

Also, I tried this in the kernel 2.6.16-rc5. (In fact I prefer this
version because the temac driver is for this version. ) The same

problem

quoted

quoted

happened. I checked the source code. The problem happened in the 

file

quoted

quoted

quoted

quoted

driver/block/xilinx_sysace/adapter.c, etc. Also, the XAssert things 

are

quoted

quoted

quoted

quoted

defined in the file 

arch/ppc/platforms/4xx/xilinx_ocp/xbasic_types.c.

quoted

quoted

quoted

quoted

(In 2.6.16 kernel, it is also defined in
driver/xilinx_edk/xbasic_types.c. There are two copies of this file. 

)

quoted

quoted

I

quoted

quoted

think the problem is, the systemACE files cannot link together with 

the

quoted

quoted

quoted

quoted

xbasic_types.c file.
I heard that you have tested this driver. Have you got this problem?

Why

quoted

quoted

there are so many strange problems for me while you have tested 

without

quoted

quoted

quoted

quoted

problem? Without the CF card, I cannot try the Temac driver and my 

work

quoted

quoted

quoted

quoted

is totally blocked. So I have to ask for your suggestion. Really

anxious

quoted

quoted

for your useful guidance. Thanks a lot!!!!!!

Regards
Ming

_________________________________________________________________
与联机的朋友进行交流，请使用 MSN Messenger:

http://messenger.msn.com/cn

quoted

quoted

_________________________________________________________________
免费下载 MSN Explorer:   http://explorer.msn.com/lccn/

_________________________________________________________________
免费下载 MSN Explorer:   http://explorer.msn.com/lccn/ 

Dear Ameet,

1. Which TEMAC patch are you using?
(http://source.mvista.com/~ank/paulus-powerpc/20060309/ppc32_xilinx_edk_temac.patch)

There are five patches in the directory 20060309 whose address is listed 
above by you. I applied all of them in my system, because without any there 
will be problems. 

2. After applying the patch, is the driver getting compiled directly
without having to select it via "make menuconfig"?

No. there is an option named "xilinx 10/100/1000 Mbit TEMAC support" in the 
menuconfig. I must select it and then compile the kernel. 

3. I don't see a Makefile in the drivers/net/xilinx_temac/ folder?

I have checked. In my kernel, there is the Makefile. I don't know why this 
happened to you.

Let me describe the detailed process I did. First, download the kernel 
2.6.17.1 (or 2.6.16-rc5). Then apply the five patches for Temac.(If I use 
2.6.17.1, I need to upgrade some files manually. For 2.6.16, there is no 
problem.) And then apply the patch for SystemACE. Also copy and replace the 
xparameters_ml403.h by my own file generated by EDK. Then make menuconfig, 
selecting both Temac and SystemACE and other basic options. Then make dep 
and make zImage. During this process, I need to modify some little problems 
which are about the inclusion of some header files, or specify some lib 
inclusion directories instead. Then that problem appears. There are some 
main points: 1. configured for ml403 board. 2.both Temac and SystemACE are 
selected. 3. 5 patches for Temac and 1 patch for SystemACE. 4. linux 
version is 2.6.17 or 2.6.16. I really have no idea why this still happens 
after your modification. So I have to ask you again. 

Ofcourse, I can work my way to compile the driver. But is there any doc.
present explaining this?

Sorry that there is no doc to explain this. I just did following the 
procedure described above. I am totally lost. The strange thing is, when I 
select only one of these two drivers, no problem, but if both, problem. 

By the way, I noticed that in the address where I get your patch, there is 
also a patch called linuxppc-2.6.17.1-sysace-1.0.patch which is much larger 
than the 1.1 one. I needn't apply the 1.0 one, right? 

Thanks for your hard work. Hopefully we can solve the problem. 

Regards
Ming

_________________________________________________________________
免费下载 MSN Explorer:   http://explorer.msn.com/lccn  

I am trying to get the Xilinx TEMAC working. I am getting an education
in Xilinx, TEMAC's, PHY's, ... in the process.

The hardware I have to support is the Hard TEMAC on the LocalLink Bus.
It is my understanding that this is the TEMAC builtin to the FX parts,
not one that is created in the FPGA.

Is anyone else working to support that configuration ? I think that is
basically the same as the GRSD TEMAC.
Is it sane to try to adapt the soft TEMAC patch from the list ?

I have a driver that works under uCos as a starting point. It initially
appeared to use basically the same xilinx_edk code that the linux temac
driver patch that has been the subject of a number of messages uses. But
on deeper inspection that dependence appears to be very shallow - mostly
using the edk macros to read the PHY and registers in the MAC.

Am I correct that the TEMAC patch floating arround is not for that TEMAC ?

I am also trying to digest the paternity of the TEMAC. Is the basic
programming of the hard TEMAC and the IP TEMAC the same ? i.e. does the
fact that the both have TEMAC in their name actually express some
commonality ? TEMAC means Tri-Mode EMAC - does that mean there is some
commonality with the IBM EMAC ?

I have a driver in the works that is based on the working uCos code I
mentioned, as well as I think the pcnet32 driver as a very basic template.
I seem to got the PHY portions working, but then addapted to the
separate PHY driver model with the MAC driver providing routines to
access the PHY registers. I may have that working. I think I have DCR
access to the MAC registers working. I am just starting on getting the
TX and RX code working.

I actually started trying to get the posted TEMAC patch working but that
quickly went off the rails - I presumed because the hard and soft
TEMAC's are just too different, or because the xilinx_edk really does
not support the hard TEMAC.

The xilinx_edk based driver seems incredibly complex. I think the OS
independent xilinx_edk incurrs a high cost in obscurity - but I am not
looking to gore someone elses ox, just solve my problem.

If the edk based driver is going to make it into the kernel, and
somebody who understands better than I beleives that it is reasonable to
adapt that to support the hard TEMAC too, I am willing to pursue that
approach.

Regardless. I need to get a driver working, and I am not looking to
duplicate effort.




-- 
Dave Lynch 					  	    DLA Systems
Software Development:  				         Embedded Linux
717.627.3770 	       dhlii@dlasys.net 	  http://www.dlasys.net
fax: 1.253.369.9244 			           Cell: 1.717.587.7774
Over 25 years' experience in platforms, languages, and technologies too numerous to list.

"Any intelligent fool can make things bigger and more complex... It takes a touch of genius - and a lot of courage to move in the opposite direction."
Albert Einstein

Hi Ming,
   Can you send me the entire text output (in a file) of the compilation
process with errors?

-Ameet

Ming Liu wrote:

Dear Ameet,

quoted

1. Which TEMAC patch are you using?
(http://source.mvista.com/~ank/paulus-powerpc/20060309/ppc32_xilinx_edk_temac.patch) 

There are five patches in the directory 20060309 whose address is listed 
above by you. I applied all of them in my system, because without any 
there will be problems.

quoted

2. After applying the patch, is the driver getting compiled directly
without having to select it via "make menuconfig"?

No. there is an option named "xilinx 10/100/1000 Mbit TEMAC support" in 
the menuconfig. I must select it and then compile the kernel.

quoted

3. I don't see a Makefile in the drivers/net/xilinx_temac/ folder?

I have checked. In my kernel, there is the Makefile. I don't know why 
this happened to you.

Let me describe the detailed process I did. First, download the kernel 
2.6.17.1 (or 2.6.16-rc5). Then apply the five patches for Temac.(If I 
use 2.6.17.1, I need to upgrade some files manually. For 2.6.16, there 
is no problem.) And then apply the patch for SystemACE. Also copy and 
replace the xparameters_ml403.h by my own file generated by EDK. Then 
make menuconfig, selecting both Temac and SystemACE and other basic 
options. Then make dep and make zImage. During this process, I need to 
modify some little problems which are about the inclusion of some header 
files, or specify some lib inclusion directories instead. Then that 
problem appears. There are some main points: 1. configured for ml403 
board. 2.both Temac and SystemACE are selected. 3. 5 patches for Temac 
and 1 patch for SystemACE. 4. linux version is 2.6.17 or 2.6.16. I 
really have no idea why this still happens after your modification. So I 
have to ask you again.

quoted

Ofcourse, I can work my way to compile the driver. But is there any doc.
present explaining this?

Sorry that there is no doc to explain this. I just did following the 
procedure described above. I am totally lost. The strange thing is, when 
I select only one of these two drivers, no problem, but if both, problem.
By the way, I noticed that in the address where I get your patch, there 
is also a patch called linuxppc-2.6.17.1-sysace-1.0.patch which is much 
larger than the 1.1 one. I needn't apply the 1.0 one, right?
Thanks for your hard work. Hopefully we can solve the problem.
Regards
Ming

_________________________________________________________________
免费下载 MSN Explorer:   http://explorer.msn.com/lccn 

Hi David,

The hardware I have to support is the Hard TEMAC on the LocalLink Bus.
It is my understanding that this is the TEMAC builtin to the FX parts,
not one that is created in the FPGA.

That's right. The hard Temac is a built-in hard core in virtex 4 FPGA. 

Is anyone else working to support that configuration ? I think that is
basically the same as the GRSD TEMAC.
Is it sane to try to adapt the soft TEMAC patch from the list ?

I am working on that. But I am not so experienced and still working. :)

I actually started trying to get the posted TEMAC patch working but that
quickly went off the rails - I presumed because the hard and soft
TEMAC's are just too different, or because the xilinx_edk really does
not support the hard TEMAC.

I don't think so. I think the hard and soft cores are similar. I have 
included the enet drive in Linux 2.4 and it works well. Now I am including 
the Temac in 2.6 and have not see the result. 

Regardless. I need to get a driver working, and I am not looking to
duplicate effort.

I am doing that. So we can share our experience. 

Regards
Ming

_________________________________________________________________
免费下载 MSN Explorer:   http://explorer.msn.com/lccn/