- ixp1200 - lists.cs.princeton.edu

RE: [ixp1200] Re: submission to IXA Special Initiative
by Yavatkar, Raj 30 May '01

30 May '01

we are looking into it. please stay tuned Raj -----Original Message----- From: Kenneth M. Mackenzie [mailto:kenmac@cc.gatech.edu] Sent: Wednesday, May 30, 2001 6:20 AM To: ixp1200(a)CS.Princeton.EDU Subject: [ixp1200] Re: submission to IXA Special Initiative Hi, Version 2.0 of the IXA SDK appears to offer additional integration for linux on the strongarm. Is it possible to become a beta site for this software? We've been using linux on our IXP1200 but before we start building more infrastructure we'd like to see what may already have been done. thanks, -- Ken

1 0

Re: submission to IXA Special Initiative
by Hilarie Orman 30 May '01

30 May '01

Has Intel gotten back to you on this? I'm also interested. Hilarie >>> kenmac(a)cc.gatech.edu 05/30/01 07:19AM >>> Hi, Version 2.0 of the IXA SDK appears to offer additional integration for linux on the strongarm. Is it possible to become a beta site for this software? We've been using linux on our IXP1200 but before we start building more infrastructure we'd like to see what may already have been done. thanks, -- Ken

1 0

Re: submission to IXA Special Initiative
by Kenneth M. Mackenzie 30 May '01

30 May '01

Hi, Version 2.0 of the IXA SDK appears to offer additional integration for linux on the strongarm. Is it possible to become a beta site for this software? We've been using linux on our IXP1200 but before we start building more infrastructure we'd like to see what may already have been done. thanks, -- Ken

1 0

RE: [ixp1200] GigaMAC diagnostic problems...
by Heaton, Eric D 24 May '01

24 May '01

This would probably be helpful. ;) The patch is available from the web at: http://developer.intel.com/design/network/products/software/swsup/SDK_v1-2_p atch.htm Eric Heaton Technical Marketing Engineer Intel Corporation - PNPO phone: 978-568-6027 -----Original Message----- From: Heaton, Eric D [mailto:eric.d.heaton@intel.com] Sent: Thursday, May 24, 2001 10:59 AM To: 'ixp1200(a)CS.Princeton.EDU' Subject: RE: [ixp1200] GigaMAC diagnostic problems... Austen, Yes, there was a problem with a rev of the diagnostics with causes the gigabit port tests to fail. The latest patch for v1.2 (which upgrades the software to 1.2D.76) fixes this problem. Eric Heaton Technical Marketing Engineer Intel Corporation - PNPO phone: 978-568-6027 -----Original Message----- From: Austen McDonald [mailto:austen@cc.gatech.edu] Sent: Wednesday, May 23, 2001 4:29 PM To: 'ixp1200(a)CS.Princeton.EDU' Subject: RE: [ixp1200] GigaMAC diagnostic problems... Im talking about the diagnostics test from Intel---it comes w/ the system. Unless you've removed the diagnostics from the flashROM you should be able to set jumpers 12 & 26 both to 2-3 and restart it. But, if you really want the microcode, its in the BoardSupport/Diagnostics directory of the installation. Austen McDonald austen(a)cc.gatech.edu God does not care about our mathematical difficulties. He integrates empirically. -- Albert Einstein On Wed, 23 May 2001, Brandewie, Dirk J wrote: > What microcode are you running to run this test? I will > try to reproduce the problem here. > > --Dirk > > > -----Original Message----- > > From: Austen McDonald [mailto:austen@cc.gatech.edu] > > Sent: Wednesday, May 23, 2001 11:22 AM > > To: ixp1200(a)CS.Princeton.EDU > > Subject: [ixp1200] GigaMAC diagnostic problems... > > > > > > > > Has anyone tried to use the diagnostics w/ the GigaMACs---we set > > it up and both internal and external loopback modes fail. We > > have the MAC > > enabled w/ jumper J34 and we get the status lights on both > > the ports when > > we loop a cable between them but the IXbus tx/rx tests fail---the > > microcode should send packets and recv them but it doesn't. > > I'm wondering if this is a hardware problem or a diagnostic > > program problem. I think it is the latter because if I run my own > > diagnostic program, I can get the GigaMAC's receive counter > > to increase > > when I send it packets (even though it doesnt appear to > > assert the rxrdy > > flag when the IX bus polls it). > > Any guidance? > > > > Austen McDonald > > austen(a)cc.gatech.edu > > > > God does not care about our mathematical difficulties. > > He integrates empirically. > > -- Albert Einstein > > > > > >

1 0

RE: [ixp1200] GigaMAC diagnostic problems...
by Heaton, Eric D 24 May '01

24 May '01

Austen, Yes, there was a problem with a rev of the diagnostics with causes the gigabit port tests to fail. The latest patch for v1.2 (which upgrades the software to 1.2D.76) fixes this problem. Eric Heaton Technical Marketing Engineer Intel Corporation - PNPO phone: 978-568-6027 -----Original Message----- From: Austen McDonald [mailto:austen@cc.gatech.edu] Sent: Wednesday, May 23, 2001 4:29 PM To: 'ixp1200(a)CS.Princeton.EDU' Subject: RE: [ixp1200] GigaMAC diagnostic problems... Im talking about the diagnostics test from Intel---it comes w/ the system. Unless you've removed the diagnostics from the flashROM you should be able to set jumpers 12 & 26 both to 2-3 and restart it. But, if you really want the microcode, its in the BoardSupport/Diagnostics directory of the installation. Austen McDonald austen(a)cc.gatech.edu God does not care about our mathematical difficulties. He integrates empirically. -- Albert Einstein On Wed, 23 May 2001, Brandewie, Dirk J wrote: > What microcode are you running to run this test? I will > try to reproduce the problem here. > > --Dirk > > > -----Original Message----- > > From: Austen McDonald [mailto:austen@cc.gatech.edu] > > Sent: Wednesday, May 23, 2001 11:22 AM > > To: ixp1200(a)CS.Princeton.EDU > > Subject: [ixp1200] GigaMAC diagnostic problems... > > > > > > > > Has anyone tried to use the diagnostics w/ the GigaMACs---we set > > it up and both internal and external loopback modes fail. We > > have the MAC > > enabled w/ jumper J34 and we get the status lights on both > > the ports when > > we loop a cable between them but the IXbus tx/rx tests fail---the > > microcode should send packets and recv them but it doesn't. > > I'm wondering if this is a hardware problem or a diagnostic > > program problem. I think it is the latter because if I run my own > > diagnostic program, I can get the GigaMAC's receive counter > > to increase > > when I send it packets (even though it doesnt appear to > > assert the rxrdy > > flag when the IX bus polls it). > > Any guidance? > > > > Austen McDonald > > austen(a)cc.gatech.edu > > > > God does not care about our mathematical difficulties. > > He integrates empirically. > > -- Albert Einstein > > > > > >

1 0

RE: [ixp1200] GigaMAC diagnostic problems...
by Brandewie, Dirk J 23 May '01

23 May '01

What microcode are you running to run this test? I will try to reproduce the problem here. --Dirk > -----Original Message----- > From: Austen McDonald [mailto:austen@cc.gatech.edu] > Sent: Wednesday, May 23, 2001 11:22 AM > To: ixp1200(a)CS.Princeton.EDU > Subject: [ixp1200] GigaMAC diagnostic problems... > > > > Has anyone tried to use the diagnostics w/ the GigaMACs---we set > it up and both internal and external loopback modes fail. We > have the MAC > enabled w/ jumper J34 and we get the status lights on both > the ports when > we loop a cable between them but the IXbus tx/rx tests fail---the > microcode should send packets and recv them but it doesn't. > I'm wondering if this is a hardware problem or a diagnostic > program problem. I think it is the latter because if I run my own > diagnostic program, I can get the GigaMAC's receive counter > to increase > when I send it packets (even though it doesnt appear to > assert the rxrdy > flag when the IX bus polls it). > Any guidance? > > Austen McDonald > austen(a)cc.gatech.edu > > God does not care about our mathematical difficulties. > He integrates empirically. > -- Albert Einstein > >

2 1

GigaMAC diagnostic problems...
by Austen McDonald 23 May '01

23 May '01

Has anyone tried to use the diagnostics w/ the GigaMACs---we set it up and both internal and external loopback modes fail. We have the MAC enabled w/ jumper J34 and we get the status lights on both the ports when we loop a cable between them but the IXbus tx/rx tests fail---the microcode should send packets and recv them but it doesn't. I'm wondering if this is a hardware problem or a diagnostic program problem. I think it is the latter because if I run my own diagnostic program, I can get the GigaMAC's receive counter to increase when I send it packets (even though it doesnt appear to assert the rxrdy flag when the IX bus polls it). Any guidance? Austen McDonald austen(a)cc.gatech.edu God does not care about our mathematical difficulties. He integrates empirically. -- Albert Einstein

1 0

Archives
by Lukas Ruf 09 May '01

09 May '01

Dear all, being new to this list, I would like to kindly ask you where I can find an archive of the discussion that went on. Thanks in advance, Lukas -- Lukas Ruf Swiss Federal Institute of Technology Office: ETZ-G61.2 Computer Engineering and Phone: +41/1/632 7312 Networks Laboratory (TIK) Fax: +41/1/632 1035 ETH Zentrum PGP 2.6: ID D20BA2ED; Gloriastr. 35 Fingerprint 6323 B9BC 9C8E 6563 B477 BADD FEA6 E6B7 CH-8092 Zurich

2 1

RE: [ixp1200] Question about the Linux kernel and the FBI RDYBUS registers.
by Raghunandan, Makaram 04 May '01

04 May '01

This and several other FBI registers are WRITE only - so you can write to them but cannot read the value back. The Programmer's Ref. Manual indicates them as WRITE only. -----Original Message----- From: Didier CONTIS [mailto:didier@ece.gatech.edu] Sent: Friday, May 04, 2001 4:16 PM To: IXP1200(a)CS.Princeton.EDU Subject: [ixp1200] Question about the Linux kernel and the FBI RDYBUS registers. -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, I am observing a weird behavior when trying to read / write some registers from the Linux kernel running on the StrongARM. Basically, it seems I can write some registers like IREG without any problem from the StrongARM. However it seems I cannot with RDYBUS_TEMPLATE_CTL. However both registers are described in the doc as being r/w accessible by the StrongARM. Below is the output of my program. I am using the following definition for RDYBUS_TEMPLATE_CTL (IREG being already defined in the includes files): #define MY_RDYBUS_TEMPLATE_CTL IXP1200_REG(MICROENGINE_FBI_BASE+0x40180) [root@thing1 Didier]$./set_rcv Initial value of RDYBUS_TEMPLATE_CTL Register: 0 Initial value of IREG Register: 0 Address of RDYBUS_TEMPLATE_CTL Register: f0640180 Address of IREG Register: f06401e0 New value of RDYBUS_TEMPLATE_CTL Register: 0 New value of IREG Register: 80000000 Thanks in advance for any help. Regards, Didier. -----BEGIN PGP SIGNATURE----- Version: PGPfreeware 6.5.3 for non-commercial use <http://www.pgp.com> iQA/AwUBOvMOAHqEbTtUcuwQEQIARACeIhs42jMRRCCpV/1n4zKktqZenyQAoKKp 1KiT9hDkijWgnLVYRmz1B/g4 =sb4r -----END PGP SIGNATURE-----

2 1

Question about the Linux kernel and the FBI RDYBUS registers.
by Didier CONTIS 04 May '01

04 May '01

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, I am observing a weird behavior when trying to read / write some registers from the Linux kernel running on the StrongARM. Basically, it seems I can write some registers like IREG without any problem from the StrongARM. However it seems I cannot with RDYBUS_TEMPLATE_CTL. However both registers are described in the doc as being r/w accessible by the StrongARM. Below is the output of my program. I am using the following definition for RDYBUS_TEMPLATE_CTL (IREG being already defined in the includes files): #define MY_RDYBUS_TEMPLATE_CTL IXP1200_REG(MICROENGINE_FBI_BASE+0x40180) [root@thing1 Didier]$./set_rcv Initial value of RDYBUS_TEMPLATE_CTL Register: 0 Initial value of IREG Register: 0 Address of RDYBUS_TEMPLATE_CTL Register: f0640180 Address of IREG Register: f06401e0 New value of RDYBUS_TEMPLATE_CTL Register: 0 New value of IREG Register: 80000000 Thanks in advance for any help. Regards, Didier. -----BEGIN PGP SIGNATURE----- Version: PGPfreeware 6.5.3 for non-commercial use <http://www.pgp.com> iQA/AwUBOvMOAHqEbTtUcuwQEQIARACeIhs42jMRRCCpV/1n4zKktqZenyQAoKKp 1KiT9hDkijWgnLVYRmz1B/g4 =sb4r -----END PGP SIGNATURE-----

1 0

RE: [ixp1200] Problem in microcode optimizer
by Raghunandan, Makaram 01 May '01

01 May '01

Hi Eric You should also post this to the internal mailing group so that all the internal folks will also know about these features... -----Original Message----- From: Heaton, Eric D [mailto:eric.d.heaton@intel.com] Sent: Monday, April 30, 2001 6:57 PM To: 'ixp1200(a)CS.Princeton.EDU' Subject: RE: [ixp1200] Problem in microcode optimizer All, This assembler bug is documented in the uca_rel_notes.txt file and in the Release Notes (found in the IXA SDK installation), as well as one additional: o) The optimizer has the following defects: 1. The optimizer will illegally place a P1 stage ctx_arb immediately after a P3 stage branch. 2. The optimizer will incorrectly move +ifsign and +carry ALU operations, changing the instructions from which they get the condition codes. One more <undocumented> optimizer bug concerns using it with the find_bset instruction and indirect shifting: alu[--, shift, b, tmpa] find_bset[search_reg, >>indirect] That is, the optimizer will move the alu statement used as the indirect shift value incorrectly somewhere below the find_bset instruction. Also note that the optimizer does not support is not currently supported for multiple segments (i.e. across the 2k control store), but will be in a future release. Be sure to keep these in mind when using the optimizer in the assembler! Eric Heaton Technical Marketing Engineer Intel Corporation -----Original Message----- From: Alok Kumar [mailto:alok@cs.utexas.edu] Sent: Monday, April 30, 2001 6:28 PM To: ixp1200(a)CS.Princeton.EDU Subject: [ixp1200] Problem in microcode optimizer Hello Everyone, I found a problem in microcode optimizer in the Developer Workbench, so I thought to send it through in the mailing list so that you can turn off the code optimizer is your optomized code has similar problem. The problem is when we use "alu" instruction with operation "+ifsign". Probably, optimizer does not account for the fact the resulf of alu with +ifsign depends on the condition code. For example the following code is optimized incorrectly .local num den res diff alu[num, num, -, den] ; instr 1 alu[--,--, B, num] ; instr 2 alu[res, 1, +IFSIGN, res, <<1] ; instr 3 alu[num, den, +IFSIGN, num] ; instr 4 alu[den, --, B, den, >>1] ; instr 5 alu[diff, diff, -, 1] ; instr 6 br<0[header_stored#] ; instr 7 .endlocal The optimizer expands it as: .local num den res diff alu[l000!num, l000!num, -, l000!den] ; instr 1 alu[--,--, b, l000!num] ; instr 2 alu_shf[l000!res, 1, +ifsign, l000!res, <<1] ; instr 3 alu_shf[l000!diff, l000!diff, -, 1, 0] ; instr 6 br<0[header_stored#], ; instr 7 defer[2] ; BRANCH LATENCY FILL OPTIMIZATION: the uword below was "pushed" down 2 positions alu[l000!num, l000!den, +ifsign, l000!num] ; instr 4 ; BRANCH LATENCY FILL OPTIMIZATION: the uword below was "pushed" down 2 positions alu_shf[l000!den, --, b, l000!den, >>1] ; instr 5 .endlocal Here semantics of instr 4 changes in optimized code and it works on condition code set by instr 6 instead of condition code set by instr 2 as it should. Using +carry in alu instruction also has similar problem. I think optimizer assumes that alu instruction does not depend on any condition codes. Please, turn off optimizer if you are using +ifsing or +carry. 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: [ixp1200] Problem in microcode optimizer
by Heaton, Eric D 30 Apr '01

30 Apr '01

All, This assembler bug is documented in the uca_rel_notes.txt file and in the Release Notes (found in the IXA SDK installation), as well as one additional: o) The optimizer has the following defects: 1. The optimizer will illegally place a P1 stage ctx_arb immediately after a P3 stage branch. 2. The optimizer will incorrectly move +ifsign and +carry ALU operations, changing the instructions from which they get the condition codes. One more <undocumented> optimizer bug concerns using it with the find_bset instruction and indirect shifting: alu[--, shift, b, tmpa] find_bset[search_reg, >>indirect] That is, the optimizer will move the alu statement used as the indirect shift value incorrectly somewhere below the find_bset instruction. Also note that the optimizer does not support is not currently supported for multiple segments (i.e. across the 2k control store), but will be in a future release. Be sure to keep these in mind when using the optimizer in the assembler! Eric Heaton Technical Marketing Engineer Intel Corporation -----Original Message----- From: Alok Kumar [mailto:alok@cs.utexas.edu] Sent: Monday, April 30, 2001 6:28 PM To: ixp1200(a)CS.Princeton.EDU Subject: [ixp1200] Problem in microcode optimizer Hello Everyone, I found a problem in microcode optimizer in the Developer Workbench, so I thought to send it through in the mailing list so that you can turn off the code optimizer is your optomized code has similar problem. The problem is when we use "alu" instruction with operation "+ifsign". Probably, optimizer does not account for the fact the resulf of alu with +ifsign depends on the condition code. For example the following code is optimized incorrectly .local num den res diff alu[num, num, -, den] ; instr 1 alu[--,--, B, num] ; instr 2 alu[res, 1, +IFSIGN, res, <<1] ; instr 3 alu[num, den, +IFSIGN, num] ; instr 4 alu[den, --, B, den, >>1] ; instr 5 alu[diff, diff, -, 1] ; instr 6 br<0[header_stored#] ; instr 7 .endlocal The optimizer expands it as: .local num den res diff alu[l000!num, l000!num, -, l000!den] ; instr 1 alu[--,--, b, l000!num] ; instr 2 alu_shf[l000!res, 1, +ifsign, l000!res, <<1] ; instr 3 alu_shf[l000!diff, l000!diff, -, 1, 0] ; instr 6 br<0[header_stored#], ; instr 7 defer[2] ; BRANCH LATENCY FILL OPTIMIZATION: the uword below was "pushed" down 2 positions alu[l000!num, l000!den, +ifsign, l000!num] ; instr 4 ; BRANCH LATENCY FILL OPTIMIZATION: the uword below was "pushed" down 2 positions alu_shf[l000!den, --, b, l000!den, >>1] ; instr 5 .endlocal Here semantics of instr 4 changes in optimized code and it works on condition code set by instr 6 instead of condition code set by instr 2 as it should. Using +carry in alu instruction also has similar problem. I think optimizer assumes that alu instruction does not depend on any condition codes. Please, turn off optimizer if you are using +ifsing or +carry. 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

Problem in microcode optimizer
by Alok Kumar 30 Apr '01

30 Apr '01

Hello Everyone, I found a problem in microcode optimizer in the Developer Workbench, so I thought to send it through in the mailing list so that you can turn off the code optimizer is your optomized code has similar problem. The problem is when we use "alu" instruction with operation "+ifsign". Probably, optimizer does not account for the fact the resulf of alu with +ifsign depends on the condition code. For example the following code is optimized incorrectly .local num den res diff alu[num, num, -, den] ; instr 1 alu[--,--, B, num] ; instr 2 alu[res, 1, +IFSIGN, res, <<1] ; instr 3 alu[num, den, +IFSIGN, num] ; instr 4 alu[den, --, B, den, >>1] ; instr 5 alu[diff, diff, -, 1] ; instr 6 br<0[header_stored#] ; instr 7 .endlocal The optimizer expands it as: .local num den res diff alu[l000!num, l000!num, -, l000!den] ; instr 1 alu[--,--, b, l000!num] ; instr 2 alu_shf[l000!res, 1, +ifsign, l000!res, <<1] ; instr 3 alu_shf[l000!diff, l000!diff, -, 1, 0] ; instr 6 br<0[header_stored#], ; instr 7 defer[2] ; BRANCH LATENCY FILL OPTIMIZATION: the uword below was "pushed" down 2 positions alu[l000!num, l000!den, +ifsign, l000!num] ; instr 4 ; BRANCH LATENCY FILL OPTIMIZATION: the uword below was "pushed" down 2 positions alu_shf[l000!den, --, b, l000!den, >>1] ; instr 5 .endlocal Here semantics of instr 4 changes in optimized code and it works on condition code set by instr 6 instead of condition code set by instr 2 as it should. Using +carry in alu instruction also has similar problem. I think optimizer assumes that alu instruction does not depend on any condition codes. Please, turn off optimizer if you are using +ifsing or +carry. 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: Princeton IXP1200 SA Environment
by Scott C. Karlin 29 Apr '01

29 Apr '01

Taroon Mandhana writes: > > On Fri, 13 Apr 2001, Scott C. Karlin wrote: > > > > Hal Rosenstock writes: > > > > > > In the Princeton work with the IXP1200, what environment runs in the > > > StrongArm of the IXP1200 ? Is it vxWorks ? > > > > We run our own code on the StrongARM. We temporarily remove > > the flash memory from the evaluation board (it is socketed), > > and use an external device programmer to get our firmware > > into the device. > > > > The code sets up the board to act as a PCI peripheral so that > > we can plug it into a standard PC. The firmware implements a > > simple protocol which allows the host CPU to download StrongARM > > code to the IXP1200 evaluation board over the PCI bus. We run > > Linux on the Pentium and have our own device driver which > > interacts with the board. > > > > We run an unmodified GCC configured as a cross-compiler to > > compile the StrongARM code. > > Are you running your own OS on strongarm. Or are you running > VxWorks or Linux ? We run our own OS. The OS is currently a library of support routines which are linked with the application to form an executable. Scott

2 1

Princeton IXP1200 SA Environment
by Hal Rosenstock 13 Apr '01

13 Apr '01

Hi, I'm new to the mailing list so you'll have to excuse me for asking a newbee question. In the Princeton work with the IXP1200, what environment runs in the StrongArm of the IXP1200 ? Is it vxWorks ? Thanks. -- Hal Rosenstock

2 1

updated admin info
by Scott C. Karlin 12 Apr '01

12 Apr '01

I have updated the "info" file for the mailing list (see below). The main change to note is that the postings will now have their "reply_to" field set to the list rather than the sender. Scott OVERVIEW -------- The purpose of this list is to facilitate discussion on the topic of the IXP1200 Network Processor including its Ethernet Evaluation System. POSTING MESSAGES ---------------- To send mail to the people on the list, send your ASCII message (not HTML) to ixp1200(a)cs.princeton.edu Note that this list has been setup so that replies go to the entire list. This is to encourage discussion on the list. GUIDELINES ---------- While informative announcements of products or services that benefit most subscribers are allowed, blatant advertising is not. Please do not clutter the archive with HTML messages or attachments. Use plain ASCII text only. (Place code, papers, etc., on a WWW or FTP site and provide a URL reference instead.) UNSUBSCRIBING ------------- See "unsubscribe" in the COMMANDS section below. ARCHIVE ------- All postings to this list are archived by month into files having extensions which represent the year and month of the archives. See "index" and "get" in the COMMANDS section below for access. COMMANDS -------- Majordomo handles the ixp1200 mailing list. To "execute" a command, send mail to majordomo(a)cs.princeton.edu (NOT ixp1200(a)cs.princeton.edu) Include the command in the *body* of the message (the subject line is ignored and may be blank). Commands include: unsubscribe ixp1200 remove yourself from this list index ixp1200 get a list of available archive files get ixp1200 <filename> retrieve an archive file. info ixp1200 get the most current version of this message (works only if you are on the list) who ixp1200 get a list of subscribers to the list (works only if you are on the list) subscribe ixp1200 request to be added to this list (must be approved by the list admin) help general help from Majordomo ADMINSTRATOR ------------ If you have administrative questions or comments about the list, send them to ixp1200-request(a)cs.princeton.edu LAST UPDATED ------------ April 12, 2001

1 0

IXE - IXP interconnect
by Ganesh Narayan Swamy 28 Mar '01

28 Mar '01

hello, is there way of connecting IXP and IXE (5418)? i understand that IXE line of products export a PCI interface to connect a CPU. but, i want to connect an IXP with one or more IXE throu' a high speed interface(like the IX bus interrconnect exported by IX3208 to connect IXP's). any such 'glue' technology does exist in IXA? i would greatly appreciate any help this regard.. :-) thank you.. regards Ganesh.N

1 1

Initialization of the MACs...
by Austen McDonald 16 Mar '01

16 Mar '01

We are GT are running Linux and don't think that the MACs are being properly initialized. We've looked at the Diagnostics code (the ARM assembly) and we know that the MACs are in the slow port area of SRAM and we know the offsets of the registers we need to access. But, our code doesn't work. Here's what Im doing: #include <asm/arch/hardware.h> #include <asm/arch/xp1200eb.h> #include <stdio.h> int main(int argc, char** argv) { unsigned char* mac0 = (unsigned char*)(SRAM_SLOW_PORT_BASE); unsigned char* mac1 = (unsigned char*)(SRAM_SLOW_PORT_BASE+0x8000); printf("%x\n",*(unsigned short*)(mac0+6*4)); return 0; } which should print out the device ID and revision ID from MAC0 (the octal MAC) but it just prints 0s. Is there something I have to do first to be able to read from this SlowPort space? Austen McDonald austen(a)cc.gatech.edu God does not care about our mathematical difficulties. He integrates empirically. -- Albert Einstein

1 0

RE: Hard Reset of IXP1200 over PCI?
by Heaton, Eric D 14 Mar '01

14 Mar '01

Scott, The text you refered to in the Programmer's Reference Manual Section 4.7.13 is actually incorrect. You may indeed write to the IXP1200_RESET register to reset the chip over PCI, as you saw in your experiments. The documentation in the IXP1200 Datasheet Section 5.6.3 has the correct information concerning this issue. Eric Heaton Technical Marketing Engineer Intel Corporation - PNPO -----Original Message----- From: Scott C. Karlin [mailto:scott@CS.Princeton.EDU] Sent: Tuesday, February 20, 2001 10:27 AM To: ixp1200(a)CS.Princeton.EDU Subject: Re: Hard Reset of IXP1200 over PCI? 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

Linux on ixp1200
by Taroon Mandhana 11 Mar '01

11 Mar '01

Hi, I am currently running linux on strongarm. Are there any applications available for this port. I am looking for a route table manager that should run on linux(something similar to Netapp on vxworks). Also, are there some kind of wrappers/library available to access sdram/sram/other functional units from strongarm ? Thanks Taroon Mandhana

1 0

RE: ixp1200 on linux
by Naik, Uday 26 Feb '01

26 Feb '01

When we first ported Linux to the IXP1200, we booted it directly from flash without cygmon. This was fairly restrictive specially since we were making changes all the time to the kernel. Also it limits what you can have on your ramdisk. So we got away from it. But it is possible if that's what you want. You will need to do some work to get there. Uday. -----Original Message----- From: Sprajc, Barry [mailto:barry.sprajc@intel.com] Sent: Monday, February 26, 2001 10:19 AM To: 'Sundar Ramachandran'; IXP1200(a)CS.Princeton.EDU Subject: RE: ixp1200 on linux To the best of my current knowledge, only TFTP is supported by Cygmon as installed in your flash - it probably could support PPP or SLIP, but I don't know for sure, as Cygmon would have to be rebuilt to support a different protocols. One way you could use TFFP is to put a linux box with a TFTP server on your local subnet, as I think TFTP is for local subnets anyways. I don't think it would be accessable by anyone on the other side of your gateway If your school policy is not not run TFTP on the network at all, you could add a second network card to the box with the TFTP server and assign it a private network address like 10.x.x.x or 192.168.x.x, one which isn't used on campus network - and connect them with a cross over cable -- this is what I have done here at work, so I don't have to bother the network admins for a static IP address for the Eval card /barry -----Original Message----- From: Sundar Ramachandran [mailto:ramachan@cse.uta.edu] Sent: Saturday, February 24, 2001 4:34 PM To: IXP1200(a)CS.Princeton.EDU Subject: ixp1200 on linux Hi, I have the ixp toolchain along with the linux kernel image loaded onto the ixp1200 evaluation processor. The one question I had was ,can we use anything other than tftpd to load this onto the eval kit? Does it compulsorily have to be tftpd, since I'm using minicom instead of NT hyperterminal to do this? The problem is that we have some restrictions on campus to use tftp services, so I need alternatives. I'll be happy if someone could give me some specifics, would appreciate it. 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 UTA, Arlington, TX 76019. ============================================================================ ====

1 0

RE: ixp1200 on linux
by Sprajc, Barry 26 Feb '01

26 Feb '01

To the best of my current knowledge, only TFTP is supported by Cygmon as installed in your flash - it probably could support PPP or SLIP, but I don't know for sure, as Cygmon would have to be rebuilt to support a different protocols. One way you could use TFFP is to put a linux box with a TFTP server on your local subnet, as I think TFTP is for local subnets anyways. I don't think it would be accessable by anyone on the other side of your gateway If your school policy is not not run TFTP on the network at all, you could add a second network card to the box with the TFTP server and assign it a private network address like 10.x.x.x or 192.168.x.x, one which isn't used on campus network - and connect them with a cross over cable -- this is what I have done here at work, so I don't have to bother the network admins for a static IP address for the Eval card /barry -----Original Message----- From: Sundar Ramachandran [mailto:ramachan@cse.uta.edu] Sent: Saturday, February 24, 2001 4:34 PM To: IXP1200(a)CS.Princeton.EDU Subject: ixp1200 on linux Hi, I have the ixp toolchain along with the linux kernel image loaded onto the ixp1200 evaluation processor. The one question I had was ,can we use anything other than tftpd to load this onto the eval kit? Does it compulsorily have to be tftpd, since I'm using minicom instead of NT hyperterminal to do this? The problem is that we have some restrictions on campus to use tftp services, so I need alternatives. I'll be happy if someone could give me some specifics, would appreciate it. 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 UTA, Arlington, TX 76019. ============================================================================ ====

1 0

ixp1200 on linux
by Sundar Ramachandran 24 Feb '01

24 Feb '01

Hi, I have the ixp toolchain along with the linux kernel image loaded onto the ixp1200 evaluation processor. The one question I had was ,can we use anything other than tftpd to load this onto the eval kit? Does it compulsorily have to be tftpd, since I'm using minicom instead of NT hyperterminal to do this? The problem is that we have some restrictions on campus to use tftp services, so I need alternatives. I'll be happy if someone could give me some specifics, would appreciate it. 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 UTA, Arlington, TX 76019. ================================================================================

1 0

What is IMP bit of Section Descriptor for IXP1200?
by Scott C. Karlin 22 Feb '01

22 Feb '01

In Section 7.6.5 of the ARM Architecture Reference Manual (the ARM ARM), bit 4 of the First-level section descriptor is described as "implementation defined." Does anyone know what this means for the IXP1200 and the IXP1200 evaluation board firmware? The IXP1200 evaluation board firmware sets the IMP bit to 1 for all mappings. Thanks, Scott

1 0

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

20 Feb '01

Josh, Yes, I am now running the ixp board in a regular PC host. (A Pentium III running Linux.) Since I'm still actively working on the code, I'm not ready to release it just yet. There are still important things to get working before it's ready. For example, I haven't enabled the MMU and caches on the StrongARM yet so I imagine that I'm taking a big performance hit. I used the documentation/PCI_debug.txt from the CD-ROM as a guide and followed steps 1 and 2 to set the jumpers on the board so that it wouldn't attempt to act like a motherboard. (This is important as there is a potential to damage either the ixp board or the motherboard.) For the on-board firmware, I am using a device programmer to burn my own code into the flash EEPROMs. As for when I'd be ready to release the code, I'm not sure. I'm working toward an end-of-March deadline and I expect I'll be giving 3 talks in April. These will be slowing me down. Scott Forwarded message from Josh Fryman: > > Date: Tue, 20 Feb 2001 11:34:08 -0500 > From: Josh Fryman <fryman(a)cc.gatech.edu> > Organization: CoC, GaTech > X-Mailer: Mozilla 4.76 [en] (X11; U; SunOS 5.7 sun4u) > X-Accept-Language: en > To: "Scott C. Karlin" <scott(a)CS.Princeton.EDU> > Subject: Re: Hard Reset of IXP1200 over PCI? > > > Scott, > > Are you running your IXP board in a regular PCI > host (such as a PC), or is it still in an eval box? > Your email suggests you may have it running in a > real PCI host. > > If you have done this, can you share the procedure > you followed to get it working? > > Thanks, > > Josh

1 0