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

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