Very useful response. At the least it verifies that my conclusions are not totally unfounded. I suppose it could be just dumb luck that it works at all - but I also wonder if there's not something that kernel gurus know about what the first <n> pages of memory are used for, and the author took advantage of that. I also see that on my system, kernel code starts at 0x08000_8000. Still not a good practice though IMO.
I'm wondering if there isn't some way to use the DT to not only enable the PRUSS, but also select a driver, and configure the driver parameters (e.g. "extram_pool_sz") automatically. I read that the remoteproc and uio drivers conflict, so none is loaded by default. I suppose it would require a change to the pruss driver (whatever reads the "ti,pruss-v2" entry in the device tree) to support this, but it would be convenient. Thanks. On Friday, March 10, 2017 at 11:52:42 AM UTC-8, din...@gmail.com wrote: > > 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/4f61a684-395d-4248-80c3-0c0dbeb6f986%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
