Hi, I believe the example is indeed buggy, and works by accident. You can check "cat /proc/iomem" and see that your mapped region overlaps the kernel code.
If you need to properly allocate and map DDR between ARM and PRU, then I would suggest to: 1. Load PRU UIO with "modprobe uio_pruss extram_pool_sz=2097152" in order to tell it allocate contiguous memory. 2. Use prussdrv_map_extmem() from ARM side to map the allocated DDR chunk. Example <https://github.com/dinuxbg/pru-gcc-examples/blob/master/ov7670-cam/host-uio/pload.c#L294> 3. Get the physical DDR base address of the chunk by using prussdrv_get_phys_addr(). Example <https://github.com/dinuxbg/pru-gcc-examples/blob/master/ov7670-cam/host-uio/pload.c#L297> 4. Write the physical DDR base address to a pre-defined location in PRU DRAM. If you are using pasm, then just hard-code the pre-defined location. If your firmware is in ELF format, there is a bit nicer way <https://github.com/dinuxbg/pru-gcc-examples/blob/master/ov7670-cam/host-uio/pload.c#L207> . Regards, Dimitar On Tuesday, March 7, 2017 at 10:07:31 PM UTC+2, ags wrote: > > I have been able to load/start/run/stop a PRU core from 4.4.30-ti-r64 > using just the uio_pruss (& uio) drivers, without any of the prussdrv code. > Big milestone in my project. > > A long time ago I asked a question about the examples in the pru here: > https://groups.google.com/d/topic/beagleboard/Kv03QMsgOmo/discussion > > as did someone else here: > https://groups.google.com/d/topic/beagleboard/vnZ9eSzoo6Y/discussion > > but I found no answer to help me. From a thorough review of the examples > in the am335x_pru_package (using the prussdrv uio-based pru driver) here: > https://github.com/beagleboard/am335x_pru_package/blob/master/pru_sw/example_apps/PRU_PRUtoPRU_Interrupt/PRU_PRUtoPRU_Interrupt.c > > it *appears* to me that this example (to teach/illustrate proper use of > pru in the BB family) works only by luck - or taking advantage of some bit > of information that is undocumented (from my research). > > Specifically, when using the L3 DDR (main) memory to share data between > the A8 and PRU, it seems that rather than using the 256KiB size region > starting at 0x9c94_0000 (on my BBB rev C) it seems to simply hardcode > 0x8000_0000 and write away. See here: > > static int LOCAL_exampleInit () { > void *DDR_regaddr; > /* open the device */ > mem_fd = open("/dev/mem", O_RDWR); > if (mem_fd < 0) { > printf("Failed to open /dev/mem (%s)\n", strerror(errno)); > return -1; > } > /* map the memory */ > ddrMem = mmap(0, 0x0FFFFFFF, PROT_WRITE | PROT_READ, MAP_SHARED, mem_fd, > DDR_BASEADDR); > if (ddrMem == NULL) { > printf("Failed to map the device (%s)\n", strerror(errno)); > close(mem_fd); > return -1; > } > //FLush the flag locations of PRU0 and PRU1 > DDR_regaddr = ddrMem; > *(unsigned long*) DDR_regaddr = 0x00; > DDR_regaddr = ddrMem + 0x000000004; > *(unsigned long*) DDR_regaddr = 0x00; > return(0); > } > I can understand how this might work "by accident" if these first eight > bytes in DDR are not used. But that's not a good example. Questions: 1) Is > there some "magic" to this physical memory location that I'm missing out > on? Or am I mis-reading the code, and it is *not* just writing to physical > memory 0x0-0x7? 2) Is it correct that the actual DDR physical memory region > that is allocated by the uio driver is properly determined by examining > /sys/class/uio/uio<n>/maps/map1/{addr,size}? If not, how? I think this is > useful information that would be helpful to others if provided. Perhaps > even an update to the example, if my assertions are correct. > -- 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 beagleboard+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/db46432f-1830-4e5e-a4fe-a7671d0f74f3%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
