- 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