April 2004 - ixp1200 - lists.cs.princeton.edu

Help?
by rasit＠cs.umanitoba.ca 29 Apr '04

29 Apr '04

Hi, I need to program the flash (Intel TE28F800 B3BA90) on our IXP1200EB board. Please email me directly for details. Thanks, Rasit -- M. Rasit Eskicioglu E-mail: rasit at cs.umanitoba.ca Department of Computer Science Phone : (204) 474-8835 (Office) 528 Machray Hall (204) 474-8313 (Messages) University of Manitoba Fax : (204) 474-7609 Winnipeg, Manitoba R3T 2N2 Canada URL : http://www.cs.umanitoba.ca/~rasit

1 0

Packet transmitting code
by Mohammad Shorfuzzaman 29 Apr '04

29 Apr '04

Hi all, Did any body try running successfully the packet transmitting code (from chap 9 IXP1200 prog. book) on hardware mode and see any packets transmitted from the ixp port? I tried to run it on IXP and it runs fine and I sent packets to the ixp port but I could not see any packet transmitted. Any help is greatly appreciated. Regards, Mohammad ------------------------------------------------- This mail sent through IMP: http://horde.org/imp/

2 1

RE: [ixp1200] core locks using IXA SDK
by Johnson, Erik J 20 Apr '04

20 Apr '04

Hi Tim Without actually trying it, I suspect you can read from the 0xf5000000 range to issue the read lock. However, that does not guarantee the lock was obtained (see the next 12 lines of code in the same example from the book). For that you will need to poll (and update) the SRAM CSR _without any other process doing the same_. This will require mapping this CSRs physical address into the virtual address space of your application as well as finding some way of making this polling code execute in a system-wide critical section. In the end, you may find that doing this work in the kernel and providing some ioctl/syscall/whatever is easier because of these reasons. erik ~~~~~~~~~~~~~~~~~~~~~~~~ Erik J. Johnson erik.j.johnson(a)intel.com Not speaking for Intel ~~~~~~~~~~~~~~~~~~~~~~~~ -----Original Message----- From: ixp1200-bounces(a)lists.cs.princeton.edu [mailto:ixp1200-bounces@lists.cs.princeton.edu] On Behalf Of Tim Stevens Sent: Tuesday, April 20, 2004 7:35 AM To: IXP1200 Developer's List Subject: RE: [ixp1200] core locks using IXA SDK Thanks David, You are right, I was confusing virtual and physical address space. Meanwhile, I have found the following lines in hardware.h: #define SRAM_READ_LOCK UNSIGNED(0xf5000000) #define SRAM_READ_LOCK_SIZE UNSIGNED(0x00800000) #define SRAM_WRITE_UNLOCK UNSIGNED(0xf5800000) #define SRAM_WRITE_UNLOCK_SIZE UNSIGNED(0x00800000) #define SRAM_CAM_UNLOCK UNSIGNED(0xf6000000) #define SRAM_CAM_UNLOCK_SIZE UNSIGNED(0x00800000) #define SRAM_CLEAR_BITS UNSIGNED(0xf6800000) #define SRAM_CLEAR_BITS_SIZE UNSIGNED(0x00800000) #define SRAM_SET_BITS UNSIGNED(0xf7000000) #define SRAM_SET_BITS_SIZE UNSIGNED(0x00800000) #define SRAM_TEST_CLEAR_BITS UNSIGNED(0xf7800000) #define SRAM_TEST_CLEAR_BITS_SIZE UNSIGNED(0x00800000) #define SRAM_TEST_SET_BITS UNSIGNED(0xf8000000) #define SRAM_TEST_SET_BITS_SIZE UNSIGNED(0x00800000) and the following in board.h: #define SRAM_BASE UNSIGNED(0xf4000000) #define RM_SRAM_BASE SRAM_BASE When an SRAM address is allocated using RmMalloc(...), an address in the 0xf4000000 range is returned (e.g. 0xf400feea). Now I wonder whether it's possible to read from the corresponding 0xf5000000 range (e.g. 0xf500feea) to issue a read-lock. Or would this cause a memory violation, since the malloc allocated memory in the 0xf4000000 range? If this is not possible, how should one use the presented constants in hardware.h? Thanks again. Kind regards, Tim At 15:15 20/04/2004, you wrote: >Hello Tim, > >I hope I have understood your issue correctly: > > > From: Tim Stevens [mailto:tim.stevens@intec.ugent.be] > > Sent: Tuesday, April 20, 2004 2:42 PM > > > Chapter 7 (p 167) of the IXP1200 programming book states that an > > SRAM memory read-lock can be obtained by the following command: > > *(unsigned int *)(SRAM_READ_LOCK + (sramLWAddr << 2)); where > > sramLWAddr is the physical address in longwords and SRAM_READ_LOCK > > is defined as follows: > > #define SRAM_READ_LOCK 0x12000000 > > > > Quite obviously, this results in a memory violation because the > > memory was not previously allocated (in the 0x12000000 range). > >Your are confusing Physical and Virtual addresses. I don't have the >IXP1200 book at hand but as far as I can guess, the 0x12000000 is a >physical one. So you need to open a window, i.e. a virtual address to >physical address translation, from a virtual address range of your user >linux program to the 0x12000000 physical address range. > >The simplest way, in my humble opinion, is to mmap(2) the /dev/mem >device that corresponds to physical address space. You'll find an >example of such a program at: >http://www.lart.tudelft.nl/lartware/port/devmem2.c > > > A related problem we face is that our addresses allocated in SRAM > > (by > > RmMalloc) seem to have a virtual address starting with 0xf400...., > > which does not correspond to the 10000000-->107fffff range presented > > in the "StrongARM Core Memory Map" (appendix C) from the "Microcode > > Programmer's Reference Manual". > >I think that once again your are confusing physical and virtual addresses. > > >Yours, >david >-- >David Mentré <mentre(a)tcl.ite.mee.com> - Research engineer (Ph.D.) >Mitsubishi Electric ITE-TCL / European Telecommunication Research Lab >Phone: +33 2 23 45 58 29 / Fax: +33 2 23 45 58 59 >http://www.mitsubishi-electric-itce.fr >_______________________________________________ >ixp1200 mailing list >ixp1200(a)lists.cs.princeton.edu >https://lists.cs.princeton.edu/mailman/listinfo/ixp1200 _______________________________________________ ixp1200 mailing list ixp1200(a)lists.cs.princeton.edu https://lists.cs.princeton.edu/mailman/listinfo/ixp1200

1 0

RE: [ixp1200] Problem running packet transmitting code
by Kunze, Aaron 20 Apr '04

20 Apr '04

Shorfuzzaman, Hello! There is an errata concerning this issue on the web site for the book. Here is a link to the errata web page: http://www.intel.com/intelpress/ixp1200/errata.htm Sorry for the trouble! A ------------------------------ Aaron Kunze Intel Research and Development aaron.kunze(a)intel.com ----PGP Key ID: 0x81124B7C---- ----NOT SPEAKING FOR INTEL---- ---------GO BOILERS!!--------- > -----Original Message----- > From: ixp1200-bounces(a)lists.cs.princeton.edu > [mailto:ixp1200-bounces@lists.cs.princeton.edu] On Behalf Of > Mohammad Shorfuzzaman > Sent: Tuesday, April 20, 2004 5:00 AM > To: ixp1200(a)lists.cs.princeton.edu > Subject: [ixp1200] Problem running packet transmitting code > > > Hi everybody, > I tried to run the packet transmittng code (Chap 9) from > IXP1200 programming > book. In function "bridging.c", hashIO_t has structure like: > > typedef struct { > unsigned int hash_lo32; > unsigned int hash_hi16 : 16; > unsigned int pad : 16; > } hashIO_t; > If I compile the code, it gives an error regarding > "hash_hi16: 16" field: > "error : intrinsic data buffer "hashInput_103$1$0" cannot be read" > > But if I remove specifying the number of bits I mean only > "unsigned int > hash_hi16" it compiles fine, though logically it's not correct. > > Any help why it's happenning and how can I solve the problem? > > Thanks, > Shorfuzzaman. > > > ------------------------------------------------- > This mail sent through IMP: http://horde.org/imp/ > _______________________________________________ > ixp1200 mailing list > ixp1200(a)lists.cs.princeton.edu > https://lists.cs.princeton.edu/mailman/listinfo/ixp1200 >

1 0

RE: [ixp1200] core locks using IXA SDK
by Tim Stevens 20 Apr '04

20 Apr '04

Thanks David, You are right, I was confusing virtual and physical address space. Meanwhile, I have found the following lines in hardware.h: #define SRAM_READ_LOCK UNSIGNED(0xf5000000) #define SRAM_READ_LOCK_SIZE UNSIGNED(0x00800000) #define SRAM_WRITE_UNLOCK UNSIGNED(0xf5800000) #define SRAM_WRITE_UNLOCK_SIZE UNSIGNED(0x00800000) #define SRAM_CAM_UNLOCK UNSIGNED(0xf6000000) #define SRAM_CAM_UNLOCK_SIZE UNSIGNED(0x00800000) #define SRAM_CLEAR_BITS UNSIGNED(0xf6800000) #define SRAM_CLEAR_BITS_SIZE UNSIGNED(0x00800000) #define SRAM_SET_BITS UNSIGNED(0xf7000000) #define SRAM_SET_BITS_SIZE UNSIGNED(0x00800000) #define SRAM_TEST_CLEAR_BITS UNSIGNED(0xf7800000) #define SRAM_TEST_CLEAR_BITS_SIZE UNSIGNED(0x00800000) #define SRAM_TEST_SET_BITS UNSIGNED(0xf8000000) #define SRAM_TEST_SET_BITS_SIZE UNSIGNED(0x00800000) and the following in board.h: #define SRAM_BASE UNSIGNED(0xf4000000) #define RM_SRAM_BASE SRAM_BASE When an SRAM address is allocated using RmMalloc(...), an address in the 0xf4000000 range is returned (e.g. 0xf400feea). Now I wonder whether it's possible to read from the corresponding 0xf5000000 range (e.g. 0xf500feea) to issue a read-lock. Or would this cause a memory violation, since the malloc allocated memory in the 0xf4000000 range? If this is not possible, how should one use the presented constants in hardware.h? Thanks again. Kind regards, Tim At 15:15 20/04/2004, you wrote: >Hello Tim, > >I hope I have understood your issue correctly: > > > From: Tim Stevens [mailto:tim.stevens@intec.ugent.be] > > Sent: Tuesday, April 20, 2004 2:42 PM > > > Chapter 7 (p 167) of the IXP1200 programming book states that an SRAM > > memory read-lock can be obtained by the following command: > > *(unsigned int *)(SRAM_READ_LOCK + (sramLWAddr << 2)); > > where sramLWAddr is the physical address in longwords and > > SRAM_READ_LOCK is > > defined as follows: > > #define SRAM_READ_LOCK 0x12000000 > > > > Quite obviously, this results in a memory violation because > > the memory was > > not previously allocated (in the 0x12000000 range). > >Your are confusing Physical and Virtual addresses. I don't have the IXP1200 >book at hand but as far as I can guess, the 0x12000000 is a physical one. So >you need to open a window, i.e. a virtual address to physical address >translation, from a virtual address range of your user linux program to the >0x12000000 physical address range. > >The simplest way, in my humble opinion, is to mmap(2) the /dev/mem device >that corresponds to physical address space. You'll find an example of such a >program at: http://www.lart.tudelft.nl/lartware/port/devmem2.c > > > A related problem we face is that our addresses allocated in SRAM (by > > RmMalloc) seem to have a virtual address starting with > > 0xf400...., which > > does not correspond to the 10000000-->107fffff range presented in the > > "StrongARM Core Memory Map" (appendix C) from the "Microcode > > Programmer's > > Reference Manual". > >I think that once again your are confusing physical and virtual addresses. > > >Yours, >david >-- >David Mentré <mentre(a)tcl.ite.mee.com> - Research engineer (Ph.D.) >Mitsubishi Electric ITE-TCL / European Telecommunication Research Lab >Phone: +33 2 23 45 58 29 / Fax: +33 2 23 45 58 59 >http://www.mitsubishi-electric-itce.fr >_______________________________________________ >ixp1200 mailing list >ixp1200(a)lists.cs.princeton.edu >https://lists.cs.princeton.edu/mailman/listinfo/ixp1200

1 0

RE: [ixp1200] core locks using IXA SDK
by David Mentre 20 Apr '04

20 Apr '04

Hello Tim, I hope I have understood your issue correctly: > From: Tim Stevens [mailto:tim.stevens@intec.ugent.be] > Sent: Tuesday, April 20, 2004 2:42 PM > Chapter 7 (p 167) of the IXP1200 programming book states that an SRAM > memory read-lock can be obtained by the following command: > *(unsigned int *)(SRAM_READ_LOCK + (sramLWAddr << 2)); > where sramLWAddr is the physical address in longwords and > SRAM_READ_LOCK is > defined as follows: > #define SRAM_READ_LOCK 0x12000000 > > Quite obviously, this results in a memory violation because > the memory was > not previously allocated (in the 0x12000000 range). Your are confusing Physical and Virtual addresses. I don't have the IXP1200 book at hand but as far as I can guess, the 0x12000000 is a physical one. So you need to open a window, i.e. a virtual address to physical address translation, from a virtual address range of your user linux program to the 0x12000000 physical address range. The simplest way, in my humble opinion, is to mmap(2) the /dev/mem device that corresponds to physical address space. You'll find an example of such a program at: http://www.lart.tudelft.nl/lartware/port/devmem2.c > A related problem we face is that our addresses allocated in SRAM (by > RmMalloc) seem to have a virtual address starting with > 0xf400...., which > does not correspond to the 10000000-->107fffff range presented in the > "StrongARM Core Memory Map" (appendix C) from the "Microcode > Programmer's > Reference Manual". I think that once again your are confusing physical and virtual addresses. Yours, david -- David Mentré <mentre(a)tcl.ite.mee.com> - Research engineer (Ph.D.) Mitsubishi Electric ITE-TCL / European Telecommunication Research Lab Phone: +33 2 23 45 58 29 / Fax: +33 2 23 45 58 59 http://www.mitsubishi-electric-itce.fr

1 0

core locks using IXA SDK
by Tim Stevens 20 Apr '04

20 Apr '04

Hi all, While programming our IXP1200 we face a problem concerning issueing a memory lock from the core. We are using linux (bluecat 2.3.99) as the operating system for the core and the IXA SDK programming model for our application development. Memory shared between the core and the microengines is allocated using the RmMalloc(...) function and read/write (without lock constraints) works fine from both the core and the MEs (passing the address returned by RmGetPhysOffset(...)). Chapter 7 (p 167) of the IXP1200 programming book states that an SRAM memory read-lock can be obtained by the following command: *(unsigned int *)(SRAM_READ_LOCK + (sramLWAddr << 2)); where sramLWAddr is the physical address in longwords and SRAM_READ_LOCK is defined as follows: #define SRAM_READ_LOCK 0x12000000 Quite obviously, this results in a memory violation because the memory was not previously allocated (in the 0x12000000 range). A related problem we face is that our addresses allocated in SRAM (by RmMalloc) seem to have a virtual address starting with 0xf400...., which does not correspond to the 10000000-->107fffff range presented in the "StrongARM Core Memory Map" (appendix C) from the "Microcode Programmer's Reference Manual". If the memory is not allocated in this range, does the corresponding 0x12000000 range for the SRAM locks make any sense? Any help for these issues would be greatly appreciated. Kind regards, Tim

1 0

Problem running packet transmitting code
by Mohammad Shorfuzzaman 20 Apr '04

20 Apr '04

Hi everybody, I tried to run the packet transmittng code (Chap 9) from IXP1200 programming book. In function "bridging.c", hashIO_t has structure like: typedef struct { unsigned int hash_lo32; unsigned int hash_hi16 : 16; unsigned int pad : 16; } hashIO_t; If I compile the code, it gives an error regarding "hash_hi16: 16" field: "error : intrinsic data buffer "hashInput_103$1$0" cannot be read" But if I remove specifying the number of bits I mean only "unsigned int hash_hi16" it compiles fine, though logically it's not correct. Any help why it's happenning and how can I solve the problem? Thanks, Shorfuzzaman. ------------------------------------------------- This mail sent through IMP: http://horde.org/imp/

1 0

Re: [ixp1200] problem with routing table
by dveluchamy＠vsnl.net 15 Apr '04

15 Apr '04

Hi, A simple initial routing table is built(see Script file -> packet_gen.ind) durin g startup. The routing table is maintained in a TRIE data structure. See "RFC1812 Imp.pdf" for more details given along with Dev Workbench. Regards, D.Veluchamy, College of Engineering, Guindy Anna University, Chennai. ----- Original Message ----- From: Ajay modi <amodipec(a)iitr.ernet.in> Date: Thursday, April 15, 2004 5:30 am Subject: [ixp1200] problem with routing table > Hi frnds, > I ma student of masters.i m working on IXP1200. > I am facing the problem of routing.I m doing some enahancement in > RFC1812router example.Any body did the work on it.Then plz tell me > where is the > routing table and what r there contents and how r they creating .... > I waitng for ur ans.... > Thanx in advance......... > bybye > ajay > > > Ajay Modi > Mobile No. 9412352842 > Mtech-II(CSE) > F-112,Jawhar Bhawnan > IIT Roorkee > --------------------------------- > M.B.M.ENGINERRING COLLEGE JODHPUR > --------------------------------- > > ----------------------------------------- (on isc) ________________________________________________________________________ Powered by TREND VirusWall: Information Superhighway Centre, IIT Roorkee --------------------------------------------------------- _______________________________________________ ixp1200 mailing list ixp1200(a)lists.cs.princeton.edu https://lists.cs.princeton.edu/mailman/listinfo/ixp1200

1 0

Problem with getting packets
by Matija Puzar 14 Apr '04

14 Apr '04

Hello, I already sent this question to the (old) list some half an year ago, but noone seemed to have an idea. Hopefully, there will be more luck this time. We have a strange problem and the most annoying part is that it shows up pretty randomly. The boards used are ENP-2505. Sometimes, when we start some aces, the card does receive packets, the ace does send a response, but its response doesn't get to the wire (it happens even with the WWBump example). The RmSendPacket() doesn't report any error and everything seems to be working, except this little thing - no packet is received from the card. It seems that the packets get lost somewhere in the DL_SASink[] macro, but I don't really know how to check it or debug it. Restarting the aces usually helps, but still, this happens once in 4 or 5 times, which makes it VERY annoying when developing something (especially if it involves more machines at the same time, like in our case). Has anyone else encountered this problem and, perhaps, found a solution to it? Best regards, Matija -- Matija Puzar Department of Informatics, University of Oslo Postbox 1080 Blindern, N-0316 Oslo tel: +47 22 85 27 87, fax: +47 22 85 24 01

2 1