rcv_rdy_lo with workbench vs without
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
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
Abhijeet, You're absolutely right, my config_1200.cpp was setting it to BUS_SPLIT mode based on the fact that it was an SI_BOARD. It's a little disconcerting that it completely ignores the bus_mode parameter of the system's board.h::ixp_board_config structure. I'd been looking yesterday in the resource manager's microengine.c file which seems to program the FBI after config_1200.cpp but somehow config_1200.cpp takes precedence. I won't bother investigating that further though. I hardwired the 64-bit setting myself and have gotten the count application to work with the debugger. Hopefully there aren't any other critical changes from the config_1200.cpp that you have. Incidentally, where did you get this updated file for the ENP-2505 and are there any other files (other than board.h) that need to be changed for proper operation? Thanks again. On Tue, 6 Aug 2002, Abhijeet Joglekar wrote:
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
Abhijeet,
I hardwired the 64-bit setting myself and have gotten the count application to work with the debugger. Hopefully there aren't any other critical changes from the config_1200.cpp that you have. Incidentally, where did you get this updated file for the ENP-2505 and are there any other files (other than board.h) that need to be changed for proper operation? Thanks again.
Michael, I dont think any other files need to be changed. I got the file from Dirk Brandewie from Intel. He is been of amazing help in figuring out a lot of stuff. You can ask somebody from Intel. Glad it works for you. - Abhijeet
There seems to be a bug in the uEngine C Compiler, when run in unoptimized mode. I was wondering if anyone's seen this behaviour before, and if they can suggest work-arounds. One of the sample IXA applications (single-threaded-packet counter) I'm looking at exhibits this bug. It works on the "optimize for speed" settings, but when I put it into the non-optimized mode, it generates questionable micro-engine assembly output. The compiler seems to want to use GPR a0 to store both a pointer into scratch memory, as well as function return address. Predictably, this causes problems :) This behaviour is consistent in the Intel IXA Software Developers Kit for IXP1200, versions 2.0, 2.01 and 2.01a. -- Francis
participants (3)
-
Abhijeet Joglekar -
Francis -
Michael Burns