RE: Xilinx hard TEMAC

RE: Xilinx hard TEMAC

[Rick Moleres]

David,


<snip>
>=20
>     The choice and configuration of the TEMAC was driven by FPGA
> realestate.
>=20
>     My perception was that the "Hard" Temac was based on silicon
already
> in the FX (much like the PowerPC) while the "Soft" TEMAC is primarily
> implimented within the FPGA (much like the MicroBlaze).
>=20
>     Is that distinction between "soft" and "hard" correct ?
>=20

That is the correct distinction between "soft" and "hard".  Just know
that in this case the "soft" TEMAC (whether LL TEMAC or PLB TEMAC) uses
the "hard" TEMAC, and the "hard" TEMAC by itself is not that useful.

>      If not is the only significant distinction between the PLB_TEMAC
> supported by the EDK and the LL_TEMAC the bus interface ?

Yes, this is one of the distinctions between LL TEMAC and PLB TEMAC. :-)

>      I should not think the difference between different bus
interfaces
> should be radically different in terms of FPGA cells. While
implimenting
> the MAC in the FPGA would likely be expensive in realestate.
>       I can try to argue for the PLB_TEMAC - as something that will
have
> Xilinx/MV support and may get incorporated in the standard Kernel - If
> the cost in cells is not substantial.
>=20

I believe LL_TEMAC is smaller than PLB_TEMAC, and so this could be a
tough sell for you if FPGA space is at a premium.  When put in a system
with other stuff (e.g., memory controller, etc...) the size gets closer,
but I think GSRD is still smaller.  Sorry, I don't have the numbers.
There were improvements to PLB TEMAC in EDK 8.1.2 to address some size
issues, and even more planned down the road to hopefully converge the
two.

>=20
>=20
> > The Linux driver posted for the TEMAC (by MontaVista) is for the
> > PLB_TEMAC.  Updates to this driver may also be released with the EDK
> > (e.g., EDK 8.1.2 updated the driver to include checksum offload).
There
> > is a Linux driver for the LL_TEMAC that comes with GSRD, but my
group's
> > efforts go toward the PLB_TEMAC as that is the EDK IP we want to
promote
> > and whose drivers we'd like to see in kernel.org.
> >
>     How can I get a copy of the GSRD LL_TEMAC ? Is it a 2.4 or 2.6
driver
> ?
>=20

You should be able to go to http://www.xilinx.com/gsrd to get the GSRD
design, and inside of that design somewhere you'll find a Linux 2.4
driver for the LL TEMAC.

> > By the way, there is no relation to the IBM EMAC.
> >
>     These things are worth knowing.
>=20
>     The T still means Tri. is there some specific EMAC that was used
as
> a reference for the design or is the TEMAC entirely a Xilinx creation
?
>=20

It's a Xilinx creation as far as I know.

> > Hope that helps,
> > -Rick
> >

Re: Xilinx hard TEMAC

[David H. Lynch Jr.]

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

Rick Moleres wrote:
> That is the correct distinction between "soft" and "hard".  Just know
> that in this case the "soft" TEMAC (whether LL TEMAC or PLB TEMAC) uses
> the "hard" TEMAC, and the "hard" TEMAC by itself is not that useful.
>   
    First, thanks, your remarks have been enormously helpful.

    I have successfully put together a Driver for the TEMAC currently
used in the Pico E-12.
   
    I am still having some difficulty corresponding this TEMAC
implimentation to any of Xilinx's documentation.
    It is Exactly the TEMAC supported by the Xilinx uCOSII Treck Web
Server application.
    It seems to be extremely minimal. Basically a DCR interface for most
things that closely matches the GSRD documents.
    and TX and RX FIFO's that I can't seem to find documented anywhere,
but I have working based on the Treck WebServer code.

    I am have two remaining problems and then I am done.
   
       The first is I am currently doing polled I/O. The transmits
happen as they are requested and the receives are picked up ona a timer
interrupt.
    But I am dropping about 50% or more of the receives. I will work
that out myself eventually.

       The second is that this driver will serve as the basis for a
driver in other Pico supported OS's. Some of which have no means of
doing Polled Receives.
       And I can not get interrupts working. Since my hardware does nto
match anything perfectly - except that Treck Webserver application and
that does not do interrupts.
    I am reading all the Xilinx TEMAC Documents and the GSRD documents
reference an IRENABLE register and an IRSTATUS register, I cobbled
something together
    assuming that they were access much as the other DCR registers in
that block and I assumed the bits in IRSTATUS and IRENABLE matched the
definitions of those
    in larger TEMAC implimentations. It appeared after I enabled TX and
RX complete interrupts that when I have received data available the
IRSTATUS register has the
    Bit set for an Rx interrupt. All fine - except that no interrupt
actually occurs.
    I can force interrupts from the PHY using the same IRQ so the IRQ is
connected correctly and programmed correctly. Other TEMAC
implimentations seem to have a GIE - Global Interrupt enable
    Bit, but I do not have a clue where to look here. What I could get
out of the Xilinx Webset GSRD seems to be a Linux driver that uses the
DMA unit and that generates its own interrupts.
    I don't think I have the DMA in my bit image.

    Anyway any clues as to where I can find some useful docs on
Interrupt handling for the LL_TEMAC that is used by the uCOSII WebServer
application ?











> Thereis a Linux driver for the LL_TEMAC that comes with GSRD, but my
>   
> group's efforts go toward the PLB_TEMAC as that is the EDK IP we want to
>   
> promote and whose drivers we'd like to see in kernel.org.
>
> You should be able to go to http://www.xilinx.com/gsrd to get the GSRD
> design, and inside of that design somewhere you'll find a Linux 2.4
> driver for the LL TEMAC.
>   
>
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>   


-- 
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


[-- Attachment #2: Type: text/html, Size: 5207 bytes --]

RE: Xilinx hard TEMAC

[Rick Moleres]

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

David,

 

Could you send a system.mhs file from the EDK project you're using so I
can get a bearing on what exactly you have in the hardware?  I didn't
think the LL TEMAC could be used without the DMA engine (CDMAC), which
is where the interrupts come from in the Linux/VxWorks drivers I've seen
for this core.

 

-Rick

 

________________________________

From: David H. Lynch Jr. [mailto:dhlii@dlasys.net] 
Sent: Saturday, July 29, 2006 7:09 PM
To: Rick Moleres
Cc: linuxppc-embedded
Subject: Re: Xilinx hard TEMAC

 

Rick Moleres wrote: 

 
That is the correct distinction between "soft" and "hard".  Just know
that in this case the "soft" TEMAC (whether LL TEMAC or PLB TEMAC) uses
the "hard" TEMAC, and the "hard" TEMAC by itself is not that useful.
  

    First, thanks, your remarks have been enormously helpful.

    I have successfully put together a Driver for the TEMAC currently
used in the Pico E-12.
    
    I am still having some difficulty corresponding this TEMAC
implimentation to any of Xilinx's documentation.
    It is Exactly the TEMAC supported by the Xilinx uCOSII Treck Web
Server application.
    It seems to be extremely minimal. Basically a DCR interface for most
things that closely matches the GSRD documents.
    and TX and RX FIFO's that I can't seem to find documented anywhere,
but I have working based on the Treck WebServer code.

    I am have two remaining problems and then I am done.
    
       The first is I am currently doing polled I/O. The transmits
happen as they are requested and the receives are picked up ona a timer
interrupt.
    But I am dropping about 50% or more of the receives. I will work
that out myself eventually.

       The second is that this driver will serve as the basis for a
driver in other Pico supported OS's. Some of which have no means of
doing Polled Receives.
       And I can not get interrupts working. Since my hardware does nto
match anything perfectly - except that Treck Webserver application and
that does not do interrupts.
    I am reading all the Xilinx TEMAC Documents and the GSRD documents
reference an IRENABLE register and an IRSTATUS register, I cobbled
something together 
    assuming that they were access much as the other DCR registers in
that block and I assumed the bits in IRSTATUS and IRENABLE matched the
definitions of those 
    in larger TEMAC implimentations. It appeared after I enabled TX and
RX complete interrupts that when I have received data available the
IRSTATUS register has the 
    Bit set for an Rx interrupt. All fine - except that no interrupt
actually occurs.
    I can force interrupts from the PHY using the same IRQ so the IRQ is
connected correctly and programmed correctly. Other TEMAC
implimentations seem to have a GIE - Global Interrupt enable
    Bit, but I do not have a clue where to look here. What I could get
out of the Xilinx Webset GSRD seems to be a Linux driver that uses the
DMA unit and that generates its own interrupts.
    I don't think I have the DMA in my bit image.

    Anyway any clues as to where I can find some useful docs on
Interrupt handling for the LL_TEMAC that is used by the uCOSII WebServer
application ?














Thereis a Linux driver for the LL_TEMAC that comes with GSRD, but my
  
group's efforts go toward the PLB_TEMAC as that is the EDK IP we want to
  
promote and whose drivers we'd like to see in kernel.org.
 
You should be able to go to http://www.xilinx.com/gsrd to get the GSRD
design, and inside of that design somewhere you'll find a Linux 2.4
driver for the LL TEMAC.
  
 
_______________________________________________
Linuxppc-embedded mailing list
Linuxppc-embedded@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-embedded
  






-- 
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

[-- Attachment #2: Type: text/html, Size: 14014 bytes --]

RE: Xilinx hard TEMAC

[Rick Moleres]

David,

I'll see if I can clarify a bit.  In Virtex-4, there is a silicon-based
Hard TEMAC.  But in order to get to it (and have things like buffering
and DMA) you need a soft wrapper - which comes in two flavors.  One is
the LL_TEMAC, which is released as part of the GSRD reference design.
The other is PLB_TEMAC, which is released in the EDK.  The fundamental
difference between the two (I'm simplifying) is that the LL_TEMAC and
GSRD system keep data off the PLB bus, using LocalLink point-to-point
connections between the LL_TEMAC and the memory and DMA controllers.
The PLB_TEMAC's data path is over the PLB.  The LL_TEMAC also supports
both channels of the Hard TEMAC, whereas the PLB_TEMAC does not (yet).
Both are comparable in performance.  The PLB_TEMAC, as part of the EDK,
has the official Xilinx support that other EDK IP has, whereas LL_TEMAC
and GSRD are just a reference design.

The Linux driver posted for the TEMAC (by MontaVista) is for the
PLB_TEMAC.  Updates to this driver may also be released with the EDK
(e.g., EDK 8.1.2 updated the driver to include checksum offload).  There
is a Linux driver for the LL_TEMAC that comes with GSRD, but my group's
efforts go toward the PLB_TEMAC as that is the EDK IP we want to promote
and whose drivers we'd like to see in kernel.org.

By the way, there is no relation to the IBM EMAC.

Hope that helps,
-Rick

-----Original Message-----
From: linuxppc-embedded-bounces+moleres=3Dxilinx.com@ozlabs.org
[mailto:linuxppc-embedded-bounces+moleres=3Dxilinx.com@ozlabs.org] On
Behalf Of David H. Lynch Jr.
Sent: Thursday, July 13, 2006 5:50 PM
To: linuxppc-embedded
Subject: Xilinx hard TEMAC


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.




--=20
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

_______________________________________________
Linuxppc-embedded mailing list
Linuxppc-embedded@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-embedded

Re: Xilinx hard TEMAC

[David H. Lynch Jr.]

Rick Moleres wrote:
> David,
>
> I'll see if I can clarify a bit.  In Virtex-4, there is a silicon-based
> Hard TEMAC.  But in order to get to it (and have things like buffering
> and DMA) you need a soft wrapper - which comes in two flavors.  One is
> the LL_TEMAC, which is released as part of the GSRD reference design.
> The other is PLB_TEMAC, which is released in the EDK.  The fundamental
> difference between the two (I'm simplifying) is that the LL_TEMAC and
> GSRD system keep data off the PLB bus, using LocalLink point-to-point
> connections between the LL_TEMAC and the memory and DMA controllers.
> The PLB_TEMAC's data path is over the PLB.  The LL_TEMAC also supports
> both channels of the Hard TEMAC, whereas the PLB_TEMAC does not (yet).
> Both are comparable in performance.  The PLB_TEMAC, as part of the EDK,
> has the official Xilinx support that other EDK IP has, whereas LL_TEMAC
> and GSRD are just a reference design.
>   
    Thanks, you have clarified things somewhat. I was vaguely aware of
the differences between the locallink and PLB.

    Though I still have some confusion.

    In my environment FPGA space is precious. The FPGA firmware for
Linux uses the UartLite, and does not include a PIC.
    The objective is to leave as much of the FPGA available for
application use as possible. Some current uses of the remaining FPGA
space have included
    decryption engines and FFT's. I am not part of the firmware process
- I am just responsible for Linux and any requests I make that require
more FPGA realestate
    tend to get stomped on.

    The choice and configuration of the TEMAC was driven by FPGA realestate.

    My perception was that the "Hard" Temac was based on silicon already
in the FX (much like the PowerPC) while the "Soft" TEMAC is primarily
implimented within the FPGA (much like the MicroBlaze).

    Is that distinction between "soft" and "hard" correct ?

     If not is the only significant distinction between the PLB_TEMAC
supported by the EDK and the LL_TEMAC the bus interface ?
     I should not think the difference between different bus interfaces
should be radically different in terms of FPGA cells. While implimenting
the MAC in the FPGA would likely be expensive in realestate.
      I can try to argue for the PLB_TEMAC - as something that will have
Xilinx/MV support and may get incorporated in the standard Kernel - If
the cost in cells is not substantial.
   
   

> The Linux driver posted for the TEMAC (by MontaVista) is for the
> PLB_TEMAC.  Updates to this driver may also be released with the EDK
> (e.g., EDK 8.1.2 updated the driver to include checksum offload).  There
> is a Linux driver for the LL_TEMAC that comes with GSRD, but my group's
> efforts go toward the PLB_TEMAC as that is the EDK IP we want to promote
> and whose drivers we'd like to see in kernel.org.
>   
    How can I get a copy of the GSRD LL_TEMAC ? Is it a 2.4 or 2.6 driver ?

> By the way, there is no relation to the IBM EMAC.
>   
    These things are worth knowing.

    The T still means Tri. is there some specific EMAC that was used as
a reference for the design or is the TEMAC entirely a Xilinx creation ?

> Hope that helps,
> -Rick
>
>   


-- 
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

Re: some problems on the SystemACE driver.

[Ameet Patil]

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
> 
> 
>> From: Ameet Patil <ammubhai@gmail.com>
>> To: Ming Liu <eemingliu@hotmail.com>
>> 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 
>>
> 
>>
>> Let me know if it works for you now?
>>
>> -Ameet
>>
>> Ming Liu wrote:
>> > 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':
>> > : 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':
>> > : 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':
>> > : 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':
>> > : 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':
>> > : 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
>> > 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
>> >
>> >
>> >
>> >> From: Ameet Patil <ammubhai@gmail.com>
>> >> To: Ming Liu <eemingliu@hotmail.com>
>> >> CC: linuxppc-embedded@ozlabs.org
>> >> Subject: Re: some problems on the SystemACE driver.
>> >> Date: Wed, 12 Jul 2006 10:54:13 +0100
>> >>
>> >> Hi Ming,
>> >>
>> >> > 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
>> >> location.
>> >>
>> >> 
> http://www.cs.york.ac.uk/rtslab/demos/amos/xupv2pro/patches/linuxppc-2.6.17_sysace.patch 
> 
> 
>> >>
>> >
>> >>
>> >> 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:
>> >> > 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
>> >> > 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':
>> >> > 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
>> >> > 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
>> >> > file. So I change #include "xparameters.h" into  #include "
>> >> >
>> > 
> /home/mingliu/linux-2.6.17.1/arch/ppc/platforms/4xx/xparameters/xparameters.h" 
> 
> 
>> >
>> >
>> >> > 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
>> >> > often happens. But, after the modification, another problem 
> happened:
>> >> >  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
>> >> > happened. I checked the source code. The problem happened in the 
> file
>> >> > driver/block/xilinx_sysace/adapter.c, etc. Also, the XAssert things 
> are
>> >> > defined in the file 
> arch/ppc/platforms/4xx/xilinx_ocp/xbasic_types.c.
>> >> > (In 2.6.16 kernel, it is also defined in
>> >> > driver/xilinx_edk/xbasic_types.c. There are two copies of this file. 
> )
>> > I
>> >> > think the problem is, the systemACE files cannot link together with 
> the
>> >> > xbasic_types.c file.
>> >> > 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? Without the CF card, I cannot try the Temac driver and my 
> work
>> >> > is totally blocked. So I have to ask for your suggestion. Really
>> > anxious
>> >> > for your useful guidance. Thanks a lot!!!!!!
>> >> >
>> >> > Regards
>> >> > Ming
>> >> >
>> >> > _________________________________________________________________
>> >> > 与联机的朋友进行交流，请使用 MSN Messenger:
>> > http://messenger.msn.com/cn
>> >> >
>> >
>> > _________________________________________________________________
>> > 免费下载 MSN Explorer:   http://explorer.msn.com/lccn/
>> >
> 
> _________________________________________________________________
> 免费下载 MSN Explorer:   http://explorer.msn.com/lccn/ 
> 

Xilinx hard TEMAC

[David H. Lynch Jr.]

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

RE: Xilinx hard TEMAC

[Ming Liu]

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/