Solution. The exception was not due to a bug in the IXP hardware. The exception was a result of incomplete/incorrect information given in the IXP1200 Hardware Reference Manual, Section 5.3.1.3. The Type 0 data in Table 5-4 states that StrongARM core address bits 23:22 are NOT equal to 11. This should read: If bits 23:22 are NOT equal to 11, then AD25:AD11 will be a copy of the StrongARM core address -- note that AD31:AD26 are not usable in this mode. If bit 23:22 are EQUAL to 11, the StrongARM core address AD15:AD11 will be decoded, and the appropriate bit in AD31:AD11 will be set. When bits 23:22 are set to 11 (0x3) the proper configuration address is decoded, and the entire configuration space (AD31:AD11) is available. jk
-----Original Message----- From: Krueger, Jon Sent: Friday, October 13, 2000 3:50 PM To: ixp1200@CS.Princeton.EDU Cc: Varsanyi, Eric Subject: PCI Configuration Space
I found an interesting "problem" with the IXP1200.
When doing Type 0/1 configuration reads with the IXP, any attempt to access devices using AD26-AD31 for their IDSEL decoding will produce nasty results.
With VxWorks, you'll get an exception, killing process execution. With the custom OS I'm running now, I drop into the debugger and the ARM PC is off in deep space... :-(
This may be a design decision by the IXP engineers. They do support a full 10 devices, but they assume that the devices will be decoded within the config space of AD11-AD25. I'm guessing a bit here, but it seems that this is the case.
There are SBCs and "passive" backplanes which hardwire device IDSELs to the higher areas of config space AD26-AD31.
Something to watch out for...
jk
Jon Krueger Senior Engineer Intel Corporation Network Equipment Division
13280 Evening Creek Drive San Diego, CA 92128 (858) 391-1710 jon.krueger@intel.com