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

RE: question regarding to Tornado software
by Varnell, Frank 30 Jun '00

30 Jun '00

You need Tornado if you want to use the vxworks OS and change the route tables or do any vxWorks or NetApp commands. The eval board comes with a VxWorks/netapp image that has the shell enabled for Tornado conectivity only. > -----Original Message----- > From: Scott C. Karlin [mailto:scott@CS.Princeton.EDU] > Sent: Friday, June 30, 2000 1:10 PM > To: ps3(a)andrew.cmu.edu > Cc: ixp1200(a)CS.Princeton.EDU > Subject: Re: question regarding to Tornado software > > > Pat writes: > > > > Hi, > > > > I have questions about the Tornado software. I am trying to > run an example > > workbench project on the SA1200 hardware, the Ethernet > Evaluation Platform. > > I am under the impression that I will need to boot the > VxWorks before I can > > run my codes on the hardware. Therefore, the Tornado > software is a must. > > Please clarify this. > > No, the Tornado software is not mandatory. We do not use it for > our development. > > > To configure my system to run the uCos operating system, I > will need to > > install the ARM software development toolkit to my host PC. > Do I really > > need this? Is only the VxWorks operating system sufficient > enough to be > > used to run codes on the hardware? > > After joining the list, you can look in the e-mail archive > for the list > (instructions will arrive when you subscribe to the list). I posted > instructions on how to take the current GNU tools and use the VxWorks > bootloader (but not the Tornado software) to load and run the code. > > > I am not yet a member of this mailing list. My friend at > Intel told me > > about it. Please let me know what I have to do to become a member. > > To join the list, send e-mail to majordomo(a)cs.princeton.edu > and include > the line "subscribe ixp1200" in the body of the message. (The subject > line is ignored and may be blank.) > > > In the meantime, please make all replies be cc to me directly. > > Done. > > > > > Thank you in advance for your help, > > > > Petcharat Suriyachai > > To join the list, send e-mail to majordomo(a)cs.princeton.edu > and include > the line "subscribe ixp1200" in the body of the message. (The subject > line is ignored and may be blank.) > > -Scott >

1 0

question regarding to Tornado software
by Pat 30 Jun '00

30 Jun '00

Hi, I have questions about the Tornado software. I am trying to run an example workbench project on the SA1200 hardware, the Ethernet Evaluation Platform. I am under the impression that I will need to boot the VxWorks before I can run my codes on the hardware. Therefore, the Tornado software is a must. Please clarify this. To configure my system to run the uCos operating system, I will need to install the ARM software development toolkit to my host PC. Do I really need this? Is only the VxWorks operating system sufficient enough to be used to run codes on the hardware? I am not yet a member of this mailing list. My friend at Intel told me about it. Please let me know what I have to do to become a member. In the meantime, please make all replies be cc to me directly. Thank you in advance for your help, Petcharat Suriyachai

2 1

RE: Technical Writer Contact
by Yavatkar, Raj 21 Jun '00

21 Jun '00

Please send those to me and I will forward those to the appropriate contact. Raj -----Original Message----- From: Scott C. Karlin [mailto:scott@CS.Princeton.EDU] Sent: Wednesday, June 21, 2000 10:36 AM To: ixp1200(a)CS.Princeton.EDU Subject: Technical Writer Contact This question is directed toward the Intel folks on the list. As we study the Intel manuals associated with the IXP1200 and the Evaluation System, we encounter the occasional bug or typo. Where should we send our bug reports? Thanks, Scott

1 0

Technical Writer Contact
by Scott C. Karlin 21 Jun '00

21 Jun '00

This question is directed toward the Intel folks on the list. As we study the Intel manuals associated with the IXP1200 and the Evaluation System, we encounter the occasional bug or typo. Where should we send our bug reports? Thanks, Scott

1 0

RE: IXP1200 programming
by Paige, Dale W 17 Jun '00

17 Jun '00

Peter - Intel is porting the NetBoost programming interface, called the IX API, to the IXP1200. This is not yet available, the developers release is due out in the fourth quarter of this year. This interface includes C++ classes. Full featured StrongArm(TM) C/C++ compilers are provided by ARM Ltd and through the FSF. Cygnus provides additional support for the GNU compiler. We do not have compiler which creates code for the uEngines. Since you have functional C code that runs on a particular Microprocessor I suggest that you port the functionality to the IXP1200 StrongARM core initially choosing the minimum subset of functionality that handles the reception and transmission of network data for implementation onto the uEngines. Once the application is running you can then use performance analysis to determine which elements of the application should be ported to run on the uEngines. In short, port the C based application to the IXP1200 using a core centric perspective, remembering that the uEngines must ultimately host the time critical application code. I hope this helps you get started. Best Regards - Dale Paige -----Original Message----- From: Peter Yang [mailto:pyang@MIT.EDU] Sent: Thursday, June 15, 2000 2:38 PM To: Paige, Dale W Subject: IXP1200 programming Hi Dale - How are you? My name is Peter Yang, and I am working with Prof. Hari Balakrishnan here at MIT on a IXP1200 project as part of the Intel grant. I saw some of your emails on the Princeton IXP1200 mailing list, and I was wondering if you'd be able to answer a couple of questions for me. First, I was wondering if Intel has any plans to add C/C++ compiler support for the Microengines. The reason I ask this is that I've been doing some background reading on various network processors, and I've seen that some companies like C-port have chosen to provide a big mess of software tools, including compilers for their RISC cores. I was wondering if Intel has anything similar in the works (though, judging from the features and ease of use of the Developer's Workbench, it seems like this is unlikely -- still, I thought I'd ask ...) On a second, related topic, as part of our project, we would like to port some previously written programs to the IXP1200. As there are no compilers, this task does not look as easy as it once appeared. Do you have any hints for how we might accomplish this? One method I've been contemplating is to compile the code into assembly code for some instruction set similar to the IXA instruction set and then translating that assembly to IXA assembly. Do you know of any ISAs that are similar to yours that might work for this purpose? I realize these questions are somewhat out of the blue, but I figured that asking you directly would save me some trouble. If you feel you are unable to answer these questions, would you be able to point me to someone who might be able to? Thank you for all your help. Sincerely, Peter Yang

1 0

uEngine LED-hello-world
by Tammo Spalink 16 Jun '00

16 Jun '00

I have managed to load the uEngines. In case others are curious what is necessary, I have included a program for the StrongArm which will load a simple uEngine program to write the number "5" to the evaluation board LEDs (similar to Scott Karlin's previous StrongARM LED activation except for use of the uEngines). It is intended to be loaded with the VxWorks boot loader. Getting this to work I have noticed a number of things in the manuals that the Intel might want to look into. I refer to the newest manuals we have, dated "March, 2000". (HRM sect 4.7) does not mention that the ECS bit should also be turned off again. Also the first step says the uEngine can be in the "Reset" state. This is not true: only the "Stopped" or "Paused" states work. (HRM sect 4.6.3) does not mention that the VS bit in the CTX_WAKEUP_EVENTS register for a given context must be set before that context can be run by the arbiter. (HRM sect 3.3, HRM sect 8.9.1, and PRM appendix C) disagree on the bounds of the SRAM SlowPort memory region. And finally some things that initially tripped us up: (PRM sect 4) In the register description tables, the "Access" column sometimes incorrectly says "Read" even if a few bits of the register are "Read/Write". I suggest the Intel folks get rid of this column entirely, since all of the information is provided by the "R/W" column on the same page. (Sort of HRM sect 4.7) The uEngines memory is word-addressed while the StrongARM memory is byte-addressed. It took me a while to notice this means the uEngines do not have byte addressing bits at all. That is, I was using only addresses 0, 4, 8, and so forth. The correct thing to do wass use 0, 1, 2, 3, etc. This difference also has implications for comparing memory maps (for things like the LED addresses, etc). Tammo ------------- uEngine LED activation code below -------------- typedef unsigned int uint32; #define IXP1200_RESET 0x4200007C static uint32 CSR_Base[6] = { 0xB0000000, 0xB0000800, 0xB0001000, 0xB0001800, 0xB0002000, 0xB0002800 }; typedef enum { USTORE_ADDRESS = 0x0, USTORE_DATA = 0x4, ALU_OUTPUT = 0x08, ACTIVE_CTX_STS = 0x10, CTX_ARB_CTL = 0x24, CTX_ENABLES = 0x28, CC_ENABLE = 0x2C, } csrOffsets; static uint32 CTX_STS[4] = { 0x34, 0x38, 0x3C, 0x40 }; static uint32 CTX_WAKEUP_EVENTS[4] = { 0x54, 0x58, 0x5C, 0x60 }; inline extern uint32 memRead(uint32 address, uint32 bitOffset, uint32 bitCount) { uint32 mask = (0xFFFFFFFFul >> (32 - bitCount)) << bitOffset; uint32 value = *((volatile uint32 *)address); return (value & mask) >> bitOffset; } inline extern void memWrite(uint32 address, uint32 value) { *((volatile uint32 *)address) = value; } inline extern uint32 memOverwrite(uint32 address, uint32 bitOffset, uint32 bitCount, uint32 value) { // Write value into a bitCount wide field bitOffset bits from the LSB // at memory location address, leaving the remaining bits as-is. uint32 mask = (0xFFFFFFFFul >> (32 - bitCount)) << bitOffset; uint32 prevValue = memRead(address, 0, 32); uint32 newValue = prevValue & ~mask; newValue |= (value << bitOffset) & mask; memWrite(address, newValue); return prevValue; } inline extern uint32 csrRead(int uEng, uint32 address, uint32 bitOffset, uint32 bitCount) { return memRead(address + CSR_Base[uEng], bitOffset, bitCount); } inline extern void csrWrite(int uEng, uint32 address, uint32 value) { memWrite(address + CSR_Base[uEng], value); } inline extern uint32 csrOverwrite(int uEng, uint32 address, uint32 bitOffset, uint32 bitCount, uint32 value) { return memOverwrite(address + CSR_Base[uEng], bitOffset, bitCount, value); } // The uCode. Notice that 0x742000 is the memory-mapped address // of the LEDs from uEngineLand. uint32 ucode_Arr[] = { 0xD8100008, // immed_w0[ledaddr, (0x742000 & 0xFFFF)] 0xD8143A00, // immed_w1[ledaddr, ((0x742000 >> 16) & 0xFFFF)] 0xA00E0039, // sram[write, $xfer0, ledaddr, 0, 1], ctx_swap 0xDC000280, // immed[$xfer0, 5] ;; in delay slot 0xE00C0004 // ctx_arb [kill] }; int ucode_Len = (sizeof(ucode_Arr) / 4); void __main(void) { uint32 destAddr = 0x0; // Where in the uStore to put code int uEng = 0; // Which uEngine to use int ctx = 0; // Which thread to use uint32 loadAddr; int i; // Take uEng out of reset state memOverwrite(IXP1200_RESET, uEng, 1, 0x0); // Load the uCode loadAddr = destAddr | 0x00000400; // Set ECS bit for (i = 0; i < ucode_Len; i++, loadAddr++) { csrWrite(uEng, USTORE_ADDRESS, loadAddr); // target uStore location csrWrite(uEng, USTORE_DATA, ucode_Arr[i]); // desired uStore contents } csrWrite(uEng, USTORE_ADDRESS, 0x0); // Unset ECS bit // Prep the other uEngine state csrOverwrite(uEng, CTX_STS[ctx], 0, 10, destAddr); csrOverwrite(uEng, CTX_WAKEUP_EVENTS[ctx], 0, 10, 0x1); csrOverwrite(uEng, ACTIVE_CTX_STS, 0, 2, ctx); csrOverwrite(uEng, CTX_ARB_CTL, 2, 2, ctx + 1); // Start the thread csrOverwrite(uEng, CTX_ENABLES, 8 + ctx, 1, 0x1); // Wait for uEngine to finish while (csrRead(uEng, ACTIVE_CTX_STS, 2, 1)) { // Waiting... } } ------------- uEngine LED activation compilation process -------------- arm-unknown-coff-gcc -nostartfiles -nodefaultlibs -fno-builtin \ -mcpu=strongarm110 -mapcs-32 -mno-sched-prolog -fvolatile -O2 \ -Wall -Winline -Wstrict-prototypes -c demo.c arm-unknown-coff-ld -X -N -e ___main -Ttext 00001000 demo.o -o bootimage.coff ---------------------------

1 0

uCode Assembler
by Tammo Spalink 09 Jun '00

09 Jun '00

I would like to have a uCode assembler which runs on our Linux workstations. Looking at some of the example code on the developer's CD-ROM, I ran across across some instructions for building under Linux. Is there some version of the uCode assembler for Linux available from Intel? If not, could the source code be made available? The provided assembler appears quite feature-rich and we would greatly prefer it to a homegrown one. Tammo

1 0

RE: Loading MicroEngine code
by Paige, Dale W 09 Jun '00

09 Jun '00

The vxWorks BSP does enable the MMU, and caching for a certain region in SDRAM. It sets this up correctly (see <ixp1200>\boardsupport\vxWorks\ixp1200eb\rominit.s). I do not think you need to, or should, disable the MMU to solve this problem. -----Original Message----- From: Tammo Spalink [mailto:tspalink@CS.Princeton.EDU] Sent: Friday, June 09, 2000 8:39 AM To: ixp1200(a)CS.Princeton.EDU Subject: Re: Loading MicroEngine code I am using the vxWorks boot loader to load my test program directly to the SACore (no OS). Does the boot loader enable the MMU and data cache (which I believe are disabled at reset)? I am working on adding the code to disable these (MMU & caches). However, the behavior I get is that I write to the CSR memory region and am unable to read back what I wrote. If I understand the side effects of caching/buffering correctly, I should definately be able to read what it wrote, but the write may not have propagated to the device correctly. No? Tammo On Thu, 8 Jun 2000, "Paige, Dale W" wrote: > What OS are you running? > > Are you certain that the SA core is treating data accesses to the CSR range > data as non-cacheable and non-bufferable? > > -----Original Message----- > From: Tammo Spalink [mailto:tspalink@CS.Princeton.EDU] > Sent: Thursday, June 08, 2000 2:09 PM > To: ixp1200(a)CS.Princeton.EDU > Subject: Re: Loading MicroEngine code > > > > No effect I am afraid. > > Tammo > > On Thu, 8 Jun 2000, "Paige, Dale W" wrote: > > Tammo - > > > > Try writting the address again prior to the read. > > > > csrWrite(CSR, USTORE_ADDR, addr); // Set the target address > > csrWrite(CSR, USTORE_DATA, 0xD8100020); // Write an instruction > > csrWrite(CSR, USTORE_ADDR, addr); // Set the target address > AGAIN > > <== > > result = csrRead(CSR, USTORE_DATA);

1 0

RE: Loading MicroEngine code
by Paige, Dale W 09 Jun '00

09 Jun '00

What OS are you running? Are you certain that the SA core is treating data accesses to the CSR range data as non-cacheable and non-bufferable? -----Original Message----- From: Tammo Spalink [mailto:tspalink@CS.Princeton.EDU] Sent: Thursday, June 08, 2000 2:09 PM To: ixp1200(a)CS.Princeton.EDU Subject: Re: Loading MicroEngine code No effect I am afraid. Tammo On Thu, 8 Jun 2000, "Paige, Dale W" wrote: > Tammo - > > Try writting the address again prior to the read. > > csrWrite(CSR, USTORE_ADDR, addr); // Set the target address > csrWrite(CSR, USTORE_DATA, 0xD8100020); // Write an instruction > csrWrite(CSR, USTORE_ADDR, addr); // Set the target address AGAIN > <== > result = csrRead(CSR, USTORE_DATA);

2 1

RE: Loading MicroEngine code
by Paige, Dale W 08 Jun '00

08 Jun '00

Tammo - Try writting the address again prior to the read. csrWrite(CSR, USTORE_ADDR, addr); // Set the target address csrWrite(CSR, USTORE_DATA, 0xD8100020); // Write an instruction csrWrite(CSR, USTORE_ADDR, addr); // Set the target address AGAIN <== result = csrRead(CSR, USTORE_DATA); -----Original Message----- From: Tammo Spalink [mailto:tspalink@CS.Princeton.EDU] Sent: Thursday, June 08, 2000 1:31 PM To: ixp1200(a)CS.Princeton.EDU Subject: Loading MicroEngine code I have been unsuccessfully trying to write to a UEngine UStore. From what I have read in both the paper docs and the example code, the code below should write the instruction 0xD8100020 to the 0th UStore location in UEngine 0 and end with the "result" variable having the value 0xD8100020. In practice (I have printing routines in my real program) "result" is always zero. Looking at the CSR for UEngine 0, it is disabled and should be ready to go. Am I missing some other bit that need to be set? The documentation seems to suggest that the reset state (which the UE is in at startup) should be a good time to write to the UStore. Tammo ----- typedef unsigned int uint32; // The following I get from example code: #define CTX_ENABLES (0x28) #define USTORE_ADDR (0x0) #define USTORE_DATA (0x4) void csrWrite(uint32 baseAddr, uint32 offset, uint32 value) { *((volatile uint32 *)(baseAddr + offset)) = value; } int32 csrRead(uint32 baseAddr, uint32 offset) { return *((volatile uint32 *)(baseAddr + offset)); } void __main(void) { uint32 CSR = 0xB0000000; // Base address microengine 0 uint32 CTXEnablesValue; // Holds contents of CTX_ENABLES CSR state uint32 addr = 0x0; // Where in the UStore to put code uint32 result; // Ensure the UEngines are disabled CTXEnablesValue = csrRead(CSR, CTX_ENABLES); csrWrite(CSR, CTX_ENABLES, CTXEnablesValue & 0xFFFFF0FF); addr |= 0x00000400; // Set the address enable (ECS) bit csrWrite(CSR, USTORE_ADDR, addr); // Set the target address csrWrite(CSR, USTORE_DATA, 0xD8100020); // Write an instruction result = csrRead(CSR, USTORE_DATA); // This is where I expect "result" to be 0xD8100020, however it is // always equal to 0 (zero). // Enable the UEngines again (including this one) csrWrite(CSR, CTX_ENABLES, CTXEnablesValue | (1 << (7 + ueng))); } -----

2 1