- ixp1200 - lists.cs.princeton.edu

RE: bad magic
by Brandewie, Dirk J 20 Nov '00

20 Nov '00

What image were you trying to load? --Dirk -----Original Message----- From: Hilarie Orman [mailto:HORMAN@novell.com] Sent: Monday, November 20, 2000 2:15 PM To: ixp1200(a)CS.Princeton.EDU Subject: bad magic I'm trying to boot a system for the first time and get an error after "attaching lo0" from loadLib saying that there's a bad magic number: 0x5a4d. Does this indicate an erroneous build or a version error or something else altogether? Hilarie

1 0

bad magic
by Hilarie Orman 20 Nov '00

20 Nov '00

I'm trying to boot a system for the first time and get an error after "attaching lo0" from loadLib saying that there's a bad magic number: 0x5a4d. Does this indicate an erroneous build or a version error or something else altogether? Hilarie

1 0

FUtil Host for Linux
by Scott C. Karlin 17 Nov '00

17 Nov '00

Does anyone know if the host side of the ixp1200eb flash utility (FUtil HOST) has been ported to Linux? If not, I am willing to do it. Can someone at Intel provide details of the protocol used between the host and the ixp1200eb? The source code for Windows is in BoardSupport/FlashUtil/host and shows that the author is "jdg" / "Jdguilfo". I'd prefer to work with a spec (even in the form of notes) about the protocol rather than the source code marked Intel proprietary. Thanks, Scott

1 0

Trouble booting new ixp1200eb
by Scott C. Karlin 16 Nov '00

16 Nov '00

I am just now trying out the new ixp1200 evaluation board. Apparently there has been some changed to the tftp procedure between firmware revisions. Here is the (correct) terminal output for my "Hello, World" program on the *old* board. (Note that I have removed duplicate blank lines from the output for readability.) =========================== OLD BOARD =========================== Early serial debug initialized muxLoad failed! 0x VxWorks System Boot Copyright 1984-1998 Wind River Systems, Inc. CPU: Level One ixp1200eb - ARM IXP1200 Version: 5.4 BSP version: 1.0/948 Creation date: Feb 16 2000, 14:44:03 Press any key to stop auto-boot... 0 auto-booting... boot device : eeE unit number : 0 processor number : 0 host name : scout-7 file name : ixp1200a inet on ethernet (e) : 128.112.42.102 inet on backplane (b): 0 host inet (h) : 128.112.42.27 user (u) : target ftp password (pw) : target flags (f) : 0x88 target name (tn) : ixp1200a Attached TCP/IP interface to eeE0. Attaching network interface lo0... done. Loading... 340 + 0 + 0 Starting at 0x1000... Hello, World! Enter characters to be echoed: ================================================================= Here's what happens with the new board. (I am using the BootMgr to point to VxWorks.) =========================== NEW BOARD =========================== Press space bar to stop auto-boot... 0 BSP IXP Version: 1.0.1129, built on May 31 2000, 10:29:10 Early serial debug initialized muxLoad VxWorks System Boot Copyright 1984-1998 Wind River Systems, Inc. CPU: Intel ixp1200eb - ARM IXP1200 Version: 5.4 BSP version: 1.2/1 Creation date: May 31 2000, 10:29:10 Press any key to stop auto-boot... 0 auto-booting... boot device : eeE unit number : 0 processor number : 0 host name : scout-7 file name : ixp1200a inet on ethernet (e) : 128.112.42.102 host inet (h) : 128.112.42.27 user (u) : target ftp password (pw) : target flags (f) : 0x88 target name (tn) : ixp1200a Can't load boot file!! BSP IXP Version: 1.0.1129, built on May 31 2000, 10:29:10 Early serial debug initialized muxLoad [VxWorks Boot]: ================================================================= What precisely does "Can't load boot file!!" mean? Why would the old version work when the new version does not? (Remember that we are not really using VxWorks. There is a possibility that the new firmware is more particular about the content of the boot file but I'm not sure if the file is getting transferred of the network.) Thanks, Scott

2 2

Re: Schematics for Eval Boards
by Scott C. Karlin 16 Nov '00

16 Nov '00

I think I have answered my own question. I was looking at the schematics in documentation/Schematics_EB/evb_p*.pdf which are marked as in my original message (and marked "July 99 Rev B" on the first page). The new schematics pages are all in the single file called "documentation/IXP1200 Eval Sys Schematics.pdf" (and marked "Jan 5, 2000 REV A01"). The title page is marked with the part number "A13033-001". -Scott Scott Karlin writes: > > I do see that the new PCB number does match the old PCB number > (A13033). However, I'm starting to suspect that there is at least > a small discrepancy between the board and the schematics. > > I'm looking carefully at the board and the schematics to convince > myself that the board will work when plugged into a Pentium > motherboard. (The PCI_debug.txt file not withstanding.) > > The signals which caught my eye are the PCI signals PRSNT1# and > PRSNT2# found on pins B9 and B11 of the PCI backplane. For expansion > boards, the PCI spec (rev 2.2, section 4.4.1) states that at least > one of the signals must be grounded to indicate that a board is > plugged into an expansion slot. The schematics (page 2, zone D3) > show that these signals are pulled up to Vdd (3.3V) via 5Kohm > ("R502") resistors R222 and R223. Both a visual inspection of the > board and a check with a meter shows that R222 and R223 are 20Kohm > (marked "203") resistors. While this is not a big discrepancy, it > tells me that the schematics may not match in more significant ways. > > Pat Kelley writes: > > > > The 002 sticker reflects the revision update for B0 200MHz. > > > > The schematics number matches the PCB (look under the sticker!) > > > > Scott Karlin writes: > > > > > > We just received a new version of the IXP1200 development board > > > with the B0 stepping of the IXP1200 chip. Included in the shipment > > > is the version 1.1.109 of the development environment CD-ROM. > > > > > > I would like to verify that the schematics on this CD-ROM match > > > the board we just received. The evb_p1.pdf page title block > > > states "TOP DOCUMENT NUMBER K-DD-54-30296-0-1" dated 13-AUG-99. > > > > > > Our older board was marked in the copper layer "A13033-001 A01 L1". > > > Our new boards have a sticker in the same place marked "A13033-002". > > > > > > Can anyone confirm that the 13-AUG-99 schematics match the board > > > we just received?

1 0

Tornado Prototyper
by Brandewie, Dirk J 16 Nov '00

16 Nov '00

Thought some on the list would be interested in this. WindRiver Has tornado for download for non-commercial use. Enjoy --Dirk http://www.wrs.com/prototyper/index.html

1 0

IXP1200 Measurement Results
by Scott C. Karlin 15 Nov '00

15 Nov '00

For those interested in what we have been up to with regard to the IXP1200 processor, you might want to check out the following paper, available at http://www.cs.princeton.edu/nsg/papers/ixp.ps The abstract is given below. Scott ----------------------- Evaluating Network Processors in IP Forwarding Tammo Spalink, Scott Karlin, Larry Peterson This paper evaluates the performance of emerging network processors---in particular, designs that employ multiple hardware contexts to hide memory latency---in constructing IP routers. Such processors are designed to forward minimum-sized IP packets at line speeds, with the advantage (over ASIC-based solutions) of being programmable. However, programming such network processors involves two challenges. The first is how to effectively employ the multiple contexts in a way that fully utilizes the memory bandwidth. The second is how to allow the network processor to be programmed dynamically (so it can support new functionality) without violating the processor's tight timing constraints. This paper addresses both of these challenges on a prototype board that uses the IXP1200 network processor. We demonstrate that it is possible to support 8 x 100Mbps ports with enough headroom to access up to 224 bytes of state information for each minimum-sized IP packet.

1 0

RE: VxWorks on IXP
by Heaton, Eric D 14 Nov '00

14 Nov '00

Just for some basic setup info: There are two documents (which should be found on the Developer's Workbench CD) which are invaluable in setting up the Eval System and running the reference designs, the Evaluation System User's Guide and the Example Software User's Guide. There is information sepcific to loading VxWorks without using Tornado in Section 2.5.6 in the Evaluation System User's Guide, but please read through the rest of the document for general setup information. -----Original Message----- From: Varnell, Frank [mailto:frank.varnell@intel.com] Sent: Monday, November 13, 2000 12:06 PM To: 'Alok Kumar'; Kelley Jr, Patrick T Cc: 'Taroon Mandhana'; ixp1200(a)CS.Princeton.EDU Subject: RE: VxWorks on IXP The vxworks_gig image includes the RTM netapp application. The only thing you would then use Tornado for is to have a shell. The developers didn't use a serial port shell, so you have to buy or obtain an eval Tornado for ARM (version 2.0 NOT 2.0.1) to connect to the target if you need a shell. To be more specific, set up your eval card to boot vxworks via the instructions provided with your boad. Then set the vxworks parameters to load vxworks_gig. Thats all you have to do. Packets will be routed according to the compiled in tables. These comments apply to the 1.0 release of the ixp eval. > -----Original Message----- > From: Alok Kumar [mailto:alok@cs.utexas.edu] > Sent: Sunday, November 12, 2000 7:46 AM > To: Kelley Jr, Patrick T > Cc: 'Taroon Mandhana'; ixp1200(a)CS.Princeton.EDU > Subject: RE: VxWorks on IXP > > > How can we run netapp application without tornado? What does netapp > application do and how will it affect if we dont run it? > > Thanks > Alok > > On Fri, 10 Nov 2000, Kelley Jr, Patrick T wrote: > > > 1. No. > > 2. This is fine! The "WDB: Ready." is the key that the > image is loaded and > > you are ready to run. > > > > You should be able to connect with the Workbench no problem now. > > > > (Just make sure you have the NetApp application running on > the core.) > > > > Best Regards, > > Pat > > ___________________________________ > > Patrick T. Kelley > > Technical Marketing Engineer > > Network Processor Operation - Network Communications Group > > > > Intel Corporation > > 77 Reed Road HD2-141 > > Hudson, Massachusetts 01749-2895 > > patrick.t.kelley.jr(a)intel.com > > http://www.intel.com > > > > > > -----Original Message----- > > From: Taroon Mandhana [mailto:mandhana@cs.utexas.edu] > > Sent: Friday, November 10, 2000 3:34 PM > > To: ixp1200(a)CS.Princeton.EDU > > Subject: VxWorks on IXP > > > > Hi, > > > > 1. Is tornado a MUST to download the reference designs on > the board ? > > > > 2. Without Tornado, I tried downloading the default VxWorks image > > ixp1200/boardsupport/bin/vp/vxworks_gig on the board > and landed into > > the errors. Here is how the output looks like > > > > Attached TCP/IP interface to eeE0. > > Attaching network interface lo0... done. > o > > > > Loading... 8488 + 14136 + 228816 > > Starting at 0x1000... > > > > BSP IXP Version: 1.0.1129, built on May 31 2000, 10:28:04 > > > > Early serial debug initialized > > muxDevLoad failed for device entry 0! > > Attached TCP/IP interface to eeE unit 0 > > Attaching network interface lo0... done. > > 0x7ffe64 (tRootTask): dc0 - Failed to read ethernet address > > NFS client support not included. > > > > > > VxWorks > > > > Copyright 1984-1998 Wind River Systems, Inc. > > > > CPU: Intel ixp1200eb - ARM IXP1200 > > VxWorks: 5.4 > > BSP version1.2/1 > > Creation date: May 31 2000 > > WDB: Ready. > > > > STATUS OF intConnect = 0 > > BigMacDriver CTOR OctalMacNumber = 0 > > status = 0 > > status = ffffffff > > > > ----- > > > > Is is erroneous? Is there some troubleshooting guide in the > > documentation ? > > > > Any help is greatly appreciated. > > > > > > Thanks, > > Taroon Mandhana > > > > > > > > > > ______________________________________________________________ > _________________ > > 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: Schematics for Eval Boards
by Kelley Jr, Patrick T 14 Nov '00

14 Nov '00

The 002 sticker reflects the revision update for B0 200MHz. The schematics number matches the PCB (look under the sticker!) Best Regards, Pat ___________________________________ Patrick T. Kelley Technical Marketing Engineer Network Processor Operation - Network Communications Group Intel Corporation 77 Reed Road HD2-141 Hudson, Massachusetts 01749-2895 patrick.t.kelley.jr(a)intel.com http://www.intel.com -----Original Message----- From: Scott C. Karlin [mailto:scott@CS.Princeton.EDU] Sent: Thursday, November 09, 2000 3:09 PM To: ixp1200(a)CS.Princeton.EDU Subject: Schematics for Eval Boards We just received a new version of the IXP1200 development board with the B0 stepping of the IXP1200 chip. Included in the shipment is the version 1.1.109 of the development environment CD-ROM. I would like to verify that the schematics on this CD-ROM match the board we just received. The evb_p1.pdf page title block states "TOP DOCUMENT NUMBER K-DD-54-30296-0-1" dated 13-AUG-99. Our older board was marked in the copper layer "A13033-001 A01 L1". Our new boards have a sticker in the same place marked "A13033-002". Can anyone confirm that the 13-AUG-99 schematics match the board we just received? Thanks, Scott PS: Early versions of the CD-ROM have the schematics in both pdf and PostScript format. Any chance we can see the PostScript versions again? -------------------------------------------------------------------------- Scott C. Karlin Princeton University PhD Candidate Department of Computer Science Voice: (609) 258-5386 35 Olden Street Email: scott(a)cs.princeton.edu Princeton, NJ 08544-2087 WWW: http://www.cs.princeton.edu/~scott --------------------------------------------------------------------------

2 1

RE: VxWorks on IXP
by Varnell, Frank 13 Nov '00

13 Nov '00

The vxworks_gig image includes the RTM netapp application. The only thing you would then use Tornado for is to have a shell. The developers didn't use a serial port shell, so you have to buy or obtain an eval Tornado for ARM (version 2.0 NOT 2.0.1) to connect to the target if you need a shell. To be more specific, set up your eval card to boot vxworks via the instructions provided with your boad. Then set the vxworks parameters to load vxworks_gig. Thats all you have to do. Packets will be routed according to the compiled in tables. These comments apply to the 1.0 release of the ixp eval. > -----Original Message----- > From: Alok Kumar [mailto:alok@cs.utexas.edu] > Sent: Sunday, November 12, 2000 7:46 AM > To: Kelley Jr, Patrick T > Cc: 'Taroon Mandhana'; ixp1200(a)CS.Princeton.EDU > Subject: RE: VxWorks on IXP > > > How can we run netapp application without tornado? What does netapp > application do and how will it affect if we dont run it? > > Thanks > Alok > > On Fri, 10 Nov 2000, Kelley Jr, Patrick T wrote: > > > 1. No. > > 2. This is fine! The "WDB: Ready." is the key that the > image is loaded and > > you are ready to run. > > > > You should be able to connect with the Workbench no problem now. > > > > (Just make sure you have the NetApp application running on > the core.) > > > > Best Regards, > > Pat > > ___________________________________ > > Patrick T. Kelley > > Technical Marketing Engineer > > Network Processor Operation - Network Communications Group > > > > Intel Corporation > > 77 Reed Road HD2-141 > > Hudson, Massachusetts 01749-2895 > > patrick.t.kelley.jr(a)intel.com > > http://www.intel.com > > > > > > -----Original Message----- > > From: Taroon Mandhana [mailto:mandhana@cs.utexas.edu] > > Sent: Friday, November 10, 2000 3:34 PM > > To: ixp1200(a)CS.Princeton.EDU > > Subject: VxWorks on IXP > > > > Hi, > > > > 1. Is tornado a MUST to download the reference designs on > the board ? > > > > 2. Without Tornado, I tried downloading the default VxWorks image > > ixp1200/boardsupport/bin/vp/vxworks_gig on the board > and landed into > > the errors. Here is how the output looks like > > > > Attached TCP/IP interface to eeE0. > > Attaching network interface lo0... done. > o > > > > Loading... 8488 + 14136 + 228816 > > Starting at 0x1000... > > > > BSP IXP Version: 1.0.1129, built on May 31 2000, 10:28:04 > > > > Early serial debug initialized > > muxDevLoad failed for device entry 0! > > Attached TCP/IP interface to eeE unit 0 > > Attaching network interface lo0... done. > > 0x7ffe64 (tRootTask): dc0 - Failed to read ethernet address > > NFS client support not included. > > > > > > VxWorks > > > > Copyright 1984-1998 Wind River Systems, Inc. > > > > CPU: Intel ixp1200eb - ARM IXP1200 > > VxWorks: 5.4 > > BSP version1.2/1 > > Creation date: May 31 2000 > > WDB: Ready. > > > > STATUS OF intConnect = 0 > > BigMacDriver CTOR OctalMacNumber = 0 > > status = 0 > > status = ffffffff > > > > ----- > > > > Is is erroneous? Is there some troubleshooting guide in the > > documentation ? > > > > Any help is greatly appreciated. > > > > > > Thanks, > > Taroon Mandhana > > > > > > > > > > ______________________________________________________________ > _________________ > > 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: VxWorks on IXP
by Kelley Jr, Patrick T 12 Nov '00

12 Nov '00

1. No. 2. This is fine! The "WDB: Ready." is the key that the image is loaded and you are ready to run. You should be able to connect with the Workbench no problem now. (Just make sure you have the NetApp application running on the core.) Best Regards, Pat ___________________________________ Patrick T. Kelley Technical Marketing Engineer Network Processor Operation - Network Communications Group Intel Corporation 77 Reed Road HD2-141 Hudson, Massachusetts 01749-2895 patrick.t.kelley.jr(a)intel.com http://www.intel.com -----Original Message----- From: Taroon Mandhana [mailto:mandhana@cs.utexas.edu] Sent: Friday, November 10, 2000 3:34 PM To: ixp1200(a)CS.Princeton.EDU Subject: VxWorks on IXP Hi, 1. Is tornado a MUST to download the reference designs on the board ? 2. Without Tornado, I tried downloading the default VxWorks image ixp1200/boardsupport/bin/vp/vxworks_gig on the board and landed into the errors. Here is how the output looks like Attached TCP/IP interface to eeE0. Attaching network interface lo0... done. o Loading... 8488 + 14136 + 228816 Starting at 0x1000... BSP IXP Version: 1.0.1129, built on May 31 2000, 10:28:04 Early serial debug initialized muxDevLoad failed for device entry 0! Attached TCP/IP interface to eeE unit 0 Attaching network interface lo0... done. 0x7ffe64 (tRootTask): dc0 - Failed to read ethernet address NFS client support not included. VxWorks Copyright 1984-1998 Wind River Systems, Inc. CPU: Intel ixp1200eb - ARM IXP1200 VxWorks: 5.4 BSP version1.2/1 Creation date: May 31 2000 WDB: Ready. STATUS OF intConnect = 0 BigMacDriver CTOR OctalMacNumber = 0 status = 0 status = ffffffff ----- Is is erroneous? Is there some troubleshooting guide in the documentation ? Any help is greatly appreciated. Thanks, Taroon Mandhana

2 1

VxWorks on IXP
by Taroon Mandhana 10 Nov '00

10 Nov '00

Hi, 1. Is tornado a MUST to download the reference designs on the board ? 2. Without Tornado, I tried downloading the default VxWorks image ixp1200/boardsupport/bin/vp/vxworks_gig on the board and landed into the errors. Here is how the output looks like Attached TCP/IP interface to eeE0. Attaching network interface lo0... done. o Loading... 8488 + 14136 + 228816 Starting at 0x1000... BSP IXP Version: 1.0.1129, built on May 31 2000, 10:28:04 Early serial debug initialized muxDevLoad failed for device entry 0! Attached TCP/IP interface to eeE unit 0 Attaching network interface lo0... done. 0x7ffe64 (tRootTask): dc0 - Failed to read ethernet address NFS client support not included. VxWorks Copyright 1984-1998 Wind River Systems, Inc. CPU: Intel ixp1200eb - ARM IXP1200 VxWorks: 5.4 BSP version1.2/1 Creation date: May 31 2000 WDB: Ready. STATUS OF intConnect = 0 BigMacDriver CTOR OctalMacNumber = 0 status = 0 status = ffffffff ----- Is is erroneous? Is there some troubleshooting guide in the documentation ? Any help is greatly appreciated. Thanks, Taroon Mandhana

1 0

Schematics for Eval Boards
by Scott C. Karlin 09 Nov '00

09 Nov '00

We just received a new version of the IXP1200 development board with the B0 stepping of the IXP1200 chip. Included in the shipment is the version 1.1.109 of the development environment CD-ROM. I would like to verify that the schematics on this CD-ROM match the board we just received. The evb_p1.pdf page title block states "TOP DOCUMENT NUMBER K-DD-54-30296-0-1" dated 13-AUG-99. Our older board was marked in the copper layer "A13033-001 A01 L1". Our new boards have a sticker in the same place marked "A13033-002". Can anyone confirm that the 13-AUG-99 schematics match the board we just received? Thanks, Scott PS: Early versions of the CD-ROM have the schematics in both pdf and PostScript format. Any chance we can see the PostScript versions again? -------------------------------------------------------------------------- Scott C. Karlin Princeton University PhD Candidate Department of Computer Science Voice: (609) 258-5386 35 Olden Street Email: scott(a)cs.princeton.edu Princeton, NJ 08544-2087 WWW: http://www.cs.princeton.edu/~scott --------------------------------------------------------------------------

1 0

RE: PCI Configuration Space
by Krueger, Jon 20 Oct '00

20 Oct '00

Solution. The exception was not due to a bug in the IXP hardware. The exception was a result of incomplete/incorrect information given in the IXP1200 Hardware Reference Manual, Section 5.3.1.3. The Type 0 data in Table 5-4 states that StrongARM core address bits 23:22 are NOT equal to 11. This should read: If bits 23:22 are NOT equal to 11, then AD25:AD11 will be a copy of the StrongARM core address -- note that AD31:AD26 are not usable in this mode. If bit 23:22 are EQUAL to 11, the StrongARM core address AD15:AD11 will be decoded, and the appropriate bit in AD31:AD11 will be set. When bits 23:22 are set to 11 (0x3) the proper configuration address is decoded, and the entire configuration space (AD31:AD11) is available. jk > -----Original Message----- > From: Krueger, Jon > Sent: Friday, October 13, 2000 3:50 PM > To: ixp1200(a)CS.Princeton.EDU > Cc: Varsanyi, Eric > Subject: PCI Configuration Space > > I found an interesting "problem" with the IXP1200. > > When doing Type 0/1 configuration reads with the IXP, > any attempt to access devices using AD26-AD31 for their > IDSEL decoding will produce nasty results. > > With VxWorks, you'll get an exception, killing process execution. > With the custom OS I'm running now, I drop into the debugger and the > ARM PC is off in deep space... :-( > > This may be a design decision by the IXP engineers. They do support > a full 10 devices, but they assume that the devices will be decoded > within the config space of AD11-AD25. I'm guessing a bit here, but > it seems that this is the case. > > There are SBCs and "passive" backplanes which hardwire device IDSELs to > the > higher areas of config space AD26-AD31. > > Something to watch out for... > > > jk > > > > Jon Krueger > Senior Engineer > Intel Corporation > Network Equipment Division > > 13280 Evening Creek Drive > San Diego, CA 92128 > (858) 391-1710 > jon.krueger(a)intel.com > >

1 0

PCI Configuration Space
by Krueger, Jon 13 Oct '00

13 Oct '00

I found an interesting "problem" with the IXP1200. When doing Type 0/1 configuration reads with the IXP, any attempt to access devices using AD26-AD31 for their IDSEL decoding will produce nasty results. With VxWorks, you'll get an exception, killing process execution. With the custom OS I'm running now, I drop into the debugger and the ARM PC is off in deep space... :-( This may be a design decision by the IXP engineers. They do support a full 10 devices, but they assume that the devices will be decoded within the config space of AD11-AD25. I'm guessing a bit here, but it seems that this is the case. There are SBCs and "passive" backplanes which hardwire device IDSELs to the higher areas of config space AD26-AD31. Something to watch out for... jk > Jon Krueger > Senior Engineer > Intel Corporation > Network Equipment Division > > 13280 Evening Creek Drive > San Diego, CA 92128 > (858) 391-1710 > jon.krueger(a)intel.com > >

1 0

Looking for 82559 Software Developer's Manual
by Scott C. Karlin 02 Oct '00

02 Oct '00

I'd like to do some low-level programming of the 82559 on the Ethernet PCI card supplied with the IXP1200 development system. The datasheet, "82559 Fast Ethernet Multifunction PCI/CardBus Controller (rev 2.0)," does not provide enough information; it does refer to a "10/100 Mbit Family Software Developer's Manual." However, there is no mention of this manual on http://developer.intel.com. Anyone know where I can get a copy of this? -Scott

1 0

RE: IXP1200 Ready Bus Sequencer
by Johnson, Erik J 19 Sep '00

19 Sep '00

We use this: TEMPLATE_PROG1 = 0x1fdb1fd7 PROG2 = PROG3 = 0x0 Alternativly, I have also used PROG2 = PROG3 = 0x1f1f1f1f Basically the PROG1 says (nop, poll rcv rdy for macs 0 and 1, nop, poll tx rdy), PROG2 = 0 says flow ctl, and 1f says nops. I understand the nops and have been explained that the flow ctls are faster (fewer cycles) and that is why they are used in many cases. erik > -----Original Message----- > From: Tammo Spalink [mailto:tspalink@CS.Princeton.EDU] > Sent: Tuesday, September 19, 2000 3:46 PM > To: ixp1200(a)CS.Princeton.EDU > Subject: Re: IXP1200 Ready Bus Sequencer > > > > I am pretty sure I deal with stale flags correctly. > > What I was hoping for is an example set of 12 sequencer instructions > that are known to work well for my scenario: 8x100Mb, no autopush. > > Tammo > > On Tue, 19 Sep 2000, "Paige, Dale W" wrote: > > A commonly encountered problem can be encountererd when the > ready bus > > sequencer is servicing "slow ports" (10/100 ports). The > collection of the > > ready flags is asynchronous with the operation of the IX > Bus receive state > > machine. You can read the ready flags and find flags that > are set even > > though a rcv_req has been queued or even completed for the > port indicating a > > need for service. This is due to the latency in handling > the ready receive > > requests. Imagine a ready bus rxrdy command collecting the > flags the IX Bus > > cycle before the MAC de-asserts its RxReady signal for the > port which is the > > subject of an IX Bus read. We refer to such flags as stale flags. > > > > To deal with stale flags the RxReady flags can be "aged" by > holding them for > > one or two ready bus sequencer cycles before using them and > AND'ing them > > with the inverse of a "rcv_req outstanding" bit map. The > RCV_RDY_CNT > > associated with a set of RxReady flags is generally used to > assist in this > > purpose, although the RCV_CNTL_CNT can be used for an even > more precise (yet > > computationally intricate) tracking of the state of the > RxReady flags. > > Refer to the Hardware Reference manual section 6.6.4.8, > "Interpreting The > > Receive Ready Flags", for more information. > > > > On the transmit side you want to read the TxReady flags > fairly frequently so > > your transmit process can proceed as quickly as possible. >

1 0

Re: IXP1200 Ready Bus Sequencer
by Tammo Spalink 19 Sep '00

19 Sep '00

I am pretty sure I deal with stale flags correctly. What I was hoping for is an example set of 12 sequencer instructions that are known to work well for my scenario: 8x100Mb, no autopush. Tammo On Tue, 19 Sep 2000, "Paige, Dale W" wrote: > A commonly encountered problem can be encountererd when the ready bus > sequencer is servicing "slow ports" (10/100 ports). The collection of the > ready flags is asynchronous with the operation of the IX Bus receive state > machine. You can read the ready flags and find flags that are set even > though a rcv_req has been queued or even completed for the port indicating a > need for service. This is due to the latency in handling the ready receive > requests. Imagine a ready bus rxrdy command collecting the flags the IX Bus > cycle before the MAC de-asserts its RxReady signal for the port which is the > subject of an IX Bus read. We refer to such flags as stale flags. > > To deal with stale flags the RxReady flags can be "aged" by holding them for > one or two ready bus sequencer cycles before using them and AND'ing them > with the inverse of a "rcv_req outstanding" bit map. The RCV_RDY_CNT > associated with a set of RxReady flags is generally used to assist in this > purpose, although the RCV_CNTL_CNT can be used for an even more precise (yet > computationally intricate) tracking of the state of the RxReady flags. > Refer to the Hardware Reference manual section 6.6.4.8, "Interpreting The > Receive Ready Flags", for more information. > > On the transmit side you want to read the TxReady flags fairly frequently so > your transmit process can proceed as quickly as possible.

1 0

RE: IXP1200 Ready Bus Sequencer
by Paige, Dale W 19 Sep '00

19 Sep '00

A commonly encountered problem can be encountererd when the ready bus sequencer is servicing "slow ports" (10/100 ports). The collection of the ready flags is asynchronous with the operation of the IX Bus receive state machine. You can read the ready flags and find flags that are set even though a rcv_req has been queued or even completed for the port indicating a need for service. This is due to the latency in handling the ready receive requests. Imagine a ready bus rxrdy command collecting the flags the IX Bus cycle before the MAC de-asserts its RxReady signal for the port which is the subject of an IX Bus read. We refer to such flags as stale flags. To deal with stale flags the RxReady flags can be "aged" by holding them for one or two ready bus sequencer cycles before using them and AND'ing them with the inverse of a "rcv_req outstanding" bit map. The RCV_RDY_CNT associated with a set of RxReady flags is generally used to assist in this purpose, although the RCV_CNTL_CNT can be used for an even more precise (yet computationally intricate) tracking of the state of the RxReady flags. Refer to the Hardware Reference manual section 6.6.4.8, "Interpreting The Receive Ready Flags", for more information. On the transmit side you want to read the TxReady flags fairly frequently so your transmit process can proceed as quickly as possible. -----Original Message----- From: Tammo Spalink [mailto:tspalink@CS.Princeton.EDU] Sent: Tuesday, September 19, 2000 3:16 PM To: ixp1200(a)CS.Princeton.EDU Subject: IXP1200 Ready Bus Sequencer Could someone tell me what the proper sequencer program I should use is? I am using the evaluation board, I am using only the 8x100Mb ports, and I do not want any autopush operations. I am tying to receive across all ports at line speeds. All of the programs I have tried seem to miss MPKTs or cause other odd behavior. Thanks, Tammo

1 0

IXP1200 Ready Bus Sequencer
by Tammo Spalink 19 Sep '00

19 Sep '00

Could someone tell me what the proper sequencer program I should use is? I am using the evaluation board, I am using only the 8x100Mb ports, and I do not want any autopush operations. I am tying to receive across all ports at line speeds. All of the programs I have tried seem to miss MPKTs or cause other odd behavior. Thanks, Tammo

1 0

Questions about future IXP1200 family processors
by Scott C. Karlin 23 Aug '00

23 Aug '00

Can anyone tell me what the PCI interface on future IXP1200 processors are likely look like? (Without disclosing confidential information, of course.) Specifically, I'm curious to know if we might see a sustained rate of 400 MB/s from the PCI bus (or PCIX) to the SDRAM on a next generation IXP1200 (say, within 6 to 12 months). To do this, the IXP1200 would need either a full blown 64-bit/66 MHz PCI bus or a PCIX bus. -Scott

1 0

RE: IXP clock rate question
by Perry Wagle 20 Jul '00

20 Jul '00

My cover letters (with "A14985-001" at the bottom) don't state this. > I found it. The note about 176 MHz is on a single sheet of paper > with Intel letterhead that came with the system. It simply listed > what came with the Evaluation System plus the note Susan quotes. >> "Also note, the IXP1200 Network Processor on this evaluation system runs at >> a core frequency of 176 MHz. This temporary condition is due to a lack of >> component availability used to design the evaluation board." ------------------------------------------------------------------------------ Also, out of curiosity, what value in hex does my "mmu_id_chip" routine return on your systems? -- Perry

1 0

RE: IXP clock rate question
by Scott C. Karlin 20 Jul '00

20 Jul '00

I found it. The note about 176 MHz is on a single sheet of paper with Intel letterhead that came with the system. It simply listed what came with the Evaluation System plus the note Susan quotes. -Scott Perry Wagle writes: > > Susan Yost writes: > > You have Evaluation Systems based on the A-3 step of the IXP1200 Network > > Processor. Buried at the bottom of the cover letter included with your > > systems is the following: > > > > "Also note, the IXP1200 Network Processor on this evaluation system runs at > > a core frequency of 176 MHz. This temporary condition is due to a lack of > > component availability used to design the evaluation board." > > > > Intel officially supports 166 MHz and now 200 MHz versions of the IXP1200. > > Our first version of the Evaluation System run at 176 MHz as indicated > > above. > > > > Susan Yost > > IXP1200 Tech Marketing > > I don't find the "core frequency of 176" in the printed documentation > that came with the systems, though now that you mention it, I seem to > remember reading that line somewhere. Could you be more specific > about its location? (I'm hoping to find other important information > there.) -------------------------------------------------------------------------- Scott C. Karlin Princeton University Graduate Student Department of Computer Science Voice: (609) 258-5386 35 Olden Street Email: scott(a)cs.princeton.edu Princeton, NJ 08544-2087 WWW: http://www.cs.princeton.edu/~scott --------------------------------------------------------------------------

1 0

RE: IXP clock rate question
by Perry Wagle 20 Jul '00

20 Jul '00

> You have Evaluation Systems based on the A-3 step of the IXP1200 Network > Processor. Buried at the bottom of the cover letter included with your > systems is the following: > > "Also note, the IXP1200 Network Processor on this evaluation system runs at > a core frequency of 176 MHz. This temporary condition is due to a lack of > component availability used to design the evaluation board." > > Intel officially supports 166 MHz and now 200 MHz versions of the IXP1200. > Our first version of the Evaluation System run at 176 MHz as indicated > above. > > Susan Yost > IXP1200 Tech Marketing I don't find the "core frequency of 176" in the printed documentation that came with the systems, though now that you mention it, I seem to remember reading that line somewhere. Could you be more specific about its location? (I'm hoping to find other important information there.) ----------------------------------------------------------------------------- My routine queries the MMU for its "ID_CHIP" function: static inline int mmu_id_chip (void) { register int x ; __asm__ __volatile__ ( "mrc 15, 0, %0, c0, c0, 0" : "=r" (x)) ; return x ; } and returns: mmu_id_chip 6901c120 which translates to [IMP]lementer = 0x69 (the documentated constant) [ARCH]itecture version = 0x01 (the documentated constant) [P]art [N]umber = 0xc12 (the documented constant for IXP1200) [REV]ision number = 0x0 I think our other system (which is currently dead) showed a higher revision number. The working system has a revision number of zero, which I'm of the impression is a earlier rev that A-3? Unlike the dead system, this board had come in a unsealed bag with no plugs for the gigabit ports, so might have been "previously owned". Do we have a revision mismatch from what we are supposed to have? ----------------------------------------------------------------------------- If my fast_clock is running at 176 MHz, what is my slow clock running at? The documentation for the PLL_CFG register on page 28 of the "IXP1200 Network Processor Specification Update (June 2000)" specifies that bits 4:0 being equal to 0x10 means 162.20 MHz if my slow_clock frequency is 3.6864 MHz. The ratio of these two constants is just about correct, given the relative frequency of interrupts generated by timers based on them. If you are telling me that my fast_clock is really running at 176Mhz, then what is my slow clock running at then? Or are you telling me that I should set bits 4:0 of the PLL_CFG register to 0x11 to make it run at 176.95Mhz as the documentation indicates? In either case, is it possible to get the exact values of both the slow_clock and the fast_clock? (down to the unit Hz) Thanks! -- Perry

1 0

RE: IXP clock rate question
by Yost, Susan 20 Jul '00

20 Jul '00

Hi All, You have Evaluation Systems based on the A-3 step of the IXP1200 Network Processor. Buried at the bottom of the cover letter included with your systems is the following: "Also note, the IXP1200 Network Processor on this evaluation system runs at a core frequency of 176 MHz. This temporary condition is due to a lack of component availability used to design the evaluation board." Intel officially supports 166 MHz and now 200 MHz versions of the IXP1200. Our first version of the Evaluation System run at 176 MHz as indicated above. Susan Yost IXP1200 Tech Marketing -----Original Message----- From: Tammo Spalink [mailto:tspalink@CS.Princeton.EDU] Sent: Thursday, July 20, 2000 3:58 PM To: Perry Wagle Cc: ixp1200(a)CS.Princeton.EDU Subject: Re: IXP clock rate question Don't really know what rev board we have. I think it's an A-somthing. Our numbers might not need to be the same, however, since I am timing the microengine cycle speed and not the StrongARM. Tammo On Thu, 20 Jul 2000, Perry Wagle wrote: > > Measurements with the microengine cycle counters suggest that the > > clock speed of our system is 177MHz as opposed to the manual's claim > > of 166MHz. > > > > Does this sound accurate? > > I'm including my own observations in my answer to your question: > > I'm loading my boot loader from angel on a rev A board. I have the > RTC firing an interrupt "once a second", and TIMER_1 firing "a hundred > times a second". Angel has set the PLL_CFG register to (my debugging > routine dumps "label address value"): > > pll_cfg 90000c00 00000010 > > which I've assumed to be "correct", so haven't tried changing it, > especially since the documentation warns againts setting it too high. > > The RTC uses what I call the "slow clock" (~ 3 MHz), and the TIMER's > use what I call the "fast clock" (~ 162 Mhz). > > To initialize the RTC calibration, I set the RTC_DIV register to my > slow_clock (expressed in Hz) divided by 128, and currently get: > > rtc_div 90002000 00037080 > > (so RDIV = 0x7080) and to initialized the TIMER_1 calibration, I set > the TIMER_1_LOAD register to the my fast_clock (expressed in Hz) > divided by 100, and currently get: > > timer_1_load 42000300 0018bff0 > timer_1_control 42000308 000000c0 > > (notice that the value of timer_1_control shows that I am counting CPU > cycles without a divisor). > > With my slow_clock constant set to 3686400 Hz and my fast_clock > constant set to 162200000, I am getting approximately 100.15 TIMER_1 > interrupts per RTC interrupt (over a 12 hour period). These two > values correspond to the ROUNDED values of the two clock rates from > page 28 of the "IXP1200 Network Processor Specification Update (June > 2000)". The roundoff is SIGNIFICANT to my measurement, and I wish the > documentation writers WOULDN'T ROUND OFF THE VALUES. For example, > since the given value of the fast_clock was almost exactly 44 times > the given value of the slow_clock, I tried just setting the fast_clock > to exactly 44 times the slow clock, and got 100.5 TIMER_1 interrupts > per second. BOTH values of the fast_clock were within the roundoff of > the value given in the documentation. > > My setting of the slow_clock is consistant with the documentation's > suggestion, and the seconds doesn't skew according to my eyeball's > comparison with my wristwatch. It's close enough that I'm not going > to worry more about it more until I have Linux running XNTP. > > So my answer to your original question is that I'm somewhat confident > that I have the Core Clock measured at about 162 MHz (+- 1 Mhz), at > least with respect to the RTC and TIMER_1 hardware on Rev A hardware. > Which Rev do you guys have? > > -- Perry >

1 0