On 01/05/2011 05:29 PM, Gilles Chanteperdrix wrote:
> Steven A. Falco wrote:
>> On 01/05/2011 04:33 PM, Gilles Chanteperdrix wrote:
>>> Herrera-Bendezu, Luis wrote:
>>>> Gilles:
>>>>
>>>>> Herrera-Bendezu, Luis wrote:
>>>>>> Hello:
>>>>>>
>>>>>> I have the following setup:
>>>>>> PPC405EX
>>>>>> Linux 2.6.30.3
>>>>>> Xenomai 2.4.10
>>>>>> I-pipe 2.7-02
>>>>>> ppc_4xx-gcc (GCC) 4.2.2
>>>>>> Configuration file is attached
>>>>> Do you have the same issue with the latest version of the I-pipe patch
>>>>> for this same version of the Linux kernel? It should be 2.8-00.
>>>> Tried I-pipe 2.8-00 which needs Linux 2.6.32.
>>> Sorry, I misread the ftp list, I was rather thinking about:
>>> http://download.gna.org/adeos/patches/v2.6/powerpc/older/adeos-ipipe-2.6.30.3-powerpc-DENX-2.7-06.patch
>>>
>>>
>>> It resulted on same problem
>>>> as reported with Linux 2.6.30.3 I-pipe 2.7-02.
>>>>
>>>> Was there any particular set of changes that you expected it could fix the
>>>> problem? Do you think more recent versions may work? If yes, which version
>>>> could be tried?
>>> Yes, there was a fix, specifially in the powerpc tree, with mappings
>>> issue. But I think it is older than 2.6.32.
>>>
>>> Now that I look at your message again, your problem seems more likely to
>>> be in your code. Specifically, you say: "bus address returned by
>>> pci_alloc_consistent()". I do not think pci_alloc_consistent return
>>> value is a bus address. The dma_handle returned by pointer probably is.
>>> But I am not sure you are supposed to know this.
>>
>> pci_alloc_consistent() returns two values. The kernel address is
>> returned directly (as a void *), and the bus address is returned
>> through the dma_handle pointer (third function argument).
>>
>> Luis' original email indicated that he tried rtdm_mmap_to_user()
>> on the kernel address, and he tried rtdm_iomap_to_user() on the
>> bus address. Either way caused the crash he reported.
>
> Ok. Could you try to do the same operation with the native API? You just
> have to pass H_SHARED | H_DMA | H_NONCACHED as flags to rt_heap_create
> to get the same effect as pci_dma_alloc_coherent.
>
> Just to see if the error lies in RTDM implementation or in Xenomai
> generic code.
>
>
>>
>> We have a home-grown program (mm) that basically opens /dev/mem
>> and allows peek/poke. Using that with the bus address works to
>> access the memory. We also pass that address to our hardware,
>> and it correctly DMAs the data. So we believe the bus address
>> is correct.
>
> You mean much like devmem2? Now even part of the busybox?
I had not known about devmem2 when I wrote my "mm" program; "mm"
turns out to be very similar to devmem2.
One difference is that I use mmap64() rather than mmap(), because
the PowerPC440EPx uses 36-bit addresses even though it has a 32-bit
instruction set. Other than that, the two programs are remarkably
similar.
Steve
>
>>
>> I believe Luis has also tried a third approach - allocating with
>> kzalloc(size, GFP_DMA), and using rtdm_mmap_to_user() on the
>> resulting pointer. That works, but getting the bus address is
>> a bit ugly - basically page_to_phys(virt_to_page()) of the pointer.
>>
>> So there is something different about the way pci_alloc_consistent()
>> allocates memory as compared to kzalloc(GFP_DMA). kzalloc(GFP_DMA)
>> works with rtdm_mmap_to_user() but pci_alloc_consistent() does
>> not.
>
> This gives me an idea. Could you try the following patch? Even before
> trying the native API.
>
> diff --git a/ksrc/skins/rtdm/drvlib.c b/ksrc/skins/rtdm/drvlib.c
> index 3495e63..d7dd3db 100644
> --- a/ksrc/skins/rtdm/drvlib.c
> +++ b/ksrc/skins/rtdm/drvlib.c
> @@ -1810,7 +1810,7 @@ static int rtdm_mmap_buffer(struct file *filp, struct
> vm_area_struct *vma)
> vaddr = (unsigned long)mmap_data->src_vaddr;
> paddr = mmap_data->src_paddr;
> if (paddr == 0) /* kmalloc memory? */
> - paddr = __pa(vaddr);
> + paddr = page_to_phys(virt_to_page(vaddr));
>
> maddr = vma->vm_start;
> size = vma->vm_end - vma->vm_start;
>
>
--
A: Because it makes the logic of the discussion difficult to follow.
Q: Why shouldn't I top post?
A: No.
Q: Should I top post?
_______________________________________________
Xenomai-help mailing list
[email protected]
https://mail.gna.org/listinfo/xenomai-help
