@William Hermans like you I won't be able to dig into the gory details of
loading Linux. This is an interesting read (albeit high-level and prompting
more questions). I think I can say a few things without understanding all
the details:
It is correct (from detailed reading of the TI TRM) that
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
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
0x800 works. In fact, if you think about it a little bit. . Read
OK, according to some dicumentation I was able to find quickly, address
0x800 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 wrote:
>
Thinking on it for a little longer, I almost want to say that the Address
0x800h 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
On Fri, Mar 10, 2017 at 2:53 PM, ags 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
>
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
On Wed, Mar 8, 2017 at 4:34 PM, ags wrote:
> Correct - to preserve deterministic execution, the PRU cannot be
> asynchronously interrupted. Polling (of some form) is required.
>
> Back to the OP, there is a way to register a (non-async) interrupt with
> the PRU. One
Correct - to preserve deterministic execution, the PRU cannot be
asynchronously interrupted. Polling (of some form) is required.
Back to the OP, there is a way to register a (non-async) interrupt with the
PRU. One can force a system interrupt (any one of the 64 that the PRUSS
recognizes) by
According to this 2015 video from the Embedded Linux Conference, the PRU
does not support asynchronous interrupts:
https://youtu.be/plCYsbmMbmY?t=22m6s
I think there is some sort of PRU interrupt queue, but it does not
interrupt the PRU's execution. Your PRU code must explicitly monitor the
On Wed, Mar 8, 2017 at 9:04 AM, William Hermans wrote:
> For the purpose of this discussion with ags, I do not think the actual
> definition of what an interrupt is, is quite so important, as much as how
> to achieve an end goal. On a single threaded "system", I also do not
On Wed, Mar 8, 2017 at 7:21 AM, Dennis Lee Bieber
wrote:
> On Tue, 7 Mar 2017 21:52:21 -0700, William Hermans
> declaimed the following:
>
> >I get the feeling however that you're misunderstanding the purpose of an
> >interrupt. An interrupt is a way
12 matches
Mail list logo