RE: XPS_LL_TEMAC works correctly?
There are a couple of bugs in the v1.00b version of xps_ll_temac (one in checksum offload, one in multicast address reception). You should try dropping back to v1.00a of the core and give that a try, or if you have EDK 10.1 you can move to v1.01a of the core. -Rick From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Mohammad Sadegh Sadri Sent: Monday, April 14, 2008 3:10 AM To: Rami WEHBI; linuxppc-embedded@ozlabs.org Subject: RE: XPS_LL_TEMAC works correctly? Rami, Thanks for reply, But if u study the kernel log I posted carefully, you can simply see that Kernel has mounted the root file system, Look at this line in my prev post : VFS: Mounted root (nfs filesystem). then init has began and after that nothing more happens. the NFS is working correctly and the folder can be mounted easily from other computers. I personally think that the problem can be with NFS or the root file system of ELDK. I have done the same things with older versions of EDK using PLB_TEMAC and every thing has worked correctly. Subject: RE: XPS_LL_TEMAC works correctly? Date: Mon, 14 Apr 2008 10:31:31 +0200 From: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Hi, I would suggest that you verify that your system file is already mounted on the host PC (where your server NFS is installed), and that the /etc/exports file (configuration file of the nfs server) permit to your board to mount the system file. example of an /etc/exports file: /opt/ml403/rootfs 192.168.206.223/24(rw,no_root_squash,sync,subtree_check) where the ip addresse is that of nfs client, and the path indicates where I mounted the system file. Good luck, Rami De : [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] De la part de Mohammad Sadegh Sadri Envoyé : lundi 14 avril 2008 10:16 À : linuxppc-embedded@ozlabs.org Objet : XPS_LL_TEMAC works correctly? Hi all, Using: EDK 9.2.02, Xilinx Linux 2.6.24-rc8-xlnx XPS_LL_TEMAC version 1.00.b I bring up the Linux kernel on ML403 -Rev04 board, LL_TEMAC buffer size 128kbits, and set to use SG DMA I encounter the following messages when the kernel wants to mount the root file system, as one can see the kernel has mounter the nfs root file system and init is initiated, but after that a Link carrier lost happens and it stops working. is this behavior natural? ( the PC has attansic gigabit ethernet port with kernel 2.6.24.4 running, nfs works very well in other tests) thanks . eth0: XLlTemac: speed set to 1000Mb/s eth0: XLlTemac: Send Threshold = 24, Receive Threshold = 4 eth0: XLlTemac: Send Wait bound = 254, Receive Wait bound = 254 IP-Config: Complete: device=eth0, addr=10.10.10.11, mask=255.255.255.0, gw=10.10.10.10, host=10.10.10.11, domain=, nis-domain=(none), bootserver=10.10.10.10, rootserver=10.10.10.10, rootpath= Looking up port of RPC 13/2 on 10.10.10.10 Looking up port of RPC 15/1 on 10.10.10.10 VFS: Mounted root (nfs filesystem). Freeing unused kernel memory: 88k init eth0: XLlTemac: PHY Link carrier lost. eth0: XLlTemac: speed set to 1000Mb/s eth0: XLlTemac: PHY Link carrier restored. ( KERNEL STOPS WORKING HERE) Sign in today. When you sign in to Windows Live Messenger you could win $1000 a day until May 12th. Learn more at SignInAndWIN.ca http://g.msn.ca/ca55/209 Sign in now! Windows Live Messenger is giving you a chance to win $1000 a day until May 12th Check out SignInAndWIN.ca today! http://g.msn.ca/ca55/214 ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
RE: Ethernet Jumbo Frames
Sure, it can be done. The Xilinx 10/100 Ethernet drivers have jumbo frame support in MontaVista/WindRiver Linux. As long as both ends are talking jumbo frames, works just fine. -Rick -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Darcy Watkins Sent: Monday, March 31, 2008 2:48 PM To: LinuxPPC-Embedded Subject: Ethernet Jumbo Frames Has anyone on this list ever been given a requirement to implement support for ethernet frames larger than the standard MTU of 1500? ... ... for normal 10/100 Ethernet? ... not gigabit. The application is to support certain encapsulation protocols without imposing smaller than 1500 byte MTU restrictions on the innermost protocol. I have been tasked to investigate this for a system based on PPC405EP. Can it be done using the IBM EMAC, Linux drivers, etc? Regards, Darcy ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
RE: xilinx Ml405 NFS mount problem
Robert, I saw an earlier email regarding v1.00b of xps_ll_temac. Besides the checksum offload issue in this version of the core, there is also an issue when receiving multicast packets where we've seen some ping packets lost around receipt of a multicast packets. So for example, we saw this issue when attached to a switch/router that sends out STP packets. When attached directly between target and host the issue disappeared. I believe this issue is fixed in v1.01a of the core being released in EDK 10.1. I also think there's an answer record on how to work around this issue, but I don't have that AR number handy (search the Xilinx website and let me know if you don't find it - if you think this applies to you at all). The issue you describe below doesn't appear to match the multicast issue, as you should see that regardless of which part you're in. You may want to talk to your FAE as to possible hw timing issues. Thanks, Rick -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Robert Woodworth Sent: Tuesday, April 01, 2008 5:44 PM To: John Linn Cc: linuxppc-embedded@ozlabs.org Subject: RE: xilinx Ml405 NFS mount problem Can you test your packet loss with your setup?? GigE or 100T?? Do you have hardware checksum turned on in your bitfile? I strongly believe that there is a timing problem in the MPMC3/LL_TEMAC. I think the smaller FX12 does not suffer as much as the larger FX60. My FX12 is fairly good, my FX60 is very bad. Guessing. The FX20 in the ML405 is somewhere between. When I make small changes to my bit file (I'm currently working on an image processing HDL module) the quality of my LL_TEMAC changes dramatically. If I take out one of my custom modules and re-synthesize the LL_TEMAC packet loss goes way up. Add another module, re-synthesize and packet loss is down. I would *really* like a Xilinx EDK expert give me some advise on this issue. Rob. On Tue, 2008-04-01 at 10:53 -0600, John Linn wrote: Now that you say that, I have been running TCP with my NFS mount as I'm mounting across a corporate network. I am also using the latest LL TEMAC with EDK 10.1. Thanks, John -Original Message- From: Robert Woodworth [mailto:[EMAIL PROTECTED] Sent: Tuesday, April 01, 2008 10:50 AM To: MingLiu Cc: John Linn; linuxppc-embedded@ozlabs.org Subject: RE: xilinx Ml405 NFS mount problem I think you may be suffering from the latest LL_TEMAC packet loss problem. (NFS/UDP really does not like packet loss) Let me guess. You are using a base system from Base System Builder Wizard? EDK 9.2i. Default syntheses/PR options. I have seen a massive packet loss problems on my ML403 and two other boards I have with an FX60. This is probably a hardware problem. Xilinx has acknowledged an LL_TEMAC problem to me but has not provided a fix. I have heard that things are better with EDK/ISE-10.1 but I have not tested it. The vendor of one of my boards (Pico) has fixed the problem on the FX60 by highly constraining the timing of the LL_TEMAC in map/PR. On my ML403 I used similar constraints and it fixed the problem, but only if the device is plugged into a GigE switch. The problem is still there with the same .bit file on a 100-T switch. Are you on a GigE switch? Rob. On Tue, 2008-04-01 at 16:15 +, MingLiu wrote: Dear John, Thank you for your replying. It’s not obvious to me what the problem is as I don’t see any driver failures. Have you tried using a ramdisk and then seeing if the network is working before using NFS root? Not yet. I will try it soon. However from the information on the LL_TEMAC, it seems everything is fine and it should work. And I’m assuming you have used the NFS root before so you know that it’s good for sure. I test on the ML405 with NFS root and haven’t seen this problem, but my setup is a little different. I use DHCP rather than a static IP, but other than that it’s similar. Yes. I used NFS before. I can make sure my NFS server works well. Also in principle, static IP should get a same result as DHCP, I think. How long has it been since you pulled from the Xilinx Git tree? I just pulled the Xilinx tree quite recently. I am using a latest kernel. BR Ming And I’m assuming you have used the NFS root before so you know that it’s good for sure. I test on the ML405 with NFS root and haven’t seen this problem, but my setup is a little different. I use DHCP rather than a static IP, but other than that it’s similar. I’m assuming that you accidentally got 2 different powerup outputs in the message below as the 1st stops and a 2nd starts in the middle.
RE: Compile time error, compiling Xilinx Linux 2.6 for XPS LLTEMAC
You should be able to contact your Xilinx sales rep for details on Virtex-5 FX as well as roadmap information. The Virtex-5 FXT product is coming soon and should be announced within the next month or so. I can't provide details, but your technical sales contact should be able to give you more info on timelines etc... As for EDK releases, Xilinx typically releases two per year (e.g., EDK 9.1 and 9.2 were both released in 2007). EDK 10.1 is scheduled for release before summer, and should be the only release in 2008 (with some service packs throughout the year). There shouldn't be any major differences from EDK 9.2.02 regarding IP/drivers. -Rick From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Mohammad Sadegh Sadri Sent: Monday, March 17, 2008 3:04 AM To: Stephen Neuendorffer; Koss, Mike(Mission Systems); linuxppc-embedded@ozlabs.org Subject: RE: Compile time error, compiling Xilinx Linux 2.6 for XPS LLTEMAC Ok, thanks for guidance, by the way it is interesting for me to hear about EDK 10.1 from u steve, EDK 9.2 has been around just for a little time and you are going to 10.1? What about future plan of xilinx about Virtex-5 FX? does this tool consider that? the future plan is really important for our development team. let me give a simple example, our dev team worked on the design of our system based on PLB and OPB buses for some thing near 6 month, just then EDK 9.2.02 released and suddenly we forced to change all of the designs and to define new activities specially focusing on MPMC. we did never consider MPMC before, but the release of EDK 9.2 changed every thing. Now, that would be nice, if we can know your future plan a little, that would help us to generate correct and real gant charts. and to assign human resources correctly. this is also true for the project budget. We know that Virtex-5 devices are really capable of doing better things than Virtex-4, specially the PCI express option is great and very usable for us, but we have not moved to virtex-5 yet, because there is no FX series or at least we do not know your plan about it. Our managers we seriously asking us if we have to move to Virtex-5 soon, we did not have any reasonable answer for them because we do not have any info from u at all. thanks Subject: RE: Compile time error, compiling Xilinx Linux 2.6 for XPS LLTEMAC Date: Sun, 16 Mar 2008 14:43:33 -0700 From: [EMAIL PROTECTED] To: [EMAIL PROTECTED]; [EMAIL PROTECTED]; linuxppc-embedded@ozlabs.org Ah, thanks mike... you knocked the answer loose out of my brain... In EDK 9.2., the ll_temac generates either SDMA or FIFO defines, as necessary. The platform data structure contains entries for both, with the correct ones being ignored. In order to get the code to compile, there are some defines in xparameters.h which have: #ifndef XPAR_LLTEMAC_0_LLINK_CONNECTED_FIFO_INTR #define XPAR_LLTEMAC_0_LLINK_CONNECTED_FIFO_INTR 0xdeadbeef #endif #ifndef XPAR_LLTEMAC_0_LLINK_CONNECTED_DMATX_INTR #define XPAR_LLTEMAC_0_LLINK_CONNECTED_DMATX_INTR 0xdeadbeef #endif #ifndef XPAR_LLTEMAC_0_LLINK_CONNECTED_DMARX_INTR #define XPAR_LLTEMAC_0_LLINK_CONNECTED_DMARX_INTR 0xdeadbeef #endif after including xparameter_ml403.h I'm guessing maybe you overwrote the xparameters.h file and got rid of these redefines? You can define it to be whatever you want, since the value will be ignored if you are using SDMA. In EDK 10.1, the BSP generator will always generate all the defines (even ones which are not sensible in the current configuration), which avoids the above annoyances. Steve -Original Message- From: [EMAIL PROTECTED] on behalf of Koss, Mike (Mission Systems) Sent: Sat 3/15/2008 9:12 PM To: Mohammad Sadegh Sadri; linuxppc-embedded@ozlabs.org Subject: RE: Compile time error, compiling Xilinx Linux 2.6 for XPS LLTEMAC That interrupt is defined if you build a xps_ll_temac with the xps_ll_fifo interface. Since you already stated that you're using the mpmc, I'm going to assume that you have it connected to a SDMA controller on the mpmc. As such the driver should be looking for that definition, and not the FIFO interrupt. I don't have your version of the virtex_devices.c to have a reference as to how the platform device is being defined, so hopefully either Stephen N can chime in w/ more information, or point me to the version of the virtex_devices.c that you're using and I can try to provide some more assistance. -- Mike From: Mohammad Sadegh Sadri [mailto:[EMAIL PROTECTED] Sent: Saturday, March 15, 2008 4:31 AM To: linuxppc-embedded@ozlabs.org Subject: Compile time error, compiling Xilinx Linux 2.6 for XPS LLTEMAC All, that should be a small problem, and i think that its solution should be simple, I generate a base system using EDK 9.2.02 , the base system contains XPS_LL_TEMAC , MPMC and other components, I generate the software libraries and copy
RE: Problems with plb_temac+hard_temac+2.6.24rc3
Try using hard_temac_v3_00_a with the ML403 board. There's an incompatibility (posted previously on this list) with PHY access. This could be causing the strange behavior you're seeing. -Rick -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of A. Nolson Sent: Wednesday, February 20, 2008 8:33 AM To: linuxppc-embedded@ozlabs.org Subject: Problems with plb_temac+hard_temac+2.6.24rc3 Hi, I am working with a ML403 platform and I have my kernel 2.6.24rc3 perfectly running on it. Almost everything seems to work but the ethernet. I am using the IP cores that come with the EDK 9.1sp2 ( plb_emac 3.00a + hard_temac 3.00b). The weird thing arises when I try to bring up the interface and use it. If I do ifconfig eth0 up the interface shows up but, strangely, it eithers not receives or send packets. I will explain myself, if I assing an IP manually and try to connect to another worksatation within the network ( by pinging from just one of the sides for example ) the interface seems only to send or receive packets , but generallty not both at the same time ( I can see this through the evolution of the Rx/Tx bytes in ifconfig). The only few times that both tx/rx work at the same time is when I do (ifconfig eth0 down and ifconfig eth0 up), but this only works sporadically and only for around a second or less. This is what I get after the first ifconfig eth0 up: [ 293.258765] eth0: XTemac: Options: 0xb8f2 [ 295.253048] eth0: XTemac: speed set to 10Mb/s [ 295.256042] eth0: XTemac: Send Threshold = 16, Receive Threshold = 2 [ 295.256095] eth0: XTemac: Send Wait bound = 1, Receive Wait bound = 1 [ 297.252047] eth0: XTemac: PHY Link carrier lost. [ 299.251657] eth0: XTemac: PHY Link carrier restored. and this after some ifconfig up/down: [ 293.258765] eth0: XTemac: Options: 0xb8f2 [ 295.253048] eth0: XTemac: speed set to 10Mb/s [ 295.256042] eth0: XTemac: Send Threshold = 16, Receive Threshold = 2 [ 295.256095] eth0: XTemac: Send Wait bound = 1, Receive Wait bound = 1 [ 297.252047] eth0: XTemac: PHY Link carrier lost. [ 299.251657] eth0: XTemac: PHY Link carrier restored. [ 438.159833] eth0: XTemac: Options: 0xb8f2 [ 440.154122] eth0: XTemac: speed set to 1000Mb/s [ 440.157316] eth0: XTemac: Send Threshold = 16, Receive Threshold = 2 [ 440.157369] eth0: XTemac: Send Wait bound = 1, Receive Wait bound = 1 [ 442.153739] eth0: XTemac: PHY Link carrier lost. [ 511.255518] eth0: XTemac: Options: 0xb8f2 [ 513.249808] eth0: XTemac: speed set to 10Mb/s [ 513.252729] eth0: XTemac: Send Threshold = 16, Receive Threshold = 2 [ 513.252784] eth0: XTemac: Send Wait bound = 1, Receive Wait bound = 1 [ 515.249462] eth0: XTemac: PHY Link carrier restored. [ 992.441619] eth0: XTemac: Options: 0xb8f2 [ 994.435904] eth0: XTemac: speed set to 1000Mb/s [ 994.438786] eth0: XTemac: Send Threshold = 16, Receive Threshold = 2 [ 994.438839] eth0: XTemac: Send Wait bound = 1, Receive Wait bound = 1 [ 996.435460] eth0: XTemac: PHY Link carrier lost. [ 1099.850622] eth0: XTemac: Options: 0xb8f2 [ 1101.844907] eth0: XTemac: speed set to 10Mb/s [ 1101.847816] eth0: XTemac: Send Threshold = 16, Receive Threshold = 2 [ 1101.847868] eth0: XTemac: Send Wait bound = 1, Receive Wait bound = 1 [ 1103.844479] eth0: XTemac: PHY Link carrier restored. [ 1180.024979] eth0: XTemac: Options: 0xb8f2 [ 1182.019263] eth0: XTemac: speed set to 1000Mb/s [ 1182.022265] eth0: XTemac: Send Threshold = 16, Receive Threshold = 2 [ 1182.022316] eth0: XTemac: Send Wait bound = 1, Receive Wait bound = 1 [ 1184.018815] eth0: XTemac: PHY Link carrier lost. It also seems to negotiate wrongly the speed since my network is 100Mb/s. This is my dmesg before ifconfig eth0 up: [0.00] Linux version 2.6.24-rc3-gd7ed933b-dirty ([EMAIL PROTECTED]) (gcc versio ion 4.0.0 (DENX ELDK 4.1 4.0.0)) #17 Mon Feb 18 11:52:47 CET 2008 [ [0.00] Xilinx ML403 Reference System (Virtex-4 FX) [ [0.00] Entering add_active_range(0, 0, 16384) 0 entries of 256 used [ [0.00] Zone PFN ranges: [ [0.00] DMA 0 - 16384 [ [0.00] Normal 16384 - 16384 [ [0.00] HighMem 16384 - 16384 [ [0.00] Movable zone start PFN for each node [ [0.00] early_node_map[1] active PFN ranges [ [0.00] 0:0 - 16384 [ [0.00] On node 0 totalpages: 16384 [ [0.00] DMA zone: 128 pages used for memmap[ [0.00] DMA zone: 0 pages reserved [ [0.00] DMA zone: 16256 pages, LIFO
RE: Xilinx ML310 Linux 2.6 PCI bridge
Grant, Can you give me more details on why you say the opb_pci bridge is badly broken? I know there have been issues with it in the past, but I'm not aware of major outages (perhaps I'm just not in the loop). However, word of warning. The Xilinx PCI bridge is badly broken. Xilinx is not supporting the PCI core and it is missing the ability to do certain types of transfers. Last I heard, Xilinx has no plans to fix their PCI core either. The opb_pci and plb_pci (plbv34) bridges have transitioned to the plbv36_pci bridge in EDK 9.2 and later. This bridge is fully supported and has been tested under MontaVista's 2.6.10 kernel. I believe only critical issues will be fixed in the opb/plbv34. Thanks, Rick ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
RE: ML405 gigabit ethernet with kernel 2.6.23
Hi, Yes, for 1500 MTU these aren’t too bad. One thing to note, using the TCP_STREAM option does not take advantage of zero-copy and possibly checksum offload on the transmit side. You should use the TCP_SENDFILE option for that. We typically use options such as: netperf -c -C -H 192.168.1.1 -t TCP_STREAM -- -s131072 -S131072 -m65536 netperf -c -C -H 192.168.1.1 -t UDP_STREAM -- -s131072 -S131072 -m8192 (if using jumbo frames of 8982) -Rick From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of MingLiu Sent: Thursday, November 08, 2007 2:32 AM To: kentaro; linuxppc-embedded@ozlabs.org Subject: RE: ML405 gigabit ethernet with kernel 2.6.23 Dear Kentaro, - netperf -H 192.168.1.1 -t TCP_STREAM 110 Mbps netperf -H 192.168.1.1 -t UDP_STREAM 210 Mbps - Are these results the ones with or without Jumbo-frame enabled? If no, they are quite good I think. The results from Montavista probably are the ones with Jumbo-frame enabled. For anybody who has interest on this topic, I have recently an accepted paper which has part of the content on this. The link is http://web.it.kth.se/~mingliu/publications/co_design(icfpt07).pdf and in 6.2 section, I listed our measurement results. 300Mbps for TCP and 400Mbps for UDP, with Jumbo-frame enabled. Unfortunately I did not explain the details and detailed configurations on our case. So these results are only for your reference. BR Ming 用 Windows Live Spaces 展示个性自我，与好友分享生活！ 了解更多信息！ http://spaces.live.com/?page=HP ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
RE: ML403 Hard TEMAC, PLB and Linux 2.6
Hi, The first thing I would try is to make sure eth1 comes up without first bringing up eth0. In other words, does it come up independently? If not, there could be something wrong with its configuration in the kernel or perhaps a hardware design issue. If both interfaces come up independently, but not together, then there’s likely a driver issue as we have not tested dual channel TEMAC with the Linux plb_temac driver. Perhaps others on the list have. The areas that I would look at would be: make sure each interface is getting a unique and correct PHY address; make sure any calls to the shared registers of the two channels are protected with semaphores/spinlocks. For example, I’m pretty sure the PHY registers are shared, so any PHY accesses should be protected. I would think other Xilinx driver accesses like Start/Stop/Reset/Get or SetOptions/etc… should be protected as they may access shared registers. -Rick From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED] Sent: Thursday, July 19, 2007 7:51 AM To: Rick Moleres Cc: Ming Liu; linuxppc-embedded@ozlabs.org; [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: RE: ML403 Hard TEMAC, PLB and Linux 2.6 Hi, we are trying to use both side of an hard temac + 2 plb temac in a Virtex4FX12 project. we succesfull implemented a single temac Montavista tree with eth0. when trying to use both temac, devices are correctly registered with kernel- eth0 comes up and working ok- when manually start eth1 (/sbin/ifconfig eth1 up) kernel hang without any error or info in the console # dmesg Linux version 2.6.10_mvl401-ml40x ([EMAIL PROTECTED]) (gcc version 3.4.3 (MontaVista 3.4.3-25.0.135.0702900 2007-04-01)) #250 Wed Jul 18 12:20:43 CEST 2007 Eurotel motherboard init Port by MontaVista Software, Inc. ([EMAIL PROTECTED]) On node 0 totalpages: 7812 DMA zone: 7812 pages, LIFO batch:1 Normal zone: 0 pages, LIFO batch:1 HighMem zone: 0 pages, LIFO batch:1 Built 1 zonelists Kernel command line: console=ttl0 root=/dev/xsysace2 rw ip=off Xilinx INTC #0 at 0x4120 mapped to 0xFDFFF000 PID hash table entries: 128 (order: 7, 2048 bytes) hr_time_init: arch_to_nsec = 8192000, nsec_to_arch = 1099511627 Console: colour dummy device 80x25 Dentry cache hash table entries: 4096 (order: 2, 16384 bytes) Inode-cache hash table entries: 2048 (order: 1, 8192 bytes) Memory: 28420k available (1864k kernel code, 528k data, 124k init, 0k highmem) Calibrating delay loop... 252.92 BogoMIPS (lpj=126464) Mount-cache hash table entries: 512 (order: 0, 4096 bytes) spawn_desched_task() desched cpu_callback 3/ ksoftirqd started up. desched cpu_callback 2/ desched thread 0 started up. NET: Registered protocol family 16 Registering platform device 'xilinx_temac.0'. Parent at platform Registering platform device 'xilinx_temac.1'. Parent at platform Registering platform device 'xilinx_sysace.0'. Parent at platform Registering platform device 'xilinx_gpio.0'. Parent at platform Registering platform device 'xilinx_gpio.1'. Parent at platform Registering platform device 'oled_fb.0'. Parent at platform Generic PHY: Registered new driver oled_fb: 4096 video memory mapped to c2011000 Console: switching to colour frame buffer device 16x8 xgpio #0 at 0x4000 mapped to 0xC202 xgpio #1 at 0x4002 mapped to 0xC204 io scheduler noop registered io scheduler anticipatory registered io scheduler deadline registered io scheduler cfq registered loop: loaded (max 8 devices) elevator: using anticipatory as default io scheduler System ACE at 0x4180 mapped to 0xC206, irq=4, 1000944KB xsysace: xsysace1 xsysace2 Universal TUN/TAP device driver 1.5 (C)1999-2002 Maxim Krasnyansky XTemac: using FIFO direct interrupt driven mode. eth0: Xilinx TEMAC #0 at 0x2000 mapped to 0xC208, irq=0 eth0: XTemac id 1.0f, block id 5, type 8 XTemac: using FIFO direct interrupt driven mode. eth1: Xilinx TEMAC #1 at 0x2001 mapped to 0xC20A, irq=10 eth1: XTemac id 1.0f, block id 5, type 8 i2c /dev entries driver i2c-xil_custom: registered with I2C (0) i2c-xil_custom: registered with I2C (1) mice: PS/2 mouse device common for all mice NET: Registered protocol family 2 IP: routing cache hash table of 512 buckets, 4Kbytes TCP: Hash tables configured (established 2048 bind 4096) NET: Registered protocol family 1 NET: Registered protocol family 17 EXT3-fs warning: maximal mount count reached, running e2fsck is recommended kjournald starting. Commit interval 5 seconds EXT3 FS on xsysace2, internal journal EXT3-fs: recovery complete. EXT3-fs: mounted filesystem with ordered data mode. VFS: Mounted root (ext3 filesystem). Freeing unused kernel memory: 124k init eth0: XTemac: Options: 0xb8f2 eth0: XTemac: speed set to 100Mb/s eth0: XTemac: PHY Link carrier lost. # /sbin/ifconfig eth1 up # eth1: XTemac: Options: 0xb8f2 Any
RE: XILINX SPI IP core with INTC IP core.
Leonid, Here's one that we've used (tested with Wind River's 2.6.14 and MV's 2.6.10 distributions). -Rick -Original Message- From: Leonid [mailto:[EMAIL PROTECTED] Sent: Friday, April 27, 2007 7:54 PM To: Grant Likely; linuxppc-embedded@ozlabs.org Cc: Rick Moleres Subject: XILINX SPI IP core with INTC IP core. Hi, I'm trying to use SPI and INTC IP cores together. Does somebody have adapter.c for SPI core, using interrupts? Thanks, Leonid. xspi_adapter.c Description: xspi_adapter.c ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
RE: ML403 and PPC4xx_DMA ?
Joachim, The Xilinx PPC405 core does not have an integrated DMA controller. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Joachim Förster Sent: Thursday, April 26, 2007 10:06 AM To: linuxppc-embedded@ozlabs.org Subject: ML403 and PPC4xx_DMA ? Hi all, I have a question regarding the PowerPC 405 Core on the Xilinx ML403 board and DMA . The Linux kernel has an option called CONFIG_PPC4xx_DMA. Do all/some PowerPC 4xx Cores have an integrated DMA Controller? I tried to find some documentation about this DMA Controller in several Xilinx and IBM manuals which cover the PowerPC 405 Core - but I didn't find anything. So, my question is: Does the Virtex-4 FX12 PowerPC 405 Core on the ML403 have such DMA Controller? If yes, is it usable within Linux to transfer data from RAM to a device's hardware buffers (typical task of a DMA controller)? Thanks, Joachim PS: I tried to compile a kernel image with CONFIG_PPC4xx_DMA enabled, but gcc complains about missing definitions in ppc4xx_dma.c ... e.g. DCRN_DMASR (defined in ibm405.h). Well I guess I have to have DCRN_MASR_BASE defined in xparameters_ml403.h but defined to what? ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
RE: Linux w/ML403 PLB TEMAC
Leonid, If it's not the ML403 board and the FX part is CES4 or later (read this at the bottom of the FX chip), then you will need hard_temac_v3_00_b to get the MDIO access working properly. If this is pre-CES4 silicon, then hard_temac_v3_00_a is the right version and there may be an issue with the MDIO signal connectivity in your design (? just guessing). You can also try to hardcode the PHY address (gmii_addr) and see if the speed detection works at that point - but my guess is it won't. -Rick -Original Message- From: Leonid [mailto:[EMAIL PROTECTED] Sent: Wednesday, April 04, 2007 5:50 PM To: Rick Moleres; linuxppc-embedded@ozlabs.org Subject: RE: Linux w/ML403 PLB TEMAC Hi, Rick: We have both in our design and both are 3.00a. I'm not sure why - I'll ask our HW folks. I have actually managed (just 30 minutes ago) to bring up network interface but I have commented out all accesses to PHY in your adapter.c and I set speed to 1000 always (see my adapter.c attached). Without these changes packets are not transmitted out of board. This is probably some issue in my EDK project. I'm not using ML403 actually but another proprietary board, based on Virtex 4 (69FX) FPGA. Thanks, Leonid. -Original Message- From: Rick Moleres [mailto:[EMAIL PROTECTED] Sent: Wednesday, April 04, 2007 4:41 PM To: Leonid; [EMAIL PROTECTED]; linuxppc-embedded@ozlabs.org Subject: RE: Linux w/ML403 PLB TEMAC Leonid, You mentioned that the TEMAC version if v3.00a. Is this the plb_temac version or the hard_temac version, or both? -Rick -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Leonid Sent: Wednesday, April 04, 2007 4:14 PM To: [EMAIL PROTECTED]; linuxppc-embedded@ozlabs.org Subject: RE: Linux w/ML403 PLB TEMAC I have investigated little bit more. Receive is working actually, but transmit doesn't. What can it be? -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Leonid Sent: Wednesday, April 04, 2007 12:06 PM To: [EMAIL PROTECTED]; linuxppc-embedded@ozlabs.org Subject: RE: Linux w/ML403 PLB TEMAC I have precisely the same problem you have described: [0.430515] XTemac: using FIFO direct interrupt driven mode. [0.437461] eth%d: XTemac: No PHY detected. Assuming a PHY at address 0 [0.445295] eth0: Xilinx TEMAC #0 at 0x0200 mapped to 0xC300, irq=0 [0.452256] eth0: XTemac id 1.0f, block id 5, type 8 [0.458665] tun: Universal TUN/TAP device driver, 1.6 [0.463712] tun: (C) 1999-2004 Max Krasnyansky [EMAIL PROTECTED] [0.471106] mice: PS/2 mouse device common for all mice [0.476339] TCP cubic registered [0.479615] NET: Registered protocol family 1 [0.484032] NET: Registered protocol family 17 [0.992599] eth0: XTemac: Options: 0xb8f2 [ 12.955691] eth0: XTemac: Not able to set the speed to 1000 (status: 0x0) [ 22.928615] eth0: XTemac: Not able to set the speed to 100 (status: 0x0) [ 32.901449] eth0: XTemac: Not able to set the speed to 10 (status: 0x0) [ 32.907976] eth0: XTemac: could not negotiate speed [ 33.921626] IP-Config: Complete: [ 33.924635] device=eth0, addr=192.168.0.223, mask=255.255.255.0, gw=192.168.0.1, [ 33.932418] host=LM200, domain=, nis-domain=(none), [ 33.937715] bootserver=192.168.0.141, rootserver=192.168.0.141, rootpath= [ 33.946230] Looking up port of RPC 13/2 on 192.168.0.141 [ 34.916694] eth0: XTemac: PHY Link carrier lost. My TEMAC core version is 3.00.a and low level code I'm using is working in u-boot without problems. I use Rick's adapter and also tried Ming's trick to set hardcoded speed value but with no success. I suspect something is configured wrong - phys is not detected: [0.437461] eth%d: XTemac: No PHY detected. Assuming a PHY at address 0 Leonid. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED] Sent: Wednesday, February 14, 2007 6:48 AM To: linuxppc-embedded@ozlabs.org Subject: RE: Linux w/ML403 PLB TEMAC Ming/Rick, I tried setting the speed to 1000 as below, but it did not change the result. I also tried Rick's new adapter.c with the same results. Changing the hard_temac_v3_b to hard_temac_v3_a was the change I needed. Unfortunately, the speed of the network is much slower now. I switched to DMA and then changed the Linux drivers for the DMA TEMAC v2 to v3. I have my own program to test performance. It seems everything is so slow it does not every complete to give me the statistics. My ping are also slower. I used to be able to ping my computer and get 0.6-0.7 ms times. With the DMA and TEMAC v3 I am now getting 1.8 ms times. I am now not sure if it is my build or my PPC design. For the PPC design I have a minimum PPC with OPB-RS232, PLB-DDR, and PLB-TEMAC. I use all the defaults from BSB except I check use interrupt on the RS232 and TEMAC. Any suggestions? Thanks, Glenn
RE: Linux w/ML403 PLB TEMAC
Leonid, You mentioned that the TEMAC version if v3.00a. Is this the plb_temac version or the hard_temac version, or both? -Rick -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Leonid Sent: Wednesday, April 04, 2007 4:14 PM To: [EMAIL PROTECTED]; linuxppc-embedded@ozlabs.org Subject: RE: Linux w/ML403 PLB TEMAC I have investigated little bit more. Receive is working actually, but transmit doesn't. What can it be? -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Leonid Sent: Wednesday, April 04, 2007 12:06 PM To: [EMAIL PROTECTED]; linuxppc-embedded@ozlabs.org Subject: RE: Linux w/ML403 PLB TEMAC I have precisely the same problem you have described: [0.430515] XTemac: using FIFO direct interrupt driven mode. [0.437461] eth%d: XTemac: No PHY detected. Assuming a PHY at address 0 [0.445295] eth0: Xilinx TEMAC #0 at 0x0200 mapped to 0xC300, irq=0 [0.452256] eth0: XTemac id 1.0f, block id 5, type 8 [0.458665] tun: Universal TUN/TAP device driver, 1.6 [0.463712] tun: (C) 1999-2004 Max Krasnyansky [EMAIL PROTECTED] [0.471106] mice: PS/2 mouse device common for all mice [0.476339] TCP cubic registered [0.479615] NET: Registered protocol family 1 [0.484032] NET: Registered protocol family 17 [0.992599] eth0: XTemac: Options: 0xb8f2 [ 12.955691] eth0: XTemac: Not able to set the speed to 1000 (status: 0x0) [ 22.928615] eth0: XTemac: Not able to set the speed to 100 (status: 0x0) [ 32.901449] eth0: XTemac: Not able to set the speed to 10 (status: 0x0) [ 32.907976] eth0: XTemac: could not negotiate speed [ 33.921626] IP-Config: Complete: [ 33.924635] device=eth0, addr=192.168.0.223, mask=255.255.255.0, gw=192.168.0.1, [ 33.932418] host=LM200, domain=, nis-domain=(none), [ 33.937715] bootserver=192.168.0.141, rootserver=192.168.0.141, rootpath= [ 33.946230] Looking up port of RPC 13/2 on 192.168.0.141 [ 34.916694] eth0: XTemac: PHY Link carrier lost. My TEMAC core version is 3.00.a and low level code I'm using is working in u-boot without problems. I use Rick's adapter and also tried Ming's trick to set hardcoded speed value but with no success. I suspect something is configured wrong - phys is not detected: [0.437461] eth%d: XTemac: No PHY detected. Assuming a PHY at address 0 Leonid. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED] Sent: Wednesday, February 14, 2007 6:48 AM To: linuxppc-embedded@ozlabs.org Subject: RE: Linux w/ML403 PLB TEMAC Ming/Rick, I tried setting the speed to 1000 as below, but it did not change the result. I also tried Rick's new adapter.c with the same results. Changing the hard_temac_v3_b to hard_temac_v3_a was the change I needed. Unfortunately, the speed of the network is much slower now. I switched to DMA and then changed the Linux drivers for the DMA TEMAC v2 to v3. I have my own program to test performance. It seems everything is so slow it does not every complete to give me the statistics. My ping are also slower. I used to be able to ping my computer and get 0.6-0.7 ms times. With the DMA and TEMAC v3 I am now getting 1.8 ms times. I am now not sure if it is my build or my PPC design. For the PPC design I have a minimum PPC with OPB-RS232, PLB-DDR, and PLB-TEMAC. I use all the defaults from BSB except I check use interrupt on the RS232 and TEMAC. Any suggestions? Thanks, Glenn (Embedded Ming Liu [EMAIL PROTECTED]@ozlabs.org image moved 02/12/2007 11:48 AM to file: pic04169.pcx) Sent by: [EMAIL PROTECTED] To:[EMAIL PROTECTED] cc:linuxppc-embedded@ozlabs.org Subject:RE: Linux w/ML403 PLB TEMAC Security Level:? Internal Dear Glenn, 3. The speed of the network was very poor. I wanted to implement DMA for the TEMAC. I created a new PPC with BSB using DMA on the TEMAC. Kernel recompilied without a problem, but upon starting the kernel I got: In fact, the old cores of TEMAC(plb_temac 2.00 hard_temac 1.00) also support DMA. But of course the 3.00 cores are prefered because of other improved features. 6. I am using busybox 1.2.1 which worked fine previously configuring the network. Now when I execute ifconfig I get the following problem: [ 12.228721] eth0: XTemac: Options:
RE: Linux w/ML403 PLB TEMAC
Glenn, Make sure that hard_temac_v3_00_a is being used in your hardware design for the ML403 board (BSB defaults to hard_temac_v3_00_b, which doesn't work well for PHY communication on the ML403 board). Then, take a look at my post on this mailing list from 2/8/07 where I included a new adapter.c that has a bit better PHY address detection and auto-negotiation. You may not need it, but you can see the changes. Thanks, Rick -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED] Sent: Monday, February 12, 2007 9:13 AM To: linuxppc-embedded@ozlabs.org Subject: Linux w/ML403 PLB TEMAC I am trying to get Linux up on my ML403 board with the PLB TEMAC with SGDMA. I am almost there and am not sure where to go now. I have seen many posts on this from Robert, Ming, and Rick. Hopefully somebody know the answer. Since I am going to detail how I got to where I am it can be somewhat of a guide for others (unless I am doing something really wrong). 1. I started with Linux 2.6.19 from kernel.org. I copied over the xparameters_ml40x.h file to xparameters_ml403.h in arch/ppc/platforms/4xx/xparameters. Setting up my kernel configuration and downloading to the board everything worked OK. ** I did not have the TEMAC configured or as part of my PPC project. 2. Next I created a new PPC with the PLB TEMAC and applied all four kernel patches from PAULUS (http://source.mvista.com/~ank/paulus-powerpc/20060309/). A couple of the files did not patch completely, so I had to do it by hand. Recompiling the kernel (with the TEMAC configured to on) I now had network support. 3. The speed of the network was very poor. I wanted to implement DMA for the TEMAC. I created a new PPC with BSB using DMA on the TEMAC. Kernel recompilied without a problem, but upon starting the kernel I got: [3.813223] Oops: machine check, sig: 7 [#1] [3.864368] NIP: C00E7B08 LR: C00E1640 CTR: [3.923854] REGS: c01c4f50 TRAP: 0202 Not tainted (2.6.19) [3.992778] MSR: 00029030 EE,ME,IR,DR CR: 8828 XER: 2000 [4.069670] TASK = c052ab70[1] 'swapper' THREAD: c052e000 [4.132247] GPR00: C00E1640 C052FE10 C052AB70 0068 C5002200 C04A242C 0001 [4.233281] GPR08: C04A2304 C5002010 2828 CD64 [4.334318] GPR16: 0B6654D8 [4.435353] GPR24: C017E890 C04A22D8 C017EA00 C017E9C8 C017E888 C04A2260 C04A22D8 [4.538579] NIP [C00E7B08] XPacketFifoV200a_Initialize+0x74/0x7c [4.610762] LR [C00E1640] XTemac_ConfigureFifoAccess+0x28/0x9c [4.680752] Call Trace: [4.710037] [C052FE10] [C000ADD8] __ioremap+0xe8/0x14c (unreliable) [4.785448] [C052FE20] [C00E1640] XTemac_ConfigureFifoAccess+0x28/0x9c [4.863880] [C052FE30] [C00DFCF8] Initialize+0x3c/0xd0 [4.925647] [C052FE40] [C00DF354] xtenet_probe+0x14c/0x5fc [4.991581] [C052FEB0] [C00D6B38] really_probe+0x84/0x154 [5.056472] [C052FED0] [C00D6D04] driver_probe_device+0xdc/0xfc [5.127613] [C052FEF0] [C00D6E68] __driver_attach+0x88/0xf4 [5.194588] [C052FF10] [C00D5CC0] bus_for_each_dev+0x54/0x94 [5.262604] [C052FF40] [C00D6EF8] driver_attach+0x24/0x34 [5.327496] [C052FF50] [C00D63E8] bus_add_driver+0x68/0x1b8 [5.394471] [C052FF70] [C00D744C] driver_register+0x98/0xac [5.461446] [C052FF80] [C01BBC00] xtenet_init+0x18/0x28 [5.524358] [C052FF90] [C0002454] init+0xb0/0x288 [5.580917] [C052FFF0] [C0004EA0] kernel_thread+0x44/0x60 [5.645794] Instruction dump: [5.681427] 3800 901f3694 91690004 90a90008 9149 380a 7c0004ac 900a [5.775062] 80010014 3860 83e1000c 7c0803a6 38210010 4e800020 2c03 7c0802a6 [5.875957] Kernel panic - not syncing: Attempted to kill init! Going back through previous posts I found that I need to upgrade the kernel driver for the DMA and TEMAC to V3. 4. From EDK 8.2.02i SP2.4+0 I copied the files from the BSP to the kernel using the following steps. a. Copied the files from linux\drivers\net\xilinx_temac of the BSP to drivers/net/xilinx_temac of the kernel preserving the Makefile from the kernel. b. To adapter.c I remove the #include xilinx_devices.h and added #include linux/platform_devices.h and #include platforms/4xx/virtex.h c. To adapter.c I changed all instances of CHECKSUM_HW to CHECKSUM_PARTIAL d. To the Makefile in linux/drivers/net/xilinux_temac I added xtemac_stats.o e. I removed the #include xparameters.h from xtemac.h f. Copied the files from linux\drivers\xilinx_common of the BSP to drivers/xilinx_edk of the kernel. g. In the drivers/xililnx_edk Makefile I removed the line containing xdma_channel.o xdma_channel_sg.o h. In the drivers/xililnx_edk Makefile I commented out the line with xlinx_syms.o 5. Recompiled the kernel I everything was OK. Starting the kernel everything looked OK: [
RE: Speed of plb_temac 3.00 on ML403
Ming, snip 1. Results are from PLB_TEMAC, not GSRD. You would likely see similar throughput rates with GSRD and Linux. Problem 1: From the website for GSRD, I know that it uses a different structure than PLB, where a Multi port mem controller and DMA are added to release the CPU from move data between Memory and TEMAC. So can GSRD achieve a higher performance than PLB_TEMAC, or similar performance like what you said above? If their performance is similar, what's the advantage for GSRD? Could you please explain some differences between these two structures? GSRD is a reference design intended to exhibit high-performance gigabit rates. It offloads the data path of the Ethernet traffic from the PLB bus, under the assumption that the arbitrated bus is best used for other things (control, other data, etc...). With Linux, however, GSRD still only achieves slightly more than 500Mbps TCP. We see similar numbers with PLB TEMAC, and with other stacks we see similar numbers as GSRD as well (e.g., Treck). The decision points for using GSRD would be a) what else needs to happen on the PLB in your system, and b) Xilinx support. GSRD is a reference design, so it's not officially supported through the Xilinx support chain. However, many of its architectural concepts are being considered for future EDK IP (sorry, no timeframe). For now, I recommend PLB TEMAC because it's part of the EDK, supported, and gets as good performance in most use cases. 2. Assuming you have everything tuned for SGDMA based on previous emails, I would suspect the bottleneck is the 300MHz CPU *when* running Linux. In Linux 2.6 we've not spent any time trying to tune the TCP/Ethernet parameters on the target board or the host, so there could be some optimizations that can be done at that level. In the exact same system we can achieve over 800Mbps using the Treck TCP/IP stack, and with VxWorks it was over 600Mbps. Problem 2. I read XAPP546 of High performance TCP/IP on xilinx FPGA devices using the Treck embedded TCP/IP stack. I notice that the features of Treck TCP/IP stack include: Zero-copy send and receive, Jumbo-frame support, CSUM offload, etc. which could achieve a much higher performance than not using it. However in the Xilinx TEMAC core V3.00, these features are all supported: Zero-copy is supported by sendfile() when using Netperf; Jumbo-frame is also supported; CSUM offload and DRE are also supported by the hardware. So does this mean I can achieve a similarly high performance with PLB_TEMAC V3.00 and without Treck TCP/IP stack? I mean if all the features of Treck stack have been included in the PLB_TEMAC cores, what's the use for Treck stack? Note that Linux only supports zero-copy on the transmit side (i.e., sendfile), not on the receive side. I'm not going to recommend one RTOS or network stack over another. Treck is a general purpose TCP/IP stack that can be used in a standalone environment or in various RTOS environments (I think). We've found that Treck, in the case where it is used without an RTOS, is a higher performing stack than the Linux stack. The VxWorks stack is also good, and Linux (of the three I've mentioned) seems to be the slowest. Again, it's possible that the Linux stack could be tuned better, but we haven't taken the time to try this. ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
RE: Speed of plb_temac 3.00 on ML403
Ming, Here's a quick summary of the systems we used: Operating system: MontaVista Linux 40 Benchmark tool: NetPerf / NetServer Kernel: Linux ml403 2.6.10_mvl401-ml40x IP Core: Name version: PLB TEMAC 3.00A Operation Mode: SGDMA mode TX/RX DRE: Yes / Yes TX/RX CSUM offload: Yes / Yes TX Data FIFO depth: 131072 bits (i.e. 16K bytes) RX Data FIFO depth: 131072 bits (i.e. 16K bytes) Xilinx Platform Hardware: Board: ML403 / Virtex4 FX12 Processor: PPC405 @ 300MHz Memory type:DDR Memory burst: Yes PC-side Test Hardware: Processor: Intel(R) Pentium(R) 4 CPU 3.20GHz OS: Ubuntu Linux 6.06 LTS, kernel 2.6.15-26-386 Network adapters used: D-LinkDL2000-based Gigabit Ethernet (rev 0c) - Are Checksum offload, SGDMA, and DRE enabled in the plb_temac? - Are you using the TCP_SENDFILE option of netperf? Your UDP numbers are similar already to what we saw in Linux 2.6, and your TCP numbers are similar to what we saw *without* the sendfile option. I don't believe the PLB is the bottleneck here. We had similar platforms running with Treck and have achieved over 800Mbps TCP rates (Tx and Rx) over the PLB. To answer your questions: 1. Results are from PLB_TEMAC, not GSRD. You would likely see similar throughput rates with GSRD and Linux. 2. Assuming you have everything tuned for SGDMA based on previous emails, I would suspect the bottleneck is the 300MHz CPU *when* running Linux. In Linux 2.6 we've not spent any time trying to tune the TCP/Ethernet parameters on the target board or the host, so there could be some optimizations that can be done at that level. In the exact same system we can achieve over 800Mbps using the Treck TCP/IP stack, and with VxWorks it was over 600Mbps. I'm not a Linux expert, so I don't know what's tunable for network performance, and there is a possibility the driver could be optimized as well. Thanks, -Rick -Original Message- From: Ming Liu [mailto:[EMAIL PROTECTED] Sent: Friday, February 09, 2007 7:17 AM To: Rick Moleres Cc: linuxppc-embedded@ozlabs.org Subject: RE: Speed of plb_temac 3.00 on ML403 Dear Rick, Again the problem of TEMAC speed. Hopefully you can give me some suggestion on that. With a 300Mhz system we saw about 730Mbps Tx with TCP on 2.4.20 (MontaVista Linux) and about 550Mbps Tx with TCP on 2.6.10 (MontaVista again) - using netperf w/ TCP_SENDFILE option. We didn't investigate the difference between 2.4 and 2.6. Now with my system(plb_temac and hard_temac v3.00 with all features enabled to improve the performance, Linux 2.6.10, 300Mhz ppc, netperf), I can achieve AT MOST 213.8Mbps for TCP TX and 277.4Mbps for TCP RX, when jumbo-frame is enabled as 8500. For UDP it is 350Mbps for TX, also 8500 jumbo-frame is enabled. So it looks that my results are still much less than yours from Xilinx(550Mbps TCP TX). So I am trying to find the bottleneck and improve the performance. When I use netperf to transfer data, I noticed that the CPU utilization is almost 100%. So I suspect that CPU is the bottleneck. However other friends said the PLB structure is the bottleneck, because when the CPU is lowered to 100Mhz, the performance will not change much, but if the PLB frquency is lowered, it will. Then they conclude that with the PLB structure, the CPU will wait a long time to load and store data from DDR. So PLB is the criminal. Then come some questions. 1. Is your result from the GSRD structure or just the normal PLB_TEMAC? Will the GSRD achieve a better performance than the normal PLB_TEMAC? 2. Which on earch is the bottleneck for the network performance, CPU or PLB structure? Is that possible for PLB to achieve a much higher throughput? 3. Because your result is based on Montavista Linux. Is there any difference between MontaVista Linux and the general open-source linux kernel which could lead to different performance? I know that many persons including me are struggling to improve the performance of PLB_TEMAC on ML403. So please give us some hints and suggestions with your experience and research. Thanks so much for your work. BR Ming _ 与联机的朋友进行交流，请使用 MSN Messenger: http://messenger.msn.com/cn ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
RE: ML403 Hard TEMAC, PLB and Linux 2.6
Hi, As Ming says the Linux 2.6 TEMAC driver is made available in EDK 8.2.2 as part of the BSP and Libraries generation for Linux 2.6. Note that we made a recent fix for better PHY address detection and speed negotiation. I've attached the adapter here, and it will be available in EDK 9.1.1 when that's released. Thanks, Rick -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Ming Liu Sent: Thursday, February 08, 2007 2:31 AM To: [EMAIL PROTECTED] Cc: linuxppc-embedded@ozlabs.org Subject: RE: ML403 Hard TEMAC, PLB and Linux 2.6 Hi, In xapp902, they are using the old cores for Temac. So it will be easier to generate a project in EDK 8.2. Not only the cores there are new, but also it can generate the driver for linux 2.6. BR Ming From: Mohammad Sadegh Sadri [EMAIL PROTECTED] To: [EMAIL PROTECTED] CC: linuxppc-embedded@ozlabs.org Subject: RE: ML403 Hard TEMAC, PLB and Linux 2.6 Date: Thu, 8 Feb 2007 07:13:47 + Hi Thanks for reply Well, regarding xapp902, there is a very simple question, Where can I find it? It seems that Xilinx has deleted all of the links to these files. Subject: Re: ML403 Hard TEMAC, PLB and Linux 2.6 From: [EMAIL PROTECTED] To: [EMAIL PROTECTED] CC: linuxppc-embedded@ozlabs.org Date: Thu, 8 Feb 2007 06:51:45 +0100 Le mercredi 07 f�vrier 2007 ?22:30 +, Mohammad Sadegh Sadri a �crit : Hi Mohammad, Please find here after some answer 1- I want to use, ML403, Hard TEMAC and PLB TEMAC cores. Is there any ready to use design, or any reference design available for this? I'm using EDK 8.1 and I understood that, when I choose the ML403 board , EDK does not use hard temac, so , should I add it manually? ( well this is funny, but the wizard does not use hard temac , is it true? ) Is there any ready EDK projects for ML403, with TEMAC and PLB TEMAC modules already inserted and cofigured? (I don't want to use GSRD ) ( If yes would you please put the link here ) You can start from XAPP 902 from Xilinx, this design demonstrate TEMAC use in loopback mode. Some memers from that community have tried from that design as a starting point. I did not nknow if the succeed. I would recommand to get EDK 8.2 SP2 and use the Wizard to build a new design with TEMAC. 2- Simply, Is there any driver available for linux 2.6 , for PLB TEMAC and Hard TEMAC modules? If yes , can you put the link here, so that I can download it? For the kernel you can get it from Montavista source code site using GIT to download it (linux-xilinx-26). This is 2.6.17.4 version (last week!) Then you will need to pacth the Kernel with TEMAC drivers (look for TEMAC PAULUS MVISTA with google, or follow my messages in that mailing list) NOTE: If you use that TEMAC patch do not use SGDMA on your TEMAC, use FIFO. thanks Regards Chris _ Personalize your Live.com homepage with the news, weather, and photos you care about. http://www.live.com/getstarted.aspx?icid=T001MSN30A0701 ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded _ Live Search: New search found http://get.live.com/search/overview ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded _ 与联机的朋友进行交流，请使用 MSN Messenger: http://messenger.msn.com/cn adapter.tar.gz Description: adapter.tar.gz ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
RE: ML403 hard Ethernet under Linux 2.6.18
Magnus, (reposting with zipped version of adapter.c) Hard_temac_v3_00_b was created to fix a compatibility problem in the MDIO interface for V4FX production silicon (CES4 or later). Unfortunately, it does not work well with silicon that is pre-CES4, which is true of all ML403 boards. The bottom line is that you should adhere to the following comment: * Note also a silicon issue with Xilinx V4FX with regards to MDIO access: * pre-CES4 chips (ML403, pre-production ML405/ML410) * use hard_temac_v3_00_a * CES4 or later chips (production ML405, ML410 boards) * use hard_temac_v3_00_b I've also attached a new adapter.c that does a slightly better job with the PHY speed negotiation. This one will be shipped in EDK 9.1.1. Thanks, Rick -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Magnus Hjorth Sent: Thursday, January 25, 2007 8:58 AM To: linuxppc-embedded@ozlabs.org Subject: Re: ML403 hard Ethernet under Linux 2.6.18 jozsef imrek wrote: On Thu, 25 Jan 2007, Magnus Hjorth wrote: Hi, I'm trying to get Linux 2.6.18.6 working on an ML403 board with a basic EDK design with a hard_temac and uart. I've generated the BSP for linux_2_6, copied the drivers and twiddled a little to make it all compile. The TEMAC driver seems to find the hardware, but the speed negotiation seems not to work. I can see the speed LEDs first go to 100 Mbit, then ... i suppose you are using plb_temac 3.00, with the corresponding driver. plb_temac 3.00.a and hard_temac 3.00.b. The driver is the one that was generated in the BSP using Xilinx EDK 8.2, adapter.c says v2.00b. The only code that I have added myself is a header file xio.h containing: #include asm/io.h #define XIo_In32(p) in_be32((volatile void *)p) #define XIo_Out32(p,v) out_be32((volatile void *)p,v) #define XIo_Out8(p,v) out_8((volatile void *)p,v) did you try to uncomment #define XILINX_PLB_TEMAC_3_00A_ML403_PHY_SUPPORT in adapter.c ? I did try that, and it seems to work even worse. It claims the speed is set to 10Mbit but the LEDs show it's still in 100Mbit operation as it is directly after programming the FPGA... The transmit LED is on for a short while before the Link carrier lost message. Startup messages shown below. loaded at: 0040 004B613C board data at: 004B4124 004B413C relocated to: 00404094 004040AC zimage at: 00404EA7 004B3CFC avail ram: 004B7000 03D09000 Linux/PPC load: console=ttyS0,9600 ip=on Uncompressing Linux...done. Now booting the kernel Linux version 2.6.18.6mh1 ([EMAIL PROTECTED]) (gcc version 3.4.1) #14 7 Xilinx ML403 Reference System (Virtex-4 FX) Built 1 zonelists. Total pages: 15625 Kernel command line: console=ttyS0,9600 ip=on Xilinx INTC #0 at 0x4120 mapped to 0xFDFFE000 PID hash table entries: 256 (order: 8, 1024 bytes) Console: colour dummy device 80x25 Dentry cache hash table entries: 8192 (order: 3, 32768 bytes) Inode-cache hash table entries: 4096 (order: 2, 16384 bytes) Memory: 60184k available (1148k kernel code, 448k data, 68k init, 0k highmem) Mount-cache hash table entries: 512 NET: Registered protocol family 16 NET: Registered protocol family 2 IP route cache hash table entries: 512 (order: -1, 2048 bytes) TCP established hash table entries: 2048 (order: 1, 8192 bytes) TCP bind hash table entries: 1024 (order: 0, 4096 bytes) TCP: Hash tables configured (established 2048 bind 1024) TCP reno registered Initializing Cryptographic API io scheduler noop registered io scheduler anticipatory registered (default) Serial: 8250/16550 driver $Revision: 1.90 $ 4 ports, IRQ sharing enabled serial8250.0: ttyS0 at MMIO 0x40401003 (irq = 1) is a 16550A XTemac: using FIFO direct interrupt driven mode. eth0: Xilinx TEMAC #0 at 0x8120 mapped to 0xC400, irq=0 eth0: XTemac id 1.0f, block id 5, type 8 TCP bic registered NET: Registered protocol family 1 eth0: XTemac: Options: 0xb8f2 eth0: XTemac: speed set to 10Mb/s Sending DHCP requests .6eth0: XTemac: PHY Link carrier lost. . timed out! IP-Config: Reopening network devices... eth0: XTemac: Options: 0xb8f2 eth0: XTemac: speed set to 10Mb/s Sending DHCP requests .. timed out! IP-Config: Reopening network devices... eth0: XTemac: Options: 0xb8f2 -- Magnus Hjorth, M.Sc. Omnisys Instruments AB Gruvgatan 8 SE-421 30 Västra Frölunda, SWEDEN Phone: +46 31 734 34 09 Fax: +46 31 734 34 29 http://www.omnisys.se ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded adapter.tar.gz Description: adapter.tar.gz ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
RE: plb_temac w/linux 2.6.18.1 driver init error
Robert, The DRE type should not matter. The problem seems to be that the hardware is built for DMA but for some reason the driver is trying to initialize the FIFO. It seems that something is out of sync. Since you're using EDK 8.2i, I wonder if you can go grab SP2, which was released Oct. 30th. It has Linux 2.6 as part of its BSP generation, along with a Linux 2.6 plb_temac driver (I don't recall where you got your version). Here are the paths, or you can just use the BSP generation process. sw\ThirdParty\bsp\linux_2_6_v1_00_a\drivers\temac_linux_2_6_v2_00_b\src sw\ThirdParty\bsp\linux_2_6_v1_00_a\linux\arch\ppc\platforms\4xx Regarding bandwidth, we saw similar numbers with plb_temac as seen with GSRD using netperf when plb_temac is built with DMA, DRE, and checksum offload (you have CSO turned off). I think the max Linux 2.6 TCP numbers were 530Mbps (TX) and 310Mbps (RX). We saw better with Linux 2.4 (730Mbps/360Mbps) - but we didn't spend time investigating the difference. Thanks, Rick -Original Message- From: robert corley [mailto:[EMAIL PROTECTED] Sent: Wednesday, November 01, 2006 2:29 PM To: Rick Moleres Subject: Re: plb_temac w/linux 2.6.18.1 driver init error Rick; Below are the defines generated by the EDK8.2 and are equal to those used in my xparameters_ml403.h file for linux. It would appear that they are in sync. Note that there are two #defines no longer generated by EDK but still used in the arch/ppc/platforms/4xx/virtex.c: #define XPAR_TEMAC_0_TEMAC_DCR_HOST 0 #define XPAR_TEMAC_0_INCLUDE_DRE1 /**/ /* Definitions for driver TEMAC */ #define XPAR_XTEMAC_NUM_INSTANCES 1 /* Definitions for peripheral PLB_TEMAC_0 */ #define XPAR_PLB_TEMAC_0_DEVICE_ID 0 #define XPAR_PLB_TEMAC_0_BASEADDR 0x6000 #define XPAR_PLB_TEMAC_0_HIGHADDR 0x60003FFF #define XPAR_PLB_TEMAC_0_RXFIFO_DEPTH 131072 #define XPAR_PLB_TEMAC_0_TXFIFO_DEPTH 131072 #define XPAR_PLB_TEMAC_0_MAC_FIFO_DEPTH 64 #define XPAR_PLB_TEMAC_0_DMA_TYPE 3 #define XPAR_PLB_TEMAC_0_TX_DRE_TYPE 2 #define XPAR_PLB_TEMAC_0_RX_DRE_TYPE 2 #define XPAR_PLB_TEMAC_0_INCLUDE_TX_CSUM 0 #define XPAR_PLB_TEMAC_0_INCLUDE_RX_CSUM 0 /**/ Do you think that the type of RX TX DRE makes a difference? That is, shall I use DSP48 blocks or logic (or that just a design consideration rather than a driver issue)? You've probably done some measurements on bandwidth throughput. Can you tell me how much bw I can get out of the plb_temac with and without DMA mode? Would it be better to use the device is a similar manner as was done in the GSRD, or can I expect to get similar bandwidths this way? -cy - Original Message From: Rick Moleres [EMAIL PROTECTED] To: robert corley [EMAIL PROTECTED]; David Bolcsfoldi [EMAIL PROTECTED] Cc: linux linuxppc-embedded linuxppc-embedded@ozlabs.org Sent: Wednesday, November 1, 2006 3:45:38 PM Subject: RE: plb_temac w/linux 2.6.18.1 driver init error Robert, I haven't seen this before, but perhaps the plb_temac hardware is built for DMA but xparameters.h is out of sync and thinks it's built with FIFO mode? This would probably cause a machine check if trying to write a FIFO register but it doesn't exist. You can crosscheck xparameters.h with your hardware design to verify. -Rick ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
RE: plb_temac w/linux 2.6.18.1 driver init error
Robert, No, I'm not sure where gmii.h is. I see in the adapter.c delivered in EDK 8.2.02i it includes linux/mii.h, but I don't see an include of gmii.h. Perhaps you can incorporate this new adapter.c as well. I believe gmii.h is a Linux 2.4 file (?). -Rick -Original Message- From: Robert Corley [mailto:[EMAIL PROTECTED] Sent: Wednesday, November 01, 2006 4:41 PM To: Rick Moleres Cc: linux linuxppc-embedded Subject: plb_temac w/linux 2.6.18.1 driver init error Rick; I see now what you were writing about. The IPIF registers for controlling FIFO control (both xmit and rcv) are not accessible when a DMA mode is used, as is shown on page 26 of the plb_temac datasheet. Examination of the drivers generated by the EDK show that a check for the presence of a DMA engine is done in xtemac.c to avoid incorrectly resetting a DMA-based plb_temac; whereas, the drivers for earlier versions of the plb_temac do not have this test. Looks like I will have to incorporate the drivers generated by the EDK8.2 into the linux tree. Do you know where I might get the file gmii.h referenced in adapter.c? -cy ___ Linuxppc-embedded mailing list Linuxppc-embedded@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
MontaVista 2.6 Kernel support for Xilinx ML40x
Note that Xilinx plans to update the MV drivers to support the latest IP in EDK 8.2.2 (due out around October), and these drivers would be part of the BSP generation process of Platform Studio. Sorry, the timing of the MV ML40x work and our EDK 8.1.x release was such that MV had no choice but to use older IP and drivers. -Rick -Original Message- From: [EMAIL PROTECTED] [mailto:linuxppc-embedded-bounces+moleres=xilinx.com at ozlabs.org] On Behalf Of Michael Galassi Sent: Thursday, August 24, 2006 9:18 AM To: Frank D Lombardo Cc: linuxppc-embedded at ozlabs.org Subject: Re: MontaVista 2.6 Kernel support for Xilinx ML40x I too had high hopes when I heard an LSP for the ML40x was imminent, I nabbed it and was disappointed to find that their drivers still only support relatively old versions of the Xilinx IP. It would seem that they are still creating the design they ported to with EDK/ISE v7.2 rather than the newer 8.1 or 8.2 with updated IP libraries. This is from the xparameters_ml40x.h file they distribute. /*** * * CAUTION: This file is automatically generated by libgen. * Version: Xilinx EDK 7.1.2 EDK_H.12.5.1 * DO NOT EDIT. * * Copyright (c) 2005 Xilinx, Inc. All rights reserved. * * Description: Driver parameters * ***/ Sigh. -michael I noticed that MontaVista now has their Pro 4.0 version (2.6 Kernel) available for the Xilinx ML40x series of boards. I would assume that means driver support for at least most of the hardware on the boards. Is this code that should be freely available? How would one get a copy of these drivers? I am interested in drivers for the ML403. Thanks, Frank ___ Linuxppc-embedded mailing list Linuxppc-embedded at ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Xilinx hard TEMAC
David, snip 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 ? 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. 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. 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 ? 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. 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 ? It's a Xilinx creation as far as I know. Hope that helps, -Rick
Linux on Virtex4
Ales, H... No, I've not done anything with the Avnet MM board. I may have responded to somebody who was working with that board on this list. We work a lot with PLB TEMAC and MV Linux, but do very little with GSRD (it's a reference design that's not officially supported through the EDK). On the surface, I don't think I can help much here, but feel free to directly send me a more detailed email and maybe I can point you to someone who can help. -Rick -Original Message- From: linuxppc-embedded-bounces+moleres=xilinx.com at ozlabs.org [mailto:[EMAIL PROTECTED] On Behalf Of Ale? Gorkic Sent: Wednesday, July 12, 2006 7:13 AM To: linuxppc-embedded at ozlabs.org Subject: re:Linux on Virtex4 Hi Rick, I saw on linuxppc-embedded at ozlabs.org that you are trying to port (or better you did) monta vista linux to Avnet's V4FX Mini-Module. I will try to deal with the same thing. My design is basically the same: all features of MM incorporated in CoreConnect style architecture. I also tried with Multi Port Memory Controller (MPMC2) and ported (memory works, but for LAN I still need phy datasheet) the Gigabit System Reference Design (GSRD2) to Mini-Module. By using the MPMC2 memory core you can connect PPC directly to memory using two PLBs (data and instruction separated). This way you might solve the CPU cache errata. The problem with MPMC2 is that it consumes A LOT of BRAM and logic. I tried to build a full featured system, but V4FX12 lacks logic for the purpose. Is there a way that you can help me with running MV linux on my system? Cheers, Ales Gorkic ___ Linuxppc-embedded mailing list Linuxppc-embedded at ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
2.6 kernel on XUPV2pro / ML300 board!
Ameet, Xilinx is working with MontaVista to create an ML40x LSP (for the Xilinx ML403/ML405 boards) and port the ML300 LSP to the MV Linux 2.6 distribution, and once it's ready MontaVista plans to push the ported drivers to the Linux 2.6 tree. I don't have an exact timeframe, but I hope this is very soon. -Rick -Original Message- From: [EMAIL PROTECTED] [mailto:linuxppc-embedded-bounces+moleres=xilinx.com at ozlabs.org] On Behalf Of Ameet Patil Sent: Wednesday, June 28, 2006 11:50 AM To: linuxppc-embedded at ozlabs.org Subject: 2.6 kernel on XUPV2pro / ML300 board! Hi, I have a XUPV2Pro Xilinx Embedded PPC405 board which is similar in many respects to the ML3XX series. With good support in the kernel source tree, I was easily able to compile the 2.4.26 linux kernel to run on it. However, I wanted 2.6 kernel to run on it. For some reason, the Xilinx drivers and the OCP code went missing in the 2.6 kernel tree. Does anyone know why did 2.6 kernel drop the Xilinx ML300 board drivers (SysACE, Ethernet, Frame Buffer) which were present in the 2.4 kernel code tree? It is because of porting issues? Anyway, I have ported the old 2.4 Xilinx drivers (Sysace and Ethernet) to 2.6.17.1 kernel. If anyone is interested to test them, please let me know. I shall put out a patch soon... Thanks, -Ameet ___ Linuxppc-embedded mailing list Linuxppc-embedded at ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Linux on Virtex4
Aiden, The cache issue I was referring to is the errata 213 that you tried. I'll ask around regarding the silicon issue - I don't know if there is a workaround for this on that board. -Rick -Original Message- From: Aidan Williams [mailto:[EMAIL PROTECTED] Sent: Wednesday, June 21, 2006 2:47 AM To: Rick Moleres Cc: Martin, Tim; linuxppc-embedded at ozlabs.org Subject: Re: Linux on Virtex4 Rick Moleres wrote: There's also a Linux 2.4 patch provided with the ML403 PPC reference design on the Xilinx website (http://www.xilinx.com/products/boards/ml403/reference_designs.htm) that takes care of a Virtex-4 PPC cache issue (CCR0 register). Have you applied this? Rick, which cache issue are you referring to? I tried setting the CCR0 bits in accordance with: Solution 10: CPU_213: Incorrect data might be flushed from the data cache but that didn't fix things in my case for the Avnet FX12 MiniModule. I'm pretty sure that the FX12-MM strikes: Solution 13: The return of a cacheline transaction that is not target word first (non-target word first) can cause data corruption in the PPC405 Core data cache in Virtex-4 FX devices. For which the only solutions mentioned are to run without caches or get a fixed chip. As I understand it, the memory controller for this board must be on the OPB because the memory is 16-bit. Is there any way to move the memory controller to the PLB thus avoiding the cache problem (for RAM at least)? - aidan
Linux on Virtex4
Aiden, Looked into this and here's what I found out. Only OPB_DDR supports 16-bit DDR memory right now and there are no concrete plans to add 16-bit support to PLB_DDR (it's been discussed, but nothing planned yet). So the only workarounds for this silicon issue are the two you mentioned - run with caches off or get a fixed version of the chip (I don't know what Avnet's plans are for your board). -Rick -Original Message- From: [EMAIL PROTECTED] [mailto:linuxppc-embedded-bounces+moleres=xilinx.com at ozlabs.org] On Behalf Of Rick Moleres Sent: Wednesday, June 21, 2006 12:10 PM To: Aidan Williams Cc: linuxppc-embedded at ozlabs.org; Martin, Tim Subject: RE: Linux on Virtex4 Aiden, The cache issue I was referring to is the errata 213 that you tried. I'll ask around regarding the silicon issue - I don't know if there is a workaround for this on that board. -Rick -Original Message- From: Aidan Williams [mailto:[EMAIL PROTECTED] Sent: Wednesday, June 21, 2006 2:47 AM To: Rick Moleres Cc: Martin, Tim; linuxppc-embedded at ozlabs.org Subject: Re: Linux on Virtex4 Rick Moleres wrote: There's also a Linux 2.4 patch provided with the ML403 PPC reference design on the Xilinx website (http://www.xilinx.com/products/boards/ml403/reference_designs.htm) that takes care of a Virtex-4 PPC cache issue (CCR0 register). Have you applied this? Rick, which cache issue are you referring to? I tried setting the CCR0 bits in accordance with: Solution 10: CPU_213: Incorrect data might be flushed from the data cache but that didn't fix things in my case for the Avnet FX12 MiniModule. I'm pretty sure that the FX12-MM strikes: Solution 13: The return of a cacheline transaction that is not target word first (non-target word first) can cause data corruption in the PPC405 Core data cache in Virtex-4 FX devices. For which the only solutions mentioned are to run without caches or get a fixed chip. As I understand it, the memory controller for this board must be on the OPB because the memory is 16-bit. Is there any way to move the memory controller to the PLB thus avoiding the cache problem (for RAM at least)? - aidan ___ Linuxppc-embedded mailing list Linuxppc-embedded at ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
Linux on Virtex4
Tim, There's also a Linux 2.4 patch provided with the ML403 PPC reference design on the Xilinx website (http://www.xilinx.com/products/boards/ml403/reference_designs.htm) that takes care of a Virtex-4 PPC cache issue (CCR0 register). Have you applied this? -Rick -Original Message- From: [EMAIL PROTECTED] [mailto:linuxppc-embedded-bounces+moleres=xilinx.com at ozlabs.org] On Behalf Of Martin, Tim Sent: Monday, June 19, 2006 5:24 PM To: linuxppc-embedded at ozlabs.org Subject: Linux on Virtex4 I have been working with a small module made by Memec/Avnet (FX12MM1-BASE) that has a Virtex-4 FX12 with some DDR SDRAM, a Gigabit Ethernet PHY, some FLASH, etc. I am using EDK 8.1 and generated the BSP for MontaVista 3.1 preview kit (which is based on the 2.4.20 kernel). This works, but occasionally panics while booting (doesn't panic all the time, maybe 1/3 the time). Examples of good boot and 2 crash boots below. We are using a root filesystem over NFS, and the panics seem to always be after the file system is mounted. I'm not sure if it is NFS related or not. I have also been working with the paulus 2.6 kernel tree (and I have tried the MVL linux-xilinx-26 tree), but have not been able to get the kernel to boot. The primary problem there is that we are using the uartlite instead of the full uart, and the patches I have found for uartlite support don't work. I can get the early serial messages to work, but I don't know enough about the console and serial core to get everything else working. I am also getting panics that seem to be non-serial related, but I haven't tracked it down yet. So two questions: 1) Is there anything obvious from the kernel panics below that I should be looking for? Just the answer linux 2.4.20 is really fricken old, upgrade is probably the right answer. 2) Does anyone have working UartLite support on a Virtex-4 FX12 design? Examples of 2.4.20 good: id mach(): done MMU:enter MMU:hw init MMU:mapin MMU:mapin_ram done MMU:setio MMU:exit Linux version 2.4.20_mvl31-v4fx12 (ahamel at uhflinux) (gcc version 3.3.1 (MontaVista 3.3.1-3.0.10.6 setup_arch: enter setup_arch: bootmem Xilinx Virtex-II Pro port (C) 2002 MontaVista Software, Inc. (source at mvista.com) arch: exit On node 0 totalpages: 16384 zone(0): 16384 pages. zone(1): 0 pages. zone(2): 0 pages. Kernel command line: root=/dev/nfs nfsroot=192.168.1.1:/opt/montavista/previewkit/ppc/405/target4 Xilinx INTC #0 at 0x4120 mapped to 0xFDFFF000 Calibrating delay loop... 197.01 BogoMIPS Memory: 63268k available (1092k kernel code, 340k data, 60k init, 0k highmem) Dentry cache hash table entries: 8192 (order: 4, 65536 bytes) Inode cache hash table entries: 4096 (order: 3, 32768 bytes) Mount-cache hash table entries: 1024 (order: 1, 8192 bytes) Buffer-cache hash table entries: 4096 (order: 2, 16384 bytes) Page-cache hash table entries: 16384 (order: 4, 65536 bytes) POSIX conformance testing by UNIFIX Linux NET4.0 for Linux 2.4 Based upon Swansea University Computer Society NET3.039 Initializing RT netlink socket LSP Revision 42 ikconfig 0.5 with /proc/ikconfig Starting kswapd Disabling the Out Of Memory Killer devfs: v1.12c (20020818) Richard Gooch (rgooch at atnf.csiro.au) devfs: boot_options: 0x1 pty: 256 Unix98 ptys configured xgpio #0 at 0x4002 mapped to 0xC500 xgpio #1 at 0x4004 mapped to 0xC5011000 xgpio #2 at 0x4006 mapped to 0xC5022000 xilinx_spi: got major number 254 xilinx_spi0 at 0x4080 mapped to 0xC5033000, irq=29 RAMDISK driver initialized: 16 RAM disks of 8192K size 1024 blocksize loop: loaded (max 8 devices) XTemac: Device instance #0 found eth0: XTemac: using fifo direct interrupt driven mode. eth0: XTemac: PHY detected at address 4. eth0: Xilinx TEMAC #0 at 0x8040 mapped to 0xC5044000, irq=28 eth0: XTemac: id 1.0f, block id 5, type 8 NET4: Linux TCP/IP 1.0 for NET4.0 IP Protocols: ICMP, UDP, TCP, IGMP IP: routing cache hash table of 512 buckets, 4Kbytes TCP: Hash tables configured (established 4096 bind 8192) eth0: XTemac: Options: 0xb8f0 eth0: XTemac: We renegotiated the speed to: 1000 eth0: XTemac: speed set to 1000Mb/s Sending DHCP requests ., OK IP-Config: Got DHCP answer from 192.168.1.1, my address is 192.168.1.75 IP-Config: Complete: device=eth0, addr=192.168.1.75, mask=255.255.255.0, gw=192.168.1.1, host=192.168.1.75, domain=, nis-domain=(none), bootserver=192.168.1.1, rootserver=192.168.1.1, rootpath= NET4: Unix domain sockets 1.0/SMP for Linux NET4.0. Looking up port of RPC 13/2 on 192.168.1.1 Looking up port of RPC 15/1 on 192.168.1.1 VFS: Mounted root (nfs filesystem). Mounted devfs on /dev Freeing unused kernel memory: 60k init serial console detected. Disabling virtual terminals. init started: BusyBox v0.60.2 (2004.04.30-17:49+) multi-call binary Welcome to MontaVista Linux Preview Kit Starting system... mounting /proc: done. Mounting '/' read-only: done. brining up loopback interface: done. Mounting /tmp: done. Starting
Making Two ethernet interfaces up in Linux
Shantanu, Can you post the xemac_g.c file in the xilinx_enet directory? Also, which version of the EDK are you using? There was a bug in EDK 7.x that prevented multiple Ethernet interfaces from working properly. It would also be helpful to see xparameters_ml300.h from the arch/ppc/platforms/xilinx_ocp directory. Thanks, -Rick -Original Message- From: [EMAIL PROTECTED] [mailto:linuxppc-embedded-bounces+moleres=xilinx.com at ozlabs.org] On Behalf Of Shantanu Nalage Sent: Wednesday, June 07, 2006 11:16 PM To: Antonio Di Bacco; linuxppc-embedded at ozlabs.org Subject: Re: Making Two ethernet interfaces up in Linux Thanks for the reply. The driver which we are using for the ethernet is provided by Xilinx. In the Linux kernel source, it is located in net/xilinx_enet directory. We are attaching the adapter file for the driver provided by Xilinx for the ethernet. When we gave a first try, it showed two ethernet interfaces eth0 and eth1 as an output of ifconfig command but only eth0 works, when eth1 is disabled. When both interfaces are up, neither interface works. While even when eth0 is disabled, eth1 interface doesn't work. With regards, Shantanu. On 6/4/06, Antonio Di Bacco antonio.dibacco at aruba.it wrote: We are trying to port Linux on Xilinx Board XUPV2Pro which is similar in most aspects to the Xilinx ML300 board. Linux is up and running for the original board i.e. having only one ethrnet interface. Now since we wanted to have the board working as router, we designed a daughter board with two ethernet phy interfaces. The MACs required for that are instantiated in Xilinx You have already the driver for the first MAC, then you should start from that modifying the init procedure for example and all the others. Your driver should initialize both the MACs and also create two devices calling init_etherdev tow times. If you post your driver I can suggest what to change. It is not so difficult. Bye, Antonio.
question about linux with Xilinx ML-403
Ming, Our best recommendation is to use the drivers/net/xilinx_enet directory for the temac driver and just enable the Xilinx 10/100 Ethernet in menuconfig. I am not so clear with this. Do you mean that I just copy the source code in the directory of xilinx_gige generated by EDK into the directory of xilinx_enet in linux2.4.20, and then enable the Xilinx 10/100 ethernet in the menuconfig? Can this method realize the 1000M ethernet? The source code file names for Temac (xtemac_xxx.c or .h) are different with the ones for emac (xemac_xxx.c or .h). Can the xtemac files be recognized by the linux kernel? Right - you would need to copy the xtemac* files and the Makefile over, and would have to change the Makefile to make sure it produces xilinx_enet.o instead of xilinx_gige.o. We haven't tried this, but we don't think there's any reason this shouldn't work. Can you let us know how it goes? -- next part -- An HTML attachment was scrubbed... URL: http://ozlabs.org/pipermail/linuxppc-embedded/attachments/20060524/a32750ad/attachment.htm
question about linux with Xilinx ML-403
Ming, Another option for you may be to get MontaVista's latest linuxppc-2.4 kernel tree from source.mvista.com (using rsync), which I believe has the xilinx_gige directory and menuconfig entries. -Rick -Original Message- From: Ming Liu [mailto:[EMAIL PROTECTED] Sent: Wednesday, May 24, 2006 12:36 PM To: rick.moleres Cc: linuxppc-embedded at ozlabs.org Subject: RE: question about linux with Xilinx ML-403 Dear Rick, OK. I will try that. However I cannot promise to finish this very soon because I am a novice. :) I will let you know if there is any result. Thanks for your method. BR Ming From: Rick Moleres rick.moleres at xilinx.com To: Ming Liu eemingliu at hotmail.com, rick.moleres rick.moleres at xilinx.com CC: linuxppc-embedded at ozlabs.org Subject: RE: question about linux with Xilinx ML-403 Date: Wed, 24 May 2006 10:25:10 -0600 Ming, Our best recommendation is to use the drivers/net/xilinx_enet directory for the temac driver and just enable the Xilinx 10/100 Ethernet in menuconfig. I am not so clear with this. Do you mean that I just copy the source code in the directory of xilinx_gige generated by EDK into the directory of xilinx_enet in linux2.4.20, and then enable the Xilinx 10/100 ethernet in the menuconfig? Can this method realize the 1000M ethernet? The source code file names for Temac (xtemac_xxx.c or .h) are different with the ones for emac (xemac_xxx.c or .h). Can the xtemac files be recognized by the linux kernel? Right - you would need to copy the xtemac* files and the Makefile over, and would have to change the Makefile to make sure it produces xilinx_enet.o instead of xilinx_gige.o. We haven't tried this, but we don't think there's any reason this shouldn't work. Can you let us know how it goes? _ MSN Explorer: http://explorer.msn.com/lccn/
question about linux with Xilinx ML-403
Ming, -Original Message- From: Ming Liu [mailto:[EMAIL PROTECTED] Sent: Tuesday, May 23, 2006 3:42 AM To: rick.moleres Cc: linuxppc-embedded at ozlabs.org Subject: question about linux with Xilinx ML-403 Hi Rick, Yes, we have a driver for the PLB TEMAC (different than the GSRD LL TEMAC) for Linux 2.4 (MontaVista Linux 2.4.20) that's shipped in EDK 8.1.1, and MontaVista is on the verge of publishing a driver for PLB TEMAC for Linux 2.6. (I believe it came across this mailing list a few weeks ago) I have generated the BSP by EDK 8.1.1 for my project in ML403(hardcore Temac and PLB Temac included). I noticed that there is a directory called Xilinx_gige in the directory of /drivers/net. Is this the driver for MontaVista Linux2.4.20? Yes, this is the PLB TEMAC driver for Linux 2.4.20. In EDK 8.1.x, the temac driver and Makefile are copied to drivers/net/xilinx_gige. This xilinx_gige directory is not available in the MVL 3.1 Preview Kit, only in the full Professional kit. We put the temac driver here mostly to take advantage of the JUMBO_FRAME_SUPPORT in kernel configuration. I copied the BSP and overwrote the original one in the linux kernel directory (in the kernel directory, there is only a directory called Xilinx_enet, no Xilinx_gige. So I just copied Xilinx_gige.). However, my problem is in the menuconfig item of Network Device Support-1000Mbit ethernet, there is not any option to choose and enable the Xilinx on-chip ethernet. Is this a problem of MontaVista Linux 3.1 Preview Kit, or my problem? And What shall I do to enable the tri-mode Temac in my platform? Thanks for your answer. Our best recommendation is to use the drivers/net/xilinx_enet directory for the temac driver and just enable the Xilinx 10/100 Ethernet in menuconfig. If you want jumbo frame support, modify adapter.c in the driver to define the CONFIG_XILINX_GIGE_JUMBO constant. Note that Linux 2.6 support for the temac should be available from MontaVista soon and a driver was pushed to this mailing list in March. There will be support for MV Linux 2.6 in EDK 8.2.1 (around August). Thanks, Rick -- next part -- An HTML attachment was scrubbed... URL: http://ozlabs.org/pipermail/linuxppc-embedded/attachments/20060523/09c6d315/attachment.htm
question about Linux 2.6 with Xilinx ML-403
Yes, we have a driver for the PLB TEMAC (different than the GSRD LL TEMAC) for Linux 2.4 (MontaVista Linux 2.4.20) that's shipped in EDK 8.1.1, and MontaVista is on the verge of publishing a driver for PLB TEMAC for Linux 2.6. (I believe it came across this mailing list a few weeks ago) -Rick -Original Message- From: [EMAIL PROTECTED] [mailto:linuxppc-embedded-bounces+moleres=xilinx.com at ozlabs.org] On Behalf Of Grant Likely Sent: Wednesday, April 12, 2006 3:25 PM To: Martin, Tim Cc: linuxppc-embedded at ozlabs.org Subject: Re: question about Linux 2.6 with Xilinx ML-403 On 4/12/06, Martin, Tim tim.martin at viasat.com wrote: Which 2.4 driver - there's the Montavista one for the softcore PLB EMAC, and there's also one for the hardcore PLB TEMAC that gets distributed with the GSRD. The montavista softcore driver. Has someone written a driver for the TEMAC yet? g. -- Grant Likely, B.Sc. P.Eng. Secret Lab Technologies Ltd. (403) 399-0195 ___ Linuxppc-embedded mailing list Linuxppc-embedded at ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-embedded
