[beagleboard] Re: does the BBGW wifi hardware have a power saving mode?

2016-11-08 Thread Stephane Charette 

>
> Yes WL18xx does have a power save mode which is on by default. It can be 
> disabled with
> echo 0 > /sys/kernel/debug/ieee80211/phy0/wlcore/sleep_auth
>

That seems to have made a difference, Iain.  My BBGW doesn't do it every 
time, so I cannot yet say for certain, but so far today the 2 times the 
BBGW boots up with those error messages and a non-working wlan0, I login 
through the serial console interface, run that command, and everything then 
starts working again.

The default value for /sys/kernel/debug/ieee80211/phy0/wlcore/sleep_auth 
seems to be 2. I eventually found WL1271_PSM_ELP = 2 (power saving move, 
extreme low power) in acx.h.  If anyone else is curious, the possible 
values 0, 1, and 2 are defined as:

/* Active mode */
WL1271_PSM_CAM = 0,

/* Power save mode */
WL1271_PSM_PS = 1,

/* Extreme low power */
WL1271_PSM_ELP = 2

Stéphane

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/34dc5b8d-00d8-4ae6-81e1-0e130d9fd068%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] hostapd on BBGW

2016-11-08 Thread Stephane Charette 

>
> In the seeed-iot image it's:  wificonfig.service


Thanks, Robert, that got me where I needed.  For the sake of Google 
searches in the future, if anyone else is looking to change their SSID, see 
"options.ssid" in the file 
/usr/local/lib/node_modules/wificonfig/lib/wifi.js.

Stéphane

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/3074a14f-f643-4103-bb4f-ee791470ed41%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Re: Beaglebone Black PRU Troubles

2016-11-08 Thread Greg 
The problem is common to both boards, one with kernel a few months old, and 
another newer one:

Older:
4.4.12-ti-r31
Newer:
4.4.27-ti-r62

The older board I have used for many hours of experimentation with the 
Remoteproc/PRUs, and never had a problem.
I never noticed the firmwares were not starting at boot!

Looking at dmesg, these lines stand out:

[4.746736] ti-pruss 4a30.pruss: creating PRU cores and other child 
platform devices
[4.747946] irq: no irq domain found for 
/ocp/pruss@4a30/intc@4a32 !
[4.748539] irq: no irq domain found for 
/ocp/pruss@4a30/intc@4a32 !

And then a bunch of lines indicating that the firmwares did not load and 
start, here are the lines for PRU0:

[4.796962]  remoteproc1: 4a334000.pru0 is available
[4.796990]  remoteproc1: Note: remoteproc is still under development 
and considered experimental.
[4.796999]  remoteproc1: THE BINARY FORMAT IS NOT YET FINALIZED, and 
backward compatibility isn't yet guaranteed.
[4.797306]  remoteproc1: Direct firmware load for am335x-pru0-fw failed 
with error -2
[4.797326]  remoteproc1: failed to load am335x-pru0-fw
[4.832461] pru-rproc 4a334000.pru0: booting the PRU core manually
[4.832497]  remoteproc1: powering up 4a334000.pru0
[4.832614]  remoteproc1: Direct firmware load for am335x-pru0-fw failed 
with error -2
[4.832630]  remoteproc1: request_firmware failed: -2
[4.837857] pru-rproc 4a334000.pru0: rproc_boot failed
[4.959415]  remoteproc1: releasing 4a334000.pru0
[4.959590] pru-rproc: probe of 4a334000.pru0 failed with error -2

There was a change a while back from "mailboxes" to system interrupts. 
 Hm...

But even after all of this, the PRUs can be started up using either 
modprobe pru_rproc, or commands to sysfs:

echo "4a334000.pru0" > /sys/bus/platform/drivers/pru-rproc/bind
echo "4a338000.pru1" > /sys/bus/platform/drivers/pru-rproc/bind

So the above commands could be put in .profile or other start-up sequence, 
but still would like to root cause the kernel log messages.

Regards,
Greg




-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/42ff3c96-7f72-4be4-8a52-9d5911a91886%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] hostapd on BBGW

2016-11-08 Thread Robert Nelson 
On Tue, Nov 8, 2016 at 4:10 PM, Stephane Charette
 wrote:
> I'm still trying to figure out where the WIFI SSID is set on the BBGW so I
> can customize it.  I see this process running:
>
> hostapd -B SoftAp0-hostapd.conf
>
> The -B means "run in the background".  So that leaves the
> SoftAp0-hostapd.conf file.  Where is this configuration file?  From what I
> can see on my BBGW, such a file does not exist.

In the seeed-iot image it's:

wificonfig.service

https://github.com/Pillar1989/wifidog-server

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/CAOCHtYh0vgABDoCFYQ6Adg840PX49XsZxxihG1QtzPKMEn6q1A%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] hostapd on BBGW

2016-11-08 Thread Stephane Charette 
I'm still trying to figure out where the WIFI SSID is set on the BBGW so I 
can customize it.  I see this process running:

hostapd -B SoftAp0-hostapd.conf

The -B means "run in the background".  So that leaves the 
SoftAp0-hostapd.conf file.  Where is this configuration file?  From what I 
can see on my BBGW, such a file does not exist.

Stéphane

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/aa3c2b0e-ab8e-4699-939c-291622fb8dcc%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Re: Beaglebone Black PRU Troubles

2016-11-08 Thread William Hermans 
On Tue, Nov 8, 2016 at 11:08 AM, Greg  wrote:

> I think I know exactly what is wrong.  You need to activate the Remoteproc
> PRU framework.  This is no longer active by default.
> Robert Nelson's script which is available via Github repository will fix
> the problem.
>
> I have been working on detailed documentation of the entire process to
> activate the framework and set up the C compiler:
>
> https://github.com/Greg-R/pruadc1
>
> More specifically, look at this PDF file:
>
> https://github.com/Greg-R/pruadc1/blob/master/doc/PRUADC1latex/PRUADC1.pdf
>
> Go to the chapter "Setting Up the Remoteproc PRU and Compiler on the
> Beaglebone Green".
>
> Now, the chapter is not completely finished.  I am still seeing a problem
> with the configuration
> At boot, the PRU firmwares are not starting correctly.  I don't understand
> why this is.
>

Probably because the device tree file you're trying to load at boot is not
in the initramfs.

>
> However, you can do this:
>
> rmmod pru_rproc
>
> and then
>
> modprobe pru_rproc
>
> The firmwares will start running.
> More investigation, required, but at least there is some path to getting
> things working for now.
>
> I will do some more work on this later today.
>
> Regards,
> Greg
>
>
> On Tuesday, November 8, 2016 at 11:42:25 AM UTC-5, Zach B wrote:
>>
>> I have spent a solid 12 hours trying to get the PRU's on the beaglebone
>> to work. So far I seem to be completely stuck at the getting the device
>> overlay to work as well as enabling the remoteproc. I have tried to piece
>> together all of the information I have found on the internet but it is
>> either out of date or extremely fragmented. I can't seem to find a current
>> working example or I hit a wall when following along as said previously.
>>
>> --
> 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/ce0bf666-a685-4e22-adc6-6bab07d7b73d%40googlegroups.com
> 
> .
>
> For more options, visit https://groups.google.com/d/optout.
>

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/CALHSORqefaVX98Fnzh2ZqYWMXMvbKzwLHsop%2Bfk8vPG5f8igvQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Long booting time when no network cable is plugged

2016-11-08 Thread David Goodenough 
Have you configured it?  It needs to know which interfaces it controls, and you 
need to make 
sure that these interfaces are not auto-started.  Have you read the README in 
/usr/share/
doc/ifplugd ?

David

On Tuesday, 8 November 2016 19:04:31 GMT Paul Plankton wrote:


Simple installation of ifplugd does not do the job - what else has to be done?




2016-10-26 12:22 GMT+02:00 David Goodenough 
:


There is a package called ifplugd which monitors the connection and only 
activates the 
connection when a cable is plugged into the socket and the electrical 
connection to another 
system (or router/switch) is established.
 
David
 
On Tuesday, 25 October 2016 22:08:51 BST Paul Plankton wrote:


But this disables the network interface permanently, not only when no cable is 
plugged?


On Tue, Oct 25, 2016 at 3:46 PM, Paul Plankton <_paul.pl...@gmail.com_> wrote: 
> Hi, > > I'm 
running a BBG with Ubuntu on external microSD-card (the one from > http://
www.elinux.org/BeagleBoardUbuntu#Ubuntu_.2816.04.1.29[2] ). > > When no network 
cable 
is connected to the BBG, the boot time is quite long, > it comes up with a text 
> > A start job 
is running for Raise network interfaces (39s / 5min 2s) > > > The first time 
value is counting 
and it really takes minutes... > > How can I avoid this delay and let it 
continue without 
network when no cable > is plugged? 

edit /etc/network/interfaces 

and comment out the two  "eth0" lines.. 

Regards, 

-- Robert Nelson 

https://rcn-ee.com/[3] 


-- For more options, visit http://beagleboard.org/discuss[4]
beagleboard+unsubscr...@googlegroups.com[5].To view this discussion on the web 
visit 
https://groups.google.com/d/msgid/beagleboard/2df6ea22-7d5f-4c39-8650-2d7520c7e32e
%40googlegroups.com[6].For more options, visit 
https://groups.google.com/d/optout[7].




-- For more options, visit http://beagleboard.org/discuss[4]
https://groups.google.com/d/topic/beagleboard/HnnW7ThaE-s/unsubscribe[8].To 
unsubscribe from this group and all its topics, send an email to beagleboard
+unsubscr...@googlegroups.com[5].To view this discussion on the web visit 
https://
groups.google.com/d/msgid/beagleboard/16604528.pWpmt2WTRT%40stargate[9].

https://groups.google.com/d/optout[7].




-- For more options, visit http://beagleboard.org/discuss[4]
beagleboard+unsubscr...@googlegroups.com[5].To view this discussion on the web 
visit 
https://groups.google.com/d/msgid/beagleboard/CAMCbi43P9HX
%3DvVuxKz_5Sdp_DgqXjNUw7DAUcdc6VCne8UxdUA%40mail.gmail.com[10].For more 
options, visit https://groups.google.com/d/optout[7].






[1] mailto:david.goodeno...@linkchoose.co.uk
[2] http://www.elinux.org/BeagleBoardUbuntu#Ubuntu_.2816.04.1.29
[3] https://rcn-ee.com/
[4] http://beagleboard.org/discuss
[5] mailto:beagleboard+unsubscr...@googlegroups.com
[6] https://groups.google.com/d/msgid/beagleboard/
2df6ea22-7d5f-4c39-8650-2d7520c7e32e%40googlegroups.com?
utm_medium=email&utm_source=footer
[7] https://groups.google.com/d/optout
[8] https://groups.google.com/d/topic/beagleboard/HnnW7ThaE-s/unsubscribe
[9] 
https://groups.google.com/d/msgid/beagleboard/16604528.pWpmt2WTRT%40stargate?
utm_medium=email&utm_source=footer
[10] https://groups.google.com/d/msgid/beagleboard/CAMCbi43P9HX
%3DvVuxKz_5Sdp_DgqXjNUw7DAUcdc6VCne8UxdUA%40mail.gmail.com?
utm_medium=email&utm_source=footer

-- 
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/2979749.jyg3ByRqtX%40stargate.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Use PWM and UART at the same time

2016-11-08 Thread Theodosis Ntegiannakis 
Thank you again!

On Tuesday, November 8, 2016 at 1:25:21 AM UTC+2, William Hermans wrote:
>
>
>
> On Mon, Nov 7, 2016 at 3:56 PM, Theodosis Ntegiannakis <
> tntegi...@gmail.com > wrote:
>
>> I tried twice to implement my own overlay but I gave up because I had a 
>> significant lack of knowledge at this point.
>>
>> Finally i used cape-universala (in which pwm works fine) and enabled 
>> uart2 and uart4 pins by using config-pin.
>> Now it works! (hope nothing else has broken!)
>>
>> Thank you very much!
>>
>>
>> one last question:
>> pins enabled using config-pin command are enabled until reboot.
>>
>> how can i keep these pins after reboot?
>>
>>
>> You create a systemd service, or use rc.local, and put the "commands" in 
> there. Which will be applied 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/e44164d9-1708-49b1-a2dc-e239b43ff20f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Re: No MLO-file on newer BBG's?

2016-11-08 Thread Robert Nelson 
On Tue, Nov 8, 2016 at 12:24 PM, Paul Plankton  wrote:
> Hi,
>
> I again played yround a bit with this. My first try was an operation
>
> sudo cp /dev/random /dev/mmcblk1
>
> From my understanding this should erase the onboard MMC completely together
> with all boot data. Nevertheless when I try to boot from a board erased in
> this way, there is still a u-boot coming up with a bunch of messages.
> Finally it of course fails because it can not find an operating system - but
> where does this boot sequence come from? It can't be on the on-board MMC and
> a SD-card is not inserted!

Or just:

sudo dd if=/dev/zero of=/dev/mmcblk1 bs=1M count=10

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/CAOCHtYg5p5J8X6rukH7h2KQK%3DKjE7YVNxM3XnCTiEnmYN1%2B_fg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Re: No MLO-file on newer BBG's?

2016-11-08 Thread Paul Plankton 
Hi,

I again played yround a bit with this. My first try was an operation

sudo cp /dev/random /dev/mmcblk1

>From my understanding this should erase the onboard MMC completely together
with all boot data. Nevertheless when I try to boot from a board erased in
this way, there is still a u-boot coming up with a bunch of messages.
Finally it of course fails because it can not find an operating system -
but where does this boot sequence come from? It can't be on the on-board
MMC and a SD-card is not inserted!

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/CAMCbi42BicxkZbtAh2-04LnSPaYuxWhkEGKOQAxosBHg9oGtxA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Beaglebone Black PRU Troubles

2016-11-08 Thread Zach B 
Thanks Robert! I'll give that a try when I get a chance later today. Will 
that possibly also solve my issue with my device overlay not applying to 
the slot. Everything I have looked at says that there should be no error 
messages when applying the overlay but that's all I get.

Zach

On Tuesday, November 8, 2016 at 11:50:35 AM UTC-5, RobertCNelson wrote:
>
> On Tue, Nov 8, 2016 at 10:39 AM, Zach B > 
> wrote: 
> > I have spent a solid 12 hours trying to get the PRU's on the beaglebone 
> to 
> > work. So far I seem to be completely stuck at the getting the device 
> overlay 
> > to work as well as enabling the remoteproc. I have tried to piece 
> together 
> > all of the information I have found on the internet but it is either out 
> of 
> > date or extremely fragmented. I can't seem to find a current working 
> example 
> > or I hit a wall when following along as said previously. 
> > 
> > Setup/Environment 
> > I have updated the kernel on the beaglebone followed by multiple 
> "updates", 
> > "upgrades" and "dist-upgrades". As far as I can tell I am using the most 
> > recent version of everything. 
> > 
> > Beaglebone Black 
> > Debian 8.6 
> > kernel 4.4.30-ti-r64 
> > dtc 1.4.1 
> > 
> > Sample Code 
> > Device Overlay File [PRU-GPIO-BLINK-00A0.dts]: 
> > 
> > // Setup file for basic PRU GPIO Blinking LED 
> > 
> > /dts-v1/; 
> > /plugin/; 
> > 
> > / { 
> > compatible = "ti,beaglebone", "ti,beaglebone-black"; 
> > 
> > part-number = "PRU-GPIO-BLINK"; 
> > version = "00A0"; 
> > 
> > // This overlay uses the following resources 
> > exclusive-use = "P8.12"; 
> > 
> > fragment@0 { 
> > target = <&am33xx_pinmux>; 
> > __overlay__ { 
> > 
> > gpio_pins: pinmux_gpio_pins { 
> > pinctrl-single,pins = < 
> > 0x034   0x06 
> > >; 
> > }; 
> > }; 
> > }; 
> > 
> > fragment@1 { 
> > target = <&pruss>; 
> > __overlay__ { 
> > status = "okay"; 
> > pinctrl-names = "default"; 
> > pinctrl-0 = <&gpio_pins>; 
> > }; 
> > }; 
> > }; 
> > 
> > 
> > 
> > The above code compiles using: 
> > root@beaglebone:/lib/firmware# dtc -O dts -o 
> > /lib/firmware/PRU-GPIO-BLINK-00A0.dtbo -b 0 -@ PRU-GPIO-BLINK.dts 
> > 
> > When I go to add this to the bone_capemgr using: 
> > root@beaglebone:/lib/firmware# echo "PRU-GPIO-BLINK" > 
> > /sys/devices/platform/bone_capemgr/slots 
> > 
> > I end up getting either a "No Such File or Directory" error or a "File 
> > Exists" error. I have disabled the HDMI in uEnvt.txt like many people 
> have 
> > recommended by simply uncommenting the line: 
> > 
> > dtb=am335x-boneblack-emmc-overlay.dtb 
> > 
> > On top of the above I tried following the exercise here: 
> > http://elinux.org/EBC_Exercise_30_PRU_via_remoteproc_and_RPMsg 
> > I make it through most of that exercise, up until I hit the enabling the 
> > remoteproc portion. When I go to "uncomment" 
> > #include "am33xx-pruss-rproc.dtsi 
> > I can't seem to find it anywhere in the file. When I simply add the line 
> to 
> > the file and try calling `make` the compiler complains that it can't 
> find 
> > the file and fails the build. 
>
> With the elinux article, make sure /opt/source/dtb-4.4-ti is up-to-date.. 
>
> cd /opt/source/dtb-4.4-ti ; git pull 
>
> 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/80f64049-4082-4f29-b8ba-06eafee4a26e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Re: Beaglebone Black PRU Troubles

2016-11-08 Thread Greg 
I think I know exactly what is wrong.  You need to activate the Remoteproc 
PRU framework.  This is no longer active by default.
Robert Nelson's script which is available via Github repository will fix 
the problem.

I have been working on detailed documentation of the entire process to 
activate the framework and set up the C compiler:

https://github.com/Greg-R/pruadc1

More specifically, look at this PDF file:

https://github.com/Greg-R/pruadc1/blob/master/doc/PRUADC1latex/PRUADC1.pdf

Go to the chapter "Setting Up the Remoteproc PRU and Compiler on the 
Beaglebone Green".

Now, the chapter is not completely finished.  I am still seeing a problem 
with the configuration
At boot, the PRU firmwares are not starting correctly.  I don't understand 
why this is.

However, you can do this:

rmmod pru_rproc

and then

modprobe pru_rproc

The firmwares will start running.
More investigation, required, but at least there is some path to getting 
things working for now.

I will do some more work on this later today.

Regards,
Greg


On Tuesday, November 8, 2016 at 11:42:25 AM UTC-5, Zach B wrote:
>
> I have spent a solid 12 hours trying to get the PRU's on the beaglebone to 
> work. So far I seem to be completely stuck at the getting the device 
> overlay to work as well as enabling the remoteproc. I have tried to piece 
> together all of the information I have found on the internet but it is 
> either out of date or extremely fragmented. I can't seem to find a current 
> working example or I hit a wall when following along as said previously.
>
>

-- 
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/ce0bf666-a685-4e22-adc6-6bab07d7b73d%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Long booting time when no network cable is plugged

2016-11-08 Thread Paul Plankton 
Simple installation of ifplugd does not do the job - what else has to be
done?

2016-10-26 12:22 GMT+02:00 David Goodenough <
david.goodeno...@linkchoose.co.uk>:

> There is a package called ifplugd which monitors the connection and only
> activates the connection when a cable is plugged into the socket and the
> electrical connection to another system (or router/switch) is established.
>
>
>
> David
>
>
>
> On Tuesday, 25 October 2016 22:08:51 BST Paul Plankton wrote:
>
> But this disables the network interface permanently, not only when no
> cable is plugged?
>
>
>
> Am Dienstag, 25. Oktober 2016 22:49:05 UTC+2 schrieb RobertCNelson:
>
> On Tue, Oct 25, 2016 at 3:46 PM, Paul Plankton 
> wrote:
> > Hi,
> >
> > I'm running a BBG with Ubuntu on external microSD-card (the one from
> > http://www.elinux.org/BeagleBoardUbuntu#Ubuntu_.2816.04.1.29 ).
> >
> > When no network cable is connected to the BBG, the boot time is quite
> long,
> > it comes up with a text
> >
> > A start job is running for Raise network interfaces (39s / 5min 2s)
> >
> >
> > The first time value is counting and it really takes minutes...
> >
> > How can I avoid this delay and let it continue without network when no
> cable
> > is plugged?
>
> edit /etc/network/interfaces
>
> and comment out the two  "eth0" lines..
>
> 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/2df6ea22-7d5f-4c39-8650-2d7520c7e32e%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 a topic in the
> Google Groups "BeagleBoard" group.
> To unsubscribe from this topic, visit https://groups.google.com/d/
> topic/beagleboard/HnnW7ThaE-s/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/16604528.pWpmt2WTRT%40stargate
> 
> .
>
> 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/CAMCbi43P9HX%3DvVuxKz_5Sdp_DgqXjNUw7DAUcdc6VCne8UxdUA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Beaglebone Black PRU Troubles

2016-11-08 Thread Robert Nelson 
On Tue, Nov 8, 2016 at 10:39 AM, Zach B  wrote:
> I have spent a solid 12 hours trying to get the PRU's on the beaglebone to
> work. So far I seem to be completely stuck at the getting the device overlay
> to work as well as enabling the remoteproc. I have tried to piece together
> all of the information I have found on the internet but it is either out of
> date or extremely fragmented. I can't seem to find a current working example
> or I hit a wall when following along as said previously.
>
> Setup/Environment
> I have updated the kernel on the beaglebone followed by multiple "updates",
> "upgrades" and "dist-upgrades". As far as I can tell I am using the most
> recent version of everything.
>
> Beaglebone Black
> Debian 8.6
> kernel 4.4.30-ti-r64
> dtc 1.4.1
>
> Sample Code
> Device Overlay File [PRU-GPIO-BLINK-00A0.dts]:
>
> // Setup file for basic PRU GPIO Blinking LED
>
> /dts-v1/;
> /plugin/;
>
> / {
> compatible = "ti,beaglebone", "ti,beaglebone-black";
>
> part-number = "PRU-GPIO-BLINK";
> version = "00A0";
>
> // This overlay uses the following resources
> exclusive-use = "P8.12";
>
> fragment@0 {
> target = <&am33xx_pinmux>;
> __overlay__ {
>
> gpio_pins: pinmux_gpio_pins {
> pinctrl-single,pins = <
> 0x034   0x06
> >;
> };
> };
> };
>
> fragment@1 {
> target = <&pruss>;
> __overlay__ {
> status = "okay";
> pinctrl-names = "default";
> pinctrl-0 = <&gpio_pins>;
> };
> };
> };
>
>
>
> The above code compiles using:
> root@beaglebone:/lib/firmware# dtc -O dts -o
> /lib/firmware/PRU-GPIO-BLINK-00A0.dtbo -b 0 -@ PRU-GPIO-BLINK.dts
>
> When I go to add this to the bone_capemgr using:
> root@beaglebone:/lib/firmware# echo "PRU-GPIO-BLINK" >
> /sys/devices/platform/bone_capemgr/slots
>
> I end up getting either a "No Such File or Directory" error or a "File
> Exists" error. I have disabled the HDMI in uEnvt.txt like many people have
> recommended by simply uncommenting the line:
>
> dtb=am335x-boneblack-emmc-overlay.dtb
>
> On top of the above I tried following the exercise here:
> http://elinux.org/EBC_Exercise_30_PRU_via_remoteproc_and_RPMsg
> I make it through most of that exercise, up until I hit the enabling the
> remoteproc portion. When I go to "uncomment"
> #include "am33xx-pruss-rproc.dtsi
> I can't seem to find it anywhere in the file. When I simply add the line to
> the file and try calling `make` the compiler complains that it can't find
> the file and fails the build.

With the elinux article, make sure /opt/source/dtb-4.4-ti is up-to-date..

cd /opt/source/dtb-4.4-ti ; git pull

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/CAOCHtYhAnt3rc_unKfMJz-Bb%2BERoDVO3FseVSz%2BPedBj5EZkng%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Beaglebone Black PRU Troubles

2016-11-08 Thread Zach B 
I have spent a solid 12 hours trying to get the PRU's on the beaglebone to 
work. So far I seem to be completely stuck at the getting the device 
overlay to work as well as enabling the remoteproc. I have tried to piece 
together all of the information I have found on the internet but it is 
either out of date or extremely fragmented. I can't seem to find a current 
working example or I hit a wall when following along as said previously.

Setup/Environment
I have updated the kernel on the beaglebone followed by multiple "updates", 
"upgrades" and "dist-upgrades". As far as I can tell I am using the most 
recent version of everything.

   - Beaglebone Black
   - Debian 8.6
   - kernel 4.4.30-ti-r64
   - dtc 1.4.1

Sample Code
Device Overlay File [PRU-GPIO-BLINK-00A0.dts]:

// Setup file for basic PRU GPIO Blinking LED

/dts-v1/;
/plugin/;

/ {
compatible = "ti,beaglebone", "ti,beaglebone-black";

part-number = "PRU-GPIO-BLINK";
version = "00A0";

// This overlay uses the following resources
exclusive-use = "P8.12";

fragment@0 {
target = <&am33xx_pinmux>;
__overlay__ {

gpio_pins: pinmux_gpio_pins {
pinctrl-single,pins = <
0x034   0x06
>;
};
};
};

fragment@1 {
target = <&pruss>;
__overlay__ {
status = "okay";
pinctrl-names = "default";
pinctrl-0 = <&gpio_pins>;
};
};
};



The above code compiles using:  
root@beaglebone:/lib/firmware# dtc -O dts -o 
/lib/firmware/PRU-GPIO-BLINK-00A0.dtbo -b 0 -@ PRU-GPIO-BLINK.dts

When I go to add this to the bone_capemgr using:
root@beaglebone:/lib/firmware# echo "PRU-GPIO-BLINK" > 
/sys/devices/platform/bone_capemgr/slots

I end up getting either a "No Such File or Directory" error or a "File 
Exists" error. I have disabled the HDMI in uEnvt.txt like many people have 
recommended by simply uncommenting the line:

dtb=am335x-boneblack-emmc-overlay.dtb

On top of the above I tried following the exercise here: 
http://elinux.org/EBC_Exercise_30_PRU_via_remoteproc_and_RPMsg  
I make it through most of that exercise, up until I hit the enabling the 
remoteproc portion. When I go to "uncomment" 
#include "am33xx-pruss-rproc.dtsi
I can't seem to find it anywhere in the file. When I simply add the line to 
the file and try calling `make` the compiler complains that it can't find 
the file and fails the build.  

If anyone is curious here is the output when I run 
cat /sys/devices/platform/bone_capemgr/slots

 0: PF  -1
 1: PF  -1
 2: PF  -1
 3: PF  -1
 4: P-O-L-   0 Override Board Name,00A0,Override Manuf,univ-emmc

Question  
Does anyone have any suggestions as to why my device overlay is not working 
and I can't follow along with the exercise on elinux? I am pretty much 
stuck at this point and most of the examples online reference out of date 
pathing or approaches. Is there a package that I am missing? From what I 
have read it seems like all of the compilers and loaders come built into 
the new beaglebone distributions now. If anyone needs clarification or I 
forgot to mention something I will be happy to provide it.

-- 
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/367f1bd1-533b-4b2a-b126-728b84238890%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] correct connection of an opto-coupler

2016-11-08 Thread Przemek Klosowski 
On Tue, Nov 8, 2016 at 10:27 AM, mzimmers  wrote:
> I apologize for the confusion...after reading the instructions for the nth
> time, I have come to realize that I'm trying to use the wrong component for
> this exercise.
Right, Derek calls for an LDR aka Light-Dependent Resistor, aka
photoresistor, that looks like this:

https://www.amazon.com/PODOY-Photoresistor-GL5537-Resistors-Light-Dependent/dp/B016D737Y4

-- 
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/CAC%3D1GgHvpuSwxYh%2BPmH9s-4YkWFVo-oS1eOav1mDhOE_Oa8uJg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] correct connection of an opto-coupler

2016-11-08 Thread mzimmers 
I apologize for the confusion...after reading the instructions for the nth 
time, I have come to realize that I'm trying to use the wrong component for 
this exercise. 

Thanks to everyone who tried to help me on 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/638fb308-9ad8-4bb1-b5ee-a347113eec72%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] correct connection of an opto-coupler

2016-11-08 Thread mzimmers 
Thanks for the replies. I should have included this picture of the diagram:




It's the opto-coupler (labelled LDR) that I'm having trouble understanding 
how to connect. 

Przemek: I haven't tried anything. I don't want to make a connection that 
could damage anything.

Thank you for any help.

-- 
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/a21eb33f-6078-4728-81eb-272ac0a64a1e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] correct connection of an opto-coupler

2016-11-08 Thread Przemek Klosowski 
On Tue, Nov 8, 2016 at 9:39 AM, mzimmers  wrote:
> Hi, all - I thought I posted something about this last week, but a search
> doesn't turn it up, so here goes again.
>
> I'm working through Molloy's book, and trying to build the opto-coupler
> circuit in chapter 6. I'm not a hardware guy, so I'm feeling my way along
> here. The diagram doesn't show specifically how to wire up the four
> connectors. I looked at the data sheet for the device, which was helpful,
> but still doesn't get me home.

OK, so what did you try? Which four connectors are you talking
about--the opto's?
As a device, opto is normally being driven by your computer (pins A
and C on your datasheet, connected to the LED) and the output
phototransistor serves as a control switch for your working circuit.
They both need current limiting, normally in the form of a series
resistor. For instance, the LED in your opto is limited to 60mA, and
probably should be driven at 10mA, so if you're driving it from 3.3V
output of your Beaglebone, you need a resistor of
R=U/I=(3.3-1.3)/.01=200 ohm. The output phototransistor is limited to
50mA, so it also should have a similar current limiting resistor
connected to it.
Of course the opto could also be used as an input circuit---the LED
driven by a voltage from the outside, and the phototransistor
connected to the input of your Beaglebone. Similar current-limiting
considerations apply.

>
> I could trial and error, but I've already fried one component, and they're
> not easy to come by in my area. Can anyone help clarify this configuration?
>
> This is the specific device: opto-coupler
>

-- 
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/CAC%3D1GgE4LmvNaS0Zn_Ek-WmDx6jq7dKE6LCY62Yf2GcLdFUsGg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] correct connection of an opto-coupler

2016-11-08 Thread evilwulfie 
You cannot use that optocoupler and directly drive it with the beaglebone.
the LED in that part needs 60ma to function correctly.

you would need to add a LED driver like what gerald has used to drive
the LEDs on the beaglebone.
you also need to calculate the correct current limiting resistor for
60ma @ 1.35v


On 11/8/2016 7:39 AM, mzimmers wrote:
> Hi, all - I thought I posted something about this last week, but a
> search doesn't turn it up, so here goes again.
>
> I'm working through Molloy's book, and trying to build the
> opto-coupler circuit in chapter 6. I'm not a hardware guy, so I'm
> feeling my way along here. The diagram doesn't show specifically how
> to wire up the four connectors. I looked at the data sheet for the
> device, which was helpful, but still doesn't get me home.
>
> I could trial and error, but I've already fried one component, and
> they're not easy to come by in my area. Can anyone help clarify this
> configuration?
>
> This is the specific device: opto-coupler
> 
>
> 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/cbd62af0-9a6d-4873-be79-ccd0a935d0b6%40googlegroups.com
> .
> For more options, visit https://groups.google.com/d/optout.


-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/f04ead10-96f8-b7d7-7e73-4568105bd00a%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] correct connection of an opto-coupler

2016-11-08 Thread mzimmers 
Hi, all - I thought I posted something about this last week, but a search 
doesn't turn it up, so here goes again.

I'm working through Molloy's book, and trying to build the opto-coupler 
circuit in chapter 6. I'm not a hardware guy, so I'm feeling my way along 
here. The diagram doesn't show specifically how to wire up the four 
connectors. I looked at the data sheet for the device, which was helpful, 
but still doesn't get me home.

I could trial and error, but I've already fried one component, and they're 
not easy to come by in my area. Can anyone help clarify this configuration?

This is the specific device: opto-coupler 


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/cbd62af0-9a6d-4873-be79-ccd0a935d0b6%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Ubuntu Core on Beaglebone Black

2016-11-08 Thread 'Luther Goh Lu Feng' via BeagleBoard 
Hi there, 

I am trying to install Ubuntu Core 16 on the Beaglebone black. Is this the 
right place to seek help? I cant seem to find the documentation on how to 
utilise the beagleblack gadget snap. Will be grateful if someone can point 
me to the relevant documentation.

Am aware of http://releases.ubuntu.com/ubuntu-core/16/ 
and https://developer.ubuntu.com/en/snappy/start/gadget-snaps/ but am 
really lost as to how to start. Thanks.


-- Luther

-- 
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/84f4d477-7c69-4094-b8ea-f58113955fc3%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Re: Unable to boot or debug Ubuntu linux on beagle board rev. C3

2016-11-08 Thread mkstart 
I try that unsuccessfully again. It surprised me that  bootargs haven't got 
updated from uEnv.txt file.
uEnv.txt
uname_r=4.7.8-armv7-x3
bootargs=earlyprintk console=ttyS2,115200


However, I did change tty from the u-boot command line directly, resuming 
boot process with "=> boot" and "=> run bootcmd"(I tried with both because 
I didn't know which is correct) , and got the same freeze after Starting 
linux kernel ... output.
Here is my output:

=> editenv console
edit: ttyS2,115200n8
=> boot
switch to partitions #0, OK
mmc0 is current device
SD/MMC found on device 0
Checking for: /uEnv.txt ...
Checking for: /boot/uEnv.txt ...
65 bytes read in 10 ms (5.9 KiB/s)
Loaded environment from /boot/uEnv.txt
Checking if uname_r is set in /boot/uEnv.txt...
Running uname_boot ...
loading /boot/vmlinuz-4.7.8-armv7-x3 ...
6095360 bytes read in 542 ms (10.7 MiB/s)
loading /boot/dtbs/4.7.8-armv7-x3/omap3-beagle.dtb ...
109840 bytes read in 278 ms (385.7 KiB/s)
debug: [console=ttyS2,115200n8 root=/dev/mmcblk0p2 ro rootfstype=ext4 
rootwait musb_hdrc.fifo_mode=5] ...
debug: [bootz 0x8200 - 0x8800] ...
## Flattened Device Tree blob at 8800
   Booting using the fdt blob at 0x8800
   Loading Device Tree to 8ffe2000, end 8d0f ... OK

Starting kernel ...



On Monday, November 7, 2016 at 7:24:34 PM UTC+1, Steve wrote:
>
> Try changing the ttyO2 to ttyS2.
>
> On Monday, November 7, 2016 at 8:14:34 AM UTC-6, mkstart wrote:
>>
>> First of all, I am new in this field,
>> I am trying to boot linux on Beagle Board Rev. C3 with no success. Steps 
>> I took for booting is taken from this wiki 
>> https://eewiki.net/display/linuxonarm/BeagleBoard . It is created by 
>> Robert Nelson. I can see that U-Boot is started and trying to start Linux 
>> kernel, but as control is passed to kernel I stop getting output. It looked 
>> like low-level debug is not configured for OMAP3. I tried to recompile and 
>> configure kernel. In menuconfig I select Kernel hacking ---> Kernel 
>> low-level debugging functions ---> Kernel low-level debugging port and I 
>> select "Kernel low-level debugging messages via OMAP3 UART3". I also select 
>> Early printk(I am not sure if I need this). After compiling I have no 
>> progress. I also connect monitor via hdmi and I see yellow screen only.
>>
>> Could you please give me some idea?
>>
>> This is my output:
>> U-Boot 2016.09-dirty (Nov 02 2016 - 12:23:39 +0100)
>>
>> OMAP3530-GP ES3.0, CPU-OPP2, L3-165MHz, Max CPU Clock 600 MHz
>> OMAP3 Beagle board + LPDDR/NAND
>> I2C:   ready
>> DRAM:  256 MiB
>> NAND:  256 MiB
>> MMC:   OMAP SD/MMC: 0
>> *** Warning - bad CRC, using default environment
>>
>> Beagle Rev C1/C2/C3
>> Timed out in wait_for_event: status=1000
>> Check if pads/pull-ups of bus are properly configured
>> No EEPROM on expansion board
>> Timed out in wait_for_bb: status=1000
>> No EEPROM on expansion board
>> OMAP die ID: 3d03040323090b01e00a
>> Net:   usb_ether
>> Error: usb_ether address not set.
>>
>> Hit any key to stop autoboot:  0 
>> switch to partitions #0, OK
>> mmc0 is current device
>> SD/MMC found on device 0
>> Checking for: /uEnv.txt ...
>> Checking for: /boot/uEnv.txt ...
>> 23 bytes read in 11 ms (2 KiB/s)
>> Loaded environment from /boot/uEnv.txt
>> Checking if uname_r is set in /boot/uEnv.txt...
>> Running uname_boot ...
>> loading /boot/vmlinuz-4.7.8-armv7-x3 ...
>> 6089504 bytes read in 543 ms (10.7 MiB/s)
>> loading /boot/dtbs/4.7.8-armv7-x3/omap3-beagle.dtb ...
>> 109840 bytes read in 277 ms (386.7 KiB/s)
>> debug: [console=ttyO2,115200n8 root=/dev/mmcblk0p2 ro rootfstype=ext4 
>> rootwait musb_hdrc.fifo_mode=5] ...
>> debug: [bootz 0x8200 - 0x8800] ...
>> ## Flattened Device Tree blob at 8800
>>Booting using the fdt blob at 0x8800
>>Loading Device Tree to 8ffe2000, end 8d0f ... OK
>>
>> Starting kernel ...
>>
>>
>>

-- 
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/8cf61bf7-4145-4bdb-a87d-783ea0706a76%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Re: Beaglebone 4.4.27-ti-r63 and uio_pruss; program ran in 3.8 not running in 4.4 pru, help appreciated

2016-11-08 Thread terra ÜÝÜ 
The issue was eclipse; during the upgrade to windows 10 all the paths got 
lost and ... big head ache; got to work on "old" 3.8 bone 70 version 
example is running fine; will try 4.4 next couple of days

part of solution was to compile on the BB, hope helps someone in future

On Saturday, 5 November 2016 23:30:29 UTC+11, terra ÜÝÜ wrote:
>
>
> Hi All :)
>
> I have a program which ran with Beaglebone black, 3.8; I am updating the 
> system to Beaglebone 4.4.27-ti-r63 and getting segmentation fault.
> Seems like the overlay is not loading, even when loaded manually.
>
> If you have a working configuration for Beaglebone 4.4.x and uio_pruss 
> please also post, as any help would be greatly appreciated
>
> On fresh reboot
> *lsmod | grep uio*
> uio_pdrv_genirq 3923  0
> uio10524  1 uio_pdrv_genirq
>
> *echo 'EBB-PRU-MIC' > /sys/devices/platform/bone_capemgr/slots*
> -bash: echo: write error: File exists
>
> *modprobe uio_pruss*
>
> *lsmod | grep uio*
> uio_pruss   5504  0
> uio_pdrv_genirq 3923  0
> uio10524  2 uio_pruss,uio_pdrv_genirq
>
> compiled program is 
>
> *Segmentation fault*So issues seem to be;
> 1. cannot load my overlay "*EBB-PRU-MIC"*
> 2. PRU seems to be running 
> 3. Other ?
>
>
>
>
>
>
> *If you have any ideas please let me know, as I am kinda lost where to go. 
> Attached source code.Much AppreciatedMB--> EBB-PRU-MIC-00A0.dts*
> /* Device Tree Overlay for enabling the pins that are used in the Chapter 
> 25
> * directory for copyright and GNU GPLv3 license information.
> */
> /dts-v1/;
> /plugin/;
>
> / {
>compatible = "ti,beaglebone", "ti,beaglebone-black";
>
>part-number = "EBB-PRU-MIC";
>version = "00A0";
>
>/* This overlay uses the following resources */
>exclusive-use =
>   "P8.46", "P8.45" , "pru1";
>
>fragment@0 {
>   target = <&am33xx_pinmux>;
>   __overlay__ {
>
>  pru_pru_pins: pinmux_pru_pru_pins {   // The PRU pin modes
> pinctrl-single,pins = <
>// See Table 6-7, no pull up/down resistors enabled
>// This is for PRU1, the sample clock -- debug only
>0x0a4 0x36  // SAMP P8_46 pr1_pru1_pru_r31_1, MODE5 | INPUT 
> | PULL UP
>0x0a0 0x36  // SAMP P8_46 pr1_pru1_pru_r31_0, MODE5 | INPUT 
> | PULL UP
> >;
>  };
>   };
>};
>
>fragment@1 { // Enable the PRUSS
>   target = <&pruss>;
>   __overlay__ {
>  status = "okay";
>  pinctrl-names = "default";
>  pinctrl-0 = <&pru_pru_pins>;
>   };
>};
>
> };
>
> *--> timedelay.p compiled with pasm -b timedelay.p ; chmod +x 
> timedelay.bin*
> // This is a nearly-minimal PRU program. It delays for five seconds, then
> // notifies the host that it has completed, then halts the PRU.
> //
> // The idea is to have a program that does something you can see from user
> // space, without doing anything complicated like playing with IO pins,
> // DDR or shared memory.
> //
> // Try adjusting the DELAYCOUNT value and re-running the test; you should
> // be able to convince yourself that the program is actually doing 
> something.
>
> .origin 0 // offset of the start of the code in PRU memory
> .entrypoint START // program entry point, used by debugger only
>
> // To signal the host that we're done, we set bit 5 in our R31
> // simultaneously with putting the number of the signal we want
> // into R31 bits 0-3. See 5.2.2.2 in AM335x PRU-ICSS Reference Guide.
>
> #define PRU0_R31_VEC_VALID  32;
> #define PRU_EVTOUT_03
> #define PRU_EVTOUT_14
> #define PRU1_ARM_INTERRUPT   20
>
> #define DELAY_SECONDS 2 // adjust this to experiment
> #define CLOCK 2 // PRU is always clocked at 200MHz
> #define CLOCKS_PER_LOOP 2 // loop contains two instructions, one clock each
> #define DELAYCOUNT DELAY_SECONDS * CLOCK / CLOCKS_PER_LOOP
>
> START:
>
> // initialize loop counter
> MOV r1, DELAYCOUNT
> // wait for specified period of time
> DELAY:
> SUB r1, r1, 1 // decrement loop counter
> QBNEDELAY, r1, 0  // repeat loop unless zero
> // tell host we're done
> mov r31.b0, PRU1_ARM_INTERRUPT+16
>
> MOV r1, DELAYCOUNT
> // wait for specified period of time
> DELAY2:
> SUB r1, r1, 1 // decrement loop counter
> QBNEDELAY2, r1, 0  // repeat loop unless zero
> // tell host we're done
> mov r31.b0, PRU1_ARM_INTERRUPT+16
>
> // initialize loop counter
> MOV r1, DELAYCOUNT
> // wait for specified period of time
> DELAY1:
> SUB r1, r1, 1 // decrement loop counter
> QBNEDELAY1, r1, 0  // repeat loop unless zero
>
> // tell host we're done, then halt
> mov r31.b0, PRU1_ARM_INTERRUPT+16 //int1
> mov r31.b0, PRU1_ARM_INTERRUPT+15 //int0
>
> HALT
>
> *-->main c ; program mea