William,
Thank you so much for this information. Will really help for that thread I'm
doing on BB. Just trying to get the P8/9 up on my little BBBW. Its nice having
a little insight into the internals of them...as much information as I can get,
I'm happy about. Not quite finished reading all my emails, but give me time.
If I have any questions can I bounce them off you, bro? It takes me a little
while to get things done but I'm starting your email. I do GREAT in burst mode,
so feel free to continue communicating as you have done.
Woody. Check out the new website at:
https://woodystanford.wordpress.com/stanford-systems-home-page/
Download the current (and past) quarterly newsletter on the development of our
suborbital offerings at https://woodystanford.wordpress.com/downloads/ - at the
bottom of the page.
Cell: 480-740-5610
On Friday, March 10, 2017 8:30 PM, William Hermans <[email protected]>
wrote:
Here is another link that should explain it clear enough.
http://processors.wiki.ti.com/index.php/HOWTO_Change_the_Linux_Kernel_Start_Address#Modifying_memory.h
So I would say that it is not by accident that the base address of 0x8000000
works. In fact, if you think about it a little bit. . Read the opening
paragraph labeled "purpose", and replace "DSP" with "PRU", for all intents and
purposes. of this discussion.
On Fri, Mar 10, 2017 at 7:59 PM, William Hermans <[email protected]> wrote:
OK, according to some dicumentation I was able to find quickly, address
0x8000000 is the base address for the start of the DDR memory on the TI EVM
board. Which is very similar to the beaglebone in memory layout.
On Fri, Mar 10, 2017 at 7:38 PM, William Hermans <[email protected]> wrote:
Thinking on it for a little longer, I almost want to say that the Address
0x8000000h is actually the start of Linux's virtual memory map. But I'm not
100% sure.
I'm doing my own research for a paying project, so can't really dive into
documentation for something else right now . . .
On Fri, Mar 10, 2017 at 7:24 PM, William Hermans <[email protected]> wrote:
On Fri, Mar 10, 2017 at 2:53 PM, ags <[email protected]> wrote:
I've had a hard time getting any definitive responses to questions on the
subject of memory access & latency. It is true that the PRU cores have faster
access to DRAM that is part of the PRU-ICSS (through the 32-bit interconnect
SCR) - though not single-cycle - than to system DDR. However, the ARM core
accesses DDR through L3 fabric, but the PRU-ICSS through L4FAST, so I'm
thinking that it can access DDR faster than PRU-ICSS memory.
I've also asked about differences in latency/throughput/contention comparing
PRU-ICSS 12KB shared RAM v the 8KB data RAM. No response. Since both 8K data
RAM is accessible to both PRU cores, I'm not sure what the benefit of the 12KB
shared RAM is (thought I imagine there is, I just can't figure it out).
Lastly - and even more importantly - is total agreement that you have to be
careful about accessing any memory correctly. I have posted several times
asking about the am335x_pru_package examples (using UIO). In at least one
(https://github.com/beagleboar d/am335x_pru_package/blob/mast
er/pru_sw/example_apps/PRU_PRU toPRU_Interrupt/PRU_PRUtoPRU_ Interrupt.c),
there is hardcoded use of the first 8 bytes of physical memory at 0x8000_0000.
I don't see how that can be OK. It may be that I don't know some secrets of
Linux internals, but from a theoretical perspective, I just don't know how one
can make the assumption that any part of main memory is not in use by another
process unless it is guaranteed by the kernel.
So here is what I meant. Of course, I have no personal hands on,but looking at
things from 35k feet. I *know* writing directly to the PRU shared memory from
userspace, would be, performance wise, just as fast as writing to the 512M of
system DDR. Through /dev/mem/. On the PRU side however, the PRU's would have
single cycle access to their own memory. So the tricky part for me here would
not be making sure we're writing to the right memory location, but knowing it's
possible to begin with because I have not attempted this personally. In fact my
hands on experience with the PRU is limited to just setting up a couple
examples, and proving to myself it would work with a 4.x kernel.
So my only real "concern" is, if it really is possible to mmap() the physical
address for the PRU's shared memory, and if that could be done "safely". But I
do know that if it is possible, it would be faster than reading and writing to
the systems 512M DDR because of the fabric latency. From the PRU side. Not only
that, from what I've read in the past, is that accessing devices, or memory
through that fabric can add a little bit of non deterministic latency. So my
thinking here is that "we'd" gain back our little bit of determinism that we
lost using DDR.
After that, I have no idea how important what I'm talking about is to you, with
your given project. Address 0x8000000h though, I seem to recall is possibly
related to the kernel, or perhaps the initrd. But another thing, that I do not
pretend to know 100% about is how Linux virtual memory works. So when we say
we're accessing "physical memory", through mmap() we're actually accessing the
device modules, or external memory through virtual memory. Which it could very
well be possible the person who wrote the uio pru examples knew this going in,
and it's not by accident at all. But rather by design. I'd have to look further
into the gory details of everything, before I could make this determination.
--
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].
To view this discussion on the web visit
https://groups.google.com/d/msgid/beagleboard/CALHSORrC4qT10TPDZECzS7PDrBTA7KPqeka7zKkfGP5p2xzt7w%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
--
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].
To view this discussion on the web visit
https://groups.google.com/d/msgid/beagleboard/1838955706.4086768.1489356430473%40mail.yahoo.com.
For more options, visit https://groups.google.com/d/optout.
