- ixp1200 - lists.cs.princeton.edu

Re: Hard Reset of IXP1200 over PCI?
by Scott C. Karlin 20 Feb '01

20 Feb '01

I performed the experiment and answered my own question. It seems that writing 0xFFFFFFFF to the IXP1200_RESET register from the PCI bus does indeed reset the IXP1200. As expected, the reset knocks the IXP1200 off of the PCI bus. However, once I restored the PCI configuration registers to their original state, the board worked fine. Can anyone from Intel confirm (to the list) that the only reason a PCI device should not write to the IXP1200_RESET register is that the board will be deconfigured from the PCI bus? Scott > From: "Scott C. Karlin" <scott(a)CS.Princeton.EDU> > Subject: Hard Reset of IXP1200 over PCI? > To: ixp1200(a)CS.Princeton.EDU > Date: Wed, 14 Feb 2001 14:50:07 -0500 (EST) > > I'd like to be able to perform a hard reset of the > IXP1200 over the PCI bus. Most of the documentation > seems to indicate that I cannot do this. However, > the IXP1200 Programmer's Reference Manual seems to > indicate that it might be possible (but not allowed). > > Section 4.7.13 IXP1200_RESET indicates that the > IXP1200_RESET register can be read and written > from offset 0x7C. However, the paragraph directly > above says that "PCI devices must not write to this > register." > > What happens if I do? (I assume that the IXP1200 > will reset and clear the PCI registers including the > BAR set by the host machine. If I promise to put the > board back in the same place in the PCI memory map, > will everything be OK?) > > Scott

1 0

Hard Reset of IXP1200 over PCI?
by Scott C. Karlin 14 Feb '01

14 Feb '01

I'd like to be able to perform a hard reset of the IXP1200 over the PCI bus. Most of the documentation seems to indicate that I cannot do this. However, the IXP1200 Programmer's Reference Manual seems to indicate that it might be possible (but not allowed). Section 4.7.13 IXP1200_RESET indicates that the IXP1200_RESET register can be read and written from offset 0x7C. However, the paragraph directly above says that "PCI devices must not write to this register." What happens if I do? (I assume that the IXP1200 will reset and clear the PCI registers including the BAR set by the host machine. If I promise to put the board back in the same place in the PCI memory map, will everything be OK?) Scott

1 0

IXP1200 + wireless LAN
by Sundar Ramachandran 14 Feb '01

14 Feb '01

Hello, Does anybody know of any kind of development in Linux IXP1200 and wireless LANs? I'm trying to figure out how heterogeneous traffic between both wired and wireless subnets will affect the performance of the IXP1200,i.e. how well the processor will perform. By the way, I need a traffic generator to use in order to study the performance characteristics of the evaluation board. If you have any in mind, please let me know. Thanks. - Sundar. ================================================================================ "The optimist proclaims we live in the best of all possible worlds; and the pessimist fears this is true. " - James Cabell Sundar Ramachandran PHONE:(817)8015233 Dept. of Computer Science & Engg., E-MAIL: ramachan(a)acm.org UT Arlington, Arlington, TX 76019. ================================================================================

1 0

Flash Image and EXCEPT_ADDR
by Scott C. Karlin 12 Feb '01

12 Feb '01

I'm trying to understand how to build a flash image by looking at the files in BoardSupport/BootMgr and comparing with the actual flash contents (externally extracted using a device programmer). In the file romInit.s there are the following lines: L$_undef_vector: .long (EXCEPT_ADDR + 0x04) L$_swi_vector: .long (EXCEPT_ADDR + 0x08) L$_pabort_vector: .long (EXCEPT_ADDR + 0x0c) L$_dabort_vector: .long (EXCEPT_ADDR + 0x10) L$_irq_vector: .long (EXCEPT_ADDR + 0x18) L$_fiq_vector: .long (EXCEPT_ADDR + 0x1c) The file os.h defines EXCEPT_ADDR as 0x101FFFC0. I would expect this to generate the following sequence of long words: 101FFFC4 101FFFC8 101FFFCC 101FFFD0 101FFFD4 101FFFD8 101FFFDC Instead, the actual flash image is: 0000C004 0000C008 0000C00C 0000C010 0000C014 0000C018 0000C01C This suggests that EXCEPT_ADDR is 0x0000C000. Has EXCEPT_ADDR changed between the time we received our boards (BootMgr Version 1.0.1129) and when the CD-ROM was produced (BootMgr Version 1.0.1133) ? Scott

1 0

BldRom Functional Description?
by Scott C. Karlin 12 Feb '01

12 Feb '01

Does anyone have a functional description of the BldRom program? It's in the BoardSupport/Boot1200 subdirectory of the CD-ROM. I couldn't find a description of it in the documentation. Thanks, Scott

1 0

NT sample ARM script compilation
by Sundar Ramachandran 05 Feb '01

05 Feb '01

Hello people, I'm having a little bit of a problem with a few trivial things: 1. To run the sample ARM core scripts, I need to compile the assembly source code namely boot.s and boot.h to produce the binary and .list file. The makefile that comes with this (directory IXP1200\SA1_CoreLibs\Samples\saboot) does not seem to produce these files. Do I need to give it an option or add any shell commands in the makefile? It doesn't seem so, but when I do a make boot.bin it says there's nothing to be made. Please tell me what I'm missing. 2. Also, while loading VxWorks through the serial port from the NT host using hyperterm, either the VxWorks image does not load or if I get past it sometimes the Tornado target server does not confirm configuration, it says that the target is not attached. Well, the environment path has been set correctly, I'm running IIS FTP service, and the boot parameters are to my knowledge correct. Tornado is running as a service (if that information will help). 3. I've gone through the linux howto for IXP1200. Has someone tried this on debian. Is there anything to be considered for Debian installation? I'd really appreciate some help from you all. Thank you. - Sundar Ramachandran. ================================================================================ "If it takes a lot of words to say what you have in mind, give it more thought." - Dennis Roch Sundar Ramachandran PHONE:(817) 801-5233 Dept. of Computer Science & Engg., E-MAIL: ramachan(a)acm.org UT Arlington, Arlington, TX 76019. ================================================================================

1 0

mini-Linux HOWTO for IXP1200 revB boards
by Josh Fryman 11 Jan '01

11 Jan '01

hi all, scott asked about this URL regarding the official linux port to the IXP 1200 platforms. this howto is for revB silicon boards, and tells you how to check whether yours is B or not. hope people not aware of it find it useful ... http://www.netwinder.org/~urnaik/ixp1200_howto.html cheers, josh fryman

1 0

RE: IXP Bus Endian Mode
by Hooper, Donald 08 Dec '00

08 Dec '00

All the CD Beta releases were tested with IX Bus in big and little endian mode. There are customers using IX Bus in production systems little endian mode. You have to program the MAC device to be little endian to get bytes swapped. Setting the RDYBUS_TEMPLATE_CTL 5 only causes byte enables pins to be interpreted correctly for little endian. Don -----Original Message----- From: Naik, Uday Sent: Thursday, December 07, 2000 10:36 PM To: Joe, Robert; IXP1200 Users; 'ixp1200(a)CS.Princeton.EDU' Subject: RE: IXP Bus Endian Mode I believe setting the IXBUS in Little Endian mode does not work. But you can set the Endian registers in the PCI bus controller for the IXP1200, to swap the data corectly as it goes over the bus. Uday -----Original Message----- From: Joe, Robert [mailto:robert.joe@intel.com] Sent: Thursday, December 07, 2000 7:32 PM To: IXP1200 Users; 'ixp1200(a)CS.Princeton.EDU' Subject: IXP Bus Endian Mode I am setting bit 5 in RDYBUS_TEMPLATE_CTL, but the IXP bus still appears to be running in Big Endian mode. Here are the details: B0 board in eval chassis Proprietary OS with the ARM running in Little Endian mode. 1.0 pwd_2f with only changes to the SDRAM packet base address In hw_init.uc just after the ready bus has been programmed immed[$xfer2, 0xF20] csr[write, $xfer2, RDYBUS_TEMPLATE_CTL], CTX_SWAP I have ARM code running which dequeues packets off SRAM/SDRAM as they were placed by the microengine receive threads. Ultimately I want to DMA the packet data across the PCI bus. However, because the IX bus is running in Big Endian mode, the packets appear in SDRAM byte swapped on longword boundaries (see HRM, pg 6-55). I know if I do a longword copy of the packet, the copied packet will appear in the correct order. But I want to avoid this overhead. In fact, this is probably the reason the PETH driver works? My thinking is, if I can get the IX bus running in Little Endian mode, the packet data will be in the correct order for my DMA over the PCI bus. Agree? Has anyone run pwd_2f with LITTLE_ENDIAN defined and Little Endian (bit 5) set in the RDYBUS_TEMPLATE_CTL? If you have: Where did you set the RDYBUS_TEMPLATE_CTL? What OS are you running and do you have the ARM running in Little or Big Endian (although this should not matter??) Are you seeing the packet data in Little Endian format? Robert Joe (858) 391 1849

1 0

RE: IXP Bus Endian Mode
by Naik, Uday 07 Dec '00

07 Dec '00

I believe setting the IXBUS in Little Endian mode does not work. But you can set the Endian registers in the PCI bus controller for the IXP1200, to swap the data corectly as it goes over the bus. Uday -----Original Message----- From: Joe, Robert [mailto:robert.joe@intel.com] Sent: Thursday, December 07, 2000 7:32 PM To: IXP1200 Users; 'ixp1200(a)CS.Princeton.EDU' Subject: IXP Bus Endian Mode I am setting bit 5 in RDYBUS_TEMPLATE_CTL, but the IXP bus still appears to be running in Big Endian mode. Here are the details: B0 board in eval chassis Proprietary OS with the ARM running in Little Endian mode. 1.0 pwd_2f with only changes to the SDRAM packet base address In hw_init.uc just after the ready bus has been programmed immed[$xfer2, 0xF20] csr[write, $xfer2, RDYBUS_TEMPLATE_CTL], CTX_SWAP I have ARM code running which dequeues packets off SRAM/SDRAM as they were placed by the microengine receive threads. Ultimately I want to DMA the packet data across the PCI bus. However, because the IX bus is running in Big Endian mode, the packets appear in SDRAM byte swapped on longword boundaries (see HRM, pg 6-55). I know if I do a longword copy of the packet, the copied packet will appear in the correct order. But I want to avoid this overhead. In fact, this is probably the reason the PETH driver works? My thinking is, if I can get the IX bus running in Little Endian mode, the packet data will be in the correct order for my DMA over the PCI bus. Agree? Has anyone run pwd_2f with LITTLE_ENDIAN defined and Little Endian (bit 5) set in the RDYBUS_TEMPLATE_CTL? If you have: Where did you set the RDYBUS_TEMPLATE_CTL? What OS are you running and do you have the ARM running in Little or Big Endian (although this should not matter??) Are you seeing the packet data in Little Endian format? Robert Joe (858) 391 1849

1 0

IXP Bus Endian Mode
by Joe, Robert 07 Dec '00

07 Dec '00

I am setting bit 5 in RDYBUS_TEMPLATE_CTL, but the IXP bus still appears to be running in Big Endian mode. Here are the details: B0 board in eval chassis Proprietary OS with the ARM running in Little Endian mode. 1.0 pwd_2f with only changes to the SDRAM packet base address In hw_init.uc just after the ready bus has been programmed immed[$xfer2, 0xF20] csr[write, $xfer2, RDYBUS_TEMPLATE_CTL], CTX_SWAP I have ARM code running which dequeues packets off SRAM/SDRAM as they were placed by the microengine receive threads. Ultimately I want to DMA the packet data across the PCI bus. However, because the IX bus is running in Big Endian mode, the packets appear in SDRAM byte swapped on longword boundaries (see HRM, pg 6-55). I know if I do a longword copy of the packet, the copied packet will appear in the correct order. But I want to avoid this overhead. In fact, this is probably the reason the PETH driver works? My thinking is, if I can get the IX bus running in Little Endian mode, the packet data will be in the correct order for my DMA over the PCI bus. Agree? Has anyone run pwd_2f with LITTLE_ENDIAN defined and Little Endian (bit 5) set in the RDYBUS_TEMPLATE_CTL? If you have: Where did you set the RDYBUS_TEMPLATE_CTL? What OS are you running and do you have the ARM running in Little or Big Endian (although this should not matter??) Are you seeing the packet data in Little Endian format? Robert Joe (858) 391 1849

1 0

RE: debugging in hardware
by Heaton, Eric D 30 Nov '00

30 Nov '00

1. I think if you are doing some kind of interthread communication where one thread is waiting for a signal from another, you could get into a situation where the signal is missed and a microengine will hang forever if you start getting your code out of sync. Chances are it wouldn't happen with just one (or perhaps many) stop/starts, but the possiblity goes up as you increase breakpoint frequency. 2. This is more a problem of exceeding the capabilities of the reference designs. One example might be if there is packet loss for a gigabit port, the gigabit code will loop forever waiting for the missing packet number. Now you're in reset-city. ;) -- Eric Heaton -- -----Original Message----- From: Alok Kumar [mailto:alok@cs.utexas.edu] Sent: Thursday, November 30, 2000 1:07 PM To: Heaton, Eric D Cc: ixp1200(a)CS.Princeton.EDU; Brandewie, Dirk J Subject: RE: debugging in hardware Hi Eric, Thanks a lot for the answers to my queries. 1. The 1st reason you gave should not affect the behavior of the microcode running. Anyway, microengines are running independentely of each other and even if they stop at slightly different times and start at slightly different time, it will not make changes in final outcome. This will not at least make some thread to goto unwanted state and theoritically final behaviour should be unchanged. 2. For the second reason, I was wondering whether this is a problem of reference design or of the debugging environment? Thanks Alok On Thu, 30 Nov 2000, Heaton, Eric D wrote: > I know we've seen problems when inserting breakpoints in hardware. > sometimes the Microengines get into an undefined state for reasons mostly > related to either: > > 1. Getting the Microengines out of sync with each other (i.e. when you set a > breakpoint in one Microengine, the other Microengines don't stop > immediately, but only stop after their respective, currently running, > threads swap out) or.. > > 2. Setting breakpoints while the IXP1200 is trying to receive or transmit > packets. This point is due to the fact that the reference designs aren't as > robust as one might like... they are, however, a very good starting point to > get a feel for the IXP1200 and to start developing your own applications. > > -- Eric Heaton -- > > -----Original Message----- > From: Alok Kumar [mailto:alok@cs.utexas.edu] > Sent: Wednesday, November 29, 2000 3:30 PM > To: ixp1200(a)CS.Princeton.EDU > Subject: debugging in hardware > > > Hi, > > I have run the reference design pfwd8_1f_16rx_6tx on hardware. I am > eventually successful in getting packets through it but here are some > problems I am getting. If anyone has any thoughts or comments on it, > please, let me know. > > 1. When I use the Intel's latest release (version 1.1), the packets > greater than 64 bytes are not forwarded correctly. In version 1.0, there > is no such problem. I downloaded pfwd8_1f_16rx_6tx in both the cases. > > 2. When I try to debug code in hardware by inserting breakpoint to follow > the execution of code, it does not forward any packet but rather go to > some undesirable state. This problem happens in both the version. > > If I use reference design of version 1.0 and do not insert any breakpoints > in code, I get packets forwarded as expected. > > If anyone has successfully run reference designs from version 1.1 or > successfully followed code execution in hardware, please, let me know. > > Thanks > Alok > > ____________________________________________________________________________ > ___ > > Alok Kumar > > Residence: > 3401 Red River St #201 > Austin, TX 78705 > > Office: > Dept of Computer Science > ACES Building > University of Texas > Austin, TX 78712 > > Ph: Home - (512) 472-6443 > Office - (512) 232-7883 > Fax: (401) 679 8171 > > Homepage: http://www.cs.utexas.edu/~alok > ____________________________________________________________________________ > ___ > > > ____________________________________________________________________________ ___ Alok Kumar Residence: 3401 Red River St #201 Austin, TX 78705 Office: Dept of Computer Science ACES Building University of Texas Austin, TX 78712 Ph: Home - (512) 472-6443 Office - (512) 232-7883 Fax: (401) 679 8171 Homepage: http://www.cs.utexas.edu/~alok ____________________________________________________________________________ ___

1 0

RE: debugging in hardware
by Heaton, Eric D 30 Nov '00

30 Nov '00

I know we've seen problems when inserting breakpoints in hardware. sometimes the Microengines get into an undefined state for reasons mostly related to either: 1. Getting the Microengines out of sync with each other (i.e. when you set a breakpoint in one Microengine, the other Microengines don't stop immediately, but only stop after their respective, currently running, threads swap out) or.. 2. Setting breakpoints while the IXP1200 is trying to receive or transmit packets. This point is due to the fact that the reference designs aren't as robust as one might like... they are, however, a very good starting point to get a feel for the IXP1200 and to start developing your own applications. -- Eric Heaton -- -----Original Message----- From: Alok Kumar [mailto:alok@cs.utexas.edu] Sent: Wednesday, November 29, 2000 3:30 PM To: ixp1200(a)CS.Princeton.EDU Subject: debugging in hardware Hi, I have run the reference design pfwd8_1f_16rx_6tx on hardware. I am eventually successful in getting packets through it but here are some problems I am getting. If anyone has any thoughts or comments on it, please, let me know. 1. When I use the Intel's latest release (version 1.1), the packets greater than 64 bytes are not forwarded correctly. In version 1.0, there is no such problem. I downloaded pfwd8_1f_16rx_6tx in both the cases. 2. When I try to debug code in hardware by inserting breakpoint to follow the execution of code, it does not forward any packet but rather go to some undesirable state. This problem happens in both the version. If I use reference design of version 1.0 and do not insert any breakpoints in code, I get packets forwarded as expected. If anyone has successfully run reference designs from version 1.1 or successfully followed code execution in hardware, please, let me know. Thanks Alok ____________________________________________________________________________ ___ Alok Kumar Residence: 3401 Red River St #201 Austin, TX 78705 Office: Dept of Computer Science ACES Building University of Texas Austin, TX 78712 Ph: Home - (512) 472-6443 Office - (512) 232-7883 Fax: (401) 679 8171 Homepage: http://www.cs.utexas.edu/~alok ____________________________________________________________________________ ___

2 1

RE: debugging in hardware
by Sprajc, Barry 30 Nov '00

30 Nov '00

One nasty debugging pitfall I've run into while trying to debug in hardware ( using L3fwd16) is the following: If a thread issues a read_lock or write_lock command and a breakpoint happens before an unlock occurs, the sram signal gets lost and the thread sits forever waiting for the signal, so following instructions which issue an unlock command never occur, all other threads who issues a read/write command never complete and wait forever on a read/write lock, and the issuing thread never continues. The only way I've been able to get past this problem is to reset the card. /b > -----Original Message----- > From: Heaton, Eric D [SMTP:eric.d.heaton@intel.com] > Sent: Thursday, November 30, 2000 9:14 AM > To: 'Alok Kumar'; ixp1200(a)CS.Princeton.EDU; Brandewie, Dirk J > Subject: RE: debugging in hardware > > I know we've seen problems when inserting breakpoints in hardware. > sometimes the Microengines get into an undefined state for reasons mostly > related to either: > > 1. Getting the Microengines out of sync with each other (i.e. when you set > a > breakpoint in one Microengine, the other Microengines don't stop > immediately, but only stop after their respective, currently running, > threads swap out) or.. > > 2. Setting breakpoints while the IXP1200 is trying to receive or transmit > packets. This point is due to the fact that the reference designs aren't > as > robust as one might like... they are, however, a very good starting point > to > get a feel for the IXP1200 and to start developing your own applications. > > -- Eric Heaton -- > > -----Original Message----- > From: Alok Kumar [mailto:alok@cs.utexas.edu] > Sent: Wednesday, November 29, 2000 3:30 PM > To: ixp1200(a)CS.Princeton.EDU > Subject: debugging in hardware > > > Hi, > > I have run the reference design pfwd8_1f_16rx_6tx on hardware. I am > eventually successful in getting packets through it but here are some > problems I am getting. If anyone has any thoughts or comments on it, > please, let me know. > > 1. When I use the Intel's latest release (version 1.1), the packets > greater than 64 bytes are not forwarded correctly. In version 1.0, there > is no such problem. I downloaded pfwd8_1f_16rx_6tx in both the cases. > > 2. When I try to debug code in hardware by inserting breakpoint to follow > the execution of code, it does not forward any packet but rather go to > some undesirable state. This problem happens in both the version. > > If I use reference design of version 1.0 and do not insert any breakpoints > in code, I get packets forwarded as expected. > > If anyone has successfully run reference designs from version 1.1 or > successfully followed code execution in hardware, please, let me know. > > Thanks > Alok > > __________________________________________________________________________ > __ > ___ > > Alok Kumar > > Residence: > 3401 Red River St #201 > Austin, TX 78705 > > Office: > Dept of Computer Science > ACES Building > University of Texas > Austin, TX 78712 > > Ph: Home - (512) 472-6443 > Office - (512) 232-7883 > Fax: (401) 679 8171 > > Homepage: http://www.cs.utexas.edu/~alok > __________________________________________________________________________ > __ > ___ > >

1 0

RE: debugging in hardware
by Brandewie, Dirk J 29 Nov '00

29 Nov '00

Hi Alok, Others have seen this problem also. I have asked our support group to look at the problem and if there are any workarounds. I will post to the list any information I can gather on the problem. Sorry I can't give a more direct answer that would fix your problem. --Dirk > Hi, > > I have run the reference design pfwd8_1f_16rx_6tx on hardware. I am > eventually successful in getting packets through it but here are some > problems I am getting. If anyone has any thoughts or comments on it, > please, let me know. > > 1. When I use the Intel's latest release (version 1.1), the packets > greater than 64 bytes are not forwarded correctly. In version > 1.0, there > is no such problem. I downloaded pfwd8_1f_16rx_6tx in both the cases. > > 2. When I try to debug code in hardware by inserting > breakpoint to follow > the execution of code, it does not forward any packet but rather go to > some undesirable state. This problem happens in both the version. > > If I use reference design of version 1.0 and do not insert > any breakpoints > in code, I get packets forwarded as expected. > > If anyone has successfully run reference designs from version 1.1 or > successfully followed code execution in hardware, please, let me know. >

1 0

RE: strong arm development
by Heaton, Eric D 29 Nov '00

29 Nov '00

Information on the StrongARM Core API to interact with the other functional units of the IXP1200 (like the IX Bus, the Microengines, etc.) can be found in Section 2 of the IXP1200 Software Reference Manual. For StrongARM Core development, one could use a development environment, such as Tornado from WindRiver www.windriver.com or some other StrongARM-compatible compiler and debugger. One way to simulate the StrongARM interacting with the microengines is by creating a foreign model, which acts as an extension to the capabilities of Transactor, which is a cycle and data accurate software model of IXP1200. More information on how to create a foreign model can be found in Section 6 of the IXP1200 Development Tool User's Guide v005. To generate packet traffic in simulation on the Developer's Workbench v1.1, you can use the IX Bus Simulator found under the "Simulation" at the top menu bar. Here you can configure one or more devices attached to the IX Bus, i.e. MACs as well as the packet streams you want to flow through them. More information on how to create a foreign model can be found in Section 2.9.21 of the IXP1200 Development Tool User's Guide v005. -- Eric Heaton -- -----Original Message----- From: Sachin Jain [mailto:sachin@cs.utexas.edu] Sent: Wednesday, November 29, 2000 3:49 PM To: ixp1200(a)CS.Princeton.EDU Subject: strong arm development Hi, I have some questions regarding strong arm development and its simulation? I want to add code in the strong arm that spawns a process that periodically does some computations. In which file in strong arm code could this be added? How does one rebuild the strong arm image after making changes? Where can i find documentation for finding the API for spawning process and getting values from sram etc? How does one simulate a reference design with strong arm image in software i.e without downloading on the hardware? If we simulate in hardware - is there a way to generate packet flows using the development bench? I will appreciate help on any of the questions... Sachin Jain Graduate student, computer sciences Univ. of Texas - Austin Res: 3401, Red River Street, #201 Austin, Tx - 78705 Ph : (512)-4726443 (R)

1 0

debugging in hardware
by Alok Kumar 29 Nov '00

29 Nov '00

Hi, I have run the reference design pfwd8_1f_16rx_6tx on hardware. I am eventually successful in getting packets through it but here are some problems I am getting. If anyone has any thoughts or comments on it, please, let me know. 1. When I use the Intel's latest release (version 1.1), the packets greater than 64 bytes are not forwarded correctly. In version 1.0, there is no such problem. I downloaded pfwd8_1f_16rx_6tx in both the cases. 2. When I try to debug code in hardware by inserting breakpoint to follow the execution of code, it does not forward any packet but rather go to some undesirable state. This problem happens in both the version. If I use reference design of version 1.0 and do not insert any breakpoints in code, I get packets forwarded as expected. If anyone has successfully run reference designs from version 1.1 or successfully followed code execution in hardware, please, let me know. Thanks Alok _______________________________________________________________________________ Alok Kumar Residence: 3401 Red River St #201 Austin, TX 78705 Office: Dept of Computer Science ACES Building University of Texas Austin, TX 78712 Ph: Home - (512) 472-6443 Office - (512) 232-7883 Fax: (401) 679 8171 Homepage: http://www.cs.utexas.edu/~alok _______________________________________________________________________________

2 1

RE: building vxworks
by Sprajc, Barry 29 Nov '00

29 Nov '00

This can also be accomplished by running \tornado\host\x86-win32\bin\torVars.bat which will also add some important stuff to the PATH variable. BTW - If anyone has had success rebuilding the BSP to support debugging through the serial port rather than the 10/100 NIC( an actually getting it to work ), please let me know. Thanks, barry.sprajc(a)intel.com > -----Original Message----- > From: Brandewie, Dirk J [SMTP:dirk.j.brandewie@intel.com] > Sent: Wednesday, November 29, 2000 10:07 AM > To: 'Hilarie Orman'; ixp1200(a)CS.Princeton.EDU > Subject: RE: building vxworks > > Can you capture the real error message? To compile from > the command line there are two environment variables that > need to be set. > > WIND_BASE=c:\Tornado > WIND_HOST_TYPE=x86-win32 > > Also make sure that the Tornado tools are on your path. CD > into the BSP directory and type "make clean" then "make". > > Hope this helps > --Dirk > > -----Original Message----- > > From: Hilarie Orman [mailto:HORMAN@novell.com] > > Sent: Wednesday, November 29, 2000 9:57 AM > > To: ixp1200(a)CS.Princeton.EDU > > Subject: building vxworks > > > > > > I am trying to build a vxworks kernel with Tornado using the > > BSP from the > > IXPl 1.1 CD; this fails due to a script error re "toolfindbyname" > > (roughly). Anyone know how to fix it? > > > > Hilarie Orman > > > > > > >

1 0

RE: building vxworks
by Brandewie, Dirk J 29 Nov '00

29 Nov '00

Can you capture the real error message? To compile from the command line there are two environment variables that need to be set. WIND_BASE=c:\Tornado WIND_HOST_TYPE=x86-win32 Also make sure that the Tornado tools are on your path. CD into the BSP directory and type "make clean" then "make". Hope this helps --Dirk > -----Original Message----- > From: Hilarie Orman [mailto:HORMAN@novell.com] > Sent: Wednesday, November 29, 2000 9:57 AM > To: ixp1200(a)CS.Princeton.EDU > Subject: building vxworks > > > I am trying to build a vxworks kernel with Tornado using the > BSP from the > IXPl 1.1 CD; this fails due to a script error re "toolfindbyname" > (roughly). Anyone know how to fix it? > > Hilarie Orman > > >

1 0

building vxworks
by Hilarie Orman 29 Nov '00

29 Nov '00

I am trying to build a vxworks kernel with Tornado using the BSP from the IXPl 1.1 CD; this fails due to a script error re "toolfindbyname" (roughly). Anyone know how to fix it? Hilarie Orman

1 0

RE: Reference Design
by Sprajc, Barry 27 Nov '00

27 Nov '00

Hi folks, The initalization script contains rt_add(.....) to add routes, however this does not include the necessary parms for MAC address. Please look at the prototype for route_add(....) ( I can't remember of the top of my head what is ) and change the script to use route_add() instead of rt_add(). route_add() includes ( I think 2 ) extra parms for the low and high portions of the destination MAC address ( MAC address for a given client ip address ) /b > -----Original Message----- > From: Taroon Mandhana [SMTP:mandhana@cs.utexas.edu] > Sent: Sunday, November 26, 2000 3:09 PM > To: Petcharat Suriyachai > Cc: ixp1200(a)CS.Princeton.EDU > Subject: Re: Reference Design > > Hi Petcharat, > > We are trying to run pfwd8_1f_rx16_tx6 on the new board - B0. Our > understanding is that the default route table here is that 1.1.1.1 goes to > port 1, 2.2.2.2 to port 2 and so on. We have two end points with IP > addresses 1.1.1.1(machine A) and 2.2.2.2(m/c B) connected to port 1 and 2 > respectively on the board. > > Here is step by step what we are doing. > > 1. On the board, download VxWorks Image from > > ixp1200/boardsupport/bin/vb/vxworks > > 2. Start Tornado and get the command shell > > 3. Run Netapp (as specified in the manual) > > 4. Open developer workbench with pfwd8_1f_rx16_tx6 and start running the > ref design in hardware. > > 5. On m/c A, do telnet 2.2.2.2 > > The Rx led blinks for port 1 on receiving, however, nothing gets > transmitted on port 2. > > I was wondering if you did the similar thing. Any help is greatly > appreciated. > > thanks, > Taroon > > > On Mon, 20 Nov 2000, Petcharat Suriyachai wrote: > > > The pfwd8_1f_rx16_tx6 project should work on the hardware. > > > > > > On Sun, 19 Nov 2000, Alok Kumar wrote: > > > > > Hi All, > > > > > > Can anyone help me out to make some reference design work in actual > > > hardware? Which reference design in the latest CD is known to actually > > > work in B0 hardware without any problem? What is the semantics of > routing > > > table in that reference? > > > > > > I have downloaded vxworks in the hardware and also run tornado. Now, I > > > download mircocode through workbench and it runs ( I can see PC > > > changing). Now, I want to send some packets and get them routed. So, > > > please tell me which reference design should I download? > > > > > > Thanks > > > Alok > > > > > > > __________________________________________________________________________ > _____ > > > > > > Alok Kumar > > > > > > Residence: > > > 3401 Red River St #201 > > > Austin, TX 78705 > > > > > > Office: > > > Dept of Computer Science > > > ACES Building > > > University of Texas > > > Austin, TX 78712 > > > > > > Ph: Home - (512) 472-6443 > > > Office - (512) 232-7883 > > > Fax: (401) 679 8171 > > > > > > Homepage: http://www.cs.utexas.edu/~alok > > > > __________________________________________________________________________ > _____ > > > > > > > >

1 0

Reference Design
by Alok Kumar 27 Nov '00

27 Nov '00

Hi All, Can anyone help me out to make some reference design work in actual hardware? Which reference design in the latest CD is known to actually work in B0 hardware without any problem? What is the semantics of routing table in that reference? I have downloaded vxworks in the hardware and also run tornado. Now, I download mircocode through workbench and it runs ( I can see PC changing). Now, I want to send some packets and get them routed. So, please tell me which reference design should I download? Thanks Alok _______________________________________________________________________________ Alok Kumar Residence: 3401 Red River St #201 Austin, TX 78705 Office: Dept of Computer Science ACES Building University of Texas Austin, TX 78712 Ph: Home - (512) 472-6443 Office - (512) 232-7883 Fax: (401) 679 8171 Homepage: http://www.cs.utexas.edu/~alok _______________________________________________________________________________

4 5

RE: PETH drivers
by Johnson, Erik J 27 Nov '00

27 Nov '00

I just successfully recompiled and here are the steps I took: 0). Make sure your environment is setup, define WIND_BASE as the root dir of your Tornado installation (e.g, C:\Tornado) WIND_HOST_TYPE as x86-win32 These can also be set by running torVars.bat in Tornado\host\x86-win32\bin (no magic here, I assume you have already done this since it it needed to compile anything for VxWorks) 1) cd IXP1200\BoardSupport\VxWorks\IXP1200EB\ 2) Edit Makefile and make sure -DMVR is added as an extra flag 3) make clean 4) make vxWorks I wonder if the missing defines come from system makefiles, which, perhaps the system can't find if you don't set the WIND_BASE environment variable properly....? erik > -----Original Message----- > From: Servio Lima [mailto:servio@andrew.cmu.edu] > Sent: Thursday, November 23, 2000 5:17 AM > To: Johnson, Erik J > Cc: ixp1200(a)CS.Princeton.EDU > Subject: Re: PETH drivers > > > Hi, > > In the compilation process of Vxworks , I've found several > flags specified > in the Makefile , defs files and rules files that needs to > be declared > first. These flags have null values and they cause the whole > make process to > stop abruptly. For example: > > partialImage.o: $(LDDEPS) $(PRJ_OBJS) $(EXTRA_MODULES) > $(COMPONENT_LIBS) > $(LIBS) $(PRJ_OBJS_FILE) > - @ $(RM) $@ > > flags like the Tornado source directory are not defined. > Whats the procedure > for giving values to them? > > Regards, > Servio > > > "Johnson, Erik J" wrote: > > > What does the console (serial) window say when > > you get these failures? If you are getting > > IP_MAX_UNITS failures, then you need to recompile > > vxworks with IP_MAX_UNITS set higher than 1 > > (it needs to be >= PETH_NUM_DEVS + 1). The NetApp > > init code registers the END driver(s) with the > > IP stack and be default VxWorks only allows > > one registration with the IP stack (which is > > consumed by the Intel NIC/driver). You can > > see an example of how I did this in the supplied > > BoardSupport/VxWorks/IXP1200EB/config.h, search > > for MVR, or IP_MAX_UNITS, and then follow this > > model to build your BSP (or if you are using the > > supplied BSP, just define MVR and recompile) > > > > if that is not the problem, I am at a loss. > > Perhaps it is a version mis-match? The driver > > was written for VxWorks 5.4 (if I remember correctly) > > maybe something changed in the END interface...? > > > > The default routes were #ifdef'd out for the MVR > > application because we were demonstrating a routing > > protocol (OSPF) rather than static routes. In addition, > > the route table manager changed its interface slightly > > to support the notion of virtual routers. If you want > > to add a route, simply use the rtm_mvr code. look in > > SA1_CoreLibs/rtm-mvr/, the VxWorks shell commands are > > available from rtm_console.cpp/rtm_console.h if you > > just want to call them "by hand", or add them into > > any init code you want. > > > > erik > > > > > -----Original Message----- > > > From: Servio Lima [mailto:servio@andrew.cmu.edu] > > > Sent: Wednesday, November 22, 2000 4:48 AM > > > To: Johnson, Erik J; ixp1200(a)CS.Princeton.EDU > > > Subject: Re: PETH drivers > > > > > > > > > Hi, > > > > > > I still get the same error , even reducing the number of > PETH devices: > > > -> NetApp_GigInit > > > > > > STATUS OF intConnect = 0 > > > BigMacDriver CTOR OctalMacNumber = 0 > > > status = 0 > > > status = ffffffff > > > Failed to load Pseudo Ethernet driver number 0 > > > Failed to load Pseudo Ethernet driver number 1 > > > Failed to load Pseudo Ethernet driver number 2 > > > Failed to load Pseudo Ethernet driver number 3 > > > value = -1341915136 = 0xb0040000 > > > > > > Some hints: > > > I am compiling the vxworks_mvr application using Tornado with the > > > following flags: > > > ccarm > > > -g -mcpu=strongarm110 -mapcs-32 -ansi -nostdinc -DRW_MULTI_THREAD > > > -D_REENTRANT -mno-sched-prolog -fno-builtin -fvolatile -w > > > -Wall -pedantic > > > -I. -IC:/Tornado/target/h -Ic:\ixp1200\include > > > -Ic:\ixp1200\SA1_CoreLibs\libd -Ic:\ixp1200\msgq > > > -Ic:\ixp1200\SA1_CoreLibs\GigaMAC_GC82547EB > > > -Ic:\ixp1200\SA1_CoreLibs\debug_1200 -Ic:\ixp1200\utils > -DCPU=ARMSA110 > > > -DOS=VXWORKS -DIOSTYLE=HARDWARE -DVX_WORKS -DVXWORKS -DROUTE > > > -DFBUS_DEV0_TYPE=0 -DFBUS_DEV1_TYPE=1 -DMAC_21440 -DMAC_GC82547EB > > > -DWB_SVR -DFBUS_DEVICE_COUNT=2 -D__unix -DRTM_MVR > -DROUTE -DPETH_DRV > > > -DPETH_NUM_DEVS=4 > > > > > > > > > That are the same flags found in vxworks_mvr.mak makefile > > > Any suggestions? > > > > > > In addition , I'd like to know exactly where the route for > > > port 18 should > > > be inserted in the fixed routing table that is implemented in > > > \Ixp1200\SA1_Corelibs\app1200\net_app.cpp, because there is a > > > preprocessor directive that banned the insertion of a route > > > in the place > > > where other routes are added. An extracted portion of the > > > code explains > > > this: > > > > > > #ifdef ROUTE > > > #ifndef RTM_MVR ------------------> it is assumed that if > > > MVR is used a > > > new route can not be inserted?? > > > rt_add("1.1.1.1", "255.0.0.0", 1); > > > ....etc > > > > > > > > > Thanks in advance, > > > Servio > > > > > > > > > > > > > > > "Johnson, Erik J" wrote: > > > > > > > Sorry, I missed the last part of your email. > > > > The PETH driver ASSUMES it gets packets from port 18, > > > > you don't need to instantiate that many drivers. > > > > Simply instantiate drivers for the ports you want to > > > > logically represent to VxWorks (e.g, just the first > > > > 4 10/100 ports). Then each driver will enqueue for > > > > the transmit port associated with its instance, > > > > all will receive from port 18 and demultiplexing will > > > > be done based on the ingress port number within the > > > > packet descriptor. Note, you should be loading the > > > > MVRRefdes microcode with this driver since it has > > > > modifications to the microcode that allow the core to > > > > properly enqueue on the outgoing (transmit) queues. > > > > > > > > erik > > > > > > > > > -----Original Message----- > > > > > From: Servio Lima [mailto:servio@andrew.cmu.edu] > > > > > Sent: Tuesday, November 21, 2000 2:23 PM > > > > > Cc: ixp1200(a)CS.Princeton.EDU > > > > > Subject: PETH drivers > > > > > > > > > > > > > > > > > > > > Hi, > > > > > Does anyone has experience using Pseudo Ethernet drivers for > > > > > StrongArm-Microengine > > > > > communications? > > > > > I got the following problem each time I compile with the > > > > > -DPETH_DRV flag on > > > > > (using Tornado Workbench): > > > > > > > > > > -> ld < my_rtmmvr.out > > > > > Loading C:/project2/ARMSA110gnu/rtmmvr.out | > > > > > value = 3275480 = 0x31fad8 > > > > > -> NetApp_GigInit > > > > > > > > > > STATUS OF intConnect = 0 > > > > > BigMacDriver CTOR OctalMacNumber = 0 > > > > > status = 0 > > > > > status = ffffffff > > > > > Failed to load Pseudo Ethernet driver number 0 > > > > > Failed to load Pseudo Ethernet driver number 1 > > > > > Failed to load Pseudo Ethernet driver number 2 > > > > > Failed to load Pseudo Ethernet driver number 3 > > > > > Failed to load Pseudo Ethernet driver number 4 > > > > > Failed to load Pseudo Ethernet driver number 5 > > > > > Failed to load Pseudo Ethernet driver number 6 > > > > > Failed to load Pseudo Ethernet driver number 7 > > > > > Failed to load Pseudo Ethernet driver number 8 > > > > > Failed to load Pseudo Ethernet driver number 9 > > > > > Failed to load Pseudo Ethernet driver number 10 > > > > > Failed to load Pseudo Ethernet driver number 11 > > > > > Failed to load Pseudo Ethernet driver number 12 > > > > > Failed to load Pseudo Ethernet driver number 13 > > > > > Failed to load Pseudo Ethernet driver number 14 > > > > > Failed to load Pseudo Ethernet driver number 15 > > > > > Failed to load Pseudo Ethernet driver number 16 > > > > > Failed to load Pseudo Ethernet driver number 17 > > > > > Failed to load Pseudo Ethernet driver number 18 > > > > > Failed to load Pseudo Ethernet driver number 19 > > > > > > > > > > Exception number 16: Task: 0x3bff74 (t31) > > > > > > > > > > Data abort > > > > > Program Counter: 0xcc294 > > > > > Status Register: 0x60000013 > > > > > 8e6c8 _vxTaskEntry +28 : 3ff64 () > > > > > 40008 _wdbFuncCallLibInit+128: _NetApp_GigInit () > > > > > cc358 _NetApp_GigInit+c : _NetApp_Init__Fv () > > > > > > > > > > Data abort > > > > > Exception address: 0x000cc294 > > > > > Current Processor Status Register: 0x60000013 > > > > > Task: 0x3bff74 "t31" > > > > > value = 0 = 0x0 > > > > > > > > > > > > > > > I am using -DPETH_NUM_DEVS=20, that is 20 PETH devices, > > > > > because I want to use port > > > > > No. 18 for the StrongArm-uengine communication. > > > > > > > > > > Basically the problem is the invocation of the function: > > > cookie = > > > > > muxDevLoad(pethDrvNum, pethEndLoad, pethInitStr, 0, NULL); > > > > > that can be found in > \IXP1200\SA1_CoreLibs\app_1200\net_app.cpp > > > > > > > > > > My goal is to transmit a packet from the StronArm to the > > > > > uengine and viceversa. I > > > > > think I should enable the PETH functionality first, but if > > > > > anyone knows of > > > > > another method for doing the same, please let me know ASAP. > > > > > > > > > > Any help would be appreciated. > > > > > > > > > > Regards, > > > > > Servio Lima7 > > > > > > > > > > > > > > > > > >

1 0

RE: PETH drivers
by Johnson, Erik J 25 Nov '00

25 Nov '00

What does the console (serial) window say when you get these failures? If you are getting IP_MAX_UNITS failures, then you need to recompile vxworks with IP_MAX_UNITS set higher than 1 (it needs to be >= PETH_NUM_DEVS + 1). The NetApp init code registers the END driver(s) with the IP stack and be default VxWorks only allows one registration with the IP stack (which is consumed by the Intel NIC/driver). You can see an example of how I did this in the supplied BoardSupport/VxWorks/IXP1200EB/config.h, search for MVR, or IP_MAX_UNITS, and then follow this model to build your BSP (or if you are using the supplied BSP, just define MVR and recompile) if that is not the problem, I am at a loss. Perhaps it is a version mis-match? The driver was written for VxWorks 5.4 (if I remember correctly) maybe something changed in the END interface...? The default routes were #ifdef'd out for the MVR application because we were demonstrating a routing protocol (OSPF) rather than static routes. In addition, the route table manager changed its interface slightly to support the notion of virtual routers. If you want to add a route, simply use the rtm_mvr code. look in SA1_CoreLibs/rtm-mvr/, the VxWorks shell commands are available from rtm_console.cpp/rtm_console.h if you just want to call them "by hand", or add them into any init code you want. erik > -----Original Message----- > From: Servio Lima [mailto:servio@andrew.cmu.edu] > Sent: Wednesday, November 22, 2000 4:48 AM > To: Johnson, Erik J; ixp1200(a)CS.Princeton.EDU > Subject: Re: PETH drivers > > > Hi, > > I still get the same error , even reducing the number of PETH devices: > -> NetApp_GigInit > > STATUS OF intConnect = 0 > BigMacDriver CTOR OctalMacNumber = 0 > status = 0 > status = ffffffff > Failed to load Pseudo Ethernet driver number 0 > Failed to load Pseudo Ethernet driver number 1 > Failed to load Pseudo Ethernet driver number 2 > Failed to load Pseudo Ethernet driver number 3 > value = -1341915136 = 0xb0040000 > > Some hints: > I am compiling the vxworks_mvr application using Tornado with the > following flags: > ccarm > -g -mcpu=strongarm110 -mapcs-32 -ansi -nostdinc -DRW_MULTI_THREAD > -D_REENTRANT -mno-sched-prolog -fno-builtin -fvolatile -w > -Wall -pedantic > -I. -IC:/Tornado/target/h -Ic:\ixp1200\include > -Ic:\ixp1200\SA1_CoreLibs\libd -Ic:\ixp1200\msgq > -Ic:\ixp1200\SA1_CoreLibs\GigaMAC_GC82547EB > -Ic:\ixp1200\SA1_CoreLibs\debug_1200 -Ic:\ixp1200\utils -DCPU=ARMSA110 > -DOS=VXWORKS -DIOSTYLE=HARDWARE -DVX_WORKS -DVXWORKS -DROUTE > -DFBUS_DEV0_TYPE=0 -DFBUS_DEV1_TYPE=1 -DMAC_21440 -DMAC_GC82547EB > -DWB_SVR -DFBUS_DEVICE_COUNT=2 -D__unix -DRTM_MVR -DROUTE -DPETH_DRV > -DPETH_NUM_DEVS=4 > > > That are the same flags found in vxworks_mvr.mak makefile > Any suggestions? > > In addition , I'd like to know exactly where the route for > port 18 should > be inserted in the fixed routing table that is implemented in > \Ixp1200\SA1_Corelibs\app1200\net_app.cpp, because there is a > preprocessor directive that banned the insertion of a route > in the place > where other routes are added. An extracted portion of the > code explains > this: > > #ifdef ROUTE > #ifndef RTM_MVR ------------------> it is assumed that if > MVR is used a > new route can not be inserted?? > rt_add("1.1.1.1", "255.0.0.0", 1); > ....etc > > > Thanks in advance, > Servio > > > > > "Johnson, Erik J" wrote: > > > Sorry, I missed the last part of your email. > > The PETH driver ASSUMES it gets packets from port 18, > > you don't need to instantiate that many drivers. > > Simply instantiate drivers for the ports you want to > > logically represent to VxWorks (e.g, just the first > > 4 10/100 ports). Then each driver will enqueue for > > the transmit port associated with its instance, > > all will receive from port 18 and demultiplexing will > > be done based on the ingress port number within the > > packet descriptor. Note, you should be loading the > > MVRRefdes microcode with this driver since it has > > modifications to the microcode that allow the core to > > properly enqueue on the outgoing (transmit) queues. > > > > erik > > > > > -----Original Message----- > > > From: Servio Lima [mailto:servio@andrew.cmu.edu] > > > Sent: Tuesday, November 21, 2000 2:23 PM > > > Cc: ixp1200(a)CS.Princeton.EDU > > > Subject: PETH drivers > > > > > > > > > > > > Hi, > > > Does anyone has experience using Pseudo Ethernet drivers for > > > StrongArm-Microengine > > > communications? > > > I got the following problem each time I compile with the > > > -DPETH_DRV flag on > > > (using Tornado Workbench): > > > > > > -> ld < my_rtmmvr.out > > > Loading C:/project2/ARMSA110gnu/rtmmvr.out | > > > value = 3275480 = 0x31fad8 > > > -> NetApp_GigInit > > > > > > STATUS OF intConnect = 0 > > > BigMacDriver CTOR OctalMacNumber = 0 > > > status = 0 > > > status = ffffffff > > > Failed to load Pseudo Ethernet driver number 0 > > > Failed to load Pseudo Ethernet driver number 1 > > > Failed to load Pseudo Ethernet driver number 2 > > > Failed to load Pseudo Ethernet driver number 3 > > > Failed to load Pseudo Ethernet driver number 4 > > > Failed to load Pseudo Ethernet driver number 5 > > > Failed to load Pseudo Ethernet driver number 6 > > > Failed to load Pseudo Ethernet driver number 7 > > > Failed to load Pseudo Ethernet driver number 8 > > > Failed to load Pseudo Ethernet driver number 9 > > > Failed to load Pseudo Ethernet driver number 10 > > > Failed to load Pseudo Ethernet driver number 11 > > > Failed to load Pseudo Ethernet driver number 12 > > > Failed to load Pseudo Ethernet driver number 13 > > > Failed to load Pseudo Ethernet driver number 14 > > > Failed to load Pseudo Ethernet driver number 15 > > > Failed to load Pseudo Ethernet driver number 16 > > > Failed to load Pseudo Ethernet driver number 17 > > > Failed to load Pseudo Ethernet driver number 18 > > > Failed to load Pseudo Ethernet driver number 19 > > > > > > Exception number 16: Task: 0x3bff74 (t31) > > > > > > Data abort > > > Program Counter: 0xcc294 > > > Status Register: 0x60000013 > > > 8e6c8 _vxTaskEntry +28 : 3ff64 () > > > 40008 _wdbFuncCallLibInit+128: _NetApp_GigInit () > > > cc358 _NetApp_GigInit+c : _NetApp_Init__Fv () > > > > > > Data abort > > > Exception address: 0x000cc294 > > > Current Processor Status Register: 0x60000013 > > > Task: 0x3bff74 "t31" > > > value = 0 = 0x0 > > > > > > > > > I am using -DPETH_NUM_DEVS=20, that is 20 PETH devices, > > > because I want to use port > > > No. 18 for the StrongArm-uengine communication. > > > > > > Basically the problem is the invocation of the function: > cookie = > > > muxDevLoad(pethDrvNum, pethEndLoad, pethInitStr, 0, NULL); > > > that can be found in \IXP1200\SA1_CoreLibs\app_1200\net_app.cpp > > > > > > My goal is to transmit a packet from the StronArm to the > > > uengine and viceversa. I > > > think I should enable the PETH functionality first, but if > > > anyone knows of > > > another method for doing the same, please let me know ASAP. > > > > > > Any help would be appreciated. > > > > > > Regards, > > > Servio Lima7 > > > > > > > >

3 2

RE: PETH drivers
by Johnson, Erik J 22 Nov '00

22 Nov '00

Sorry, I missed the last part of your email. The PETH driver ASSUMES it gets packets from port 18, you don't need to instantiate that many drivers. Simply instantiate drivers for the ports you want to logically represent to VxWorks (e.g, just the first 4 10/100 ports). Then each driver will enqueue for the transmit port associated with its instance, all will receive from port 18 and demultiplexing will be done based on the ingress port number within the packet descriptor. Note, you should be loading the MVRRefdes microcode with this driver since it has modifications to the microcode that allow the core to properly enqueue on the outgoing (transmit) queues. erik > -----Original Message----- > From: Servio Lima [mailto:servio@andrew.cmu.edu] > Sent: Tuesday, November 21, 2000 2:23 PM > Cc: ixp1200(a)CS.Princeton.EDU > Subject: PETH drivers > > > > Hi, > Does anyone has experience using Pseudo Ethernet drivers for > StrongArm-Microengine > communications? > I got the following problem each time I compile with the > -DPETH_DRV flag on > (using Tornado Workbench): > > -> ld < my_rtmmvr.out > Loading C:/project2/ARMSA110gnu/rtmmvr.out | > value = 3275480 = 0x31fad8 > -> NetApp_GigInit > > STATUS OF intConnect = 0 > BigMacDriver CTOR OctalMacNumber = 0 > status = 0 > status = ffffffff > Failed to load Pseudo Ethernet driver number 0 > Failed to load Pseudo Ethernet driver number 1 > Failed to load Pseudo Ethernet driver number 2 > Failed to load Pseudo Ethernet driver number 3 > Failed to load Pseudo Ethernet driver number 4 > Failed to load Pseudo Ethernet driver number 5 > Failed to load Pseudo Ethernet driver number 6 > Failed to load Pseudo Ethernet driver number 7 > Failed to load Pseudo Ethernet driver number 8 > Failed to load Pseudo Ethernet driver number 9 > Failed to load Pseudo Ethernet driver number 10 > Failed to load Pseudo Ethernet driver number 11 > Failed to load Pseudo Ethernet driver number 12 > Failed to load Pseudo Ethernet driver number 13 > Failed to load Pseudo Ethernet driver number 14 > Failed to load Pseudo Ethernet driver number 15 > Failed to load Pseudo Ethernet driver number 16 > Failed to load Pseudo Ethernet driver number 17 > Failed to load Pseudo Ethernet driver number 18 > Failed to load Pseudo Ethernet driver number 19 > > Exception number 16: Task: 0x3bff74 (t31) > > Data abort > Program Counter: 0xcc294 > Status Register: 0x60000013 > 8e6c8 _vxTaskEntry +28 : 3ff64 () > 40008 _wdbFuncCallLibInit+128: _NetApp_GigInit () > cc358 _NetApp_GigInit+c : _NetApp_Init__Fv () > > Data abort > Exception address: 0x000cc294 > Current Processor Status Register: 0x60000013 > Task: 0x3bff74 "t31" > value = 0 = 0x0 > > > I am using -DPETH_NUM_DEVS=20, that is 20 PETH devices, > because I want to use port > No. 18 for the StrongArm-uengine communication. > > Basically the problem is the invocation of the function: cookie = > muxDevLoad(pethDrvNum, pethEndLoad, pethInitStr, 0, NULL); > that can be found in \IXP1200\SA1_CoreLibs\app_1200\net_app.cpp > > My goal is to transmit a packet from the StronArm to the > uengine and viceversa. I > think I should enable the PETH functionality first, but if > anyone knows of > another method for doing the same, please let me know ASAP. > > Any help would be appreciated. > > Regards, > Servio Lima7 > >

2 1

RE: PETH drivers
by Johnson, Erik J 21 Nov '00

21 Nov '00

You also need to define PETH_NUM_DEVS=xx some integer value of the number of interfaces you want to install drivers for (e.g., PETH_NUM_DEVS=8). The vxworks_mvr.mak makefile compiles the driver into the NetApp code, if you want an example. erik > -----Original Message----- > From: Servio Lima [mailto:servio@andrew.cmu.edu] > Sent: Tuesday, November 21, 2000 2:23 PM > Cc: ixp1200(a)CS.Princeton.EDU > Subject: PETH drivers > > > > Hi, > Does anyone has experience using Pseudo Ethernet drivers for > StrongArm-Microengine > communications? > I got the following problem each time I compile with the > -DPETH_DRV flag on > (using Tornado Workbench): > > -> ld < my_rtmmvr.out > Loading C:/project2/ARMSA110gnu/rtmmvr.out | > value = 3275480 = 0x31fad8 > -> NetApp_GigInit > > STATUS OF intConnect = 0 > BigMacDriver CTOR OctalMacNumber = 0 > status = 0 > status = ffffffff > Failed to load Pseudo Ethernet driver number 0 > Failed to load Pseudo Ethernet driver number 1 > Failed to load Pseudo Ethernet driver number 2 > Failed to load Pseudo Ethernet driver number 3 > Failed to load Pseudo Ethernet driver number 4 > Failed to load Pseudo Ethernet driver number 5 > Failed to load Pseudo Ethernet driver number 6 > Failed to load Pseudo Ethernet driver number 7 > Failed to load Pseudo Ethernet driver number 8 > Failed to load Pseudo Ethernet driver number 9 > Failed to load Pseudo Ethernet driver number 10 > Failed to load Pseudo Ethernet driver number 11 > Failed to load Pseudo Ethernet driver number 12 > Failed to load Pseudo Ethernet driver number 13 > Failed to load Pseudo Ethernet driver number 14 > Failed to load Pseudo Ethernet driver number 15 > Failed to load Pseudo Ethernet driver number 16 > Failed to load Pseudo Ethernet driver number 17 > Failed to load Pseudo Ethernet driver number 18 > Failed to load Pseudo Ethernet driver number 19 > > Exception number 16: Task: 0x3bff74 (t31) > > Data abort > Program Counter: 0xcc294 > Status Register: 0x60000013 > 8e6c8 _vxTaskEntry +28 : 3ff64 () > 40008 _wdbFuncCallLibInit+128: _NetApp_GigInit () > cc358 _NetApp_GigInit+c : _NetApp_Init__Fv () > > Data abort > Exception address: 0x000cc294 > Current Processor Status Register: 0x60000013 > Task: 0x3bff74 "t31" > value = 0 = 0x0 > > > I am using -DPETH_NUM_DEVS=20, that is 20 PETH devices, > because I want to use port > No. 18 for the StrongArm-uengine communication. > > Basically the problem is the invocation of the function: cookie = > muxDevLoad(pethDrvNum, pethEndLoad, pethInitStr, 0, NULL); > that can be found in \IXP1200\SA1_CoreLibs\app_1200\net_app.cpp > > My goal is to transmit a packet from the StronArm to the > uengine and viceversa. I > think I should enable the PETH functionality first, but if > anyone knows of > another method for doing the same, please let me know ASAP. > > Any help would be appreciated. > > Regards, > Servio Lima7 > >

1 0