- ixp1200 - lists.cs.princeton.edu

Re: Hard Reset of IXP1200 over PCI?
by Scott C. Karlin 20 Feb '01

20 Feb '01

I performed the experiment and answered my own question. It seems that writing 0xFFFFFFFF to the IXP1200_RESET register from the PCI bus does indeed reset the IXP1200. As expected, the reset knocks the IXP1200 off of the PCI bus. However, once I restored the PCI configuration registers to their original state, the board worked fine. Can anyone from Intel confirm (to the list) that the only reason a PCI device should not write to the IXP1200_RESET register is that the board will be deconfigured from the PCI bus? Scott > From: "Scott C. Karlin" <scott(a)CS.Princeton.EDU> > Subject: Hard Reset of IXP1200 over PCI? > To: ixp1200(a)CS.Princeton.EDU > Date: Wed, 14 Feb 2001 14:50:07 -0500 (EST) > > I'd like to be able to perform a hard reset of the > IXP1200 over the PCI bus. Most of the documentation > seems to indicate that I cannot do this. However, > the IXP1200 Programmer's Reference Manual seems to > indicate that it might be possible (but not allowed). > > Section 4.7.13 IXP1200_RESET indicates that the > IXP1200_RESET register can be read and written > from offset 0x7C. However, the paragraph directly > above says that "PCI devices must not write to this > register." > > What happens if I do? (I assume that the IXP1200 > will reset and clear the PCI registers including the > BAR set by the host machine. If I promise to put the > board back in the same place in the PCI memory map, > will everything be OK?) > > Scott

1 0

Hard Reset of IXP1200 over PCI?
by Scott C. Karlin 14 Feb '01

14 Feb '01

I'd like to be able to perform a hard reset of the IXP1200 over the PCI bus. Most of the documentation seems to indicate that I cannot do this. However, the IXP1200 Programmer's Reference Manual seems to indicate that it might be possible (but not allowed). Section 4.7.13 IXP1200_RESET indicates that the IXP1200_RESET register can be read and written from offset 0x7C. However, the paragraph directly above says that "PCI devices must not write to this register." What happens if I do? (I assume that the IXP1200 will reset and clear the PCI registers including the BAR set by the host machine. If I promise to put the board back in the same place in the PCI memory map, will everything be OK?) Scott

1 0

IXP1200 + wireless LAN
by Sundar Ramachandran 14 Feb '01

14 Feb '01

Hello, Does anybody know of any kind of development in Linux IXP1200 and wireless LANs? I'm trying to figure out how heterogeneous traffic between both wired and wireless subnets will affect the performance of the IXP1200,i.e. how well the processor will perform. By the way, I need a traffic generator to use in order to study the performance characteristics of the evaluation board. If you have any in mind, please let me know. Thanks. - Sundar. ================================================================================ "The optimist proclaims we live in the best of all possible worlds; and the pessimist fears this is true. " - James Cabell Sundar Ramachandran PHONE:(817)8015233 Dept. of Computer Science & Engg., E-MAIL: ramachan(a)acm.org UT Arlington, Arlington, TX 76019. ================================================================================

1 0

Flash Image and EXCEPT_ADDR
by Scott C. Karlin 12 Feb '01

12 Feb '01

I'm trying to understand how to build a flash image by looking at the files in BoardSupport/BootMgr and comparing with the actual flash contents (externally extracted using a device programmer). In the file romInit.s there are the following lines: L$_undef_vector: .long (EXCEPT_ADDR + 0x04) L$_swi_vector: .long (EXCEPT_ADDR + 0x08) L$_pabort_vector: .long (EXCEPT_ADDR + 0x0c) L$_dabort_vector: .long (EXCEPT_ADDR + 0x10) L$_irq_vector: .long (EXCEPT_ADDR + 0x18) L$_fiq_vector: .long (EXCEPT_ADDR + 0x1c) The file os.h defines EXCEPT_ADDR as 0x101FFFC0. I would expect this to generate the following sequence of long words: 101FFFC4 101FFFC8 101FFFCC 101FFFD0 101FFFD4 101FFFD8 101FFFDC Instead, the actual flash image is: 0000C004 0000C008 0000C00C 0000C010 0000C014 0000C018 0000C01C This suggests that EXCEPT_ADDR is 0x0000C000. Has EXCEPT_ADDR changed between the time we received our boards (BootMgr Version 1.0.1129) and when the CD-ROM was produced (BootMgr Version 1.0.1133) ? Scott

1 0

BldRom Functional Description?
by Scott C. Karlin 12 Feb '01

12 Feb '01

Does anyone have a functional description of the BldRom program? It's in the BoardSupport/Boot1200 subdirectory of the CD-ROM. I couldn't find a description of it in the documentation. Thanks, Scott

1 0

NT sample ARM script compilation
by Sundar Ramachandran 05 Feb '01

05 Feb '01

Hello people, I'm having a little bit of a problem with a few trivial things: 1. To run the sample ARM core scripts, I need to compile the assembly source code namely boot.s and boot.h to produce the binary and .list file. The makefile that comes with this (directory IXP1200\SA1_CoreLibs\Samples\saboot) does not seem to produce these files. Do I need to give it an option or add any shell commands in the makefile? It doesn't seem so, but when I do a make boot.bin it says there's nothing to be made. Please tell me what I'm missing. 2. Also, while loading VxWorks through the serial port from the NT host using hyperterm, either the VxWorks image does not load or if I get past it sometimes the Tornado target server does not confirm configuration, it says that the target is not attached. Well, the environment path has been set correctly, I'm running IIS FTP service, and the boot parameters are to my knowledge correct. Tornado is running as a service (if that information will help). 3. I've gone through the linux howto for IXP1200. Has someone tried this on debian. Is there anything to be considered for Debian installation? I'd really appreciate some help from you all. Thank you. - Sundar Ramachandran. ================================================================================ "If it takes a lot of words to say what you have in mind, give it more thought." - Dennis Roch Sundar Ramachandran PHONE:(817) 801-5233 Dept. of Computer Science & Engg., E-MAIL: ramachan(a)acm.org UT Arlington, Arlington, TX 76019. ================================================================================

1 0

mini-Linux HOWTO for IXP1200 revB boards
by Josh Fryman 11 Jan '01

11 Jan '01

hi all, scott asked about this URL regarding the official linux port to the IXP 1200 platforms. this howto is for revB silicon boards, and tells you how to check whether yours is B or not. hope people not aware of it find it useful ... http://www.netwinder.org/~urnaik/ixp1200_howto.html cheers, josh fryman

1 0

RE: IXP Bus Endian Mode
by Hooper, Donald 08 Dec '00

08 Dec '00

All the CD Beta releases were tested with IX Bus in big and little endian mode. There are customers using IX Bus in production systems little endian mode. You have to program the MAC device to be little endian to get bytes swapped. Setting the RDYBUS_TEMPLATE_CTL 5 only causes byte enables pins to be interpreted correctly for little endian. Don -----Original Message----- From: Naik, Uday Sent: Thursday, December 07, 2000 10:36 PM To: Joe, Robert; IXP1200 Users; 'ixp1200(a)CS.Princeton.EDU' Subject: RE: IXP Bus Endian Mode I believe setting the IXBUS in Little Endian mode does not work. But you can set the Endian registers in the PCI bus controller for the IXP1200, to swap the data corectly as it goes over the bus. Uday -----Original Message----- From: Joe, Robert [mailto:robert.joe@intel.com] Sent: Thursday, December 07, 2000 7:32 PM To: IXP1200 Users; 'ixp1200(a)CS.Princeton.EDU' Subject: IXP Bus Endian Mode I am setting bit 5 in RDYBUS_TEMPLATE_CTL, but the IXP bus still appears to be running in Big Endian mode. Here are the details: B0 board in eval chassis Proprietary OS with the ARM running in Little Endian mode. 1.0 pwd_2f with only changes to the SDRAM packet base address In hw_init.uc just after the ready bus has been programmed immed[$xfer2, 0xF20] csr[write, $xfer2, RDYBUS_TEMPLATE_CTL], CTX_SWAP I have ARM code running which dequeues packets off SRAM/SDRAM as they were placed by the microengine receive threads. Ultimately I want to DMA the packet data across the PCI bus. However, because the IX bus is running in Big Endian mode, the packets appear in SDRAM byte swapped on longword boundaries (see HRM, pg 6-55). I know if I do a longword copy of the packet, the copied packet will appear in the correct order. But I want to avoid this overhead. In fact, this is probably the reason the PETH driver works? My thinking is, if I can get the IX bus running in Little Endian mode, the packet data will be in the correct order for my DMA over the PCI bus. Agree? Has anyone run pwd_2f with LITTLE_ENDIAN defined and Little Endian (bit 5) set in the RDYBUS_TEMPLATE_CTL? If you have: Where did you set the RDYBUS_TEMPLATE_CTL? What OS are you running and do you have the ARM running in Little or Big Endian (although this should not matter??) Are you seeing the packet data in Little Endian format? Robert Joe (858) 391 1849

1 0

RE: IXP Bus Endian Mode
by Naik, Uday 07 Dec '00

07 Dec '00

I believe setting the IXBUS in Little Endian mode does not work. But you can set the Endian registers in the PCI bus controller for the IXP1200, to swap the data corectly as it goes over the bus. Uday -----Original Message----- From: Joe, Robert [mailto:robert.joe@intel.com] Sent: Thursday, December 07, 2000 7:32 PM To: IXP1200 Users; 'ixp1200(a)CS.Princeton.EDU' Subject: IXP Bus Endian Mode I am setting bit 5 in RDYBUS_TEMPLATE_CTL, but the IXP bus still appears to be running in Big Endian mode. Here are the details: B0 board in eval chassis Proprietary OS with the ARM running in Little Endian mode. 1.0 pwd_2f with only changes to the SDRAM packet base address In hw_init.uc just after the ready bus has been programmed immed[$xfer2, 0xF20] csr[write, $xfer2, RDYBUS_TEMPLATE_CTL], CTX_SWAP I have ARM code running which dequeues packets off SRAM/SDRAM as they were placed by the microengine receive threads. Ultimately I want to DMA the packet data across the PCI bus. However, because the IX bus is running in Big Endian mode, the packets appear in SDRAM byte swapped on longword boundaries (see HRM, pg 6-55). I know if I do a longword copy of the packet, the copied packet will appear in the correct order. But I want to avoid this overhead. In fact, this is probably the reason the PETH driver works? My thinking is, if I can get the IX bus running in Little Endian mode, the packet data will be in the correct order for my DMA over the PCI bus. Agree? Has anyone run pwd_2f with LITTLE_ENDIAN defined and Little Endian (bit 5) set in the RDYBUS_TEMPLATE_CTL? If you have: Where did you set the RDYBUS_TEMPLATE_CTL? What OS are you running and do you have the ARM running in Little or Big Endian (although this should not matter??) Are you seeing the packet data in Little Endian format? Robert Joe (858) 391 1849

1 0

IXP Bus Endian Mode
by Joe, Robert 07 Dec '00

07 Dec '00

I am setting bit 5 in RDYBUS_TEMPLATE_CTL, but the IXP bus still appears to be running in Big Endian mode. Here are the details: B0 board in eval chassis Proprietary OS with the ARM running in Little Endian mode. 1.0 pwd_2f with only changes to the SDRAM packet base address In hw_init.uc just after the ready bus has been programmed immed[$xfer2, 0xF20] csr[write, $xfer2, RDYBUS_TEMPLATE_CTL], CTX_SWAP I have ARM code running which dequeues packets off SRAM/SDRAM as they were placed by the microengine receive threads. Ultimately I want to DMA the packet data across the PCI bus. However, because the IX bus is running in Big Endian mode, the packets appear in SDRAM byte swapped on longword boundaries (see HRM, pg 6-55). I know if I do a longword copy of the packet, the copied packet will appear in the correct order. But I want to avoid this overhead. In fact, this is probably the reason the PETH driver works? My thinking is, if I can get the IX bus running in Little Endian mode, the packet data will be in the correct order for my DMA over the PCI bus. Agree? Has anyone run pwd_2f with LITTLE_ENDIAN defined and Little Endian (bit 5) set in the RDYBUS_TEMPLATE_CTL? If you have: Where did you set the RDYBUS_TEMPLATE_CTL? What OS are you running and do you have the ARM running in Little or Big Endian (although this should not matter??) Are you seeing the packet data in Little Endian format? Robert Joe (858) 391 1849

1 0