November 2002 - ixp1200 - lists.cs.princeton.edu

recycling NICs from IXP12EB's, gig NICs & multiple IXP12EB's in a PC (running VERA)
by Andrew Moore 18 Nov '02

18 Nov '02

Q1. I have vera working happily on an ixp12eb (rev C.), can the ethernet board that comes with the ix12eb kit be recycled into a linux box? I'm tempted to try, and did in fact do this, but the machine wasn't happy booting so I figured it could be either the ancient machine I was trying or something more fundamental in the ethernet nic that comes with the ixp12eb. Q2. I'm interested in talking to people that have used vera and the 1 Gig interfaces... anyone out there? I'm interested in using them for traffic generation, but would like to talk to anyone who has done more than the basic "turn it on" and "yep the physical layer is working" test. Q3 now this one might be a bit odd, however.... What problems are there with sticking several ixp12eb's into a machine? I assume in its current incarnation the vera drivers are not aware of several boards? (no I've not tried it) any ideas what the load is for an ixp12eb? is it going to 'cause the mobo pci supplies to be draining too much? This would be for a "lots of ports" traffic generator.... although a "lots of ports" might be good too. cheers, Andrew. Andrew Moore, Computer Laboratory, University of Cambridge, Ph: +44-1223-763446 Fax: +44-1223-334678 andrew.moore(a)cl.cam.ac.uk www.cl.cam.ac.uk/users/awm22/

2 1

princeton roms on a rev Bixp1200 Eth. Eval. Board.
by Andrew Moore 18 Nov '02

18 Nov '02

Hi, I've been attempting to get VERA up on a board with rev B arm core (at least its what I had always thought was a REV B - this may be the problem) Possibly there are many more versions of the IXP1200 Ethernet Evaluation Board than I realised and I may be stuck with one that will never fly... I've been following the "update the flash" instructions (http://www.cs.princeton.edu/nsg/vera/README.flash.txt) However everything is fine until futil, Instead of getting C:\>FUtil -c 1 -n -a 0 -o 0 -e 200000 -f FILE.bin Flash Utility, Version 1.2.76 FlashUtil, Version 1.2.76 CPU Revision: 6901C123 Flash Width: 32 Flash Bank Size: 2048 KBytes Flash Type Bank[0]: 28F800B3-B Flash Type Bank[1]: 28F160B3-T Flash Type Bank[2]: 28F160B3-T Flash Type Bank[3]: 28F160B3-T Sending data to remote system... Percent complete: 100 Updating flash... Percent Complete: 100 done I get C:\> FUtil -c 1 -n -a 0 -o 0 -e 200000 -f flashImage.bin Flash Utility, Version 2.01.112 FlashUtil, Version 1.1.109 CPU Revision: 6901C121 Flash Width: 32 Flash Bank Size: 2048 KBytes Flash Type Bank[0]: 28F800B3-B Flash Type Bank[1]: 28F160B3-T Flash Type Bank[2]: Unknown Flash Type Bank[3]: Unknown Sending data to remote system... Percent complete: 100 Error in doing inflate: 'Error FFFFFFFD C:\> Clearly this board doesn't have 2Mb of flash, or its not in the configuration expected. I've tried the same process on other IXP ether Eval boards and it works, but not this particular type. Details: the boards I have that work call themselves Rev C the board has the identifier A13033-001 A02 L1 (this is from the sth/wst corner of the board) (near serial port) the board that gives the error above identifies itself as a Rev B and has the identifier A13033-002 Is this board a waste of time??? Thanks for your thoughts, Andrew. Andrew Moore, Computer Laboratory, University of Cambridge, Ph: +44-1223-763446 Fax: +44-1223-334678 andrew.moore(a)cl.cam.ac.uk www.cl.cam.ac.uk/users/awm22/

6 8

IXP1200 - RHL
by Rayashish＠aol.com 15 Nov '02

15 Nov '02

Hi all, Can anyone help me to load Linux2.4 kernel on IXP12eb sitting on host pc running RHL2.4. --I have VERA drivers loaded on Linux Host. --Can connect to ixp-board through Hyper teminal. --Cygmon is running in flash. --Also Vera loader is running in flash which waits for start address of srec-image. How do i load arm-kernel and ramdisk image through host pci usinng vera tools? Any help or pointer- TIX --Ashish

2 1

RE: [ixp1200] IXP1200-2505 PCI card booting
by Brandewie, Dirk J 15 Nov '02

15 Nov '02

The problem here is that the card saw a space bar that told it to drop out of loop where it was waiting for the kernel to be downloaded and go to cygmon. The ixstart script waits to see the login prompt from the kernel booting on the board. The script times out if it does not see the login prompt. If you reboot the system and connect to the serial port that the board is connected to you should see the message: "Press space bar to abort host download mode...." repeated over and over. If this is the case you should be able to exit minicom and use the bootixp script to boot the board. --Dirk > -----Original Message----- > From: Ning Weng [mailto:nweng@ecs.umass.edu] > Sent: Wednesday, November 13, 2002 3:45 PM > To: ixp1200(a)CS.Princeton.EDU > Subject: [ixp1200] IXP1200-2505 PCI card booting > > > > Hello, > > Sorry for bother but I really need some kind inputs... > > Did I any one have this kind of experience? Plese help and give me > some hints. > > For IXP1200 ENP-2505 PCI card, following the IXA Education > Workstation > Setup Guide, I did successfully boot the card with the > message" Finished > ENP-2505 Driver Install..." . But after a few days, when I > reboot, this is > what I got : > > ".... > > Welcome to minicom 1.83.1 > > OPTIONS: History Buffer, F-key Macros, Search History Buffer, I18n > Compiled on Aug 28 2001, 15:09:33. > > Press CTRL-A Z for help on special keys > > > cygmon> script "./.ixstart": global timeout > > ...." > > I cann't remember what I exactly did after my first > successful booting. > But I try to reinstall the software and hardware, but I got the same > message. > > Any help is greatly appreciated!!!! > > Thanks a lot. > > -Ning >

2 2

microengine loader (w/correct URL)
by Kenneth M. Mackenzie 13 Nov '02

13 Nov '02

[doh -- always check the URLs] Hi all, Here's an updated package of our local tools, just updated to include a microcode loader, etc. that we use to operate the microengines from the StrongARM under Linux without ACEs or the workbench. http://www.cercs.gatech.edu/projects/asan/software.html Note that the StrongARM tools (in the "utils/" directory) don't depend on our alternative host-side driver scheme, I'm just packaging them in one tarball. ---------------- Various folks have asked about alternatives to ACEs. We use three schemes to program the microengines: 1. Homebrew tools including loader and etc., that run stand-alone under Linux on the StrongARM and communicate with the uEngines via Intel's "ue.o" kernel module on the StrongARM (same as used by rs_udebug with the workbench). We also use command-line versions of the assembler and linker in this configuration under "wine" so it's an all-linux solution. 2. Intel's Workbench. You can use this to load code onto the hardware instead of the simulator and it doesn't require ACEs (in fact it doesn't work with ACEs although it's not obvious that they should be incompatible). 3. ACEs Note: I would not characterize any of these three toolchains as exactly "easy". Each just offers its own kind of pain. In other words, don't switch toolchains just because you're frustrated with ACEs. -- Ken

2 1

VERA LibIXPRouter Minor Software Update
by Yitzchak M. Gottlieb 13 Nov '02

13 Nov '02

We are very happy to announce an update of the Vera IXPRouter library. This is a very minor update to correct small problems in compiling the IXPRouter library. Some relevant changes include: 1) Removed references to atoi in Libixprouter/sa/src/control.c (I applied the patch previously posted to the mailing list.) 2) Removed reference to p2tosa.h in Libixprouter/common/src/Makefile The software is available at http://www.cs.princeton.edu/nsg/vera. Please feel free to post any questions. Zuki -- Yitzchak Gottlieb zuki(a)CS.Princeton.EDU

1 0

RE: [ixp1200] Workbench, debug with "hardware" option?
by Botham, Mick 12 Nov '02

12 Nov '02

Irwin, Check the portmapper is running on the host, this error message results if the portmapper is not started. Rgds Mick -----Original Message----- From: Ye, Irvin [mailto:i.ye@lancaster.ac.uk] Sent: 08 November 2002 14:09 To: 'ixp1200(a)CS.Princeton.EDU' Subject: RE: [ixp1200] Workbench, debug with "hardware" option? I'm using Linux. -----Original Message----- From: Botham, Mick [mailto:mick.botham@intel.com] Sent: 08 November 2002 13:43 To: ixp1200(a)CS.Princeton.EDU Subject: RE: [ixp1200] Workbench, debug with "hardware" option? Irvin, Are you using VxWorks or Linux? The workbench will function the same on either EB or SI card. I prefer a direct network connection from host to target board, it saves a lot of confusion. Rgds Michael Botham EMEA IXA TME -----Original Message----- From: Ye, Irvin [mailto:i.ye@lancaster.ac.uk] Sent: 08 November 2002 11:46 To: 'ixp1200(a)cs.princeton.edu' Subject: [ixp1200] Workbench, debug with "hardware" option? Hi, I wonder, if I can use Workbench to do "hardware" debug? It's said that it's OK on EB boards, but I only have a SI board from Radisys. So I'm not sure whether it works. I've tried. Sometimes, it seemed successifully connected with the board, while in the other times, it just reported "Attach to debug library operation failed". It let me puzzled. Who can give some hints? BTW, to my opinion, play with ixp1200 is a game far from fun. There are enormous documents, while it's rather difficult to find wanted information. Cheers! Irvin

1 0

microengine loader
by Kenneth M. Mackenzie 11 Nov '02

11 Nov '02

Hi all, Here's an updated package of our local tools, just updated to include a microcode loader, etc. that we use to operate the microengines from the StrongARM under Linux without ACEs or the workbench. http://www.cercs.gatech.edu/projects/asan/software/ Note that the StrongARM tools (in the "utils/" directory) don't depend on our alternative host-side driver scheme, I'm just packaging them in one tarball. ---------------- Various folks have asked about alternatives to ACEs. We use three schemes to program the microengines: 1. Homebrew tools including loader and etc., that run stand-alone under Linux on the StrongARM and communicate with the uEngines via Intel's "ue.o" kernel module on the StrongARM (same as used by rs_udebug with the workbench). We also use command-line versions of the assembler and linker in this configuration under "wine" so it's an all-linux solution. 2. Intel's Workbench. You can use this to load code onto the hardware instead of the simulator and it doesn't require ACEs (in fact it doesn't work with ACEs although it's not obvious that they should be incompatible). 3. ACEs Note: I would not characterize any of these three toolchains as exactly "easy". Each just offers its own kind of pain. In other words, don't switch toolchains just because you're frustrated with ACEs. -- Ken

1 0

RmSendPacket error "Ring to microengine is full"
by Ye, Irvin 11 Nov '02

11 Nov '02

Hi, I use Intel's MicroACE. But there's a problem on egress side. The problem is between the core and micro block. When the core tried to send packets to micro block, there may be a RmSendPacket error, and the message is "Ring to microengine is full". Who can give me some help? Regards. Irvin

1 0

uengine interrupt
by Arthur Berkowitz 11 Nov '02

11 Nov '02

Excuse me in advance if this is too long. Let me explain what I'm trying to do: I'm using the uengine interrupt to StrongARM to ask for an ARP service performed by VxWorks. I'm not using the OS ARP Cache directly from uengines, rather I maintain a private hash table (SRAM and DRAM) for IP to MAC entries. This table is written by the core and read by uengines. All locking, hash unit and duplicates issues are just fine. When a lookup from uengine thread fails to find an entry for IP (the MAC is unknown!), the uengine thread will write the request in a mailbox and raise an interrupt to core. ACK from core is waited (inter thread signal). when ACK received, uthread will drop the packet, hopefully next packet required MAC will be resolved since ARP Service on core will add the information to IP2MAC table. On core there is an interrupt handler, that is a callback function registered with the Global uengine ISR (yeah, the same one breakpoint is using!). This handler will read the uthread request from mailbox and send it by message queue to ARP resolver task. The interrupt handler send an inter thread signal as an ACK back to uengines. The ARP resolver task perform the ARP and adds the resolved MAC to IP2MAC hash table. some code snippets: #macro arp_resolve_request(_output_intf, _ip) .local mailbox xbuf_alloc($request, 2) move($request0, _output_intf) move($request1, _ip) #if (UENGINE_ID == 0) move(mailbox, LWOFFSET0) #else // UENGINE_ID == 1 move(mailbox, LWOFFSET2) #endif sram_write($request0, UTHREAD_TO_CORE_MAILBOXES, mailbox, LWCOUNT2, sig_done) block_on_sram#: br_!signal[sram, block_on_sram#] ; block until mailbox written to continue fast_wr[1, ireg] ; raise interrupt block_on_inter_thread#: br_!signal[inter_thread, block_on_inter_thread#] ; wait for core ACK xbuf_free($request) alu[--,--,b, 0] ; this will cause drop pkt .endlocal // mailbox #endm note that I use only the first 2 (0, 1) uengines to Receive & Forward so just two mailboxes. now at the core... I connect the interrupt handler as: #include "ueng.h" ......... /* statics initialization */ unsigned int & ArpServ::_ireg(*(unsigned int *)0xB00401E0); ................. uEng_intConnect(UENG_MSG_INT, 0xFFFFFF, interrupt_handler, 0); ................ void ArpServ::interrupt_handler(int){ REQUEST_t request; unsigned int ifname, ipaddr, request_size; unsigned int iregShadow; iregShadow= _ireg; _ireg = iregShadow & 0xF8FFFFFF; iregShadow &= 0xFFFFFF; for(int bit=0; bit<FWD_THR_NUM; bit++){ if (iregShadow & (1 << bit)){ iregShadow = iregShadow & ~( 1<< bit); request_size = (bit >> 2) ? REQ_SIZE : 0; READ_MAILBOX(request_size, ifname, ipaddr); request.ifname = ifname; request.ipaddr = ipaddr; logMsg("request.ifname = %d request.ipaddr = 0x%08x\n", request.ifname, request.ipaddr, 3, 4, 5, 6); msgQSend(msgQId, (char *)&request, REQ_SIZE, 0, 0); /* ack uengine thread by inter thread signal */ *(unsigned int *)0xB00401C0 = bit; } } } At this point let me thank you for reading so far! Now the problem: 3 boards with same configuration work inconsistently. Board A always performs as expected. Board B and Board C not always. The interrupt isn't received on core. BUT, when I set breakpoint in uthread and stop as close before the fast_wr instruction (on sram_write) then just continue running interrupt is received on core! Then even if I unset the breakpoint the board function as expected The software looks OK and (surprisingly :-) it sometimes (always on one of the Boards) work as expected. Is it some timing issue with SRAM reference? Maybe I mask something wrong in ireg and not register proper to ISR? At the time of writing this an idea came to me: I should link out debug from vxworksnetapp so Breakpoint interrupt handler is not getting connected. Could this be a H/W problem?! Any ideas and all are welcomed ! Arthur Berkowitz COMGATES Ltd. 15 Hagalim Avenue. Herzliya, 46725 Israel Tel: +972.9.950.0404 Ext: 288 Fax: +972.9.950.0385 Mobile: +972.55.535.349 Email: arthur(a)comgates.co.il Visit Us: www.comgates.com

1 0