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(a)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(a)intel.com
>
>
