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/beagleboard/am335x_pru_package/blob/mast >>>> er/pru_sw/example_apps/PRU_PRUtoPRU_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.
