Re: [beagleboard] Re: Tuning the watchdog timer - correct place?

[Hugh Frater]

Yep, I did verify that. You need to use the child_process.execSync()
function to call the tuning binary from Node.js because you must wait for
the tuning to complete before opening the watchdog device from within your
Node.js application. I know, using synchronous functions inside an
asynchronous environment like Node.js is bad practice, blah blah blah - It
works, it's good enough for me.

Verification of the timeout change is done by looking at the timeout and
timeleft entries in:

/sys/devices/platform/ocp/44e35000.wdt/watchdog/watchdog0

For example, on first boot:

debian@beaglebone:/sys/devices/platform/ocp/44e35000.wdt/watchdog/watchdog0$
cat timeout
60

Then I start my Node.js application that in turn calls the watchdog tuning
binary then sets up a 1 second write to the watchdog device:

debian@beaglebone:/sys/devices/platform/ocp/44e35000.wdt/watchdog/watchdog0$
cat timeout
5

debian@beaglebone:/sys/devices/platform/ocp/44e35000.wdt/watchdog/watchdog0$
cat timeleft
4

If I Ctrl-C my Node.js application (simulating a lockup/it crashes etc)
then I can watch the timeout value count down and the system reboots.

I hope that helps...



On Tue, 18 Jun 2019 at 17:40, 'Mark Lazarewicz' via BeagleBoard <
beagleboard@googlegroups.com> wrote:

> Did you verify the time out changed?
> If so how?
>
>
> Sent from Yahoo Mail on Android
> <https://go.onelink.me/107872968?pid=InProduct=Global_Internal_YGrowth_AndroidEmailSig__AndroidUsers_wl=ym_sub1=Internal_sub2=Global_YGrowth_sub3=EmailSignature>
>
> On Tue, Jun 18, 2019 at 7:55 AM, Hugh Frater
>  wrote:
> Update: The kernel watchdog driver support tuning the timout through ioctl
> calls. A quick and dirty bit of C code:
>
>
> int main()
> {
> int fd = open("/dev/watchdog", O_WRONLY);
> int timeout = 5;
> ioctl(fd, WDIOC_SETTIMEOUT, );
> printf("Setting timeout to %d seconds\n", timeout);
> close(fd);
> return 0;
> }
>
> Will tune the watchdog. I use node.js' child_process to call the above
> code (when compiled, obviously), if my node.js app crashes then the BBB
> will reboot. Perfect
>
> On Monday, 3 June 2019 13:07:49 UTC+1, Hugh Frater wrote:
>
> Where does one go to tune the watchdog timer? Is it a
> kernel-recompilation-required thing, or can it be done through uBoot?
>
> Or should I just use my PRU code to tune the watchdog control register
> when it boots? This would be the easiest option for me, if someone can
> point me at the correct area if the AM335XTRM? I had a look in there and
> couldn't find the correct registers.
>
> I'd like it to run about 10 seconds if possible for my application.
>
> --
> 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/ab8ea583-ab9a-4017-a89f-6bd8127eaf47%40googlegroups.com
> <https://groups.google.com/d/msgid/beagleboard/ab8ea583-ab9a-4017-a89f-6bd8127eaf47%40googlegroups.com?utm_medium=email_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 a topic in the
> Google Groups "BeagleBoard" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/beagleboard/ovGQSAXqwBE/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/952566089.2906417.1560876023480%40mail.yahoo.com
> <https://groups.google.com/d/msgid/beagleboard/952566089.2906417.1560876023480%40mail.yahoo.com?utm_medium=email_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/CAPm6wa11-z9GOguf%3DdddpFob1PsVZAi4U%2BMcmv80gQ-W6duydg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Re: Tuning the watchdog timer - correct place?

[Hugh Frater]

Update: The kernel watchdog driver support tuning the timout through ioctl 
calls. A quick and dirty bit of C code:


int main()
{
int fd = open("/dev/watchdog", O_WRONLY);
int timeout = 5;
ioctl(fd, WDIOC_SETTIMEOUT, );
printf("Setting timeout to %d seconds\n", timeout);
close(fd);
return 0;
}

Will tune the watchdog. I use node.js' child_process to call the above code 
(when compiled, obviously), if my node.js app crashes then the BBB will 
reboot. Perfect

On Monday, 3 June 2019 13:07:49 UTC+1, Hugh Frater wrote:
>
> Where does one go to tune the watchdog timer? Is it a 
> kernel-recompilation-required thing, or can it be done through uBoot?
>
> Or should I just use my PRU code to tune the watchdog control register 
> when it boots? This would be the easiest option for me, if someone can 
> point me at the correct area if the AM335XTRM? I had a look in there and 
> couldn't find the correct registers.
>
> I'd like it to run about 10 seconds if possible for my application.
>

-- 
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/ab8ea583-ab9a-4017-a89f-6bd8127eaf47%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Tuning the watchdog timer - correct place?

[Hugh Frater]

An update - I haven't got round to testing new PRU code. However, this:

Setting and getting the timeout:
For some drivers it is possible to modify the watchdog timeout on the
fly with the SETTIMEOUT ioctl, those drivers have the WDIOF_SETTIMEOUT
flag set in their option field. The argument is an integer
representing the timeout in seconds. The driver returns the real
timeout used in the same variable, and this timeout might differ from
the requested one due to limitation of the hardware. 
>From 
here: 
https://github.com/philenotfound/beagleboneblack-kernel/blob/master/Documentation/watchdog/watchdog-api.txt

Looks relevant. Does anyone know if the Watchdog driver supports on the fly 
timeout adjustment?

On Tuesday, 4 June 2019 10:57:40 UTC+1, Hugh Frater wrote:

My experience of working directly with the i2c and eqep parts of the 
> silicon from within the PRU suggest that register access to the watchdog 
> peripheral would be both easy and reliable. It's simply a #define and you 
> can then access the register contents directly from within the PRU. 
>
> I will write some test code to reconfigure the watchdog and report back.
>
> On Tuesday, 4 June 2019 02:02:37 UTC+1, lazarman wrote:
>>
>> I'd ask the question are these register's accessable from the PRU my 
>> experience is dated and I'm not a Linux guy but most OS protect Access to 
>> certain registers I briefly looked at TRM the WDOG is enabled by default 
>> probably during boot. To set it or change the clock source you disable it 
>> which I doubt Linux would like from PRU side  but maybe I'm wrong. I'd look 
>> at the interconnect block diagram to see if PRU has access to the 
>> registers. Google am335x watchdog c code I see discussion about Kernel 
>> configuration. Typically on non Linux ARM side project TI provided quite a 
>> bit of example code for customer boot code options that's where I always 
>> start but that code isn't always in the public  domain and in your case 
>> isn't relavent after Linux takes over you may have to let ARM Linux side 
>> handle it. I'd look at PRU register memory map unless someone in here has 
>> done it from PRU. 
>> Good luck
>>
>> Sent from Yahoo Mail on Android 
>> <https://go.onelink.me/107872968?pid=InProduct=Global_Internal_YGrowth_AndroidEmailSig__AndroidUsers_wl=ym_sub1=Internal_sub2=Global_YGrowth_sub3=EmailSignature>
>>
>> On Mon, Jun 3, 2019 at 7:07 AM, Hugh Frater
>>  wrote:
>> Where does one go to tune the watchdog timer? Is it a 
>> kernel-recompilation-required thing, or can it be done through uBoot?
>>
>> Or should I just use my PRU code to tune the watchdog control 
>> register when it boots? This would be the easiest option for me, if someone 
>> can point me at the correct area if the AM335XTRM? I had a look in there 
>> and couldn't find the correct registers.
>>
>> I'd like it to run about 10 seconds if possible for my application.
>>
>> -- 
>> 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 beagl...@googlegroups.com.
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/beagleboard/2d6c30bf-484e-49e6-ab9d-582535f60a84%40googlegroups.com
>>  
>> <https://groups.google.com/d/msgid/beagleboard/2d6c30bf-484e-49e6-ab9d-582535f60a84%40googlegroups.com?utm_medium=email_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/d5001fc4-3965-407f-8146-77c07a3a2718%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Tuning the watchdog timer - correct place?

[Hugh Frater]

My experience of working directly with the i2c and eqep parts of the 
silicon from within the PRU suggest that register access to the watchdog 
peripheral would be both easy and reliable. It's simply a #define and you 
can then access the register contents directly from within the PRU. 

I will write some test code to reconfigure the watchdog and report back.

On Tuesday, 4 June 2019 02:02:37 UTC+1, lazarman wrote:
>
> I'd ask the question are these register's accessable from the PRU my 
> experience is dated and I'm not a Linux guy but most OS protect Access to 
> certain registers I briefly looked at TRM the WDOG is enabled by default 
> probably during boot. To set it or change the clock source you disable it 
> which I doubt Linux would like from PRU side  but maybe I'm wrong. I'd look 
> at the interconnect block diagram to see if PRU has access to the 
> registers. Google am335x watchdog c code I see discussion about Kernel 
> configuration. Typically on non Linux ARM side project TI provided quite a 
> bit of example code for customer boot code options that's where I always 
> start but that code isn't always in the public  domain and in your case 
> isn't relavent after Linux takes over you may have to let ARM Linux side 
> handle it. I'd look at PRU register memory map unless someone in here has 
> done it from PRU. 
> Good luck
>
> Sent from Yahoo Mail on Android 
> <https://go.onelink.me/107872968?pid=InProduct=Global_Internal_YGrowth_AndroidEmailSig__AndroidUsers_wl=ym_sub1=Internal_sub2=Global_YGrowth_sub3=EmailSignature>
>
> On Mon, Jun 3, 2019 at 7:07 AM, Hugh Frater
> > wrote:
> Where does one go to tune the watchdog timer? Is it a 
> kernel-recompilation-required thing, or can it be done through uBoot?
>
> Or should I just use my PRU code to tune the watchdog control register 
> when it boots? This would be the easiest option for me, if someone can 
> point me at the correct area if the AM335XTRM? I had a look in there and 
> couldn't find the correct registers.
>
> I'd like it to run about 10 seconds if possible for my application.
>
> -- 
> 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 beagl...@googlegroups.com .
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/beagleboard/2d6c30bf-484e-49e6-ab9d-582535f60a84%40googlegroups.com
>  
> <https://groups.google.com/d/msgid/beagleboard/2d6c30bf-484e-49e6-ab9d-582535f60a84%40googlegroups.com?utm_medium=email_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/aaedce6d-668e-420d-a1c1-a8f19744c236%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Re: Tuning the watchdog timer - correct place?

[Hugh Frater]

Update: page 4492 of the TRM details the watchdog timer. I'll probably use 
the PRU to configure the registers unless there is an easier way...

On Monday, 3 June 2019 13:07:49 UTC+1, Hugh Frater wrote:
>
> Where does one go to tune the watchdog timer? Is it a 
> kernel-recompilation-required thing, or can it be done through uBoot?
>
> Or should I just use my PRU code to tune the watchdog control register 
> when it boots? This would be the easiest option for me, if someone can 
> point me at the correct area if the AM335XTRM? I had a look in there and 
> couldn't find the correct registers.
>
> I'd like it to run about 10 seconds if possible for my application.
>

-- 
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/5aef9f7c-4aa3-4f56-9fbf-0e3fff17538f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Tuning the watchdog timer - correct place?

[Hugh Frater]

Where does one go to tune the watchdog timer? Is it a 
kernel-recompilation-required thing, or can it be done through uBoot?

Or should I just use my PRU code to tune the watchdog control register 
when it boots? This would be the easiest option for me, if someone can 
point me at the correct area if the AM335XTRM? I had a look in there and 
couldn't find the correct registers.

I'd like it to run about 10 seconds if possible for my application.

-- 
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/2d6c30bf-484e-49e6-ab9d-582535f60a84%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] cape-universal vs custom overlay

[Hugh Frater]

I'm getting our product ready for production... During the development 
phase I've been using cape-universal and have a script that runs at boot 
time that just serially runs config-pin to setup all of the 30 pins we 
need. There is a mix of GPIO, eQEP, i2c and some uarts... this little 
script isn't exactly ideal for boot time reduction, it takes 10-12 seconds 
or so to run according to systemd-analyze

Will I save a bunch of time if I write this pimux'ing mess as a custom 
device tree overlay (no, we don't have an identity eeprom on our interface 
card)?

Will a custom overlay properly setup the required directory entries in the 
filesystem for bonscript to work? We do some slow GPIO and uarts through 
bonescript, the eQEP and i2c is done directly from the PRU.

-- 
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/89e7bb8c-fd98-465b-8844-571cf19cef97%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] firmware loads fail, remoteproc error codes

[Hugh Frater]

If anyone stumbles upon this thread - the attached script will allow init.d 
to start the PRU at boot time which the new pru_rproc driver doesn't seem 
to do. In debian 8.7 with 4.4 kernels, it needed a reboot once the kernel 
module had loaded because of a bug creating the rpmsg entry in /dev. I've 
modified my pru-rebooting script to instead start the PRU.

Configure the script to start with the following:

1. Copy script to /etc/init.d

2. chmod 755 script

3. sudo update-rc.d start-pru.sh defaults




On Tuesday, 28 May 2019 17:36:09 UTC+1, Hugh Frater wrote:
>
> Fixed it...
>
> sudo sh -c "echo 'start' > state" from within 
> /sys/devices/platform/ocp/4a326004.pruss-soc-bus/4a30.pruss/4a338000.pru/remoteproc/remoteproc2
>
>
>
> On Tuesday, 28 May 2019 17:25:44 UTC+1, Hugh Frater wrote:
>>
>> My takeaway from Mark's excellent writeup is that I should be able to 
>> copy my .out file into /lib/firmware with the correct naming convention.
>>
>> I should then be able to echo 'start' or 'stop' to the correct state 
>> file. Which seems to be located at:
>>
>> debian@beaglebone:/sys/devices/platform/ocp/4a326004.pruss-soc-bus/4a30.pruss/4a338000.pru/remoteproc/remoteproc2$
>>  
>> cat state
>> offline
>>
>> For PRU1
>>
>> Hmmm 
>>
>> On Tuesday, 28 May 2019 17:00:04 UTC+1, Hugh Frater wrote:
>>>
>>> Reading it now, I'll be back... Cheers for all your help up till now
>>>
>>> On Tuesday, 28 May 2019 16:53:47 UTC+1, RobertCNelson wrote:
>>>>
>>>> On Tue, May 28, 2019 at 10:41 AM Hugh Frater  
>>>> wrote: 
>>>> > 
>>>> > Tried both those fixes Robert, no joy. Is it still acceptable 
>>>> practice to symlink am335x-pru1-fw to our .out file? 
>>>> > 
>>>> > Google led me to this post: 
>>>> > 
>>>> > 
>>>> http://e2e.ti.com/support/processors/f/791/t/783113?Linux-AM3358-remoteproc-remoteproc0-Direct-firmware-load-for-tmp-PRU-LED1-out-failed-with-error-2
>>>>  
>>>> > 
>>>> > Where the OP had a fix which involved echo'ing the path of the PRU 
>>>> binary from /lib/firmware into /sys/class/remoteproc/remoteproc2/firmware. 
>>>> I've tried that also... 
>>>> > 
>>>> > Have things changed in the move to 4.14 and uBoot overlays or should 
>>>> the old ways still work? 
>>>>
>>>> Take a look at Mark's writeup: 
>>>>
>>>> https://markayoder.github.io/PRUCookbook/ 
>>>>
>>>> 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/af2622b2-bfb7-491b-aa29-bfee763d0aff%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
#!/bin/bash

### BEGIN INIT INFO
# Provides:  start-pru
# Required-Start:$remote_fs $syslog
# Required-Stop: $remote_fs $syslog
# Default-Start: 2 3 4 5
# Default-Stop:  0 1 6
# Short-Description: start-pru
# Description:   Starts PRU1 after boot
#  

### END INIT INFO

# Author: Hugh Frater  /sys/class/remoteproc/remoteproc2/state

Re: [beagleboard] firmware loads fail, remoteproc error codes

[Hugh Frater]

Fixed it...

sudo sh -c "echo 'start' > state" from within 
/sys/devices/platform/ocp/4a326004.pruss-soc-bus/4a30.pruss/4a338000.pru/remoteproc/remoteproc2



On Tuesday, 28 May 2019 17:25:44 UTC+1, Hugh Frater wrote:
>
> My takeaway from Mark's excellent writeup is that I should be able to copy 
> my .out file into /lib/firmware with the correct naming convention.
>
> I should then be able to echo 'start' or 'stop' to the correct state file. 
> Which seems to be located at:
>
> debian@beaglebone:/sys/devices/platform/ocp/4a326004.pruss-soc-bus/4a30.pruss/4a338000.pru/remoteproc/remoteproc2$
>  
> cat state
> offline
>
> For PRU1
>
> Hmmm.... 
>
> On Tuesday, 28 May 2019 17:00:04 UTC+1, Hugh Frater wrote:
>>
>> Reading it now, I'll be back... Cheers for all your help up till now
>>
>> On Tuesday, 28 May 2019 16:53:47 UTC+1, RobertCNelson wrote:
>>>
>>> On Tue, May 28, 2019 at 10:41 AM Hugh Frater  
>>> wrote: 
>>> > 
>>> > Tried both those fixes Robert, no joy. Is it still acceptable practice 
>>> to symlink am335x-pru1-fw to our .out file? 
>>> > 
>>> > Google led me to this post: 
>>> > 
>>> > 
>>> http://e2e.ti.com/support/processors/f/791/t/783113?Linux-AM3358-remoteproc-remoteproc0-Direct-firmware-load-for-tmp-PRU-LED1-out-failed-with-error-2
>>>  
>>> > 
>>> > Where the OP had a fix which involved echo'ing the path of the PRU 
>>> binary from /lib/firmware into /sys/class/remoteproc/remoteproc2/firmware. 
>>> I've tried that also... 
>>> > 
>>> > Have things changed in the move to 4.14 and uBoot overlays or should 
>>> the old ways still work? 
>>>
>>> Take a look at Mark's writeup: 
>>>
>>> https://markayoder.github.io/PRUCookbook/ 
>>>
>>> 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/00c9b71b-a203-47cb-afc3-2645dc9e097b%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] firmware loads fail, remoteproc error codes

[Hugh Frater]

My takeaway from Mark's excellent writeup is that I should be able to copy 
my .out file into /lib/firmware with the correct naming convention.

I should then be able to echo 'start' or 'stop' to the correct state file. 
Which seems to be located at:

debian@beaglebone:/sys/devices/platform/ocp/4a326004.pruss-soc-bus/4a30.pruss/4a338000.pru/remoteproc/remoteproc2$
 
cat state
offline

For PRU1

Hmmm 

On Tuesday, 28 May 2019 17:00:04 UTC+1, Hugh Frater wrote:
>
> Reading it now, I'll be back... Cheers for all your help up till now
>
> On Tuesday, 28 May 2019 16:53:47 UTC+1, RobertCNelson wrote:
>>
>> On Tue, May 28, 2019 at 10:41 AM Hugh Frater  wrote: 
>> > 
>> > Tried both those fixes Robert, no joy. Is it still acceptable practice 
>> to symlink am335x-pru1-fw to our .out file? 
>> > 
>> > Google led me to this post: 
>> > 
>> > 
>> http://e2e.ti.com/support/processors/f/791/t/783113?Linux-AM3358-remoteproc-remoteproc0-Direct-firmware-load-for-tmp-PRU-LED1-out-failed-with-error-2
>>  
>> > 
>> > Where the OP had a fix which involved echo'ing the path of the PRU 
>> binary from /lib/firmware into /sys/class/remoteproc/remoteproc2/firmware. 
>> I've tried that also... 
>> > 
>> > Have things changed in the move to 4.14 and uBoot overlays or should 
>> the old ways still work? 
>>
>> Take a look at Mark's writeup: 
>>
>> https://markayoder.github.io/PRUCookbook/ 
>>
>> 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/e45cb1a7-4fda-40ec-9822-b1bf7f3ac3ff%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] firmware loads fail, remoteproc error codes

[Hugh Frater]

Reading it now, I'll be back... Cheers for all your help up till now

On Tuesday, 28 May 2019 16:53:47 UTC+1, RobertCNelson wrote:
>
> On Tue, May 28, 2019 at 10:41 AM Hugh Frater  > wrote: 
> > 
> > Tried both those fixes Robert, no joy. Is it still acceptable practice 
> to symlink am335x-pru1-fw to our .out file? 
> > 
> > Google led me to this post: 
> > 
> > 
> http://e2e.ti.com/support/processors/f/791/t/783113?Linux-AM3358-remoteproc-remoteproc0-Direct-firmware-load-for-tmp-PRU-LED1-out-failed-with-error-2
>  
> > 
> > Where the OP had a fix which involved echo'ing the path of the PRU 
> binary from /lib/firmware into /sys/class/remoteproc/remoteproc2/firmware. 
> I've tried that also... 
> > 
> > Have things changed in the move to 4.14 and uBoot overlays or should the 
> old ways still work? 
>
> Take a look at Mark's writeup: 
>
> https://markayoder.github.io/PRUCookbook/ 
>
> 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/64e93360-1e31-410d-90ac-d2cf4f3aeec9%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] firmware loads fail, remoteproc error codes

[Hugh Frater]

Tried both those fixes Robert, no joy. Is it still acceptable practice to 
symlink am335x-pru1-fw to our .out file?

Google led me to this post:

http://e2e.ti.com/support/processors/f/791/t/783113?Linux-AM3358-remoteproc-remoteproc0-Direct-firmware-load-for-tmp-PRU-LED1-out-failed-with-error-2

Where the OP had a fix which involved echo'ing the path of the PRU binary 
from /lib/firmware into /sys/class/remoteproc/remoteproc2/firmware. I've 
tried that also...

Have things changed in the move to 4.14 and uBoot overlays or should the 
old ways still work?

On Tuesday, 28 May 2019 16:33:54 UTC+1, RobertCNelson wrote:
>
> On Tue, May 28, 2019 at 10:27 AM Hugh Frater  > wrote: 
> > 
> > Does anyone know what the remoteproc error codes are? 
> > 
> > pru_rproc doesn't start the pru's at boot time, I assume this is the new 
> behaviour in 4.14 with the uBoot overlays. I've updated initramfs since 
> symlinking my binary to /lib/firmware/am335x-pru1-fw, that hasn't helped. 
> I've done an rmmod/modprobe cycle, that hasn't helped either. 
> > 
> > However, I would have expected it to start when I: 
> > 
> > debian@beaglebone:/lib/firmware$ sudo echo 'start' > 
> /sys/class/remoteproc/remoteproc2/state 
> > -bash: /sys/class/remoteproc/remoteproc2/state: Permission denied 
> > 
> > Looking at dmesg, I see: 
> > 
> > [22251.654264] remoteproc remoteproc2: powering up 4a338000.pru 
> > [22251.654353] remoteproc remoteproc2: Direct firmware load for 
> am335x-pru1-fw failed with error -2 
> > [22251.654371] remoteproc remoteproc2: request_firmware failed: -2 
> > [22251.665903] remoteproc remoteproc2: Boot failed: -2 
> > 
> > The .out file is built with Ti v2.1.5 compiler under CCS - do I need to 
> update my pru-software-support-package? 
> > 
> > It would be handy if I could figure out what the -2 error code was. 
>
> $ errno 2 
> ENOENT 2 No such file or directory 
>
> make sure am335x-pru1-fw is in /lib/firmware/ and the initramfs 
>
> sudo update-initramfs -uk `uname -r` 
>
> 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/166f926e-4671-43f0-9044-d7e03b9c76f0%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] firmware loads fail, remoteproc error codes

[Hugh Frater]

Does anyone know what the remoteproc error codes are?

pru_rproc doesn't start the pru's at boot time, I assume this is the new 
behaviour in 4.14 with the uBoot overlays. I've updated initramfs since 
symlinking my binary to /lib/firmware/am335x-pru1-fw, that hasn't helped. 
I've done an rmmod/modprobe cycle, that hasn't helped either.

However, I would have expected it to start when I:

debian@beaglebone:/lib/firmware$ sudo echo 'start' > 
/sys/class/remoteproc/remoteproc2/state
-bash: /sys/class/remoteproc/remoteproc2/state: Permission denied

Looking at dmesg, I see:

[22251.654264] remoteproc remoteproc2: powering up 4a338000.pru
[22251.654353] remoteproc remoteproc2: Direct firmware load for 
am335x-pru1-fw failed with error -2
[22251.654371] remoteproc remoteproc2: request_firmware failed: -2
[22251.665903] remoteproc remoteproc2: Boot failed: -2

The .out file is built with Ti v2.1.5 compiler under CCS - do I need to 
update my pru-software-support-package?

It would be handy if I could figure out what the -2 error code was.




-- 
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/9562f144-008e-4984-b9bc-fb187eee1c68%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Re: Trouble enabling pru-rproc uBoot overlay

[Hugh Frater]

Good to hear that it is working for you... It's detecting PRUs for me now 
when booting off the SD card - I just need to get them to start my code and 
setup /de/rpmsg_31 properly... another hurdle but I'm sure I will overcome.

On Sunday, 26 May 2019 23:33:37 UTC+1, jonre...@gmail.com wrote:
>
> Okay I managed to get everything working too. I had to do the following 
> steps:
>
> 1. reset eMMC
> sudo /opt/scripts/tools/developers/update_bootloader.sh 
>
> 2. flash new image provided above
>
> 3. After that the model from /opt/scripts/tools/version.sh was wrong for 
> me. I'm using a BBBW but model field had just regular beaglebone black in 
> it. This prevent wifi (via connman) from working. I followed another post 
> about this (
> https://groups.google.com/forum/#!topic/beagleboard/_ydry5HYVNQ) which 
> suggested to reset  eeprom:
>
> GND TP1 then run as root: 
>
> dd 
> if=/opt/scripts/device/bone/bbbw-eeprom.dump 
> of=/sys/devices/platform/ocp/44e0b000.i2c/i2c-0/0-0050/eeprom 
>
> reboot.
>
> Everything works fine now!
>
> Thanks Robert and Hugh
>
> On Saturday, May 25, 2019 at 2:37:07 PM UTC-7, Hugh Frater wrote:
>>
>> Robert, is it ok to use this image in production or should I use the 
>> current stretch IOT image and flash the eMMC to overwrite this old 
>> bootloader?
>>
>> On Saturday, 25 May 2019 20:55:58 UTC+1, RobertCNelson wrote:
>>>
>>> > This is what I think is relevant from my uBoot console: 
>>> > 
>>> > U-Boot SPL 2017.03-2-gd12b1519b4 (Mar 14 2017 - 10:28:26) 
>>> > Trying to boot from MMC2 
>>> > U-Boot 2017.03-2-gd12b1519b4 (Mar 14 2017 - 10:28:26 -0500), 
>>> Build: jenkins- 
>>> > github_Bootloader-Builder-532 
>>>
>>> There you go!! Would you please give me a dd copy of the first 100Mb 
>>> of the eMMC partition.. Such that i can use it to update the 
>>> version.sh script, to detect this bad version... 
>>>
>>> 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/d8785b07-088a-41de-81eb-159ddf7dec5e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Re: Trouble enabling pru-rproc uBoot overlay

[Hugh Frater]

Robert, is it ok to use this image in production or should I use the 
current stretch IOT image and flash the eMMC to overwrite this old 
bootloader?

On Saturday, 25 May 2019 20:55:58 UTC+1, RobertCNelson wrote:
>
> > This is what I think is relevant from my uBoot console: 
> > 
> > U-Boot SPL 2017.03-2-gd12b1519b4 (Mar 14 2017 - 10:28:26) 
> > Trying to boot from MMC2 
> > U-Boot 2017.03-2-gd12b1519b4 (Mar 14 2017 - 10:28:26 -0500), Build: 
> jenkins- 
> > github_Bootloader-Builder-532 
>
> There you go!! Would you please give me a dd copy of the first 100Mb 
> of the eMMC partition.. Such that i can use it to update the 
> version.sh script, to detect this bad version... 
>
> 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/1790a173-01bf-4ac7-871b-da6ffd19c3e4%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Trouble enabling pru-rproc uBoot overlay

[Hugh Frater]

You should run the flasher with a serial console connected to the debug 
header, that way you can monitor exactly what is going on. My attempts at 
flashing the latest image Robert posted was successful.

On Friday, 24 May 2019 21:28:29 UTC+1, jonre...@gmail.com wrote:
>
> I had the same issue on my BBBW:
>
> > ls /sys/class/remoteproc/
> remoteproc0
>
> I flashed the new image to an SD, then booted from SD. From there I 
> checked:
>
> > ls /sys/class/remoteproc/
> remoteproc0  remoteproc1  remoteproc2
>
> Next I removed the line from /boot/uEnv.txt so that the new image would 
> flash to BBBW and rebooted. As expected the lights cycle while flashing. 
> However, when I rebooted without SD card BBBW is bricked with all LEDs on.
>
> Any idea what's going on?
>
>
> On Thursday, May 23, 2019 at 9:56:39 AM UTC-7, RobertCNelson wrote:
>>
>> On Thu, May 23, 2019 at 3:39 AM Hugh Frater  wrote: 
>> > 
>> > OK, back in the office 
>> > 
>> > I've tried updating the bootloader, that didn't make a difference. Here 
>> is the output from version.sh 
>> > 
>> > debian@beaglebone:~$ sudo /opt/scripts/tools/version.sh 
>> > [sudo] password for debian: 
>> > git:/opt/scripts/:[c2a5ae96746d10d711c60bc84ba244f4cd7b75c3] 
>> > eeprom:[A335BNLT00C03816BBBK190D] 
>> > model:[TI_AM335x_BeagleBone_Black] 
>> > dogtag:[BeagleBoard.org Debian Image 2018-10-07] 
>> > bootloader:[microSD-(push-button)]:[/dev/mmcblk0]:[U-Boot 
>> 2019.04-2-g9ca2c5819f]:[location: dd MBR] 
>> > kernel:[4.14.108-ti-r104] 
>> > nodejs:[v6.14.4] 
>> > uboot_overlay_options:[enable_uboot_overlays=1] 
>> > uboot_overlay_options:[disable_uboot_overlay_emmc=1] 
>> > uboot_overlay_options:[disable_uboot_overlay_video=1] 
>> > uboot_overlay_options:[disable_uboot_overlay_audio=1] 
>> > uboot_overlay_options:[disable_uboot_overlay_wireless=1] 
>> > uboot_overlay_options:[disable_uboot_overlay_adc=1] 
>> > 
>> uboot_overlay_options:[uboot_overlay_pru=/lib/firmware/AM335X-PRU-RPROC-4-14-TI-00A0.dtbo]
>>  
>>
>> > uboot_overlay_options:[enable_uboot_cape_universal=1] 
>> > pkg check: to individually upgrade run: [sudo apt install 
>> --only-upgrade ] 
>> > pkg:[bb-cape-overlays]:[4.4.20190429.0-0rcnee0~stretch+20190429] 
>> > pkg:[bb-wl18xx-firmware]:[1.20180517-0rcnee0~stretch+20180517] 
>> > pkg:[kmod]:[23-2rcnee1~stretch+20171005] 
>> > pkg:[librobotcontrol]:[1.0.3-git20181005.0-0rcnee0~stretch+20181005] 
>> > pkg:[firmware-ti-connectivity]:[20170823-1rcnee1~stretch+20180328] 
>> > groups:[debian : debian adm kmem dialout cdrom floppy audio dip video 
>> plugdev users systemd-journal i2c bluetooth netdev cloud9ide gpio pwm eqep 
>> admin spi tisdk we 
>> > ston-launch xenomai] 
>> > cmdline:[console=ttyO0,115200n8 bone_capemgr.uboot_capemgr_enabled=1 
>> root=/dev/mmcblk0p1 ro rootfstype=ext4 rootwait coherent_pool=1M 
>> net.ifnames=0 quiet] 
>> > dmesg | grep remote 
>> > [1.302439] remoteproc remoteproc0: wkup_m3 is available 
>> > [1.390494] remoteproc remoteproc0: powering up wkup_m3 
>> > [1.390611] remoteproc remoteproc0: Booting fw image 
>> am335x-pm-firmware.elf, size 217168 
>> > [1.393154] remoteproc remoteproc0: remote processor wkup_m3 is now 
>> up 
>> > dmesg | grep pru 
>> > dmesg | grep pinctrl-single 
>> > [0.971836] pinctrl-single 44e10800.pinmux: 142 pins at pa f9e10800 
>> size 568 
>> > dmesg | grep gpio-of-helper 
>> > [0.983805] gpio-of-helper ocp:cape-universal: ready 
>> > lsusb 
>> > Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub 
>> > END 
>> > 
>> > I'm booting from a micro-sd card and the device is an element 
>> 14/farnell BBB 
>>
>> With a spare microSD, can you test this image: 
>>
>>
>> https://rcn-ee.net/rootfs/bb.org/testing/2019-05-12/stretch-iot/bone-debian-9.9-iot-armhf-2019-05-12-4gb.img.xz
>>  
>>
>> 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/db5d9c50-2e50-476b-93c7-d0f6f06867a8%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Re: Trouble enabling pru-rproc uBoot overlay

[Hugh Frater]

Damn... accidentally overwritten uBoot on the eMMC... I thought the flasher 
wouldn't touch that. Apologies Robert.

However, it was obviously a uBoot on eMMC problem as with a freshly flashed 
eMMC the overlay loads properly. I'll try booting from SD card now and see 
if that works too,. In our application we use a bunch of the eMMC pins for 
other hardware so we're forced to use an SD card.

On Saturday, 25 May 2019 21:39:23 UTC+1, Hugh Frater wrote:
>
> I will get that sorted and put it on my dropbox. I've got to flash eMMC 
> with the sd card contents then reboot with another sd card in the USB-A 
> port - I'm working from home and don't have any cables other than a 232r on 
> the debug header and a 5v power brick.
>
> Give me half an hour...
>
> On Saturday, 25 May 2019 20:55:58 UTC+1, RobertCNelson wrote:
>>
>> > This is what I think is relevant from my uBoot console: 
>> > 
>> > U-Boot SPL 2017.03-2-gd12b1519b4 (Mar 14 2017 - 10:28:26) 
>> > Trying to boot from MMC2 
>> > U-Boot 2017.03-2-gd12b1519b4 (Mar 14 2017 - 10:28:26 -0500), Build: 
>> jenkins- 
>> > github_Bootloader-Builder-532 
>>
>> There you go!! Would you please give me a dd copy of the first 100Mb 
>> of the eMMC partition.. Such that i can use it to update the 
>> version.sh script, to detect this bad version... 
>>
>> 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/0a8d4ce6-c7e6-4375-8e14-6eb0adff1658%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Re: Trouble enabling pru-rproc uBoot overlay

[Hugh Frater]

I will get that sorted and put it on my dropbox. I've got to flash eMMC 
with the sd card contents then reboot with another sd card in the USB-A 
port - I'm working from home and don't have any cables other than a 232r on 
the debug header and a 5v power brick.

Give me half an hour...

On Saturday, 25 May 2019 20:55:58 UTC+1, RobertCNelson wrote:
>
> > This is what I think is relevant from my uBoot console: 
> > 
> > U-Boot SPL 2017.03-2-gd12b1519b4 (Mar 14 2017 - 10:28:26) 
> > Trying to boot from MMC2 
> > U-Boot 2017.03-2-gd12b1519b4 (Mar 14 2017 - 10:28:26 -0500), Build: 
> jenkins- 
> > github_Bootloader-Builder-532 
>
> There you go!! Would you please give me a dd copy of the first 100Mb 
> of the eMMC partition.. Such that i can use it to update the 
> version.sh script, to detect this bad version... 
>
> 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/57799b04-591c-41b9-ae46-4950798af29e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Re: Trouble enabling pru-rproc uBoot overlay

[Hugh Frater]

n 56 (gpio 56) value is 1  
 
Running uname_boot ...  

loading /boot/vmlinuz-4.14.108-ti-r104 ...  

9925120 bytes read in 653 ms (14.5 MiB/s)  
 
uboot_overlays: [uboot_base_dtb=am335x-boneblack-uboot.dtb] ...
 
uboot_overlays: Switching too: dtb=am335x-boneblack-uboot.dtb ...  
 
loading /boot/dtbs/4.14.108-ti-r104/am335x-boneblack-uboot.dtb ...  

58048 bytes read in 139 ms (407.2 KiB/s)

uboot_overlays: [fdt_buffer=0x6] ...

uboot_overlays: loading /lib/firmware/AM335X-20-00A0.dtbo ...  
 
378 bytes read in 86 ms (3.9 KiB/s)
 
uboot_overlays: uboot loading of [/lib/firmware/BB-BONE-eMMC1-01-00A0.dtbo] 
disa
bled by /boot/uEnv.txt [disable_uboot_overlay_emmc=1]...

uboot_overlays: uboot loading of [/lib/firmware/BB-HDMI-TDA998x-00A0.dtbo] 
disab
led by /boot/uEnv.txt [disable_uboot_overlay_video=1]...

uboot_overlays: loading /lib/firmware/univ-bbb-xxx-00A0.dtbo ...

118834 bytes read in 388 ms (298.8 KiB/s)  
 
loading /boot/initrd.img-4.14.108-ti-r104 ...  
 
4424559 bytes read in 306 ms (13.8 MiB/s)  
 
debug: [console=ttyO0,115200n8 bone_capemgr.uboot_capemgr_enabled=1 
root=/dev/mm
cblk0p1 ro rootfstype=ext4 rootwait coherent_pool=1M net.ifnames=0 quiet 
cape_un
iversal=enable] ...
 
debug: [bootz 0x8200 0x8808:43836f 8800] ...  



On Wednesday, 22 May 2019 13:42:57 UTC+1, Hugh Frater wrote:
>
> This thread is a followup to my post over in the PRU section. Tl;Dr - 
> latest stretch IOT image using 4.14.108-ti-r104 wouldn't enable the PRUs 
> when I un-commented:
>
> ###pru_rproc (4.14.x-ti kernel)
> #uboot_overlay_pru=/lib/firmware/AM335X-PRU-RPROC-4-14-TI-00A0.dtbo
>
> I attached a serial debug header and have managed to get the PRU overlays 
> to load correctly and configure the PRUs by fudging uEnv.txt thus:
>
> ###Overide capes with eeprom
> uboot_overlay_addr0=/lib/firmware/AM335X-PRU-RPROC-4-14-TI-00A0.dtbo
>
> However, this gives rise to the following problem:
>
> uboot_overlays: cape universal disabled, external cape enabled or 
> detected...
>
> And I really need to use cape-universal. So, my questions:
>
> 1. How come the uBoot overlay for the PRU-RPROC support doesn't work?
>
> 2. How can I get uBoot to load the PRU-RPROC overlay and the overlay for 
> cape-universal?
>
> Cheers all...
>
>
>
>
>
>

-- 
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/e7991e4a-85a6-4ef4-9e71-c821ad5e9910%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Trouble enabling pru-rproc uBoot overlay

[Hugh Frater]

I'm not sure, sounds like the flashing of eMMC wasn't successful. I have a new 
SD card writer so I will try this image this evening and report my findings...

-- 
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/e4262a61-7ca3-49c0-ae2d-976df94d2313%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Re: remoteproc not detecting PRUs under 4.14, am I missing something?

[Hugh Frater]

I think it is related to uboot overlays. I started a new thread over in the 
uBoot section... You might like to take a look over there, Robert has posted an 
image for me to try but perhaps you can test it for me? I'm currently 
sd-card-writer-less...

-- 
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/4f0c5899-595c-4a98-a310-c13b7f35838e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Trouble enabling pru-rproc uBoot overlay

[Hugh Frater]

I will try this and report back Robert. I need to get hold of another sd 
card adapter tomorrow, the card reader in my laptop has decided to stop 
mounting cards rw... :(

On Thursday, 23 May 2019 17:56:39 UTC+1, RobertCNelson wrote:
>
> On Thu, May 23, 2019 at 3:39 AM Hugh Frater  > wrote: 
> > 
> > OK, back in the office 
> > 
> > I've tried updating the bootloader, that didn't make a difference. Here 
> is the output from version.sh 
> > 
> > debian@beaglebone:~$ sudo /opt/scripts/tools/version.sh 
> > [sudo] password for debian: 
> > git:/opt/scripts/:[c2a5ae96746d10d711c60bc84ba244f4cd7b75c3] 
> > eeprom:[A335BNLT00C03816BBBK190D] 
> > model:[TI_AM335x_BeagleBone_Black] 
> > dogtag:[BeagleBoard.org Debian Image 2018-10-07] 
> > bootloader:[microSD-(push-button)]:[/dev/mmcblk0]:[U-Boot 
> 2019.04-2-g9ca2c5819f]:[location: dd MBR] 
> > kernel:[4.14.108-ti-r104] 
> > nodejs:[v6.14.4] 
> > uboot_overlay_options:[enable_uboot_overlays=1] 
> > uboot_overlay_options:[disable_uboot_overlay_emmc=1] 
> > uboot_overlay_options:[disable_uboot_overlay_video=1] 
> > uboot_overlay_options:[disable_uboot_overlay_audio=1] 
> > uboot_overlay_options:[disable_uboot_overlay_wireless=1] 
> > uboot_overlay_options:[disable_uboot_overlay_adc=1] 
> > 
> uboot_overlay_options:[uboot_overlay_pru=/lib/firmware/AM335X-PRU-RPROC-4-14-TI-00A0.dtbo]
>  
>
> > uboot_overlay_options:[enable_uboot_cape_universal=1] 
> > pkg check: to individually upgrade run: [sudo apt install --only-upgrade 
> ] 
> > pkg:[bb-cape-overlays]:[4.4.20190429.0-0rcnee0~stretch+20190429] 
> > pkg:[bb-wl18xx-firmware]:[1.20180517-0rcnee0~stretch+20180517] 
> > pkg:[kmod]:[23-2rcnee1~stretch+20171005] 
> > pkg:[librobotcontrol]:[1.0.3-git20181005.0-0rcnee0~stretch+20181005] 
> > pkg:[firmware-ti-connectivity]:[20170823-1rcnee1~stretch+20180328] 
> > groups:[debian : debian adm kmem dialout cdrom floppy audio dip video 
> plugdev users systemd-journal i2c bluetooth netdev cloud9ide gpio pwm eqep 
> admin spi tisdk we 
> > ston-launch xenomai] 
> > cmdline:[console=ttyO0,115200n8 bone_capemgr.uboot_capemgr_enabled=1 
> root=/dev/mmcblk0p1 ro rootfstype=ext4 rootwait coherent_pool=1M 
> net.ifnames=0 quiet] 
> > dmesg | grep remote 
> > [1.302439] remoteproc remoteproc0: wkup_m3 is available 
> > [1.390494] remoteproc remoteproc0: powering up wkup_m3 
> > [1.390611] remoteproc remoteproc0: Booting fw image 
> am335x-pm-firmware.elf, size 217168 
> > [1.393154] remoteproc remoteproc0: remote processor wkup_m3 is now 
> up 
> > dmesg | grep pru 
> > dmesg | grep pinctrl-single 
> > [0.971836] pinctrl-single 44e10800.pinmux: 142 pins at pa f9e10800 
> size 568 
> > dmesg | grep gpio-of-helper 
> > [0.983805] gpio-of-helper ocp:cape-universal: ready 
> > lsusb 
> > Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub 
> > END 
> > 
> > I'm booting from a micro-sd card and the device is an element 14/farnell 
> BBB 
>
> With a spare microSD, can you test this image: 
>
>
> https://rcn-ee.net/rootfs/bb.org/testing/2019-05-12/stretch-iot/bone-debian-9.9-iot-armhf-2019-05-12-4gb.img.xz
>  
>
> 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/a76c12a7-5646-4ebc-98bb-1d5d36c77e4a%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Trouble enabling pru-rproc uBoot overlay

[Hugh Frater]

OK, back in the office

I've tried updating the bootloader, that didn't make a difference. Here is 
the output from version.sh

debian@beaglebone:~$ sudo /opt/scripts/tools/version.sh 
[sudo] password for debian: 
git:/opt/scripts/:[c2a5ae96746d10d711c60bc84ba244f4cd7b75c3]
eeprom:[A335BNLT00C03816BBBK190D]
model:[TI_AM335x_BeagleBone_Black]
dogtag:[BeagleBoard.org Debian Image 2018-10-07]
bootloader:[microSD-(push-button)]:[/dev/mmcblk0]:[U-Boot 
2019.04-2-g9ca2c5819f]:[location: dd MBR]
kernel:[4.14.108-ti-r104]
nodejs:[v6.14.4]
uboot_overlay_options:[enable_uboot_overlays=1]
uboot_overlay_options:[disable_uboot_overlay_emmc=1]
uboot_overlay_options:[disable_uboot_overlay_video=1]
uboot_overlay_options:[disable_uboot_overlay_audio=1]
uboot_overlay_options:[disable_uboot_overlay_wireless=1]
uboot_overlay_options:[disable_uboot_overlay_adc=1]
uboot_overlay_options:[uboot_overlay_pru=/lib/firmware/AM335X-PRU-RPROC-4-14-TI-00A0.dtbo]
uboot_overlay_options:[enable_uboot_cape_universal=1]
pkg check: to individually upgrade run: [sudo apt install --only-upgrade 
]
pkg:[bb-cape-overlays]:[4.4.20190429.0-0rcnee0~stretch+20190429]
pkg:[bb-wl18xx-firmware]:[1.20180517-0rcnee0~stretch+20180517]
pkg:[kmod]:[23-2rcnee1~stretch+20171005]
pkg:[librobotcontrol]:[1.0.3-git20181005.0-0rcnee0~stretch+20181005]
pkg:[firmware-ti-connectivity]:[20170823-1rcnee1~stretch+20180328]
groups:[debian : debian adm kmem dialout cdrom floppy audio dip video 
plugdev users systemd-journal i2c bluetooth netdev cloud9ide gpio pwm eqep 
admin spi tisdk we
ston-launch xenomai]
cmdline:[console=ttyO0,115200n8 bone_capemgr.uboot_capemgr_enabled=1 
root=/dev/mmcblk0p1 ro rootfstype=ext4 rootwait coherent_pool=1M 
net.ifnames=0 quiet]
dmesg | grep remote
[1.302439] remoteproc remoteproc0: wkup_m3 is available
[1.390494] remoteproc remoteproc0: powering up wkup_m3
[1.390611] remoteproc remoteproc0: Booting fw image 
am335x-pm-firmware.elf, size 217168
[1.393154] remoteproc remoteproc0: remote processor wkup_m3 is now up
dmesg | grep pru
dmesg | grep pinctrl-single
[0.971836] pinctrl-single 44e10800.pinmux: 142 pins at pa f9e10800 size 
568
dmesg | grep gpio-of-helper
[0.983805] gpio-of-helper ocp:cape-universal: ready
lsusb
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
END

I'm booting from a micro-sd card and the device is an element 14/farnell BBB

On Wednesday, 22 May 2019 19:13:57 UTC+1, Hugh Frater wrote:
>
> Interesting that it works for you... Might be something to do with our 
> 50Hz wall power :p
>
> I'll get back on this when I'm in work tomorrow and I'll try updating the 
> bootloader and get you a fresh output from version.sh
>

-- 
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/98987c3d-425a-4902-b3ba-cfd9d3822ce0%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Trouble enabling pru-rproc uBoot overlay

[Hugh Frater]

Interesting that it works for you... Might be something to do with our 50Hz 
wall power :p

I'll get back on this when I'm in work tomorrow and I'll try updating the 
bootloader and get you a fresh output from version.sh

-- 
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/f4f19048-d28c-48a9-aff1-be0cbc326aaf%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Trouble enabling pru-rproc uBoot overlay

[Hugh Frater]

Hi Robert, I'm no longer in front of the hardware for today but you can see the 
output of version.sh on my thread over in the PRU section. You can also see I 
tried zero-ing out the mmc in case that had a version of uboot that didn't 
support overlays. Didn't make a difference.

-- 
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/f02845e9-f219-499f-bba1-2fa75356a3c2%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Trouble enabling pru-rproc uBoot overlay

[Hugh Frater]

This thread is a followup to my post over in the PRU section. Tl;Dr - 
latest stretch IOT image using 4.14.108-ti-r104 wouldn't enable the PRUs 
when I un-commented:

###pru_rproc (4.14.x-ti kernel)
#uboot_overlay_pru=/lib/firmware/AM335X-PRU-RPROC-4-14-TI-00A0.dtbo

I attached a serial debug header and have managed to get the PRU overlays 
to load correctly and configure the PRUs by fudging uEnv.txt thus:

###Overide capes with eeprom
uboot_overlay_addr0=/lib/firmware/AM335X-PRU-RPROC-4-14-TI-00A0.dtbo

However, this gives rise to the following problem:

uboot_overlays: cape universal disabled, external cape enabled or 
detected...

And I really need to use cape-universal. So, my questions:

1. How come the uBoot overlay for the PRU-RPROC support doesn't work?

2. How can I get uBoot to load the PRU-RPROC overlay and the overlay for 
cape-universal?

Cheers all...





-- 
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/bf204599-1d40-4e7f-9267-b3e564e3ce84%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Re: remoteproc not detecting PRUs under 4.14, am I missing something?

[Hugh Frater]

Our application is node.js for the easy stuff with all the heavy lifting 
done in the PRU... if you want to code in C, it's worth looking at the MRAA 
libraries from Intel https://github.com/intel-iot-devkit/mraa

On Friday, 17 May 2019 14:20:34 UTC+1, Walter Cromer wrote:
>
> I plan to write the code in C since I'm most familiar with it (although 
> very rusty, but it's coming back) and I have considered learning Python and 
> using it.
>
> By the way, thanks to all for your patience with me on this!  It has been 
> a long time since I worked in this space and a lot has changed and improved!
>
> On Friday, May 17, 2019 at 9:17:24 AM UTC-4, Hugh Frater wrote:
>>
>> If you can live with using the universal-cape and just configuring the 
>> pins once booted using the config-pin utility, that's a good way to go. 
>> What programming language are you wanting to use to write your temperature 
>> sensor software? If you are doing it from the PRU then you can just code up 
>> your own i2c read function and access the registers directly though the 
>> memory map, just like any standard MCU. 
>>
>> On Thursday, 16 May 2019 20:34:58 UTC+1, Walter Cromer wrote:
>>>
>>> Hugh - I'll dig around in the UBoot section.  Thanks for suggesting 
>>> that.  I'm such a newbie on here!
>>>
>>> As for how I compiled the custom device tree overlay, I followed the 
>>> instructions posted at this location and it worked fine - no errors after I 
>>> corrected the typos, etc. that were posted in the comments.
>>>
>>>
>>> http://www.bonebrews.com/temperature-monitoring-with-the-ds18b20-on-a-beaglebone-black/
>>>
>>> I'd really like to get this temperature sensor working but all the 
>>> instructions are pre-Uboot.   I can make a lot of progress with my 
>>> prototype once I get this working but liquid temperature is a critical 
>>> input so without it I can't move forward!
>>>
>>>
>>>
>>> On Thursday, May 16, 2019 at 5:53:38 AM UTC-4, Hugh Frater wrote:
>>>>
>>>> Hi Walter, I'm afraid I can't help with your custom device overlay 
>>>> issue, it us really a topic for a new thread in the uBoot section I would 
>>>> have thought?
>>>>
>>>> I would be interested in hearing how you compiled a custom device tree 
>>>> overlay though. We have our BBB on a custom card that uses a bunch of 
>>>> gpio, 
>>>> an eqep module, a bunch of uarts and some pru_ecap pwm - it's a lot of 
>>>> work 
>>>> for config-pin to setup at boot time and I'd like to trim this 13 seconds 
>>>> of work out of my bootup if possible. Perhaps you could make a post in the 
>>>> uBoot section?
>>>>
>>>> Hugh
>>>>
>>>> On Thursday, 16 May 2019 01:27:36 UTC+1, Walter Cromer wrote:
>>>>>
>>>>> Hugh - I'm a real newbie.  I compiled a device tree overlay with not 
>>>>> errors and have a dtbo file now.  I just don't know how to get it into 
>>>>> the 
>>>>> boot process.  Where do I put it, do I need to change a file like env.txt 
>>>>> somewhere to get it to load and if so what syntax do i use?  Where did 
>>>>> you 
>>>>> find these instructions?  I'm so lost and need to keep moving forward.  
>>>>> it 
>>>>> was going so well...
>>>>>
>>>>> I'm on 4.4.14 
>>>>>
>>>>> On Thursday, May 9, 2019 at 7:31:27 AM UTC-4, Hugh Frater wrote:
>>>>>>
>>>>>> I have the same problem as this user: 
>>>>>> https://groups.google.com/forum/#!category-topic/beagleboard/pru/g2NcW2sUX-4
>>>>>>  
>>>>>> in that remoteproc only detects the wkup_m3 coprocessor (whatever that 
>>>>>> is) 
>>>>>> and doesn't seem to detect the PRUs on boot.
>>>>>>
>>>>>> This is a fresh install of Sretch IOT from beagleboard.org, with the 
>>>>>> kernel and cape-overlays updated through the tools/scripts...
>>>>>>
>>>>>> version.sh shows:
>>>>>>
>>>>>> git:/opt/scripts/:[c2a5ae96746d10d711c60bc84ba244f4cd7b75c3]
>>>>>> eeprom:[A335BNLT00C03816BBBK190D]
>>>>>> model:[TI_AM335x_BeagleBone_Black]
>>>>>> dogtag:[BeagleBoard.org Debian Image 2018-10-07]
>>>>>> bootloader:[microSD-(push-button)]:[/dev/mmcblk0]:[U-Boot 
>>>>>> 

[beagleboard] Re: remoteproc not detecting PRUs under 4.14, am I missing something?

[Hugh Frater]

If you can live with using the universal-cape and just configuring the pins 
once booted using the config-pin utility, that's a good way to go. What 
programming language are you wanting to use to write your temperature 
sensor software? If you are doing it from the PRU then you can just code up 
your own i2c read function and access the registers directly though the 
memory map, just like any standard MCU. 

On Thursday, 16 May 2019 20:34:58 UTC+1, Walter Cromer wrote:
>
> Hugh - I'll dig around in the UBoot section.  Thanks for suggesting that.  
> I'm such a newbie on here!
>
> As for how I compiled the custom device tree overlay, I followed the 
> instructions posted at this location and it worked fine - no errors after I 
> corrected the typos, etc. that were posted in the comments.
>
>
> http://www.bonebrews.com/temperature-monitoring-with-the-ds18b20-on-a-beaglebone-black/
>
> I'd really like to get this temperature sensor working but all the 
> instructions are pre-Uboot.   I can make a lot of progress with my 
> prototype once I get this working but liquid temperature is a critical 
> input so without it I can't move forward!
>
>
>
> On Thursday, May 16, 2019 at 5:53:38 AM UTC-4, Hugh Frater wrote:
>>
>> Hi Walter, I'm afraid I can't help with your custom device overlay issue, 
>> it us really a topic for a new thread in the uBoot section I would have 
>> thought?
>>
>> I would be interested in hearing how you compiled a custom device tree 
>> overlay though. We have our BBB on a custom card that uses a bunch of gpio, 
>> an eqep module, a bunch of uarts and some pru_ecap pwm - it's a lot of work 
>> for config-pin to setup at boot time and I'd like to trim this 13 seconds 
>> of work out of my bootup if possible. Perhaps you could make a post in the 
>> uBoot section?
>>
>> Hugh
>>
>> On Thursday, 16 May 2019 01:27:36 UTC+1, Walter Cromer wrote:
>>>
>>> Hugh - I'm a real newbie.  I compiled a device tree overlay with not 
>>> errors and have a dtbo file now.  I just don't know how to get it into the 
>>> boot process.  Where do I put it, do I need to change a file like env.txt 
>>> somewhere to get it to load and if so what syntax do i use?  Where did you 
>>> find these instructions?  I'm so lost and need to keep moving forward.  it 
>>> was going so well...
>>>
>>> I'm on 4.4.14 
>>>
>>> On Thursday, May 9, 2019 at 7:31:27 AM UTC-4, Hugh Frater wrote:
>>>>
>>>> I have the same problem as this user: 
>>>> https://groups.google.com/forum/#!category-topic/beagleboard/pru/g2NcW2sUX-4
>>>>  
>>>> in that remoteproc only detects the wkup_m3 coprocessor (whatever that is) 
>>>> and doesn't seem to detect the PRUs on boot.
>>>>
>>>> This is a fresh install of Sretch IOT from beagleboard.org, with the 
>>>> kernel and cape-overlays updated through the tools/scripts...
>>>>
>>>> version.sh shows:
>>>>
>>>> git:/opt/scripts/:[c2a5ae96746d10d711c60bc84ba244f4cd7b75c3]
>>>> eeprom:[A335BNLT00C03816BBBK190D]
>>>> model:[TI_AM335x_BeagleBone_Black]
>>>> dogtag:[BeagleBoard.org Debian Image 2018-10-07]
>>>> bootloader:[microSD-(push-button)]:[/dev/mmcblk0]:[U-Boot 
>>>> 2018.09-2-g0b54a51eee]:[location: dd MBR]
>>>> kernel:[4.14.108-ti-r104]
>>>> nodejs:[v6.14.4]
>>>> uboot_overlay_options:[enable_uboot_overlays=1]
>>>> uboot_overlay_options:[disable_uboot_overlay_emmc=1]
>>>> uboot_overlay_options:[disable_uboot_overlay_video=1]
>>>> uboot_overlay_options:[disable_uboot_overlay_audio=1]
>>>> uboot_overlay_options:[disable_uboot_overlay_wireless=1]
>>>> uboot_overlay_options:[disable_uboot_overlay_adc=1]
>>>>
>>>> uboot_overlay_options:[uboot_overlay_pru=/lib/firmware/AM335X-PRU-RPROC-4-14-TI-00A0.dtbo]
>>>> uboot_overlay_options:[enable_uboot_cape_universal=1]
>>>> pkg check: to individually upgrade run: [sudo apt install 
>>>> --only-upgrade ]
>>>> pkg:[bb-cape-overlays]:[4.4.20190429.0-0rcnee0~stretch+20190429]
>>>> pkg:[bb-wl18xx-firmware]:[1.20180517-0rcnee0~stretch+20180517]
>>>> pkg:[kmod]:[23-2rcnee1~stretch+20171005]
>>>> pkg:[librobotcontrol]:[1.0.3-git20181005.0-0rcnee0~stretch+20181005]
>>>> pkg:[firmware-ti-connectivity]:[20170823-1rcnee1~stretch+20180328]
>>>> groups:[debian : debian adm kmem dialout cdrom floppy audio dip video 
>>>> plugdev users systemd-journal i2c bluetooth netdev cloud9ide g

[beagleboard] Re: remoteproc not detecting PRUs under 4.14, am I missing something?

[Hugh Frater]

An update - tried switching my 8.9/4.4.54-ti-r93 setup (that we have 
working with kernel overlays) over to uBoot overlays - all good...

[   37.211677]  remoteproc1: powering up 4a338000.pru1
[   37.212435]  remoteproc1: Booting fw image am335x-pru1-fw, size 129436
[   37.240836] ti-pruss 4a30.pruss: configured system_events = 
0x000c intr_channels = 0x000a host_intr = 0x000a
[   37.246313]  remoteproc1: remote processor 4a338000.pru1 is now up
[   37.261296] virtio_rpmsg_bus virtio0: rpmsg host is online
[   37.261377] virtio_rpmsg_bus virtio0: creating channel rpmsg-pru addr 
0x1f
[   38.227474] rpmsg_pru rpmsg0: new rpmsg_pru device: /dev/rpmsg_pru31

No idea why the PRUSS driver doesn't power up the PRU under 
Stretch/4.14.whatver

Now to see if I can get overlayroot working on 8.9/4.4 and sort out the 
read-only filesystem




On Thursday, 9 May 2019 12:31:27 UTC+1, Hugh Frater wrote:
>
> I have the same problem as this user: 
> https://groups.google.com/forum/#!category-topic/beagleboard/pru/g2NcW2sUX-4 
> in that remoteproc only detects the wkup_m3 coprocessor (whatever that is) 
> and doesn't seem to detect the PRUs on boot.
>
> This is a fresh install of Sretch IOT from beagleboard.org, with the 
> kernel and cape-overlays updated through the tools/scripts...
>
> version.sh shows:
>
> git:/opt/scripts/:[c2a5ae96746d10d711c60bc84ba244f4cd7b75c3]
> eeprom:[A335BNLT00C03816BBBK190D]
> model:[TI_AM335x_BeagleBone_Black]
> dogtag:[BeagleBoard.org Debian Image 2018-10-07]
> bootloader:[microSD-(push-button)]:[/dev/mmcblk0]:[U-Boot 
> 2018.09-2-g0b54a51eee]:[location: dd MBR]
> kernel:[4.14.108-ti-r104]
> nodejs:[v6.14.4]
> uboot_overlay_options:[enable_uboot_overlays=1]
> uboot_overlay_options:[disable_uboot_overlay_emmc=1]
> uboot_overlay_options:[disable_uboot_overlay_video=1]
> uboot_overlay_options:[disable_uboot_overlay_audio=1]
> uboot_overlay_options:[disable_uboot_overlay_wireless=1]
> uboot_overlay_options:[disable_uboot_overlay_adc=1]
>
> uboot_overlay_options:[uboot_overlay_pru=/lib/firmware/AM335X-PRU-RPROC-4-14-TI-00A0.dtbo]
> uboot_overlay_options:[enable_uboot_cape_universal=1]
> pkg check: to individually upgrade run: [sudo apt install --only-upgrade 
> ]
> pkg:[bb-cape-overlays]:[4.4.20190429.0-0rcnee0~stretch+20190429]
> pkg:[bb-wl18xx-firmware]:[1.20180517-0rcnee0~stretch+20180517]
> pkg:[kmod]:[23-2rcnee1~stretch+20171005]
> pkg:[librobotcontrol]:[1.0.3-git20181005.0-0rcnee0~stretch+20181005]
> pkg:[firmware-ti-connectivity]:[20170823-1rcnee1~stretch+20180328]
> groups:[debian : debian adm kmem dialout cdrom floppy audio dip video 
> plugdev users systemd-journal i2c bluetooth netdev cloud9ide gpio pwm eqep 
> admin spi tisdk weston-launch xenomai]
> cmdline:[console=ttyO0,115200n8 bone_capemgr.uboot_capemgr_enabled=1 
> root=/dev/mmcblk0p1 ro rootfstype=ext4 rootwait coherent_pool=1M 
> net.ifnames=0 quiet]
> dmesg | grep remote
> [1.302485] remoteproc remoteproc0: wkup_m3 is available
> [1.389525] remoteproc remoteproc0: powering up wkup_m3
> [1.389661] remoteproc remoteproc0: Booting fw image 
> am335x-pm-firmware.elf, size 217168
> [1.393097] remoteproc remoteproc0: remote processor wkup_m3 is now up
> dmesg | grep pru
> dmesg | grep pinctrl-single
> [0.971911] pinctrl-single 44e10800.pinmux: 142 pins at pa f9e10800 
> size 568
> dmesg | grep gpio-of-helper
> [0.984114] gpio-of-helper ocp:cape-universal: ready
> lsusb
> Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
> END
>
> What am I doing wrong here? Surely PRU support is one of those things that 
> should be working out of the box with the correct u-boot overlay applied?
>
>
>
>
>
>

-- 
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/8dc31247-c629-4782-9b2a-f5802e696634%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Re: remoteproc not detecting PRUs under 4.14, am I missing something?

[Hugh Frater]

Hi Walter, I'm afraid I can't help with your custom device overlay issue, 
it us really a topic for a new thread in the uBoot section I would have 
thought?

I would be interested in hearing how you compiled a custom device tree 
overlay though. We have our BBB on a custom card that uses a bunch of gpio, 
an eqep module, a bunch of uarts and some pru_ecap pwm - it's a lot of work 
for config-pin to setup at boot time and I'd like to trim this 13 seconds 
of work out of my bootup if possible. Perhaps you could make a post in the 
uBoot section?

Hugh

On Thursday, 16 May 2019 01:27:36 UTC+1, Walter Cromer wrote:
>
> Hugh - I'm a real newbie.  I compiled a device tree overlay with not 
> errors and have a dtbo file now.  I just don't know how to get it into the 
> boot process.  Where do I put it, do I need to change a file like env.txt 
> somewhere to get it to load and if so what syntax do i use?  Where did you 
> find these instructions?  I'm so lost and need to keep moving forward.  it 
> was going so well...
>
> I'm on 4.4.14 
>
> On Thursday, May 9, 2019 at 7:31:27 AM UTC-4, Hugh Frater wrote:
>>
>> I have the same problem as this user: 
>> https://groups.google.com/forum/#!category-topic/beagleboard/pru/g2NcW2sUX-4 
>> in that remoteproc only detects the wkup_m3 coprocessor (whatever that is) 
>> and doesn't seem to detect the PRUs on boot.
>>
>> This is a fresh install of Sretch IOT from beagleboard.org, with the 
>> kernel and cape-overlays updated through the tools/scripts...
>>
>> version.sh shows:
>>
>> git:/opt/scripts/:[c2a5ae96746d10d711c60bc84ba244f4cd7b75c3]
>> eeprom:[A335BNLT00C03816BBBK190D]
>> model:[TI_AM335x_BeagleBone_Black]
>> dogtag:[BeagleBoard.org Debian Image 2018-10-07]
>> bootloader:[microSD-(push-button)]:[/dev/mmcblk0]:[U-Boot 
>> 2018.09-2-g0b54a51eee]:[location: dd MBR]
>> kernel:[4.14.108-ti-r104]
>> nodejs:[v6.14.4]
>> uboot_overlay_options:[enable_uboot_overlays=1]
>> uboot_overlay_options:[disable_uboot_overlay_emmc=1]
>> uboot_overlay_options:[disable_uboot_overlay_video=1]
>> uboot_overlay_options:[disable_uboot_overlay_audio=1]
>> uboot_overlay_options:[disable_uboot_overlay_wireless=1]
>> uboot_overlay_options:[disable_uboot_overlay_adc=1]
>>
>> uboot_overlay_options:[uboot_overlay_pru=/lib/firmware/AM335X-PRU-RPROC-4-14-TI-00A0.dtbo]
>> uboot_overlay_options:[enable_uboot_cape_universal=1]
>> pkg check: to individually upgrade run: [sudo apt install --only-upgrade 
>> ]
>> pkg:[bb-cape-overlays]:[4.4.20190429.0-0rcnee0~stretch+20190429]
>> pkg:[bb-wl18xx-firmware]:[1.20180517-0rcnee0~stretch+20180517]
>> pkg:[kmod]:[23-2rcnee1~stretch+20171005]
>> pkg:[librobotcontrol]:[1.0.3-git20181005.0-0rcnee0~stretch+20181005]
>> pkg:[firmware-ti-connectivity]:[20170823-1rcnee1~stretch+20180328]
>> groups:[debian : debian adm kmem dialout cdrom floppy audio dip video 
>> plugdev users systemd-journal i2c bluetooth netdev cloud9ide gpio pwm eqep 
>> admin spi tisdk weston-launch xenomai]
>> cmdline:[console=ttyO0,115200n8 bone_capemgr.uboot_capemgr_enabled=1 
>> root=/dev/mmcblk0p1 ro rootfstype=ext4 rootwait coherent_pool=1M 
>> net.ifnames=0 quiet]
>> dmesg | grep remote
>> [1.302485] remoteproc remoteproc0: wkup_m3 is available
>> [1.389525] remoteproc remoteproc0: powering up wkup_m3
>> [1.389661] remoteproc remoteproc0: Booting fw image 
>> am335x-pm-firmware.elf, size 217168
>> [1.393097] remoteproc remoteproc0: remote processor wkup_m3 is now up
>> dmesg | grep pru
>> dmesg | grep pinctrl-single
>> [0.971911] pinctrl-single 44e10800.pinmux: 142 pins at pa f9e10800 
>> size 568
>> dmesg | grep gpio-of-helper
>> [0.984114] gpio-of-helper ocp:cape-universal: ready
>> lsusb
>> Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
>> END
>>
>> What am I doing wrong here? Surely PRU support is one of those things 
>> that should be working out of the box with the correct u-boot overlay 
>> applied?
>>
>>
>>
>>
>>
>>

-- 
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/3fd45e85-c42a-421c-9060-c102f9ad130c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Re: remoteproc not detecting PRUs under 4.14, am I missing something?

[Hugh Frater]

Thought I would try zero-ing the eMMC boot partition, just in case there 
was a resident uBoot that was old and didn't support overlays no joy :(

On Thursday, 9 May 2019 12:31:27 UTC+1, Hugh Frater wrote:
>
> I have the same problem as this user: 
> https://groups.google.com/forum/#!category-topic/beagleboard/pru/g2NcW2sUX-4 
> in that remoteproc only detects the wkup_m3 coprocessor (whatever that is) 
> and doesn't seem to detect the PRUs on boot.
>
> This is a fresh install of Sretch IOT from beagleboard.org, with the 
> kernel and cape-overlays updated through the tools/scripts...
>
> version.sh shows:
>
> git:/opt/scripts/:[c2a5ae96746d10d711c60bc84ba244f4cd7b75c3]
> eeprom:[A335BNLT00C03816BBBK190D]
> model:[TI_AM335x_BeagleBone_Black]
> dogtag:[BeagleBoard.org Debian Image 2018-10-07]
> bootloader:[microSD-(push-button)]:[/dev/mmcblk0]:[U-Boot 
> 2018.09-2-g0b54a51eee]:[location: dd MBR]
> kernel:[4.14.108-ti-r104]
> nodejs:[v6.14.4]
> uboot_overlay_options:[enable_uboot_overlays=1]
> uboot_overlay_options:[disable_uboot_overlay_emmc=1]
> uboot_overlay_options:[disable_uboot_overlay_video=1]
> uboot_overlay_options:[disable_uboot_overlay_audio=1]
> uboot_overlay_options:[disable_uboot_overlay_wireless=1]
> uboot_overlay_options:[disable_uboot_overlay_adc=1]
>
> uboot_overlay_options:[uboot_overlay_pru=/lib/firmware/AM335X-PRU-RPROC-4-14-TI-00A0.dtbo]
> uboot_overlay_options:[enable_uboot_cape_universal=1]
> pkg check: to individually upgrade run: [sudo apt install --only-upgrade 
> ]
> pkg:[bb-cape-overlays]:[4.4.20190429.0-0rcnee0~stretch+20190429]
> pkg:[bb-wl18xx-firmware]:[1.20180517-0rcnee0~stretch+20180517]
> pkg:[kmod]:[23-2rcnee1~stretch+20171005]
> pkg:[librobotcontrol]:[1.0.3-git20181005.0-0rcnee0~stretch+20181005]
> pkg:[firmware-ti-connectivity]:[20170823-1rcnee1~stretch+20180328]
> groups:[debian : debian adm kmem dialout cdrom floppy audio dip video 
> plugdev users systemd-journal i2c bluetooth netdev cloud9ide gpio pwm eqep 
> admin spi tisdk weston-launch xenomai]
> cmdline:[console=ttyO0,115200n8 bone_capemgr.uboot_capemgr_enabled=1 
> root=/dev/mmcblk0p1 ro rootfstype=ext4 rootwait coherent_pool=1M 
> net.ifnames=0 quiet]
> dmesg | grep remote
> [1.302485] remoteproc remoteproc0: wkup_m3 is available
> [1.389525] remoteproc remoteproc0: powering up wkup_m3
> [1.389661] remoteproc remoteproc0: Booting fw image 
> am335x-pm-firmware.elf, size 217168
> [1.393097] remoteproc remoteproc0: remote processor wkup_m3 is now up
> dmesg | grep pru
> dmesg | grep pinctrl-single
> [0.971911] pinctrl-single 44e10800.pinmux: 142 pins at pa f9e10800 
> size 568
> dmesg | grep gpio-of-helper
> [0.984114] gpio-of-helper ocp:cape-universal: ready
> lsusb
> Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
> END
>
> What am I doing wrong here? Surely PRU support is one of those things that 
> should be working out of the box with the correct u-boot overlay applied?
>
>
>
>
>
>

-- 
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/aefa2eb3-d8ed-4f6d-ac76-8bada759e7d6%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Re: remoteproc not detecting PRUs under 4.14, am I missing something?

[Hugh Frater]

Anybody? I would really like to complete a migration to Stretch and 4.14 
due to the awesomeness of uBoot overlays and the pre-built overlay-root 
setup that is available from a setting in uEnv.txt, that's a big help for 
my project.

On Thursday, 9 May 2019 12:31:27 UTC+1, Hugh Frater wrote:
>
> I have the same problem as this user: 
> https://groups.google.com/forum/#!category-topic/beagleboard/pru/g2NcW2sUX-4 
> in that remoteproc only detects the wkup_m3 coprocessor (whatever that is) 
> and doesn't seem to detect the PRUs on boot.
>
> This is a fresh install of Sretch IOT from beagleboard.org, with the 
> kernel and cape-overlays updated through the tools/scripts...
>
> version.sh shows:
>
> git:/opt/scripts/:[c2a5ae96746d10d711c60bc84ba244f4cd7b75c3]
> eeprom:[A335BNLT00C03816BBBK190D]
> model:[TI_AM335x_BeagleBone_Black]
> dogtag:[BeagleBoard.org Debian Image 2018-10-07]
> bootloader:[microSD-(push-button)]:[/dev/mmcblk0]:[U-Boot 
> 2018.09-2-g0b54a51eee]:[location: dd MBR]
> kernel:[4.14.108-ti-r104]
> nodejs:[v6.14.4]
> uboot_overlay_options:[enable_uboot_overlays=1]
> uboot_overlay_options:[disable_uboot_overlay_emmc=1]
> uboot_overlay_options:[disable_uboot_overlay_video=1]
> uboot_overlay_options:[disable_uboot_overlay_audio=1]
> uboot_overlay_options:[disable_uboot_overlay_wireless=1]
> uboot_overlay_options:[disable_uboot_overlay_adc=1]
>
> uboot_overlay_options:[uboot_overlay_pru=/lib/firmware/AM335X-PRU-RPROC-4-14-TI-00A0.dtbo]
> uboot_overlay_options:[enable_uboot_cape_universal=1]
> pkg check: to individually upgrade run: [sudo apt install --only-upgrade 
> ]
> pkg:[bb-cape-overlays]:[4.4.20190429.0-0rcnee0~stretch+20190429]
> pkg:[bb-wl18xx-firmware]:[1.20180517-0rcnee0~stretch+20180517]
> pkg:[kmod]:[23-2rcnee1~stretch+20171005]
> pkg:[librobotcontrol]:[1.0.3-git20181005.0-0rcnee0~stretch+20181005]
> pkg:[firmware-ti-connectivity]:[20170823-1rcnee1~stretch+20180328]
> groups:[debian : debian adm kmem dialout cdrom floppy audio dip video 
> plugdev users systemd-journal i2c bluetooth netdev cloud9ide gpio pwm eqep 
> admin spi tisdk weston-launch xenomai]
> cmdline:[console=ttyO0,115200n8 bone_capemgr.uboot_capemgr_enabled=1 
> root=/dev/mmcblk0p1 ro rootfstype=ext4 rootwait coherent_pool=1M 
> net.ifnames=0 quiet]
> dmesg | grep remote
> [1.302485] remoteproc remoteproc0: wkup_m3 is available
> [1.389525] remoteproc remoteproc0: powering up wkup_m3
> [1.389661] remoteproc remoteproc0: Booting fw image 
> am335x-pm-firmware.elf, size 217168
> [1.393097] remoteproc remoteproc0: remote processor wkup_m3 is now up
> dmesg | grep pru
> dmesg | grep pinctrl-single
> [0.971911] pinctrl-single 44e10800.pinmux: 142 pins at pa f9e10800 
> size 568
> dmesg | grep gpio-of-helper
> [0.984114] gpio-of-helper ocp:cape-universal: ready
> lsusb
> Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
> END
>
> What am I doing wrong here? Surely PRU support is one of those things that 
> should be working out of the box with the correct u-boot overlay applied?
>
>
>
>
>
>

-- 
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/fa36ef72-080d-4066-a1b0-8779d06f7718%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] remoteproc not detecting PRUs under 4.14, am I missing something?

[Hugh Frater]

I have the same problem as this user: 
https://groups.google.com/forum/#!category-topic/beagleboard/pru/g2NcW2sUX-4 
in that remoteproc only detects the wkup_m3 coprocessor (whatever that is) 
and doesn't seem to detect the PRUs on boot.

This is a fresh install of Sretch IOT from beagleboard.org, with the kernel 
and cape-overlays updated through the tools/scripts...

version.sh shows:

git:/opt/scripts/:[c2a5ae96746d10d711c60bc84ba244f4cd7b75c3]
eeprom:[A335BNLT00C03816BBBK190D]
model:[TI_AM335x_BeagleBone_Black]
dogtag:[BeagleBoard.org Debian Image 2018-10-07]
bootloader:[microSD-(push-button)]:[/dev/mmcblk0]:[U-Boot 
2018.09-2-g0b54a51eee]:[location: dd MBR]
kernel:[4.14.108-ti-r104]
nodejs:[v6.14.4]
uboot_overlay_options:[enable_uboot_overlays=1]
uboot_overlay_options:[disable_uboot_overlay_emmc=1]
uboot_overlay_options:[disable_uboot_overlay_video=1]
uboot_overlay_options:[disable_uboot_overlay_audio=1]
uboot_overlay_options:[disable_uboot_overlay_wireless=1]
uboot_overlay_options:[disable_uboot_overlay_adc=1]
uboot_overlay_options:[uboot_overlay_pru=/lib/firmware/AM335X-PRU-RPROC-4-14-TI-00A0.dtbo]
uboot_overlay_options:[enable_uboot_cape_universal=1]
pkg check: to individually upgrade run: [sudo apt install --only-upgrade 
]
pkg:[bb-cape-overlays]:[4.4.20190429.0-0rcnee0~stretch+20190429]
pkg:[bb-wl18xx-firmware]:[1.20180517-0rcnee0~stretch+20180517]
pkg:[kmod]:[23-2rcnee1~stretch+20171005]
pkg:[librobotcontrol]:[1.0.3-git20181005.0-0rcnee0~stretch+20181005]
pkg:[firmware-ti-connectivity]:[20170823-1rcnee1~stretch+20180328]
groups:[debian : debian adm kmem dialout cdrom floppy audio dip video 
plugdev users systemd-journal i2c bluetooth netdev cloud9ide gpio pwm eqep 
admin spi tisdk weston-launch xenomai]
cmdline:[console=ttyO0,115200n8 bone_capemgr.uboot_capemgr_enabled=1 
root=/dev/mmcblk0p1 ro rootfstype=ext4 rootwait coherent_pool=1M 
net.ifnames=0 quiet]
dmesg | grep remote
[1.302485] remoteproc remoteproc0: wkup_m3 is available
[1.389525] remoteproc remoteproc0: powering up wkup_m3
[1.389661] remoteproc remoteproc0: Booting fw image 
am335x-pm-firmware.elf, size 217168
[1.393097] remoteproc remoteproc0: remote processor wkup_m3 is now up
dmesg | grep pru
dmesg | grep pinctrl-single
[0.971911] pinctrl-single 44e10800.pinmux: 142 pins at pa f9e10800 size 
568
dmesg | grep gpio-of-helper
[0.984114] gpio-of-helper ocp:cape-universal: ready
lsusb
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
END

What am I doing wrong here? Surely PRU support is one of those things that 
should be working out of the box with the correct u-boot overlay applied?





-- 
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/a71c3102-1ead-43cc-8553-464325a9557d%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Re: PRU remoteproc[12] not appearing under /sys/class/remoteproc/

[hugh . frater]

I have the exact same issue, except my output from version.sh indicates the 
board id eeprom is programmed correctly? Any other ideas Robert?... I'm 
playing around with migrating our device from 8.7 with 4.4 kernel up to 
something more recent and am coming up against this PRU issue...

On Wednesday, 10 April 2019 03:06:45 UTC+1, eth...@uw.edu wrote:
>
>
> I've just set up a new Debian 9.5 (kernel 14.4.71-ti-r80) image 
> 
>  
> and made the following changes to /boot/uEnv.txt:
>
> disable_uboot_overlay_video=1
> uboot_overlay_pru=/lib/firmware/AM335X-PRU-RPROC-4-14-TI-00A0.dtbo
>
> I've also disabled loading of the uio modules. (
> /etc/modprobe.d/pruss-blacklist.conf)
> blacklist uio
> blacklist uio_pdrv_genirq
>
> However, I don't see any evidence that the rproc module has loaded the PRU:
> "uio\|pru"
>
> Specifically, there is no module for the PRU in /sys/class/remoteproc/. 
> remoteproc0 appears, but this is for the M3 power management unit.
>
> Am I doing anything wrong? or is there an additional step to allow use of 
> the PRUs? What should I look at to debug this issue?
>

-- 
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/26fa-76fd-42f1-aae8-bf7dba75d049%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] I2C random read of off-board device from within PRU not working correctly

[Hugh Frater]

Got this working with a few code changes:

/*
 * read_wiper - returns the 2nd byte of a 2-byte read from the specified 
wiper
 * 'reg' contains the write command to read the required wiper
 */
uint8_t read_wiper(uint8_t reg)
{

uint8_t dataByte;

//initialise i2c2 device
init_i2c();

//set I2C2_CNT register to 1 for initial write command
I2C2_CNT = 1;

while (I2C2_STATUSRAW & 0x1000);
//poll 'busy bit' in I2C2_STATUSRAW register (bit 12) until it is 
zero
//set transmit mode
I2C2_CON = 0x8601;
//load data register with write command
I2C2_DATA = reg;
while (!(I2C2_STATUSRAW & 0x0010));
//poll XRDY bit in I2C2_STATUSRAW register (bit 4) until it is 
non-zero

//data has transmitted, write 1 to clear the interrupt
I2C2_STATUSRAW |= 0x0010;

while (!(I2C2_STATUSRAW & 0x0004));
//poll 'access ready' bit in I2C2_STATUSRAW register (bit 4) until 
it is non-zero
//set byte count to 2
I2C2_CNT = 2;

//set receive mode
I2C2_CON = 0x8400;

//set start and auto stop condition
I2C2_CON |= 0x0003;

while (!(I2C2_STATUSRAW & 0x0008));
//poll 'receive ready bit' in I2C2_STATUSRAW register (bit 3) until 
it is non-zero

dataByte = I2C2_DATA;   //first byte is always 0x00

//data has been received, write 1 to clear the interrupt
I2C2_STATUSRAW |= 0x0008;

while (!(I2C2_STATUSRAW & 0x0008));
//poll 'receive ready bit' in I2C2_STATUSRAW register (bit 3) until 
it is non-zero

dataByte = I2C2_DATA;   //second byte is the value we want

//data has been received, write 1 to clear the interrupt
I2C2_STATUSRAW |= 0x0008;

while (!(I2C2_STATUSRAW & 0x0100));
//poll 'buss free' bit in I2C2_STATUSRAW register (bit 8) until it 
is non-zero

//clear all pending interrupts
I2C2_STATUS = 0x7FF;

return dataByte;
}

Note the clearing of pending interrupts after each check and the final 
clear of the status register (not status_raw) at the end. 5 byte writes now 
working every time...

On Thursday, 13 September 2018 14:39:04 UTC+1, lazarman wrote:
>
> I love the TRM documentation its very detailed best to follow its 
> recommended sequences and roll your own code using examples as a template. 
>
> I'd look at the i2C slave data sheet carefully especially the timing/setup 
> diagrams.
>  you have the scope looks like your close.Another idea look for example 
> code for device even if another micro. Looking at it might give you a clue 
> what's wrong. Last attempt try something quick and simple if you have 
> available no OS barebones one processor I bet your code works on it.
> Good Luck
>
>
> Sent from Yahoo Mail on Android 
> <https://overview.mail.yahoo.com/mobile/?.src=Android>
>
> On Thu, Sep 13, 2018 at 8:06 AM, Hugh Frater
> > wrote:
> Does anyone know the correct programming sequence for doing an I2C random 
> read from within the PRU? I've tried this nicely written driver:
>
> https://github.com/LinuxDroneLab/pru-i2c-lib
>
> It works less than my code does...
>
> My code works fine if I call my routine once, on the scope I see the write 
> followed by the read of the 2 bytes I want... Call my function again and 
> all I see is the read.
>
> Code and scope grabs attached - the documentation on the I2C module from 
> within the AM335xTRM pdf is shocking and this problem is driving me mad... 
>
> /*
>  * read_wiper - returns the 2nd byte of a 2-byte read from the specified 
> wiper
>  * 'reg' contains the write command to read the required wiper
>  */
> uint8_t read_wiper(uint8_t reg)
> {
>
> uint8_t dataByte;
>
> //initialise i2c2 device
> init_i2c();
>
> //set I2C2_CNT register to 1 for initial write command
> I2C2_CNT = 1;
>
> while (!(I2C2_STATUSRAW & 0x0100));
> //poll 'buss free' bit in I2C2_STATUSRAW register (bit 8) until it 
> is non-zero
> //set transmit mode
> I2C2_CON = 0x8601;
> //load data register with write command
> I2C2_DATA = reg;
>
> while (!(I2C2_STATUSRAW & 0x0004));
> //poll 'access ready' bit in I2C2_STATUSRAW register (bit 4) until 
> it is non-zero
> //set byte count to 2
> I2C2_CNT = 2;
> //set receive mode
> I2C2_CON = 0x8403;
>
> while (!(I2C2_STATUSRAW & 0x0008));
> //poll 'receive ready bit' in I2C2_STATUSRAW register (bit 3) 
> until it is non-zero
>
> dataByte = I2C2_DATA;   //first byte is always 0x00
>
> //zero the receive ready bit once we have read the 1st byte into our 
> local variable
> I2C2_STATUSRAW |= 0x0008;
>
> while (!(I2C2_STATUSRAW & 0x0008));
> //poll 'receive ready bit' in I2C2_STATUSRAW register (bit 3) 
> until it is

[beagleboard] Re: header file for CCSv6 & PRU

[Hugh Frater]

Hi, I found all the required information in the AM335x TRM pdf file. You 
need to offsets for the I2C module you are using and the base address from 
the memory map.

The programming sequence is all detailed in there under the I2C section.

On Tuesday, 21 August 2018 12:44:01 UTC+1, Gaurav S wrote:
>
> Hugh,
> Thanks for sharing your research.
> Any chance you could also include a reference (ie where did you find this 
> info)?
>
> Thanks
>
> On Friday, August 17, 2018 at 9:43:47 AM UTC-5, Hugh Frater wrote:
>>
>> I forgot this from my previous post:
>>
>> /* I2C2 register offsets */
>>
>> #define I2C2_STATUSRAW (*((volatile unsigned int*)0x4819C024))
>> #define I2C2_CNT (*((volatile unsigned int*)0x4819C098))
>> #define I2C2_SA (*((volatile unsigned int*)0x4819C0AC))
>> #define I2C2_DATA (*((volatile unsigned int*)0x4819C09C))
>> #define I2C2_CON (*((volatile unsigned int*)0x4819C0A4))
>> #define I2C2_SCLL (*((volatile unsigned int*)0x4819C0B4))
>> #define I2C2_SCLH (*((volatile unsigned int*)0x4819C0B8))
>> #define I2C2_PSC (*((volatile unsigned int*)0x4819C0B0))
>>
>> I couldn't be bothered to setup a header file for this lot, so just 
>> stuffed it in the top of my PRU code... Registers for other I2C modules are 
>> in the memory map from the am335X_trm
>>
>> On Tuesday, 14 August 2018 12:29:12 UTC+1, Hugh Frater wrote:
>>>
>>> Does anyone know the header file I need to include to get access to the 
>>> i2c2 control registers from within the PRU subsystem? Having a hard time 
>>> getting any info and my google-foo is usually pretty decent...
>>>
>>

-- 
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/49a46d7b-2197-44b9-a6b7-b903e654704a%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Re: header file for CCSv6 & PRU

[Hugh Frater]

I forgot this from my previous post:

/* I2C2 register offsets */

#define I2C2_STATUSRAW (*((volatile unsigned int*)0x4819C024))
#define I2C2_CNT (*((volatile unsigned int*)0x4819C098))
#define I2C2_SA (*((volatile unsigned int*)0x4819C0AC))
#define I2C2_DATA (*((volatile unsigned int*)0x4819C09C))
#define I2C2_CON (*((volatile unsigned int*)0x4819C0A4))
#define I2C2_SCLL (*((volatile unsigned int*)0x4819C0B4))
#define I2C2_SCLH (*((volatile unsigned int*)0x4819C0B8))
#define I2C2_PSC (*((volatile unsigned int*)0x4819C0B0))

I couldn't be bothered to setup a header file for this lot, so just stuffed 
it in the top of my PRU code... Registers for other I2C modules are in the 
memory map from the am335X_trm

On Tuesday, 14 August 2018 12:29:12 UTC+1, Hugh Frater wrote:
>
> Does anyone know the header file I need to include to get access to the 
> i2c2 control registers from within the PRU subsystem? Having a hard time 
> getting any info and my google-foo is usually pretty decent...
>

-- 
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/9145aa05-a10f-4188-a293-b1cb0358392a%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Re: header file for CCSv6 & PRU

[Hugh Frater]

An update:

1. Enable the i2c peripheral clock: 

#define CM_PER_I2C2 (*((volatile unsigned int *)0x44E00044))

/* Enable I2C2 clock signal generation */
while (!(CM_PER_I2C2 & 0x2))
 CM_PER_I2C2 |= 0x2;

2. Setup the registers:

/*
 *  set I2C2_PSC register to 0x0B
 *  set I2C2_SCCL register to 0x0D
 *  set I2C2_SCCH register to 0x0F
 *  set I2C2_CON register to 1000 0110   (0x8600)
 *  set I2C2_SA register to 0x2E (address of MCP4641)
 *  set I2C2_CNT register to 2 (data length)
 */

I2C2_PSC = 0x000B;
I2C2_SCLL = 0x000D;
I2C2_SCLH = 0x000F;
I2C2_CON = 0x8600;
I2C2_SA = i2cPotAddress;
I2C2_CNT = 2;

3. You can now program the device:

/*
*  poll 'busy bit' in I2C2_STATUSRAW register (bit 12) until it is zero
*  set start/stop bits in I2C2_CON register to initiate a transfer
*  poll XRDY bit in I2C2_STATUSRAW register (bit 4) until it is non-zero
*  load 1st byte of data into I2C2_DATA register
*  poll XRDY bit in I2C2_STATUSRAW register (bit 4) until it is non-zero
*  load 2nd byte of data into I2C2_DATA register
*/

while (I2C2_STATUSRAW & 0x1000);
   //poll 'busy bit' in I2C2_STATUSRAW register (bit 12) until it is zero
I2C2_CON = 0x8603;
while (!I2C2_STATUSRAW & 0x0010);
   //poll XRDY bit in I2C2_STATUSRAW register (bit 4) until it is non-zero
I2C2_DATA = torqueWiper;
while (!I2C2_STATUSRAW & 0x0010);
   //poll XRDY bit in I2C2_STATUSRAW register (bit 4) until it is non-zero
I2C2_DATA = 0x55;

4. The kernel mode (and bonescript) i2c drivers will put the device to 
sleep and disable the clock after every transfer, so to access it from the 
PRU you need to setup the registers each time you want to access a device 
on the bus. 

Hope that helps someone...

On Tuesday, 14 August 2018 12:29:12 UTC+1, Hugh Frater wrote:
>
> Does anyone know the header file I need to include to get access to the 
> i2c2 control registers from within the PRU subsystem? Having a hard time 
> getting any info and my google-foo is usually pretty decent...
>

-- 
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/4f509d76-975c-4f6e-920d-5e3963d2f364%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Re: PRUs realtime data acquisition, I2C bus and ADC

[Hugh Frater]

Did you figure out access to the i2c registers from within the PRU? I'm 
working on that at the moment and could use a header file or similar...

On Tuesday, 13 February 2018 17:49:23 UTC, pierric...@gadz.org wrote:
>
> Hi all, 
>
> I am trying to use the PRUs for real time data acquisition on the 
> Beaglebone black (Linux debian 4.9.45-ti-r57). I have set up the PRU with 
> remoteproc and RPMsg; everything is working fine. 
> The first time, I successfully captured data with the PRU using the SPI 
> protocol and bit banging, and I have sent them to the ARM with RPMsg. 
>
> Now I want to do the same thing using the I2C protocol, which left me with 
> some questions: 
> - Is it possible to use the on-board I2C bus with the PRUs? 
> - If not, I will enable the pull-up resistor on a GPIO pins using a custom 
> device tree. But after that, I do not really understand how I can read and 
> write the SDA line for I2C? (Contrary to the SPI protocol, I won't have 
> Data In and  Data out lines but only one SDA line).
>
> My final goal will be to use the on-board ADC. There is already a very 
> interesting project PRUADC that captures data using an external ADC. I 
> would like to use the on-board ADC, is there any way to do it ? (I am not 
> afraid of going into complex stuff). 
>
> Thanks,
>
>
> Pierrick 
>
>
>

-- 
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/7ca6b77b-3f58-4b10-9ad1-20458e8e3efd%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] header file for CCSv6 & PRU

[Hugh Frater]

Interesting, thanks Charles...

FWIW, I've been working with the eQEP hardware from within the PRU and that 
also lacks a header file, however, some example TI code (which I am using 
in my project) shows:

/* Non-CT register defines */
#define CM_PER_EPWMSS1 (*((volatile unsigned int *)0x44E000CC))

Coupled with:

#include 

As being good enough to allow subsequent access and control of the PWMSS 
from within the PRU... I have added a #define for the base address of I2C2 
but I now need to find if there is a header file to go with. I'll do some 
searching.

On Wednesday, 15 August 2018 03:30:01 UTC+1, Charles Steinkuehler wrote:
>
> On 8/14/2018 6:29 AM, Hugh Frater wrote: 
> > Does anyone know the header file I need to include to get access to the 
> > i2c2 control registers from within the PRU subsystem? Having a hard time 
> > getting any info and my google-foo is usually pretty decent... 
>
> AFAIK, there are no "standard" headers for accessing physical hardware 
> like the i2c buses from the PRU.  Even the Linux kernel generally 
> mixes this sort of thing between header files (for the bit definitions 
> and "structure" of the control registers) and the device tree (for 
> base addresses, IRQ values, etc). 
>
> Probably the closest you'll find is something from the TI bare-metal code: 
>
> http://processors.wiki.ti.com/index.php/StarterWare 
>
> -- 
> 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/c2ed5676-e76b-4227-8e87-f249db3eeed1%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] header file for CCSv6 & PRU

[Hugh Frater]

Does anyone know the header file I need to include to get access to the 
i2c2 control registers from within the PRU subsystem? Having a hard time 
getting any info and my google-foo is usually pretty decent...

-- 
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/489699f1-9555-4fa3-9265-db090dc18fa3%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Re: More pimux woes

[Hugh Frater]

On Monday, 22 January 2018 17:42:03 UTC, lgil...@tethers.com wrote:
>
> Thanks!!   Very helpful.  One issue with just using the config-pin utility 
> is that it doesn't always give you access to all the configurations 
> possible for a peripheral (not pin), for instance, setting a pin to eqep 
> (qep), there are actually several modes of eqep.   The dts file often 
> includes all these options.  
>
> That is a very valid point and something I hadn't considered. I was 
working around this by using my pru code to configure the required 
peripheral registers directly, which now I look at it seems a terrible way 
to do it when I could use the dts file... 

-- 
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/6f82ba09-c0de-4318-bc76-5e272dc0a8f4%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Re: More pimux woes

[Hugh Frater]

Robert, everything is working nicely at this end with the new version of 
bb-cape-overlays. 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/18053977-5aaa-41ad-86be-33c15d0936d6%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Re: More pimux woes

[Hugh Frater]

You basically have 2 options regarding pinmuxing on a bb the config-pin 
utility requires the universal cape to be loaded as the only dtbo, you then use 
configure-pin to setup the pins you want.

2nd option, specify the overlays for the actual hardware you want to use, e.g 
robotics cape, bone-eqep2 etc. You can’t load the specific overlays and the 
universal cape together, they conflict, and you can’t use confit-pin without 
the universal overlay being loaded.

Personally, given I’m using a ton of pins for various things, I use the 
universal overlay then have a script that runs from init.d to configure all the 
pins at boot time. I preferred the convenience of using the config-pin utility 
as apposed to writing my own device overlay for the pins I’m using.

-- 
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/30b0ebb2-991a-46ca-90c0-490cc04e288c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Re: More pimux woes

[Hugh Frater]

Thanks Robert, I won’t be back in front of my BBB till Monday now but I’ll be 
sure to test it first thing.

-- 
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/5b8146ee-3982-4472-b6eb-1883101442c9%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Re: More pimux woes

[Hugh Frater]

Top man, thanks for taking care of this. Let me know when it gets pushed up 
and i'll re-run apt update


On Friday, 19 January 2018 16:17:21 UTC, RobertCNelson wrote:
>
> On Fri, Jan 19, 2018 at 5:45 AM, Hugh Frater <hugh@gmail.com 
> > wrote: 
> >>> 
> >> Running: 
> >> 
> >> sudo apt update ; sudo apt install bb-cape-overlays 
> >> 
> >> Has fixed the eqep errors and the clash between p9_26 and p8_24 that I 
> was 
> >> seeing - however, pru_ecap has now gone as a mode for p9_42 - 
> argggh 
> > 
> > 
> > I see from the most recent commit that this has been added back again as 
> a 
> > mux option Robert, any idea when it will be pushed up and available 
> through 
> > apt update? 
>
> Hi Hugh, 
>
> Yeah after your message yesterday, i went thru the overlays and 
> regenerated with *.dts/pinmux.. 
>
> I'll have a full update for the kernel/config-pin/etc shortly 
>
> (plus gpio_input option will be available).. 
>
> 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/8047deb5-a5b3-42bc-b550-e38fb34ad843%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Re: More pimux woes

[Hugh Frater]

>
>
>> Running:
>
> sudo apt update ; sudo apt install bb-cape-overlays
>
> Has fixed the eqep errors and the clash between p9_26 and p8_24 that I was 
> seeing - however, pru_ecap has now gone as a mode for p9_42 - argggh
>

I see from the most recent commit that this has been added back again as a 
mux option Robert, any idea when it will be pushed up and available through 
apt update?

 

-- 
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/e8fc5f86-3620-4968-94fa-dd8b1615059b%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Re: More pimux woes

[Hugh Frater]

On Thursday, 18 January 2018 12:53:59 UTC, Hugh Frater wrote:
>
> I've been trying to get my test hardware back up and running after 
> corrupting node and bonescript, see my earlier post.
>
> I'm trying to get up and running with an 8.6 image as I couldn't get a 9.2 
> image to provide pru_rproc support
>
> debian@beaglebone:~$ uname -r
> 4.4.54-ti-r93
>
> I'm trying to get the eqep support working on P8_31,33 & 35 (it was 
> working before)
>
> debian@beaglebone:~$ sudo config-pin -l P8_31
> default gpio gpio_pu gpio_pd uart qep
>
> Looks like qep is a supported mode...
>
> debian@beaglebone:~$ sudo config-pin P8_31 qep
> [sudo] password for debian: 
> bash: line 0: echo: write error: No such device
> Cannot write pinmux file: /sys/devices/platform/ocp/ocp:P8_31_pinmux/state
>
> Any idea what is causing the above error? The important bits from uEnv.txt 
> are:
>
> ##BeagleBone Black: HDMI (Audio/Video)/eMMC disabled:
> dtb=am335x-boneblack-overlay.dtb
>
> cmdline=coherent_pool=1M net.ifnames=0 quiet cape-universal=enable
>
> ##Example v4.1.x
> #cape_disable=bone_capemgr.disable_partno=
> cape_enable=bone_capemgr.enable_partno=cape-universala
>
>
> Running:

sudo apt update ; sudo apt install bb-cape-overlays

Has fixed the eqep errors and the clash between p9_26 and p8_24 that I was 
seeing - however, pru_ecap has now gone as a mode for p9_42 - argggh

-- 
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/b83d1ac0-721a-4dd7-a546-e6fa05f8014c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] More pimux woes

[Hugh Frater]

I've been trying to get my test hardware back up and running after 
corrupting node and bonescript, see my earlier post.

I'm trying to get up and running with an 8.6 image as I couldn't get a 9.2 
image to provide pru_rproc support

debian@beaglebone:~$ uname -r
4.4.54-ti-r93

I'm trying to get the eqep support working on P8_31,33 & 35 (it was working 
before)

debian@beaglebone:~$ sudo config-pin -l P8_31
default gpio gpio_pu gpio_pd uart qep

Looks like qep is a supported mode...

debian@beaglebone:~$ sudo config-pin P8_31 qep
[sudo] password for debian: 
bash: line 0: echo: write error: No such device
Cannot write pinmux file: /sys/devices/platform/ocp/ocp:P8_31_pinmux/state

Any idea what is causing the above error? The important bits from uEnv.txt 
are:

##BeagleBone Black: HDMI (Audio/Video)/eMMC disabled:
dtb=am335x-boneblack-overlay.dtb

cmdline=coherent_pool=1M net.ifnames=0 quiet cape-universal=enable

##Example v4.1.x
#cape_disable=bone_capemgr.disable_partno=
cape_enable=bone_capemgr.enable_partno=cape-universala







-- 
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/0f157ef5-3803-4f41-8d3a-f92e73ac848e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] pru_rproc on latest Stretch IoT image

[Hugh Frater]

On Wednesday, 17 January 2018 10:41:56 UTC, Hugh Frater wrote:
>
>
>>>>
>>>  Robert, thanks for the input so far. I had just come across this post
>>>
>>> *https://groups.google.com/forum/#!category-topic/beagleboard/boot/lS8QlNV8JCc
>>>  
>>> <https://groups.google.com/forum/#!category-topic/beagleboard/boot/lS8QlNV8JCc>*
>>>
>>> And tried the steps you outlined in there but with no joy. I've tried 
>>> running the script 
>>>
>>> sudo /opt/scripts/tools/developers/update_initrd.sh
>>>
>>> but again, not luck. I'm not actually getting any reference to pru_rproc 
>>> at all from within the dmesg log, apart from in relation to the PM 
>>> peripheral (whatever that is) - very odd.
>>>
>>
>> I'm going to try again today with the 8.7 image from March '17
>>
>
> An update - a clean install of 8.7 with the stock uEnv.txt results in the 
> usual pru-rproc stuff in dmesg. Edit the file to enable u-boot overlays and 
> the pru-rproc subsystem doesn't load at boot time. 
>

Robert, any idea why pru_ecap has gone from the config-pin options for 
P9_42? 

-- 
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/b30a7562-306b-4432-8cae-fe5bef837838%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Re: eQEP1 setup problems with latest debian iOT

[Hugh Frater]

On Wednesday, 17 January 2018 12:37:03 UTC, Hugh Frater wrote:
>
>
>
> On Thursday, 11 May 2017 10:18:08 UTC+1, Hugh Frater wrote:
>>
>> It looks like we are good-to-go. Thanks for sorting this out guys :)
>>
>> Hugh
>>
>> On Wednesday, 10 May 2017 17:16:50 UTC+1, RobertCNelson wrote:
>>>
>>> On Wed, May 10, 2017 at 10:20 AM, Hugh Frater <hugh@gmail.com> 
>>> wrote: 
>>> > Thanks guys, I'll keep an eye on the repository and grab a copy once 
>>> things 
>>> > are finalised. 
>>>
>>> Okay all pushed out.. 
>>>
>>> run: 
>>>
>>> sudo apt update ; sudo apt upgrade 
>>>
>>> and it should show an upgrade for bb-cape-overlays 
>>> bb-cape-overlays_4.4.20170510.0 
>>>
>>> reboot and it should work, let us know.. 
>>>
>>> Regards, 
>>>
>>> -- 
>>> Robert Nelson 
>>> https://rcn-ee.com/ 
>>>
>>
> Just to add to this again - this fix is still required if you use the 8.7 
> IoT image but is not required if you use the 9.1 image. Also note that the 
> pru_ecap mode for P9_42 is now called PWM when you call config-pin 
>

OK, looks like pru_ecap mode was removed from the .dtbo as an option for 
this pin - PWM is not what you want if you want to use the pru1 ecap device 
as a PWM generator - you need mode 3, which is no longer a valid option. 
Time to downgrade again to 8.6 :( Why can't these options stay when the 
universal overlays get updated?

-- 
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/76dcedb2-8543-4555-8f04-807187200ffa%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Re: eQEP1 setup problems with latest debian iOT

[Hugh Frater]

On Thursday, 11 May 2017 10:18:08 UTC+1, Hugh Frater wrote:
>
> It looks like we are good-to-go. Thanks for sorting this out guys :)
>
> Hugh
>
> On Wednesday, 10 May 2017 17:16:50 UTC+1, RobertCNelson wrote:
>>
>> On Wed, May 10, 2017 at 10:20 AM, Hugh Frater <hugh@gmail.com> 
>> wrote: 
>> > Thanks guys, I'll keep an eye on the repository and grab a copy once 
>> things 
>> > are finalised. 
>>
>> Okay all pushed out.. 
>>
>> run: 
>>
>> sudo apt update ; sudo apt upgrade 
>>
>> and it should show an upgrade for bb-cape-overlays 
>> bb-cape-overlays_4.4.20170510.0 
>>
>> reboot and it should work, let us know.. 
>>
>> Regards, 
>>
>> -- 
>> Robert Nelson 
>> https://rcn-ee.com/ 
>>
>
Just to add to this again - this fix is still required if you use the 8.7 
IoT image but is not required if you use the 9.1 image. Also note that the 
pru_ecap mode for P9_42 is now called PWM when you call config-pin 

-- 
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/6c463427-2340-4882-b3d6-a4a79f9f5e67%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] pru_rproc on latest Stretch IoT image

[Hugh Frater]

>
>
>>>
>>  Robert, thanks for the input so far. I had just come across this post
>>
>> *https://groups.google.com/forum/#!category-topic/beagleboard/boot/lS8QlNV8JCc
>>  
>> *
>>
>> And tried the steps you outlined in there but with no joy. I've tried 
>> running the script 
>>
>> sudo /opt/scripts/tools/developers/update_initrd.sh
>>
>> but again, not luck. I'm not actually getting any reference to pru_rproc 
>> at all from within the dmesg log, apart from in relation to the PM 
>> peripheral (whatever that is) - very odd.
>>
>
> I'm going to try again today with the 8.7 image from March '17
>

An update - a clean install of 8.7 with the stock uEnv.txt results in the 
usual pru-rproc stuff in dmesg. Edit the file to enable u-boot overlays and 
the pru-rproc subsystem doesn't load at boot time. 

-- 
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/e42df4c8-7c04-4e16-9752-24fac841ff43%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] pru_rproc on latest Stretch IoT image

[Hugh Frater]

On Tuesday, 16 January 2018 16:00:33 UTC, Hugh Frater wrote:
>
>
>
> On Tuesday, 16 January 2018 15:52:23 UTC, RobertCNelson wrote:
>>
>> > Gotcha - here is the output after correcting /boot/uEnv.txt: 
>> > 
>> > debian@beaglebone:~$ sudo /opt/scripts/tools/version.sh 
>> > [sudo] password for debian: 
>> > git:/opt/scripts/:[d36fe9a7be9ebfc872b10a470e904ab4c61c4516] 
>> > eeprom:[A335BNLT00C03816BBBK190D] 
>> > dogtag:[BeagleBoard.org Debian Image 2017-10-10] 
>> > bootloader:[microSD-(push-button)]:[/dev/mmcblk0]:[U-Boot 
>> > 2017.09-2-g0f3f1c7907] 
>> > kernel:[4.4.91-ti-r133] 
>> > nodejs:[v6.11.4] 
>> > uboot_overlay_options:[enable_uboot_overlays=1] 
>> > uboot_overlay_options:[disable_uboot_overlay_emmc=1] 
>> > uboot_overlay_options:[disable_uboot_overlay_video=1] 
>> > uboot_overlay_options:[disable_uboot_overlay_audio=1] 
>> > uboot_overlay_options:[disable_uboot_overlay_wireless=1] 
>> > uboot_overlay_options:[disable_uboot_overlay_adc=1] 
>> > 
>> uboot_overlay_options:[uboot_overlay_pru=/lib/firmware/AM335X-PRU-RPROC-4-4-TI-00A0.dtbo]
>>  
>>
>> > uboot_overlay_options:[enable_uboot_cape_universal=1] 
>> > pkg:[bb-cape-overlays]:[4.4.20171009.0-0rcnee1~stretch+20171009] 
>> > pkg:[bb-wl18xx-firmware]:[1.20170829-0rcnee1~stretch+20170829] 
>>
>>
>> Okay perfect! 
>>
>> Next for the pru firmware, the symlink might not work, but you'll need to 
>> run: 
>>
>> sudo /opt/scripts/tools/developers/update_initrd.sh 
>>
>> the initrd hook: 
>>
>> /usr/share/initramfs-tools/hooks/ti_pru_firmware 
>>
>> will copy the /lib/firmware/am335x-pru0-fw to the initrd so that the 
>> pru will loaded early on bootup.. 
>>
>> Regards, 
>>
>>
>> -- 
>> Robert Nelson 
>> https://rcn-ee.com/ 
>>
>
>  Robert, thanks for the input so far. I had just come across this post
>
> *https://groups.google.com/forum/#!category-topic/beagleboard/boot/lS8QlNV8JCc
>  
> <https://groups.google.com/forum/#!category-topic/beagleboard/boot/lS8QlNV8JCc>*
>
> And tried the steps you outlined in there but with no joy. I've tried 
> running the script 
>
> sudo /opt/scripts/tools/developers/update_initrd.sh
>
> but again, not luck. I'm not actually getting any reference to pru_rproc 
> at all from within the dmesg log, apart from in relation to the PM 
> peripheral (whatever that is) - very odd.
>

I'm going to try again today with the 8.7 image from March '17

-- 
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/cc945957-71fa-48e1-9005-61d80586827d%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] pru_rproc on latest Stretch IoT image

[Hugh Frater]

On Tuesday, 16 January 2018 15:52:23 UTC, RobertCNelson wrote:
>
> > Gotcha - here is the output after correcting /boot/uEnv.txt: 
> > 
> > debian@beaglebone:~$ sudo /opt/scripts/tools/version.sh 
> > [sudo] password for debian: 
> > git:/opt/scripts/:[d36fe9a7be9ebfc872b10a470e904ab4c61c4516] 
> > eeprom:[A335BNLT00C03816BBBK190D] 
> > dogtag:[BeagleBoard.org Debian Image 2017-10-10] 
> > bootloader:[microSD-(push-button)]:[/dev/mmcblk0]:[U-Boot 
> > 2017.09-2-g0f3f1c7907] 
> > kernel:[4.4.91-ti-r133] 
> > nodejs:[v6.11.4] 
> > uboot_overlay_options:[enable_uboot_overlays=1] 
> > uboot_overlay_options:[disable_uboot_overlay_emmc=1] 
> > uboot_overlay_options:[disable_uboot_overlay_video=1] 
> > uboot_overlay_options:[disable_uboot_overlay_audio=1] 
> > uboot_overlay_options:[disable_uboot_overlay_wireless=1] 
> > uboot_overlay_options:[disable_uboot_overlay_adc=1] 
> > 
> uboot_overlay_options:[uboot_overlay_pru=/lib/firmware/AM335X-PRU-RPROC-4-4-TI-00A0.dtbo]
>  
>
> > uboot_overlay_options:[enable_uboot_cape_universal=1] 
> > pkg:[bb-cape-overlays]:[4.4.20171009.0-0rcnee1~stretch+20171009] 
> > pkg:[bb-wl18xx-firmware]:[1.20170829-0rcnee1~stretch+20170829] 
>
>
> Okay perfect! 
>
> Next for the pru firmware, the symlink might not work, but you'll need to 
> run: 
>
> sudo /opt/scripts/tools/developers/update_initrd.sh 
>
> the initrd hook: 
>
> /usr/share/initramfs-tools/hooks/ti_pru_firmware 
>
> will copy the /lib/firmware/am335x-pru0-fw to the initrd so that the 
> pru will loaded early on bootup.. 
>
> Regards, 
>
>
> -- 
> Robert Nelson 
> https://rcn-ee.com/ 
>

 Robert, thanks for the input so far. I had just come across this post

*https://groups.google.com/forum/#!category-topic/beagleboard/boot/lS8QlNV8JCc*

And tried the steps you outlined in there but with no joy. I've tried 
running the script 

sudo /opt/scripts/tools/developers/update_initrd.sh

but again, not luck. I'm not actually getting any reference to pru_rproc at 
all from within the dmesg log, apart from in relation to the PM peripheral 
(whatever that is) - very odd.

-- 
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/c9de05a7-4963-46d2-b80c-de0bb68cf836%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] pru_rproc on latest Stretch IoT image

[Hugh Frater]

On Tuesday, 16 January 2018 15:08:51 UTC, RobertCNelson wrote:
>
> > debian@beaglebone:~$ sudo /opt/scripts/tools/version.sh 
>
> > kernel:[4.4.91-ti-r133] 
>
> > 
> uboot_overlay_options:[uboot_overlay_pru=/lib/firmware/AM335X-PRU-RPROC-4-9-TI-00A0.dtbo]
>  
>
>
> > I edited this line: 
> > 
> > 
> uboot_overlay_options:[uboot_overlay_pru=/lib/firmware/AM335X-PRU-RPROC-4-9-TI-00A0.dtbo]
>  
>
> > 
> > To point at the .dtbo that matched my kernel revision - it didn't make 
> any 
> > difference. 
>
> Actually your running v4.4.x based kernel, use the 
>
> uboot_overlay_pru=/lib/firmware/AM335X-PRU-RPROC-4-4-TI-00A0.dtbo 
>
> option.. 
>
> TI rewrote the pru_rproc again in v4.9.x so the device tree node is 
> incompatible. 
>
> Regards, 
>
> -- 
> Robert Nelson 
> https://rcn-ee.com/ 
>

Gotcha - here is the output after correcting /boot/uEnv.txt:

debian@beaglebone:~$ sudo /opt/scripts/tools/version.sh 
[sudo] password for debian: 
git:/opt/scripts/:[d36fe9a7be9ebfc872b10a470e904ab4c61c4516]
eeprom:[A335BNLT00C03816BBBK190D]
dogtag:[BeagleBoard.org Debian Image 2017-10-10]
bootloader:[microSD-(push-button)]:[/dev/mmcblk0]:[U-Boot 
2017.09-2-g0f3f1c7907]
kernel:[4.4.91-ti-r133]
nodejs:[v6.11.4]
uboot_overlay_options:[enable_uboot_overlays=1]
uboot_overlay_options:[disable_uboot_overlay_emmc=1]
uboot_overlay_options:[disable_uboot_overlay_video=1]
uboot_overlay_options:[disable_uboot_overlay_audio=1]
uboot_overlay_options:[disable_uboot_overlay_wireless=1]
uboot_overlay_options:[disable_uboot_overlay_adc=1]
uboot_overlay_options:[uboot_overlay_pru=/lib/firmware/AM335X-PRU-RPROC-4-4-TI-00A0.dtbo]
uboot_overlay_options:[enable_uboot_cape_universal=1]
pkg:[bb-cape-overlays]:[4.4.20171009.0-0rcnee1~stretch+20171009]
pkg:[bb-wl18xx-firmware]:[1.20170829-0rcnee1~stretch+20170829]
pkg:[firmware-ti-connectivity]:[20170823-1rcnee0~stretch+20170830]

-- 
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/e65970d6-9ba3-446c-ac70-01ea64243d03%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] pru_rproc on latest Stretch IoT image

[Hugh Frater]

On Tuesday, 16 January 2018 14:56:03 UTC, RobertCNelson wrote:
>
> On Tue, Jan 16, 2018 at 8:12 AM, Hugh Frater <hugh@gmail.com 
> > wrote: 
> > I broke my installation (screwed up node.js and bonescript versions, 
> stuff 
> > went bad) so re-flashed my test hardware with the latest Stretch IoT 
> > image... I'm now figuring out how U-Boot overlays work, which seem 
> pretty 
> > straightforward, just a few changes in uEnv.txt... 
> > 
> > How the heck do I get pru_rproc to work again? I'm guessing I need to 
> > blacklist uio_pruss modules before I'll start to see the results of a 
> > modprobe pru_rproc in a dmesg output? 
> > 
> > During bootup I don't see much in the way of output from the pru_rproc 
> > subsystem in dmesg, the only stuff there is related to what I assume is 
> a 
> > power management peripheral: 
> > 
> > [2.519084]  remoteproc0: powering up wkup_m3 
> > [2.519481]  remoteproc0: Booting fw image am335x-pm-firmware.elf, 
> size 
> > 217148 
> > [2.521735]  remoteproc0: remote processor wkup_m3 is now up 
> > [2.521759] wkup_m3_ipc 44e11324.wkup_m3_ipc: CM3 Firmware Version = 
> > 0x192 
> > [2.521955] PM: bootloader does not support rtc-only! 
>
> That's ^ the pm firmware, not for the pru... 
>
> > 
> > I have copied my binary over and symlinked it against 
> > /lib/firmware/am335x-pru1-fw as before. 
>
> Please run: 
>
> sudo /opt/scripts/tools/version.sh 
>
> and we will debug what's up with pru_rproc. 
>
> Regards, 
>
> -- 
> Robert Nelson 
> https://rcn-ee.com/ 
>

debian@beaglebone:~$ sudo /opt/scripts/tools/version.sh 
git:/opt/scripts/:[d36fe9a7be9ebfc872b10a470e904ab4c61c4516]
eeprom:[A335BNLT00C03816BBBK190D]
dogtag:[BeagleBoard.org Debian Image 2017-10-10]
bootloader:[microSD-(push-button)]:[/dev/mmcblk0]:[U-Boot 
2017.09-2-g0f3f1c7907]
kernel:[4.4.91-ti-r133]
nodejs:[v6.11.4]
uboot_overlay_options:[enable_uboot_overlays=1]
uboot_overlay_options:[disable_uboot_overlay_emmc=1]
uboot_overlay_options:[disable_uboot_overlay_video=1]
uboot_overlay_options:[disable_uboot_overlay_audio=1]
uboot_overlay_options:[disable_uboot_overlay_wireless=1]
uboot_overlay_options:[disable_uboot_overlay_adc=1]
uboot_overlay_options:[uboot_overlay_pru=/lib/firmware/AM335X-PRU-RPROC-4-9-TI-00A0.dtbo]
uboot_overlay_options:[enable_uboot_cape_universal=1]
pkg:[bb-cape-overlays]:[4.4.20171009.0-0rcnee1~stretch+20171009]
pkg:[bb-wl18xx-firmware]:[1.20170829-0rcnee1~stretch+20170829]
pkg:[firmware-ti-connectivity]:[20170823-1rcnee0~stretch+20170830]

I edited this line:

uboot_overlay_options:[uboot_overlay_pru=/lib/firmware/AM335X-PRU-RPROC-4-9-TI-00A0.dtbo]

To point at the .dtbo that matched my kernel revision - it didn't make any 
difference.

 

-- 
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/c2475428-095a-4009-aa86-52776fdc1590%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] pru_rproc on latest Stretch IoT image

[Hugh Frater]

I broke my installation (screwed up node.js and bonescript versions, stuff 
went bad) so re-flashed my test hardware with the latest Stretch IoT 
image... I'm now figuring out how U-Boot overlays work, which seem pretty 
straightforward, just a few changes in uEnv.txt...

How the heck do I get pru_rproc to work again? I'm guessing I need to 
blacklist uio_pruss modules before I'll start to see the results of a 
modprobe pru_rproc in a dmesg output?

During bootup I don't see much in the way of output from the pru_rproc 
subsystem in dmesg, the only stuff there is related to what I assume is a 
power management peripheral:

[2.519084]  remoteproc0: powering up wkup_m3
[2.519481]  remoteproc0: Booting fw image am335x-pm-firmware.elf, size 
217148
[2.521735]  remoteproc0: remote processor wkup_m3 is now up
[2.521759] wkup_m3_ipc 44e11324.wkup_m3_ipc: CM3 Firmware Version = 
0x192
[2.521955] PM: bootloader does not support rtc-only!

I have copied my binary over and symlinked it against 
/lib/firmware/am335x-pru1-fw as before. 

-- 
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/44e31ad0-d029-40c1-809f-f4e5957866e0%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Timers, interrupts and other such delights

[Hugh Frater]

I have a mechatronic device which has a couple of 'jog' buttons, these are 
working nicely on a interrupt. The interrupt code fires on level change 
then checks the value - corresponding code sections send a command to the 
PRU via /dev/rpmsg_pru31.

Part of the command sent is a numeric value representing the frequency of 
the pru_ecap PWM generation (this connects to an AC servo motor 'step' 
input)...

As you can now see, press the button, the motor moves, release the button & 
the frequency command sent is reduced to '0' and the PRU code stops the pwm 
generation.

What I've been playing around with today is making this a ramped 
(accelerated) jog. I can put a loop inside the interrupt code that 
increases the value of the numeric value, works fine, but I would like to 
delay the loop so the acceleration is more gradual. I've played around with 
a setTimeout function inside the loop, doesn't work.

I've moved this delayed loop to a separate function outside of the ISR. 
Inside the ISR I just loop in a do->while until the ramp generation code 
has incremented the value to a maximum, I then cancel the interval timer - 
this doesn't work either.

Is there a better way to do this that I've overlooked?


-- 
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/e2c31a95-5479-45b6-bc25-3082e485c772%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Duplex stream for reading and writing commands to /dev/rpmsg_pru31

[Hugh Frater]

A simple oversight in an area of my PRU code (I was sending the whole 
rpunit struct back as the payload, rather than just the first member of the 
struct, a single char representing the command) now has the characters 
coming back into my userspace program. However, I can only manage 3x 
command exchanges before something locks up... nothing in dmesg... I'm 
using the file-duplex package which I found on npm to handle the duplex 
stream, perhaps the bug is in here...?

On Saturday, 28 October 2017 17:20:54 UTC+1, Nahuel Greco wrote:
>
> you don't need that, you can use a single  /dev/rpmsg_pruXX for 
> bidirectional communication with a single PRU. Try running the Texas echo 
> example from command line (first doing an "echo xxx > dev/rpmsg_pruXX", and 
> then "cat /dev/rpmsg_pruXX"),then try to use that from node. That will 
> discard if the problem is in your PRU code.
>
> Saludos,
> Nahuel Greco.
>
> On Fri, Oct 27, 2017 at 5:30 PM, Hugh Frater <hugh@gmail.com 
> > wrote:
>
>> I know the stream is transmitting OK, my PRU code reacts as expected to 
>> the messages I'm sending over. I'm going to look at the data in more detail 
>> over this weekend, I've been off this project for 10 days or so.
>>
>> I'm beginning to wonder if I fudge around this by using shared memory 
>> between the 2x PRUs and then use one /dev entry for commands to and one 
>> /dev entry for commands from - I'd rather not though.
>>
>> On Friday, 27 October 2017 18:36:35 UTC+1, Nahuel Greco wrote:
>>>
>>> Smells like the problem is at the nodejs side, maybe you can try not 
>>> running the node program and cat'ing the device to see if the characters 
>>> are shown. What's the value of the 'data' received in the callback?
>>>
>>>
>>> Saludos,
>>> Nahuel Greco.
>>>
>>> On Fri, Oct 27, 2017 at 11:05 AM, Hugh Frater <hugh@gmail.com> 
>>> wrote:
>>>
>>>> Hi Nahuel,
>>>>
>>>> You can't cat the device file because linux doesn't allow concurrent 
>>>> access to the device file descriptor from more than one userspace program, 
>>>> and we need to open that device file from within our node.js program to 
>>>> write to the PRU. I do have a hardware UART looped back from the PRU into 
>>>> userspace, so I could use that for the communication back into userpace, 
>>>> but I would rather persevere and get the rpmsg subsystem working in a 
>>>> bi-directional mode.
>>>>
>>>>
>>>> On Thursday, 26 October 2017 21:57:02 UTC+1, Nahuel Greco wrote:
>>>>>
>>>>> doing "cat /dev/rpmsg_pruXX" shows any data? do you have a github repo 
>>>>> with a complete sample?
>>>>>
>>>>> Saludos,
>>>>> Nahuel Greco.
>>>>>
>>>>> On Mon, Oct 9, 2017 at 1:11 PM, Hugh Frater <hugh@gmail.com> 
>>>>> wrote:
>>>>>
>>>>>> Does anyone have any experience of working with /dev/rpmsg_pruXX 
>>>>>> files from within Node.Js/Bonescript? I've been playing around with the 
>>>>>> file-duplex package and have data going into the PRU just fine, but I'm 
>>>>>> having an issue getting data back into my userspace program. I've got 
>>>>>> the 
>>>>>> stream.on('data', function(data)) picking up that a data has been pushed 
>>>>>> into the rpmsg file from the PRU side, but I can't get any meaningful 
>>>>>> data 
>>>>>> into my program. I'm sending single character ascii characters as my 
>>>>>> data.
>>>>>>
>>>>>> Am I missing the 'proper' way to do this?
>>>>>>
>>>>>> -- 
>>>>>> 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/666d2c51-fa4f-464b-83db-ffc7a158fecf%40googlegroups.com
>>>>>>  
>>>>>> <https://groups.google.com/d/msgid/beagleboard/666d2c51-fa4f-464b-83db-ffc7a158fecf%40googlegroups.com?utm_medium=email_source=footer>
>>>&

Re: [beagleboard] Duplex stream for reading and writing commands to /dev/rpmsg_pru31

[Hugh Frater]

I know the stream is transmitting OK, my PRU code reacts as expected to the 
messages I'm sending over. I'm going to look at the data in more detail 
over this weekend, I've been off this project for 10 days or so.

I'm beginning to wonder if I fudge around this by using shared memory 
between the 2x PRUs and then use one /dev entry for commands to and one 
/dev entry for commands from - I'd rather not though.

On Friday, 27 October 2017 18:36:35 UTC+1, Nahuel Greco wrote:
>
> Smells like the problem is at the nodejs side, maybe you can try not 
> running the node program and cat'ing the device to see if the characters 
> are shown. What's the value of the 'data' received in the callback?
>
>
> Saludos,
> Nahuel Greco.
>
> On Fri, Oct 27, 2017 at 11:05 AM, Hugh Frater <hugh@gmail.com 
> > wrote:
>
>> Hi Nahuel,
>>
>> You can't cat the device file because linux doesn't allow concurrent 
>> access to the device file descriptor from more than one userspace program, 
>> and we need to open that device file from within our node.js program to 
>> write to the PRU. I do have a hardware UART looped back from the PRU into 
>> userspace, so I could use that for the communication back into userpace, 
>> but I would rather persevere and get the rpmsg subsystem working in a 
>> bi-directional mode.
>>
>>
>> On Thursday, 26 October 2017 21:57:02 UTC+1, Nahuel Greco wrote:
>>>
>>> doing "cat /dev/rpmsg_pruXX" shows any data? do you have a github repo 
>>> with a complete sample?
>>>
>>> Saludos,
>>> Nahuel Greco.
>>>
>>> On Mon, Oct 9, 2017 at 1:11 PM, Hugh Frater <hugh@gmail.com> wrote:
>>>
>>>> Does anyone have any experience of working with /dev/rpmsg_pruXX files 
>>>> from within Node.Js/Bonescript? I've been playing around with the 
>>>> file-duplex package and have data going into the PRU just fine, but I'm 
>>>> having an issue getting data back into my userspace program. I've got the 
>>>> stream.on('data', function(data)) picking up that a data has been pushed 
>>>> into the rpmsg file from the PRU side, but I can't get any meaningful data 
>>>> into my program. I'm sending single character ascii characters as my data.
>>>>
>>>> Am I missing the 'proper' way to do this?
>>>>
>>>> -- 
>>>> 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/666d2c51-fa4f-464b-83db-ffc7a158fecf%40googlegroups.com
>>>>  
>>>> <https://groups.google.com/d/msgid/beagleboard/666d2c51-fa4f-464b-83db-ffc7a158fecf%40googlegroups.com?utm_medium=email_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/07c3768b-461a-456f-aecd-f31600184ec7%40googlegroups.com
>>  
>> <https://groups.google.com/d/msgid/beagleboard/07c3768b-461a-456f-aecd-f31600184ec7%40googlegroups.com?utm_medium=email_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/85cd0b2a-75af-461b-ad88-5f5907f8d104%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Duplex stream for reading and writing commands to /dev/rpmsg_pru31

[Hugh Frater]

Hi Nahuel,

You can't cat the device file because linux doesn't allow concurrent access 
to the device file descriptor from more than one userspace program, and we 
need to open that device file from within our node.js program to write to 
the PRU. I do have a hardware UART looped back from the PRU into userspace, 
so I could use that for the communication back into userpace, but I would 
rather persevere and get the rpmsg subsystem working in a bi-directional 
mode.


On Thursday, 26 October 2017 21:57:02 UTC+1, Nahuel Greco wrote:
>
> doing "cat /dev/rpmsg_pruXX" shows any data? do you have a github repo 
> with a complete sample?
>
> Saludos,
> Nahuel Greco.
>
> On Mon, Oct 9, 2017 at 1:11 PM, Hugh Frater <hugh@gmail.com 
> > wrote:
>
>> Does anyone have any experience of working with /dev/rpmsg_pruXX files 
>> from within Node.Js/Bonescript? I've been playing around with the 
>> file-duplex package and have data going into the PRU just fine, but I'm 
>> having an issue getting data back into my userspace program. I've got the 
>> stream.on('data', function(data)) picking up that a data has been pushed 
>> into the rpmsg file from the PRU side, but I can't get any meaningful data 
>> into my program. I'm sending single character ascii characters as my data.
>>
>> Am I missing the 'proper' way to do this?
>>
>> -- 
>> 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/666d2c51-fa4f-464b-83db-ffc7a158fecf%40googlegroups.com
>>  
>> <https://groups.google.com/d/msgid/beagleboard/666d2c51-fa4f-464b-83db-ffc7a158fecf%40googlegroups.com?utm_medium=email_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/07c3768b-461a-456f-aecd-f31600184ec7%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Duplex stream for reading and writing commands to /dev/rpmsg_pru31

[Hugh Frater]

Does anyone have any experience of working with /dev/rpmsg_pruXX files from 
within Node.Js/Bonescript? I've been playing around with the file-duplex 
package and have data going into the PRU just fine, but I'm having an issue 
getting data back into my userspace program. I've got the stream.on('data', 
function(data)) picking up that a data has been pushed into the rpmsg file 
from the PRU side, but I can't get any meaningful data into my program. I'm 
sending single character ascii characters as my data.

Am I missing the 'proper' way to do this?

-- 
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/666d2c51-fa4f-464b-83db-ffc7a158fecf%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] pru-rproc failing on boot, working manually

[Hugh Frater]

Looks like this kind-of works now... dmesg doesn't show any errors, but a 
/dev entry for rpmsg_pru31 is only created if I manually cycle an rrmod -f 
pru_rproc, modprobe pru_rproc...

Is this because the pru's are booting before the /dev filesystem kernel 
modules are loaded?

On Thursday, 18 May 2017 15:27:34 UTC+1, RobertCNelson wrote:
>
> On Thu, May 18, 2017 at 5:54 AM, Hugh Frater <hugh@gmail.com 
> > wrote: 
> > Despite googling the heck out of this simple problem, I can't find 
> > anything... 
> > 
> > Problem is: 
> > 
> > [   34.358783]  remoteproc1: 4a338000.pru1 is available 
> > [   34.358802]  remoteproc1: Note: remoteproc is still under development 
> and 
> > considered experimental. 
> > [   34.358811]  remoteproc1: THE BINARY FORMAT IS NOT YET FINALIZED, and 
> > backward compatibility isn't yet guaranteed. 
> > [   34.359092]  remoteproc1: Direct firmware load for am335x-pru1-fw 
> failed 
> > with error -2 
> > [   34.359113]  remoteproc1: failed to load am335x-pru1-fw 
> > [   34.371827] pru-rproc 4a338000.pru1: booting the PRU core manually 
> > [   34.371857]  remoteproc1: powering up 4a338000.pru1 
> > [   34.371968]  remoteproc1: Direct firmware load for am335x-pru1-fw 
> failed 
> > with error -2 
> > [   34.371985]  remoteproc1: request_firmware failed: -2 
> > [   34.377200] pru-rproc 4a338000.pru1: rproc_boot failed 
> > [   34.493128]  remoteproc1: releasing 4a338000.pru1 
> > [   34.493310] pru-rproc: probe of 4a338000.pru1 failed with error -2 
> > 
> > The firmware file is present, it works - I just have to load it manually 
> > once I've booted with: 
> > 
> > sudo rmmod -f pru_rproc 
> > sudo modprobe pru_rproc 
> > 
> > Is there a known issue with enabling the PRU's at boot? 
>
> Thanks for the bug, the firmware wasn't getting copied to the 
> initramfs, just pushed a fix, and should hit the apt repo shortly: 
>
>
> https://github.com/rcn-ee/repos/commit/2922f56ce8ab70771944f7eb99d7fd10f8a52b6a
>  
>
> [   10.478212] ti-pruss 4a30.pruss: creating PRU cores and other 
> child platform devices 
> [   10.478410] irq: no irq domain found for 
> /ocp/pruss@4a30/intc@4a32 ! 
> [   10.499594] irq: no irq domain found for 
> /ocp/pruss@4a30/intc@4a32 ! 
> [   10.562246]  remoteproc1: 4a338000.pru1 is available 
> [   10.599505] pru-rproc 4a338000.pru1: booting the PRU core manually 
> [   10.599538]  remoteproc1: powering up 4a338000.pru1 
> [   10.599836]  remoteproc1: Booting fw image am335x-pru1-fw, size 35392 
> [   10.599913]  remoteproc1: remote processor 4a338000.pru1 is now up 
> [   10.599951] pru-rproc 4a338000.pru1: PRU rproc node 
> /ocp/pruss@4a30/pru1@4a338000 probed successfully 
> [   10.602814]  remoteproc2: 4a334000.pru0 is available 
> [   10.604856] pru-rproc 4a334000.pru0: booting the PRU core manually 
> [   10.604883]  remoteproc2: powering up 4a334000.pru0 
> [   10.605156]  remoteproc2: Booting fw image am335x-pru0-fw, size 36296 
> [   10.605225]  remoteproc2: remote processor 4a334000.pru0 is now up 
> [   10.605260] pru-rproc 4a334000.pru0: PRU rproc node 
> /ocp/pruss@4a30/pru0@4a334000 probed successfully 
>
> 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/39afa0bc-9140-4173-9f0e-fb253867ccfe%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] pru-rproc failing on boot, working manually

[Hugh Frater]

Despite googling the heck out of this simple problem, I can't find 
anything...

Problem is:

[   34.358783]  remoteproc1: 4a338000.pru1 is available
[   34.358802]  remoteproc1: Note: remoteproc is still under development 
and considered experimental.
[   34.358811]  remoteproc1: THE BINARY FORMAT IS NOT YET FINALIZED, and 
backward compatibility isn't yet guaranteed.
[   34.359092]  remoteproc1: Direct firmware load for am335x-pru1-fw failed 
with error -2
[   34.359113]  remoteproc1: failed to load am335x-pru1-fw
[   34.371827] pru-rproc 4a338000.pru1: booting the PRU core manually
[   34.371857]  remoteproc1: powering up 4a338000.pru1
[   34.371968]  remoteproc1: Direct firmware load for am335x-pru1-fw failed 
with error -2
[   34.371985]  remoteproc1: request_firmware failed: -2
[   34.377200] pru-rproc 4a338000.pru1: rproc_boot failed
[   34.493128]  remoteproc1: releasing 4a338000.pru1
[   34.493310] pru-rproc: probe of 4a338000.pru1 failed with error -2

The firmware file is present, it works - I just have to load it manually 
once I've booted with:

sudo rmmod -f pru_rproc
sudo modprobe pru_rproc

Is there a known issue with enabling the PRU's at boot?

-- 
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/677499d0-ee37-49cf-b10f-b18e6b794aa6%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Re: eQEP1 setup problems with latest debian iOT

[Hugh Frater]

It looks like we are good-to-go. Thanks for sorting this out guys :)

Hugh

On Wednesday, 10 May 2017 17:16:50 UTC+1, RobertCNelson wrote:
>
> On Wed, May 10, 2017 at 10:20 AM, Hugh Frater <hugh@gmail.com 
> > wrote: 
> > Thanks guys, I'll keep an eye on the repository and grab a copy once 
> things 
> > are finalised. 
>
> Okay all pushed out.. 
>
> run: 
>
> sudo apt update ; sudo apt upgrade 
>
> and it should show an upgrade for bb-cape-overlays 
> bb-cape-overlays_4.4.20170510.0 
>
> reboot and it should work, let us know.. 
>
> 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/7775f949-292e-48ab-aaa1-c798dd11274b%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Re: eQEP1 setup problems with latest debian iOT

[Hugh Frater]

Thanks guys, I'll keep an eye on the repository and grab a copy once things 
are finalised.

On Wednesday, 10 May 2017 15:29:22 UTC+1, RobertCNelson wrote:
>
> I just pushed another sync up: P8_31 was mising ecap. ;) 
>
>
> https://github.com/beagleboard/bb.org-overlays/commit/6197c268c1b875a2c066635413c9742b720762bc
>  
>
> I'm going to do a quick space -> tab conversion on cape-universal*.dts 
> as i need to also sync all the eqep options with 12 or so 
> univ--.dts 
>
> Regards, 
>
> On Wed, May 10, 2017 at 9:01 AM, Drew Fustini <pdp7...@gmail.com 
> > wrote: 
> > I actually ran into this too recently and have modified 
> > cape-universala-00A0.dts to enable pins P8_33 and P8_35 for eqep1: 
> > https://github.com/beagleboard/bb.org-overlays/pull/46 
> > 
> > Thanks 
> > Drew 
> > 
> > On May 10, 2017 7:29 AM, "Hugh Frater" <hugh@gmail.com > 
> wrote: 
> >> 
> >> Found it - cape-universal doesn't support eqep1, this was added to 
> >> cape-universalh 4 months ago but the code wasn't merged into 
> cape-universal. 
> >> I will look at doing this now. 
> >> 
> >> On Wednesday, 10 May 2017 10:20:56 UTC+1, Hugh Frater wrote: 
> >>> 
> >>> Anyone? 
> >>> 
> >>> On Thursday, 20 April 2017 15:01:07 UTC+1, Hugh Frater wrote: 
> >>>> 
> >>>> Following on from my earlier messages related to this, I am using 
> >>>> cape-universal now to setup and control the pins for my mechatronics 
> >>>> project. Pinmap constraints mean I need to use eQEP1 and eQEP2. eQEP2 
> on 
> >>>> P8_11, P8_12 and P8_16 is working, but I can't get config-pin to 
> setup eQEP1 
> >>>> on P8_31, P8_33 and P8_35. 
> >>>> 
> >>>> root@beaglebone:/dev# config-pin -l P8_31 
> >>>> default gpio gpio_pu gpio_pd uart qep 
> >>>> 
> >>>> You can see qep is a supported mode. 
> >>>> 
> >>>> root@beaglebone:/dev# config-pin P8_31 qep 
> >>>> bash: line 0: echo: write error: No such device 
> >>>> Cannot write pinmux file: 
> >>>> /sys/devices/platform/ocp/ocp:P8_31_pinmux/state 
> >>>> 
> >>>> And that is the error I get... 
> >>>> 
> >>>> Does anyone know what is going on here? This 2nd encoder input is the 
> >>>> last bit of the pinmux'ing puzzle I need to sort out, all the other 
> GPIO is 
> >>>> working nicely now. 
> >>>> 
> >>>> Thanks, Hugh 
> >>>> 
> >> -- 
> >> 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/2cbad167-27c6-44b0-aea2-e423cca25dd1%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...@googlegroups.com . 
> > To view this discussion on the web visit 
> > 
> https://groups.google.com/d/msgid/beagleboard/CAEf4M_D9ytOfzome-NbXGJ6oObebsBO8en_OcVW9XqiygqoVsw%40mail.gmail.com.
>  
>
> > 
> > For more options, visit https://groups.google.com/d/optout. 
>
>
>
> -- 
> 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/14a712d3-98de-42c9-8a4f-44f49c6856e1%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Re: eQEP1 setup problems with latest debian iOT

[Hugh Frater]

Found it - cape-universal doesn't support eqep1, this was added to 
cape-universalh 4 months ago but the code wasn't merged into 
cape-universal. I will look at doing this now.

On Wednesday, 10 May 2017 10:20:56 UTC+1, Hugh Frater wrote:
>
> Anyone?
>
> On Thursday, 20 April 2017 15:01:07 UTC+1, Hugh Frater wrote:
>>
>> Following on from my earlier messages related to this, I am using 
>> cape-universal now to setup and control the pins for my mechatronics 
>> project. Pinmap constraints mean I need to use eQEP1 and eQEP2. eQEP2 on 
>> P8_11, P8_12 and P8_16 is working, but I can't get config-pin to setup 
>> eQEP1 on P8_31, P8_33 and P8_35.
>>
>> root@beaglebone:/dev# config-pin -l P8_31 
>> default gpio gpio_pu gpio_pd uart qep
>>
>> You can see qep is a supported mode.
>>
>> root@beaglebone:/dev# config-pin P8_31 qep
>> bash: line 0: echo: write error: No such device
>> Cannot write pinmux file: /sys/devices/platform/ocp/ocp:P8_31_pinmux/state
>>
>> And that is the error I get...
>>
>> Does anyone know what is going on here? This 2nd encoder input is the 
>> last bit of the pinmux'ing puzzle I need to sort out, all the other GPIO is 
>> working nicely now.
>>
>> Thanks, Hugh
>>
>>

-- 
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/2cbad167-27c6-44b0-aea2-e423cca25dd1%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Re: eQEP1 setup problems with latest debian iOT

[Hugh Frater]

Anyone?

On Thursday, 20 April 2017 15:01:07 UTC+1, Hugh Frater wrote:
>
> Following on from my earlier messages related to this, I am using 
> cape-universal now to setup and control the pins for my mechatronics 
> project. Pinmap constraints mean I need to use eQEP1 and eQEP2. eQEP2 on 
> P8_11, P8_12 and P8_16 is working, but I can't get config-pin to setup 
> eQEP1 on P8_31, P8_33 and P8_35.
>
> root@beaglebone:/dev# config-pin -l P8_31 
> default gpio gpio_pu gpio_pd uart qep
>
> You can see qep is a supported mode.
>
> root@beaglebone:/dev# config-pin P8_31 qep
> bash: line 0: echo: write error: No such device
> Cannot write pinmux file: /sys/devices/platform/ocp/ocp:P8_31_pinmux/state
>
> And that is the error I get...
>
> Does anyone know what is going on here? This 2nd encoder input is the last 
> bit of the pinmux'ing puzzle I need to sort out, all the other GPIO is 
> working nicely now.
>
> Thanks, Hugh
>
>

-- 
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/83512d69-e765-4da9-a8de-8a72f2b1b57d%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] eQEP1 setup problems with latest debian iOT

[Hugh Frater]

Following on from my earlier messages related to this, I am using 
cape-universal now to setup and control the pins for my mechatronics 
project. Pinmap constraints mean I need to use eQEP1 and eQEP2. eQEP2 on 
P8_11, P8_12 and P8_16 is working, but I can't get config-pin to setup 
eQEP1 on P8_31, P8_33 and P8_35.

root@beaglebone:/dev# config-pin -l P8_31 
default gpio gpio_pu gpio_pd uart qep

You can see qep is a supported mode.

root@beaglebone:/dev# config-pin P8_31 qep
bash: line 0: echo: write error: No such device
Cannot write pinmux file: /sys/devices/platform/ocp/ocp:P8_31_pinmux/state

And that is the error I get...

Does anyone know what is going on here? This 2nd encoder input is the last 
bit of the pinmux'ing puzzle I need to sort out, all the other GPIO is 
working nicely now.

Thanks, Hugh

-- 
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/d4410432-ed85-49b0-8fe7-c1ca3c1cd76c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Re: Custom device overlay or cape-universal - decisions...

[Hugh Frater]

More for my own reference, but I'll post up my findings so far... Most of 
these errors seem to stem from my lack of understanding about how various 
things work together. Anyway:

Not using universal-cape and config-pin allows me to setup the 2x eqep's I 
need using the built in dtbo's for eqep1 and eqep2b. monitoring this from 
/sys/kernel/debug/pinctrl/44e10800.pinmux/pingroups

Perhaps I'll just use those 2 overlays to configure the eqeps and do 
everything else in a cut down version of my custom overlay...

On Wednesday, 29 March 2017 11:51:58 UTC+1, Hugh Frater wrote:
>
> Ok, looking at this again in the cold light of day - looks like config-pin 
> refuses to setup eQEP1 on P8_31 onwards... I get a:
>
> bash: line 0: echo: write error: No such device
> Cannot write pinmux file: /sys/devices/platform/ocp/ocp:P8_31_pinmux/state
>
> Error...
>
> Anyone have any ideas about this?
>
> On Tuesday, 28 March 2017 17:07:16 UTC+1, Hugh Frater wrote:
>>
>> Hi everyone, I'm building a custom piece of mechatronics as part of my 
>> day job. We have a custom interface cape laid out (it doesn't have an 
>> eeprom) and I've mapped out the 16 lines we need to go back to the BBB. 
>> I've written a custom device tree for these lines which compiles with dtc 
>> fine, no errors. I've configured uEnv.txt to not load any other overlays, 
>> everything we don't need is disabled. As a result of the universal-cape not 
>> being loaded, I can't use config-pin to query if my pins have been setup 
>> correctly through my device tree.
>>
>> Should I ditch my device tree based setup, and use the universal-cape 
>> along with a script to configure my pimuxing? Would this approach be easier 
>> to debug/verify?
>>
>> Thanks in advance, Hugh
>>
>

-- 
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/c2fe41b9-3cf0-49d6-b49c-8a6551bb131f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Re: Custom device overlay or cape-universal - decisions...

[Hugh Frater]

Ok, looking at this again in the cold light of day - looks like config-pin 
refuses to setup eQEP1 on P8_31 onwards... I get a:

bash: line 0: echo: write error: No such device
Cannot write pinmux file: /sys/devices/platform/ocp/ocp:P8_31_pinmux/state

Error...

Anyone have any ideas about this?

On Tuesday, 28 March 2017 17:07:16 UTC+1, Hugh Frater wrote:
>
> Hi everyone, I'm building a custom piece of mechatronics as part of my day 
> job. We have a custom interface cape laid out (it doesn't have an eeprom) 
> and I've mapped out the 16 lines we need to go back to the BBB. I've 
> written a custom device tree for these lines which compiles with dtc fine, 
> no errors. I've configured uEnv.txt to not load any other overlays, 
> everything we don't need is disabled. As a result of the universal-cape not 
> being loaded, I can't use config-pin to query if my pins have been setup 
> correctly through my device tree.
>
> Should I ditch my device tree based setup, and use the universal-cape 
> along with a script to configure my pimuxing? Would this approach be easier 
> to debug/verify?
>
> Thanks in advance, Hugh
>

-- 
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/7fe54696-f8c3-4191-ba0f-36b4ee6a6b74%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Custom device overlay or cape-universal - decisions...

[Hugh Frater]

Hi everyone, I'm building a custom piece of mechatronics as part of my day 
job. We have a custom interface cape laid out (it doesn't have an eeprom) 
and I've mapped out the 16 lines we need to go back to the BBB. I've 
written a custom device tree for these lines which compiles with dtc fine, 
no errors. I've configured uEnv.txt to not load any other overlays, 
everything we don't need is disabled. As a result of the universal-cape not 
being loaded, I can't use config-pin to query if my pins have been setup 
correctly through my device tree.

Should I ditch my device tree based setup, and use the universal-cape along 
with a script to configure my pimuxing? Would this approach be easier to 
debug/verify?

Thanks in advance, Hugh

-- 
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/e564a1f5-5efd-4832-8365-96817dede943%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Re: eQEP on 4.4.19-ti-r41

[Hugh Frater]

I was getting weird values - it turns out I didn't correctly understand how 
to use pin-config & the universal overlay. When I configured the pins 
correctly, everything works.

On Friday, 3 February 2017 21:18:35 UTC, Drew Fustini wrote:
>
> On Fri, Feb 3, 2017 at 6:02 AM, Hugh Frater <hugh@gmail.com 
> > wrote: 
> > Did you ever get any further with this? I'm struggling with eQEP on 
> 4.4.36 - 
> > but for different reasons 
>
> Are you getting an error? 
>
> I am able to use eQEP ok with a rotary encoder on 4.4 kernel: 
>
> # uname -a 
> Linux beaglebone 4.4.44-ti-r85 #1 SMP Fri Jan 27 22:16:52 
>
> # config-pin p8.11 qep 
> # config-pin p8.12 qep 
>
> # cat /sys/devices/platform/ocp/48304000.epwmss/48304180.eqep/position 
> -2 
>  
> # cat /sys/devices/platform/ocp/48304000.epwmss/48304180.eqep/position 
> 18 
>
> Here are results with 4.1, 4.4 and 4.9: 
> https://gist.github.com/pdp7/1db356e758e9ff0c1e570e6ee362c673 
>
>
> -drew 
>

-- 
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/1276f9da-9966-4171-a03c-4915d94e8e6b%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] eQEP not reading meaningful values

[Hugh Frater]

I got it to work properly in 4.4.x - using the universal cape and running 
config-pin P8_11 qep & config-pin P8_12 qep

On Friday, 3 February 2017 16:55:42 UTC, abhilash h wrote:
>
> For sure it will work.
> On Fri, 3 Feb 2017 at 9:33 PM, Hugh Frater <hugh@gmail.com 
> > wrote:
>
>> I'll give 7.9 a go and let you know my findings, thanks.
>>
>>
>> On Friday, 3 February 2017 13:40:05 UTC, abhilash h wrote:
>>
>>> I had used debian 7.9 
>>>
>> On Fri, 3 Feb 2017 at 7:05 PM, Hugh Frater <hugh@gmail.com> wrote:
>>>
>> Thanks, I'm currently trying to downgrade to a 3.8 revision, 1st attempt 
>>>> resulted in a 'won't boot, all the LEDs are on' so I guess I missed a step.
>>>>
>>>>
>>>> On Friday, 3 February 2017 13:31:00 UTC, abhilash h wrote:
>>>>
>>>>> I had used debian . And it worked with busybox rfs and 3.8 kernel also 
>>>>> .
>>>>>
>>>> On Fri, 3 Feb 2017 at 6:20 PM, Hugh Frater <hugh@gmail.com> wrote:
>>>>>
>>>> Hi Abhilash, 
>>>>>>
>>>>>> That's interesting, I will try and downgrade. May I ask what image 
>>>>>> you are using now (Angstrom, Debian etc)?
>>>>>>
>>>>>> Hugh
>>>>>>
>>>>>>
>>>>>> On Friday, 3 February 2017 12:36:34 UTC, abhilash h wrote:
>>>>>>
>>>>>>> Hi hugh,  
>>>>>>>
>>>>>>> It never worked for me in 4.x kernel. I used to get same values. So 
>>>>>>> i swutched back to 3.8 kernel . 
>>>>>>>
>>>>>> On Fri, 3 Feb 2017 at 5:47 PM, Hugh Frater <hugh@gmail.com> 
>>>>>>> wrote:
>>>>>>>
>>>>>> Hi, I'm getting started on a control system that needs to read 2x 
>>>>>>>> quadrature encoders. One is a 1000 line, the other a 2000 line, but 
>>>>>>>> that is 
>>>>>>>> really immaterial. I have the physical interface sorted (one needs a 
>>>>>>>> 26lv32 
>>>>>>>> to glue it to the BBB, the other is open collector), and the traces 
>>>>>>>> look 
>>>>>>>> good on the scope.
>>>>>>>>
>>>>>>>> I'm running Jessie IOT with 4.4.36, I have disabled hdmi and 
>>>>>>>> universal cape. I can load Nathaniel Lewis' overlays (supplied with 
>>>>>>>> the 
>>>>>>>> clean install of Jessie) just fine with no errors in dmesg.
>>>>>>>>
>>>>>>>> However when I 'cat position' in each of the relevant sys entries 
>>>>>>>> (having moved my encoder A/B lines to the relevant pins each time), I 
>>>>>>>> get a 
>>>>>>>> changing value but it isn't meaningful. Am I missing something, or is 
>>>>>>>> it 
>>>>>>>> more likely that I've blown up the inputs? I did power on the servo 
>>>>>>>> drive 
>>>>>>>> (that was connected to the 26lv32 breakout board) by accident when the 
>>>>>>>> BBB 
>>>>>>>> wasn't powered up.
>>>>>>>>
>>>>>>>> I've tested with a simple 24ppr 'audio style' encoder and again 
>>>>>>>> don't get meaningful results.
>>>>>>>>
>>>>>>>> Do I have to mess about with config-pin for each of the eQEP 
>>>>>>>> inputs, or should loading the relevant dtbo file for the eQEP module 
>>>>>>>> (0, 1 
>>>>>>>> 2 etc) set up the pins for me?
>>>>>>>>
>>>>>>>> There's so much old documentation floating about it's hard to 
>>>>>>>> identify what is current and what is no longer relevant now that the 
>>>>>>>> universal-cape is in existence.
>>>>>>>>
>>>>>>>> Regards, Hugh
>>>>>>>>
>>>>>>>> -- 
>>>>>>>> For more options, visit http://beagleboard.org/discuss
>>>>>>>> --- 
>>>>>>>> You received this message because you are subscribed to the Google 
>>>>>>>> Groups "BeagleBoard" group.
>>&

Re: [beagleboard] eQEP not reading meaningful values

[Hugh Frater]

I'll give 7.9 a go and let you know my findings, thanks.

On Friday, 3 February 2017 13:40:05 UTC, abhilash h wrote:
>
> I had used debian 7.9 
> On Fri, 3 Feb 2017 at 7:05 PM, Hugh Frater <hugh@gmail.com 
> > wrote:
>
>> Thanks, I'm currently trying to downgrade to a 3.8 revision, 1st attempt 
>> resulted in a 'won't boot, all the LEDs are on' so I guess I missed a step.
>>
>>
>> On Friday, 3 February 2017 13:31:00 UTC, abhilash h wrote:
>>
>>> I had used debian . And it worked with busybox rfs and 3.8 kernel also .
>>>
>> On Fri, 3 Feb 2017 at 6:20 PM, Hugh Frater <hugh@gmail.com> wrote:
>>>
>> Hi Abhilash, 
>>>>
>>>> That's interesting, I will try and downgrade. May I ask what image you 
>>>> are using now (Angstrom, Debian etc)?
>>>>
>>>> Hugh
>>>>
>>>>
>>>> On Friday, 3 February 2017 12:36:34 UTC, abhilash h wrote:
>>>>
>>>>> Hi hugh,  
>>>>>
>>>>> It never worked for me in 4.x kernel. I used to get same values. So i 
>>>>> swutched back to 3.8 kernel . 
>>>>>
>>>> On Fri, 3 Feb 2017 at 5:47 PM, Hugh Frater <hugh@gmail.com> wrote:
>>>>>
>>>> Hi, I'm getting started on a control system that needs to read 2x 
>>>>>> quadrature encoders. One is a 1000 line, the other a 2000 line, but that 
>>>>>> is 
>>>>>> really immaterial. I have the physical interface sorted (one needs a 
>>>>>> 26lv32 
>>>>>> to glue it to the BBB, the other is open collector), and the traces look 
>>>>>> good on the scope.
>>>>>>
>>>>>> I'm running Jessie IOT with 4.4.36, I have disabled hdmi and 
>>>>>> universal cape. I can load Nathaniel Lewis' overlays (supplied with the 
>>>>>> clean install of Jessie) just fine with no errors in dmesg.
>>>>>>
>>>>>> However when I 'cat position' in each of the relevant sys entries 
>>>>>> (having moved my encoder A/B lines to the relevant pins each time), I 
>>>>>> get a 
>>>>>> changing value but it isn't meaningful. Am I missing something, or is it 
>>>>>> more likely that I've blown up the inputs? I did power on the servo 
>>>>>> drive 
>>>>>> (that was connected to the 26lv32 breakout board) by accident when the 
>>>>>> BBB 
>>>>>> wasn't powered up.
>>>>>>
>>>>>> I've tested with a simple 24ppr 'audio style' encoder and again don't 
>>>>>> get meaningful results.
>>>>>>
>>>>>> Do I have to mess about with config-pin for each of the eQEP inputs, 
>>>>>> or should loading the relevant dtbo file for the eQEP module (0, 1 2 
>>>>>> etc) 
>>>>>> set up the pins for me?
>>>>>>
>>>>>> There's so much old documentation floating about it's hard to 
>>>>>> identify what is current and what is no longer relevant now that the 
>>>>>> universal-cape is in existence.
>>>>>>
>>>>>> Regards, Hugh
>>>>>>
>>>>>> -- 
>>>>>> 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/c28fc73b-b2f4-4e73-8318-fd37599ef3b6%40googlegroups.com
>>>>>>  
>>>>>> <https://groups.google.com/d/msgid/beagleboard/c28fc73b-b2f4-4e73-8318-fd37599ef3b6%40googlegroups.com?utm_medium=email_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 rec

Re: [beagleboard] eQEP not reading meaningful values

[Hugh Frater]

Thanks, I'm currently trying to downgrade to a 3.8 revision, 1st attempt 
resulted in a 'won't boot, all the LEDs are on' so I guess I missed a step.

On Friday, 3 February 2017 13:31:00 UTC, abhilash h wrote:
>
> I had used debian . And it worked with busybox rfs and 3.8 kernel also .
> On Fri, 3 Feb 2017 at 6:20 PM, Hugh Frater <hugh@gmail.com 
> > wrote:
>
>> Hi Abhilash, 
>>
>> That's interesting, I will try and downgrade. May I ask what image you 
>> are using now (Angstrom, Debian etc)?
>>
>> Hugh
>>
>>
>> On Friday, 3 February 2017 12:36:34 UTC, abhilash h wrote:
>>
>>> Hi hugh,  
>>>
>>> It never worked for me in 4.x kernel. I used to get same values. So i 
>>> swutched back to 3.8 kernel . 
>>>
>> On Fri, 3 Feb 2017 at 5:47 PM, Hugh Frater <hugh@gmail.com> wrote:
>>>
>> Hi, I'm getting started on a control system that needs to read 2x 
>>>> quadrature encoders. One is a 1000 line, the other a 2000 line, but that 
>>>> is 
>>>> really immaterial. I have the physical interface sorted (one needs a 
>>>> 26lv32 
>>>> to glue it to the BBB, the other is open collector), and the traces look 
>>>> good on the scope.
>>>>
>>>> I'm running Jessie IOT with 4.4.36, I have disabled hdmi and universal 
>>>> cape. I can load Nathaniel Lewis' overlays (supplied with the clean 
>>>> install 
>>>> of Jessie) just fine with no errors in dmesg.
>>>>
>>>> However when I 'cat position' in each of the relevant sys entries 
>>>> (having moved my encoder A/B lines to the relevant pins each time), I get 
>>>> a 
>>>> changing value but it isn't meaningful. Am I missing something, or is it 
>>>> more likely that I've blown up the inputs? I did power on the servo drive 
>>>> (that was connected to the 26lv32 breakout board) by accident when the BBB 
>>>> wasn't powered up.
>>>>
>>>> I've tested with a simple 24ppr 'audio style' encoder and again don't 
>>>> get meaningful results.
>>>>
>>>> Do I have to mess about with config-pin for each of the eQEP inputs, or 
>>>> should loading the relevant dtbo file for the eQEP module (0, 1 2 etc) set 
>>>> up the pins for me?
>>>>
>>>> There's so much old documentation floating about it's hard to identify 
>>>> what is current and what is no longer relevant now that the universal-cape 
>>>> is in existence.
>>>>
>>>> Regards, Hugh
>>>>
>>>> -- 
>>>> 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/c28fc73b-b2f4-4e73-8318-fd37599ef3b6%40googlegroups.com
>>>>  
>>>> <https://groups.google.com/d/msgid/beagleboard/c28fc73b-b2f4-4e73-8318-fd37599ef3b6%40googlegroups.com?utm_medium=email_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/3e6b19d3-1c4a-4fea-9833-0d20fa29071a%40googlegroups.com
>>  
>> <https://groups.google.com/d/msgid/beagleboard/3e6b19d3-1c4a-4fea-9833-0d20fa29071a%40googlegroups.com?utm_medium=email_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/39682a43-a9ad-42a6-9906-751c77e102bd%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] eQEP not reading meaningful values

[Hugh Frater]

Hi Abhilash, 

That's interesting, I will try and downgrade. May I ask what image you are 
using now (Angstrom, Debian etc)?

Hugh

On Friday, 3 February 2017 12:36:34 UTC, abhilash h wrote:
>
> Hi hugh,  
>
> It never worked for me in 4.x kernel. I used to get same values. So i 
> swutched back to 3.8 kernel . 
>
> On Fri, 3 Feb 2017 at 5:47 PM, Hugh Frater <hugh@gmail.com 
> > wrote:
>
>> Hi, I'm getting started on a control system that needs to read 2x 
>> quadrature encoders. One is a 1000 line, the other a 2000 line, but that is 
>> really immaterial. I have the physical interface sorted (one needs a 26lv32 
>> to glue it to the BBB, the other is open collector), and the traces look 
>> good on the scope.
>>
>> I'm running Jessie IOT with 4.4.36, I have disabled hdmi and universal 
>> cape. I can load Nathaniel Lewis' overlays (supplied with the clean install 
>> of Jessie) just fine with no errors in dmesg.
>>
>> However when I 'cat position' in each of the relevant sys entries (having 
>> moved my encoder A/B lines to the relevant pins each time), I get a 
>> changing value but it isn't meaningful. Am I missing something, or is it 
>> more likely that I've blown up the inputs? I did power on the servo drive 
>> (that was connected to the 26lv32 breakout board) by accident when the BBB 
>> wasn't powered up.
>>
>> I've tested with a simple 24ppr 'audio style' encoder and again don't get 
>> meaningful results.
>>
>> Do I have to mess about with config-pin for each of the eQEP inputs, or 
>> should loading the relevant dtbo file for the eQEP module (0, 1 2 etc) set 
>> up the pins for me?
>>
>> There's so much old documentation floating about it's hard to identify 
>> what is current and what is no longer relevant now that the universal-cape 
>> is in existence.
>>
>> Regards, Hugh
>>
>> -- 
>> 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/c28fc73b-b2f4-4e73-8318-fd37599ef3b6%40googlegroups.com
>>  
>> <https://groups.google.com/d/msgid/beagleboard/c28fc73b-b2f4-4e73-8318-fd37599ef3b6%40googlegroups.com?utm_medium=email_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/3e6b19d3-1c4a-4fea-9833-0d20fa29071a%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] eQEP not reading meaningful values

[Hugh Frater]

Hi, I'm getting started on a control system that needs to read 2x 
quadrature encoders. One is a 1000 line, the other a 2000 line, but that is 
really immaterial. I have the physical interface sorted (one needs a 26lv32 
to glue it to the BBB, the other is open collector), and the traces look 
good on the scope.

I'm running Jessie IOT with 4.4.36, I have disabled hdmi and universal 
cape. I can load Nathaniel Lewis' overlays (supplied with the clean install 
of Jessie) just fine with no errors in dmesg.

However when I 'cat position' in each of the relevant sys entries (having 
moved my encoder A/B lines to the relevant pins each time), I get a 
changing value but it isn't meaningful. Am I missing something, or is it 
more likely that I've blown up the inputs? I did power on the servo drive 
(that was connected to the 26lv32 breakout board) by accident when the BBB 
wasn't powered up.

I've tested with a simple 24ppr 'audio style' encoder and again don't get 
meaningful results.

Do I have to mess about with config-pin for each of the eQEP inputs, or 
should loading the relevant dtbo file for the eQEP module (0, 1 2 etc) set 
up the pins for me?

There's so much old documentation floating about it's hard to identify what 
is current and what is no longer relevant now that the universal-cape is in 
existence.

Regards, Hugh

-- 
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/c28fc73b-b2f4-4e73-8318-fd37599ef3b6%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Re: eQEP on 4.4.19-ti-r41

[Hugh Frater]

Did you ever get any further with this? I'm struggling with eQEP on 4.4.36 
- but for different reasons

Hugh

On Wednesday, 14 September 2016 21:22:06 UTC+1, Mark A. Yoder wrote:
>
> Hi:
>   I'm running BeagleBoard.org Debian Image 2016-08-28 which is running 
> the 4.4.19-ti-r41 kernel.  I've disabled the HDMI (audio and video) and 
> want to use the eQEPs.
>
> *ls /lib/firmware/ | grep -i eqep*
> bone_eqep0-00A0.dtbo
> bone_eqep1-00A0.dtbo
> bone_eqep2-00A0.dtbo
> bone_eqep2b-00A0.dtbo
> PyBBIO-eqep0-00A0.dtbo
> PyBBIO-eqep1-00A0.dtbo
> PyBBIO-eqep2-00A0.dtbo
> PyBBIO-eqep2b-00A0.dtbo
>
> shows I have several options.  However none seem to work.
>
> *echo bone_eqep1 > $SLOTS* 
> -bash: echo: write error: File exists
> *dmesg*
> [Sep14 16:15] bone_capemgr bone_capemgr: part_number 'bone_eqep1', version 
> 'N/A'
> [  +0.75] bone_capemgr bone_capemgr: slot #9: override
> [  +0.45] bone_capemgr bone_capemgr: Using override eeprom data at 
> slot 9
> [  +0.46] bone_capemgr bone_capemgr: slot #9: 'Override Board 
> Name,00A0,Override Manuf,bone_eqep1'
> [  +0.012094] bone_capemgr bone_capemgr: slot #9: bone_eqep1 conflict 
> P8.35 (#4:univ-emmc)
> [  +0.008573] bone_capemgr bone_capemgr: slot #9: Failed verification
>
> So it looking like the emmc overlay is controlling the pin.
>
> What's the correct way to get emmc overlay to let me use the pin?
>
> Do I have to get dtb-4.4-ti and edit am335x-boneblack-emmc-overlay.dtb? 
>  If so, what do I edit?
>
> I'm looking for a general approach that I can apply to other pins I want 
> to control.
>
> Thanks...
>
> --Mark
>

-- 
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/e972eae7-97c1-4eef-b63a-1cdcd3d3dcba%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.