Please do also realize that I left out mmc media on purpose in the context of high speed "permanent" storage. Then the GPMC connected to *something* could possibly be of use too.
On Sat, Jul 30, 2016 at 2:13 PM, William Hermans <[email protected]> wrote: > > > On Sat, Jul 30, 2016 at 1:54 PM, Charles Steinkuehler < > [email protected]> wrote: > >> DMA is not really necessary, as the PRU can read/write to the ARM >> system DRAM and the ARM can read/write to the PRU memories. There are >> some ways DMA could improve performance of a high-performance >> application using both the ARM and the PRU heavily, but it's not a >> clear win in all cases. >> >> However, any kernel-level physical memory access for talking to the >> PRU is going to have a lot in common with doing DMA. You need to map >> physical addresses into logical memory space, issue fence instruction >> to guarantee memory coherency, etc. Basically, the PRU can be >> considered a "custom" DMA controller, in that it is something other >> than the application processor that is accessing and changing main >> memory contents. The usage semantics for talking to the PRU in kernel >> space are very similar to using DMA. Just 's/DMA/PRU/g' and you won't >> go too far wrong! ;-) >> >> -- >> Charles Steinkuehler >> [email protected] > > > Well, what I was thinking, and perhaps this would have more of a home on > the Beagleboard X15. . . Is that, you have a PRU reading data in some > fashion from an external peripheral, at high speeds. Then you want to get > that data out of the PRU shared memory as fast as possible to some external > storage. > > With the Beaglebones, you're going to be limited by your fastest block > device, or interface. In the case of the Beaglebone, that would probably be > USB, which as it stands ( stock ) is not really much faster than ethernet. > Real world performance that is. > > But on the X15 where you have dual GbE, PCIe, USB3.0, and SATA . . . you > have much faster external "storage". IN this case, you might want a DMA > buffer in kernel space that blasts this data directly onto the storage > peripheral. All the while keeping your CPU load as low as possible, for > other potential duties. > > But as I said, I have no practical hands on here, but the theory seems > possible at first glance. > -- 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]. To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/CALHSORqkVP23frNgLcaM-Po48939WzBOmo_LN%2Bh626bRzwDFwA%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
