On Wednesday, 10 June 2015 20:03:22 UTC+2, Charles Steinkuehler wrote: > > In addition to the other thread, I'd suggest looking at the > BeagleLogic code. It's possible to move _large_ amounts of data > through the PRU to the DRAM, but it requires some finesse. >
My first intuition would be using EDMA. On Thursday, 26 March 2015 23:51:02 UTC+1, Charles Steinkuehler wrote: > > on the ARM side you won't ever see any changes unless you're careful about > your cache management (typically using kernel-mode code and the same sort > of memory semantics required when doing DMA transactions). > Mapping the memory as uncacheable and using appropriate barriers suffices (privilege is not needed, though typically baremetal code tends to run privileged anyway). I'd recommend just using the PRU data memory space for anything like > semaphores or mailboxes. The memory is already mapped with the proper > access flags to avoid ARM side caching issues, and the PRUs can access > the memory without stalling. Well in a baremetal application nothing is "already mapped". In fact an issue here is that the PRU memory space resides within the same 1MB section as peripherals, so if both are accessed from the A8 you'd need to set up a page table for that section to make PRU memory space normal uncacheable while making the peripheral space device-type. (Well, you don't *have* to, but if you care about performance...) I do agree with having the PRUs stick to PRU memory as much as possible. > I looked at your TI post, but it doesn't make much sense to me. I'm not > very familiar with starterware, or with the spinlock register you refer > to. I can say that the ARM atomic bus transactions are unlikely to work > properly between the PRU and the ARM if you're using the PRU shared > memory, but there are many other synchronizing constructs you can use. > I'm pretty sure that ARM atomic bus transactions (neither the old locked SWP nor the newer load/store-exclusive) will not accomplish anything useful, if they get anywhere beyond the CPU boundary at all. TI is however referring to the hwspinlock peripheral which (along with the mailbox peripheral) is specifically intended for inter-core synchronization. I personally would not be eager to use hwspinlock though. I'd also try to go for unidirectional messaging like you're saying. The mailbox peripheral looks quite reasonable for inter-core notification, especially if this is infrequent and you want to avoid polling, though I think you also may be able to do that purely with the rather elaborate PRUSS interrupt controller. When writing from the A8 to uncacheable memory, do remember to finish off with a memory barrier instruction since the A8 is allowed to (and *does*) buffer writes indefinitely otherwise. -- 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.
