Ethernet driver for Linux kernel 2.6 running on ML403

Ethernet driver for Linux kernel 2.6 running on ML403

[Aleck Lin]

Hi,

I'm able to boot Linux 2.6 on ML403 board (with a ramdisk file system).

However, during the kernel booting, it complains that "No network devices
available," So I figured I probably didn't enable the ethernet driver in the
kernel. 

>From doing "make menuconfig", under "Device Drivers" --> "Network device
support" --> "Ethernet(10 or 100Mbit)", I checked the box of both "Ethernet
(10 or 100Mbit)" and "PowerPC 4xx on-chip Ethernet support." I then
save/exit the menuconfig to compile the kernel again. I've attached the
error output at the bottom.

The problem is that I don't have any define in my .config file that matches
"CONFIG_405GP", "CONFIG_405GPR" or "CONFIG_405EP" in the
/drivers/net/ibm_emac/ibm_emac.h file, so it complains that I might not have
correct defines. 

1st question: Which one of the CONFIG_405xxx should I use? I was searching
around but couldn't find an answer, but my intuition tells me that it should
probably be CONFIG_405GP.

2nd question: So I decided to try with CONFIG_405GP just to see what
happens. However, some compilation errors were still there. And it complains
about "dereferencing pointer to incomplete type". Does anyone have any
experience working with this driver and perhaps found that there's an error
in the kernel for this driver?

Thanks,

Aleck


------------------------------------------------------------------------
In file included from drivers/net/ibm_emac/ibm_emac_core.h:28,
                 from drivers/net/ibm_emac/ibm_emac_mal.c:33:
drivers/net/ibm_emac/ibm_emac.h:31:2: error: #error "Unknown SoC. Please,
check chip user manual and make sure EMAC defines are OK"
In file included from drivers/net/ibm_emac/ibm_emac_core.h:32,
                 from drivers/net/ibm_emac/ibm_emac_mal.c:33:
drivers/net/ibm_emac/ibm_emac_mal.h:42:2: error: #error "Unknown SoC, please
check chip manual and choose MAL 'version'"
drivers/net/ibm_emac/ibm_emac_mal.h:53:5: warning: "MAL_VERSION" is not
defined
drivers/net/ibm_emac/ibm_emac_mal.h:61:7: warning: "MAL_VERSION" is not
defined
drivers/net/ibm_emac/ibm_emac_mal.h:72:2: error: #error "Unknown MAL
version"
drivers/net/ibm_emac/ibm_emac_mal.h:88:5: warning: "MAL_VERSION" is not
defined
drivers/net/ibm_emac/ibm_emac_mal.h:91:7: warning: "MAL_VERSION" is not
defined
drivers/net/ibm_emac/ibm_emac_mal.h:99:2: error: #error "Unknown MAL
version"
drivers/net/ibm_emac/ibm_emac_mal.h:107:5: warning: "MAL_VERSION" is not
defined
drivers/net/ibm_emac/ibm_emac_mal.h:110:7: warning: "MAL_VERSION" is not
defined
drivers/net/ibm_emac/ibm_emac_mal.h:116:2: error: #error "Unknown MAL
version"
drivers/net/ibm_emac/ibm_emac_mal.c: In function 'mal_register_commac':
drivers/net/ibm_emac/ibm_emac_mal.c:50: error: dereferencing pointer to
incomplete type
drivers/net/ibm_emac/ibm_emac_mal.c: In function 'mal_set_rcbs':
drivers/net/ibm_emac/ibm_emac_mal.c:80: error: dereferencing pointer to
incomplete type
drivers/net/ibm_emac/ibm_emac_mal.c:81: error: dereferencing pointer to
incomplete type
drivers/net/ibm_emac/ibm_emac_mal.c:81: error: dereferencing pointer to
incomplete type
drivers/net/ibm_emac/ibm_emac_mal.c:81: error: dereferencing pointer to
incomplete type
drivers/net/ibm_emac/ibm_emac_mal.c:89: error: dereferencing pointer to
incomplete type
drivers/net/ibm_emac/ibm_emac_mal.c: In function 'mal_tx_bd_offset':
drivers/net/ibm_emac/ibm_emac_mal.c:99: error: dereferencing pointer to
incomplete type
drivers/net/ibm_emac/ibm_emac_mal.c:100: error: dereferencing pointer to
incomplete type
drivers/net/ibm_emac/ibm_emac_mal.c:100: error: dereferencing pointer to
incomplete type
drivers/net/ibm_emac/ibm_emac_mal.c:100: error: dereferencing pointer to
incomplete type
drivers/net/ibm_emac/ibm_emac_mal.c: In function 'mal_rx_bd_offset':
drivers/net/ibm_emac/ibm_emac_mal.c:106: error: dereferencing pointer to
incomplete type
drivers/net/ibm_emac/ibm_emac_mal.c:107: error: dereferencing pointer to
incomplete type
drivers/net/ibm_emac/ibm_emac_mal.c:107: error: dereferencing pointer to
incomplete type
drivers/net/ibm_emac/ibm_emac_mal.c:107: error: dereferencing pointer to
incomplete type
drivers/net/ibm_emac/ibm_emac_mal.c:108: error: dereferencing pointer to
incomplete type
drivers/net/ibm_emac/ibm_emac_mal.c: In function 'mal_serr':
drivers/net/ibm_emac/ibm_emac_mal.c:196: error: dereferencing pointer to
incomplete type
drivers/net/ibm_emac/ibm_emac_mal.c:204: error: dereferencing pointer to
incomplete type
drivers/net/ibm_emac/ibm_emac_mal.c: In function 'mal_txde':
drivers/net/ibm_emac/ibm_emac_mal.c:250: error: dereferencing pointer to
incomplete type
drivers/net/ibm_emac/ibm_emac_mal.c: In function 'mal_reset':
drivers/net/ibm_emac/ibm_emac_mal.c:359: error: dereferencing pointer to
incomplete type
drivers/net/ibm_emac/ibm_emac_mal.c: In function 'mal_dump_regs':
drivers/net/ibm_emac/ibm_emac_mal.c:372: error: dereferencing pointer to
incomplete type
drivers/net/ibm_emac/ibm_emac_mal.c:375: error: 'MAL_VERSION' undeclared
(first use in this function)
drivers/net/ibm_emac/ibm_emac_mal.c:375: error: (Each undeclared identifier
is reported only once
drivers/net/ibm_emac/ibm_emac_mal.c:375: error: for each function it appears
in.)
drivers/net/ibm_emac/ibm_emac_mal.c:376: error: dereferencing pointer to
incomplete type
drivers/net/ibm_emac/ibm_emac_mal.c:378: error: dereferencing pointer to
incomplete type
drivers/net/ibm_emac/ibm_emac_mal.c:379: error: dereferencing pointer to
incomplete type
drivers/net/ibm_emac/ibm_emac_mal.c: In function 'mal_probe':
drivers/net/ibm_emac/ibm_emac_mal.c:411: error: dereferencing pointer to
incomplete type
drivers/net/ibm_emac/ibm_emac_mal.c:414: error: dereferencing pointer to
incomplete type
drivers/net/ibm_emac/ibm_emac_mal.c:422: error: dereferencing pointer to
incomplete type
drivers/net/ibm_emac/ibm_emac_mal.c:425: error: dereferencing pointer to
incomplete type
drivers/net/ibm_emac/ibm_emac_mal.c:426: error: dereferencing pointer to
incomplete type
drivers/net/ibm_emac/ibm_emac_mal.c:441: error: 'MAL_CFG_DEFAULT' undeclared
(first use in this function)
drivers/net/ibm_emac/ibm_emac_mal.c:447: error: dereferencing pointer to
incomplete type
drivers/net/ibm_emac/ibm_emac_mal.c:447: error: dereferencing pointer to
incomplete type
drivers/net/ibm_emac/ibm_emac_mal.c:447: error: dereferencing pointer to
incomplete type
drivers/net/ibm_emac/ibm_emac_mal.c:447: error: dereferencing pointer to
incomplete type
drivers/net/ibm_emac/ibm_emac_mal.c:447: error: dereferencing pointer to
incomplete type
drivers/net/ibm_emac/ibm_emac_mal.c:447: error: dereferencing pointer to
incomplete type
drivers/net/ibm_emac/ibm_emac_mal.c:448: error: dereferencing pointer to
incomplete type
drivers/net/ibm_emac/ibm_emac_mal.c:448: error: dereferencing pointer to
incomplete type
drivers/net/ibm_emac/ibm_emac_mal.c:448: error: dereferencing pointer to
incomplete type
drivers/net/ibm_emac/ibm_emac_mal.c:448: error: dereferencing pointer to
incomplete type
drivers/net/ibm_emac/ibm_emac_mal.c:448: error: dereferencing pointer to
incomplete type
drivers/net/ibm_emac/ibm_emac_mal.c:448: error: dereferencing pointer to
incomplete type
drivers/net/ibm_emac/ibm_emac_mal.c:450: error: dereferencing pointer to
incomplete type
drivers/net/ibm_emac/ibm_emac_mal.c:451: error: dereferencing pointer to
incomplete type
drivers/net/ibm_emac/ibm_emac_mal.c:453: error: dereferencing pointer to
incomplete type
drivers/net/ibm_emac/ibm_emac_mal.c:458: error: dereferencing pointer to
incomplete type
drivers/net/ibm_emac/ibm_emac_mal.c:464: error: dereferencing pointer to
incomplete type
drivers/net/ibm_emac/ibm_emac_mal.c:469: error: dereferencing pointer to
incomplete type
drivers/net/ibm_emac/ibm_emac_mal.c:474: error: dereferencing pointer to
incomplete type
drivers/net/ibm_emac/ibm_emac_mal.c:477: error: dereferencing pointer to
incomplete type
drivers/net/ibm_emac/ibm_emac_mal.c:480: error: dereferencing pointer to
incomplete type
drivers/net/ibm_emac/ibm_emac_mal.c:483: error: dereferencing pointer to
incomplete type
drivers/net/ibm_emac/ibm_emac_mal.c:486: error: dereferencing pointer to
incomplete type
drivers/net/ibm_emac/ibm_emac_mal.c:491: error: 'MAL_IER_SOC_EVENTS'
undeclared (first use in this function)
drivers/net/ibm_emac/ibm_emac_mal.c:494: warning: implicit declaration of
function 'ocp_set_drvdata'
drivers/net/ibm_emac/ibm_emac_mal.c:499: error: dereferencing pointer to
incomplete type
drivers/net/ibm_emac/ibm_emac_mal.c:499: error: dereferencing pointer to
incomplete type
drivers/net/ibm_emac/ibm_emac_mal.c:499: error: dereferencing pointer to
incomplete type
drivers/net/ibm_emac/ibm_emac_mal.c:503: error: dereferencing pointer to
incomplete type
drivers/net/ibm_emac/ibm_emac_mal.c:505: error: dereferencing pointer to
incomplete type
drivers/net/ibm_emac/ibm_emac_mal.c:507: error: dereferencing pointer to
incomplete type
drivers/net/ibm_emac/ibm_emac_mal.c:509: error: dereferencing pointer to
incomplete type
drivers/net/ibm_emac/ibm_emac_mal.c:511: error: dereferencing pointer to
incomplete type
drivers/net/ibm_emac/ibm_emac_mal.c: In function 'mal_remove':
drivers/net/ibm_emac/ibm_emac_mal.c:519: warning: implicit declaration of
function 'ocp_get_drvdata'
drivers/net/ibm_emac/ibm_emac_mal.c:519: warning: initialization makes
pointer from integer without a cast
drivers/net/ibm_emac/ibm_emac_mal.c:520: error: dereferencing pointer to
incomplete type
drivers/net/ibm_emac/ibm_emac_mal.c:534: error: dereferencing pointer to
incomplete type
drivers/net/ibm_emac/ibm_emac_mal.c:539: error: dereferencing pointer to
incomplete type
drivers/net/ibm_emac/ibm_emac_mal.c:540: error: dereferencing pointer to
incomplete type
drivers/net/ibm_emac/ibm_emac_mal.c:541: error: dereferencing pointer to
incomplete type
drivers/net/ibm_emac/ibm_emac_mal.c:542: error: dereferencing pointer to
incomplete type
drivers/net/ibm_emac/ibm_emac_mal.c:543: error: dereferencing pointer to
incomplete type
drivers/net/ibm_emac/ibm_emac_mal.c:549: error: dereferencing pointer to
incomplete type
drivers/net/ibm_emac/ibm_emac_mal.c:551: error: dereferencing pointer to
incomplete type
drivers/net/ibm_emac/ibm_emac_mal.c:552: error: dereferencing pointer to
incomplete type
drivers/net/ibm_emac/ibm_emac_mal.c: At top level:
drivers/net/ibm_emac/ibm_emac_mal.c:559: error: array type has incomplete
element type
drivers/net/ibm_emac/ibm_emac_mal.c:560: error: field name not in record or
union initializer
drivers/net/ibm_emac/ibm_emac_mal.c:560: error: (near initialization for
'mal_ids')
drivers/net/ibm_emac/ibm_emac_mal.c:560: error: field name not in record or
union initializer
drivers/net/ibm_emac/ibm_emac_mal.c:560: error: (near initialization for
'mal_ids')
drivers/net/ibm_emac/ibm_emac_mal.c:561: error: field name not in record or
union initializer
drivers/net/ibm_emac/ibm_emac_mal.c:561: error: (near initialization for
'mal_ids')
drivers/net/ibm_emac/ibm_emac_mal.c:564: error: variable 'mal_driver' has
initializer but incomplete type
drivers/net/ibm_emac/ibm_emac_mal.c:565: error: unknown field 'name'
specified in initializer
drivers/net/ibm_emac/ibm_emac_mal.c:565: warning: excess elements in struct
initializer
drivers/net/ibm_emac/ibm_emac_mal.c:565: warning: (near initialization for
'mal_driver')
drivers/net/ibm_emac/ibm_emac_mal.c:566: error: unknown field 'id_table'
specified in initializer
drivers/net/ibm_emac/ibm_emac_mal.c:566: warning: excess elements in struct
initializer
drivers/net/ibm_emac/ibm_emac_mal.c:566: warning: (near initialization for
'mal_driver')
drivers/net/ibm_emac/ibm_emac_mal.c:568: error: unknown field 'probe'
specified in initializer
drivers/net/ibm_emac/ibm_emac_mal.c:568: warning: excess elements in struct
initializer
drivers/net/ibm_emac/ibm_emac_mal.c:568: warning: (near initialization for
'mal_driver')
drivers/net/ibm_emac/ibm_emac_mal.c:569: error: unknown field 'remove'
specified in initializer
drivers/net/ibm_emac/ibm_emac_mal.c:569: warning: excess elements in struct
initializer
drivers/net/ibm_emac/ibm_emac_mal.c:569: warning: (near initialization for
'mal_driver')
drivers/net/ibm_emac/ibm_emac_mal.c: In function 'mal_init':
drivers/net/ibm_emac/ibm_emac_mal.c:575: warning: implicit declaration of
function 'ocp_register_driver'
drivers/net/ibm_emac/ibm_emac_mal.c: In function 'mal_exit':
drivers/net/ibm_emac/ibm_emac_mal.c:581: warning: implicit declaration of
function 'ocp_unregister_driver'
make[3]: *** [drivers/net/ibm_emac/ibm_emac_mal.o] Error 1
make[2]: *** [drivers/net/ibm_emac] Error 2
make[1]: *** [drivers/net] Error 2
make: *** [drivers] Error 2
---------------------------------------------------------------------------

Re: Ethernet driver for Linux kernel 2.6 running on ML403

[Eugene Surovegin]

On Wed, Sep 13, 2006 at 06:40:40PM -0700, Aleck Lin wrote:
> Hi,
> 
> I'm able to boot Linux 2.6 on ML403 board (with a ramdisk file system).
> 
> However, during the kernel booting, it complains that "No network devices
> available," So I figured I probably didn't enable the ethernet driver in the
> kernel. 
> 
> >From doing "make menuconfig", under "Device Drivers" --> "Network device
> support" --> "Ethernet(10 or 100Mbit)", I checked the box of both "Ethernet
> (10 or 100Mbit)" and "PowerPC 4xx on-chip Ethernet support." I then
> save/exit the menuconfig to compile the kernel again. I've attached the
> error output at the bottom.
> 
> The problem is that I don't have any define in my .config file that matches
> "CONFIG_405GP", "CONFIG_405GPR" or "CONFIG_405EP" in the
> /drivers/net/ibm_emac/ibm_emac.h file, so it complains that I might not have
> correct defines. 

Yes, I put that check there exactly to prevent people from using my 
driver on non-compatible hardware :).

> 1st question: Which one of the CONFIG_405xxx should I use? I was searching
> around but couldn't find an answer, but my intuition tells me that it should
> probably be CONFIG_405GP.

No.

> 2nd question: So I decided to try with CONFIG_405GP just to see what
> happens. However, some compilation errors were still there. And it complains
> about "dereferencing pointer to incomplete type". Does anyone have any
> experience working with this driver and perhaps found that there's an error
> in the kernel for this driver?

This driver isn't for your chip and simply cannot work.

-- 
Eugene

Re: Ethernet driver for Linux kernel 2.6 running on ML403

[Grant Likely]

On 9/13/06, Aleck Lin <aleck@gdatech.com> wrote:
> Hi,
>
> I'm able to boot Linux 2.6 on ML403 board (with a ramdisk file system).
>
> However, during the kernel booting, it complains that "No network devices
> available," So I figured I probably didn't enable the ethernet driver in the
> kernel.
>
> >From doing "make menuconfig", under "Device Drivers" --> "Network device
> support" --> "Ethernet(10 or 100Mbit)", I checked the box of both "Ethernet
> (10 or 100Mbit)" and "PowerPC 4xx on-chip Ethernet support." I then
> save/exit the menuconfig to compile the kernel again. I've attached the
> error output at the bottom.

The virtex eth device is not the same as 4xx on-chip Ethernet, so
CONFIG_IBM_EMAC will not work.  You need the xilinx_enet driver (which
is not in mainline).  It might be in MontaVista's 2.6 tree.

I think people have posted patches for it to this list, so try
searching the archives.  (I don't have a link off the top of my head.)

-- 
Grant Likely, B.Sc. P.Eng.
Secret Lab Technologies Ltd.
grant.likely@secretlab.ca
(403) 399-0195

Re: Ethernet driver for Linux kernel 2.6 running on ML403

[David H. Lynch Jr.]

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

Grant Likely wrote:
> On 9/13/06, Aleck Lin <aleck@gdatech.com> wrote:
>   
>> Hi,
>>
>> I'm able to boot Linux 2.6 on ML403 board (with a ramdisk file system).
>>
>> However, during the kernel booting, it complains that "No network devices
>> available," So I figured I probably didn't enable the ethernet driver in the
>> kernel.
>>
>> >From doing "make menuconfig", under "Device Drivers" --> "Network device
>> support" --> "Ethernet(10 or 100Mbit)", I checked the box of both "Ethernet
>> (10 or 100Mbit)" and "PowerPC 4xx on-chip Ethernet support." I then
>> save/exit the menuconfig to compile the kernel again. I've attached the
>> error output at the bottom.
>>     
>
> The virtex eth device is not the same as 4xx on-chip Ethernet, so
> CONFIG_IBM_EMAC will not work.  You need the xilinx_enet driver (which
> is not in mainline).  It might be in MontaVista's 2.6 tree.
>
> I think people have posted patches for it to this list, so try
> searching the archives.  (I don't have a link off the top of my head.)
>   
    The MV 2.6 Xilinx_edk based TEMAC driver has been posted to this 
list several times.

    As of the last incarnation I tried it had no MII/PHY support and you 
had to manully change the speed of the driver 10/100/1000 by editing the 
code.
    Otherwise it worked with the PLB FIFO TEMAC, that I am using, and 
should with others.

    I have a polled driver that works with the LL TEMAC.
    I am nearly finished a PLB FIFO TEMAC driver that includes working 
autonegotiation and does not use the Xilinx_edk.
    But right now it has a receive problem - packets come in they look 
good but linux silently discards them.

    I have virtually the same code working under GHS Integrity.




-- 
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: 2992 bytes --]

Re: Ethernet driver for Linux kernel 2.6 running on ML403

[Michael Galassi]

>> The virtex eth device is not the same as 4xx on-chip Ethernet, so
>> CONFIG_IBM_EMAC will not work.  You need the xilinx_enet driver (which
>> is not in mainline).  It might be in MontaVista's 2.6 tree.
>>
>> I think people have posted patches for it to this list, so try
>> searching the archives.  (I don't have a link off the top of my head.)
>>   
>    The MV 2.6 Xilinx_edk based TEMAC driver has been posted to this 
>list several times.
>
>    As of the last incarnation I tried it had no MII/PHY support and you 
>had to manully change the speed of the driver 10/100/1000 by editing the 
>code.

It is also worth noting that as released in MVL pro 4.0.1 it only
supports hard_temac 1.00.a and plb_temac 2.00.a, both of which are
tagged as deprecated in the current version (8.2.01i) of Xilinx's
EDK. The current version of {plb,hard}_temac (3.00.a) goes to great
lengths to break compatibility with older versions.  This will
presumably be fixed next month when it is rumored that wonderful new
things will come from Xilinx.  In the mean-time it is possible, though
neither simple, nor fun, to create Virtex4 designs with the older IP.

-michael

Re: Ethernet driver for Linux kernel 2.6 running on ML403

[Grant Likely]

On 9/14/06, Michael Galassi <mgalassi@c-cor.com> wrote:
> It is also worth noting that as released in MVL pro 4.0.1 it only
> supports hard_temac 1.00.a and plb_temac 2.00.a, both of which are
> tagged as deprecated in the current version (8.2.01i) of Xilinx's
> EDK. The current version of {plb,hard}_temac (3.00.a) goes to great
> lengths to break compatibility with older versions.  This will
> presumably be fixed next month when it is rumored that wonderful new
> things will come from Xilinx.  In the mean-time it is possible, though
> neither simple, nor fun, to create Virtex4 designs with the older IP.

So what direction do we (as the community) want to go for supporting
Xilinx IP in the Linux kernel?

IIRC, Xilinx intends to get drivers submitted into mainline.  (Based
on their cross-platform driver support code).  It is unknown which and
how many drivers for different IP versions will be submitted.

However, the xilinx driver code is verbose and does not match well
with the rest of the Linux code base.  (due to the cross platform
support)  Plus, the Xilinx tool work flow is geared towards the EDK
tool overwriting the driver code in the kernel tree with code for the
generated design.  In which case, does it even make sense to accept
Xilinx drivers into the Linux tree when they are just going to get
overwritten by the toolchain anyway?  Unfortunately, regenerating
drivers has it's own problems considering that the license on the
generated code is not GPL compatible at the moment.

If we reject the Xilinx driver code, then we either have to do without
Xilinx support in mainline, or we need to write new drivers that
address the above issues (support multiple IP versions, etc).  The
Xilinx support in mainline right now does not use any Xilinx code.
(Xilinx PIC and UART).

Thoughts?

g.

-- 
Grant Likely, B.Sc. P.Eng.
Secret Lab Technologies Ltd.
grant.likely@secretlab.ca
(403) 399-0195

Re: Ethernet driver for Linux kernel 2.6 running on ML403

[Keith J Outwater]

Grant,
You bring up excellent points, and I am having to deal with these
issues in my 2.4.x kernel and U-Boot ports to VirtexII Pro FPGAs
as well.

> On 9/14/06, Michael Galassi <mgalassi@c-cor.com> wrote:
> > It is also worth noting that as released in MVL pro 4.0.1 it only
> > supports hard_temac 1.00.a and plb_temac 2.00.a, both of which are
> > tagged as deprecated in the current version (8.2.01i) of Xilinx's
> > EDK. The current version of {plb,hard}_temac (3.00.a) goes to great
> > lengths to break compatibility with older versions.  This will
> > presumably be fixed next month when it is rumored that wonderful new
> > things will come from Xilinx.  In the mean-time it is possible, though
> > neither simple, nor fun, to create Virtex4 designs with the older IP.

I think the general case is that Xilinx IP will be constantly evolving, 
and
Xilinx driver code, when released under the GPL, will appear sporadically.
Maybe it's best to resign ourselves to the fact that this situation
probably won't change, and then try to deal with it in a way that does
not depend so heavily on Xilinx drivers.

> 
> So what direction do we (as the community) want to go for supporting
> Xilinx IP in the Linux kernel?

I don't know about anyone else, but running Linux on Virtex FPGAs is
something I simply have to be able to do.  With or without Xilinx
drivers, I think the kernel needs to support Xilinx hardware.

> 
> IIRC, Xilinx intends to get drivers submitted into mainline.  (Based
> on their cross-platform driver support code).  It is unknown which and
> how many drivers for different IP versions will be submitted.

That's part of the problem: we seem to get support for some
IP cores, but not all.  Xilinx takes a piecemeal approach
to releasing drivers under the GPL.

> 
> However, the xilinx driver code is verbose and does not match well
> with the rest of the Linux code base.  (due to the cross platform
> support)  Plus, the Xilinx tool work flow is geared towards the EDK
> tool overwriting the driver code in the kernel tree with code for the
> generated design.  In which case, does it even make sense to accept
> Xilinx drivers into the Linux tree when they are just going to get
> overwritten by the toolchain anyway?  Unfortunately, regenerating
> drivers has it's own problems considering that the license on the
> generated code is not GPL compatible at the moment.

Same complaints apply for Xilinx drivers in the U-Boot bootloader.
It is proving very difficult to get Xilinx code into U-Boot which means
BSPs that use the code are hard to get submitted as well.

The Xilinx approach of overwriting the source tree just feels wrong, and
no one seems to want to do it that way.

> 
> If we reject the Xilinx driver code, then we either have to do without
> Xilinx support in mainline, or we need to write new drivers that
> address the above issues (support multiple IP versions, etc).  The
> Xilinx support in mainline right now does not use any Xilinx code.
> (Xilinx PIC and UART).
> 
> Thoughts?

As painful as it may be, maybe we just write drivers from scratch and
try to track changes in the IP.

Regards,
Keith Outwater

RE: Ethernet driver for Linux kernel 2.6 running on ML403

[John Bonesio]

Hi,

I just saw this thread. The next version of EDK 8.2.2 will have a temac
v3.00a driver for linux 2.6. Our plan is to begin our code freeze stage
tomorrow. If people really need the driver right away, and can't wait a
few weeks for the release, I could possibly provide a patch (or use some
other distribution method) for the driver.
=20
Here at Xilinx, we have been in talks about having our drivers more
readily available in the open source repositories. As far as I know,
everyone seems to think that this would be a good thing for us. Right
now the plan is to have a 3rd party check our drivers into the main
repository as we have limited resources here. (Basically we're up to our
eyeballs in work right now.)

I do know that Xilinx would rather play a principle role in developing
and maintaining these open source drivers, rather than having a separate
group go off and implement a separate set.

<< Same complaints apply for Xilinx drivers in the U-Boot bootloader.
It is proving very difficult to get Xilinx code into U-Boot which means
BSPs that use the code are hard to get submitted as well.>>

I've only touched on U-Boot a little bit. Have any thoughts on how to
make this easier?

<< The Xilinx approach of overwriting the source tree just feels wrong,
and
no one seems to want to do it that way.>>

I am in the group that has control over how this is done. What would you
propose be done different? Keep in mind that we are trying to support a
process where someone builds a hardware design and the later changes it
with new peripherals or perhaps makes minor tweaks. We want to make the
updating of the Linux kernel to reflect these hardware changes easy for
people.

Having the ability to make rapid hardware changes, I think, is a bit
different from what most folks are used to.

Cheers,

- John

-----Original Message-----
From: linuxppc-embedded-bounces+jbonesio=3Dxilinx.com@ozlabs.org
[mailto:linuxppc-embedded-bounces+jbonesio=3Dxilinx.com@ozlabs.org] On
Behalf Of Keith J Outwater
Sent: Thursday, September 14, 2006 9:48 AM
To: linuxppc-embedded@ozlabs.org
Subject: Re: Ethernet driver for Linux kernel 2.6 running on ML403

Grant,
You bring up excellent points, and I am having to deal with these
issues in my 2.4.x kernel and U-Boot ports to VirtexII Pro FPGAs
as well.

> On 9/14/06, Michael Galassi <mgalassi@c-cor.com> wrote:
> > It is also worth noting that as released in MVL pro 4.0.1 it only
> > supports hard_temac 1.00.a and plb_temac 2.00.a, both of which are
> > tagged as deprecated in the current version (8.2.01i) of Xilinx's
> > EDK. The current version of {plb,hard}_temac (3.00.a) goes to great
> > lengths to break compatibility with older versions.  This will
> > presumably be fixed next month when it is rumored that wonderful new
> > things will come from Xilinx.  In the mean-time it is possible,
though
> > neither simple, nor fun, to create Virtex4 designs with the older
IP.

I think the general case is that Xilinx IP will be constantly evolving,=20
and
Xilinx driver code, when released under the GPL, will appear
sporadically.
Maybe it's best to resign ourselves to the fact that this situation
probably won't change, and then try to deal with it in a way that does
not depend so heavily on Xilinx drivers.

>=20
> So what direction do we (as the community) want to go for supporting
> Xilinx IP in the Linux kernel?

I don't know about anyone else, but running Linux on Virtex FPGAs is
something I simply have to be able to do.  With or without Xilinx
drivers, I think the kernel needs to support Xilinx hardware.

>=20
> IIRC, Xilinx intends to get drivers submitted into mainline.  (Based
> on their cross-platform driver support code).  It is unknown which and
> how many drivers for different IP versions will be submitted.

That's part of the problem: we seem to get support for some
IP cores, but not all.  Xilinx takes a piecemeal approach
to releasing drivers under the GPL.

>=20
> However, the xilinx driver code is verbose and does not match well
> with the rest of the Linux code base.  (due to the cross platform
> support)  Plus, the Xilinx tool work flow is geared towards the EDK
> tool overwriting the driver code in the kernel tree with code for the
> generated design.  In which case, does it even make sense to accept
> Xilinx drivers into the Linux tree when they are just going to get
> overwritten by the toolchain anyway?  Unfortunately, regenerating
> drivers has it's own problems considering that the license on the
> generated code is not GPL compatible at the moment.

Same complaints apply for Xilinx drivers in the U-Boot bootloader.
It is proving very difficult to get Xilinx code into U-Boot which means
BSPs that use the code are hard to get submitted as well.

The Xilinx approach of overwriting the source tree just feels wrong, and
no one seems to want to do it that way.

>=20
> If we reject the Xilinx driver code, then we either have to do without
> Xilinx support in mainline, or we need to write new drivers that
> address the above issues (support multiple IP versions, etc).  The
> Xilinx support in mainline right now does not use any Xilinx code.
> (Xilinx PIC and UART).
>=20
> Thoughts?

As painful as it may be, maybe we just write drivers from scratch and
try to track changes in the IP.

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

RE: Ethernet driver for Linux kernel 2.6 running on ML403

[Keith J Outwater]

> Hi,
> 
> I just saw this thread. The next version of EDK 8.2.2 will have a temac
> v3.00a driver for linux 2.6. Our plan is to begin our code freeze stage
> tomorrow. If people really need the driver right away, and can't wait a
> few weeks for the release, I could possibly provide a patch (or use some
> other distribution method) for the driver.
> 
> Here at Xilinx, we have been in talks about having our drivers more
> readily available in the open source repositories. As far as I know,
> everyone seems to think that this would be a good thing for us. Right
> now the plan is to have a 3rd party check our drivers into the main
> repository as we have limited resources here. (Basically we're up to our
> eyeballs in work right now.)

I know that MontaVista is you preferred Linux partner - if they do the
released, then we have to wait for them.  If individual designers can
get the driver sources, you can bet it will make it's way into the
mainline kernel.

> 
> I do know that Xilinx would rather play a principle role in developing
> and maintaining these open source drivers, rather than having a separate
> group go off and implement a separate set.

You may end up having to serve multiple customer bases then, to keep
things from forking.  The are lots of us who want to have lots of
fine-grained control over our source trees and the way in which we do 
builds.

> 
> << Same complaints apply for Xilinx drivers in the U-Boot bootloader.
> It is proving very difficult to get Xilinx code into U-Boot which means
> BSPs that use the code are hard to get submitted as well.>>
> 
> I've only touched on U-Boot a little bit. Have any thoughts on how to
> make this easier?

My perspective on this is that of a hardware designer who also develops
code.  I understand that is a good thing from the Xilinx point of view
to make it as easy as possible for designers to develop designs using
EDK with automatic BSP generation.  It's great for
doing stand alone (no OS) designs or to get "instant gratification"
as in "gee, I just booted Linux!" (a la Xilinx XAPP765).
When you do that, though, invariably
you end up having to make decisions that constrain how the design flow
works for the user and then it's hard for the user to deviate from that 
flow.
For example, the idea of having a user auto-generate source code for a BSP
that overwrites the bootloader or kernel source tree.  The problem
is that it's hard to "take the training wheels off" if I want or need
to have a stable source base of if I want to use the mainline kernel
or the mainline bootloader (U-Boot).  What if the source code bases
for the kernel or bootloader get re-arranged?

What I'd really like to have is "out of the box"
kernel support for all the
primary peripheral devices like communications and interface stuff
and U-Boot support for those devices as well.  I don't want to
have to generate BSPs and overwrite the source trees.

The whole licensing thing is another issue.  As I stated to someone
else at Xilinx: These are just drivers, not the crown jewels. GPL it
all and make it easier for designers to incorporate the code into
open source projects.  Dual license if you have customers who have
to have things locked up.

For U-Boot, I'm getting push-back from the maintainer on the
size and "verbosity" of the code.  Sounds like this might be an
issue for the kernel as well.

> 
> << The Xilinx approach of overwriting the source tree just feels wrong,
> and
> no one seems to want to do it that way.>>
> 
> I am in the group that has control over how this is done. What would you
> propose be done different? Keep in mind that we are trying to support a
> process where someone builds a hardware design and the later changes it
> with new peripherals or perhaps makes minor tweaks. We want to make the
> updating of the Linux kernel to reflect these hardware changes easy for
> people.

A noble goal, and clearly the right thing to do from a user-success point
of view, but do the hardware peripherals (i.e. the IP cores) change that 
much?
See my comment below: Can you create a system that allows software drivers
to verify that they (the drivers) are compatible with a particular IP
version?  For the novice user, the "full auto" system probably works
fine, but for (some, at least) experienced users, it tends to be an
additional layer or complexity (or opacity) that would be nice to get rid
of.

> 
> Having the ability to make rapid hardware changes, I think, is a bit
> different from what most folks are used to.

I agree.  I think we all need to agree how best to manage the
driver code so that as IP versions change, the drivers can be properly
matched to the IP.  Also, as more and more people port Linux to their
Virtex designs, we can (hopefully) expect more "out of the box"
support for Xilinx hardware.  That's basically the situation you have
with more conventional peripheral devices.

I don't think that there are any "version" registers in the Xilinx 
IP cores that a driver could check to determine compatibility.  That
would be very cheap to implement in hardware and you could then
develop more universal drivers.

> 
> Cheers,
> 
> - John
> 
> -----Original Message-----
> From: linuxppc-embedded-bounces+jbonesio=xilinx.com@ozlabs.org
> [mailto:linuxppc-embedded-bounces+jbonesio=xilinx.com@ozlabs.org] On
> Behalf Of Keith J Outwater
> Sent: Thursday, September 14, 2006 9:48 AM
> To: linuxppc-embedded@ozlabs.org
> Subject: Re: Ethernet driver for Linux kernel 2.6 running on ML403
> 
> Grant,
> You bring up excellent points, and I am having to deal with these
> issues in my 2.4.x kernel and U-Boot ports to VirtexII Pro FPGAs
> as well.
> 
> > On 9/14/06, Michael Galassi <mgalassi@c-cor.com> wrote:
> > > It is also worth noting that as released in MVL pro 4.0.1 it only
> > > supports hard_temac 1.00.a and plb_temac 2.00.a, both of which are
> > > tagged as deprecated in the current version (8.2.01i) of Xilinx's
> > > EDK. The current version of {plb,hard}_temac (3.00.a) goes to great
> > > lengths to break compatibility with older versions.  This will
> > > presumably be fixed next month when it is rumored that wonderful new
> > > things will come from Xilinx.  In the mean-time it is possible,
> though
> > > neither simple, nor fun, to create Virtex4 designs with the older
> IP.
> 
> I think the general case is that Xilinx IP will be constantly evolving, 
> and
> Xilinx driver code, when released under the GPL, will appear
> sporadically.
> Maybe it's best to resign ourselves to the fact that this situation
> probably won't change, and then try to deal with it in a way that does
> not depend so heavily on Xilinx drivers.
> 
> > 
> > So what direction do we (as the community) want to go for supporting
> > Xilinx IP in the Linux kernel?
> 
> I don't know about anyone else, but running Linux on Virtex FPGAs is
> something I simply have to be able to do.  With or without Xilinx
> drivers, I think the kernel needs to support Xilinx hardware.
> 
> > 
> > IIRC, Xilinx intends to get drivers submitted into mainline.  (Based
> > on their cross-platform driver support code).  It is unknown which and
> > how many drivers for different IP versions will be submitted.
> 
> That's part of the problem: we seem to get support for some
> IP cores, but not all.  Xilinx takes a piecemeal approach
> to releasing drivers under the GPL.
> 
> > 
> > However, the xilinx driver code is verbose and does not match well
> > with the rest of the Linux code base.  (due to the cross platform
> > support)  Plus, the Xilinx tool work flow is geared towards the EDK
> > tool overwriting the driver code in the kernel tree with code for the
> > generated design.  In which case, does it even make sense to accept
> > Xilinx drivers into the Linux tree when they are just going to get
> > overwritten by the toolchain anyway?  Unfortunately, regenerating
> > drivers has it's own problems considering that the license on the
> > generated code is not GPL compatible at the moment.
> 
> Same complaints apply for Xilinx drivers in the U-Boot bootloader.
> It is proving very difficult to get Xilinx code into U-Boot which means
> BSPs that use the code are hard to get submitted as well.
> 
> The Xilinx approach of overwriting the source tree just feels wrong, and
> no one seems to want to do it that way.
> 
> > 
> > If we reject the Xilinx driver code, then we either have to do without
> > Xilinx support in mainline, or we need to write new drivers that
> > address the above issues (support multiple IP versions, etc).  The
> > Xilinx support in mainline right now does not use any Xilinx code.
> > (Xilinx PIC and UART).
> > 
> > Thoughts?
> 
> As painful as it may be, maybe we just write drivers from scratch and
> try to track changes in the IP.
> 
> Regards,
> Keith Outwater
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
> 
> 

RE: Ethernet driver for Linux kernel 2.6 running on ML403

[John Bonesio]

More comments below...

-----Original Message-----
From: linuxppc-embedded-bounces+jbonesio=3Dxilinx.com@ozlabs.org
[mailto:linuxppc-embedded-bounces+jbonesio=3Dxilinx.com@ozlabs.org] On
Behalf Of Keith J Outwater
Sent: Thursday, September 14, 2006 11:36 AM
To: linuxppc-embedded@ozlabs.org
Subject: RE: Ethernet driver for Linux kernel 2.6 running on ML403

> Hi,
>=20
> I just saw this thread. The next version of EDK 8.2.2 will have a
temac
> v3.00a driver for linux 2.6. Our plan is to begin our code freeze
stage
> tomorrow. If people really need the driver right away, and can't wait
a
> few weeks for the release, I could possibly provide a patch (or use
some
> other distribution method) for the driver.
>=20
> Here at Xilinx, we have been in talks about having our drivers more
> readily available in the open source repositories. As far as I know,
> everyone seems to think that this would be a good thing for us. Right
> now the plan is to have a 3rd party check our drivers into the main
> repository as we have limited resources here. (Basically we're up to
our
> eyeballs in work right now.)

I know that MontaVista is you preferred Linux partner - if they do the
released, then we have to wait for them.  If individual designers can
get the driver sources, you can bet it will make it's way into the
mainline kernel.

>=20
> I do know that Xilinx would rather play a principle role in developing
> and maintaining these open source drivers, rather than having a
separate
> group go off and implement a separate set.

You may end up having to serve multiple customer bases then, to keep
things from forking.  The are lots of us who want to have lots of
fine-grained control over our source trees and the way in which we do=20
builds.

[John]
One thing that may help you, is that you can clear out the 'target_dir'
setting in xps. That will let you generate the BSP and then simply copy
over the files you need.

>=20
> << Same complaints apply for Xilinx drivers in the U-Boot bootloader.
> It is proving very difficult to get Xilinx code into U-Boot which
means
> BSPs that use the code are hard to get submitted as well.>>
>=20
> I've only touched on U-Boot a little bit. Have any thoughts on how to
> make this easier?

My perspective on this is that of a hardware designer who also develops
code.  I understand that is a good thing from the Xilinx point of view
to make it as easy as possible for designers to develop designs using
EDK with automatic BSP generation.  It's great for
doing stand alone (no OS) designs or to get "instant gratification"
as in "gee, I just booted Linux!" (a la Xilinx XAPP765).
When you do that, though, invariably
you end up having to make decisions that constrain how the design flow
works for the user and then it's hard for the user to deviate from that=20
flow.
For example, the idea of having a user auto-generate source code for a
BSP
that overwrites the bootloader or kernel source tree.  The problem
is that it's hard to "take the training wheels off" if I want or need
to have a stable source base of if I want to use the mainline kernel
or the mainline bootloader (U-Boot).  What if the source code bases
for the kernel or bootloader get re-arranged?

What I'd really like to have is "out of the box"
kernel support for all the
primary peripheral devices like communications and interface stuff
and U-Boot support for those devices as well.  I don't want to
have to generate BSPs and overwrite the source trees.

[John]
See my comment above.

The whole licensing thing is another issue.  As I stated to someone
else at Xilinx: These are just drivers, not the crown jewels. GPL it
all and make it easier for designers to incorporate the code into
open source projects.  Dual license if you have customers who have
to have things locked up.

[John]
I believe this is our intention going forward.

For U-Boot, I'm getting push-back from the maintainer on the
size and "verbosity" of the code.  Sounds like this might be an
issue for the kernel as well.

>=20
> << The Xilinx approach of overwriting the source tree just feels
wrong,
> and
> no one seems to want to do it that way.>>
>=20
> I am in the group that has control over how this is done. What would
you
> propose be done different? Keep in mind that we are trying to support
a
> process where someone builds a hardware design and the later changes
it
> with new peripherals or perhaps makes minor tweaks. We want to make
the
> updating of the Linux kernel to reflect these hardware changes easy
for
> people.

A noble goal, and clearly the right thing to do from a user-success
point
of view, but do the hardware peripherals (i.e. the IP cores) change that

much?
See my comment below: Can you create a system that allows software
drivers
to verify that they (the drivers) are compatible with a particular IP
version?  For the novice user, the "full auto" system probably works
fine, but for (some, at least) experienced users, it tends to be an
additional layer or complexity (or opacity) that would be nice to get
rid
of.

>=20
> Having the ability to make rapid hardware changes, I think, is a bit
> different from what most folks are used to.

I agree.  I think we all need to agree how best to manage the
driver code so that as IP versions change, the drivers can be properly
matched to the IP.  Also, as more and more people port Linux to their
Virtex designs, we can (hopefully) expect more "out of the box"
support for Xilinx hardware.  That's basically the situation you have
with more conventional peripheral devices.

[John]
Yep, we'd like this too.

I don't think that there are any "version" registers in the Xilinx=20
IP cores that a driver could check to determine compatibility.  That
would be very cheap to implement in hardware and you could then
develop more universal drivers.

[John]
We've examined doing this in the past, and gotten some push back due to
the use of bram or other resources. Conceptually, it's a great idea, I
just don't know if this is likely to happen any time soon.

>=20
> Cheers,
>=20
> - John
>=20
> -----Original Message-----
> From: linuxppc-embedded-bounces+jbonesio=3Dxilinx.com@ozlabs.org
> [mailto:linuxppc-embedded-bounces+jbonesio=3Dxilinx.com@ozlabs.org] On
> Behalf Of Keith J Outwater
> Sent: Thursday, September 14, 2006 9:48 AM
> To: linuxppc-embedded@ozlabs.org
> Subject: Re: Ethernet driver for Linux kernel 2.6 running on ML403
>=20
> Grant,
> You bring up excellent points, and I am having to deal with these
> issues in my 2.4.x kernel and U-Boot ports to VirtexII Pro FPGAs
> as well.
>=20
> > On 9/14/06, Michael Galassi <mgalassi@c-cor.com> wrote:
> > > It is also worth noting that as released in MVL pro 4.0.1 it only
> > > supports hard_temac 1.00.a and plb_temac 2.00.a, both of which are
> > > tagged as deprecated in the current version (8.2.01i) of Xilinx's
> > > EDK. The current version of {plb,hard}_temac (3.00.a) goes to
great
> > > lengths to break compatibility with older versions.  This will
> > > presumably be fixed next month when it is rumored that wonderful
new
> > > things will come from Xilinx.  In the mean-time it is possible,
> though
> > > neither simple, nor fun, to create Virtex4 designs with the older
> IP.
>=20
> I think the general case is that Xilinx IP will be constantly
evolving,=20
> and
> Xilinx driver code, when released under the GPL, will appear
> sporadically.
> Maybe it's best to resign ourselves to the fact that this situation
> probably won't change, and then try to deal with it in a way that does
> not depend so heavily on Xilinx drivers.
>=20
> >=20
> > So what direction do we (as the community) want to go for supporting
> > Xilinx IP in the Linux kernel?
>=20
> I don't know about anyone else, but running Linux on Virtex FPGAs is
> something I simply have to be able to do.  With or without Xilinx
> drivers, I think the kernel needs to support Xilinx hardware.
>=20
> >=20
> > IIRC, Xilinx intends to get drivers submitted into mainline.  (Based
> > on their cross-platform driver support code).  It is unknown which
and
> > how many drivers for different IP versions will be submitted.
>=20
> That's part of the problem: we seem to get support for some
> IP cores, but not all.  Xilinx takes a piecemeal approach
> to releasing drivers under the GPL.
>=20
> >=20
> > However, the xilinx driver code is verbose and does not match well
> > with the rest of the Linux code base.  (due to the cross platform
> > support)  Plus, the Xilinx tool work flow is geared towards the EDK
> > tool overwriting the driver code in the kernel tree with code for
the
> > generated design.  In which case, does it even make sense to accept
> > Xilinx drivers into the Linux tree when they are just going to get
> > overwritten by the toolchain anyway?  Unfortunately, regenerating
> > drivers has it's own problems considering that the license on the
> > generated code is not GPL compatible at the moment.
>=20
> Same complaints apply for Xilinx drivers in the U-Boot bootloader.
> It is proving very difficult to get Xilinx code into U-Boot which
means
> BSPs that use the code are hard to get submitted as well.
>=20
> The Xilinx approach of overwriting the source tree just feels wrong,
and
> no one seems to want to do it that way.
>=20
> >=20
> > If we reject the Xilinx driver code, then we either have to do
without
> > Xilinx support in mainline, or we need to write new drivers that
> > address the above issues (support multiple IP versions, etc).  The
> > Xilinx support in mainline right now does not use any Xilinx code.
> > (Xilinx PIC and UART).
> >=20
> > Thoughts?
>=20
> As painful as it may be, maybe we just write drivers from scratch and
> try to track changes in the IP.
>=20
> Regards,
> Keith Outwater
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>=20
>=20

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

RE: Ethernet driver for Linux kernel 2.6 running on ML403

[T Ziomek]

>> << The Xilinx approach of overwriting the source tree just feels wrong,
>> and
>> no one seems to want to do it that way.>>
>>
>> I am in the group that has control over how this is done. What would you
>> propose be done different? Keep in mind that we are trying to support a
>> process where someone builds a hardware design and the later changes it
>> with new peripherals or perhaps makes minor tweaks. We want to make the
>> updating of the Linux kernel to reflect these hardware changes easy for
>> people.
>
> A noble goal, and clearly the right thing to do from a user-success point
> of view, but do the hardware peripherals (i.e. the IP cores) change that
> much?

Driver-per-version (i.e. separate drivers for 'xilinx_emac_1_00_b', 1_00_c,
etc.) is the most obvious but unlikely to be accepted, and it would lead to
lots of duplicated code.  How about having a single driver that supports
all versions of xilinx_emac, and adding the specific IP version info in the
kernel config?  So we would have, for example, CONFIG_XILINX_ENET_1_00_C,
or whatever, in addition to or in place of CONFIG_XILINX_ENET.  The neces-
sary adjustments would generally be made via conditionally compiled code in
the driver source, or in the driver's Makefile when the version differences
are larger in scope.

>From what I've seen this is pretty consistent with The Kernel Way...  And
it'd force the kernel builder to be aware of what IP version(s) are in
their hardware.

Tom
-- 
   /"\  ASCII Ribbon Campaign   |
   \ /                          |   Email to user 'CTZ001'
    X        Against HTML       |             at 'email.mot.com'
   / \     in e-mail & news     |

Re: Ethernet driver for Linux kernel 2.6 running on ML403

[Grant Likely]

On 9/14/06, John Bonesio <john.bonesio@xilinx.com> wrote:

<snip>

> << Same complaints apply for Xilinx drivers in the U-Boot bootloader.
> It is proving very difficult to get Xilinx code into U-Boot which means
> BSPs that use the code are hard to get submitted as well.>>
>
> I've only touched on U-Boot a little bit. Have any thoughts on how to
> make this easier?

U-Boot has the same issues as Linux
- Xilinx drivers don't match the coding style
- The license boilerplate is not GPL compatible
- The IP can change rapidly, so do the drivers belong in the u-boot
mainline tree?
- Current code is not set up to support multiple drivers in the code
base.  (I know it's possible, but it's not being done at the moment)

(and see my comments on Linux below)

>
> << The Xilinx approach of overwriting the source tree just feels wrong,
> and no one seems to want to do it that way.>>
>
> I am in the group that has control over how this is done. What would you
> propose be done different? Keep in mind that we are trying to support a
> process where someone builds a hardware design and the later changes it
> with new peripherals or perhaps makes minor tweaks. We want to make the
> updating of the Linux kernel to reflect these hardware changes easy for
> people.

Simply generating code and inserting it into the kernel tree itself is
okay on the surface, but the current scheme is distasteful.  I would
make the following recommendations to make it more palatable:
- Keep generated code in a single sub-directory.  Don't scatter it all
over the kernel source.  ie. generate all code into /xilinx-bsp
instead of bits into /arch/ppc and /drivers.
- Don't overwrite *anything* that from the mainline tree.  (Hence the
/xilinx-bsp suggestion above).  If you need to modify files in the
tree, like in /arch/ppc, then submit patches for the needed changes
and *don't* try to modify them from within EDK.
- If you want something in mainline; make sure it can coexist with
drivers for other versions of the same IP, or make it support multiple
versions.
- Corollary to the above two points; once a Xilinx provided
patch/driver is accepted into mainline, treat it like the rest of
mainline and don't let EDK overwrite it.
- Regardless of Xilinx's intentions, 3rd party drivers will probably
be written and accepted into mainline.  Be prepared to coexist with
them also.
- Stop requiring xparameters.h to be mangled!  Generate it correctly
the first time!  I think I'll scream if I get handed another xparams
file from an FPGA engineer which was generated as a no-os target.  The
Linux redefines are useful, why aren't they in xparameters.h for all
targets?

Unfortunately, generating the drivers ends up being a one way street.
If the code is not in mainline, it will not keep up with changes to
the kernel API, and it is more difficult to get bug fixes into the
driver code from 3rd parties (ie. users need to wait for the next EDK
release cycle before the changes appear in generated code).  This is
probably the major reason why writing new 3rd party drivers for
inclusion in mainline is attractive to me.

>
> Having the ability to make rapid hardware changes, I think, is a bit
> different from what most folks are used to.

Different, but manageable.

-- 
Grant Likely, B.Sc. P.Eng.
Secret Lab Technologies Ltd.
grant.likely@secretlab.ca
(403) 399-0195

Re: Ethernet driver for Linux kernel 2.6 running on ML403

[Grant Likely]

On 9/14/06, Keith J Outwater <kjoutwater@raytheon.com> wrote:
> >
> > So what direction do we (as the community) want to go for supporting
> > Xilinx IP in the Linux kernel?
>
> I don't know about anyone else, but running Linux on Virtex FPGAs is
> something I simply have to be able to do.  With or without Xilinx
> drivers, I think the kernel needs to support Xilinx hardware.

ditto

>
> >
> > If we reject the Xilinx driver code, then we either have to do without
> > Xilinx support in mainline, or we need to write new drivers that
> > address the above issues (support multiple IP versions, etc).  The
> > Xilinx support in mainline right now does not use any Xilinx code.
> > (Xilinx PIC and UART).
> >
> > Thoughts?
>
> As painful as it may be, maybe we just write drivers from scratch and
> try to track changes in the IP.

That's kind of the direction I'm leaning too.


-- 
Grant Likely, B.Sc. P.Eng.
Secret Lab Technologies Ltd.
grant.likely@secretlab.ca
(403) 399-0195

Re: Ethernet driver for Linux kernel 2.6 running on ML403

[David H. Lynch Jr.]

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

Michael Galassi wrote:
>
> It is also worth noting that as released in MVL pro 4.0.1 it only
> supports hard_temac 1.00.a and plb_temac 2.00.a, both of which are
> tagged as deprecated in the current version (8.2.01i) of Xilinx's
> EDK. The current version of {plb,hard}_temac (3.00.a) goes to great
> lengths to break compatibility with older versions.  This will
> presumably be fixed next month when it is rumored that wonderful new
> things will come from Xilinx.  In the mean-time it is possible, though
> neither simple, nor fun, to create Virtex4 designs with the older IP.
>   
    Fortunately, I have little to do with the firmware.
    Unfortunately, after the firmware is in the product, I am the guy 
who has to make the drivers work.

    I am also not straight - though I am somewhat clearer, on exactly 
what any given flavor of TEMAC is.

    As best as I can tell, the V4 FX chipsets contain some dedicated 
hardware that forms the basis for the TEMAC.
    (or possibly several TEMAC's depending on how it is built).
   
    Separately Xilinx provides a plethora of wrapper logic, that allows 
you to implement  a slew of different incarnations.
    All similar yet different at the same time. Ranging from the Local 
Link TEMAC which is the simplest to the
    PLB SG DMA driven TEMAC which is probably the most complex.

    Then there is an assortment of PDF's from Xilinx, none of which 
quite match whatever you might have.

    And at the risk of Goring somebodies Ox, the MV/EDK based drivers 
may/may not have the attribute of
    being portable accross multiple OS's, but they seem to pretty much 
deliberately violate almost every style
    quideline for Linux drivers. Linux is written in C, not preprocessor 
Macros.

    For anyone at MV I have ticked off - Sorry, I am sure it is 
brilliantly written preprocessor Macros.
   
   
   




> -michael
>   


-- 
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: 3339 bytes --]

RE: Ethernet driver for Linux kernel 2.6 running on ML403

[Keith J Outwater]

"John Bonesio" <john.bonesio@xilinx.com> wrote on 09/14/2006 10:52:16 AM:
<snip>
> 
> I don't think that there are any "version" registers in the Xilinx 
> IP cores that a driver could check to determine compatibility.  That
> would be very cheap to implement in hardware and you could then
> develop more universal drivers.
> 
> [John]
> We've examined doing this in the past, and gotten some push back due to
> the use of bram or other resources. Conceptually, it's a great idea, I
> just don't know if this is likely to happen any time soon.
> 

John,
I thinking in terms of something like a 32 bit register
(i.e. like a processor's PVR register) that has a hard-coded magic number
which a driver can read and decode to determine driver compatibility.
That does not sound resource-intensive given the size FPGAs we are talking
about.  Probably don't even need 32 bits.

Keith

Re: Ethernet driver for Linux kernel 2.6 running on ML403

[David H. Lynch Jr.]

Keith J Outwater wrote:
>> Hi,
>
> I don't think that there are any "version" registers in the Xilinx 
> IP cores that a driver could check to determine compatibility.  That
> would be very cheap to implement in hardware and you could then
> develop more universal drivers.
>
>   
    Some of the IP's do, some don't - and then some might.
    Some of the documentation isn't too bad, some is almost un-uasable.
   
 
   




-- 
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: Ethernet driver for Linux kernel 2.6 running on ML403

[David H. Lynch Jr.]

John;

    My guess would be that as the whole xilinx drivers/edk stand, even 
with the virulent support of this list I would not bet on their being 
accepted upstream.

    Nothing in the Linux Kernel that I am aware of resembles them.
    There has been on ongoing holy war in LKML over getting reiser4 
accepted as experimental, one of the major issues being coding style. 
The style of reiser4
    is alot closer to Linux norms than the Xilinx EDK code.

    The current Xilinx approach is supposed to easily give us board 
support for varying IP's accross several platforms. I have been 
providing board support for
Pico Computing's Xilinx V4 based offerings for about a year, and I have 
been unable to take advantage of any of that. I have done board bringup 
for two OS's.
While I have been able to benefit from the work of other's on this list, 
and I have been able to occasionally use some code coming from Xilinx - 
mostly as  a reference,
I have two products supporting two operating systems, with a small 
collection of variable peripherals. None of this uses the Xilinx EDK. I 
deliberately postponed
work on the ethernet drivers in the hope they would be finished by the 
time I finished everything else. In the end I had to write my own.

I am not trying to bash Xilinx or Monta Vista. What I am questioning is 
whether the approach that Xilinx is currently using, aside from other 
problems, may actually run
counter to its goal.

If the Xilinx EDK could give us the support we need for the IP's we use. 
If it adapted easily between OS's, and IP versions. And if the code was 
as current as the IP's themselves.
Maybe the Xilinx EDK would be vindicated.

Certainly many of us would use it. While I happen to personally adhere 
to 98% of the Linux Style guidelines - I here many of my own views 
express ed in them, I am not a fanatic.
I am happy if my work improves Linux. But in the end I pay my mortgage 
and feed my family. I will use the resources that get the job done. 
Style is secondary.

But my honest expectation is that MV/Xilinx EDK support will always lag 
way behind what I am trying to do, and/or be incompatible with the goals 
and objectives of my clients.
For me the code coming from Xilinx/MV is most useful as a reference. I 
have ranted about mismatches between documentation and hardware - but 
that is not something new or specific
to Xilinx. What code has leaked out has proven useful - often after 
several days work turning it into something actually readable, as a 
reference - "Oh, that is how that bit really works"

I would be happy to be proven wrong - but I do not expect to be.






-- 
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: Ethernet driver for Linux kernel 2.6 running on ML403

[David H. Lynch Jr.]

John;

    In a related rant. Why is it that there is so much meaningless 
variation in the IP's.

    I accept that there are reasons for sometimes mapping registers via 
dcr and in other IP's making them available directly.
    But why do the assorted bits in what is virtually the same register 
have to keep jumping all over the place ?

    As an example there are enormous similarities between the GEMAC that 
has a driver provided by GHS Integrity, and the
PLB FIFO TEMAC. It is almost possible to build the driver as either with 
just a different set of deffinitions - I spent two weeks
trying unsuccessfully to do just that.



-- 
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: Ethernet driver for Linux kernel 2.6 running on ML403

[T Ziomek]

On Thu, 14 Sep 2006, Grant Likely wrote:
  . . .
> - Stop requiring xparameters.h to be mangled!

Here, here!

>Generate it correctly
> the first time!  I think I'll scream if I get handed another xparams
> file from an FPGA engineer which was generated as a no-os target.  The
> Linux redefines are useful, why aren't they in xparameters.h for all
> targets?

I think that would be okay.  To offer an alternative, the way I handle
it now is to separate the two.  See
<http://ozlabs.org/pipermail/linuxppc-embedded/2005-August/019945.html>

Tom
-- 
   /"\  ASCII Ribbon Campaign   |
   \ /                          |   Email to user 'CTZ001'
    X        Against HTML       |             at 'email.mot.com'
   / \     in e-mail & news     |

RE: Ethernet driver for Linux kernel 2.6 running on ML403

[John Bonesio]

Hi Keith,

I know that on the surface it seems like a simple thing. Some of our
parts are big, yet some are small. We are always getting pressure to
make our IP as small as possible.

Though, this may be something we can revisit again, for now this
information just isn't going to be available.

Perhaps the problem can be solved in a different way.

- John

-----Original Message-----
From: linuxppc-embedded-bounces+jbonesio=3Dxilinx.com@ozlabs.org
[mailto:linuxppc-embedded-bounces+jbonesio=3Dxilinx.com@ozlabs.org] On
Behalf Of Keith J Outwater
Sent: Thursday, September 14, 2006 5:09 PM
To: linuxppc-embedded@ozlabs.org
Subject: RE: Ethernet driver for Linux kernel 2.6 running on ML403

"John Bonesio" <john.bonesio@xilinx.com> wrote on 09/14/2006 10:52:16
AM:
<snip>
>=20
> I don't think that there are any "version" registers in the Xilinx=20
> IP cores that a driver could check to determine compatibility.  That
> would be very cheap to implement in hardware and you could then
> develop more universal drivers.
>=20
> [John]
> We've examined doing this in the past, and gotten some push back due
to
> the use of bram or other resources. Conceptually, it's a great idea, I
> just don't know if this is likely to happen any time soon.
>=20

John,
I thinking in terms of something like a 32 bit register
(i.e. like a processor's PVR register) that has a hard-coded magic
number
which a driver can read and decode to determine driver compatibility.
That does not sound resource-intensive given the size FPGAs we are
talking
about.  Probably don't even need 32 bits.

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

Re: Ethernet driver for Linux kernel 2.6 running on ML403

[Peter Korsgaard]

>>>>> "GL" == Grant Likely <grant.likely@secretlab.ca> writes:

Hi,

GL> So what direction do we (as the community) want to go for
GL> supporting Xilinx IP in the Linux kernel?

GL> IIRC, Xilinx intends to get drivers submitted into mainline.
GL> (Based on their cross-platform driver support code).  It is
GL> unknown which and how many drivers for different IP versions will
GL> be submitted.

Yes, that's also what I hear from the Xilinx guys - But action speaks
louder than words. It's not like the V2P is new technology anymore.

GL> However, the xilinx driver code is verbose and does not match well
GL> with the rest of the Linux code base.

Yeah, the Xilinx stuff/flow definately doesn't fit the kernel.

GL> If we reject the Xilinx driver code, then we either have to do
GL> without Xilinx support in mainline, or we need to write new
GL> drivers that address the above issues (support multiple IP
GL> versions, etc).  The Xilinx support in mainline right now does not
GL> use any Xilinx code.  (Xilinx PIC and UART).

I think the best option is to simply forget about the Xilinx code,
see the FPGAs as any other PPC system and write normal device drivers
for it. Your platform bus stuff and my (to-be-mainlined) uartlite
driver is a first step in this direction..

-- 
Bye, Peter Korsgaard

Re: Ethernet driver for Linux kernel 2.6 running on ML403

[Peter Korsgaard]

>>>>> "JB" == John Bonesio <john.bonesio@xilinx.com> writes:

Hi,

JB> << The Xilinx approach of overwriting the source tree just feels
JB> wrong, and no one seems to want to do it that way.>>

JB> I am in the group that has control over how this is done. What
JB> would you propose be done different? Keep in mind that we are
JB> trying to support a process where someone builds a hardware design
JB> and the later changes it with new peripherals or perhaps makes
JB> minor tweaks. We want to make the updating of the Linux kernel to
JB> reflect these hardware changes easy for people.

Don't patch the kernel sources from EDK, but instead get the drivers
integrated in the mainline kernel. Either do config options for the
various IP versions or use runtime detection.

We're doing Linux development for several platforms and using a single
kernel tree for it all is absolute critical to my sanity..

The EDK drivers are nice as examples of how to use the IP cores, but
the defined and documented interface should be the IP, not the EDK
drivers.

-- 
Bye, Peter Korsgaard

Re: Ethernet driver for Linux kernel 2.6 running on ML403

[Grant Likely]

[edited for context]

On 9/15/06, John Bonesio <john.bonesio@xilinx.com> wrote:
> On Thursday, September 14, 2006 5:09 PM, Keith J Outwater wrote:
> > I thinking in terms of something like a 32 bit register (i.e. like a
> > processor's PVR register) that has a hard-coded magic number
> > which a driver can read and decode to determine driver compatibility.
> > That does not sound resource-intensive given the size FPGAs we are
> > talking about.  Probably don't even need 32 bits.
>
> I know that on the surface it seems like a simple thing. Some of our
> parts are big, yet some are small. We are always getting pressure to
> make our IP as small as possible.
>
> Though, this may be something we can revisit again, for now this
> information just isn't going to be available.

Then its probably just a matter of whoever configures the kernel needs
to know what version of IP is being used.  ie. always have the
fallback of compile time specification of IP version. Could be done
manually, or by putting the info into the dts.  We probably need a
tool to generate a dts from the .mhs or xparameters.h file anyway.

Cheers,
g.

-- 
Grant Likely, B.Sc. P.Eng.
Secret Lab Technologies Ltd.
grant.likely@secretlab.ca
(403) 399-0195

Re: Ethernet driver for Linux kernel 2.6 running on ML403

[Grant Likely]

On 9/19/06, Peter Korsgaard <jacmet@sunsite.dk> wrote:
> >>>>> "GL" == Grant Likely <grant.likely@secretlab.ca> writes:
> GL> If we reject the Xilinx driver code, then we either have to do
> GL> without Xilinx support in mainline, or we need to write new
> GL> drivers that address the above issues (support multiple IP
> GL> versions, etc).  The Xilinx support in mainline right now does not
> GL> use any Xilinx code.  (Xilinx PIC and UART).
>
> I think the best option is to simply forget about the Xilinx code,
> see the FPGAs as any other PPC system and write normal device drivers
> for it. Your platform bus stuff and my (to-be-mainlined) uartlite
> driver is a first step in this direction..

Too bad platform bus is sooo last year.  :p

Time to hack device trees.
g.

-- 
Grant Likely, B.Sc. P.Eng.
Secret Lab Technologies Ltd.
grant.likely@secretlab.ca
(403) 399-0195

Re: Ethernet driver for Linux kernel 2.6 running on ML403

[Andrew]

On Thu, 14 Sep 2006 09:40:53 -0700
"John Bonesio" <john.bonesio@xilinx.com> wrote:

> I am in the group that has control over how this is done. What would
> you propose be done different? Keep in mind that we are trying to
> support a process where someone builds a hardware design and the
> later changes it with new peripherals or perhaps makes minor tweaks.
> We want to make the updating of the Linux kernel to reflect these
> hardware changes easy for people.
> 
> Having the ability to make rapid hardware changes, I think, is a bit
> different from what most folks are used to.

I am coming into this a bit late and it has been awhile since I worked
Virtex parts. But it doesn't look like things have changed much.

Since Linux is from a PC base, hardware changes are as rapid as
powering off and plugging a new device in the machine. Rebuilding the
kernel for this is not usually something people consider for this.
So to say Linux people aren't use to rapid hardware changes, seems
pretty backwards to me.

The static configuration of the hardware is the thing that is very
unusual for the software. And having that static hardware setup
compiled into the kernel is a real source of problems.
Typically things get probed, discovered/learned at boot time. Either by
the boot loader, pin strapping, dip switches, user config etc.

I worked on a board with 2 Virtex chips. They had some set of common IP
cores with minor differences between the two. There was no way I wanted
to build 2 sets of kernels and drivers to deal with things.
The first small difference of one chip having 2 serial ports and the
other side only having 1 serial port, rippled the entire IRQ mapping in
both xparameters.h file. There were all kinds of little changes between
the mem mapping and everything else as well.
Depending on how things were used from xparemeters.h I could change the
static numbers to function calls to get values, but most of the time I
easist to hack up the drivers to pick one of two values depending on
the chip.

At first I just used a kernel boot param saved in u-boot flash to tell
the SW which chip it was running on. Then I got our HW people to put
in a single bit in another register for SW to tell which chip was
running. That saved us setup step in production of setting up flash
with different items.

There are trade offs on how much it is worth being determined at run
time compared to compiled into the kernel, but with the current
xparemters.h you are stuck with things compiled in. Getting to a point
where anything can be learned at run time, or just pulled from flash
would be a big step forward. But at that point it should still be easy
to compile things into the kernel if someone has major sw space
constraints.

I also keep hearing about doing partial re-configuration bit streams.
Were the FPGA can change at run time as well. (ie switch from an
CAT5 ethernet IP core over to an 802.11 ethernet depending on if the
user plugs in a cable or an antenna)

How would you even plan to do that with the xparemters.h file and the
drivers as it is now?

Re: Ethernet driver for Linux kernel 2.6 running on ML403

[Grant Likely]

On 9/19/06, Grant Likely <grant.likely@secretlab.ca> wrote:
> On 9/19/06, Peter Korsgaard <jacmet@sunsite.dk> wrote:
> > >>>>> "GL" == Grant Likely <grant.likely@secretlab.ca> writes:
> > GL> If we reject the Xilinx driver code, then we either have to do
> > GL> without Xilinx support in mainline, or we need to write new
> > GL> drivers that address the above issues (support multiple IP
> > GL> versions, etc).  The Xilinx support in mainline right now does not
> > GL> use any Xilinx code.  (Xilinx PIC and UART).
> >
> > I think the best option is to simply forget about the Xilinx code,
> > see the FPGAs as any other PPC system and write normal device drivers
> > for it. Your platform bus stuff and my (to-be-mainlined) uartlite
> > driver is a first step in this direction..
>
> Too bad platform bus is sooo last year.  :p
>
> Time to hack device trees.

Avast!  After getting quizzed on IRC about this off-the-cuff comment,
I should probably clarify.  Since the Xilinx IP could be wired up to a
ublaze core or an off-chip processor, the drivers still need to use a
platform bus attachment to keep it all cross platform.

So, replace above comment with the following:

Populating the platform device with static code during initialization
is sooo last year.

Time to hack device trees to populate it instead.

:)

g.

-- 
Grant Likely, B.Sc. P.Eng.
Secret Lab Technologies Ltd.
grant.likely@secretlab.ca
(403) 399-0195

Re: Ethernet driver for Linux kernel 2.6 running on ML403

[David H. Lynch Jr.]

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

Grant Likely wrote:
>
>
> Avast!  After getting quizzed on IRC about this off-the-cuff comment,
> I should probably clarify.  Since the Xilinx IP could be wired up to a
> ublaze core or an off-chip processor, the drivers still need to use a
> platform bus attachment to keep it all cross platform.
>
> So, replace above comment with the following:
>
> Populating the platform device with static code during initialization
> is sooo last year.
>
> Time to hack device trees to populate it instead.
>   
    So I got another X V4 board. I hacked in the Platform device stuff 
from you ml403 code with changes needed for my hardware.
    and my brain is slowly begining to actually grasp  what is going on 
- I am begining to grasp the platform devices big picture (over a 
mountain through a spyglass in the fog)

    Where do I begin with Device Trees ?

    The vague Picture I have is the have something to do with some 
datastructure that Mac's typically create at or prior to boot. And that 
for embedded systems we are building them
    externally compiling them and then attaching the compiled device 
tree to our project.

    I got a Xilinv V4 device currently with a Pic, UartLite, TEMAC, 
Flash and Keyhole (pseuodo serial host interface). Of those it is only 
certain that the flash will always be there.
    We have bit images with Keyhole only, Uartlite only TEMAC only, 
Sometimes we have a Pic sometimes not. I was trying to get to the point 
were I could dynamically add what was there
    to Platform devices during initialization.

    If Device trees are static, then do they even apply to what I have 
to deal with ?

    Please pardon my ignorance.


-- 
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: 2866 bytes --]

Re: Ethernet driver for Linux kernel 2.6 running on ML403

[Grant Likely]

On 9/19/06, David H. Lynch Jr. <dhlii@dlasys.net> wrote:
>
>  Grant Likely wrote:
>
>  Avast! After getting quizzed on IRC about this off-the-cuff comment,
> I should probably clarify. Since the Xilinx IP could be wired up to a
> ublaze core or an off-chip processor, the drivers still need to use a
> platform bus attachment to keep it all cross platform.
>
> So, replace above comment with the following:
>
> Populating the platform device with static code during initialization
> is sooo last year.
>
> Time to hack device trees to populate it instead.
>
>      So I got another X V4 board. I hacked in the Platform device stuff from
> you ml403 code with changes needed for my hardware.
>      and my brain is slowly begining to actually grasp  what is going on - I
> am begining to grasp the platform devices big picture (over a mountain
> through a spyglass in the fog)
>
>      Where do I begin with Device Trees ?

Step 1: run away
Step 2: don't look back.

Just kidding.  Unless you want to help move Virtex support from
arch/ppc to arch/powerpc, you don't really need to worry about device
trees for a while.

If you are interested, look at
Documentation/powerpc/booting-without-of.txt.  Then start poking Matt
Porter about when he's going to get 4xx ported to arch/powerpc.

I've been half heartedly looking at what needs to be done to generate
a device tree based on either system.mhs or xparameters.h.  I'm
probably going to write a tiny C program that is compiled against
xparameters.h and spits out a valid dts file.  The dts file can then
be run through the device tree compiler to produce the flattened
device tree structure.

>
>      The vague Picture I have is the have something to do with some
> datastructure that Mac's typically create at or prior to boot. And that for
> embedded systems we are building them
>      externally compiling them and then attaching the compiled device tree
> to our project.

That right.  You don't compile device base addresses, irqs, etc into
the kernel.  You pass them in at boot time with a data structure.

>
>      I got a Xilinv V4 device currently with a Pic, UartLite, TEMAC, Flash
> and Keyhole (pseuodo serial host interface). Of those it is only certain
> that the flash will always be there.
>      We have bit images with Keyhole only, Uartlite only TEMAC only,
> Sometimes we have a Pic sometimes not. I was trying to get to the point were
> I could dynamically add what was there
>      to Platform devices during initialization.
>
>      If Device trees are static, then do they even apply to what I have to
> deal with ?

Device trees don't have to be static.  They can be generated/modified
on the fly if the bootloader supports it.  Or you can pass a different
tree depending on what IP you have on the board.

Cheers,
g.

-- 
Grant Likely, B.Sc. P.Eng.
Secret Lab Technologies Ltd.
grant.likely@secretlab.ca
(403) 399-0195

Re: Ethernet driver for Linux kernel 2.6 running on ML403

[David H. Lynch Jr.]

Grant Likely wrote:
>
> Step 1: run away
> Step 2: don't look back.
    There are days.

>
> Just kidding.  Unless you want to help move Virtex support from
> arch/ppc to arch/powerpc, you don't really need to worry about device
> trees for a while.
>
> If you are interested, look at
> Documentation/powerpc/booting-without-of.txt.  Then start poking Matt
> Porter about when he's going to get 4xx ported to arch/powerpc.
    That depends. I am a consultant. My works is primarily paid for by
my clients, clients.
    I tinker when I am not otherwise busy. But I am very busy, despite
being short on work !?

   
>
> I've been half heartedly looking at what needs to be done to generate
> a device tree based on either system.mhs or xparameters.h.  I'm
> probably going to write a tiny C program that is compiled against
> xparameters.h and spits out a valid dts file.  The dts file can then
> be run through the device tree compiler to produce the flattened
> device tree structure.
    That sounds somewhat interesting.

    But as was somewhat raised elsewhere - what about partial
reprogramming the FPGA on the fly ?
   
    One of the fundimental issues I am facing, is that I have to deal
with a system where nothing is certain except that there is a
    ppc405 present. There will always be more than that - but there is
not another component that MUST be present.
    As things go forward, more optional components get added.
    Pico is not yet doing partial FPGA reprogramming on the fly - but I
am certain it is coming. It fits perfectly with the goals and objectives
    of the company and its clients.

    For the moment the problem is fairly small. But it is only going to
get worse with time. The decisions I make now, will either make my life
pleasant or horrible later.
    Better to work towards where we are going now.

    I guess I need to digest
Documentation/powerpc/booting-without-of.txt. now. At the moment things
are  busy
>
>>
>>      The vague Picture I have is the have something to do with some
>> datastructure that Mac's typically create at or prior to boot. And
>> that for
>> embedded systems we are building them
>>      externally compiling them and then attaching the compiled device
>> tree
>> to our project.
>
> That right.  You don't compile device base addresses, irqs, etc into
> the kernel.  You pass them in at boot time with a data structure.
>
>>
>>      I got a Xilinv V4 device currently with a Pic, UartLite, TEMAC,
>> Flash
>> and Keyhole (pseuodo serial host interface). Of those it is only certain
>> that the flash will always be there.
>>      We have bit images with Keyhole only, Uartlite only TEMAC only,
>> Sometimes we have a Pic sometimes not. I was trying to get to the
>> point were
>> I could dynamically add what was there
>>      to Platform devices during initialization.
>>
>>      If Device trees are static, then do they even apply to what I
>> have to
>> deal with ?
>
> Device trees don't have to be static.  They can be generated/modified
> on the fly if the bootloader supports it.  Or you can pass a different
> tree depending on what IP you have on the board.
    Can you populate the tree dynamically inside the Linux setup code ?

>
> Cheers,
> g.
>


-- 
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: Ethernet driver for Linux kernel 2.6 running on ML403

[Grant Likely]

On 9/23/06, David H. Lynch Jr. <dhlii@dlasys.net> wrote:
> > I've been half heartedly looking at what needs to be done to generate
> > a device tree based on either system.mhs or xparameters.h.  I'm
> > probably going to write a tiny C program that is compiled against
> > xparameters.h and spits out a valid dts file.  The dts file can then
> > be run through the device tree compiler to produce the flattened
> > device tree structure.
>     That sounds somewhat interesting.
>
>     But as was somewhat raised elsewhere - what about partial
> reprogramming the FPGA on the fly ?

Then you'll need to register/unregister devices from the platform bus
on the fly (assuming the FPGA is reprogrammed after control is passed
to Linux).  The device tree is primarily for passing information from
the boot loader to linux.  Once linux is booted and the fdt is used to
populate the platform buss, you can safely ignore it.

> > Device trees don't have to be static.  They can be generated/modified
> > on the fly if the bootloader supports it.  Or you can pass a different
> > tree depending on what IP you have on the board.
>     Can you populate the tree dynamically inside the Linux setup code ?

Yes; there is a common library that is being developed to
generate/modify the device tree from anywhere; boot loader, inside the
kernel (like for kexec), etc.  Search the mailing list.

-- 
Grant Likely, B.Sc. P.Eng.
Secret Lab Technologies Ltd.
grant.likely@secretlab.ca
(403) 399-0195