On Tue, Mar 10, 2009 at 2:23 PM, Leon Woestenberg <leon.woestenb...@gmail.com> wrote: > Hello Vadim, Stefan, >
Hi Leon, thank you for your interest, the problem I was dealing with has been long fixed. What happened was that in the Read transaction response the FPGA was setting one of the header attributes to a value different from what the transaction originator (460GT root complex) requested. The analyzer was not even highlighting that as a potential issue (even though it was showing the discrepancy between request and response headers). It turned out that the 460GT PCIe core was much more sensitive (some would say closer to the spec and thus more correct) than some other CPUs, and was just ignoring the PCIe responses with incorrect header contents, eventually generating PCIe timeouts which caused and were reported as PLB timeouts (because this is where the CPU was waiting). Very poor error reporting mechanism, but we have to do with what we have to do :-) cheers, /vb > On Wed, Jan 14, 2009 at 5:42 PM, vb <v...@vsbe.com> wrote: >> On Wed, Jan 14, 2009 at 7:03 AM, Stefan Roese <s...@denx.de> wrote: >>> On Tuesday 13 January 2009, vb wrote: >>> >>>> I have several different targets with different PCIe components, but >>>> all using the same base CPU subsystem design, and on some of them PCIe >>>> components misbehave, namely, PCIe memory read transactions fail with >>>> a machine check after a timeout, even though the PCIe side of things >>>> is fine (when looking with a protocol analyzer). >>> >> on our own design). The one which fails is based on the very similar >> 460GT based platform, but uses an Altera FPGA with a standard Altera >> PCIe interface implementation. >> >> What happens is that config space transactions (both read and write) >> and memory writes work fine, but attempts to read Altera's memory >> mapped space causes a machine check with very vague error reporting. >> > > Vadim, I am currently designing a Altera FPGA PCIe application and > testing on the AMCC460EX as one of the targets, so I may provide some > hints on where to look. I debugged *without* protocol analyser and > also hit some emachine check exceptions when the FPGA logic was still > misbehaving. > > Let me just throw some hints and references your way, hope they might be > useful: > > Do you use a reference design? > Does the FPGA application respond to the reads? > Do you map the BARs correctly? > Do you use 32-bit read/writes, 32-bit alignment? > > In the linux-next GIT tree, my driver for the Altera PCIe Chaining DMA > design is included: > drivers/staging/altpciechdma/altpciechdma.c > > Best regards, > -- > Leon > _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
