I am trying to figure out memory mappings in the PRU, and especially ddrMem vs extRAM, and although there is information here and there, I have yet to find a cohesive explanation. I have found a few things to share, and perhaps someone more knowledgeable can help fill in some unanswered questions. First, a small caution, the Makefiles in the individual directories of TI’s three examples in their am335x_pru_package are missing the -V3 flags that should be passed to pasm_2; they are not missing in the Makefile one level up, since I used the lower level Makefiles, this error lost me almost a week. Irrespective, re memory.
It appears to me that ddrMem accessed at 0x80000000 in PRU space is different than extRAM that is accessed at an address in PRU space found from >cat /sys/class/uio/uio0/maps/map1/addr which for me gives 0x9f2c0000. The extRAM size is easily found using >cat /sys/class/uio/uio0/maps/map1/size (0x40000 for me as I haven’t increased it yet). However, I can’t find anywhere discussion on what the size of ddrMem can be safely used. In user space I map ddrMem in userspace using:
mem_fd = open("/dev/mem", O_RDWR);
/* map the DDR 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;
}
ddrMem_int = (unsigned int) ddrMem;
memset(ddrMem, 0, 0x2000);
where DDR_BASEADDR is 0x80000000. This is based on the TI example. It appears the size of the memory is 0x10000000 or about 256Mbytes. However, if one changes the memset to memset(ddrMem, 0, 0x0FFFFFFF); (DO NOT DO THIS), it renders the BBB unuseable; it needs to be powererd down, disconnected from power, and then powered back up before it is useable. It would be nice to know how ddrMem could be used. I am working on figuring out access speeds to each, and from various places, it appears extRAM is always at memory locations where it can be accessed using Direct Memory Access. Can someone tell me the maximum size that can be used when loading uio_pruss; I saw it somewhere, but can’t find the posting again? Also, it would be nice if the size could be set in a uio_pruss device tree overlay at boot time; I can’t find info re this at all. Accessing ddrMem using SBCO seems to take 4 cycles for the first register, and then one cycle per additional register; that is the command:
SBCO r0, CONST_DDR, PARAM_OFFSET+0, 32 takes 11 cycles; I was expecting 9 cycles (SBCO and SBBO commands normally take 2 cycles for the first register and 1 for each additional register, as opposed to LBCO and LBBO commands which take 4 cycles for the first register, and 1 cycle per additional register - it sure would be nice if TI gave us a table for disassembling the op codes and how many cycles per code). I don’t understand yet where I am losing the 2 cycles. Just for some more info re memory mapping, noting the pid of my user space process is 1354, then doing sudo cat /proc/1354/maps gives:
00008000-0000a000 r-xp 00000000 b3:02 14116 /home/martin/programming/pru/pru_test/logic_test
00012000-00013000 rw-p 00002000 b3:02 14116 /home/martin/programming/pru/pru_test/logic_test
00013000-00034000 rw-p 00000000 00:00 0 [heap]
a6d00000-a6d40000 rw-s 00001000 00:05 5333 /dev/uio0
a6d40000-b6d40000 rw-s 80000000 00:05 2292 /dev/mem
b6d40000-b6d80000 rw-s 00001000 00:05 5333 /dev/uio0
b6d80000-b6e00000 rw-s 00000000 00:05 5333 /dev/uio0
b6e00000-b6e40000 rw-s 00001000 00:05 5333 /dev/uio0
b6e40000-b6ec0000 rw-s 00000000 00:05 5333 /dev/uio0
b6ec0000-b6f98000 r-xp 00000000 b3:02 34894 /lib/arm-linux-gnueabihf/libc-2.13.so
and so on. The pru base addresses are b6d80000-b6e00000 and the addresses of the ddrMem are a6d40000-b6d40000, but again do not assume you can use all of these. There are also a number of mappings that I don’t understand (such as b6d40000-b6d80000, b6e00000-b6e40000, and b6e40000-b6ec0000).
Finally, I have had some success with including:
#include “/home/martin/programming/pru/am335x_pru_package/pru_sw/app_loader/interface/__prussdrv.h”
extern tprussdrv prussdrv;
to get at the prussdrv struct using gdb. This is quite helpful in understanding some of the PRU addresses.
Also, including
#include “logic_addresses.h” // for PRU relative addresses used in debug
where logic_addresses.h has:
#define PDATA0 0x00000
#define PINST0 0x34000
#define PCNTL0 0x22000
#define PDBUG0 0x22400
#define PDATA1 0x02000
#define PINST1 0x38000
#define PCNTL1 0x24000
#define PDBUG1 0x24400
#define PBASE 0x00000
#define PINSTC 0x20000
#define PIEP 0x2E000
#define PSHARE 0x10000
static unsigned int pdata0 = PDATA0;
static unsigned int pinst0 = PINST0;
static unsigned int pcntl0 = PCNTL0;
static unsigned int pdbug0 = PDBUG0;
static unsigned int pdata1 = PDATA1;
static unsigned int pinst1 = PINST1;
static unsigned int pcntl1 = PCNTL1;
static unsigned int pdbug1 = PDBUG1;
static unsigned int pbase = PBASE;
static unsigned int pinstc = PINSTC;
static unsigned int piep = PIEP;
static unsigned int pshare = PSHARE;
to allow one to get at the debug registers using gdb in user space (they are not accessible in PRU space as far as I can tell - if anyone knows how to get at them, please share it with us).
It appears TI is not interested in supporting the PRU on BBB:
"Hi,
The PRU support package that you refer is not developed or supported by TI. You can ask for information about it at http://beagleboard.org/Community/Forums"
so we are pretty well on our own; it would be a shame if after spending considerable time to understand and use the PRU’s TI decided to drop them - we can only hope this would not be the case. It might be nice if the PRU info could be collected into one location or wiki, as currently it is spread over many different locations with much of the info in forum posts being simple one liners (with the notable exception being Derek Malloy’s web site http://exploringbeaglebone.com/chapter13). My background is hardware, so I wouldn’t know how to set a wiki up, but if someone could look after it, I would be able to contribute. Anyways, thanks for any help that experienced PRUers can give, especially with respect to a uio_pruss device tree overlay and the usable size of ddrMem.