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

Reference Design
by Alok Kumar 27 Nov '00

27 Nov '00

Hi All, Can anyone help me out to make some reference design work in actual hardware? Which reference design in the latest CD is known to actually work in B0 hardware without any problem? What is the semantics of routing table in that reference? I have downloaded vxworks in the hardware and also run tornado. Now, I download mircocode through workbench and it runs ( I can see PC changing). Now, I want to send some packets and get them routed. So, please tell me which reference design should I download? 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 _______________________________________________________________________________

4 5

RE: PETH drivers
by Johnson, Erik J 27 Nov '00

27 Nov '00

I just successfully recompiled and here are the steps I took: 0). Make sure your environment is setup, define WIND_BASE as the root dir of your Tornado installation (e.g, C:\Tornado) WIND_HOST_TYPE as x86-win32 These can also be set by running torVars.bat in Tornado\host\x86-win32\bin (no magic here, I assume you have already done this since it it needed to compile anything for VxWorks) 1) cd IXP1200\BoardSupport\VxWorks\IXP1200EB\ 2) Edit Makefile and make sure -DMVR is added as an extra flag 3) make clean 4) make vxWorks I wonder if the missing defines come from system makefiles, which, perhaps the system can't find if you don't set the WIND_BASE environment variable properly....? erik > -----Original Message----- > From: Servio Lima [mailto:servio@andrew.cmu.edu] > Sent: Thursday, November 23, 2000 5:17 AM > To: Johnson, Erik J > Cc: ixp1200(a)CS.Princeton.EDU > Subject: Re: PETH drivers > > > Hi, > > In the compilation process of Vxworks , I've found several > flags specified > in the Makefile , defs files and rules files that needs to > be declared > first. These flags have null values and they cause the whole > make process to > stop abruptly. For example: > > partialImage.o: $(LDDEPS) $(PRJ_OBJS) $(EXTRA_MODULES) > $(COMPONENT_LIBS) > $(LIBS) $(PRJ_OBJS_FILE) > - @ $(RM) $@ > > flags like the Tornado source directory are not defined. > Whats the procedure > for giving values to them? > > Regards, > Servio > > > "Johnson, Erik J" wrote: > > > What does the console (serial) window say when > > you get these failures? If you are getting > > IP_MAX_UNITS failures, then you need to recompile > > vxworks with IP_MAX_UNITS set higher than 1 > > (it needs to be >= PETH_NUM_DEVS + 1). The NetApp > > init code registers the END driver(s) with the > > IP stack and be default VxWorks only allows > > one registration with the IP stack (which is > > consumed by the Intel NIC/driver). You can > > see an example of how I did this in the supplied > > BoardSupport/VxWorks/IXP1200EB/config.h, search > > for MVR, or IP_MAX_UNITS, and then follow this > > model to build your BSP (or if you are using the > > supplied BSP, just define MVR and recompile) > > > > if that is not the problem, I am at a loss. > > Perhaps it is a version mis-match? The driver > > was written for VxWorks 5.4 (if I remember correctly) > > maybe something changed in the END interface...? > > > > The default routes were #ifdef'd out for the MVR > > application because we were demonstrating a routing > > protocol (OSPF) rather than static routes. In addition, > > the route table manager changed its interface slightly > > to support the notion of virtual routers. If you want > > to add a route, simply use the rtm_mvr code. look in > > SA1_CoreLibs/rtm-mvr/, the VxWorks shell commands are > > available from rtm_console.cpp/rtm_console.h if you > > just want to call them "by hand", or add them into > > any init code you want. > > > > erik > > > > > -----Original Message----- > > > From: Servio Lima [mailto:servio@andrew.cmu.edu] > > > Sent: Wednesday, November 22, 2000 4:48 AM > > > To: Johnson, Erik J; ixp1200(a)CS.Princeton.EDU > > > Subject: Re: PETH drivers > > > > > > > > > Hi, > > > > > > I still get the same error , even reducing the number of > PETH devices: > > > -> NetApp_GigInit > > > > > > STATUS OF intConnect = 0 > > > BigMacDriver CTOR OctalMacNumber = 0 > > > status = 0 > > > status = ffffffff > > > Failed to load Pseudo Ethernet driver number 0 > > > Failed to load Pseudo Ethernet driver number 1 > > > Failed to load Pseudo Ethernet driver number 2 > > > Failed to load Pseudo Ethernet driver number 3 > > > value = -1341915136 = 0xb0040000 > > > > > > Some hints: > > > I am compiling the vxworks_mvr application using Tornado with the > > > following flags: > > > ccarm > > > -g -mcpu=strongarm110 -mapcs-32 -ansi -nostdinc -DRW_MULTI_THREAD > > > -D_REENTRANT -mno-sched-prolog -fno-builtin -fvolatile -w > > > -Wall -pedantic > > > -I. -IC:/Tornado/target/h -Ic:\ixp1200\include > > > -Ic:\ixp1200\SA1_CoreLibs\libd -Ic:\ixp1200\msgq > > > -Ic:\ixp1200\SA1_CoreLibs\GigaMAC_GC82547EB > > > -Ic:\ixp1200\SA1_CoreLibs\debug_1200 -Ic:\ixp1200\utils > -DCPU=ARMSA110 > > > -DOS=VXWORKS -DIOSTYLE=HARDWARE -DVX_WORKS -DVXWORKS -DROUTE > > > -DFBUS_DEV0_TYPE=0 -DFBUS_DEV1_TYPE=1 -DMAC_21440 -DMAC_GC82547EB > > > -DWB_SVR -DFBUS_DEVICE_COUNT=2 -D__unix -DRTM_MVR > -DROUTE -DPETH_DRV > > > -DPETH_NUM_DEVS=4 > > > > > > > > > That are the same flags found in vxworks_mvr.mak makefile > > > Any suggestions? > > > > > > In addition , I'd like to know exactly where the route for > > > port 18 should > > > be inserted in the fixed routing table that is implemented in > > > \Ixp1200\SA1_Corelibs\app1200\net_app.cpp, because there is a > > > preprocessor directive that banned the insertion of a route > > > in the place > > > where other routes are added. An extracted portion of the > > > code explains > > > this: > > > > > > #ifdef ROUTE > > > #ifndef RTM_MVR ------------------> it is assumed that if > > > MVR is used a > > > new route can not be inserted?? > > > rt_add("1.1.1.1", "255.0.0.0", 1); > > > ....etc > > > > > > > > > Thanks in advance, > > > Servio > > > > > > > > > > > > > > > "Johnson, Erik J" wrote: > > > > > > > Sorry, I missed the last part of your email. > > > > The PETH driver ASSUMES it gets packets from port 18, > > > > you don't need to instantiate that many drivers. > > > > Simply instantiate drivers for the ports you want to > > > > logically represent to VxWorks (e.g, just the first > > > > 4 10/100 ports). Then each driver will enqueue for > > > > the transmit port associated with its instance, > > > > all will receive from port 18 and demultiplexing will > > > > be done based on the ingress port number within the > > > > packet descriptor. Note, you should be loading the > > > > MVRRefdes microcode with this driver since it has > > > > modifications to the microcode that allow the core to > > > > properly enqueue on the outgoing (transmit) queues. > > > > > > > > erik > > > > > > > > > -----Original Message----- > > > > > From: Servio Lima [mailto:servio@andrew.cmu.edu] > > > > > Sent: Tuesday, November 21, 2000 2:23 PM > > > > > Cc: ixp1200(a)CS.Princeton.EDU > > > > > Subject: PETH drivers > > > > > > > > > > > > > > > > > > > > Hi, > > > > > Does anyone has experience using Pseudo Ethernet drivers for > > > > > StrongArm-Microengine > > > > > communications? > > > > > I got the following problem each time I compile with the > > > > > -DPETH_DRV flag on > > > > > (using Tornado Workbench): > > > > > > > > > > -> ld < my_rtmmvr.out > > > > > Loading C:/project2/ARMSA110gnu/rtmmvr.out | > > > > > value = 3275480 = 0x31fad8 > > > > > -> NetApp_GigInit > > > > > > > > > > STATUS OF intConnect = 0 > > > > > BigMacDriver CTOR OctalMacNumber = 0 > > > > > status = 0 > > > > > status = ffffffff > > > > > Failed to load Pseudo Ethernet driver number 0 > > > > > Failed to load Pseudo Ethernet driver number 1 > > > > > Failed to load Pseudo Ethernet driver number 2 > > > > > Failed to load Pseudo Ethernet driver number 3 > > > > > Failed to load Pseudo Ethernet driver number 4 > > > > > Failed to load Pseudo Ethernet driver number 5 > > > > > Failed to load Pseudo Ethernet driver number 6 > > > > > Failed to load Pseudo Ethernet driver number 7 > > > > > Failed to load Pseudo Ethernet driver number 8 > > > > > Failed to load Pseudo Ethernet driver number 9 > > > > > Failed to load Pseudo Ethernet driver number 10 > > > > > Failed to load Pseudo Ethernet driver number 11 > > > > > Failed to load Pseudo Ethernet driver number 12 > > > > > Failed to load Pseudo Ethernet driver number 13 > > > > > Failed to load Pseudo Ethernet driver number 14 > > > > > Failed to load Pseudo Ethernet driver number 15 > > > > > Failed to load Pseudo Ethernet driver number 16 > > > > > Failed to load Pseudo Ethernet driver number 17 > > > > > Failed to load Pseudo Ethernet driver number 18 > > > > > Failed to load Pseudo Ethernet driver number 19 > > > > > > > > > > Exception number 16: Task: 0x3bff74 (t31) > > > > > > > > > > Data abort > > > > > Program Counter: 0xcc294 > > > > > Status Register: 0x60000013 > > > > > 8e6c8 _vxTaskEntry +28 : 3ff64 () > > > > > 40008 _wdbFuncCallLibInit+128: _NetApp_GigInit () > > > > > cc358 _NetApp_GigInit+c : _NetApp_Init__Fv () > > > > > > > > > > Data abort > > > > > Exception address: 0x000cc294 > > > > > Current Processor Status Register: 0x60000013 > > > > > Task: 0x3bff74 "t31" > > > > > value = 0 = 0x0 > > > > > > > > > > > > > > > I am using -DPETH_NUM_DEVS=20, that is 20 PETH devices, > > > > > because I want to use port > > > > > No. 18 for the StrongArm-uengine communication. > > > > > > > > > > Basically the problem is the invocation of the function: > > > cookie = > > > > > muxDevLoad(pethDrvNum, pethEndLoad, pethInitStr, 0, NULL); > > > > > that can be found in > \IXP1200\SA1_CoreLibs\app_1200\net_app.cpp > > > > > > > > > > My goal is to transmit a packet from the StronArm to the > > > > > uengine and viceversa. I > > > > > think I should enable the PETH functionality first, but if > > > > > anyone knows of > > > > > another method for doing the same, please let me know ASAP. > > > > > > > > > > Any help would be appreciated. > > > > > > > > > > Regards, > > > > > Servio Lima7 > > > > > > > > > > > > > > > > > >

1 0

RE: PETH drivers
by Johnson, Erik J 25 Nov '00

25 Nov '00

What does the console (serial) window say when you get these failures? If you are getting IP_MAX_UNITS failures, then you need to recompile vxworks with IP_MAX_UNITS set higher than 1 (it needs to be >= PETH_NUM_DEVS + 1). The NetApp init code registers the END driver(s) with the IP stack and be default VxWorks only allows one registration with the IP stack (which is consumed by the Intel NIC/driver). You can see an example of how I did this in the supplied BoardSupport/VxWorks/IXP1200EB/config.h, search for MVR, or IP_MAX_UNITS, and then follow this model to build your BSP (or if you are using the supplied BSP, just define MVR and recompile) if that is not the problem, I am at a loss. Perhaps it is a version mis-match? The driver was written for VxWorks 5.4 (if I remember correctly) maybe something changed in the END interface...? The default routes were #ifdef'd out for the MVR application because we were demonstrating a routing protocol (OSPF) rather than static routes. In addition, the route table manager changed its interface slightly to support the notion of virtual routers. If you want to add a route, simply use the rtm_mvr code. look in SA1_CoreLibs/rtm-mvr/, the VxWorks shell commands are available from rtm_console.cpp/rtm_console.h if you just want to call them "by hand", or add them into any init code you want. erik > -----Original Message----- > From: Servio Lima [mailto:servio@andrew.cmu.edu] > Sent: Wednesday, November 22, 2000 4:48 AM > To: Johnson, Erik J; ixp1200(a)CS.Princeton.EDU > Subject: Re: PETH drivers > > > Hi, > > I still get the same error , even reducing the number of PETH devices: > -> NetApp_GigInit > > STATUS OF intConnect = 0 > BigMacDriver CTOR OctalMacNumber = 0 > status = 0 > status = ffffffff > Failed to load Pseudo Ethernet driver number 0 > Failed to load Pseudo Ethernet driver number 1 > Failed to load Pseudo Ethernet driver number 2 > Failed to load Pseudo Ethernet driver number 3 > value = -1341915136 = 0xb0040000 > > Some hints: > I am compiling the vxworks_mvr application using Tornado with the > following flags: > ccarm > -g -mcpu=strongarm110 -mapcs-32 -ansi -nostdinc -DRW_MULTI_THREAD > -D_REENTRANT -mno-sched-prolog -fno-builtin -fvolatile -w > -Wall -pedantic > -I. -IC:/Tornado/target/h -Ic:\ixp1200\include > -Ic:\ixp1200\SA1_CoreLibs\libd -Ic:\ixp1200\msgq > -Ic:\ixp1200\SA1_CoreLibs\GigaMAC_GC82547EB > -Ic:\ixp1200\SA1_CoreLibs\debug_1200 -Ic:\ixp1200\utils -DCPU=ARMSA110 > -DOS=VXWORKS -DIOSTYLE=HARDWARE -DVX_WORKS -DVXWORKS -DROUTE > -DFBUS_DEV0_TYPE=0 -DFBUS_DEV1_TYPE=1 -DMAC_21440 -DMAC_GC82547EB > -DWB_SVR -DFBUS_DEVICE_COUNT=2 -D__unix -DRTM_MVR -DROUTE -DPETH_DRV > -DPETH_NUM_DEVS=4 > > > That are the same flags found in vxworks_mvr.mak makefile > Any suggestions? > > In addition , I'd like to know exactly where the route for > port 18 should > be inserted in the fixed routing table that is implemented in > \Ixp1200\SA1_Corelibs\app1200\net_app.cpp, because there is a > preprocessor directive that banned the insertion of a route > in the place > where other routes are added. An extracted portion of the > code explains > this: > > #ifdef ROUTE > #ifndef RTM_MVR ------------------> it is assumed that if > MVR is used a > new route can not be inserted?? > rt_add("1.1.1.1", "255.0.0.0", 1); > ....etc > > > Thanks in advance, > Servio > > > > > "Johnson, Erik J" wrote: > > > Sorry, I missed the last part of your email. > > The PETH driver ASSUMES it gets packets from port 18, > > you don't need to instantiate that many drivers. > > Simply instantiate drivers for the ports you want to > > logically represent to VxWorks (e.g, just the first > > 4 10/100 ports). Then each driver will enqueue for > > the transmit port associated with its instance, > > all will receive from port 18 and demultiplexing will > > be done based on the ingress port number within the > > packet descriptor. Note, you should be loading the > > MVRRefdes microcode with this driver since it has > > modifications to the microcode that allow the core to > > properly enqueue on the outgoing (transmit) queues. > > > > erik > > > > > -----Original Message----- > > > From: Servio Lima [mailto:servio@andrew.cmu.edu] > > > Sent: Tuesday, November 21, 2000 2:23 PM > > > Cc: ixp1200(a)CS.Princeton.EDU > > > Subject: PETH drivers > > > > > > > > > > > > Hi, > > > Does anyone has experience using Pseudo Ethernet drivers for > > > StrongArm-Microengine > > > communications? > > > I got the following problem each time I compile with the > > > -DPETH_DRV flag on > > > (using Tornado Workbench): > > > > > > -> ld < my_rtmmvr.out > > > Loading C:/project2/ARMSA110gnu/rtmmvr.out | > > > value = 3275480 = 0x31fad8 > > > -> NetApp_GigInit > > > > > > STATUS OF intConnect = 0 > > > BigMacDriver CTOR OctalMacNumber = 0 > > > status = 0 > > > status = ffffffff > > > Failed to load Pseudo Ethernet driver number 0 > > > Failed to load Pseudo Ethernet driver number 1 > > > Failed to load Pseudo Ethernet driver number 2 > > > Failed to load Pseudo Ethernet driver number 3 > > > Failed to load Pseudo Ethernet driver number 4 > > > Failed to load Pseudo Ethernet driver number 5 > > > Failed to load Pseudo Ethernet driver number 6 > > > Failed to load Pseudo Ethernet driver number 7 > > > Failed to load Pseudo Ethernet driver number 8 > > > Failed to load Pseudo Ethernet driver number 9 > > > Failed to load Pseudo Ethernet driver number 10 > > > Failed to load Pseudo Ethernet driver number 11 > > > Failed to load Pseudo Ethernet driver number 12 > > > Failed to load Pseudo Ethernet driver number 13 > > > Failed to load Pseudo Ethernet driver number 14 > > > Failed to load Pseudo Ethernet driver number 15 > > > Failed to load Pseudo Ethernet driver number 16 > > > Failed to load Pseudo Ethernet driver number 17 > > > Failed to load Pseudo Ethernet driver number 18 > > > Failed to load Pseudo Ethernet driver number 19 > > > > > > Exception number 16: Task: 0x3bff74 (t31) > > > > > > Data abort > > > Program Counter: 0xcc294 > > > Status Register: 0x60000013 > > > 8e6c8 _vxTaskEntry +28 : 3ff64 () > > > 40008 _wdbFuncCallLibInit+128: _NetApp_GigInit () > > > cc358 _NetApp_GigInit+c : _NetApp_Init__Fv () > > > > > > Data abort > > > Exception address: 0x000cc294 > > > Current Processor Status Register: 0x60000013 > > > Task: 0x3bff74 "t31" > > > value = 0 = 0x0 > > > > > > > > > I am using -DPETH_NUM_DEVS=20, that is 20 PETH devices, > > > because I want to use port > > > No. 18 for the StrongArm-uengine communication. > > > > > > Basically the problem is the invocation of the function: > cookie = > > > muxDevLoad(pethDrvNum, pethEndLoad, pethInitStr, 0, NULL); > > > that can be found in \IXP1200\SA1_CoreLibs\app_1200\net_app.cpp > > > > > > My goal is to transmit a packet from the StronArm to the > > > uengine and viceversa. I > > > think I should enable the PETH functionality first, but if > > > anyone knows of > > > another method for doing the same, please let me know ASAP. > > > > > > Any help would be appreciated. > > > > > > Regards, > > > Servio Lima7 > > > > > > > >

3 2

RE: PETH drivers
by Johnson, Erik J 22 Nov '00

22 Nov '00

Sorry, I missed the last part of your email. The PETH driver ASSUMES it gets packets from port 18, you don't need to instantiate that many drivers. Simply instantiate drivers for the ports you want to logically represent to VxWorks (e.g, just the first 4 10/100 ports). Then each driver will enqueue for the transmit port associated with its instance, all will receive from port 18 and demultiplexing will be done based on the ingress port number within the packet descriptor. Note, you should be loading the MVRRefdes microcode with this driver since it has modifications to the microcode that allow the core to properly enqueue on the outgoing (transmit) queues. erik > -----Original Message----- > From: Servio Lima [mailto:servio@andrew.cmu.edu] > Sent: Tuesday, November 21, 2000 2:23 PM > Cc: ixp1200(a)CS.Princeton.EDU > Subject: PETH drivers > > > > Hi, > Does anyone has experience using Pseudo Ethernet drivers for > StrongArm-Microengine > communications? > I got the following problem each time I compile with the > -DPETH_DRV flag on > (using Tornado Workbench): > > -> ld < my_rtmmvr.out > Loading C:/project2/ARMSA110gnu/rtmmvr.out | > value = 3275480 = 0x31fad8 > -> NetApp_GigInit > > STATUS OF intConnect = 0 > BigMacDriver CTOR OctalMacNumber = 0 > status = 0 > status = ffffffff > Failed to load Pseudo Ethernet driver number 0 > Failed to load Pseudo Ethernet driver number 1 > Failed to load Pseudo Ethernet driver number 2 > Failed to load Pseudo Ethernet driver number 3 > Failed to load Pseudo Ethernet driver number 4 > Failed to load Pseudo Ethernet driver number 5 > Failed to load Pseudo Ethernet driver number 6 > Failed to load Pseudo Ethernet driver number 7 > Failed to load Pseudo Ethernet driver number 8 > Failed to load Pseudo Ethernet driver number 9 > Failed to load Pseudo Ethernet driver number 10 > Failed to load Pseudo Ethernet driver number 11 > Failed to load Pseudo Ethernet driver number 12 > Failed to load Pseudo Ethernet driver number 13 > Failed to load Pseudo Ethernet driver number 14 > Failed to load Pseudo Ethernet driver number 15 > Failed to load Pseudo Ethernet driver number 16 > Failed to load Pseudo Ethernet driver number 17 > Failed to load Pseudo Ethernet driver number 18 > Failed to load Pseudo Ethernet driver number 19 > > Exception number 16: Task: 0x3bff74 (t31) > > Data abort > Program Counter: 0xcc294 > Status Register: 0x60000013 > 8e6c8 _vxTaskEntry +28 : 3ff64 () > 40008 _wdbFuncCallLibInit+128: _NetApp_GigInit () > cc358 _NetApp_GigInit+c : _NetApp_Init__Fv () > > Data abort > Exception address: 0x000cc294 > Current Processor Status Register: 0x60000013 > Task: 0x3bff74 "t31" > value = 0 = 0x0 > > > I am using -DPETH_NUM_DEVS=20, that is 20 PETH devices, > because I want to use port > No. 18 for the StrongArm-uengine communication. > > Basically the problem is the invocation of the function: cookie = > muxDevLoad(pethDrvNum, pethEndLoad, pethInitStr, 0, NULL); > that can be found in \IXP1200\SA1_CoreLibs\app_1200\net_app.cpp > > My goal is to transmit a packet from the StronArm to the > uengine and viceversa. I > think I should enable the PETH functionality first, but if > anyone knows of > another method for doing the same, please let me know ASAP. > > Any help would be appreciated. > > Regards, > Servio Lima7 > >

2 1

RE: PETH drivers
by Johnson, Erik J 21 Nov '00

21 Nov '00

You also need to define PETH_NUM_DEVS=xx some integer value of the number of interfaces you want to install drivers for (e.g., PETH_NUM_DEVS=8). The vxworks_mvr.mak makefile compiles the driver into the NetApp code, if you want an example. erik > -----Original Message----- > From: Servio Lima [mailto:servio@andrew.cmu.edu] > Sent: Tuesday, November 21, 2000 2:23 PM > Cc: ixp1200(a)CS.Princeton.EDU > Subject: PETH drivers > > > > Hi, > Does anyone has experience using Pseudo Ethernet drivers for > StrongArm-Microengine > communications? > I got the following problem each time I compile with the > -DPETH_DRV flag on > (using Tornado Workbench): > > -> ld < my_rtmmvr.out > Loading C:/project2/ARMSA110gnu/rtmmvr.out | > value = 3275480 = 0x31fad8 > -> NetApp_GigInit > > STATUS OF intConnect = 0 > BigMacDriver CTOR OctalMacNumber = 0 > status = 0 > status = ffffffff > Failed to load Pseudo Ethernet driver number 0 > Failed to load Pseudo Ethernet driver number 1 > Failed to load Pseudo Ethernet driver number 2 > Failed to load Pseudo Ethernet driver number 3 > Failed to load Pseudo Ethernet driver number 4 > Failed to load Pseudo Ethernet driver number 5 > Failed to load Pseudo Ethernet driver number 6 > Failed to load Pseudo Ethernet driver number 7 > Failed to load Pseudo Ethernet driver number 8 > Failed to load Pseudo Ethernet driver number 9 > Failed to load Pseudo Ethernet driver number 10 > Failed to load Pseudo Ethernet driver number 11 > Failed to load Pseudo Ethernet driver number 12 > Failed to load Pseudo Ethernet driver number 13 > Failed to load Pseudo Ethernet driver number 14 > Failed to load Pseudo Ethernet driver number 15 > Failed to load Pseudo Ethernet driver number 16 > Failed to load Pseudo Ethernet driver number 17 > Failed to load Pseudo Ethernet driver number 18 > Failed to load Pseudo Ethernet driver number 19 > > Exception number 16: Task: 0x3bff74 (t31) > > Data abort > Program Counter: 0xcc294 > Status Register: 0x60000013 > 8e6c8 _vxTaskEntry +28 : 3ff64 () > 40008 _wdbFuncCallLibInit+128: _NetApp_GigInit () > cc358 _NetApp_GigInit+c : _NetApp_Init__Fv () > > Data abort > Exception address: 0x000cc294 > Current Processor Status Register: 0x60000013 > Task: 0x3bff74 "t31" > value = 0 = 0x0 > > > I am using -DPETH_NUM_DEVS=20, that is 20 PETH devices, > because I want to use port > No. 18 for the StrongArm-uengine communication. > > Basically the problem is the invocation of the function: cookie = > muxDevLoad(pethDrvNum, pethEndLoad, pethInitStr, 0, NULL); > that can be found in \IXP1200\SA1_CoreLibs\app_1200\net_app.cpp > > My goal is to transmit a packet from the StronArm to the > uengine and viceversa. I > think I should enable the PETH functionality first, but if > anyone knows of > another method for doing the same, please let me know ASAP. > > Any help would be appreciated. > > Regards, > Servio Lima7 > >

1 0

RE: bad magic
by Brandewie, Dirk J 20 Nov '00

20 Nov '00

What image were you trying to load? --Dirk -----Original Message----- From: Hilarie Orman [mailto:HORMAN@novell.com] Sent: Monday, November 20, 2000 2:15 PM To: ixp1200(a)CS.Princeton.EDU Subject: bad magic I'm trying to boot a system for the first time and get an error after "attaching lo0" from loadLib saying that there's a bad magic number: 0x5a4d. Does this indicate an erroneous build or a version error or something else altogether? Hilarie

1 0

bad magic
by Hilarie Orman 20 Nov '00

20 Nov '00

I'm trying to boot a system for the first time and get an error after "attaching lo0" from loadLib saying that there's a bad magic number: 0x5a4d. Does this indicate an erroneous build or a version error or something else altogether? Hilarie

1 0

FUtil Host for Linux
by Scott C. Karlin 17 Nov '00

17 Nov '00

Does anyone know if the host side of the ixp1200eb flash utility (FUtil HOST) has been ported to Linux? If not, I am willing to do it. Can someone at Intel provide details of the protocol used between the host and the ixp1200eb? The source code for Windows is in BoardSupport/FlashUtil/host and shows that the author is "jdg" / "Jdguilfo". I'd prefer to work with a spec (even in the form of notes) about the protocol rather than the source code marked Intel proprietary. Thanks, Scott

1 0

Trouble booting new ixp1200eb
by Scott C. Karlin 16 Nov '00

16 Nov '00

I am just now trying out the new ixp1200 evaluation board. Apparently there has been some changed to the tftp procedure between firmware revisions. Here is the (correct) terminal output for my "Hello, World" program on the *old* board. (Note that I have removed duplicate blank lines from the output for readability.) =========================== OLD BOARD =========================== Early serial debug initialized muxLoad failed! 0x VxWorks System Boot Copyright 1984-1998 Wind River Systems, Inc. CPU: Level One ixp1200eb - ARM IXP1200 Version: 5.4 BSP version: 1.0/948 Creation date: Feb 16 2000, 14:44:03 Press any key to stop auto-boot... 0 auto-booting... boot device : eeE unit number : 0 processor number : 0 host name : scout-7 file name : ixp1200a inet on ethernet (e) : 128.112.42.102 inet on backplane (b): 0 host inet (h) : 128.112.42.27 user (u) : target ftp password (pw) : target flags (f) : 0x88 target name (tn) : ixp1200a Attached TCP/IP interface to eeE0. Attaching network interface lo0... done. Loading... 340 + 0 + 0 Starting at 0x1000... Hello, World! Enter characters to be echoed: ================================================================= Here's what happens with the new board. (I am using the BootMgr to point to VxWorks.) =========================== NEW BOARD =========================== Press space bar to stop auto-boot... 0 BSP IXP Version: 1.0.1129, built on May 31 2000, 10:29:10 Early serial debug initialized muxLoad VxWorks System Boot Copyright 1984-1998 Wind River Systems, Inc. CPU: Intel ixp1200eb - ARM IXP1200 Version: 5.4 BSP version: 1.2/1 Creation date: May 31 2000, 10:29:10 Press any key to stop auto-boot... 0 auto-booting... boot device : eeE unit number : 0 processor number : 0 host name : scout-7 file name : ixp1200a inet on ethernet (e) : 128.112.42.102 host inet (h) : 128.112.42.27 user (u) : target ftp password (pw) : target flags (f) : 0x88 target name (tn) : ixp1200a Can't load boot file!! BSP IXP Version: 1.0.1129, built on May 31 2000, 10:29:10 Early serial debug initialized muxLoad [VxWorks Boot]: ================================================================= What precisely does "Can't load boot file!!" mean? Why would the old version work when the new version does not? (Remember that we are not really using VxWorks. There is a possibility that the new firmware is more particular about the content of the boot file but I'm not sure if the file is getting transferred of the network.) Thanks, Scott

2 2

Re: Schematics for Eval Boards
by Scott C. Karlin 16 Nov '00

16 Nov '00

I think I have answered my own question. I was looking at the schematics in documentation/Schematics_EB/evb_p*.pdf which are marked as in my original message (and marked "July 99 Rev B" on the first page). The new schematics pages are all in the single file called "documentation/IXP1200 Eval Sys Schematics.pdf" (and marked "Jan 5, 2000 REV A01"). The title page is marked with the part number "A13033-001". -Scott Scott Karlin writes: > > I do see that the new PCB number does match the old PCB number > (A13033). However, I'm starting to suspect that there is at least > a small discrepancy between the board and the schematics. > > I'm looking carefully at the board and the schematics to convince > myself that the board will work when plugged into a Pentium > motherboard. (The PCI_debug.txt file not withstanding.) > > The signals which caught my eye are the PCI signals PRSNT1# and > PRSNT2# found on pins B9 and B11 of the PCI backplane. For expansion > boards, the PCI spec (rev 2.2, section 4.4.1) states that at least > one of the signals must be grounded to indicate that a board is > plugged into an expansion slot. The schematics (page 2, zone D3) > show that these signals are pulled up to Vdd (3.3V) via 5Kohm > ("R502") resistors R222 and R223. Both a visual inspection of the > board and a check with a meter shows that R222 and R223 are 20Kohm > (marked "203") resistors. While this is not a big discrepancy, it > tells me that the schematics may not match in more significant ways. > > Pat Kelley writes: > > > > The 002 sticker reflects the revision update for B0 200MHz. > > > > The schematics number matches the PCB (look under the sticker!) > > > > Scott Karlin writes: > > > > > > We just received a new version of the IXP1200 development board > > > with the B0 stepping of the IXP1200 chip. Included in the shipment > > > is the version 1.1.109 of the development environment CD-ROM. > > > > > > I would like to verify that the schematics on this CD-ROM match > > > the board we just received. The evb_p1.pdf page title block > > > states "TOP DOCUMENT NUMBER K-DD-54-30296-0-1" dated 13-AUG-99. > > > > > > Our older board was marked in the copper layer "A13033-001 A01 L1". > > > Our new boards have a sticker in the same place marked "A13033-002". > > > > > > Can anyone confirm that the 13-AUG-99 schematics match the board > > > we just received?

1 0