Re: [beagleboard] Re: Is there a way to send an interrupt from userspace to the PRU-ICSS?

[William Hermans]

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 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  wrote:

> 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 10, 2017 at 7:24 PM, William Hermans 
>> wrote:
>>
>>>
>>>
>>> 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
 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_. 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 0x800h 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 

Re: [beagleboard] Re: Is there a way to send an interrupt from userspace to the PRU-ICSS?

[William Hermans]

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 10, 2017 at 7:24 PM, William Hermans 
> wrote:
>
>>
>>
>> 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
>>> 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_. 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 0x800h 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 beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/CALHSORrqwBHZKauFJHrY4k094fFpWq%2BGTXFiW43Mjt%3DkfJ9pKQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Re: Is there a way to send an interrupt from userspace to the PRU-ICSS?

[William Hermans]

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 10, 2017 at 7:24 PM, William Hermans  wrote:

>
>
> 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
>> 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/
>> master/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_. 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 0x800h 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 beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/CALHSORqKRStuVtAY0p0V7RXB9Z1WQ%3DAnwZaxFqrmoRu%2BixBT9A%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Re: Is there a way to send an interrupt from userspace to the PRU-ICSS?

[William Hermans]

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
> 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/master/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_. 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 0x800h 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 beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/CALHSORrixYD7i697VM9Ksx3Kgz7Kp5umV5o%3DoKrGHxEzZ63Epg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Re: on accessing the p8/9 headers

[Gerald Coley]

Bye Bye!!

Gerald


On Fri, Mar 10, 2017 at 4:04 PM, 'woody stanford' via BeagleBoard <
beagleboard@googlegroups.com> wrote:

> Sweet Fish
> Q: What kind of fish goes well with peanut butter?
>
> A: Jellyfish!
>
> Categories: Animal Jokes(Fish Jokes), Food Jokes, Riddles(Riddles for Kids)
> Copyright © 2013 - All Rights Reserved - Used with Permission.
> Share ViaE-MailTwitterFacebookGoogle PlusURL Share
> 264111
> Anonymous
>
> Blow Your Top -Riddles
> Q: What is a volcano?
>
> A: A mountain with the hiccups.
>
>
>
> Categories: Riddles(Riddles for Kids)
> Share ViaE-MailTwitterFacebookGoogle PlusURL Share
> 13227
> Anonymous
>
> Identity Theft
> Q: What do you call a noodle that committed identity theft?
>
> A: An im-pasta!
>
> Categories: Food Jokes, Word Play Jokes, Riddles(Riddles for Kids)
> Copyright © 2013 - All Rights Reserved - Used with Permission.
> 130
> Anonymous
>
> Deportation
> I live in constant fear that Trump will deport my latina mother-in-law who
> lives at 1944 5th Street in a white house with a blue door.  She gets off
> work at 6PM.
>
> Categories: Jokes about Families(Mother-in-Law Jokes), Ethnic / Country
> Jokes(Mexico Jokes)
> 220
> Anonymous
>
> Getting on Television
> Q: How do you get on television?
>
> A: You sit on it!
>
> Categories: One-Liner Jokes, Word Play Jokes, Riddles(Riddles for Kids)
> Copyright © 2013 - All Rights Reserved - Used with Permission.
> 032
> Submitted By: toemeraldcity
>
> Call Me Maybe
> Q: How did the telephone propose to his girlfriend?
>
> A: He gave her a ring.
>
> Categories: Relationship Jokes(Dating Jokes), Telephone Jokes,
> Riddles(Riddles for Kids)
> 11122
> Anonymous
>
> Police Stop at 2AM
> An elderly man is stopped by the police around 2 a.m. and is asked where
> he is going at this time of night.
>
> The man replies, "I am on my way to a lecture about alcohol abuse and the
> effects it has on the human body, as well as smoking and staying out late."
> The officer then asks, "Really? Who is giving that lecture at this time of
> night?"
>
> The man replies, "That would be my wife."
>
> Categories: Old Age Jokes, Relationship Jokes(Marriage Jokes), Alcohol
> Jokes
> 490
> Anonymous
>
> Shady Dog
> Q: Why did the dog sit in the shade?
>
> A: Because he didn't want to be a hot dog!
>
> Categories: Food Jokes, Animal Jokes(Dog Jokes), Funny Thoughts, Word Play
> Jokes, Riddles(Riddles for Kids)
> 11001636422
> Anonymous
>
> Snowman Transport
> Q: How does a Snowman get to work?
>
> A: By icicle.
>
> On Thursday, March 9, 2017 at 5:17:59 AM UTC-7, woody stanford wrote:
>>
>> OK, I want to get to the bottom of this whole GPIO issue on the BBB, so
>> I'm opening up this thread as a "documenter" whereby which I can take notes
>> based on my research into how you consistently, stably and SOLIDLY
>> programatically access the GPIO pins on a BBB. I've already done a lot of
>> the footwork so I'm not entirely unknowledgeable, but I want to get to the
>> heart of this issue and solve the mental block people have with this. A
>> private hope.
>>
>> Either way, probably a good mess of processed links, articles and
>> information where you can start.
>>
> --
> 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.
> To view this discussion on the web visit https://groups.google.com/d/
> msgid/beagleboard/59810c04-e7f2-4da9-b42e-80c2ee8be07d%40googlegroups.com
> 
> .
>
> For more options, visit https://groups.google.com/d/optout.
>



-- 
Gerald

ger...@beagleboard.org
http://beagleboard.org/
gcol...@emprodesign.com

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/CAHK_S%2Bfzagq5P2_OFymYPT%3DXBzJR9Sh3sbgL2dmBuY1CpBbSBw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Re: on accessing the p8/9 headers

['woody stanford' via BeagleBoard]

Sweet Fish
Q: What kind of fish goes well with peanut butter?

A: Jellyfish!

Categories: Animal Jokes(Fish Jokes), Food Jokes, Riddles(Riddles for Kids)
Copyright © 2013 - All Rights Reserved - Used with Permission.
Share ViaE-MailTwitterFacebookGoogle PlusURL Share
264111
Anonymous

Blow Your Top -Riddles
Q: What is a volcano?

A: A mountain with the hiccups.

 

Categories: Riddles(Riddles for Kids)
Share ViaE-MailTwitterFacebookGoogle PlusURL Share
13227
Anonymous

Identity Theft
Q: What do you call a noodle that committed identity theft?

A: An im-pasta!

Categories: Food Jokes, Word Play Jokes, Riddles(Riddles for Kids)
Copyright © 2013 - All Rights Reserved - Used with Permission.
130
Anonymous

Deportation
I live in constant fear that Trump will deport my latina mother-in-law who 
lives at 1944 5th Street in a white house with a blue door.  She gets off 
work at 6PM.

Categories: Jokes about Families(Mother-in-Law Jokes), Ethnic / Country 
Jokes(Mexico Jokes)
220
Anonymous

Getting on Television
Q: How do you get on television?

A: You sit on it!

Categories: One-Liner Jokes, Word Play Jokes, Riddles(Riddles for Kids)
Copyright © 2013 - All Rights Reserved - Used with Permission.
032
Submitted By: toemeraldcity

Call Me Maybe
Q: How did the telephone propose to his girlfriend?

A: He gave her a ring.

Categories: Relationship Jokes(Dating Jokes), Telephone Jokes, 
Riddles(Riddles for Kids)
11122
Anonymous

Police Stop at 2AM
An elderly man is stopped by the police around 2 a.m. and is asked where he 
is going at this time of night.

The man replies, "I am on my way to a lecture about alcohol abuse and the 
effects it has on the human body, as well as smoking and staying out late." 
The officer then asks, "Really? Who is giving that lecture at this time of 
night?"

The man replies, "That would be my wife."

Categories: Old Age Jokes, Relationship Jokes(Marriage Jokes), Alcohol Jokes
490
Anonymous

Shady Dog
Q: Why did the dog sit in the shade?

A: Because he didn't want to be a hot dog!

Categories: Food Jokes, Animal Jokes(Dog Jokes), Funny Thoughts, Word Play 
Jokes, Riddles(Riddles for Kids)
11001636422
Anonymous

Snowman Transport
Q: How does a Snowman get to work?

A: By icicle.

On Thursday, March 9, 2017 at 5:17:59 AM UTC-7, woody stanford wrote:
>
> OK, I want to get to the bottom of this whole GPIO issue on the BBB, so 
> I'm opening up this thread as a "documenter" whereby which I can take notes 
> based on my research into how you consistently, stably and SOLIDLY 
> programatically access the GPIO pins on a BBB. I've already done a lot of 
> the footwork so I'm not entirely unknowledgeable, but I want to get to the 
> heart of this issue and solve the mental block people have with this. A 
> private hope.
>
> Either way, probably a good mess of processed links, articles and 
> information where you can start.
>

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/59810c04-e7f2-4da9-b42e-80c2ee8be07d%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Re: on accessing the p8/9 headers

['woody stanford' via BeagleBoard]

Sweet Fish

*Q: *What kind of fish goes well with peanut butter?

*A:* Jellyfish!

Categories:
Animal Jokes (Fish Jokes 
), Food Jokes 
, Riddles 
(Riddles for Kids 
)
Copyright © 2013 - All Rights Reserved - Used with Permission.

   - Share Via
   - E-Mail 
   - Twitter 
   - Facebook 
   - Google Plus
   - URL Share 

26
41
11

Anonymous
Blow Your Top -Riddles

*Q:* What is a volcano?

*A:* A mountain with the hiccups.

 

Categories:
Riddles (Riddles for Kids 
)

   - Share Via
   - E-Mail 
   - Twitter 
   - Facebook 
   - Google Plus
   - URL Share 

13
22
7

Anonymous
Identity Theft

*Q: *What do you call a noodle that committed identity theft?

*A: *An im-pasta!

Categories:
Food Jokes , Word Play Jokes 
, Riddles 
(Riddles for Kids 
)
Copyright © 2013 - All Rights Reserved - Used with Permission.

   - Share Via
   - E-Mail 
   - Twitter 
   - Facebook 
   - Google Plus
   - URL Share 

1
3
0

Anonymous
Deportation

I live in constant fear that Trump will deport my latina mother-in-law who 
lives at 1944 5th Street in a white house with a blue door.  She gets off 
work at 6PM.

Categories:
Jokes about Families 
(Mother-in-Law 
Jokes ), Ethnic / Country 
Jokes (Mexico Jokes 
)

   - Share Via
   - E-Mail 
   - Twitter 
   - Facebook 
   - Google Plus
   - URL Share 

2
2
0

Anonymous
Getting on Television

*Q: *How do you get on television?

*A:* You sit on it!

Categories:
One-Liner Jokes , Word Play Jokes 
, Riddles 
(Riddles for Kids 
)
Copyright © 2013 - All Rights Reserved - Used with Permission.

   - Share Via
   - E-Mail 
   - Twitter 
   - Facebook 
   - Google Plus
   - URL Share 

0
3
2

Submitted By: toemeraldcity
Call Me Maybe

*Q:* How did the telephone propose to his girlfriend?

*A:* He gave her a ring.

Categories:
Relationship Jokes (Dating 
Jokes ), Telephone Jokes 
, Riddles 
(Riddles for Kids 
)

   - Share Via
   - E-Mail 
   - Twitter 
   - Facebook 
   - Google Plus
   - URL Share 

11
12
2

Anonymous
Police Stop at 2AM

An elderly man is stopped by the police around 2 a.m. and is asked where he 
is going at this time of night.

The man replies, "I am on my way to a lecture about alcohol abuse and the 
effects it has on the human body, as well as smoking and staying out late." 
The officer then asks, "Really? Who is giving that lecture at this time of 
night?"

The man replies, "That would be my wife."

Categories:
Old Age Jokes , Relationship Jokes 
(Marriage Jokes 
), Alcohol Jokes 


   - Share Via
   - E-Mail 
   - Twitter 
   - Facebook 
   - Google Plus
   - URL Share 

4

Re: [beagleboard] Re: Is there a way to send an interrupt from userspace to the PRU-ICSS?

[ags]

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/master/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_. 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.

On Wednesday, March 8, 2017 at 4:14:56 PM UTC-8, William Hermans wrote:
>
>
>
> 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 can force a system interrupt (any one of the 64 that the PRUSS 
>> recognizes) by setting a bit in the Interrupt Status Register. From 
>> userspace it looks just like writing to the PRU DRAM since it's just 
>> writing a value to mmap()'d physical address. The advantage over what's 
>> been discussed here is that depending on how it's set up, it could be 
>> faster than polling from DRAM. I will have to implement to provide actual 
>> measurements.
>>
>
> So I remember asking Charles, some time ago, if it would be more efficient 
> writting to DRAM, or to one of the shared memory area for the PRU. From the 
> ARM side of things. I think perhaps in this case, writing to one of the 
> PRU's memory area's might be more efficient. In this one case. My reasoning 
> here is that through userspace, one would have to write out to memory 
> through /dev/mem/ anyhow. So why not make that to a memory location where 
> the PRU has single cycle read speeds ? One *would* have to take extra care 
> to make sure this memory location is correct, but no more so than writing 
> into DRAM. . . .
>
> Something to think about anyhow.
>

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/17e13ff7-4418-4058-9433-f30726d3d922%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Re: on accessing the p8/9 headers

['woody stanford' via BeagleBoard]

Since this is my thread, I though I would reach out to my fellows, both 
professional (ie. Beagleboard) and hobbyist (that that have ACTUALLY solved 
this issue and can add something to this discussion) if they can shed some 
light on the following issues.

I'm serious though about people that have done it before, ok, I've been 
programming UN*X for quite sometime and already know what a popen and a ps 
are, we don't need yet another elaboration on it. If you have successfully 
managed to properly configure the GPIO on a BB I would love to hear from 
you. And I will proceed with my own research on the subject, posting here.

Some of the topics that elaboration would help on are currently:

- how conceptually (not technically, functionally, in english) does 
"overlaying" work. And better if it is a mundain procedure but I do need it 
explained (would save me some time).

- Am I correct in assuming that to commit this "overlay" to OS that I need 
to "compile" it? Have I got it right that its the DTC compiler at the above 
URL.

- Does this correctly configure my board for the suite of 
PWM/TIMER/I2C/UART/SPI/CAN/GPIO features available on the p8/9 headers AT 
START UP?

- Down the line: is there a nice tutorial out there or PDF that deliniates 
a correct procedure for using /dev/ abstraction to access especially the 
I2C/SPI/UART features via streams (in let's say C).

- what is the accepted procedure for accessing the pins in GPIO mode?

- A moderators: once we get this issue resolved is there any way we can 
stickey it to the top of each of the boards sections, as well as the 
hardware board? I apologize for my forwardness, its just a question.

Thank you for your compliance jk. :D

On Thursday, March 9, 2017 at 5:17:59 AM UTC-7, woody stanford wrote:
>
> OK, I want to get to the bottom of this whole GPIO issue on the BBB, so 
> I'm opening up this thread as a "documenter" whereby which I can take notes 
> based on my research into how you consistently, stably and SOLIDLY 
> programatically access the GPIO pins on a BBB. I've already done a lot of 
> the footwork so I'm not entirely unknowledgeable, but I want to get to the 
> heart of this issue and solve the mental block people have with this. A 
> private hope.
>
> Either way, probably a good mess of processed links, articles and 
> information where you can start.
>

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/26562988-3d22-406f-ac28-3832e43c7218%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Re: Are the am335x_pru_package examples incorrectly (dangerously) accessing DDR memory?

[dinuxbg]

Hi,

I believe the example is indeed buggy, and works by accident. You can check 
"cat /proc/iomem" and see that your mapped region overlaps the kernel code.

If you need to properly allocate and map DDR between ARM and PRU, then I 
would suggest to:

   1. Load PRU UIO with "modprobe uio_pruss extram_pool_sz=2097152" in 
   order to tell it allocate contiguous memory.
   2. Use prussdrv_map_extmem() from ARM side to map the allocated DDR 
   chunk. Example 
   

   3. Get the physical DDR base address of the chunk by using 
   prussdrv_get_phys_addr(). Example 
   

   4. Write the physical DDR base address to a pre-defined location in PRU 
   DRAM. If you are using pasm, then just hard-code the pre-defined location. 
   If your firmware is in ELF format, there is a bit nicer way 
   

   .


Regards,
Dimitar

On Tuesday, March 7, 2017 at 10:07:31 PM UTC+2, ags wrote:
>
> I have been able to load/start/run/stop a PRU core from 4.4.30-ti-r64 
> using just the uio_pruss (& uio) drivers, without any of the prussdrv code. 
> Big milestone in my project.
>
> A long time ago I asked a question about the examples in the pru here: 
> https://groups.google.com/d/topic/beagleboard/Kv03QMsgOmo/discussion
>
> as did someone else here: 
> https://groups.google.com/d/topic/beagleboard/vnZ9eSzoo6Y/discussion
>
> but I found no answer to help me. From a thorough review of the examples 
> in the am335x_pru_package (using the prussdrv uio-based pru driver) here: 
> https://github.com/beagleboard/am335x_pru_package/blob/master/pru_sw/example_apps/PRU_PRUtoPRU_Interrupt/PRU_PRUtoPRU_Interrupt.c
>
> it *appears* to me that this example (to teach/illustrate proper use of 
> pru in the BB family) works only by luck - or taking advantage of some bit 
> of information that is undocumented (from my research).
>
> Specifically, when using the L3 DDR (main) memory to share data between 
> the A8 and PRU, it seems that rather than using the 256KiB size region 
> starting at 0x9c94_ (on my BBB rev C) it seems to simply hardcode 
> 0x8000_ and write away. See here:
>
> static int LOCAL_exampleInit () {
>  void *DDR_regaddr;
>  /* open the device */
>  mem_fd = open("/dev/mem", O_RDWR);
>  if (mem_fd < 0) {
>   printf("Failed to open /dev/mem (%s)\n", strerror(errno));
>   return -1;
>  }
>  /* map the memory */
>  ddrMem = mmap(0, 0x0FFF, 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;
>  }
>  //FLush the flag locations of PRU0 and PRU1
>  DDR_regaddr = ddrMem;
>  *(unsigned long*) DDR_regaddr = 0x00;
>  DDR_regaddr = ddrMem + 0x4;
>  *(unsigned long*) DDR_regaddr = 0x00;
>  return(0);
> }
> I can understand how this might work "by accident" if these first eight 
> bytes in DDR are not used. But that's not a good example. Questions: 1) Is 
> there some "magic" to this physical memory location that I'm missing out 
> on? Or am I mis-reading the code, and it is *not* just writing to physical 
> memory 0x0-0x7? 2) Is it correct that the actual DDR physical memory region 
> that is allocated by the uio driver is properly determined by examining 
> /sys/class/uio/uio/maps/map1/{addr,size}? If not, how? I think this is 
> useful information that would be helpful to others if provided. Perhaps 
> even an update to the example, if my assertions are correct.
>

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/db46432f-1830-4e5e-a4fe-a7671d0f74f3%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Re: Making a custom SD image of BBB's eMMC

[William Hermans]

For example here you will notice two different H tags for two of the same
type of image:

http://elinux.org/Beagleboard:BeagleBoneBlack_Debian#Jessie_Snapshot_iot

Jessie Snapshot iot Flasher: (iot) (All BeagleBone Variants)
>
> Get prebuilt image:
>
> wget 
> https://rcn-ee.com/rootfs/bb.org/testing/2017-02-12/iot/BBB-blank-debian-8.7-iot-armhf-2017-02-12-4gb.img.xz
>
>
Versus:

microSD/Standalone: (iot) (All BeagleBone Variants)
>
> Get prebuilt image:
>
> wget 
> https://rcn-ee.com/rootfs/bb.org/testing/2017-02-12/iot/bone-debian-8.7-iot-armhf-2017-02-12-4gb.img.xz
>
>
Read the "bolded" (H tag ) description. The first is a flasher image, the
second is a standalone image. This is of course just an example, you may,or
may not want an IoT type image. There are also "lxqt", and "console" type
images.

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/CALHSORpLmxVCRLStWu%3DXn-z%2BgsW7dsEvQ1xELzFmkw_r-E7tFQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Re: Making a custom SD image of BBB's eMMC

[William Hermans]

On Fri, Mar 10, 2017 at 10:24 AM, Justin Pearson 
wrote:

> This sounds like what I'm looking for, thanks.
>
> Follow-up: Is there an easy way to modify this procedure so the new BBB
> simply boots from the SD card instead of wiping out its eMMC with the image
> on the SD card?
>
> Yes, download, and write a standalone image to the sdcard. Instead of
downloading and writing a flasher image to the sdcard.

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/CALHSORpXm4JXJfF2H90-AQQ-Rru8cMJ%3Dv_vhUEtCHgBhEqnfYQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Re: Making a custom SD image of BBB's eMMC

[Justin Pearson]

On Fri, Mar 10, 2017 at 6:37 AM, Charlie Rysenga  wrote:

>
>- Boot master BBB with no SD card in
>- Insert SD card
>- Log in (e.g. with serial terminal, SSH etc.) and run sudo
>/opt/scripts/tools/eMMC/beaglebone-black-make-microSD-flasher-from-eMMC.sh
>(you may have to cd /opt/scripts and git pull before this.) LEDs will flash
>in sequence whilst SD card is being written.
>- When the LEDs stop and the script terminates, remove the SD card.
>- Insert SD card into new BBB then power on.
>- eMMC will be flashed; LEDs on new BBB will flash in sequence until
>complete.
>
>
This sounds like what I'm looking for, thanks.

Follow-up: Is there an easy way to modify this procedure so the new BBB
simply boots from the SD card instead of wiping out its eMMC with the image
on the SD card?

Thanks,
Justin




>
>-
>
>
> On Monday, March 6, 2017 at 12:46:13 PM UTC-5, Justin Pearson wrote:
>>
>> I'd like to help a fellow BBB user by sending him a disk image of my
>> working BBB configuration for him to install on his own BBB.
>>
>> However, I'm not sure how to copy my BBB's eMMC. I was hoping that it
>> would be as simple as using dd to copy my BBB's entire 2GB eMMC into some
>> .img.xz file. But then I found this article:
>>
>> http://blog.logikonlabs.com/how-to-create-a-custom-microsd-
>> card-image-for-the-beaglebone-black/
>>
>> It's a long procedure. Is this the correct method for creating an image
>> of an entire BBB configuration, suitable for copying to another BBB?
>>
>> Thanks,
>> Justin
>>
>> --
> For more options, visit http://beagleboard.org/discuss
> ---
> You received this message because you are subscribed to a topic in the
> Google Groups "BeagleBoard" group.
> To unsubscribe from this topic, visit https://groups.google.com/d/
> topic/beagleboard/DuLpDvzrmAE/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> beagleboard+unsubscr...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/
> msgid/beagleboard/9e599566-4b82-4520-8065-41b2aae88119%40googlegroups.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 beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/CABCHBhKwjg5C9o%2B_xGMxh2Si-T5Rck2HuDkWpFeqO9fp11QSrw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] config-pin does not work for all pins on BBBW

[ansepi]

On BBBW, when I do 'config-pin -q P9.28', I get the following error: 
"Cannot read pinmux file: /sys/devices/platform/ocp/ocp*P9_28_pinmux/state".
When I do 'config-pin -q P9.22', it works fine.  I have loaded 
cape-universala previously with the following command "config-pin overlay 
cape-universala" so config-pin should work for all the pins.  How do I fix 
this problem.  I'm trying to get spidev1 to work on BBBW.  Thanks.

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/04ac0cb0-8e1e-42ca-93b1-840efb4ee4e6%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Re: Detecting (probing) MPU-9250 connected to beaglebone board black

[Graham]

If you have a current version of Debian 8, with the cape manager, 
THEN I2C-2 IS ALREADY ENABLED.
IT IS ALREADY BROUGHT OUT ON  P9_19 and P9_20
Start with that one, Don't mess with I2C-1. If you touch the EEPROM on 
I2C-1, you can brick the unit. It is intended for internal use.
Get your part working on I2C-2, before you start messing with other things.

put your part on P9-19 and P9-20, then boot, then run "i2cdetect -y -r 2"

If you wired it up right, it will be there.

==

On Friday, March 10, 2017 at 9:08:39 AM UTC-6, christ christ wrote:
>
> Hi Graham, 
> I have been using the latest version of Debien, for three days now with 
> the same result. 
> On the other hand i checked with the oscilloscope the SDA and SCL lines 
> are not acting like they are supposed to act (even on the default P9_19 and 
> P9_20).
>
> Thought maybe they all need to be enable.Tried the following method but in 
> vain (NO such file or directory is the response i'm getting)
> *To enable the I2c-1 on the BeagleBone Black Rev A, B and C:*
>
>1. Rev A/B: Open the file /media/BEAGLEBONE/uEnv.txt in an editor 
>(vim/nano)
>2. Rec C: Open the file /boot/uboot/uEnv.txt in an editor (vim/nano)
>3. Add the key "capemgr.enable_partno="
>4. Add the ports you want to enable, comma separated (BB-I2C0, 
>BB-I2C1, etc)
>5. Reboot.
>
> Am i right to say the I2c buses are not enable? or is it another proble?
>
> On Thu, Mar 9, 2017 at 4:25 PM, Graham  > wrote:
>
>> Then it is not wired or connected correctly.
>> Put an oscilloscope on the data and clock lines and see if they are doing 
>> what they are supposed to do.
>> It also looks like you are using an old version of the OS.
>> Move to Debian 8, and you should see the I2C devices on bus 2.
>> Hook the I2C Clock to P9-19.  Hook the I2C data to P9-20.
>> You should not have to mess with the device tree or pin configuration.
>> Power and ground also required.
>>
>> --- Graham
>>
>> ==
>>
>> On Thursday, March 9, 2017 at 6:52:04 AM UTC-6, christ christ wrote:
>>>
>>> The MPU-9250 breakout from spark fun come with pull up resistors.
>>>
>>> On 09 Mar 2017 00:42, "Graham"  wrote:
>>>
 Something is not wired right.
 Did you put pull-up resistors on the I2C lines?
 --- Graham

 ==

 On Wednesday, March 8, 2017 at 12:02:04 PM UTC-6, mamane...@gmail.com 
 wrote:
>
> Hi Guys,
>
> I’m struggling to get the device address (MPU-9250). i got to the 
> following stage:
>
>
> root@beaglebone:~# sudo i2cdetect -r 0
> WARNING! This program can confuse your I2C bus, cause data loss and 
> worse!
> I will probe file /dev/i2c-0 using read byte commands.
> I will probe address range 0x03-0x77.
> Continue? [Y/n] y
> 0 1 2 3 4 5 6 7 8 9 a b c d e f
> 00: — — — — — — — — — — — — —
> 10: — — — — — — — — — — — — — — — —
> 20: — — — — UU — — — — — — — — — — —
> 30: — — — — UU — — — — — — — — — — —
> 40: — — — — — — — — — — — — — — — —
> 50: UU — — — — — — — — — — — — — — —
> 60: — — — — — — — — — — — — — — — —
> 70: UU — — — — — — —
> root@beaglebone:~# sudo i2cdetect -r 1
> WARNING! This program can confuse your I2C bus, cause data loss and 
> worse!
> I will probe file /dev/i2c-1 using read byte commands.
> I will probe address range 0x03-0x77.
> Continue? [Y/n] y
> 0 1 2 3 4 5 6 7 8 9 a b c d e f
> 00: — — — — — — — — — — — — —
> 10: — — — — — — — — — — — — — — — —
> 20: — — — — — — — — — — — — — — — —
> 30: — — — — — — — — — — — — — — — —
> 40: — — — — — — — — — — — — — — — —
> 50: — — — — UU UU UU UU — — — — — — — —
> 60: — — — — — — — — — — — — — — — —
> 70: — — — — — — — —
>
>
> But even after connecting my device It is still the same (I mean it 
> still doesn't show the device's address). Any advise?
>
> Thanks
>

>

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/394180d5-b55c-49ae-9900-9e55873a67d7%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] TI Sitara 57XX - Combining Debian FS Image from BeagleBoard-X-15 with Kernel/Boot from TI SDK

[Jeff Andich]

FYI,

Thanks again!!

It was pretty straight forward to get mono and .net applications up and 
running (but haven't tried serial ports over USB yet) the other day on 572x 
EVM with the stock BeagleBoard-X15 image..   Now slogging through 
manipulating all the DT stuff for when the custom hardware with the 5718 
comes along.  Also got to re-build the kernel per your Kconfig.. 

One question ... Is there anything special we need to worry about when 
deploying the BeagleBoard-X15 image (or Debian/TI SDK kernel image) to the 
AM5718 vs. the AM5728, since the former has only one A15 core and the 
BeagleBoard-X15 has the AM5728 chip?



On Wednesday, March 8, 2017 at 8:52:42 AM UTC-6, RobertCNelson wrote:
>
> On Wed, Mar 8, 2017 at 8:29 AM, Jeff Andich  > wrote: 
> > Thanks!! 
> > 
> > While figuring out where/how to drop this defconfig in the TI SDK's 
> > directory structure, and have it override existing kernel configuration 
> > settings, I'm thinking of trying something in "parallel." 
> > 
> > 
> > Since the stock BeagleBoard-X15 SD card image booted Debian on my 57XX 
> EVM 
> > (but with some pru/remoteproc errors), 
>
> The error is because you haven't built "your own" custom pru firmware 
> and copied it to /lib/firmware/ 
>
> > I'm wondering if I can still use the 
> > 572X EVM with the BeagleBoard-X15 SDK image (kernel and all), to move 
> > forward with installing Mono/.Net with RS232/serial port (over USB) + 
> > Ethernet access.I don't know whether the USB ports on the EVM are 
> 2.0 or 
> > 3.0, but if they're < 3.0, then they should work, right? 
>
> the 572xevm is a fork of the x15 design. 
>
> Regards, 
>
> -- 
> Robert Nelson 
> https://rcn-ee.com/ 
>

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/0a6d600d-62fc-4754-9c9b-9e27fdd7e6dd%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Re: Detecting (probing) MPU-9250 connected to beaglebone board black

[christ christ]

Hi Graham,
I have been using the latest version of Debien, for three days now with the
same result.
On the other hand i checked with the oscilloscope the SDA and SCL lines are
not acting like they are supposed to act (even on the default P9_19 and
P9_20).

Thought maybe they all need to be enable.Tried the following method but in
vain (NO such file or directory is the response i'm getting)
*To enable the I2c-1 on the BeagleBone Black Rev A, B and C:*

   1. Rev A/B: Open the file /media/BEAGLEBONE/uEnv.txt in an editor
   (vim/nano)
   2. Rec C: Open the file /boot/uboot/uEnv.txt in an editor (vim/nano)
   3. Add the key "capemgr.enable_partno="
   4. Add the ports you want to enable, comma separated (BB-I2C0, BB-I2C1,
   etc)
   5. Reboot.

Am i right to say the I2c buses are not enable? or is it another proble?

On Thu, Mar 9, 2017 at 4:25 PM, Graham  wrote:

> Then it is not wired or connected correctly.
> Put an oscilloscope on the data and clock lines and see if they are doing
> what they are supposed to do.
> It also looks like you are using an old version of the OS.
> Move to Debian 8, and you should see the I2C devices on bus 2.
> Hook the I2C Clock to P9-19.  Hook the I2C data to P9-20.
> You should not have to mess with the device tree or pin configuration.
> Power and ground also required.
>
> --- Graham
>
> ==
>
> On Thursday, March 9, 2017 at 6:52:04 AM UTC-6, christ christ wrote:
>>
>> The MPU-9250 breakout from spark fun come with pull up resistors.
>>
>> On 09 Mar 2017 00:42, "Graham"  wrote:
>>
>>> Something is not wired right.
>>> Did you put pull-up resistors on the I2C lines?
>>> --- Graham
>>>
>>> ==
>>>
>>> On Wednesday, March 8, 2017 at 12:02:04 PM UTC-6, mamane...@gmail.com
>>> wrote:

 Hi Guys,

 I’m struggling to get the device address (MPU-9250). i got to the
 following stage:


 root@beaglebone:~# sudo i2cdetect -r 0
 WARNING! This program can confuse your I2C bus, cause data loss and
 worse!
 I will probe file /dev/i2c-0 using read byte commands.
 I will probe address range 0x03-0x77.
 Continue? [Y/n] y
 0 1 2 3 4 5 6 7 8 9 a b c d e f
 00: — — — — — — — — — — — — —
 10: — — — — — — — — — — — — — — — —
 20: — — — — UU — — — — — — — — — — —
 30: — — — — UU — — — — — — — — — — —
 40: — — — — — — — — — — — — — — — —
 50: UU — — — — — — — — — — — — — — —
 60: — — — — — — — — — — — — — — — —
 70: UU — — — — — — —
 root@beaglebone:~# sudo i2cdetect -r 1
 WARNING! This program can confuse your I2C bus, cause data loss and
 worse!
 I will probe file /dev/i2c-1 using read byte commands.
 I will probe address range 0x03-0x77.
 Continue? [Y/n] y
 0 1 2 3 4 5 6 7 8 9 a b c d e f
 00: — — — — — — — — — — — — —
 10: — — — — — — — — — — — — — — — —
 20: — — — — — — — — — — — — — — — —
 30: — — — — — — — — — — — — — — — —
 40: — — — — — — — — — — — — — — — —
 50: — — — — UU UU UU UU — — — — — — — —
 60: — — — — — — — — — — — — — — — —
 70: — — — — — — — —


 But even after connecting my device It is still the same (I mean it
 still doesn't show the device's address). Any advise?

 Thanks

>>>

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/CAPTvsHhB1sa-5vUFL%3DCyjVUkNwQ5y%2BoR3ynNczm66bY6DFc8VA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Re: Making a custom SD image of BBB's eMMC

[Charlie Rysenga]

There is a much easier way if you are running the Debian image from BB.org 
there is a script that is already on your bone. Steps are as follows: 

   - Boot master BBB with no SD card in
   - Insert SD card
   - Log in (e.g. with serial terminal, SSH etc.) and run sudo 
   /opt/scripts/tools/eMMC/beaglebone-black-make-microSD-flasher-from-eMMC.sh 
   (you may have to cd /opt/scripts and git pull before this.) LEDs will flash 
   in sequence whilst SD card is being written.
   - When the LEDs stop and the script terminates, remove the SD card.
   - Insert SD card into new BBB then power on.
   - eMMC will be flashed; LEDs on new BBB will flash in sequence until 
   complete.
   

On Monday, March 6, 2017 at 12:46:13 PM UTC-5, Justin Pearson wrote:
>
> I'd like to help a fellow BBB user by sending him a disk image of my 
> working BBB configuration for him to install on his own BBB.
>
> However, I'm not sure how to copy my BBB's eMMC. I was hoping that it 
> would be as simple as using dd to copy my BBB's entire 2GB eMMC into some 
> .img.xz file. But then I found this article:
>
>
> http://blog.logikonlabs.com/how-to-create-a-custom-microsd-card-image-for-the-beaglebone-black/
>
> It's a long procedure. Is this the correct method for creating an image of 
> an entire BBB configuration, suitable for copying to another BBB?
>
> Thanks,
> Justin
>
>

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/9e599566-4b82-4520-8065-41b2aae88119%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Re: Detecting (probing) MPU-9250 connected to beaglebone board black

[Graham Haddock]

Under Debian 8, the external I2C bus is now I2C-2.
I2C-1 is internal only, and used for talking to the PMIC and things like
that.
Don't use it, unless you really understand what you are doing.
--- Graham

==

On Fri, Mar 10, 2017 at 8:08 AM, christ christ 
wrote:

> Hi Graham,
> I have been using the latest version of Debien, for three days now with
> the same result.
> On the other hand i checked with the oscilloscope the SDA and SCL lines
> are not acting like they are supposed to act (even on the default P9_19 and
> P9_20).
>
> Thought maybe they all need to be enable.Tried the following method but in
> vain (NO such file or directory is the response i'm getting)
> *To enable the I2c-1 on the BeagleBone Black Rev A, B and C:*
>
>1. Rev A/B: Open the file /media/BEAGLEBONE/uEnv.txt in an editor
>(vim/nano)
>2. Rec C: Open the file /boot/uboot/uEnv.txt in an editor (vim/nano)
>3. Add the key "capemgr.enable_partno="
>4. Add the ports you want to enable, comma separated (BB-I2C0,
>BB-I2C1, etc)
>5. Reboot.
>
> Am i right to say the I2c buses are not enable? or is it another proble?
>
> On Thu, Mar 9, 2017 at 4:25 PM, Graham  wrote:
>
>> Then it is not wired or connected correctly.
>> Put an oscilloscope on the data and clock lines and see if they are doing
>> what they are supposed to do.
>> It also looks like you are using an old version of the OS.
>> Move to Debian 8, and you should see the I2C devices on bus 2.
>> Hook the I2C Clock to P9-19.  Hook the I2C data to P9-20.
>> You should not have to mess with the device tree or pin configuration.
>> Power and ground also required.
>>
>> --- Graham
>>
>> ==
>>
>> On Thursday, March 9, 2017 at 6:52:04 AM UTC-6, christ christ wrote:
>>>
>>> The MPU-9250 breakout from spark fun come with pull up resistors.
>>>
>>> On 09 Mar 2017 00:42, "Graham"  wrote:
>>>
 Something is not wired right.
 Did you put pull-up resistors on the I2C lines?
 --- Graham

 ==

 On Wednesday, March 8, 2017 at 12:02:04 PM UTC-6, mamane...@gmail.com
 wrote:
>
> Hi Guys,
>
> I’m struggling to get the device address (MPU-9250). i got to the
> following stage:
>
>
> root@beaglebone:~# sudo i2cdetect -r 0
> WARNING! This program can confuse your I2C bus, cause data loss and
> worse!
> I will probe file /dev/i2c-0 using read byte commands.
> I will probe address range 0x03-0x77.
> Continue? [Y/n] y
> 0 1 2 3 4 5 6 7 8 9 a b c d e f
> 00: — — — — — — — — — — — — —
> 10: — — — — — — — — — — — — — — — —
> 20: — — — — UU — — — — — — — — — — —
> 30: — — — — UU — — — — — — — — — — —
> 40: — — — — — — — — — — — — — — — —
> 50: UU — — — — — — — — — — — — — — —
> 60: — — — — — — — — — — — — — — — —
> 70: UU — — — — — — —
> root@beaglebone:~# sudo i2cdetect -r 1
> WARNING! This program can confuse your I2C bus, cause data loss and
> worse!
> I will probe file /dev/i2c-1 using read byte commands.
> I will probe address range 0x03-0x77.
> Continue? [Y/n] y
> 0 1 2 3 4 5 6 7 8 9 a b c d e f
> 00: — — — — — — — — — — — — —
> 10: — — — — — — — — — — — — — — — —
> 20: — — — — — — — — — — — — — — — —
> 30: — — — — — — — — — — — — — — — —
> 40: — — — — — — — — — — — — — — — —
> 50: — — — — UU UU UU UU — — — — — — — —
> 60: — — — — — — — — — — — — — — — —
> 70: — — — — — — — —
>
>
> But even after connecting my device It is still the same (I mean it
> still doesn't show the device's address). Any advise?
>
> Thanks
>

>

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/CANN_KV5OQzLvi9ckb%3D8yDKubQbbCQri8t-VO4aEVe4zSx2O64Q%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Re: Detecting (probing) MPU-9250 connected to beaglebone board black

[christ christ]

Thanks Graham, I did the update already. Will try to see with the
oscilloscope.

Christ

On Thu, Mar 9, 2017 at 4:25 PM, Graham  wrote:

> Then it is not wired or connected correctly.
> Put an oscilloscope on the data and clock lines and see if they are doing
> what they are supposed to do.
> It also looks like you are using an old version of the OS.
> Move to Debian 8, and you should see the I2C devices on bus 2.
> Hook the I2C Clock to P9-19.  Hook the I2C data to P9-20.
> You should not have to mess with the device tree or pin configuration.
> Power and ground also required.
>
> --- Graham
>
> ==
>
> On Thursday, March 9, 2017 at 6:52:04 AM UTC-6, christ christ wrote:
>>
>> The MPU-9250 breakout from spark fun come with pull up resistors.
>>
>> On 09 Mar 2017 00:42, "Graham"  wrote:
>>
>>> Something is not wired right.
>>> Did you put pull-up resistors on the I2C lines?
>>> --- Graham
>>>
>>> ==
>>>
>>> On Wednesday, March 8, 2017 at 12:02:04 PM UTC-6, mamane...@gmail.com
>>> wrote:

 Hi Guys,

 I’m struggling to get the device address (MPU-9250). i got to the
 following stage:


 root@beaglebone:~# sudo i2cdetect -r 0
 WARNING! This program can confuse your I2C bus, cause data loss and
 worse!
 I will probe file /dev/i2c-0 using read byte commands.
 I will probe address range 0x03-0x77.
 Continue? [Y/n] y
 0 1 2 3 4 5 6 7 8 9 a b c d e f
 00: — — — — — — — — — — — — —
 10: — — — — — — — — — — — — — — — —
 20: — — — — UU — — — — — — — — — — —
 30: — — — — UU — — — — — — — — — — —
 40: — — — — — — — — — — — — — — — —
 50: UU — — — — — — — — — — — — — — —
 60: — — — — — — — — — — — — — — — —
 70: UU — — — — — — —
 root@beaglebone:~# sudo i2cdetect -r 1
 WARNING! This program can confuse your I2C bus, cause data loss and
 worse!
 I will probe file /dev/i2c-1 using read byte commands.
 I will probe address range 0x03-0x77.
 Continue? [Y/n] y
 0 1 2 3 4 5 6 7 8 9 a b c d e f
 00: — — — — — — — — — — — — —
 10: — — — — — — — — — — — — — — — —
 20: — — — — — — — — — — — — — — — —
 30: — — — — — — — — — — — — — — — —
 40: — — — — — — — — — — — — — — — —
 50: — — — — UU UU UU UU — — — — — — — —
 60: — — — — — — — — — — — — — — — —
 70: — — — — — — — —


 But even after connecting my device It is still the same (I mean it
 still doesn't show the device's address). Any advise?

 Thanks

>>>

-- 
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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/CAPTvsHhKWHOfmkanp6F7X8ADVda-gM%2BRxi_VqAih1sYh5UPZgA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.