- ixp1200 - lists.cs.princeton.edu

Re: IXP clock rate question
by Perry Wagle 20 Jul '00

20 Jul '00

> Measurements with the microengine cycle counters suggest that the > clock speed of our system is 177MHz as opposed to the manual's claim > of 166MHz. > > Does this sound accurate? I'm including my own observations in my answer to your question: I'm loading my boot loader from angel on a rev A board. I have the RTC firing an interrupt "once a second", and TIMER_1 firing "a hundred times a second". Angel has set the PLL_CFG register to (my debugging routine dumps "label address value"): pll_cfg 90000c00 00000010 which I've assumed to be "correct", so haven't tried changing it, especially since the documentation warns againts setting it too high. The RTC uses what I call the "slow clock" (~ 3 MHz), and the TIMER's use what I call the "fast clock" (~ 162 Mhz). To initialize the RTC calibration, I set the RTC_DIV register to my slow_clock (expressed in Hz) divided by 128, and currently get: rtc_div 90002000 00037080 (so RDIV = 0x7080) and to initialized the TIMER_1 calibration, I set the TIMER_1_LOAD register to the my fast_clock (expressed in Hz) divided by 100, and currently get: timer_1_load 42000300 0018bff0 timer_1_control 42000308 000000c0 (notice that the value of timer_1_control shows that I am counting CPU cycles without a divisor). With my slow_clock constant set to 3686400 Hz and my fast_clock constant set to 162200000, I am getting approximately 100.15 TIMER_1 interrupts per RTC interrupt (over a 12 hour period). These two values correspond to the ROUNDED values of the two clock rates from page 28 of the "IXP1200 Network Processor Specification Update (June 2000)". The roundoff is SIGNIFICANT to my measurement, and I wish the documentation writers WOULDN'T ROUND OFF THE VALUES. For example, since the given value of the fast_clock was almost exactly 44 times the given value of the slow_clock, I tried just setting the fast_clock to exactly 44 times the slow clock, and got 100.5 TIMER_1 interrupts per second. BOTH values of the fast_clock were within the roundoff of the value given in the documentation. My setting of the slow_clock is consistant with the documentation's suggestion, and the seconds doesn't skew according to my eyeball's comparison with my wristwatch. It's close enough that I'm not going to worry more about it more until I have Linux running XNTP. So my answer to your original question is that I'm somewhat confident that I have the Core Clock measured at about 162 MHz (+- 1 Mhz), at least with respect to the RTC and TIMER_1 hardware on Rev A hardware. Which Rev do you guys have? -- Perry

2 1

IXP clock rate question
by Tammo Spalink 20 Jul '00

20 Jul '00

Measurements with the microengine cycle counters suggest that the clock speed of our system is 177MHz as opposed to the manual's claim of 166MHz. Does this sound accurate? Tammo

1 0

IXP1200 Workbench Key
by Tammo Spalink 19 Jul '00

19 Jul '00

We recently received a new IXP development CD (Version 1.0 release) from Intel. This one appears to require key/password to get at the executables. However, when we try to go to the website to get the keys the link does not work. Has anyone else had luck with this? If it's not just us, maybe Intel could look into it. The link I am trying to use is from the developer.intel.com IXP1200 site: http://apps-cic.jf.intel.com/CNFY2/e_register.asp?cnfy2=xx&Actv_ID=2797 Thanks, Tammo

1 0

21440 transmit success
by Tammo Spalink 18 Jul '00

18 Jul '00

I finally got it to work: I can send as well as receive a packet. For me the trick appears to be using the 64 bit wide IXBus mode. I have yet to discover why this is. Using 32 bit wide mode results in, for every 8 bytes sent, bytes 0-3 are replicated in positions 4-7 replacing what should be there. Tammo

1 0

RE: UART interrupts
by Ananthanarayanan, Arul 11 Jul '00

11 Jul '00

Perry, On the B step the CoProcessor 15 ID_CHIP command will return a 1 in bit 0. If you read a 0, you have the A step. You have the old cdrom. You need to get the new 1.0 version (1.0.1129) as it has the specification update that lists all the differences between the steps. You should be able to get this from your Intel support person. Arul -----Original Message----- From: Perry Wagle [mailto:wagle@cse.ogi.edu] Sent: Tuesday, July 11, 2000 3:36 PM To: arul.ananthanarayanan(a)intel.com; ixp1200(a)CS.Princeton.EDU; wagle(a)cse.ogi.edu Subject: RE: UART interrupts Arul -- How do I tell for sure whether I have an A or B step IXP1200? The Coprocessor 15 (MMU) ID_CHIP command (section 4.10.1) returns 0x6901c120, which means revision 0 of something (the MMU?). The edge of the board near the serial connector says "A13033-001 A01 L1" on the side with most of the chips, and "A13033 001 A01 L8" on the other side. What are all the differences between Rev A and Rev B? If the documentation I have is going to be this far off in general, I'm not sure I can port Linux to the board, and I need to complain. Which document on the Version 1.0.1011 CDrom (that came with the boards) are you talking about that describes the uart? --- I thought I'd tried setting mystery bit 9 to see if it would clear the interupt. It seems to work now. You have to reinitialize the uart (setting baud, etc) after each interupt? Thanks! -- Perry > From arul.ananthanarayanan(a)intel.com Tue Jul 11 14:34:53 2000 > From: "Ananthanarayanan, Arul" <arul.ananthanarayanan(a)intel.com> > To: "'Perry Wagle'" <wagle(a)cse.ogi.edu>, ixp1200(a)CS.Princeton.EDU > Subject: RE: UART interrupts > Date: Tue, 11 Jul 2000 14:34:47 -0700 > MIME-Version: 1.0 > Perry, > > The documentation refers to the B stepping of the IXP1200. You > probably have > the A step of the processor and there are differences in handling the UART. > In the A stepping, bit 6 of the IRQ register is really the UART interrupt > (not the RTC). > You do need to clear the UART interrupts on the A step, so the mystery bit 9 > of the > UART_SR is what you need to set before exiting your handler. > There is a specification update on the Version 1.0 developers CD that > details the changes > for the A step. > Arul > -----Original Message----- > From: Perry Wagle [mailto:wagle@cse.ogi.edu] > Sent: Monday, July 10, 2000 5:22 PM > To: ixp1200(a)CS.Princeton.EDU > Subject: UART interupts > Has anyone gotten the UART interupts to work right? > I can read and write the UART just fine with polled i/o, but > interupts seem all messed up. I suspect the March 2000 IXP1200 > Network Processor Programmer's Reference is either false or I wasn't > given the board that it corresponds to. > Section 4.6.10 UART_CR (page 4-78): The UART generates a IRQ interupt > regardless of what I set set bit 9 (UIS, select IRQ or FIQ) to. > Setting bit 4 (RIE) is necessary to get IRQ interupts to fire, but > once I get them to fire, they won't stop firing. My IRQ handler will > be entered even if there are no characters ready to read from the UART > after I've left it for the first time. It won't enter my IRQ_handler > the first time until I've send a character. If I read the UART_CR > register, I get what I set it to except for UIS is always zero; ie, > 0x001700f0 (9600baud, the mystery bit 9 (UIS) is clear, transmit > interupts disabled, uart enabled, 8 bits data size, recieve interupts > enabled, 1 stop bit, no parity). > What is the mystery bit 9? > Section 4.6.9 UART_SR (page 4-77): This register address is always [?] > equal to "RXD pin set, transmit fifo full, ... , transmit fifo empty, > ..." (0x00000180) when my IRQ_handler is entered (except the first > time, when the "receive fifo ready" bit is also set (0x00000190)). > It would seem impossible that the transmit fifo is both full and empty > at the same time, what's going on? > Section 4.6.17 IRQ (page 4-86): When my IRQ_handler is entered, this > register is always equal to "IRQ interupt generated by RTC" (bit 6 = > 0x00000040), and no matter what I do to the UART status, control, and > data registers, its still set when my IRQ_handler is ready to leave > (ie, after its read one character after waiting for it to become > available). I suspect that since I'm not succeeding in clearing the > interupt condition, that its being reissued just as soon as I leave > the interupt handler. > I'm thinking that bit 6 corresponds to the UART, and not the RTC, > since my IRQ handler is only entered for the first time when I send a > character to the IXP1200 serial port. I have apparently not succeeded > (yet) in getting the RTC to generate an interupt. What is the correct > layout of the IRQ register? > My foreground job (spin the led with an ever-incrementing unsigned > char counter in a tight infinite loop) usually doesn't make progress > after my IRQ_handler is entered for the first time. But when it does, > it has only 2-3 "favorite" values that the led ends up displaying. It > seems odd that I've got such a good phase lock on 2-3 out of 256 > possible values, but I can't imagine what this information is telling > me. > -- Perry

1 0

RE: UART interrupts
by Perry Wagle 11 Jul '00

11 Jul '00

Arul -- How do I tell for sure whether I have an A or B step IXP1200? The Coprocessor 15 (MMU) ID_CHIP command (section 4.10.1) returns 0x6901c120, which means revision 0 of something (the MMU?). The edge of the board near the serial connector says "A13033-001 A01 L1" on the side with most of the chips, and "A13033 001 A01 L8" on the other side. What are all the differences between Rev A and Rev B? If the documentation I have is going to be this far off in general, I'm not sure I can port Linux to the board, and I need to complain. Which document on the Version 1.0.1011 CDrom (that came with the boards) are you talking about that describes the uart? --- I thought I'd tried setting mystery bit 9 to see if it would clear the interupt. It seems to work now. You have to reinitialize the uart (setting baud, etc) after each interupt? Thanks! -- Perry > From arul.ananthanarayanan(a)intel.com Tue Jul 11 14:34:53 2000 > From: "Ananthanarayanan, Arul" <arul.ananthanarayanan(a)intel.com> > To: "'Perry Wagle'" <wagle(a)cse.ogi.edu>, ixp1200(a)CS.Princeton.EDU > Subject: RE: UART interrupts > Date: Tue, 11 Jul 2000 14:34:47 -0700 > MIME-Version: 1.0 > Perry, > > The documentation refers to the B stepping of the IXP1200. You > probably have > the A step of the processor and there are differences in handling the UART. > In the A stepping, bit 6 of the IRQ register is really the UART interrupt > (not the RTC). > You do need to clear the UART interrupts on the A step, so the mystery bit 9 > of the > UART_SR is what you need to set before exiting your handler. > There is a specification update on the Version 1.0 developers CD that > details the changes > for the A step. > Arul > -----Original Message----- > From: Perry Wagle [mailto:wagle@cse.ogi.edu] > Sent: Monday, July 10, 2000 5:22 PM > To: ixp1200(a)CS.Princeton.EDU > Subject: UART interupts > Has anyone gotten the UART interupts to work right? > I can read and write the UART just fine with polled i/o, but > interupts seem all messed up. I suspect the March 2000 IXP1200 > Network Processor Programmer's Reference is either false or I wasn't > given the board that it corresponds to. > Section 4.6.10 UART_CR (page 4-78): The UART generates a IRQ interupt > regardless of what I set set bit 9 (UIS, select IRQ or FIQ) to. > Setting bit 4 (RIE) is necessary to get IRQ interupts to fire, but > once I get them to fire, they won't stop firing. My IRQ handler will > be entered even if there are no characters ready to read from the UART > after I've left it for the first time. It won't enter my IRQ_handler > the first time until I've send a character. If I read the UART_CR > register, I get what I set it to except for UIS is always zero; ie, > 0x001700f0 (9600baud, the mystery bit 9 (UIS) is clear, transmit > interupts disabled, uart enabled, 8 bits data size, recieve interupts > enabled, 1 stop bit, no parity). > What is the mystery bit 9? > Section 4.6.9 UART_SR (page 4-77): This register address is always [?] > equal to "RXD pin set, transmit fifo full, ... , transmit fifo empty, > ..." (0x00000180) when my IRQ_handler is entered (except the first > time, when the "receive fifo ready" bit is also set (0x00000190)). > It would seem impossible that the transmit fifo is both full and empty > at the same time, what's going on? > Section 4.6.17 IRQ (page 4-86): When my IRQ_handler is entered, this > register is always equal to "IRQ interupt generated by RTC" (bit 6 = > 0x00000040), and no matter what I do to the UART status, control, and > data registers, its still set when my IRQ_handler is ready to leave > (ie, after its read one character after waiting for it to become > available). I suspect that since I'm not succeeding in clearing the > interupt condition, that its being reissued just as soon as I leave > the interupt handler. > I'm thinking that bit 6 corresponds to the UART, and not the RTC, > since my IRQ handler is only entered for the first time when I send a > character to the IXP1200 serial port. I have apparently not succeeded > (yet) in getting the RTC to generate an interupt. What is the correct > layout of the IRQ register? > My foreground job (spin the led with an ever-incrementing unsigned > char counter in a tight infinite loop) usually doesn't make progress > after my IRQ_handler is entered for the first time. But when it does, > it has only 2-3 "favorite" values that the led ends up displaying. It > seems odd that I've got such a good phase lock on 2-3 out of 256 > possible values, but I can't imagine what this information is telling > me. > -- Perry

1 0

RE: UART interrupts
by Ananthanarayanan, Arul 11 Jul '00

11 Jul '00

Perry, The documentation refers to the B stepping of the IXP1200. You probably have the A step of the processor and there are differences in handling the UART. In the A stepping, bit 6 of the IRQ register is really the UART interrupt (not the RTC). You do need to clear the UART interrupts on the A step, so the mystery bit 9 of the UART_SR is what you need to set before exiting your handler. There is a specification update on the Version 1.0 developers CD that details the changes for the A step. Arul -----Original Message----- From: Perry Wagle [mailto:wagle@cse.ogi.edu] Sent: Monday, July 10, 2000 5:22 PM To: ixp1200(a)CS.Princeton.EDU Subject: UART interupts Has anyone gotten the UART interupts to work right? I can read and write the UART just fine with polled i/o, but interupts seem all messed up. I suspect the March 2000 IXP1200 Network Processor Programmer's Reference is either false or I wasn't given the board that it corresponds to. Section 4.6.10 UART_CR (page 4-78): The UART generates a IRQ interupt regardless of what I set set bit 9 (UIS, select IRQ or FIQ) to. Setting bit 4 (RIE) is necessary to get IRQ interupts to fire, but once I get them to fire, they won't stop firing. My IRQ handler will be entered even if there are no characters ready to read from the UART after I've left it for the first time. It won't enter my IRQ_handler the first time until I've send a character. If I read the UART_CR register, I get what I set it to except for UIS is always zero; ie, 0x001700f0 (9600baud, the mystery bit 9 (UIS) is clear, transmit interupts disabled, uart enabled, 8 bits data size, recieve interupts enabled, 1 stop bit, no parity). What is the mystery bit 9? Section 4.6.9 UART_SR (page 4-77): This register address is always [?] equal to "RXD pin set, transmit fifo full, ... , transmit fifo empty, ..." (0x00000180) when my IRQ_handler is entered (except the first time, when the "receive fifo ready" bit is also set (0x00000190)). It would seem impossible that the transmit fifo is both full and empty at the same time, what's going on? Section 4.6.17 IRQ (page 4-86): When my IRQ_handler is entered, this register is always equal to "IRQ interupt generated by RTC" (bit 6 = 0x00000040), and no matter what I do to the UART status, control, and data registers, its still set when my IRQ_handler is ready to leave (ie, after its read one character after waiting for it to become available). I suspect that since I'm not succeeding in clearing the interupt condition, that its being reissued just as soon as I leave the interupt handler. I'm thinking that bit 6 corresponds to the UART, and not the RTC, since my IRQ handler is only entered for the first time when I send a character to the IXP1200 serial port. I have apparently not succeeded (yet) in getting the RTC to generate an interupt. What is the correct layout of the IRQ register? My foreground job (spin the led with an ever-incrementing unsigned char counter in a tight infinite loop) usually doesn't make progress after my IRQ_handler is entered for the first time. But when it does, it has only 2-3 "favorite" values that the led ends up displaying. It seems odd that I've got such a good phase lock on 2-3 out of 256 possible values, but I can't imagine what this information is telling me. -- Perry

1 0

Re: Question Regarding Tornado Software
by Scott C. Karlin 11 Jul '00

11 Jul '00

Perhaps I gave you the wrong impression in my original response. Let me try to clarify... With the exception of the command-line assembler for the microengines, we are not using any of the Windows-based tools for our development. (We are not using Tornado, Workbench, or Transactor.) All our development is based on GNU tools running on Linux. Since we are not using VxWorks/Tornado, I assume that we cannot run any of the examples which might be included on the development CD-ROM. When I stated that "the Tornado software is not mandatory," I simply meant that you do not need Tornado if you want to run code on the IXP1200. It probably *is* mandatory if you want to develop code using the environment described in the Intel documentation (VxWorks, NetApp, NT, ...). Hope that helps, Scott Petcharat Suriyachai writes: > > Did anyone load the VxWorks NetApp Image onto the IXP 1200? From the > manual the VxWorksNetApp.o image must be loaded onto the IXP 1200 to be > able to test the Workbench connection and to run projects. How did you do > this WITHOUT the VxWorks window? > > I have the following so far: > > ///////////////////////////////////////// > Attached TCP/IP interface to eeE0. > Attaching network interface lo0... done. > Loading... 602392 + 13020 + 45320 > Starting at 0x1000... > > Early serial debug initialized > muxDevLoad failed for device entry 0! > Attached TCP/IP interface to eeE unit 0 > Attaching network interface lo0... done. > 0x7ffe64 (tRootTask): dc0 - Failed to read ethernet address > NFS client support not included. > > > VxWorks > > Copyright 1984-1998 Wind River Systems, Inc. > > CPU: Level One ixp1200eb - ARM IXP1200 > VxWorks: 5.4 > BSP version: 1.0/948 > Creation date: Feb 16 2000 > WDB: Ready. > > ////////////////////////////////////// > > The next step based on the manual is "configuring and launching a target > server with Tornado." Since the Tornado is not mandatory, I don't really > know what to do after this. The workbench will hang if I try to debug a > program. The error is "Error opening network connection to node > TestTarget." I assume that the host doesn't know the ip address of the > Evaluation system. Any suggestion? > > Thank you, > Pat > > > > --On Friday, June 30, 2000, 4:10 PM -0400 "Scott C. Karlin" > <scott(a)CS.Princeton.EDU> wrote: > > > 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. > > > > -Scott

1 0

Re: UART interupts
by Scott C. Karlin 11 Jul '00

11 Jul '00

Perry Wagle writes: > > Has anyone gotten the UART interrupts to work right? I haven't tried. The only information I can give is that I know the VxWorks bootloader runs with UART interrupts enabled. To use polled I/O, I have to explicitly disable them: #define UART_CR 0x90003800 /* UART Control Register Address */ #define XIE 0x00000100 /* Transmit interrupt enable bit */ #define RIE 0x00000010 /* Receive interrupt enable bit */ void noUartInts(void) { volatile unsigned long *ptrCR = (unsigned long *) UART_CR; *ptrCR &= ~(XIE | RIE); } (Since you stated that you got polled I/O to work, you are probably already doing the same thing.) My recommendation is to look through the code source from the development CD-ROM. It may have the source for the bootloader which would include the interrupt enabling and handling code. Hopefully, someone else on the list can give a more helpful answer than mine. Good Luck, Scott

1 0

21440 Network Statistic Counters
by Tammo Spalink 06 Jul '00

06 Jul '00

Are these counters mapped to the memory locations specified in the manual (21440 Datasheet Rev 2.0, Mar 2000)? The manual gives per-counter offsets. Then it says that these offsets are relative to either 0x100 or 0x200. If they are read at 0x100 the counters are reset. Regardless of where I read them or how often I read them, I always get back the number "1" for all counters. I am reading them as 32-bit quantities. I am using the following as the per-port absolute CSR offsets: static uint32 Port_CSR_Addrs[] = { 0x38400000, 0x38401000, 0x38402000, 0x38403000, 0x38404000, 0x38405000, 0x38406000, 0x38407000, }; I was hoping to use them to further diagnose my previously mentioned problem. Thanks, Tammo

1 0

21440 transmit problems
by Tammo Spalink 05 Jul '00

05 Jul '00

I am currently unable to transmit data using the 21440 on the IXP1200 evaluation board. I hope someone can give me some insight into what I may be doing wrong. I am only having problems with transmit, my receive code appears to work fine. I have two of the 100Mbps ports connected by a Xover cable. All I am trying to do is send a minimal ethernet packet from one port to the other. Here is a minimal program that exhibits my problem (I load it into the S-ARM with the VxWorks loader). I am presenting pseudo-code for readability. I can send you real code too if that helps. // Initialize 21440 ports 6 & 7 which are connected by an X-cable // The port CSRs are at offsets 0x38406000 and 0x38407000 respectively. // PORT_CTR is at 0x14, FFO_BUS at 0x48, TX_ERR_MOD at 0x50, and // TX_TSHD_BOFF at 0x54 from the initial offsets. PORT_CTR = PTRST & CTRST PORT_CTR = CNRST FFO_BUS = BEND TX_ERR_MOD = XCLS & LCLS & UNFS TX_TSHD_BOFF = 0xAF (BLK = 84 bytes, TSD = 124 bytes) PORT_CTR = TXEN & RXEN INT_EN = STOPE & OVFCE & LNCHE & TXERE & TXOKE & RXEVE & RXOKE // Initialize the IX bus RDYBUS_TEMPLATE_PROG = 0xFFFFFFF7, 0xFFFFFFFB, 0xFFFFFFFF RDYBUS_SYNCH_COUNT_DEFAULT = 0 RCV_RDY_CTL = 0 XMIT_RDY_CTL = 0 RDYBUS_TEMPLATE_CTL = ER & TM & MS // Initialize a packet in SRAM static uint8 packet[] = { 0x11, 0x12, 0x13, 0x14, 0x15, 0x16, 0x21, 0x22, 0x23, 0x24, 0x25, 0x26, 0x00, 0x06, 0x01, 0x02, 0x03, 0x04, 0x05, 0x06 }; I copy this into SRAM and print it out again to verify that the copy worked correctly. BTW, is SRAM little-endian? // Initialize and start a uEngine I use it to run the following uCode program. ---- Start uCode ----- #macro imm32 [destReg, const] immed_w1 [destReg, ((const >> 16) & 0xFFFF)] immed_w0 [destReg, (const & 0xFFFF)] #endm #macro imm16 [destReg, const] immed [destReg, const] #endm #macro move [destReg, srcReg] alu [destReg, --, B, srcReg] #endm #macro set_field [reg, offset, val] alu [reg, reg, OR, val, offset] #endm #define BUFFER 0x1400 ; SRAM packet buffer .xfer_order $xfer0 $xfer1 $xfer2 $xfer3 $xfer4 $xfer5 $xfer6 $xfer7 imm32 [sram_addr, BUFFER] imm16 [tfifo_addr, 0] sram [read, $xfer0, sram_addr, 0, 8], ctx_swap t_fifo_wr [$xfer0, tfifo_addr, 0, 4], ctx_swap imm16 [control, 0] set_field [control, <<0, 6] ; PID set_field [control, <<7, 0] ; ERR set_field [control, <<8, 1] ; SOP set_field [control, <<9, 1] ; EOP set_field [control, <<10, 3] ; VLD set_field [control, <<13, 2] ; QWD set_field [control, <<16, 0] ; PREP set_field [control, <<17, 0] ; TXASIS set_field [control, <<18, 0] ; TXER move [$xfer0, control] imm16 [$xfer1, 0] imm16 [tfifo_addr, 128] t_fifo_wr [$xfer0, tfifo_addr, 0, 1], ctx_swap fast_wr [0, xmit_validate] fast_wr [1, thread_done] ctx_arb [kill] ---- End uCode ----- CONCLUSION: I expected that after this code ran (after the thread_done signal), I would get an TXOK interrupt on port 6 and an RXOK interrupt on port 7. However, all that happens is that XMIT_PTR is incremented from 0 to 1 and nothing else. What am I missing/forgetting? Thanks for any help or suggestions, Tammo

1 0

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

Loading MicroEngine code
by Tammo Spalink 08 Jun '00

08 Jun '00

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))); } -----

1 0

Hello, World (bare, no libs yet)
by Scott C. Karlin 09 May '00

09 May '00

Just an update to my previous post about building StrongARM tools under linux... As it turns out the "mysterious" file format the vxWorks boot loader expects is simply "coff-arm-little." After rebuilding the tools, I now have a "Hello, World" program which sends characters out the serial port. It does not use any library calls (e.g., printf). I am now in the process of getting the standard runtime libraries working. This way, I can use printf(). I'll let everyone know when this is working. In the meantime, in case anyone is interested, here's what I did to get it working: 1. Build the tools for arm-unknown-coff. I followed the steps in the CrossGCC FAQ online at http://www.objsw.com/CrossGCC/ and used GCC 2.95.2, binutils 2.9.1, and newlib 1.8.2. Before building the tools, I edited newlib-1.8.2/newlib/configure.host by commenting out both ARM_RDP_MONITOR and ARM_RDI_MONITOR. 2. Here is the program: *************************************************************************/ /* ** UART Definitions */ #define UART_SR 0x90003400 /* UART Status Register Address */ #define TXF 0x00000080 /* Transmit FIFO full bit */ #define RXR 0x00000010 /* Receive FIFO ready (not empty) */ #define UART_CR 0x90003800 /* UART Control Register Address */ #define XIE 0x00000100 /* Transmit interrupt enable bit */ #define RIE 0x00000010 /* Receive interrupt enable bit */ #define UART_DR 0x90003C00 /* UART Data Register Address */ /* ** Forward References */ static void noUartInts(void); static void putchar(int c); static void puts(char *s); static int getchar(void); /* ** Entry Point */ void __main(void) { int c; noUartInts(); puts("Hello, World!\n\r"); puts("\n\r"); puts("Enter characters to be echoed:\n\r"); while(1) { c = getchar(); if(c == '\r') { puts("\n\r"); } else { putchar(c); } } } /* ** Disable UART transmit/receive interrupts */ static void noUartInts(void) { volatile unsigned long *ptrCR; ptrCR = (volatile unsigned long *) UART_CR; *ptrCR &= ~(XIE | RIE); } /* ** Send a single character */ static void putchar(int c) { volatile unsigned long *ptrSR; volatile unsigned long *ptrDR; ptrSR = (volatile unsigned long *) UART_SR; while((*ptrSR & TXF) != 0) ; ptrDR = (volatile unsigned long *) UART_DR; *ptrDR = (unsigned long) c; } /* ** Send a null terminated string */ static void puts(char *s) { int c; while((c = *s++) != '\0') { putchar(c); } } /* ** Get a character */ static int getchar(void) { volatile unsigned long *ptrSR; volatile unsigned long *ptrDR; ptrSR = (volatile unsigned long *) UART_SR; while((*ptrSR & RXR) == 0) ; ptrDR = (volatile unsigned long *) UART_DR; return (int) *ptrDR; } /*************************************************************************/ 3. Here are the commands I used to compile the code: arm-unknown-coff-gcc -I. -nostartfiles -nodefaultlibs \ -fno-builtin -mcpu=strongarm110 -mapcs-32 -mno-sched-prolog \ -fvolatile -Wall -Wstrict-prototypes -O2 -c hw.c -o hw.o arm-unknown-coff-ld -o hw.coff hw.o -X -N -e ___main \ -Ttext 00001000 -Scott

1 0

re: IXP1200 Board as a Peripheral
by Perry Wagle 08 May '00

08 May '00

We are porting linux, with our mods, to the IXP1200. We just got our IXP1200's last week. I have one configured to vxworks, and the other to angel. With help from Dirk Brandewie at Intel, we successfully did a LED helloworld with angel and angelboot (ftp://ftp.netwinder.org/users/n/nico/). My current task is hacking the bios at (ftp://ftp.arm.linux.org.uk/pub/linux/arm/source/boot/) to download via angel over serial-line to the card to then boot off the network ala vxworks. I'm hoping this approach will dovetail to recreating and extending the stuff described below. We've already got linux running on a SA110 (ebsa285 board). Its a PCI slave running on a Pentium Linux box. Using the patches at (ftp://nt4.el.utwente.nl/pub/co285/), I was able to get Linux kernel 2.3.24 (but not 2.2.12) to boot over the PCI bus. To get this to go, the ROM on the ebsa285 board needed to be reprogrammed, and the kernels patched with the PCI mods that both permit the ebsa285 board to be initialized and a kernel loaded over the PCI bus, and to provide >>>IP-over-PCI<<<, which is then used to mount the root filesystem via NFS. Since this is a clean implementation of IP, it also permits the host kernel to route packets outwards to other systems. I'm rather taken with this IP-over-PCI, but it doesn't look like that code is being maintained (last time stamp is June 1999), but I haven't gotten around yet to querying the mailing lists to find out what the deal is. Having the root file system be accessible and modifiable by other systems aids debugging: watch those timestamps change during boot to see how far the boot sequence got; or watch the pci network traffic via tcpdump. You also get to build stuff on your cross-development platform, and write directly to the filesystem image. I'm wondering how bad I want to maintain this stuff myself. -- Perry Wagle (wagle(a)cse.ogi.edu)

1 0

IXP1200 Board as a Peripheral
by Scott C. Karlin 08 May '00

08 May '00

At some point soon, we would like to move the IXP1200 board from the passive PCI backplane to a traditional Pentium motherboard. I am starting this thread so that we can get a feel for the issues involved. It seems that there are several hurdles we must clear before doing this: 1. The PCI arbiter function must be disabled on the board. * Supported by J13 (CFN1) 2. The PCI reset function must be disabled on the board. * Supported by J14 (CFN0) 3. The board must be configured so that generates interrupts rather than receives them. * (Partially?) Supported by J10, J11, J17, and J9. 4. There must be a way to get the application code into the board. * One way would be to have the board boot up in a passive mode (selected by an unused combination of the GPIO[3:0] jumper settings) where the StrongARM waits for code to be written from the PCI bus by the host. On some signal from the host, the boot code would jump to a well-known address to run the downloaded code. Is this list complete? I know the engineers at Intel have been thinking about the problem because they wanted to do exactly this for the sessions at the Intel Developer Forum in Palm Springs. Thoughts? Ideas? Comments? -Scott

1 0