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.
--
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.
For more options, visit https://groups.google.com/d/optout.
