[beagleboard] Re: P8_9 and P8_10 from the PRU?

[Jay Doobie]

The libpruss code you posted seemed to use basic as a compiler.  Maybe I 
missed something on the link.

On Sunday, December 25, 2016 at 2:34:15 PM UTC-5, TJF wrote:
>
>
>
> Am Sonntag, 25. Dezember 2016 02:34:57 UTC+1 schrieb Jay Doobie:
>>
>> Thanks, is there a way to do it in ASM rather than basic?  My entire code 
>> base so far is in ASM and I don't really want to recode it.
>>
>
> What do you mean? All the PRU code is in ASM (pasm style).
>
> Regards
>

-- 
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/e29fda0c-af33-458c-ba1b-320ffadec671%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Re: P8_9 and P8_10 from the PRU?

[Jay Doobie]

Thanks, is there a way to do it in ASM rather than basic?  My entire code 
base so far is in ASM and I don't really want to recode it.

On Saturday, December 24, 2016 at 10:04:05 AM UTC-5, TJF wrote:
>
> Hi Jay!
>
> Am Freitag, 23. Dezember 2016 04:25:12 UTC+1 schrieb Jay Doobie:
>>
>> Is there an easy way to access to P8_9 and P8_10 from the PRU?  I haven't 
>> found much code on how one can access the GPIO's, I assume the DTO needs to 
>> set the mode to 7 (GPIO[5] and GPIO[4])?
>>
>
> Find example code in the libpruio 
> <http://beagleboard.org/project/libpruio/> project.
>
> The CPU balls should be in mode 7 after boot / reset, allready -> no DTBO 
> necessary. Check it by executing analyse example 
> <http://users.freebasic-portal.de/tjf/Projekte/libpruio/doc/html/_cha_examples.html#SubSecExaAnalyse>,
>  
> here I get
>
> Header Pins:
> ...
>   P8_09, GPIO 2/05: input, pullup
>   P8_10, GPIO 2/04: input, pullup
> ...
>
> For IO, set or read in GPIO-2 subsystem bits 5 (P8_09) and 4 (P8_10).
>
> Note: the subsystem GPIO-2 is disabled by default:
>
> ...
> GPIO-2 (DeAd: , ClAd: , ClVa: )
>  REVISION: 
>  --> subsystem not handled (is down)
> ...
>
> Regards
>
>

-- 
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/6ed3d42c-98a3-4932-9c9c-7db47db41ed0%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Re: Wireless speed issues?

[Jay Doobie]

The 24v is isolated from the 5v for the BBB, I've found sometimes my 
machine is unstable and sometimes it is fine.  I did pick up a 24v 6a 
supply and haven't had an issue since.  Also, when I plugin the supply to 
the wall, it can support powering up the machine as compared to the 
previous supply which had issues supplying whatever initial power the 
system needs (I didn't design the hardware only reverse engineering it to 
write my own open source software).

On Tuesday, December 20, 2016 at 2:07:53 PM UTC-5, William Hermans wrote:
>
>
>
> On Tue, Dec 20, 2016 at 7:16 AM, Jay Doobie  > wrote:
>
>> Is there a power supply requirement difference between the BBB and a 
>> BBBW?  
>>
>
> You should get, and read the SRM for the BBBW. But there almost certainly 
> is. 
>
>>
>> The BBB works great outside of my machine connected to USB on a computer, 
>> but within the machine it hangs and crashes.  
>>
>> The cape powers the BBB, it has a 24v 2.7a supply.  I have noticed some 
>> funny things (I have to plug it in to the wall first, then the device; it 
>> won't start if the device is plugged in first) with the supply and am in 
>> the process of trying to acquire a new one.
>>
>
> Is everything that needs to be isolated properly isolated ? My buddy 
> designed a cape for us too, which is also 24v powered, But everything is 
> properly isolated, and we're doing some external power management as well.
>

-- 
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/4fc1835d-ba34-4adc-88da-cb3d4b865274%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] P8_9 and P8_10 from the PRU?

[Jay Doobie]

Is there an easy way to access to P8_9 and P8_10 from the PRU?  I haven't 
found much code on how one can access the GPIO's, I assume the DTO needs to 
set the mode to 7 (GPIO[5] and GPIO[4])?

Thanks
J

-- 
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/55102869-3f54-470c-9511-aa69ef50226f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Re: BBBW product image

[Jay Doobie]

Haha, I usually search for "beaglebone black wireless"  I'm glad I never 
did look for BBBW ;)

On Monday, December 19, 2016 at 3:38:36 AM UTC-5, Stephane Charette wrote:
>
> I wanted to make a blog post about the BBBW, and needed an image to use.
>
> For sanity sake, I recommend that people do not make a Google image search 
> for BBBW at work.  Definitely NSFW!
>
> Stéphane
>

-- 
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/99e70ef0-c3dc-46b9-a065-0421dab97b4f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Re: Wireless speed issues?

[Jay Doobie]

Is there a power supply requirement difference between the BBB and a BBBW?  

The BBB works great outside of my machine connected to USB on a computer, 
but within the machine it hangs and crashes.  

The cape powers the BBB, it has a 24v 2.7a supply.  I have noticed some 
funny things (I have to plug it in to the wall first, then the device; it 
won't start if the device is plugged in first) with the supply and am in 
the process of trying to acquire a new one.

/J

On Monday, December 19, 2016 at 7:09:19 PM UTC-5, William Hermans wrote:
>
> If your power supply reliably supplies 1A or more, at 5v, then that's 
> probably not the problem.
>
> On Mon, Dec 19, 2016 at 5:00 PM, Jay Doobie  > wrote:
>
>> I think I know what is going on, I think the BBBW uses a bit more power 
>> than the BBB, I believe the power supply that came with my 3d printer may 
>> either be faulty or at it's limit of what it can supply.  Going to look 
>> into a slightly beefier supply.
>>
>> On Monday, December 19, 2016 at 3:42:01 PM UTC-5, William Hermans wrote:
>>>
>>> Well I do not have a BBBW, but I do have an rPI 3. Disabling power save 
>>> at boot is fairly easy.
>>>
>>> william@rpi:~$ sudo nano /etc/rc.local
>>> Add: /sbin/iw dev wlan0 set power_save off
>>>
>>> william@rpi:~$ sudo reboot
>>> william@rpi:~$ iwconfig wlan0
>>> wlan0 IEEE 802.11bgn  Mode:Master  Tx-Power=31 dBm
>>>   Retry short limit:7   RTS thr:off   Fragment thr:off
>>>   Power Management:off
>>>
>>> However, I have a sneaking suspicion that this, and all the other 
>>> methods mentioned above won't work. I'm fairly sure Robert is using some 
>>> form of a network manager to handle the BBBW's wireless, and in this case, 
>>> disabling power_save will have to be done through this network manager.
>>>
>>>
>>>
>>> On Mon, Dec 19, 2016 at 10:52 AM, Jay Doobie  wrote:
>>>
>>>> At this point I don't know what it is.  I setup a cronjob to turn off 
>>>> wireless power management, but something else seems to be causing a crash. 
>>>>  
>>>> My SSH hangs or so so slow that I can type "ls" and walk away to make a 
>>>> cup 
>>>> of coffee and it still hasn't done an 'ls', but 5 minutes later, bam, it 
>>>> happens.  
>>>>
>>>> I've looked in dmesg and journalctl to see if there are any messages, 
>>>> but nothing.
>>>>
>>>> -- 
>>>> 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...@googlegroups.com.
>>>> To view this discussion on the web visit 
>>>> https://groups.google.com/d/msgid/beagleboard/2c23a6b8-df50-4a95-a43d-fbd9499724c0%40googlegroups.com
>>>>  
>>>> <https://groups.google.com/d/msgid/beagleboard/2c23a6b8-df50-4a95-a43d-fbd9499724c0%40googlegroups.com?utm_medium=email&utm_source=footer>
>>>> .
>>>>
>>>> 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...@googlegroups.com .
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/beagleboard/1a0cb60b-64ac-4cbf-b677-6999df34da78%40googlegroups.com
>>  
>> <https://groups.google.com/d/msgid/beagleboard/1a0cb60b-64ac-4cbf-b677-6999df34da78%40googlegroups.com?utm_medium=email&utm_source=footer>
>> .
>>
>> 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/5e2e1294-e908-4566-b384-dc3f975839e2%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Re: Wireless speed issues?

[Jay Doobie]

I think I know what is going on, I think the BBBW uses a bit more power 
than the BBB, I believe the power supply that came with my 3d printer may 
either be faulty or at it's limit of what it can supply.  Going to look 
into a slightly beefier supply.

On Monday, December 19, 2016 at 3:42:01 PM UTC-5, William Hermans wrote:
>
> Well I do not have a BBBW, but I do have an rPI 3. Disabling power save at 
> boot is fairly easy.
>
> william@rpi:~$ sudo nano /etc/rc.local
> Add: /sbin/iw dev wlan0 set power_save off
>
> william@rpi:~$ sudo reboot
> william@rpi:~$ iwconfig wlan0
> wlan0 IEEE 802.11bgn  Mode:Master  Tx-Power=31 dBm
>   Retry short limit:7   RTS thr:off   Fragment thr:off
>   Power Management:off
>
> However, I have a sneaking suspicion that this, and all the other methods 
> mentioned above won't work. I'm fairly sure Robert is using some form of a 
> network manager to handle the BBBW's wireless, and in this case, disabling 
> power_save will have to be done through this network manager.
>
>
>
> On Mon, Dec 19, 2016 at 10:52 AM, Jay Doobie  > wrote:
>
>> At this point I don't know what it is.  I setup a cronjob to turn off 
>> wireless power management, but something else seems to be causing a crash.  
>> My SSH hangs or so so slow that I can type "ls" and walk away to make a cup 
>> of coffee and it still hasn't done an 'ls', but 5 minutes later, bam, it 
>> happens.  
>>
>> I've looked in dmesg and journalctl to see if there are any messages, but 
>> nothing.
>>
>> -- 
>> 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...@googlegroups.com .
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/beagleboard/2c23a6b8-df50-4a95-a43d-fbd9499724c0%40googlegroups.com
>>  
>> <https://groups.google.com/d/msgid/beagleboard/2c23a6b8-df50-4a95-a43d-fbd9499724c0%40googlegroups.com?utm_medium=email&utm_source=footer>
>> .
>>
>> 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/1a0cb60b-64ac-4cbf-b677-6999df34da78%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Re: Wireless speed issues?

[Jay Doobie]

At this point I don't know what it is.  I setup a cronjob to turn off 
wireless power management, but something else seems to be causing a crash. 
 My SSH hangs or so so slow that I can type "ls" and walk away to make a 
cup of coffee and it still hasn't done an 'ls', but 5 minutes later, bam, 
it happens.  

I've looked in dmesg and journalctl to see if there are any messages, but 
nothing.

-- 
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/2c23a6b8-df50-4a95-a43d-fbd9499724c0%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Re: Wireless speed issues?

[Jay Doobie]

I believe I've found the problem to be power management on the wifi.  I 
have found a way to disable it manually, but not a method to disable it 
automatically.  Any ideas?

On Thursday, December 15, 2016 at 11:11:21 PM UTC-5, Jay Doobie wrote:
>
> I'm running with bone-debian-8.6-lxqt-4gb-armhf-2016-11-06-4gb.img.xz 
> <https://debian.beagleboard.org/images/bone-debian-8.6-lxqt-4gb-armhf-2016-11-06-4gb.img.xz>,
>  
> and my wireless connected without a problem, however at times I feel like 
> I'm back in the 80s typing on a 300baud modem.  I've checked log files and 
> dmesg and see nothing.  My load average seems to stay high even though I 
> see pretty much everything is idle.
>
>
>

-- 
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/441a050f-3d19-440e-9a33-d2b5701c6a43%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Re: pru + 4.4 kernel?

[Jay Doobie]

Ahhh! Ok, I had modified things so much last night I went back to the 
original and forgot to update the uio pruss in the non-overlay version.  It 
WORKS!

When I was saying pinmux works, I guess I should have indicated that I was 
trying to set 990, 99c, 994 to 0x15.  

So it appears something in the *overlay version is preventing my pinmux 
from being set the way I wanted it, but (for now) it works!

Thank you so much everyone!

/Jason
On Saturday, December 17, 2016 at 10:38:37 AM UTC-5, Greg wrote:
>
> Not totally clear what you are saying.  I see you have the UIO PRUSS line 
> uncommented in "PRU works".
> It is not uncommented in "pinmux works".
>
> So are you saying when you uncomment the UIO PRUSS line to activate it, it 
> kills the pinmux?
> Sorry for the confusion!
>
> On Saturday, December 17, 2016 at 10:28:23 AM UTC-5, Jay Doobie wrote:
>>
>>
>> I have modified the dts files from the dts-rebuilder and in one I can 
>> access the PRU, and in the other I can get the pins set the way I want, but 
>> sadly not at the same time.
>>
>> PRU works: 
>> https://github.com/doobie42/OpenPegasus/blob/master/dtb-rebuilder/src/arm/am335x-boneblack-wireless-emmc-overlay.dts
>>  
>>  
>> pinmux works: 
>> https://github.com/doobie42/OpenPegasus/blob/master/dtb-rebuilder/src/arm/am335x-boneblack-wireless.dts
>>
>> If it is easier for me to post the decompiled DTS (so it is in a single 
>> file) or DTB let me know,
>>
>> /Jay
>>
>

-- 
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/37e61244-3d63-48de-9c26-6660f32b6dc9%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Re: pru + 4.4 kernel?

[Jay Doobie]

uEnv.txt: https://github.com/doobie42/OpenPegasus/blob/master/uEnv.txt

Some progress that might shed light into issues?

I have modified the dts files from the dts-rebuilder and in one I can 
access the PRU, and in the other I can get the pins set the way I want, but 
sadly not at the same time.

PRU works: 
https://github.com/doobie42/OpenPegasus/blob/master/dtb-rebuilder/src/arm/am335x-boneblack-wireless-emmc-overlay.dts
 
 
pinmux 
works: 
https://github.com/doobie42/OpenPegasus/blob/master/dtb-rebuilder/src/arm/am335x-boneblack-wireless.dts

If it is easier for me to post the decompiled DTS (so it is in a single 
file) or DTB let me know,

/Jay

On Saturday, December 17, 2016 at 8:40:30 AM UTC-5, Jay Doobie wrote:
>
> I certainly expect I screwed something up.  I've yet to see a website that 
> really does a good job describing how to get the pru enaled or setting a 
> main DT or overlay.  I was going to try to grab the source for my old main 
> DT and see if I am missing something. I have't been able to get either the 
> PRU or pinmux working again since last yesterday and I stayed up way too 
> late trying.  I'm going to give it an hour or two today then I need to get 
> going on other projects.
>
> On Saturday, December 17, 2016 at 12:57:37 AM UTC-5, William Hermans wrote:
>>
>> Jay,
>>
>> So keep this in mind, 99% chance, what you've done, you've somehow 
>> screwed up. Don't take this as a negative response please. But more or less 
>> a realistic response. I've done "similar" myself. the whole time, I might 
>> be thinking . .. "I'm going to let x.y.z have it on the groups . . ." only 
>> to find that I totally screwed something up in the process.
>>
>> Yeah do what I say, and completely 100% document what you do, as you do 
>> it. Trust me, if you do not thank me for that, you will at least thank 
>> yourself for it.
>>
>> On Fri, Dec 16, 2016 at 8:52 PM, doobie  wrote:
>>
>>> Thanks, that is really sweet looking!  No matter what I do when I load 
>>> my DTO it doesn't seem to change the pinmux/ctrl values unfortunately.   
>>>  Everything in dmesg, journalctl acts as if it worked successfully, but I 
>>> see no change to the pinmux/ctlr.  Is there a kernel (or bone_capemgr) 
>>> level of debug?
>>>
>>> /Jason
>>>
>>> On 16 December 2016 at 22:42, Robert Nelson  wrote:
>>>
>>>> On Fri, Dec 16, 2016 at 9:11 PM, Jay Doobie  wrote:
>>>> > I have no idea what I did, but I'm back to nothing working and have 
>>>> been
>>>> > unable to get the PRU working ( prussdrv_open(PRU_EVTOUT_0) fails in 
>>>> my
>>>> > program), nor am I able to have my DTO configure the pinmux anymore. 
>>>> Is
>>>> > there a way to increase debug levels so I can see what is going on 
>>>> when it
>>>> > tries to load my DTO?
>>>>
>>>> there's a handy script under:
>>>>
>>>> /opt/scripts/device/bone/
>>>>
>>>> sudo perl show-pins.pl
>>>>
>>>> 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...@googlegroups.com.
>>> To view this discussion on the web visit 
>>> https://groups.google.com/d/msgid/beagleboard/CAPXoZv97mhYP9eHUY%3DNrjhn6S4_%2BVwe-o_Pe5_XWU0P4G1SytA%40mail.gmail.com
>>>  
>>> <https://groups.google.com/d/msgid/beagleboard/CAPXoZv97mhYP9eHUY%3DNrjhn6S4_%2BVwe-o_Pe5_XWU0P4G1SytA%40mail.gmail.com?utm_medium=email&utm_source=footer>
>>> .
>>>
>>> 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/2de2e85e-5f24-4a9d-8162-0ef7ab57f013%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Re: pru + 4.4 kernel?

[Jay Doobie]

I certainly expect I screwed something up.  I've yet to see a website that 
really does a good job describing how to get the pru enaled or setting a 
main DT or overlay.  I was going to try to grab the source for my old main 
DT and see if I am missing something. I have't been able to get either the 
PRU or pinmux working again since last yesterday and I stayed up way too 
late trying.  I'm going to give it an hour or two today then I need to get 
going on other projects.

On Saturday, December 17, 2016 at 12:57:37 AM UTC-5, William Hermans wrote:
>
> Jay,
>
> So keep this in mind, 99% chance, what you've done, you've somehow screwed 
> up. Don't take this as a negative response please. But more or less a 
> realistic response. I've done "similar" myself. the whole time, I might be 
> thinking . .. "I'm going to let x.y.z have it on the groups . . ." only to 
> find that I totally screwed something up in the process.
>
> Yeah do what I say, and completely 100% document what you do, as you do 
> it. Trust me, if you do not thank me for that, you will at least thank 
> yourself for it.
>
> On Fri, Dec 16, 2016 at 8:52 PM, doobie > 
> wrote:
>
>> Thanks, that is really sweet looking!  No matter what I do when I load my 
>> DTO it doesn't seem to change the pinmux/ctrl values unfortunately.   
>>  Everything in dmesg, journalctl acts as if it worked successfully, but I 
>> see no change to the pinmux/ctlr.  Is there a kernel (or bone_capemgr) 
>> level of debug?
>>
>> /Jason
>>
>> On 16 December 2016 at 22:42, Robert Nelson > > wrote:
>>
>>> On Fri, Dec 16, 2016 at 9:11 PM, Jay Doobie >> > wrote:
>>> > I have no idea what I did, but I'm back to nothing working and have 
>>> been
>>> > unable to get the PRU working ( prussdrv_open(PRU_EVTOUT_0) fails in my
>>> > program), nor am I able to have my DTO configure the pinmux anymore. Is
>>> > there a way to increase debug levels so I can see what is going on 
>>> when it
>>> > tries to load my DTO?
>>>
>>> there's a handy script under:
>>>
>>> /opt/scripts/device/bone/
>>>
>>> sudo perl show-pins.pl
>>>
>>> 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...@googlegroups.com .
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/beagleboard/CAPXoZv97mhYP9eHUY%3DNrjhn6S4_%2BVwe-o_Pe5_XWU0P4G1SytA%40mail.gmail.com
>>  
>> <https://groups.google.com/d/msgid/beagleboard/CAPXoZv97mhYP9eHUY%3DNrjhn6S4_%2BVwe-o_Pe5_XWU0P4G1SytA%40mail.gmail.com?utm_medium=email&utm_source=footer>
>> .
>>
>> 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/99ca71bc-a080-47ba-9fbb-c0e2531860d9%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Re: pru + 4.4 kernel?

[Jay Doobie]

I also just realized, I posted this in the BBB group, not the BBB wireless 
one.  It is a wireless BBB I just received the other day.

On Friday, December 16, 2016 at 10:52:27 PM UTC-5, Jay Doobie wrote:
>
> Thanks, that is really sweet looking!  No matter what I do when I load my 
> DTO it doesn't seem to change the pinmux/ctrl values unfortunately.   
>  Everything in dmesg, journalctl acts as if it worked successfully, but I 
> see no change to the pinmux/ctlr.  Is there a kernel (or bone_capemgr) 
> level of debug?
>
> /Jason
>
>>
>> > I have no idea what I did, but I'm back to nothing working and have been
>> > unable to get the PRU working ( prussdrv_open(PRU_EVTOUT_0) fails in my
>> > program), nor am I able to have my DTO configure the pinmux anymore. Is
>> > there a way to increase debug levels so I can see what is going on when 
>> it
>> > tries to load my DTO?
>>
>> there's a handy script under:
>>
>> /opt/scripts/device/bone/
>>
>> sudo perl show-pins.pl
>>
>> 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/265b9483-7ba4-4ef5-a4bd-20a9cb91d84d%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Re: pru + 4.4 kernel?

[Jay Doobie]

I have no idea what I did, but I'm back to nothing working and have been 
unable to get the PRU working ( prussdrv_open(PRU_EVTOUT_0) fails in my 
program), nor am I able to have my DTO configure the pinmux anymore. Is 
there a way to increase debug levels so I can see what is going on when it 
tries to load my DTO?

/jason 

On Friday, December 16, 2016 at 2:06:07 PM UTC-5, Jay Doobie wrote:
>
> Yeah, of course now the PRU died, which I had working before .time to 
> debug that again :)
>
> On Friday, December 16, 2016 at 2:00:53 PM UTC-5, William Hermans wrote:
>>
>>
>>
>> On Fri, Dec 16, 2016 at 11:55 AM, Jay Doobie  wrote:
>>
>>> Ya know, I figured out what happened, I wish things were a bit better 
>>> documented, what you indicated above about creating the initramfs fixed 
>>> it.  I believe what happened was I modifed the uEnv.txt file and thought it 
>>> took my changes, but it didn't.  I was running still with HDMI enabled and 
>>> that conflicted with my DTS.
>>>
>>> I'll have to reassemble the machine now (I took the board out to put on 
>>> a scope), but the values in the pinmux/pins file look correct now.
>>>
>>> /Jason
>>>
>>
>> Ah, yeah, that'll do it. One thing I always do when working with various 
>> things that take many commands to perform, and may easily be forgotten or 
>> messed up. Is to create a text file of exact steps I've done to achieve my 
>> end goal. Then when it comes to duplicating those steps, it turns into a 
>> copy paste session that usually succeeds. Which also gives me an easy way 
>> of creating a bash script later if needed. What just happened to you, 
>> forgetting ti disable the HDMI pins has happened to me before many times in 
>> the past . . .
>>
>>

-- 
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/3a5682de-f144-45d7-905a-2e91f46ceab2%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Re: pru + 4.4 kernel?

[Jay Doobie]

Yeah, of course now the PRU died, which I had working before .time to 
debug that again :)

On Friday, December 16, 2016 at 2:00:53 PM UTC-5, William Hermans wrote:
>
>
>
> On Fri, Dec 16, 2016 at 11:55 AM, Jay Doobie  > wrote:
>
>> Ya know, I figured out what happened, I wish things were a bit better 
>> documented, what you indicated above about creating the initramfs fixed 
>> it.  I believe what happened was I modifed the uEnv.txt file and thought it 
>> took my changes, but it didn't.  I was running still with HDMI enabled and 
>> that conflicted with my DTS.
>>
>> I'll have to reassemble the machine now (I took the board out to put on a 
>> scope), but the values in the pinmux/pins file look correct now.
>>
>> /Jason
>>
>
> Ah, yeah, that'll do it. One thing I always do when working with various 
> things that take many commands to perform, and may easily be forgotten or 
> messed up. Is to create a text file of exact steps I've done to achieve my 
> end goal. Then when it comes to duplicating those steps, it turns into a 
> copy paste session that usually succeeds. Which also gives me an easy way 
> of creating a bash script later if needed. What just happened to you, 
> forgetting ti disable the HDMI pins has happened to me before many times in 
> the past . . .
>
>

-- 
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/a4b08be3-d062-465d-842a-0e0bea2c5967%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Re: pru + 4.4 kernel?

[Jay Doobie]

Ya know, I figured out what happened, I wish things were a bit better 
documented, what you indicated above about creating the initramfs fixed it. 
 I believe what happened was I modifed the uEnv.txt file and thought it 
took my changes, but it didn't.  I was running still with HDMI enabled and 
that conflicted with my DTS.

I'll have to reassemble the machine now (I took the board out to put on a 
scope), but the values in the pinmux/pins file look correct now.

/Jason

On Friday, December 16, 2016 at 1:52:11 PM UTC-5, William Hermans wrote:
>
> Jay, 
>
> Ok, so can you describe in more detail what the problem is ? Also pasting 
> the output of the commands you're running to test your overlay may help too.
>
> On Fri, Dec 16, 2016 at 11:45 AM, Jay Doobie  > wrote:
>
>> I was grepping /sys/kernel/debug/pinctrl/44e10800.pinmux/pins for 994 -B 
>> 4 -A4 
>>
>> and loading my overlay manually: "echo openpegasus > 
>> /sys/devices/platform/bone_capemgr/slots"
>>
>> According to dmesg it seems like it accepts my overlay without error.
>>
>> I'll keep the above in mind when I try to load it by default on boot.
>>
>> /Jason
>>
>> On Friday, December 16, 2016 at 1:41:28 PM UTC-5, William Hermans wrote:
>>>
>>> So whatever way that works for you, is the right way. But yes, in my own 
>>>> opinion loading from uEnv.txt is the proper way. As the pin configurations 
>>>> take place the quickest possible after a boot. 
>>>>
>>>>
>>>>1. So you need the overlay in /lib/firmware of course.
>>>>2. Then you need to add the overlay to the 
>>>>cape_enable=bone_capemgr.enable_partno= line in uEnv.txt
>>>>3. Finally you'll need to update the initramfs
>>>>
>>>> To update the initramfs You need to:
>>>>
>>>> william@beaglebone:~$ cd /opt/scripts/
>>>> william@beaglebone:/opt/scripts$ git pull /* So you need to sudo 
>>>> apt-get install git - If not already installed */
>>>>
>>>> william@beaglebone:/opt/scripts$ cd tools/developers/
>>>>
>>>> william@beaglebone:/opt/scripts/tools/developers$ sudo 
>>>> ./update_initrd.sh
>>>>
>>>> william@beaglebone:/opt/scripts/tools/developers$ sudo reboot
>>>>
>>>> Then your custom overlay will be "injected" into the initramfs, and 
>>>> properly load at boot.
>>>>
>>>
>>>
>>> On Fri, Dec 16, 2016 at 11:39 AM, William Hermans  
>>> wrote:
>>>
>>>> Jay,
>>>>
>>>> If by "updating" you mean your overlay isn't loading at boot. That 
>>>> would be because the overlay is not in the initramfs. Which is needed for 
>>>> the latest images. I actually posted on the groups about this a few days 
>>>> go, so I'll find my post and copy paste the procedure here.
>>>>
>>>> If this is not what you mean, post back and describe in more detail 
>>>> what you mean by "updating".
>>>>
>>>> On Fri, Dec 16, 2016 at 11:23 AM, Jay Doobie  wrote:
>>>>
>>>>> Hi TJF: is there some place I can find more info on the DT's across 
>>>>> kernels?  I'm using 4.4.30-ti-r64.  I have access to the PRU, and I think 
>>>>> my DT isn't updating anything (even though it seems to install properly). 
>>>>>  
>>>>> My DT can be seen here:
>>>>>
>>>>>
>>>>> https://github.com/doobie42/OpenPegasus/blob/master/dto/openpegasus-00A0.dtsi
>>>>>
>>>>> Thanks,
>>>>> Jason
>>>>>
>>>>> On Friday, December 16, 2016 at 11:06:35 AM UTC-5, TJF wrote:
>>>>>>
>>>>>> Hello Jay!
>>>>>>
>>>>>> You need not adapt the device tree when you use a bone kernel. (The 
>>>>>> device tree fixup is for TI kernels only.)
>>>>>>
>>>>>> Am Freitag, 16. Dezember 2016 05:44:26 UTC+1 schrieb Jay Doobie:
>>>>>>>
>>>>>>> I figured out what happened, it wasn't am335x-boneblack.dts, but 
>>>>>>> am335x-boneblack-wireless.dts.  Seems like I can talk to the PRU, but I 
>>>>>>> don't see it doing what it should be doing.  Need to grab a copy of 
>>>>>>> prudebug and see if I can debug what the PRU is trying to do vs. is 
>>>>>

Re: [beagleboard] Re: pru + 4.4 kernel?

[Jay Doobie]

I was grepping /sys/kernel/debug/pinctrl/44e10800.pinmux/pins for 994 -B 4 
-A4 

and loading my overlay manually: "echo openpegasus > 
/sys/devices/platform/bone_capemgr/slots"

According to dmesg it seems like it accepts my overlay without error.

I'll keep the above in mind when I try to load it by default on boot.

/Jason

On Friday, December 16, 2016 at 1:41:28 PM UTC-5, William Hermans wrote:
>
> So whatever way that works for you, is the right way. But yes, in my own 
>> opinion loading from uEnv.txt is the proper way. As the pin configurations 
>> take place the quickest possible after a boot. 
>>
>>
>>1. So you need the overlay in /lib/firmware of course.
>>2. Then you need to add the overlay to the 
>>cape_enable=bone_capemgr.enable_partno= line in uEnv.txt
>>3. Finally you'll need to update the initramfs
>>
>> To update the initramfs You need to:
>>
>> william@beaglebone:~$ cd /opt/scripts/
>> william@beaglebone:/opt/scripts$ git pull /* So you need to sudo apt-get 
>> install git - If not already installed */
>>
>> william@beaglebone:/opt/scripts$ cd tools/developers/
>>
>> william@beaglebone:/opt/scripts/tools/developers$ sudo ./update_initrd.sh
>>
>> william@beaglebone:/opt/scripts/tools/developers$ sudo reboot
>>
>> Then your custom overlay will be "injected" into the initramfs, and 
>> properly load at boot.
>>
>
>
> On Fri, Dec 16, 2016 at 11:39 AM, William Hermans  > wrote:
>
>> Jay,
>>
>> If by "updating" you mean your overlay isn't loading at boot. That would 
>> be because the overlay is not in the initramfs. Which is needed for the 
>> latest images. I actually posted on the groups about this a few days go, so 
>> I'll find my post and copy paste the procedure here.
>>
>> If this is not what you mean, post back and describe in more detail what 
>> you mean by "updating".
>>
>> On Fri, Dec 16, 2016 at 11:23 AM, Jay Doobie > > wrote:
>>
>>> Hi TJF: is there some place I can find more info on the DT's across 
>>> kernels?  I'm using 4.4.30-ti-r64.  I have access to the PRU, and I think 
>>> my DT isn't updating anything (even though it seems to install properly).  
>>> My DT can be seen here:
>>>
>>>
>>> https://github.com/doobie42/OpenPegasus/blob/master/dto/openpegasus-00A0.dtsi
>>>
>>> Thanks,
>>> Jason
>>>
>>> On Friday, December 16, 2016 at 11:06:35 AM UTC-5, TJF wrote:
>>>>
>>>> Hello Jay!
>>>>
>>>> You need not adapt the device tree when you use a bone kernel. (The 
>>>> device tree fixup is for TI kernels only.)
>>>>
>>>> Am Freitag, 16. Dezember 2016 05:44:26 UTC+1 schrieb Jay Doobie:
>>>>>
>>>>> I figured out what happened, it wasn't am335x-boneblack.dts, but 
>>>>> am335x-boneblack-wireless.dts.  Seems like I can talk to the PRU, but I 
>>>>> don't see it doing what it should be doing.  Need to grab a copy of 
>>>>> prudebug and see if I can debug what the PRU is trying to do vs. is doing.
>>>>>
>>>>
>>>> PRU software is independant from the kernel. Once the driver is loaded 
>>>> accordingly, all should work. (Exept the PWM outputs of the eHRPWM modules 
>>>> in the PWMSS subsystems.)
>>>>
>>>> Regards
>>>>
>>> -- 
>>> 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...@googlegroups.com .
>>> To view this discussion on the web visit 
>>> https://groups.google.com/d/msgid/beagleboard/62ff2009-8a84-49d7-b8e4-b71f2bdd3867%40googlegroups.com
>>>  
>>> <https://groups.google.com/d/msgid/beagleboard/62ff2009-8a84-49d7-b8e4-b71f2bdd3867%40googlegroups.com?utm_medium=email&utm_source=footer>
>>> .
>>>
>>> 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/255d6cdc-7ba5-4d31-9f81-dbb1c96bba9a%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Re: pru + 4.4 kernel?

[Jay Doobie]

Hi TJF: is there some place I can find more info on the DT's across 
kernels?  I'm using 4.4.30-ti-r64.  I have access to the PRU, and I think 
my DT isn't updating anything (even though it seems to install properly). 
 My DT can be seen here:

https://github.com/doobie42/OpenPegasus/blob/master/dto/openpegasus-00A0.dtsi

Thanks,
Jason

On Friday, December 16, 2016 at 11:06:35 AM UTC-5, TJF wrote:
>
> Hello Jay!
>
> You need not adapt the device tree when you use a bone kernel. (The device 
> tree fixup is for TI kernels only.)
>
> Am Freitag, 16. Dezember 2016 05:44:26 UTC+1 schrieb Jay Doobie:
>>
>> I figured out what happened, it wasn't am335x-boneblack.dts, but 
>> am335x-boneblack-wireless.dts.  Seems like I can talk to the PRU, but I 
>> don't see it doing what it should be doing.  Need to grab a copy of 
>> prudebug and see if I can debug what the PRU is trying to do vs. is doing.
>>
>
> PRU software is independant from the kernel. Once the driver is loaded 
> accordingly, all should work. (Exept the PWM outputs of the eHRPWM modules 
> in the PWMSS subsystems.)
>
> Regards
>

-- 
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/62ff2009-8a84-49d7-b8e4-b71f2bdd3867%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Re: pru + 4.4 kernel?

[Jay Doobie]

I figured out what happened, it wasn't am335x-boneblack.dts, but 
am335x-boneblack-wireless.dts.  Seems like I can talk to the PRU, but I 
don't see it doing what it should be doing.  Need to grab a copy of 
prudebug and see if I can debug what the PRU is trying to do vs. is doing.

Thanks!

On Thursday, December 15, 2016 at 11:18:48 PM UTC-5, William Hermans wrote:
>
>
>
> On Thu, Dec 15, 2016 at 8:40 PM, Jay Doobie  > wrote:
>
>> Sadly this did not work.  I'm using the default kernel/setup from the 
>> image bone-debian-8.6-lxqt-4gb-armhf-2016-11-06-4gb.img.xz 
>> <https://debian.beagleboard.org/images/bone-debian-8.6-lxqt-4gb-armhf-2016-11-06-4gb.img.xz>.
>>   
>> It uses kernel 4.4.30-ti-r64. Is there something better to start with?  I'd 
>> like something newer than the 2012 build I previously had.
>>
>
> If that did not work, then you're doing something wrong, or you missed a 
> step. But you can not just do what Greg suggested and have it work. You 
> need to make sure you either replace the exact board file you load at boot, 
> or change the board file that loads at boot.
>
> Anyway, I know what Greg suggest works, because I was the first person on 
> the list to test the changes, on the list. Once Robert posted to the list 
> about these changes. In fact, if you search my username on this google 
> group, with the additional keyword "uio_pruss", it probably won't take you 
> long to find the exact steps post I made. 
>

-- 
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/4dc4bda9-4a54-4a2b-83db-f0bb0e0e5569%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Wireless speed issues?

[Jay Doobie]

I'm running with bone-debian-8.6-lxqt-4gb-armhf-2016-11-06-4gb.img.xz 
,
 
and my wireless connected without a problem, however at times I feel like 
I'm back in the 80s typing on a 300baud modem.  I've checked log files and 
dmesg and see nothing.  My load average seems to stay high even though I 
see pretty much everything is idle.


-- 
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/3d865960-4568-420e-ab8a-e548cbd02ada%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Re: pru + 4.4 kernel?

[Jay Doobie]

Sadly this did not work.  I'm using the default kernel/setup from the image 
bone-debian-8.6-lxqt-4gb-armhf-2016-11-06-4gb.img.xz 
.
 
 It uses kernel 4.4.30-ti-r64. Is there something better to start with? 
 I'd like something newer than the 2012 build I previously had.

On Thursday, December 15, 2016 at 10:19:05 PM UTC-5, Greg wrote:
>
> Jay, you have to do a minimal edit to the device tree and rebuild the 
> blobs.
> I'm pretty sure 4.4.x kernels will require this (not sure exactly when 
> this was rolled out).
>
> Clone this to your Beaglebone:
>
> https://github.com/RobertCNelson/dtb-rebuilder
>
> Look in the directory src/arm.
> Find the file:
>
> am335x-bonegreen.dts
>
> or
>
> am335x-boneblack.dts
>
> In the file, you need to uncomment a line like:
>
> /* #include "am33xx-pruss-uio.dtsi" */
>
> Then you need to create a very simple file
>
> /etc/modprobe.d/pruss-blacklist.conf
>
> and include the following:
>
>  blacklist pruss
>  blacklist pruss_intc
>  blacklist pru-rproc
>
> You will find instructions for the above in the dts file.
> Then
>
> make
> make install
> reboot
>
> Then see if it works!  Good luck.
> Greg
>
>
>
>
>
>
>

-- 
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/20de0963-1875-494a-b68d-d33dab062526%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] pru + 4.4 kernel?

[Jay Doobie]

Hi, I was hoping to upgrade from 3.8.13 to the 4.4.x kernels and installed 
4.4.30 on my BBB, my app fails on the following call:

/* Open PRU Interrupt */
> if ((ret = prussdrv_open(PRU_EVTOUT_0))) {
> printf("prussdrv_open open failed\n");
> return;
> } 


Any ideas or pointers on upgrading? 

-- 
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/0f8f3116-9ccd-4581-9704-270f79a7a826%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] ARM->PRU->ARM interrupts for data transfer from ARM->PRU

[Jay Doobie]

awesome!  Thank you!  Do you know where I can find a good example of using 
shared memory?  I am wondering if I might be better off using shared memory 
instead.  Does shared memory work both ways so that ARM can access the PRU 
memory and PRU access the ARM memory?

On Thursday, October 13, 2016 at 10:59:26 PM UTC-4, Charles Steinkuehler 
wrote:
>
> On 10/13/2016 5:48 PM, Jay Doobie wrote: 
> > Hi, 
> > 
> > I'm trying to send some data from ARM to the PRU for the PRU to execute 
> upon it, 
> > but I'm having some issues where it tends to miss some of the data on 
> the PRU, 
> > so I assume I am not synchronizing the interrupts properly, here is 
> basically 
> > what I am doing: 
> > 
> > C code: 
> > 
> > for (i = 0; i < 10; i++) { 
> >   prussdrv_pru_write_memory(PRUSS0_PRU0_DATARAM, SHARED_MEMORY, 
> (unsigned 
> > int*)pkts[i], memSize); 
> >//if I put a sleep here it generally works: usleep(50); 
>
> The ARM has a weak memory model.  You need a memory fence instruction 
> here to insure that all writes before the fence (your write to the PRU 
> memory, above) have completed before any writes after the fence 
> (generating the PRU interrupt) take effect. 
>
> It's a bit ham-fisted, but you can use a __sync_synchronize() here 
> (assuming you're using gcc...it's a full memory barrier).  Or you can 
> use the C++11 memory fence semantics (more complicated).  Either is 
> way better than the "old school" full cache flush and invalidate!  :) 
>
> >//printf("sending intc...\n"); 
> >// here are the packets! 
> >prussdrv_pru_send_event(ARM_PRU0_INTERRUPT); 
> >// wait for PRU response 
> >//printf("waiting intc...\n"); 
> >prussdrv_pru_wait_event (PRU_EVTOUT_0); 
> >// clear PRU response 
> >//printf("clr intc from PRU0...\n"); 
> >prussdrv_pru_clear_event (PRU_EVTOUT_0, PRU0_ARM_INTERRUPT); 
> > 
> >   } 
> > 
> >   PRU: 
> > 
> > HANDLE_DATA: 
> > // wait for interrupt 
> > WBS r31, #30 
> > // reset interrupt 
> > LBCOr20, CONST_IEP, 0x44, 4  // Load CMP_STATUS register 
> > sbco rResetInterrupt, CONST_PRUSSINTC, SICR_OFFSET, 4 
> > // handle data 
> > MOV   R31.b0, PRU0_R31_VEC_VALID | PRU_EVTOUT_0 
> > sub rCounter, rCounter, rCounter 
> > qbne HANDLE_DATA, rCounter, 0 
> > 
> > 
> > Kernel: Linux beaglebone 3.8.13-bone79 #1 SMP Tue Oct 13 20:44:55 UTC 
> 2015 
> > armv7l GNU/Linux 
> > 
> > Thanks! 
>
>
>
> -- 
> Charles Steinkuehler 
> cha...@steinkuehler.net  
>

-- 
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/ec5b24bc-3b9e-4aba-a262-f79355ce0eb4%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] ARM->PRU->ARM interrupts for data transfer from ARM->PRU

[Jay Doobie]

Hi,

I'm trying to send some data from ARM to the PRU for the PRU to execute 
upon it, but I'm having some issues where it tends to miss some of the data 
on the PRU, so I assume I am not synchronizing the interrupts properly, 
here is basically what I am doing:

C code:

for (i = 0; i < 10; i++) {
>  prussdrv_pru_write_memory(PRUSS0_PRU0_DATARAM, SHARED_MEMORY, (unsigned 
> int*)pkts[i], memSize);
>   //if I put a sleep here it generally works: usleep(50);
>   //printf("sending intc...\n");
>   // here are the packets!
>   prussdrv_pru_send_event(ARM_PRU0_INTERRUPT);
>   // wait for PRU response
>   //printf("waiting intc...\n");
>   prussdrv_pru_wait_event (PRU_EVTOUT_0);
>   // clear PRU response
>   //printf("clr intc from PRU0...\n");
>   prussdrv_pru_clear_event (PRU_EVTOUT_0, PRU0_ARM_INTERRUPT);

 }

 PRU:

HANDLE_DATA:
>// wait for interrupt
>WBS r31, #30
>// reset interrupt
>LBCOr20, CONST_IEP, 0x44, 4  // Load CMP_STATUS register
>sbco rResetInterrupt, CONST_PRUSSINTC, SICR_OFFSET, 4
>// handle data
>MOV   R31.b0, PRU0_R31_VEC_VALID | PRU_EVTOUT_0
>sub rCounter, rCounter, rCounter
>qbne HANDLE_DATA, rCounter, 0


Kernel: Linux beaglebone 3.8.13-bone79 #1 SMP Tue Oct 13 20:44:55 UTC 2015 
armv7l GNU/Linux

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/6ea5fc62-1bee-44fd-b13a-56d39c773111%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.