- ixp1200 - lists.cs.princeton.edu

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

Deep Packet Inspection using IXP1200 simulator.
by Denis Lyons 13 Apr '04

13 Apr '04

Hi, I am a masters student who is just starting work with the IXP1200 simulator. I am interested in performing deep packet inspection using the simulator (v2.0) and analysing the perfromance. Is there any code available for implementing deep packet inspection on the IXP1200 simulator?? Any help or advice will be greatly appreciated. Thanks in advance, Denis Lyons Department of Informatics and Electronics University of Limerick Limerick Ireland.

1 0

IXP1200's publicly available in Emulab
by Jay Lepreau 09 Apr '04

09 Apr '04

I am pleased to announce the Utah Emulab testbed's integrated and documented support for IXP1200's. Currently we have 8 cards installed; all are publicly available to anyone with a valid research, educational, or development use, by signing up at www.emulab.net. http://www.emulab.net/tutorial/docwrapper.php3?docname=ixp.html Similar to other Emulab resources, an IXP1200 node can be allocated through an 'ns' script or through the Netbuild GUI. It can be configured as part of an arbitrary topology (of PCs, IXPs, or other node types), with end-nodes, traffic generators, routers, links, etc. Through NFS it has access to /proj and your Emulab home directory. You can configure a command to run automatically upon bootup. You have full access to the serial consoles of both the IXP and its host PC, which you can power cycle and of course reboot. All that makes it easy to allocate, experiment with, and evaluate an IXP-based application. Right now we have 8 ENP2505 (Bridalveil) cards installed, with Intel SDK 2.01 software. We hope to incorporate more IXP1200 nodes as we make space in our machine room, and also IXP2400 cards as development resources permit. Many thanks go to Intel for helping to support this work, to NSF of course, to the Emulab crew who helped develop it, and most especially to our former student Abhijeet Joglekar, who became our IXP expert.... and is now working at Intel. Jay Lepreau University of Utah

1 0

plugging an IXP1200 eval board into a regular PC causes infinite reboot
by wdebruij＠dds.nl 07 Apr '04

07 Apr '04

Hi all, to be able to use the evaluation boards on a regular basis I would like to move them onto a regular (active) PCI backplane. From the VERA project documentation I've gotten quite useful information, and from the georgia tech PCI drivers for the ENP I've managed to write to the card over PCI just fine. However, I'm experiencing a strange problem that I hope someone has seen before: when I plug in the board it keeps resetting itself. This appears to be related to the BootMgr software, as it nicely waits for user input when I enter its menu by pressing space. Running cygmon or the diagnostics will immediately reset the board, though. I'm using the netwinder flash with cygmon on a B0 board, by the way. at first I thought that it might have to do with receiving a possible interrupt from the backplane, but having tried all interrupt lines (and none at all), this does not appear to be the problem. Does this problem sound familiar to anyone? On a related note: we're trying to get the eval boards working as ENP boards, ie booting linux over PCI. So far I've managed to write drivers for directly accessing the onboard pci from the host in kernelspace and through mmmap in userspace. In case anyone's interested, the sources can be found in CVS on ffpf.sourceforge.net . As soon as I've worked out the last bugs I'll supply a regular distribution.

2 1

Doubt reg. sending data streams to IXP1200 ports
by sharmila radhakrishnan 07 Apr '04

07 Apr '04

Hello all, I have a doubt.I tried sending data to the IXP1200 physical port using 'ping' command.But I was not able to read the data from the port.Can you'll help me out with this.It is very urgent please. Thanx in advance, Sharmila Win an evening with the Indian cricket captain: Yahoo! India Promos.

1 0

Re: Doubt reg. sending data streams to IXP1200 ports
by sharmila radhakrishnan 07 Apr '04

07 Apr '04

Hello Win an evening with the Indian cricket captain: Yahoo! India Promos.

1 0