- ixp1200 - lists.cs.princeton.edu

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