> > *Could you tell me where I can find it?* >
http://processors.wiki.ti.com/index.php/PRU_Linux_Application_Loader_API_Guide You can also read through the code . . . but I will mention the last time I was reading through the code, and reading up on this API, the amount of memory used is not limited to 8k or whatever is default as shipped. Another interesting thing I realized, is that mmap() can map any register through /dev/mem/ so should be easy to access the PRU scratchpad from "userspace". Meaning, you still have the latency from Linux to memory, but PRU accesses should be much faster. Not to mention having the ability of "broadsiding" from one PRU to the other . . .granted, I'm having a hard time tryign to think of a usecase where that might be useful . . . On Wed, Feb 10, 2016 at 2:15 PM, Bill Gray <[email protected]> wrote: > Charles, > > Thanks so much for a definitive answer to this question!!! > > Perhaps even more than the answer, I am fascinated by the account you give > of how you know this to be the case! > > I would like to have a better understanding of kernel drivers and DMA > memory. As an educational exercise I would like dig through the PRU kernel > driver and see this code for myself? > > Could you tell me where I can find it? > > Thank you very much. > > Bill > > On Wed, Feb 10, 2016 at 12:15 PM, Charles Steinkuehler < > [email protected]> wrote: > >> If you dig through the user-mode uio_pruss code, you will see that the >> PRU itself, the PRU memory and control registers, and the large shared >> buffer is all accessed via a mmap on the /dev/uio_pruss* device. >> >> If you dig in the PRU kernel driver, you will see the dram shared >> buffer is allocated and handled as DMA memory. The >> dma_alloc_coherent() call used to allocate the memory grabs a >> physically contiguous chunk, provides physical and virtual addresses, >> and sets the page caching flags as needed for the architecture. >> >> On 2/10/2016 9:07 AM, Tyler Turcotte wrote: >> > I have been using the BeagleBone PRU and have been accessing and >> mapping >> > memory this way and thus far it seems as though it is one contiguous >> > address. I am relatively new to Beaglebone so maybe one of the more >> > experienced may want to step in on this one. >> > >> > Once I have used prussdrv_get_phys_addr to get the physical address it >> > seems to store to one contiguous memory and is limited to 8mb. >> > >> > I believe it is allocated contiguous from uio_pruss as well. >> > >> > >> > On Friday, February 5, 2016 at 7:33:59 PM UTC-5, Bill Gray wrote: >> >> >> >> Hi, >> >> >> >> I've got PRU0 of my BBB pulling in 12 Bytes of data from a ADC with a >> >> sampling frequency of 31250hz. >> >> >> >> I want to stash all of this data in an array that lives in DDR >> memory. I >> >> would like to make the array 0x4000 bytes (16kB) large. This would >> give me >> >> 1365 12 byte records and about 43ms of data to play with. >> >> >> >> I'm currently using prussdrv_map_extmem() to hook me up with the DDR >> >> memory. It provides me with a memory block that is 256kB, so I have >> plenty >> >> of room. >> >> >> >> The question I have is... can I count on the physical address in this >> >> 256kB block of memory to be contiguous? >> >> >> >> I'm pretty new to linux memory management, but I see that the "page >> size" >> >> is only 4kB... so I imagine that the virtual memory system might chop >> my >> >> 256kB block up into bits which might not necessarily have contiguous >> >> addresses. >> >> >> >> If I can count on contiguous addresses, this radically simplifies the >> >> memory access code in the PRU. If I can't... well, then I can't, and >> I've >> >> got to figure something else out. >> >> >> >> When I run experiments I see that the physical addresses are >> contiguous, >> >> but are they guaranteed to be? or has this just been "lucky"? >> >> >> >> Thanks, >> >> >> >> Bill >> >> >> >> >> >> >> > >> >> >> -- >> Charles Steinkuehler >> [email protected] >> >> -- >> For more options, visit http://beagleboard.org/discuss >> --- >> You received this message because you are subscribed to a topic in the >> Google Groups "BeagleBoard" group. >> To unsubscribe from this topic, visit >> https://groups.google.com/d/topic/beagleboard/N47C7-WdsZE/unsubscribe. >> To unsubscribe from this group and all its topics, send an email to >> [email protected]. >> For more options, visit https://groups.google.com/d/optout. >> > > > > -- > Bill Gray > Velkess > 415 407 7356 > > -- > For more options, visit http://beagleboard.org/discuss > --- > You received this message because you are subscribed to the Google Groups > "BeagleBoard" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > For more options, visit https://groups.google.com/d/optout. > -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups "BeagleBoard" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
