Michael, One of the possible problems (I faced this one) could be that the IXBus is not been initialised properly in the workbench mode. In the workbench mode, the rs_udebug app which is run by the startup scripts does the board initialisation. There is a file called config_1200.cpp in SA1_CoreLibs/app_1200 directory. I had the wrong version of this file which was initialising the IX bus wrongly. Basically for the Enp2505, this file should hard-wire the IX bus to be used in 64 bit mode. Look below.... **************** #if 1 /* gerry enp-2505 is not 32Bit split bus */ < printf("ConfigureFBusInterface: 64Bit IXbus.\n"); < fb_width = BUS_WIDTH_64; < #else < printf("ConfigureFBusInterface: using sysBoardIDGet() to determine 32/64bi t IXbus.\n"); 539d533 < #endif **************** If you dont have something like this in that file, then in all probability you need to get the correct version of this file. Hope this helps. - Abhijeet On Tue, 6 Aug 2002, Michael Burns wrote:
Hello all,
I've been having trouble using the workbench to run the ingress interface aces (of the SDK) while debugging. I can successfully run the various tutorials and the L3 forwarding ace without debugging them by using the ixstart scripts with mode = 0. When I use mode = 1 and use the workbench to debug, the microaces run as if no packets were being received.
Inspection of the code (and some added debugging routines) show that when the workbench is not running, incoming data on ports 0-3 are reflected in bits 0-3 of the rcv_rdy_lo CSR. However, if I use the workbench to upload the code and run it, bits 8-11 of rcv_rdy_lo reflect the activity on ports 0-3. This of course prevents packets from being received [the code looks at ((rcv_rdy_lo >> port_num) & 1) for activity]. I'm pretty sure all the variables/symbols are being patched correctly.
Does anybody have any ideas what could cause this discrepancy? I'm using an ENP-2505 board with 4 100Mb ports. Thanks for any help.
-Michael Burns UCLA LASR