Hi,
>> You haven't really provided enough information.
>
> Sorry about that. I grabbed one of the h/w guys to help out.
No problem. Just wanted to check the basics had been covered.
Sounds like they have.
> On the local bus frequency is 33.0 MHz. (66.0 PCI_CLK_IN). See the
> attached .cfg script for memory map.
It got dropped by the mailer. Don't sweat it.
>> 2. If its on the local bus, do you access it using GPCM or UPM?
>> Have you setup either correctly?
>> Have you confirmed the bus timing with a logic analyzer?
>
> GPCM.
> We have confirmed the timing both in functionality (in the debugger) and
> with a logic analyzer (plus oscope for setup and hold times).
> We have stand-alone C-code that runs in CodeWarrior that bangs away at
> the registers of this device and the hardware runs perfectly using the
> .cfg script settings..
Great.
>> 3. Have you created a bus functional model of the processor bus
>> that you have then run with your FPGA bus in ModelSim to
>> confirm that your FPGA performs correctly.
>
> Yes, we have. Also, checked in h/w (see 2 above)
Nice :)
>> 4. Have you tried burst and non-burst access by either using
>> DMA, or treating the memory area as cacheable or non-cacheable?
>> Have you checked those cases with simulation and then
>> with a scope or logic analyzer?
>
> Always non-burst at this point.
Are you sure?
When I was playing with the Yosemite board, I was having trouble
with a PCI card due to caching ... here's a code snippet from
the mmap routine of a driver:
/* Flags to stop the processor treating PCI memory as
* cacheable (see asm-ppc/pgtable.h)
*
* (thanks to Travis Sawyer from the ppc-embedded list)
*
* I could have used '#ifdef CONFIG_44x', but 40x uses
* these flags too, as do other processors. So just check
* whether the flag exists.
*
* TODO:
* p425 Rubini; use pgprot_noncached()
*
* asm-ppc/pgtable.h defines it as setting these two flags
*
* So, that appears to be the 'portable' way to do it.
*
* drivers/char/mem.c uses pgprot_noncached()
*/
#ifdef pgprot_noncached
vma->vm_page_prot = pgprot_noncached(vma->vm_page_prot);
#endif
In that particular case, I think I wasn't seeing data transferred
to the bus until a cache flush occurred. Its possible that in your
case a burst is triggered to your hardware.
How does your BFM+simulation react to bus bursts?
Can you probe the bus when you trigger the seg-fault to see
if caching is the problem?
I'm not sure that a bus error can cause a segfault. When I
get my boards, I'll generate bus parity errors to see what
kernel routines it triggers. So, chances are this is not
the source of your error.
>> 5. Did you try running stand-alone tests in U-Boot, to go for a
>> more bare-metal debug approach?
>
> I assume the bare-metal debug approach is using a JTAG debugger
> connection and CodeWarrior. We started there and now are trying to
> access the same device(s) via linux drivers.
Yep, sounds good.
Ok, so assuming you come back with the fact that the seg-fault
occurs without bursting. Lets take a look at your driver code.
Cheers,
Dave
_______________________________________________
Linuxppc-embedded mailing list
Linuxppc-embedded@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-embedded
