[beagleboard] Re: Unable to update device tree overlay file

[Colin Bester]

Robert's suggestions/explanations worked for me and solved issue.

On Wednesday, August 16, 2017 at 7:14:40 PM UTC-5, farzin...@gmail.com 
wrote:
>
>
>
> On Monday, March 23, 2015 at 6:27:06 AM UTC+3:30, Colin Bester wrote:
>>
>> In adding Audio Cape (BB-BONE-AUDI-02-00A0) to beaglebone black which 
>> also has LCD4 mounted I receive a GPIO 19 conflict error.
>>
>> Looking at the dts file I see it has specified exclusive use for gpio1_18 
>> and gpio1_19. In the past I circumvented this error by commenting these two 
>> pins out of the exclusive list and all works fine (doesn't appear that 
>> these pwm pins are used by audio cape)
>>
>> Now I upgraded debian to 3.8.13-bone70 and in performing upgrade and 
>> setting up new board I forgot to exclude these two pins from dts file 
>> before compiling, only to see the conflict error again.
>>
>> My problem is that no matter what I do, (edit out pins, compile and copy 
>> new dtbo to /lib/firmware), I keep getting the same conflict error. If I 
>> edit the dts file and change the part number to something else and load it 
>> manually it works so I know the change and compile is valid.
>>
>
>  
>
>>
>> It appears that my original compiled dtbo file is somehow being 
>> cached/persisted through power off/power on and my updated dtbo is not 
>> being 'seen'.
>>
>> I'd appreciate any suggestions on next steps.
>>
>> Colin
>>
>>
>
>
>
> Hello your problem solved?
> I have this problem, but not done?
> Can you help me in the end?
> fixed?
>

-- 
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/e703f887-11f6-49ce-9c4b-ae9887c097ff%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Decrease ramdisk (tmpfs) to increase available RAM memory

[Colin Bester]

I am looking to increase the amount of RAM by about 100K and was wondering 
if I could 'steal' some from ramdisk.

I see several tmpfs when running mount command but don't see setting up of 
tmps in /etc/fstab so am guessing this is done elsewhere.

Firstly is this possible and/or wise to do and secondly any suggestions on 
where to find creation of ram disks on startup.

Thanks
Colin

-- 
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/9aaaeff8-ea52-4b53-a094-fc189a61e350%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Kiosk mode chromium, setting memory limits

[Colin Bester]

I am running chromium in kiosk mode on debian 3.8.13 using command line:

chromium  --app=http://localhost --kiosk --disable-pinch 
--disable-touch-drag-drop --disable-touch-editing 
--touch-selection-strategy=direction


I have noticed that it's memory usage continues to grow. I don't suspect 
memory leak (at least not at rate I see) as when using standalone (remote) 
browser and profiling I don't see this growth. I suspect this is due to 
garbage collection not being called as it is not hitting memory ceiling.


Does anyone know if one can limit memory usage (setting a cap) like you'd 
do with java or node (using max_old_space_size).


Much appreciated.


~C

-- 
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/921d81aa-c009-4842-b4b0-1b7ce9b0c565%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] LCD4 phantom clicks

[Colin Bester]

I was wondering if there is a way to configure/set touchscreen parameters 
on debian 3.8.13-bone68 as I am seeing random phantom click events on lcd4 
touchscreen. I have taken a look at /etc/ts.conf but it doesn't seem to 
make any difference.

Much appreciated,
Colin

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

Re: [beagleboard] init-eMMC-flasher-v3.sh not shutting down

[Colin Bester]

I was just going to add to my post that I found difference in my 
am335x_evm.sh files. Prior working version included

#eMMC flasher just exited single user mode via: [exec /sbin/init]
#as we can't shudown properly in single user mode..
unset are_we_flasher
are_we_flasher=$(grep init-eMMC-flasher /proc/cmdline || true)
if [ ! "x${are_we_flasher}" = "x" ] ; then
 halt
 exit
fi

while current am335x_evm.sh doesn't. I do see the code you mention in 
generic-startup.sh but don't see where this file is called/referenced. 


> Yeah, this is a bug/workaround... 
>
> Does? "exec /sbin/init 0" actually shut it down?  For me when i tested 
> it late last year summer, it wasn't doing what i wanted.. 
>
> Right now i catch the "shutdown" here: 
>
>
> https://github.com/RobertCNelson/boot-scripts/blob/master/boot/generic-startup.sh#L3-L10
>  
>
> 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.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] init-eMMC-flasher-v3.sh not shutting down

[Colin Bester]

I'm in process of reflashing and will let you know on /sbin/init 0 working 
or not.

Did 'shutdown -h now' not work when you tried, any reason not to call this 
directly in the init-eMMC script?

Looking forward to getting this version buttoned up so that I can move to 
later version


On Wednesday, October 21, 2015 at 4:59:34 PM UTC-5, RobertCNelson wrote:
>
> On Wed, Oct 21, 2015 at 4:49 PM, Colin Bester <bester...@gmail.com 
> > wrote: 
> > I am updating my images ((3.8.13-bone68) and looking to make new images 
> for 
> > cloning from SD card to eMMC 
> > 
> > My process is to setup beaglebone as required and then run 
> > 
> /opt/scripts/tools/eMMC/beaglebone-black-make-microSD-flasher-from-eMMC.sh 
> > after first changing directory to /opt/scripts/tools and issuing a git 
> pull 
> > to get the lastest scripts. 
> > 
> > Creating SD image works as expected. 
> > 
> > However when cloning from SD to eMMC (in powered off board, insert SD 
> card, 
> > hold boot button and power up board and wait for power down) the 
> destination 
> > board is not closing down. I then hooked up serial to usb cable and 
> > monitored output. I see the script is getting called and message "eMMC 
> has 
> > been flashed: please wait for device to power down" is being displayed. 
> > However the device is not shutting down and appears to be restarting. 
> > 
> > Looking at  init-eMMC-flasher-v3.sh script function copy_rootfs () I 
> see: 
> > 
> >  message="eMMC has been flashed: please wait for device to power down." 
> ; 
> > broadcast 
> >  message="-" ; broadcast 
> > 
> > 
> >  flush_cache 
> >  #To properly shudown, /opt/scripts/boot/am335x_evm.sh is going to call 
> > halt: 
> >  exec /sbin/init 
> >  #halt -f 
> > 
> > The last line is calling /sbin/init and halt is commented out - is this 
> > correct? I'd assume if you wanted to shutdown using init you'd need to 
> > calling init 0 and not just init. 
>
> Yeah, this is a bug/workaround... 
>
> Does? "exec /sbin/init 0" actually shut it down?  For me when i tested 
> it late last year summer, it wasn't doing what i wanted.. 
>
> Right now i catch the "shutdown" here: 
>
>
> https://github.com/RobertCNelson/boot-scripts/blob/master/boot/generic-startup.sh#L3-L10
>  
>
> 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.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] init-eMMC-flasher-v3.sh not shutting down

[Colin Bester]

Thanks Robert, appreciate the info.


On Wednesday, October 21, 2015 at 5:20:17 PM UTC-5, RobertCNelson wrote:
>
> On Wed, Oct 21, 2015 at 5:14 PM, Colin Bester <bester...@gmail.com 
> > wrote: 
> > I'm in process of reflashing and will let you know on /sbin/init 0 
> working 
> > or not. 
> > 
> > Did 'shutdown -h now' not work when you tried, any reason not to call 
> this 
> > directly in the init-eMMC script? 
>
> i think it just brought down the kernel... don't remember 100% anymore.. 
>
> > 
> > Looking forward to getting this version buttoned up so that I can move 
> to 
> > later version 
>
> btw... there is a back door in the init script: 
>
> touch /boot/debug.txt 
>
>
> https://github.com/RobertCNelson/boot-scripts/blob/master/tools/eMMC/init-eMMC-flasher-v3.sh#L428
>  
>
> beagleboard.org 
>
>
> https://github.com/RobertCNelson/boot-scripts/blob/master/tools/eMMC/init-eMMC-flasher-v3.sh#L74
>  
>
> and you get bash access, in that init, over serial   debug single user mode>... 
>
> 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.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] init-eMMC-flasher-v3.sh not shutting down

[Colin Bester]

I am updating my images ((3.8.13-bone68) and looking to make new images for 
cloning from SD card to eMMC 

My process is to setup beaglebone as required and then run 
/opt/scripts/tools/eMMC/beaglebone-black-make-microSD-flasher-from-eMMC.sh 
after first changing directory to /opt/scripts/tools and issuing a git pull 
to get the lastest scripts.

Creating SD image works as expected.

However when cloning from SD to eMMC (in powered off board, insert SD card, 
hold boot button and power up board and wait for power down) the 
destination board is not closing down. I then hooked up serial to usb cable 
and monitored output. I see the script is getting called and message "eMMC 
has been flashed: please wait for device to power down" is being displayed. 
However the device is not shutting down and appears to be restarting.

Looking at  init-eMMC-flasher-v3.sh script function copy_rootfs () I see:

 message="eMMC has been flashed: please wait for device to power down." ; 
broadcast
 message="-" ; broadcast


 flush_cache
 #To properly shudown, /opt/scripts/boot/am335x_evm.sh is going to call 
halt:
 exec /sbin/init
 #halt -f

The last line is calling /sbin/init and halt is commented out - is this 
correct? I'd assume if you wanted to shutdown using init you'd need to 
calling init 0 and not just init.

Thanks
Colin

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

Re: [beagleboard] When is USB bus scanned

[Colin Bester]

What's the difference between v4.1.x-ti versus v4.1.x-bone? I 
see http://elinux.org/Beagleboard:BeagleBoneBlack_Debian refers to bone and 
not ti?

Is this for beagleBONE or related to bonescript or something else?

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

Re: [beagleboard] When is USB bus scanned

[Colin Bester]

I will definitely experiment with 4.x but do need a production ready 
release with working bonescript - I haven't looked into using bonescript 
with 4.x yet.

Thanks

~Colin

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

Re: [beagleboard] When is USB bus scanned

[Colin Bester]

Thanks. I installed (via apt-get) 4.1.6-ti but when I ran the kernel update 
script under /opt/script/tools it updated to 4.1.8-boneX

Is it okay/advised to run the update kernel script and stick with its Linux 
version?

I am in process of downloading emmc flasher as I just bricked my BBB after 
editing uEnv.txt. 

Should one add a dtb entry in uEnv or can we keep that line commented out and 
just use default? 

I will go through examples tomorrow and try get base stack going with BBB rev 
C, LCD cape, i2c and PWM. Afterwards will look into audio. 

Sent from my iPhone

> On Sep 22, 2015, at 5:06 PM, Robert Nelson <robertcnel...@gmail.com> wrote:
> 
>> On Tue, Sep 22, 2015 at 4:03 PM, Colin Bester <bester.co...@gmail.com> wrote:
>> What's the difference between v4.1.x-ti versus v4.1.x-bone? I see
>> http://elinux.org/Beagleboard:BeagleBoneBlack_Debian refers to bone and not
>> ti?
>> 
>> Is this for beagleBONE or related to bonescript or something else?
> 
> 
> bone = generic armv7 config optimized for the beaglebone's..
> 
> (note, these "optimizing" are becoming less important in every kernel
> release, as things are becoming more generic and detectable, so at
> some point, the .config diff between my 'armv7' and 'bone' will be no
> more..)
> 
> ti: ti jumped on the v4.1.x lts release, so we are taking full
> advanage of that..  (i've cherry picked a few things from ti's v4.1.x
> that you see in our bone branch. cpufreq-volt, iodelay, etc..)
> 
> The "v4.1.x-ti" is what i'm testing/pushing by default..
> 
> Regards,
> 
> -- 
> Robert Nelson
> https://rcn-ee.com/
> 
> -- 
> 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/6bKl8wzt8CI/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to 
> beagleboard+unsubscr...@googlegroups.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.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] When is USB bus scanned

[Colin Bester]

I used --lts per documentation, maybe that's what caused it. I thought 'lts' 
sounded good as I want more stable and long term support so didn't question it. 
Gotta run but will continue tomorrow and try not too bug ya'll too much!

Sent from my iPhone

> On Sep 22, 2015, at 5:29 PM, Robert Nelson  wrote:
> 
> odd, as i have the defaults setup to install the 'ti' branch:

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

Re: [beagleboard] When is USB bus scanned

[Colin Bester]

Powered via external power supply and not via usb port (which is definitely 
an issue).

Your question on what changed is a good one as that's what I always try and 
ask. As per a separate post 
(https://groups.google.com/forum/#!category-topic/beagleboard/beaglebone-black/ZceK86k1oZc)
 
the only change is in wifi manufacturer.

The chipset is the same as what we were using previously and before I 
signed off on these new devices I ran tests on three different end devices 
with the same usb wifi adapter, rebooting devices and cycling power at 
least 50 times if not more.

What's weird is that the devices do work reliably for some time and then 
start acting up and when one starts to 'fail' if I plug it into a different 
beaglebone is works fine. Also plugging a new usb device into same 
beaglebone works - it's only that usb and that beaglebone combo that fails 
- doesn't make sense and I must be missing something.


On Monday, September 21, 2015 at 5:12:06 PM UTC-5, William Hermans wrote:
>
> Colin,
>
> How are you powering the BBB ? If it's not by way of barrel jack, then 
> you're doing it wrong . . . Powering by USB might work for a little while, 
> but eventually it will not provide enough power. I got bitten by this 
> myself, just using the CAN peripheral.
>
> But what's changed since the last time it worked reliably ? Software? 
> settings ?
>
> On Mon, Sep 21, 2015 at 3:07 PM, Robert Nelson <robert...@gmail.com 
> > wrote:
>
>> On Mon, Sep 21, 2015 at 5:02 PM, Colin Bester <bester...@gmail.com 
>> > wrote:
>> > On debian 3.8.13 when is the usb port scanned for devices on startup? I 
>> am
>> > trying to debug why a normally work usb wifi adapter is now failing and 
>> not
>> > being detected on power up.
>> >
>> > Is USB bus scan tied to a service I could somehow delay?
>> >
>> > Any other way to force scanning and loading of usb wifi adapter?
>>
>> usb was nothing but a hack in v3.8.x... this was all fixed by v3.14.x...
>>
>> I'll get you to leave 3.8.x by the wayside at some point. ;)
>>
>> Regards,
>>
>> --
>> Robert Nelson
>> https://rcn-ee.com/
>>
>> --
>> For more options, visit http://beagleboard.org/discuss
>> ---
>> You received this message because you are subscribed to the Google Groups 
>> "BeagleBoard" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to beagleboard...@googlegroups.com .
>> 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.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] When is USB bus scanned

[Colin Bester]

Fast learning it was a bit of a hack, but I do have to be honest in that 
it's been solid till now!

Any suggestions (for testing purposes) on whether I can somehow either 
delay detected USB devices or restart the bus scan at later time?

On Monday, September 21, 2015 at 5:08:34 PM UTC-5, RobertCNelson wrote:
>
> On Mon, Sep 21, 2015 at 5:02 PM, Colin Bester <bester...@gmail.com 
> > wrote: 
> > On debian 3.8.13 when is the usb port scanned for devices on startup? I 
> am 
> > trying to debug why a normally work usb wifi adapter is now failing and 
> not 
> > being detected on power up. 
> > 
> > Is USB bus scan tied to a service I could somehow delay? 
> > 
> > Any other way to force scanning and loading of usb wifi adapter? 
>
> usb was nothing but a hack in v3.8.x... this was all fixed by v3.14.x... 
>
> I'll get you to leave 3.8.x by the wayside at some point. ;) 
>
> 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.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] When is USB bus scanned

[Colin Bester]

Robert, I'd love to leave 3.8.13 but it will be a long and slow process as 
the fixed cape overlays don't work for me ( I assume 3.14.x will give me 
same issues I had with 3.8.13-bone70 where due to pin definitions in 
overlays that I lost functionality - I'd love to chat if you have time for 
suggestions and possible solutions. If there are contractors out there 
willing to help, I'd be willing to chat.

Is 3.8.x still not the 'official' latest base?

On Monday, September 21, 2015 at 5:08:34 PM UTC-5, RobertCNelson wrote:
>
> On Mon, Sep 21, 2015 at 5:02 PM, Colin Bester <bester...@gmail.com 
> > wrote: 
> > On debian 3.8.13 when is the usb port scanned for devices on startup? I 
> am 
> > trying to debug why a normally work usb wifi adapter is now failing and 
> not 
> > being detected on power up. 
> > 
> > Is USB bus scan tied to a service I could somehow delay? 
> > 
> > Any other way to force scanning and loading of usb wifi adapter? 
>
> usb was nothing but a hack in v3.8.x... this was all fixed by v3.14.x... 
>
> I'll get you to leave 3.8.x by the wayside at some point. ;) 
>
> 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.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] When is USB bus scanned

[Colin Bester]

On debian 3.8.13 when is the usb port scanned for devices on startup? I am 
trying to debug why a normally work usb wifi adapter is now failing and not 
being detected on power up.

Is USB bus scan tied to a service I could somehow delay?

Any other way to force scanning and loading of usb wifi adapter?

Thanks
Colin

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

[beagleboard] Re: Resistive touchscreen with random events

[Colin Bester]

LCDs have been sent under RMA to manufacturer who are investigating the 
issue.

On Thursday, August 27, 2015 at 10:59:30 AM UTC-5, Colin Bester wrote:
>
> With latest batch of LCD4 modules (4DCape-43T) we have noticed an issue 
> with intermittent click events which is obviously playing havoc as it is 
> generating user events.
>
> Until now we have had absolutely no issue and have only started seeing 
> this now. We are running debian on beaglebone black rev C using 
> 3.8.13-bone68,
>
> Upgrading to 4.x is not an option as well as moving higher than build 
> bone68 is not an option due to changes in how LCD and Audio setup is done 
> which causes conflicts.
>
> I have seen some (not much) talk on tweaking and re-compiling touch screen 
> device drivers which I am not keen to do if I don't have to. I have messed 
> round with settings in /etc/ts.conf to no avail so may need to dig in 
> deeper and look at recompiling touchscreen driver.
>
> I am assuming the driver is ti-tsc and would very much appreciate hearing 
> from anyone if they have had this issue and/or have compiled the 
> touchscreen device driver successfully on debian 3.8.13.
>
> Thanks
> Colin 
>

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

[beagleboard] Working USB wifi adapter now not being detected

[Colin Bester]

I've been successfully using RT5370 chipset wifi USB for several months on 
by BBB running debian 3.8.13-bone68 with no issues whatsoever.

Recently however when booting the device from power off state the USB 
adapter is no longer detected. "ifconfig -a" doesn't not show any wlanx 
devices, lsusb does not list the usb adapter at all.

If I ssh into the device and issue a reboot command then the USB device is 
detected.

If I plug in a new USB adapter (after clearing 
out /etc/udev/rules.d/70-persistent-net.rules) into powered off device it 
correctly detects the new usb adapter from power off startup.

Connected the 'non-working' USB adapter into a different BBB running the 
exact same setup (they are identical s/w clones) works fine.

I am a little stumped and am not sure if there is another file besides 
"/etc/udev/rules.d/70-persistent-net.rules" that I should look at - would 
appreciate ideas/feedback.

Is there any way to manually scan for usb adapter for fault finding - seems 
only way to detect device is to reboot?

Colin

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

Re: [beagleboard] Building Kernel using RobertCNelson scripts

[Colin Bester]

Quick question. When building the kernel I assume you run build scripts 
(I'm using R. Nelson's bb-kernel scripts) as normal user. 

So far all is working well and the only 'issue' I see is that my module 
files (in modules tar) all have user (used to run scripts) permissions as 
opposed to root permissions (kinda obvious). Now once all installed it's 
obviously easy to change ownership of the modules after untarring them into 
correct locations. 

Is this the correct way or am I missing something - there is such good work 
put into these scripts that I thought maybe I missed something.

~C

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

Re: [beagleboard] Building Kernel using RobertCNelson scripts

[Colin Bester]

Thanks Robert, I didn't realize the issue with large number of tags.

Appreciate the feedback

~C

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

Re: [beagleboard] Building Kernel using RobertCNelson scripts

[Colin Bester]

Robert, I know there are many ways to accomplish the same thing - besides 
downloading and manually overwriting the script/ files and the host_det.sh 
files you mention is there a better way you can suggest?

~C

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

[beagleboard] Resistive touchscreen with random events

[Colin Bester]

With latest batch of LCD4 modules (4DCape-43T) we have noticed an issue 
with intermittent click events which is obviously playing havoc as it is 
generating user events.

Until now we have had absolutely no issue and have only started seeing this 
now. We are running debian on beaglebone black rev C using 3.8.13-bone68,

Upgrading to 4.x is not an option as well as moving higher than build 
bone68 is not an option due to changes in how LCD and Audio setup is done 
which causes conflicts.

I have seen some (not much) talk on tweaking and re-compiling touch screen 
device drivers which I am not keen to do if I don't have to. I have messed 
round with settings in /etc/ts.conf to no avail so may need to dig in 
deeper and look at recompiling touchscreen driver.

I am assuming the driver is ti-tsc and would very much appreciate hearing 
from anyone if they have had this issue and/or have compiled the 
touchscreen device driver successfully on debian 3.8.13.

Thanks
Colin 

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

[beagleboard] Building Kernel using RobertCNelson scripts

[Colin Bester]

I am looking to build debian kernel and see two different github 
repositories; https://github.com/RobertCNelson/bb-kernel and 
https://github.com/RobertCNelson/linux-dev. Both look pretty neat and I 
tried bb-kernel on my ubuntu desktop and it seems to have worked.

Questions: 
1) Is there preference to which to use (any other)?
2) How do I recompile a specific version - in my case 3.8.13-bone68. I am 
looking to replicate this know working version (for me) and update one of 
its files. I see you can checkout origin/am33x-v3.8 and I see on github 
several tags, but none the ones I want.

Apologies if this is mentioned somewhere but I am battling with an 
extremely slow connection and am not finding results.

Thanks!
Colin

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

[beagleboard] Re: WiFi with external antenna for BBB - recommendations?

[colin . bester]

I am not sure on what distance you are looking for but I have had good 
success with USB wifi adapters utilizing the RT5370 chipset (in my 
application I need both access point mode as well as managed mode).

I have not used this device itself but have used without the external 
antenna

http://www.amazon.com/Landlord-Portable-802-11NGB-Wireless-Converter/dp/B00Y1V566W/ref=sr_1_13?s=pcie=UTF8qid=1439823003sr=1-13keywords=usb+wifi+5370

One word of caution though, I have recently been caught out ordering RT5370 
advertised devices to receive 7601 chipset devices - while I could get 
these to work in managed mode I have been unable to use them as an access 
point.

~C

On Monday, August 17, 2015 at 4:33:53 AM UTC-5, c...@isbd.net wrote:

 Don deJuan donju...@gmail.com javascript: wrote: 
  On 08/16/2015 08:07 AM, c...@isbd.net javascript: wrote: 
   Marcus Diogo mvdi...@gmail.com javascript: wrote: 
   [-- text/plain, encoding quoted-printable, charset: UTF-8, 53 lines 
 --] 
   
   In my house i use one external like nanostation 
   https://www.ubnt.com/airmax/nanostationm/ just plug on ethernet bbb 
   Em 16/08/2015 06:20, c...@isbd.net javascript: escreveu: 
   
   I already use the similar TP-Link TL-WA7210G. 
   
   However I have a specific requirement to use a USB adapter in this 
   application as I need to do the WiFi authentication in the host 
   computer not in the remote device. 
   
  alfa series cards will work fine 
  
 I've found:- 

 http://www.alfa.com.tw/products_list.php?pc=2 

 Are these the ones you mean?  They seem to make quite a good range, 
 thank you. 

 -- 
 Chris Green 
 · 



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

Re: [beagleboard] Beaglebone Black Wifi Managed and Master mode

[Colin Bester]

Thanks Nuno, I'll take note of chipset. Unfortunately in my case I can't 
chance upgrading to 4.x yet.

On Wednesday, August 12, 2015 at 8:21:14 PM UTC-5, Nuno wrote:

 On 08/12/2015 04:53 PM, Colin Bester wrote: 
  USB WiFi to debian 3.8.13-boneX where they are able to connect to 
  existing access points AND configure the wifi to act as an access point 
  (master mode) using hostapd. 

 Not using debian, but ubuntu 15.04 with hostapd in bridge mode, in the 
 5GHz wifi band: 

 ~$ lsb_release -a 
 No LSB modules are available. 
 Distributor ID:Ubuntu 
 Description:Ubuntu 15.04 
 Release:15.04 
 Codename:vivid 

 ~$ uname -srpo 
 Linux 4.1.3-bone15 armv7l GNU/Linux 

 ~$ lsusb 
 Bus 001 Device 002: ID 148f:5572 Ralink Technology, Corp. RT5572 Wireless 
 Adapter 

 regards, 
 Nuno 

 -- 


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

Re: [beagleboard] BeagleBone Black doesn't sometimes start. Only Power LED is on

[Colin Bester]

In my case I am running 3.8.13-bone68 and system is pretty darn solid if it 
does start up. I have not seen Ethernet fail nor have I had any random 
reboots, but occasional I do have a device not power up when power is 
applied. We have not been able to determine a consistent cause and I am not 
convinced it's due to the mentioned RX pin as I am pretty sure I saw that 
this pin is pulled low (which I still think is wrong polarity) on rev C 
boards.

In addition, we have physically blocked off the PWR button and only expose 
the reset button via a small pin hole in our enclosure.



On Thursday, August 13, 2015 at 5:42:23 PM UTC-5, ivan.wu...@gmail.com 
wrote:

 Hi Robert,

  Please confirm which kernel your running

 3.8.13-bone71 (updated beginning of last June)

  There's a big thread on this list, where a bunch spend about 2 weeks 
 bisecting the v4.1.x kernel to find the cause of the random reboot.. 

 I don't have an issue though with random reboots - the reboots are 
 initiated on purpose by my application (because of the eth0 problem) - but 
 as described 2 in 30,000 reboots failed.

 Cheers,
 Ivan



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

Re: [beagleboard] BeagleBone Black doesn't sometimes start. Only Power LED is on

[Colin Bester]

I just took a look at Rev C schematics and there is a 100K pulldown on the RX 
pin so I wouldn’t have expected pulling directly to ground to make it any 
worse. All in all 100K is not much of a pull down, but I do agree that pull up 
is what you want - that at least is idle state on a serial line (from what I 
recall). My gut feel would be to use around a 3K resistor would should allow 
plenty headroom for hooking up a serial monitor if you ever wanted to - its a 
real pity that there is no convenient 3V3 on the monitor header.

~C

 On Aug 13, 2015, at 6:25 PM, AQG Chris cwal...@gmail.com wrote:
 
 I'll chime in again too - we originally tested our 3v3-rx jumper with a 
 direct connection, but then decided it might be nice to keep the ability to 
 use the serial debug port.  Right now we've got a 470 ohm resistor pulling rx 
 up, which seems to allow communication over serial still.  We also tried 
 values of 220 through 1kohm and were still able to send characters to uart0.  
 100 ohm was too low to send anything over serial.  I've not done extensive 
 reboot testing yet with each of these, but we will likely settle on either 
 470 or 1kohm.
 
 If you probe the RX pin of the BB with nothing attached, we find 0v.  The TX 
 pin (both on the BB and on the FTDI board we attach to the BB) is at 3.3v by 
 default, and we've also noticed that the problem never occurs when we're 
 hooked up to uart0 with our FTDI chip adapter.  That made pulling the line up 
 rather than down an attractive option.  We did try pulling RX down to ground 
 at some point, but the very first test I did after that resulted in power LED 
 on but no boot.
 
 We still haven't done a mass deployment, so for now I'm taking our smaller 
 testing runs and experiences like Ivan's to guide us.  Sidenote - yes, we 
 have noticed eth0 not showing up as well, although it's not critical for our 
 application.
 
 On Thursday, August 13, 2015 at 4:04:34 PM UTC-7, Colin Bester wrote:
 In my case I am running 3.8.13-bone68 and system is pretty darn solid if it 
 does start up. I have not seen Ethernet fail nor have I had any random 
 reboots, but occasional I do have a device not power up when power is 
 applied. We have not been able to determine a consistent cause and I am not 
 convinced it's due to the mentioned RX pin as I am pretty sure I saw that 
 this pin is pulled low (which I still think is wrong polarity) on rev C 
 boards.
 
 In addition, we have physically blocked off the PWR button and only expose 
 the reset button via a small pin hole in our enclosure.
 
 
 
 On Thursday, August 13, 2015 at 5:42:23 PM UTC-5, ivan.wu...@gmail.com  
 wrote:
 Hi Robert,
 
  Please confirm which kernel your running
 
 3.8.13-bone71 (updated beginning of last June)
 
  There's a big thread on this list, where a bunch spend about 2 weeks 
  bisecting the v4.1.x kernel to find the cause of the random reboot.. 
 
 I don't have an issue though with random reboots - the reboots are initiated 
 on purpose by my application (because of the eth0 problem) - but as described 
 2 in 30,000 reboots failed.
 
 Cheers,
 Ivan
 
 
 -- 
 For more options, visit http://beagleboard.org/discuss 
 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/aXv6An1xfqI/unsubscribe 
 https://groups.google.com/d/topic/beagleboard/aXv6An1xfqI/unsubscribe.
 To unsubscribe from this group and all its topics, send an email to 
 beagleboard+unsubscr...@googlegroups.com 
 mailto:beagleboard+unsubscr...@googlegroups.com.
 For more options, visit https://groups.google.com/d/optout 
 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.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] BeagleBone Black doesn't sometimes start. Only Power LED is on

[Colin Bester]

Please let us know how the jumping RX to 3V3 line works out. If I recall 
correctly, the RX line is pulled down to ground which didn't make sense to 
me as generally an asserted RX state is considered idle (if memory serves 
me correctly). What resistance are you using? Modifying u-boot is not 
something I want to do if I don't have to.


On Wednesday, June 3, 2015 at 2:04:29 PM UTC-5, AQG Chris wrote:

 We are dealing with the same issue - we found another complaint of the 
 same thing, in which the user identifies phantom characters on the UART 
 during startup causing the board to go into u-boot.  If you don't have a 
 display attached or a serial connection available, u-boot looks a lot like 
 a solid power LED and nothing else.  link to that thread:
 http://andicelabs.com/2014/07/beaglebone-black-boot-issues/

 That user apparently was able to modify u-boot to look for a certain 
 character instead of any keystroke.  In the limiting testing I've done, it 
 seems that the problem also doesn't occur if you have a serial connection 
 hooked up to UART0.  I'm now experimenting with jumping the RX line of 
 UART0 to 3.3v, and so far haven't had the issue again.




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

[beagleboard] Beaglebone Black Wifi Managed and Master mode

[Colin Bester]

I know there are several threads regarding wifi but many of these are 
outdated so thought I'd start a new thread, asking if anyone has been 
successful adding USB WiFi to debian 3.8.13-boneX where they are able to 
connect to existing access points AND configure the wifi to act as an 
access point (master mode) using hostapd.

If you have been successful with both modes, I'd really appreciate you 
sharing which USB adapter you used and specifically the chipset.

To date I have been using the RT5370 chipset with very reliable 
communications in both client (managed) and ap (master) mode - my issue is 
supply of these USB devices and I am looking for backup solutions.

If we can collect sufficient info I will update wiki with this info to 
assist other users.

Thanks
Colin

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

Re: [beagleboard] Debian 3.8.13-bone-68 and RALINK 7601 driver

[Colin Bester]

No joy so far, I fear this is a losing battle...

On Tuesday, August 11, 2015 at 10:31:37 AM UTC-5, Colin Bester wrote:

 Thanks Robert, I will hunt this down - I am so close to the trees at the 
 moment that O can't see wood for trees - appreciate your assistance.

 When I am in your neck of the woods or you are here in Austin, I owe you a 
 beer/dinner for all your help!

 On Tuesday, August 11, 2015 at 10:24:37 AM UTC-5, RobertCNelson wrote:

 On Tue, Aug 11, 2015 at 10:09 AM, Colin Bester bester...@gmail.com 
 wrote: 
  Robert, 
  
  I have it working in managed mode connecting to my access point using 
  wpa_supplicant but am unable to switch it to master mode (access 
 point). 
  
  Error on running hostapd is (after installing 
 mt7601u-modules-3.8.13-bone68 
  from link you sent). 
  
  random: Trying to read entropy from /dev/random 
  
  Configuration file: /etc/hostapd/hostapd.conf 
  nl80211: 'nl80211' generic netlink not found 
  Failed to initialize driver 'nl80211' 
  Segmentation fault 
  
  
  Does this version support hostapd, or is 'segmentation fault' 
 indication of 
  version incompatibilities? 

 there's a mt7601u fork of hostapd for this driver somewhere on 
 github...  Haven't found it yet in my quick searches.. 

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

Re: [beagleboard] Debian 3.8.13-bone-68 and RALINK 7601 driver

[Colin Bester]

While migrating to 4.1 is on my development path that is not an option at 
the moment as production is full steam ahead. 

~C

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

Re: [beagleboard] Debian 3.8.13-bone-68 and RALINK 7601 driver

[Colin Bester]

Good question, especially as I have not seen this before so I guess not if 
it's standard.

I assume I download the .deb package and install?

What does installing these modules do, do I still need to compile drivers 
and install (seems I do as after installing modules using dpkg I don't see 
any loaded modules)

Thanks so much for rapid response!

On Tuesday, August 11, 2015 at 7:53:08 AM UTC-5, RobertCNelson wrote:

 On Tue, Aug 11, 2015 at 7:21 AM, Colin Bester bester...@gmail.com 
 javascript: wrote: 
  While migrating to 4.1 is on my development path that is not an option 
 at 
  the moment as production is full steam ahead. 

 btw, do you have: 

 mt7601u-modules-3.8.13-bone68 installed? 

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

Re: [beagleboard] Debian 3.8.13-bone-68 and RALINK 7601 driver

[Colin Bester]

 

Reason I went the .deb route was because I couldn't install the module - 
see below - am I missing some salient point (i.e. lessons to be learnt)



root@biochargerng:/home/callin/mt7601u# apt-get install 
mt7601u-modules-`uname -r`

Reading package lists... Done

Building dependency tree   

Reading state information... Done

E: Unable to locate package mt7601u-modules-3.8.13-bone68

E: Couldn't find any package by regex 'mt7601u-modules-3.8.13-bone68'

root@biochargerng:/home/callin/mt7601u# 

On Tuesday, August 11, 2015 at 8:26:13 AM UTC-5, RobertCNelson wrote:

 On Tue, Aug 11, 2015 at 8:19 AM, Colin Bester bester...@gmail.com 
 javascript: wrote: 
  Good question, especially as I have not seen this before so I guess not 
 if 
  it's standard. 
  
  I assume I download the .deb package and install? 
  
  What does installing these modules do, do I still need to compile 
 drivers 
  and install (seems I do as after installing modules using dpkg I don't 
 see 
  any loaded modules) 
  
  Thanks so much for rapid response! 

 Just run: 

 sudo apt-get install mt7601u-modules-`uname -r` 
 sudo depmod -a `uname -r` 
 sudo update-initramfs -uk `uname -r` 

 Firmare should be located here: 

 /etc/Wireless/RT2870STA/RT2870STA.dat 

 if it's not.. 

 mkdir -p /etc/Wireless/RT2870STA/ 
 cd /etc/Wireless/RT2870STA/ 
 wget 
 https://raw.githubusercontent.com/rcn-ee/mt7601u/master/src/RT2870STA.dat 
 cd / 

 and /etc/modules-load.d/mt7601.conf should have been added by 
 mt7601u-modules-`uname -r` 

 if not: 

 echo mt7601Usta  /etc/modules-load.d/mt7601.conf 

 Then upon reboot, you should see a ra0 device with sudo ifconfig -a 

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

Re: [beagleboard] Debian 3.8.13-bone-68 and RALINK 7601 driver

[Colin Bester]

Robert, 

I have it working in managed mode connecting to my access point using 
wpa_supplicant but am unable to switch it to master mode (access point).

Error on running hostapd is (after installing mt7601u-modules-3.8.13-bone68 
from link you sent).

random: Trying to read entropy from /dev/random

Configuration file: /etc/hostapd/hostapd.conf 
nl80211: 'nl80211' generic netlink not found 
Failed to initialize driver 'nl80211' 
Segmentation fault


Does this version support hostapd, or is 'segmentation fault' indication of 
version incompatibilities?


~C

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

Re: [beagleboard] Debian 3.8.13-bone-68 and RALINK 7601 driver

[Colin Bester]

Thanks Robert, I will hunt this down - I am so close to the trees at the 
moment that O can't see wood for trees - appreciate your assistance.

When I am in your neck of the woods or you are here in Austin, I owe you a 
beer/dinner for all your help!

On Tuesday, August 11, 2015 at 10:24:37 AM UTC-5, RobertCNelson wrote:

 On Tue, Aug 11, 2015 at 10:09 AM, Colin Bester bester...@gmail.com 
 javascript: wrote: 
  Robert, 
  
  I have it working in managed mode connecting to my access point using 
  wpa_supplicant but am unable to switch it to master mode (access point). 
  
  Error on running hostapd is (after installing 
 mt7601u-modules-3.8.13-bone68 
  from link you sent). 
  
  random: Trying to read entropy from /dev/random 
  
  Configuration file: /etc/hostapd/hostapd.conf 
  nl80211: 'nl80211' generic netlink not found 
  Failed to initialize driver 'nl80211' 
  Segmentation fault 
  
  
  Does this version support hostapd, or is 'segmentation fault' indication 
 of 
  version incompatibilities? 

 there's a mt7601u fork of hostapd for this driver somewhere on 
 github...  Haven't found it yet in my quick searches.. 

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

[beagleboard] mt7601u fork of hostapd

[Colin Bester]

I am looking to compile hostapd to work with mt7601u chipset. I am 
convinced somewhere I saw a hostap subdirectory within mt7601 source bundle 
but am unable to find it again.

Does anyone know of a fork of hostapd for mt7601 or download location where 
I can access the hostapd source files?

~C

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

[beagleboard] Debian 3.8.13-bone-68 and RALINK 7601 driver

[Colin Bester]

I have been using the 5370 driver for usb wifi dongle successfully with 
ability to support both Master and Managed mode with no issues whatsoever.

However last batch of wifi dongles delivered no longer work and lsusb shows
  Bus 001 Device 002: ID 148f:7601 Ralink Technology, Corp. 
instead of 
  Bus 001 Device 002: ID 148f:5370 Ralink Technology, Corp. RT5370 Wireless 
Adapter

I expected the 7601 drivers to be installed in my build (Debian 
3.8.13-bone68, which I am stuck with for now due to changes in bone69 and 
up that makes using LCD and Audio Cape together an issue 
https://groups.google.com/forum/#!category-topic/beagleboard/beaglebone-black/2dXgKp9T8_g)
 
but this doesn't appear to be the case.

Powering with external 5V, and ensuring usb dongle is inserted prior to 
power up.

dmesg shows 
[1.097202] usb 1-1: new high-speed USB device number 2 using musb-hdrc
[1.216778] usb 1-1: default language 0x0409
[1.581547] usb 1-1: udev 2, busnum 1, minor = 1
[1.581571] usb 1-1: New USB device found, idVendor=148f, idProduct=7601
[1.581583] usb 1-1: New USB device strings: Mfr=1, Product=2, 
SerialNumber=3
[1.582006] usb 1-1: usb_probe_device
[1.582024] usb 1-1: configuration #1 chosen from 1 choice
[1.582114] usb 1-1: adding 1-1:1.0 (config #1, interface 0)

Running lsmod shows no indication of wifi driver

I have also tried building various 7601 driver sources but am unable to get 
both managed and master mode working.

Does/should 3.8.13-bone68 support 7601 driver? If so what could I be doing 
wrong.

If not supported, any suggestion on source files to build in order to 
support both managed and master mode.

This feels like a pretty solid wall I have hit and would appreciate any 
assistance 

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

[beagleboard] Re: Turning Off the Power management Beagle Bone Black

[Colin Bester]

Marlon, I have used the power cape from Andice Labs very successfully, take 
a look at: http://andicelabs.com/beaglebone-powercape/

I am using it with a rechargeable lithium battery and am able to detect 
power outages (via i2c) and shutdown/restart beaglebone - it has several 
neat features and if I recall correctly you can read the battery levels as 
well.

~C

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

Re: [beagleboard] Turning Off the Power management Beagle Bone Black

[Colin Bester]

Yup, that's what I do with the powercape from Andice Labs as mentioned 
above. Except for very low drain battery is essentially disconnected.

I initially went the route of trying to use the onboard battery connector 
but it's not really a decent solution if you want solid system and battery 
management.

On Tuesday, July 14, 2015 at 12:12:03 PM UTC-5, Marlon Cesar Pilonetto 
wrote:

 Lords am new to the BBB and what I need is to turn off the battery 
 management so that when my system is not connected to battery is not 
 consumed in its entirety.


  

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

Re: [beagleboard] Debugging Audio Cape configuration

[Colin Bester]

On beaglebone black (Debian3.8.13-bone68) I ran tests with and without an 
audio cape (rev B) and confirm that speaker-test -D default:EVM does not 
output anything on P9_28 without the audio cape connected. With audio cape 
connected I do see ouput on P9_28.

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

Re: [beagleboard] Debugging Audio Cape configuration

[Colin Bester]

Yes I have a scope and will run tests for you when I get back to my desk. 

Sent from my iPhone

 On Jul 4, 2015, at 11:15 AM, jrbl...@colorado.edu wrote:
 
 Colin,
 
 That would be phenomenally helpful!  Do you have a scope?
 
 I'm curious if you see any life on pin 28 of the P9 header with and without a 
 cape.  I suspect you will see data with the cape (because the DAC on the cape 
 board is talking to the BBB's processor), but nothing without it.
 
 I unfortunately don't have a way to fake the cape. 
 
 
 
 On Saturday, July 4, 2015 at 9:23:59 AM UTC-6, Colin Bester wrote:
 If it'd help I could run same tests for you with and without audio cape and 
 test the theory - I am running bone68 but suspect results will be the same - 
 it'd be good to know if you can see output or not.
 
 On Saturday, July 4, 2015 at 10:19:59 AM UTC-5, jrb...@colorado.edu wrote:
 
 Latest thoughts on this: I think perhaps the problem is that I should not 
 expect to see serial data from P9_28 (I2S serial data out) without an 
 actual Audio Cape.  There are probably I2C (control) and I2S (audio 
 content) requirements, such as clocks and so forth, that are required 
 before the BBB will output data.
 
 Unfortunately, I know virtually nothing about hardware.  
 
 I would just buy an Audio Cape, but I have not seen them in stock anywhere 
 for the past month, and there seems to be no indication of when they'll be 
 available again.
 
 -- 
 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/xfv4BY1AiEA/unsubscribe.
 To unsubscribe from this group and all its topics, send an email to 
 beagleboard+unsubscr...@googlegroups.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.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Debugging Audio Cape configuration

[Colin Bester]

I don't know when the change happened but am pretty sure when I was using 
bone47 I didn't have issue with kernel included audio cape. When I upgraded 
(I'm now using bone68) I found that audio cape was included so compiling 
your own and placing in /lib/firmware made no difference as it was already 
included - work around is to rename the file to something else (in my case 
I called it BB-BONE-AUDI-03 and added this to my capemgr startup.


On Friday, July 3, 2015 at 10:35:23 PM UTC-5, jrb...@colorado.edu wrote:


 What distro and version are you using? I know on Debian after a certain 
 build ( I don't know which ) that BB-BONE-AUDI-02 is installed as part of 
 the kernel - if this is your case then the dts you are looking at may not 
 be the same at kernel dtbo is using - just a thought 

 I had this issue with 3.13.8-bone70 


 I'm using 

 Linux beaglebone 3.8.13-bone47 #1 SMP Fri Apr 11 01:36:09 UTC 2014 armv7l 
 GNU/Linux

 I'm not sure what you're saying though.  I know that 
 /lib/firmware/BB-BONE-AUDI-02.dtbo is the right one because I compiled it 
 myself from the dts.  Are you saying that it may conflict with another one 
 already hardcoded in the kernel?

 When you had this issue, how did you resolve it?

 I suppose I could unload the dtbo and see if P9_28 comes to life?!
  


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

Re: [beagleboard] 3.8.13bone70, LCD/Audio bust?

[Colin Bester]

I'm glad I asked :-), these versioning schemes don't always make sense to 
folks out of the loop.

Where does 68.1 fit in? I see it commented out in diff.

Is there a scheme to the numbering - e.g. is bone70 68.3 patch or does it 
have no patch - is there a link explaining this for my own future reference.

Thanks!


On Wednesday, July 1, 2015 at 10:03:49 AM UTC-5, RobertCNelson wrote:

 Hi Colin, 

 On Wed, Jul 1, 2015 at 10:01 AM, Colin Bester bester...@gmail.com 
 javascript: wrote: 
  Robert, I just wanted to check that I am doing the linux image 
 correctly. 
  
  Will apt-get install linux-image-3.8.13-bone68 include the 68.2 patch 
 you 
  mentioned? 

 68 is before 68.2 (68.2 patch = bone69) 

 So sudo apt-get install linux-image-3.8.13-bone68 will install a 
 kernel without that pin change.. 

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

Re: [beagleboard] 3.8.13bone70, LCD/Audio bust?

[Colin Bester]

Thanks Robert, the link is most useful and I learned something new today - 
I never even saw that commits link of git page - even after all these years.

On Wednesday, July 1, 2015 at 10:35:39 AM UTC-5, RobertCNelson wrote:

 On Wed, Jul 1, 2015 at 10:17 AM, Colin Bester bester...@gmail.com 
 javascript: wrote: 
  I'm glad I asked :-), these versioning schemes don't always make sense 
 to 
  folks out of the loop. 
  
  Where does 68.1 fit in? I see it commented out in diff. 
  
  Is there a scheme to the numbering - e.g. is bone70 68.3 patch or does 
 it 
  have no patch - is there a link explaining this for my own future 
 reference. 

 There is scheme, it's all linear.. 

 https://github.com/RobertCNelson/bb-kernel/commits/am33x-v3.8 

 x.0 releases are pushed out, anything x.y + 0.1 is a between 
 release commit... 

 68 - bone68 pushed out.. 
 68.1 probotix lcd cape 
 68.2 lcd4 cape fix 
 68.3 hdmi pin fix 
 68.4 config: CONFIG_TI_CPTS, CONFIG_PTP_1588_CLOCK and CONFIG_USB_G_DBGP 
 69 - bone69 pushed out.. 

 Usually i try to keep things down to one change between 0.1 bumps.. 

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

Re: [beagleboard] 3.8.13bone70, LCD/Audio bust?

[Colin Bester]

Robert, I just wanted to check that I am doing the linux image correctly. 

Will apt-get install linux-image-3.8.13-bone68 include the 68.2 patch you 
mentioned?

Much appreciated,
Colin


On Tuesday, June 30, 2015 at 12:27:18 PM UTC-5, RobertCNelson wrote:

 On Tue, Jun 30, 2015 at 12:07 PM, Colin Bester bester...@gmail.com 
 javascript: wrote: 
  Thanks Robert I will give that a try - did it get 'broken' after 68.2 
 moving 
  up to 70? 
  
  One of my main reasons for moving up to 70 was for the pretty solid (and 
  neat) eMMC cloning scripts, hopefully 68 is close. 

 The scripts really don't care about kernel version... As long as the 
 kernel is in the repo: 

 DL the non-flasher.. 

 Install the kernel you want via apt-get: 

 update scripts: 

 cd /opt/scripts/ 
 git pull 

 enable the flasher, last line of: 
 /boot/uEnv.txt 

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

Re: [beagleboard] 3.8.13bone70, LCD/Audio bust?

[Colin Bester]

Robert, I think I misunderstood your comment regarding 'fix' with patch 
68.2 as in my situation this patch (68.2) actually broke my system (per my 
requirements) as the offending key was added to LCD cape - my confusion was 
that word 'fix' fixed my problem.

By setting gpi3_16, functionality required by Audio cape was locked out 
making operation of audio cape and lcd not possible. 

bone68 works and bone69 doesn't support both audio cape and lcd.

I am not sure what solution is going forward as this locks me in to this 
version if the patch (not a fix in my case) is included in kernel.

Thanks for all your assistance - couldn't do this without your input.

Cheers
Colin

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

Re: [beagleboard] Audio Cape on BBB rev C

[Colin Bester]

Ah, gotcha - you had me there with rfs :-). 

yes the dmesg outputs shown are using the bone70 installation. 

glad to have someone else looking at this as I may just be missing 
something simple - I am wanting to move up to bone70 to make use of the 
improved cloning scripts as I need to clone quite a few boards in the very 
near future.

On Tuesday, June 30, 2015 at 4:23:23 AM UTC-5, J Evans wrote:

 Excellent stuff. Thank you.  The dmesg spw below is from your bone70 
 installation (?). Let me try and get that bone50 set up to work first.

  

 rfs == root file system (in case you were using something generated by 
 Buildroot for example)

  

 BR

  

 Jerry.

  


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

Re: [beagleboard] 3.8.13bone70, LCD/Audio bust?

[Colin Bester]

I've broken my setup at present but will forward dtbo when it's back up. I 
assume you are busy with bone50 setup and not bone70?

If so, I think you need to enable audio in /etc/default/capemgr and not in 
uEnv.txt:

callin@BioChargerNG011:~$ cat /etc/default/capemgr 
# Default settings for capemgr. This file is sourced by /bin/sh from
# /etc/init.d/capemgr.sh


# Options to pass to capemgr
CAPE=BB-BONE-AUDI-03

Note that I changed audio cape's name to BB-BONE-AUDI-03 and not 
BB-BONE-AUDI-02,

In the meantime, till I get back up and running, in the BB-BONE-AUDI-02 dts 
file change

exclusive-use =
/* the pin header uses */
P9.31, /* mcasp0: mcasp0_aclkx */
P9.29, /* mcasp0: mcasp0_fsx */
P9.28, /* mcasp0: mcasp0_axr2 */
P9.25, /* mcasp0: mcasp0_ahclkx */
/* the hardware ip uses */
gpio1_18, gpio1_19,
mcasp0;

to
exclusive-use =
/* the pin header uses */
P9.31, /* mcasp0: mcasp0_aclkx */
P9.29, /* mcasp0: mcasp0_fsx */
P9.28, /* mcasp0: mcasp0_axr2 */
P9.25, /* mcasp0: mcasp0_ahclkx */
/* the hardware ip uses */
mcasp0;


Rename file to BB-BONE-AUDI-03-00A0.dts and compile to 
BB-BONE-AUDI-03-00A0.dtbo and copy to /lib/firmware directory.

If you can try this in the meantime and let me know.

~Colin

On Tuesday, June 30, 2015 at 12:56:30 PM UTC-5, J Evans wrote:

 Hi Colin, I have been trying to get this config working all afternoon and 
 zilch. I suspect the overlay file. Would you mind sharing both source and 
 compiled(+working!) version so I can try out here? 

  

 My uEnv has 

  

 cape_disable=capemgr.disable_partno=BB-BONELT_HDMI

 cape_enable=capemgr.enable_partno=BB-BONE-AUDI-02

  

 which does not agree with this report

  

 root@beaglebone:~# cat /sys/devices/bone_capemgr.9/slots

 0: 54:PF---

 1: 55:PF---

 2: 56:PF---

 3: 57:PF---

 4: ff:P-O-L Bone-LT-eMMC-2G,00A0,Texas Instrument,BB-BONE-EMMC-2G

 5: ff:P-O-- Bone-Black-HDMI,00A0,Texas Instrument,BB-BONELT-HDMI

 6: ff:P-O-L Bone-Black-HDMIN,00A0,Texas Instrument,BB-BONELT-HDMIN

  

 Thanks beaucoup.

  

  Prior to upgrading to 3.8.13bone70, I was running Debian 3.8.13bone50 on 
  Beaglebone black (RevC) together with LCD4 (BB-BONE-LCD4-01) and 
 CircuitCo's 
  Audio cape Rev B1. From the beginning, I had issues with the audio dts 
 file 
  in that it grabbed exclusive use of gpio1_18 and gpio1_19, commenting 
 these 
  pins out and recompiling solved the problem. 



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

Re: [beagleboard] 3.8.13bone70, LCD/Audio bust?

[Colin Bester]

Thanks Robert I will give that a try - did it get 'broken' after 68.2 
moving up to 70?

One of my main reasons for moving up to 70 was for the pretty solid (and 
neat) eMMC cloning scripts, hopefully 68 is close.

On Tuesday, June 30, 2015 at 11:55:52 AM UTC-5, RobertCNelson wrote:

 On Tue, Jun 30, 2015 at 11:46 AM, Colin Bester bester...@gmail.com 
 javascript: wrote: 
  I decided to separate this thread from thread 
  (
 https://groups.google.com/forum/#!category-topic/beagleboard/beaglebone-black/kT0DKgpHQOU)
  

  I had commented earlier on as I felt the different versions just 
 confused 
  the issue. 
  
  Prior to upgrading to 3.8.13bone70, I was running Debian 3.8.13bone50 on 
  Beaglebone black (RevC) together with LCD4 (BB-BONE-LCD4-01) and 
 CircuitCo's 
  Audio cape Rev B1. From the beginning, I had issues with the audio dts 
 file 
  in that it grabbed exclusive use of gpio1_18 and gpio1_19, commenting 
 these 
  pins out and recompiling solved the problem. 
  
  When moving to 3.8.13bone70, I also had to rename the 
 BB-BONE-AUDI-02-00A0 
  file to BB-BONE-AUDI-03-00A0 file so as to not load the kernel supplied 
  device overlay. 
  
  Now it appears there is a pretty serious bust between LCD and Audio 
 cape 
  that I don't know how to resolve (I say bust in inverted commas as I may 
 be 
  doing something wrong). 
  
  To me it appears that there is a conflict and I assume that the kernel 
  supplied LCD's dts is different to what was previously used. 
  
  After renaming the audio device overlay and manually loading (etc 
  BB-BONE-AUDI-03  ) which seemed to work, running aplay -l shows 
 audio 
  device but when trying to play a wav file all I hear is a 'click' noise 
 and 
  no music. 
  
  Using 3.8.13bone70 
  
  After manually loading BB-BONE-AUDI-03 cape, dmesg shows following 
 error(s) 
  with configuration: 
  
  [  323.427162] pinctrl-single 44e10800.pinmux: pin 44e10998 already 
  requested by gpio_keys.13; cannot claim for 48038000.mcasp 
  [  323.439210] pinctrl-single 44e10800.pinmux: pin-102 (48038000.mcasp) 
  status -22 
  [  323.447022] pinctrl-single 44e10800.pinmux: could not request pin 102 
 on 
  device pinctrl-single 
  [  323.492148] davinci-mcasp 48038000.mcasp: pins are not configured 
 from 
  the driver 
  
  Rebooting with LCD cape enabled and AUDIO cape disabled, pin mux shows 
 use 
  of pin 102. 
  
  pin 16 (44e10840): gpio_keys.13 (GPIO UNCLAIMED) function 
  pinmux_bone_lcd4_cape_keys_00A2_pins group 
  pinmux_bone_lcd4_cape_keys_00A2_pins 
  pin 17 (44e10844): gpio_keys.13 (GPIO UNCLAIMED) function 
  pinmux_bone_lcd4_cape_keys_00A2_pins group 
  pinmux_bone_lcd4_cape_keys_00A2_pins 
  pin 19 (44e1084c): gpio_keys.13 (GPIO UNCLAIMED) function 
  pinmux_bone_lcd4_cape_keys_00A2_pins group 
  pinmux_bone_lcd4_cape_keys_00A2_pins 
  pin 30 (44e10878): gpio-leds-cape-lcd4.12 (GPIO UNCLAIMED) function 
  pinmux_bone_lcd4_cape_led_00A1_pins group 
  pinmux_bone_lcd4_cape_led_00A1_pins 
  ... 
  pin 97 (44e10984): gpio_keys.13 (GPIO UNCLAIMED) function 
  pinmux_bone_lcd4_cape_keys_00A2_pins group 
  pinmux_bone_lcd4_cape_keys_00A2_pins 
  pin 102 (44e10998): gpio_keys.13 (GPIO UNCLAIMED) function 
  pinmux_bone_lcd4_cape_keys_00A2_pins group 
  pinmux_bone_lcd4_cape_keys_00A2_pins 
  pin 105 (44e109a4): panel.14 (GPIO UNCLAIMED) function 
  pinmux_bone_lcd4_cape_lcd_pins group pinmux_bone_lcd4_cape_lcd_pins 
  
  With LCD4 disabled (in /boot/uEnv.txt) and AUDIO cape enabled, you can 
 see 
  use of pin 102 - a conflict? 
  
  pin 100 (44e10990): 48038000.mcasp (GPIO UNCLAIMED) function 
  pinmux_bone_audio_cape_audio_pins group 
 pinmux_bone_audio_cape_audio_pins 
  pin 101 (44e10994): 48038000.mcasp (GPIO UNCLAIMED) function 
  pinmux_bone_audio_cape_audio_pins group 
 pinmux_bone_audio_cape_audio_pins 
  pin 102 (44e10998): 48038000.mcasp (GPIO UNCLAIMED) function 
  pinmux_bone_audio_cape_audio_pins group 
 pinmux_bone_audio_cape_audio_pins 
  pin 103 (44e1099c): 48038000.mcasp (GPIO UNCLAIMED) function 
  pinmux_bone_audio_cape_audio_pins group 
 pinmux_bone_audio_cape_audio_pins 
  pin 104 (44e109a0): (MUX UNCLAIMED) (GPIO UNCLAIMED) 
  pin 105 (44e109a4): (MUX UNCLAIMED) (GPIO UNCLAIMED) 
  pin 106 (44e109a8): (MUX UNCLAIMED) (GPIO UNCLAIMED) 
  pin 107 (44e109ac): 48038000.mcasp (GPIO UNCLAIMED) function 
  pinmux_bone_audio_cape_audio_pins group 
 pinmux_bone_audio_cape_audio_pins 
  
  Using 3.8.13bone50 
  
  Running pinmux on 3.8.13bone50 setup shows pinmux below, no mention of 
 pin 
  102. 
  
  callin@BioChargerNG011:~$ sudo grep lcd $PINMUX 
  pin 16 (44e10840): gpio_keys.13 (GPIO UNCLAIMED) function 
  pinmux_bone_lcd4_cape_keys_00A2_pins group 
  pinmux_bone_lcd4_cape_keys_00A2_pins 
  pin 17 (44e10844): gpio_keys.13 (GPIO UNCLAIMED) function 
  pinmux_bone_lcd4_cape_keys_00A2_pins group 
  pinmux_bone_lcd4_cape_keys_00A2_pins 
  pin 19 (44e1084c): gpio_keys.13 (GPIO UNCLAIMED) function 
  pinmux_bone_lcd4_cape_keys_00A2_pins group

[beagleboard] 3.8.13bone70, LCD/Audio bust?

[Colin Bester]

I decided to separate this thread from thread 
(https://groups.google.com/forum/#!category-topic/beagleboard/beaglebone-black/kT0DKgpHQOU)
 
I had commented earlier on as I felt the different versions just confused 
the issue.

Prior to upgrading to 3.8.13bone70, I was running Debian 3.8.13bone50 on 
Beaglebone black (RevC) together with LCD4 (BB-BONE-LCD4-01) and 
CircuitCo's Audio cape Rev B1. From the beginning, I had issues with the 
audio dts file in that it grabbed exclusive use of gpio1_18 and gpio1_19, 
commenting these pins out and recompiling solved the problem.

When moving to 3.8.13bone70, I also had to rename the BB-BONE-AUDI-02-00A0 
file to BB-BONE-AUDI-03-00A0 file so as to not load the kernel supplied 
device overlay.

Now it appears there is a pretty serious bust between LCD and Audio cape 
that I don't know how to resolve (I say bust in inverted commas as I may be 
doing something wrong).

To me it appears that there is a conflict and I assume that the kernel 
supplied LCD's dts is different to what was previously used. 

After renaming the audio device overlay and manually loading (etc 
BB-BONE-AUDI-03  ) which seemed to work, running aplay -l shows audio 
device but when trying to play a wav file all I hear is a 'click' noise and 
no music.

Using 3.8.13bone70

After manually loading BB-BONE-AUDI-03 cape, dmesg shows following error(s) 
with configuration:

[  323.427162] pinctrl-single 44e10800.pinmux: pin 44e10998 already 
requested by gpio_keys.13; cannot claim for 48038000.mcasp
[  323.439210] pinctrl-single 44e10800.pinmux: pin-102 (48038000.mcasp) 
status -22
[  323.447022] pinctrl-single 44e10800.pinmux: could not request pin 102 on 
device pinctrl-single
[  323.492148] davinci-mcasp 48038000.mcasp: pins are not configured from 
the driver

Rebooting with LCD cape enabled and AUDIO cape disabled, pin mux shows use 
of pin 102.

pin 16 (44e10840): gpio_keys.13 (GPIO UNCLAIMED) function 
pinmux_bone_lcd4_cape_keys_00A2_pins group 
pinmux_bone_lcd4_cape_keys_00A2_pins
pin 17 (44e10844): gpio_keys.13 (GPIO UNCLAIMED) function 
pinmux_bone_lcd4_cape_keys_00A2_pins group 
pinmux_bone_lcd4_cape_keys_00A2_pins
pin 19 (44e1084c): gpio_keys.13 (GPIO UNCLAIMED) function 
pinmux_bone_lcd4_cape_keys_00A2_pins group 
pinmux_bone_lcd4_cape_keys_00A2_pins
pin 30 (44e10878): gpio-leds-cape-lcd4.12 (GPIO UNCLAIMED) function 
pinmux_bone_lcd4_cape_led_00A1_pins group 
pinmux_bone_lcd4_cape_led_00A1_pins
...
pin 97 (44e10984): gpio_keys.13 (GPIO UNCLAIMED) function 
pinmux_bone_lcd4_cape_keys_00A2_pins group 
pinmux_bone_lcd4_cape_keys_00A2_pins
 pin 102 (44e10998): gpio_keys.13 (GPIO UNCLAIMED) function 
pinmux_bone_lcd4_cape_keys_00A2_pins group 
pinmux_bone_lcd4_cape_keys_00A2_pins
pin 105 (44e109a4): panel.14 (GPIO UNCLAIMED) function 
pinmux_bone_lcd4_cape_lcd_pins group pinmux_bone_lcd4_cape_lcd_pins

With LCD4 disabled (in /boot/uEnv.txt) and AUDIO cape enabled, you can see 
use of pin 102 - a conflict?

pin 100 (44e10990): 48038000.mcasp (GPIO UNCLAIMED) function 
pinmux_bone_audio_cape_audio_pins group pinmux_bone_audio_cape_audio_pins
pin 101 (44e10994): 48038000.mcasp (GPIO UNCLAIMED) function 
pinmux_bone_audio_cape_audio_pins group pinmux_bone_audio_cape_audio_pins
 pin 102 (44e10998): 48038000.mcasp (GPIO UNCLAIMED) function 
pinmux_bone_audio_cape_audio_pins group pinmux_bone_audio_cape_audio_pins
pin 103 (44e1099c): 48038000.mcasp (GPIO UNCLAIMED) function 
pinmux_bone_audio_cape_audio_pins group pinmux_bone_audio_cape_audio_pins
pin 104 (44e109a0): (MUX UNCLAIMED) (GPIO UNCLAIMED)
pin 105 (44e109a4): (MUX UNCLAIMED) (GPIO UNCLAIMED)
pin 106 (44e109a8): (MUX UNCLAIMED) (GPIO UNCLAIMED)
pin 107 (44e109ac): 48038000.mcasp (GPIO UNCLAIMED) function 
pinmux_bone_audio_cape_audio_pins group pinmux_bone_audio_cape_audio_pins

Using 3.8.13bone50

Running pinmux on 3.8.13bone50 setup shows pinmux below, no mention of pin 
102.

callin@BioChargerNG011:~$ sudo grep lcd $PINMUX
pin 16 (44e10840): gpio_keys.13 (GPIO UNCLAIMED) function 
pinmux_bone_lcd4_cape_keys_00A2_pins group 
pinmux_bone_lcd4_cape_keys_00A2_pins
pin 17 (44e10844): gpio_keys.13 (GPIO UNCLAIMED) function 
pinmux_bone_lcd4_cape_keys_00A2_pins group 
pinmux_bone_lcd4_cape_keys_00A2_pins
pin 19 (44e1084c): gpio_keys.13 (GPIO UNCLAIMED) function 
pinmux_bone_lcd4_cape_keys_00A2_pins group 
pinmux_bone_lcd4_cape_keys_00A2_pins
pin 30 (44e10878): gpio-leds-cape-lcd4.12 (GPIO UNCLAIMED) function 
pinmux_bone_lcd4_cape_led_00A1_pins group 
pinmux_bone_lcd4_cape_led_00A1_pins
...
pin 59 (44e108ec): panel.14 (GPIO UNCLAIMED) function 
pinmux_bone_lcd4_cape_lcd_pins group pinmux_bone_lcd4_cape_lcd_pins
pin 85 (44e10954): gpio_keys.13 (GPIO UNCLAIMED) function 
pinmux_bone_lcd4_cape_keys_00A2_pins group 
pinmux_bone_lcd4_cape_keys_00A2_pins
pin 105 (44e109a4): panel.14 (GPIO UNCLAIMED) function 
pinmux_bone_lcd4_cape_lcd_pins group pinmux_bone_lcd4_cape_lcd_pins

It seems that there has been changes to LCD4-01 in that mention is 

Re: [beagleboard] Audio Cape on BBB rev C

[Colin Bester]

Has anyone come right using audio card (rev B) together with 4DCAPE-43T and 
BBB Rev C running kernel 3.8.13-bone70?

My setup works flawless using kernel 3.8.13-bone50 but after updating to 
use 3.8.13-bone70 there seems to be an issue when LCD is connected.

aplay -l shows audio device and running aplay mytunes.wav just makes a 
single click sound and nothing more (no music).

If I disconnect the LCD then aplay works just fine.

On prior kernel I did modify BB-BONE-AUDI-02 as the dts file specified 
exclusive gpio1_18 and gpio1_19 use (and as far I recall, these pins 
weren't even used) causing conflict with LCD Cape overlay - until updating 
kernal to bone70.

dts snippet:

exclusive-use =
/* the pin header uses */
P9.31,/* mcasp0: mcasp0_aclkx */
P9.29,/* mcasp0: mcasp0_fsx */
P9.28,/* mcasp0: mcasp0_axr2 */
P9.25,/* mcasp0: mcasp0_ahclkx */
/* the hardware ip uses */
/*gpio1_18, gpio1_19,*/
mcasp0;

root@beaglebone:~# cat /sys/devices/bone_capemgr.9/slots 

 0: 54:PF--- 
 1: 55:PF--- 
 2: 56:PF--- 
 3: 57:P---L 4D 4.3 LCD CAPE- 4DCAPE-43T ,00A1,4D SYSTEMS  ,BB-BONE-
LCD4-01
 4: ff:P-O-L Bone-LT-eMMC-2G,00A0,Texas Instrument,BB-BONE-EMMC-2G
 5: ff:P-O-- Bone-Black-HDMI,00A0,Texas Instrument,BB-BONELT-HDMI
 8: ff:P-O-L Override Board Name,00A0,Override Manuf,BB-BONE-AUDI-03



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

Re: [beagleboard] Audio Cape on BBB rev C

[Colin Bester]

No problem. I am not at my desk right now but will forward info once I'm back 
at desk.
Pretty silly of me not to state that I'm running the Debian distro as this is 
an important piece of the equation :-)

Excuse my ignorance but what is 'rfs'?


Sent from my iPhone

 On Jun 29, 2015, at 7:22 PM, g...@novadsp.com g...@novadsp.com wrote:
 
 Hello Colin.
  
 Keenly interested in getting a known good setup. Which distro/rfs package 
 were you using with that kernel?
  
 Thx++
  
 From: beagleboard@googlegroups.com [mailto:beagleboard@googlegroups.com] On 
 Behalf Of Colin Bester
 Sent: 29 June 2015 22:42
 To: beagleboard@googlegroups.com
 Subject: Re: [beagleboard] Audio Cape on BBB rev C
  
 Has anyone come right using audio card (rev B) together with 4DCAPE-43T and 
 BBB Rev C running kernel 3.8.13-bone70?
  
 My setup works flawless using kernel 3.8.13-bone50 but after updating to use 
 3.8.13-bone70 there seems to be an issue when LCD is connected.
  
 aplay -l shows audio device and running aplay mytunes.wav just makes a 
 single click sound and nothing more (no music).
  
 If I disconnect the LCD then aplay works just fine.
  
 On prior kernel I did modify BB-BONE-AUDI-02 as the dts file specified 
 exclusive gpio1_18 and gpio1_19 use (and as far I recall, these pins weren't 
 even used) causing conflict with LCD Cape overlay - until updating kernal to 
 bone70.
  
 dts snippet:
 
 exclusive-use =
 /* the pin header uses */
 P9.31,/* mcasp0: mcasp0_aclkx */
 P9.29,/* mcasp0: mcasp0_fsx */
 P9.28,/* mcasp0: mcasp0_axr2 */
 P9.25,/* mcasp0: mcasp0_ahclkx */
 /* the hardware ip uses */
 /*gpio1_18, gpio1_19,*/
 mcasp0;
  
 root@beaglebone:~# cat /sys/devices/bone_capemgr.9/slots 
  
  0: 54:PF--- 
  1: 55:PF--- 
  2: 56:PF--- 
  3: 57:P---L 4D 4.3 LCD CAPE- 4DCAPE-43T ,00A1,4D SYSTEMS  
 ,BB-BONE-LCD4-01
  4: ff:P-O-L Bone-LT-eMMC-2G,00A0,Texas Instrument,BB-BONE-EMMC-2G
  5: ff:P-O-- Bone-Black-HDMI,00A0,Texas Instrument,BB-BONELT-HDMI
  8: ff:P-O-L Override Board Name,00A0,Override Manuf,BB-BONE-AUDI-03
  
  
  
 -- 
 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.
 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/kT0DKgpHQOU/unsubscribe.
 To unsubscribe from this group and all its topics, send an email to 
 beagleboard+unsubscr...@googlegroups.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.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Cloning Beaglebone fails running out of space

[Colin Bester]

I haven't dug in yet but when trying to execute git pull from within 
/opt/script/tools/eMMC I get the following error message:

root@mydevice:/opt/scripts/tools/eMMC# git pull
error: server certificate verification failed. CAfile: /etc/ssl/certs/ca-
certificates.crt CRLfile: none while accessing https:
//github.com/RobertCNelson/boot-scripts/info/refs
fatal: HTTP request failed

/etc/dogtag shows:

root@BioChargerNG:~# cat /etc/dogtag 
BeagleBoard.org Debian Image 2015-03-08


~C

On Thursday, June 11, 2015 at 3:34:45 PM UTC-5, RobertCNelson wrote:

 On Thu, Jun 11, 2015 at 3:24 PM, Colin Bester bester...@gmail.com 
 javascript: wrote: 
  Thanks Robert, I assume when using rsync method that you boot the BBB's 
 eMMC 
  that you want to clone and then run the 
  beaglebone-black-make-microSD-flasher-from-eMMC.sh script as opposed 
 to 
  executing script after booting up from a SD card - is this correct? 
  
  If so, what about any changes to 'source' files while running rsync? Can 
  this not be an issue as you are syncing a live system - this is one of 
 the 
  reasons why I thought it best to boot from a SD card first. 
  
  I do like the idea rsync vs dd for exact issue I am experiencing. 

 Yes, we originally did run into some issues if the source was 
 changing.. (May 2014 bb.org debian release) 

 All current eMMC flasher's do it in single user mode now 


 https://github.com/RobertCNelson/boot-scripts/blob/master/tools/eMMC/init-eMMC-flasher-v3.sh
  

 (this was changed mid 2014).. 

 If your image (cat /etc/dogtag) is after Sep 2014, just do: 

 cd /opt/scripts/tools/eMMC/ 

 git pull 

 ./beaglebone-black-make-microSD-flasher-from-eMMC.sh 

 If you look at the script close enough: 


 https://github.com/RobertCNelson/boot-scripts/blob/master/tools/eMMC/beaglebone-black-make-microSD-flasher-from-eMMC.sh#L366
  

 There's a few things you can all tune/override via /boot/SOC.sh 

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

Re: [beagleboard] Cloning Beaglebone fails running out of space

[Colin Bester]

Date and time are definitely correctly and just checked again. I am still 
getting the same error if running git pull from /opt/scripts/tools/eMMC but 
if I run from /opt/scripts it works.

Should I be running git pull from eMMC directory or from scripts directory?

~C


On Saturday, June 13, 2015 at 10:55:52 AM UTC-5, RobertCNelson wrote:

 On Sat, Jun 13, 2015 at 10:15 AM, Colin Bester bester...@gmail.com 
 javascript: wrote: 
  I haven't dug in yet but when trying to execute git pull from within 
  /opt/script/tools/eMMC I get the following error message: 
  
  root@mydevice:/opt/scripts/tools/eMMC# git pull 
  error: server certificate verification failed. CAfile: 
  /etc/ssl/certs/ca-certificates.crt CRLfile: none while accessing 
  https://github.com/RobertCNelson/boot-scripts/info/refs 
  fatal: HTTP request failed 
  
  /etc/dogtag shows: 
  
  root@BioChargerNG:~# cat /etc/dogtag 
  BeagleBoard.org Debian Image 2015-03-08 

 odd? is your clock up-to date? (systemd-timesyncd) should be taking care 
 of it.. 

 github hasn't mentioned anything... 

 https://status.github.com/messages 

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

Re: [beagleboard] Cloning Beaglebone fails running out of space

[Colin Bester]

I will create another BBB from scratch and check, but after running git 
pull from /opt/scripts I can now run it from /opt/scripts/tools/eMMC??

Maybe it's just been too long of a week.


On Saturday, June 13, 2015 at 4:16:32 PM UTC-5, Colin Bester wrote:


 Date and time are definitely correctly and just checked again. I am still 
 getting the same error if running git pull from /opt/scripts/tools/eMMC but 
 if I run from /opt/scripts it works.

 Should I be running git pull from eMMC directory or from scripts directory?

 ~C


 On Saturday, June 13, 2015 at 10:55:52 AM UTC-5, RobertCNelson wrote:

 On Sat, Jun 13, 2015 at 10:15 AM, Colin Bester bester...@gmail.com 
 wrote: 
  I haven't dug in yet but when trying to execute git pull from within 
  /opt/script/tools/eMMC I get the following error message: 
  
  root@mydevice:/opt/scripts/tools/eMMC# git pull 
  error: server certificate verification failed. CAfile: 
  /etc/ssl/certs/ca-certificates.crt CRLfile: none while accessing 
  https://github.com/RobertCNelson/boot-scripts/info/refs 
  fatal: HTTP request failed 
  
  /etc/dogtag shows: 
  
  root@BioChargerNG:~# cat /etc/dogtag 
  BeagleBoard.org Debian Image 2015-03-08 

 odd? is your clock up-to date? (systemd-timesyncd) should be taking care 
 of it.. 

 github hasn't mentioned anything... 

 https://status.github.com/messages 

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

Re: [beagleboard] Cloning Beaglebone fails running out of space

[Colin Bester]

Much appreciated, thanks!

On Thursday, June 11, 2015 at 3:34:45 PM UTC-5, RobertCNelson wrote:

 On Thu, Jun 11, 2015 at 3:24 PM, Colin Bester bester...@gmail.com 
 javascript: wrote: 
  Thanks Robert, I assume when using rsync method that you boot the BBB's 
 eMMC 
  that you want to clone and then run the 
  beaglebone-black-make-microSD-flasher-from-eMMC.sh script as opposed 
 to 
  executing script after booting up from a SD card - is this correct? 
  
  If so, what about any changes to 'source' files while running rsync? Can 
  this not be an issue as you are syncing a live system - this is one of 
 the 
  reasons why I thought it best to boot from a SD card first. 
  
  I do like the idea rsync vs dd for exact issue I am experiencing. 

 Yes, we originally did run into some issues if the source was 
 changing.. (May 2014 bb.org debian release) 

 All current eMMC flasher's do it in single user mode now 


 https://github.com/RobertCNelson/boot-scripts/blob/master/tools/eMMC/init-eMMC-flasher-v3.sh
  

 (this was changed mid 2014).. 

 If your image (cat /etc/dogtag) is after Sep 2014, just do: 

 cd /opt/scripts/tools/eMMC/ 

 git pull 

 ./beaglebone-black-make-microSD-flasher-from-eMMC.sh 

 If you look at the script close enough: 


 https://github.com/RobertCNelson/boot-scripts/blob/master/tools/eMMC/beaglebone-black-make-microSD-flasher-from-eMMC.sh#L366
  

 There's a few things you can all tune/override via /boot/SOC.sh 

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

Re: [beagleboard] Cloning Beaglebone fails running out of space

[Colin Bester]

Thanks Robert, I assume when using rsync method that you boot the BBB's 
eMMC that you want to clone and then run the 
beaglebone-black-make-microSD-flasher-from-eMMC.sh script as opposed to 
executing script after booting up from a SD card - is this correct?

If so, what about any changes to 'source' files while running rsync? Can 
this not be an issue as you are syncing a live system - this is one of the 
reasons why I thought it best to boot from a SD card first.

I do like the idea rsync vs dd for exact issue I am experiencing.

~Colin


On Thursday, June 11, 2015 at 3:13:14 PM UTC-5, RobertCNelson wrote:

 On Thu, Jun 11, 2015 at 3:04 PM, Colin Bester bester...@gmail.com 
 javascript: wrote: 
  After backing up eMMC contents to SD card and then restoring via method 
  similar to mentioned in 
  http://elinux.org/BeagleBone_Black_Extracting_eMMC_contents, booting 
 from a 
  SD card and using dd to write to eMMC I have issue with failed write 
 with 
  error Out of disk space being reported. 
  
  Firing up two Rev C cards, one from Mouser and one from Element14 show 
  following differences running fdisk /dev/mmcblk0 

  Disk /dev/mmcblk0: 3925 MB, 3925868544 bytes 

  Disk /dev/mmcblk0: 3867 MB, 3867148288 bytes 

 One's probally Micron, other Kingston... 

 You can try resizing the *.img manually with gparted and other tools. 

 This is why i prefer the rsync approach vs dd... 

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

Re: [beagleboard] BBB LCD3 Cape and inactivity

[Colin Bester]

Thanks!

 On May 20, 2015, at 1:33 PM, aahila...@gmail.com wrote:
 
  
 https://lh3.googleusercontent.com/-NW_qX1Cz0Vk/VVzTguPp-RI/DKs/NIVwCCQ1PLM/s1600/Screen%2BShot%2B2015-05-21%2Bat%2B02.25.52.jpegHi
  there folks,
 
 The CircuitCo LCD3 cape version A2 basically pulls up the backlight supply 
 enable line via R126.  By removing R126, and adding a 0R resistor (or a blob 
 of solder) on the pads for R123, you enable use of the EHRPWM1A line to 
 control the backlight.
 
 The caveat is that when you power up the BBB, you should issue a 
 
 echo 50  /sys/class/backlight/backlight/brightness
 
 to have anything come up on the BBB LCD3.
 
 Cheers!
 
 
 
 - Antonio
 
 On Friday, 30 May 2014 02:43:06 UTC+8, john3909 wrote:
 
 From: Colin Bester bester...@gmail.com javascript:
 Reply-To: beagl...@googlegroups.com javascript:
 Date: Thursday, May 29, 2014 at 6:45 AM
 To: beagl...@googlegroups.com javascript:
 Subject: Re: [beagleboard] BBB LCD3 Cape and inactivity
 
 I just managed to get around to looking a little deeper into this and 
 connected an oscilloscope to EHRPWM1A (which I figure is pin P9_14) and 
 confirm that when writing a zero to brightness (using echo 0  
 /sys/class/backlight/backlight.11/brightness) that the pin is low. Likewise 
 write a ’50’ sets a 50% duty cycle and LCD brightens. I haven’t set up 
 environment to compile and test using ‘c’ files yet.
 
 With low on pin P9_14 the LCD is still visible.
 In that case this is a hardware issue. P9_14 is connected to the enable pin 
 of the LED backplane driver so the leds should turn off. 
 
 Regards,
 John
 
 With debian version I now have running, I have not seen the LCD goto sleep 
 yet - still have to look into this.
 
 ~C
 
 
 On May 26, 2014, at 8:03 PM, John Syn john...@gmail.com javascript: wrote:
 
 
 From: Colin Bester bester...@gmail.com javascript:
 Reply-To: beagl...@googlegroups.com javascript:
 Date: Monday, May 26, 2014 at 4:54 PM
 To: beagl...@googlegroups.com javascript:
 Subject: Re: [beagleboard] BBB LCD3 Cape and inactivity
 
 Was wondering if you have come up with any further solution? I can write 
 '0' to backlight brightness but while this dims the display significantly 
 it doesn't switch if off.
 
 Have you checked that EHRPWM1A is low when you dim the display? Here are two 
 files that will control the backlight.
 
 /driver/video/backlight/pwm_bl.c
 /driver/pwm/pwm-tiehrpwm.c
 
 Regards
 John
 
 
 
 
 -- 
 For more options, visit http://beagleboard.org/discuss 
 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 javascript:.
 For more options, visit https://groups.google.com/d/optout 
 https://groups.google.com/d/optout.
 
 -- 
 For more options, visit http://beagleboard.org/discuss 
 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/d_6HC6ps2RU/unsubscribe 
 https://groups.google.com/d/topic/beagleboard/d_6HC6ps2RU/unsubscribe.
 To unsubscribe from this group and all its topics, send an email to 
 beagleboard+unsubscr...@googlegroups.com 
 mailto:beagleboard+unsubscr...@googlegroups.com.
 For more options, visit https://groups.google.com/d/optout 
 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.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Unable to update device tree overlay file

[Colin Bester]

In adding Audio Cape (BB-BONE-AUDI-02-00A0) to beaglebone black which also 
has LCD4 mounted I receive a GPIO 19 conflict error.

Looking at the dts file I see it has specified exclusive use for gpio1_18 
and gpio1_19. In the past I circumvented this error by commenting these two 
pins out of the exclusive list and all works fine (doesn't appear that 
these pwm pins are used by audio cape)

Now I upgraded debian to 3.8.13-bone70 and in performing upgrade and 
setting up new board I forgot to exclude these two pins from dts file 
before compiling, only to see the conflict error again.

My problem is that no matter what I do, (edit out pins, compile and copy 
new dtbo to /lib/firmware), I keep getting the same conflict error. If I 
edit the dts file and change the part number to something else and load it 
manually it works so I know the change and compile is valid.

It appears that my original compiled dtbo file is somehow being 
cached/persisted through power off/power on and my updated dtbo is not 
being 'seen'.

I'd appreciate any suggestions on next steps.

Colin

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

[beagleboard] Re: Unable to update device tree overlay file

[Colin Bester]

Adding to this;

If I remove the compiled dtbo file from /lib/firmware directory and 
power-off/power-on the board running manual insert echo BB-BONE-AUDI-02  
/sys/devices/bone_capemgr.9/slots gives error write error: File Exists and 
dmesg shows BB-BONE-AUDI-02 conflict gpio1_19 (#3:BB-BONE-LCD4-01) where I 
expect it to throw error stating No such file or directory. I validated 
expected error by trying  

echo BB-BONE-AUDI-03  /sys/devices/bone_capemgr.9/slots which does give 
expected error of write error: No such file or directory

On Sunday, March 22, 2015 at 9:57:06 PM UTC-5, Colin Bester wrote:

 In adding Audio Cape (BB-BONE-AUDI-02-00A0) to beaglebone black which also 
 has LCD4 mounted I receive a GPIO 19 conflict error.

 Looking at the dts file I see it has specified exclusive use for gpio1_18 
 and gpio1_19. In the past I circumvented this error by commenting these two 
 pins out of the exclusive list and all works fine (doesn't appear that 
 these pwm pins are used by audio cape)

 Now I upgraded debian to 3.8.13-bone70 and in performing upgrade and 
 setting up new board I forgot to exclude these two pins from dts file 
 before compiling, only to see the conflict error again.

 My problem is that no matter what I do, (edit out pins, compile and copy 
 new dtbo to /lib/firmware), I keep getting the same conflict error. If I 
 edit the dts file and change the part number to something else and load it 
 manually it works so I know the change and compile is valid.

 It appears that my original compiled dtbo file is somehow being 
 cached/persisted through power off/power on and my updated dtbo is not 
 being 'seen'.

 I'd appreciate any suggestions on next steps.

 Colin



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

Re: [beagleboard] Re: Unable to update device tree overlay file

[Colin Bester]

Thanks for your rapid response.

I did originally suspect it may already be included but a system wide 
search through folders did not reveal bb-bone-audi-02.dtbo file so I 
figured it wasn't included - I guess it has a different file name.

Would suggested fix be creating by own cape based on original dts and 
giving it a different name?

~C

On Sunday, March 22, 2015 at 10:38:14 PM UTC-5, RobertCNelson wrote:

 The issue is name collision.. That dtbo is already built into the kernel. 
 Also see

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

 And search this list as we gone over it multiple times.
 On Mar 22, 2015 8:14 PM, Colin Bester bester...@gmail.com javascript: 
 wrote:

 Adding to this;

 If I remove the compiled dtbo file from /lib/firmware directory and 
 power-off/power-on the board running manual insert echo BB-BONE-AUDI-02  
 /sys/devices/bone_capemgr.9/slots gives error write error: File Exists and 
 dmesg shows BB-BONE-AUDI-02 conflict gpio1_19 (#3:BB-BONE-LCD4-01) where 
 I expect it to throw error stating No such file or directory. I validated 
 expected error by trying  

 echo BB-BONE-AUDI-03  /sys/devices/bone_capemgr.9/slots which does give 
 expected error of write error: No such file or directory

 On Sunday, March 22, 2015 at 9:57:06 PM UTC-5, Colin Bester wrote:

 In adding Audio Cape (BB-BONE-AUDI-02-00A0) to beaglebone black which 
 also has LCD4 mounted I receive a GPIO 19 conflict error.

 Looking at the dts file I see it has specified exclusive use for 
 gpio1_18 and gpio1_19. In the past I circumvented this error by commenting 
 these two pins out of the exclusive list and all works fine (doesn't appear 
 that these pwm pins are used by audio cape)

 Now I upgraded debian to 3.8.13-bone70 and in performing upgrade and 
 setting up new board I forgot to exclude these two pins from dts file 
 before compiling, only to see the conflict error again.

 My problem is that no matter what I do, (edit out pins, compile and copy 
 new dtbo to /lib/firmware), I keep getting the same conflict error. If I 
 edit the dts file and change the part number to something else and load it 
 manually it works so I know the change and compile is valid.

 It appears that my original compiled dtbo file is somehow being 
 cached/persisted through power off/power on and my updated dtbo is not 
 being 'seen'.

 I'd appreciate any suggestions on next steps.

 Colin

  -- 
 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 javascript:.
 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.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] BBB with chrony and RTC

[Colin Bester]

I am running debian  3.8.13-bone47 on Beaglebone black and have a RTC cape 
up and running (/dev/rtc1) together with chrony 1.24

If I manually run chronyd -s then it does load time from /dev/rtc1

I am wanting to be able to call trimrtc using chronyc and have inserted 
rtcfile and rtcdevice into /etc/chrony/chrony.conf

rtcfile /var/lib/chrony/chrony.rtc
rtcdevice /dev/rtc1



If I don't insert rtcfile then when running *trimrtc* in *chronyc* I get 
error of no RTC driver found. If I include the rtcfile, then I get message 
of *OK* when running trimrtc but rtcfile is not read.

Looking at syslog, if I include *rtcfile* in *chrony.conf* then I get an 
error Could not start measurement : Invalid argument but doesn't say due 
to what. I I comment out declaration of rtcfile then I get no errors when 
starting chronyd but trimrtc fails with error message of RTC driver not 
found.

Has anyone gotten chrony to work on BBB running debian and able to 
access/trim RTC?

Thanks
Colin

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

Re: [beagleboard] Re: Completely disable screensaver

[Colin Bester]

I am running on 4DCape43 LCD on Debian BBB and added 

xset -dpms
xset s off

to .xsessionrc file in user's home directory and this prevents my LCD from 
blanking after a period.

~C

On Saturday, January 18, 2014 at 10:02:10 PM UTC-6, blueboatjc wrote:

 Hi, I have tried this on my Beagle Bone Black, but it doesn't work.  I'm 
 assuming it's because I'm not using the HDMI port.  Instead I'm using 4D 
 Systems 4DCape-43 Touchscreen.  Do you have any advice or ideas on how to 
 get this to work?

 On Wednesday, November 20, 2013 3:10:26 PM UTC-5, cody wrote:

 Try this, and let me know if it works.

 **
 Prevent Monitor Sleep
 **
 Add the following to /etc/X11/xorg.conf then reboot.

 Section ServerFlags

 Option BlankTime 0

 Option StandbyTime 0

  Option SuspendTime 0

 Option OffTime 0

 EndSection
 


 Section Monitor
  Option DPMS 
 
 Identifier  Builtin Default Monitor

 EndSection


 On Wed, Nov 20, 2013 at 1:23 PM, jimmyj...@gmail.com wrote:

 On Saturday, August 31, 2013 1:40:26 PM UTC-4, Don Miller wrote:


 There is some FAQ stuff related to this (link below).  If you try it, 
 could you report back?  This was an issue for me a month or so ago, but I 
 moved on to other things and have not had a chance to play with this.

 http://circuitco.com/support/index.php?title=BeagleBone_
 Black_FAQ#Is_there_a_way_to_prevent_my_HDMI_monitor_from_
 sleeping_while_using_my_BBB.3F

 Thanks,
 Don



 I too need to have the HDMI output not blank out, and am having 
 problems.  Using the link that you provided, I did the following:

 - I went to */media/BEAGLEBONE* where */dev/mmcblk0p1* was mounted.
 - I edited *uEnv.txt* changing it from: 
 *optargs=quiet drm.debug=7*
 to
 *optargs=quiet drm.debug=7 consoleblank=0*

 then rebooted the system.  To my dismay, after ten minutes, the HDMI 
 output still blanked out.
 *(I also tried adding consoleblank=0 with double quotes around it as 
 shown in the provided link, but no luck.)*


 I did discover that the other part of information from that link does 
 work.

 When SSHed into the BBB, issuing this command:
 *   echo 0  /sys/class/graphics/fb0/blank *
 does take turn the HDMI output back on.


 Did I do something wrong with that consoleblank=0 line in uEnv.txt?  I 
 also tried adding it to the uEnv.txt file in the /boot partition.

 Thanks,

Jim

 -- 
 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.
 For more options, visit https://groups.google.com/groups/opt_out.




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

Re: [beagleboard] Beaglebone black, Debian, Setting up Wifi access point.

[Colin Bester]

Windows wifi access is working fine using device IP address. Issue I was having 
was with bonjour lookup. 

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

Re: [beagleboard] Beaglebone black, Debian, Setting up Wifi access point.

[Colin Bester]

i purchased Ralink5370 USB dongle and it is working as access point. I am 
having issues connecting with a windows client but am not yet sure on cause 
- whether its a config issue or USB wifi dongle issue.

My hostapd.conf file

```

### Default hostapd settings ## Wireless network name 
###interface=wlan0 Set your bridge name 
bridge=br0#driverdriver=nl80211country_code=USssid=biocharger_defaultchannel=7hw_mode=g#
 # Static WPA2 key configuration# #1=wpa1, 2=wpa2, 
3=bothwpa=3wpa_passphrase=apassword## Key management algorithms 
##wpa_key_mgmt=WPA-PSK### Set cipher suites (encryption algorithms)  TKIP = 
Temporal Key Integrity Protocol## CCMP = AES in Counter mode with 
CBC-MACwpa_pairwise=TKIP#rsn_pairwise=CCMP### Shared Key Authentication 
##auth_algs=1## Accept all MAC address ###macaddr_acl=0#enables/disables 
broadcasting the ssidignore_broadcast_ssid=0# Needed for Windows 
clientseapol_key_index_workaround=0

```

My udhcpd.conf file:


```

### default udhcpd configuration file ###start  192.168.4.2end
192.168.4.9interface  wlan0max_leases 8option subnet 255.255.255.248

```

My /etc/network/interfaces file (pretty much everything commented out:


```

###Default network interfaces, supporting eth0 and wlan0 configured as Access 
Pointauto loiface lo inet loopback# The primary network interfaceallow-hotplug 
eth0iface eth0 inet dhcp# WiFiallow-hotplug wlan0#iface wlan0 inet static# 
address 192.168.4.1#network 192.168.4.0#netmask 255.255.255.0#
broadcast 192.168.4.255#hostapd /etc/hostapd/hostapd.conf

```


On Monday, July 7, 2014 2:18:37 AM UTC-5, chrich...@gmail.com wrote:

 I got the same Problems. 

 Could you please tell me which dongle you bought and send me the conf-file?

 Thx, Heiko



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

Re: [beagleboard] Power down a battery backed up BeagleBone Black

[Colin Bester]

Several observations.

When pressing power button or executing halt instruction, processor does 
shutdown but the voltage rails SYS_5V and VLD02 don't (I didn't check 
VLDO01). VLDO2 does drop to less than 2V but appears to still be enough to 
trigger U4 TL5209's enable pin thus switching SYS_5V to VDD_3V3B. This to 
me doesn't look right, this level (VLD02) should either be asserted or 
negated and not in between levels.

Powering up with just battery and no 5V (not pressing any buttons) shows 
SYS-5V active high (5V) and VLD02 at expected 0V.

Looks to me like there is a power switching problem although fixing this 
still won't fix the issue I am having as I want to totally switch off LCD4 
which is using SYS_5V for backlight. I am not sure from the tech notes if 
it's possible or not to switch off SYS_5V voltage (Pins 7.8 SYS1/SYS2 on 
TPS65217C).

If one can't then my question to LCD module supplier/manufacturer is how 
did they intend us to shut device down with a battery connected.

~C

On Monday, June 23, 2014 6:52:03 PM UTC-5, john3909 wrote:


 Power Button is also on P9 Pin 9. BTW, sudo halt powers off all power 
 rails and is functionally equivalent to holding the power button for 10 
 seconds. If your LCD backlight is still on, then it is powered from the 5V 
 rail because all other power rails are off. 

 Regards,
 John




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

[beagleboard] PCManFM consuming cpu

[Colin Bester]

Has anyone experienced slow down on BBB running latest debian due to PCManFM 
consuming  50% cpu?

I installed debain, ran apt-get update, apt-get upgrade then ran command to 
upgrade bonescript.

All ran fine, no errors and system was behaving. 

top showed nothing weird and PCManFM was no where near top of the list. 
After a short while however the BBB started slowing down and now PCManFM is 
up in the 50%'s

~C

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

Re: [beagleboard] BBB LCD3 Cape and inactivity

[Colin Bester]

I just managed to get around to looking a little deeper into this and connected 
an oscilloscope to EHRPWM1A (which I figure is pin P9_14) and confirm that when 
writing a zero to brightness (using echo 0  
/sys/class/backlight/backlight.11/brightness) that the pin is low. Likewise 
write a '50' sets a 50% duty cycle and LCD brightens. I haven't set up 
environment to compile and test using 'c' files yet.

With low on pin P9_14 the LCD is still visible.

With debian version I now have running, I have not seen the LCD goto sleep yet 
- still have to look into this.

~C


On May 26, 2014, at 8:03 PM, John Syn john3...@gmail.com wrote:

 
 From: Colin Bester bester.co...@gmail.com
 Reply-To: beagleboard@googlegroups.com
 Date: Monday, May 26, 2014 at 4:54 PM
 To: beagleboard@googlegroups.com
 Subject: Re: [beagleboard] BBB LCD3 Cape and inactivity
 
 Was wondering if you have come up with any further solution? I can write '0' 
 to backlight brightness but while this dims the display significantly it 
 doesn't switch if off.
 
 Have you checked that EHRPWM1A is low when you dim the display? Here are two 
 files that will control the backlight.
 
 /driver/video/backlight/pwm_bl.c
 /driver/pwm/pwm-tiehrpwm.c
 
 Regards
 John



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

Re: [beagleboard] BBB LCD3 Cape and inactivity

[Colin Bester]

I'd agree except I am seeing it with two different LCD modules BB-View and Cape 
LCD3  LCD4 - different designs, different circuit, different manufacturer.

I'll have to noodle on it.

~C

On May 29, 2014, at 1:42 PM, John Syn john3...@gmail.com wrote:

 
 From: Colin Bester bester.co...@gmail.com
 Reply-To: beagleboard@googlegroups.com
 Date: Thursday, May 29, 2014 at 6:45 AM
 To: beagleboard@googlegroups.com
 Subject: Re: [beagleboard] BBB LCD3 Cape and inactivity
 
 I just managed to get around to looking a little deeper into this and 
 connected an oscilloscope to EHRPWM1A (which I figure is pin P9_14) and 
 confirm that when writing a zero to brightness (using echo 0  
 /sys/class/backlight/backlight.11/brightness) that the pin is low. Likewise 
 write a '50' sets a 50% duty cycle and LCD brightens. I haven't set up 
 environment to compile and test using 'c' files yet.
 
 With low on pin P9_14 the LCD is still visible.
 
 In that case this is a hardware issue. P9_14 is connected to the enable pin 
 of the LED backplane driver so the leds should turn off. 
 
 Regards,
 John

Internet Disclaimer
_

This message (including any attachments) contains confidential information 
intended for a specific individual and purpose, and may be protected by law. 
If you are not the intended recipient, you should delete this message and are 
hereby notified that any disclosure, copying, or distribution of this message, 
or the taking of any action based on it, is strictly prohibited.
_



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

[beagleboard] Using /etc/init/_.conf for autostarting services

[Colin Bester]

I am looking to add a auto start service using conf file in /etc/init but 
it seems that debian version on BBB presently only supports older style 
/etc/init.d sys  init scripts.

I thought I'd ask the group before starting to add packages to install on 
whether this newer version is supported or should I go straight to using 
systemd for startup of services.

My aim is not to stray to far from base debian image in these early days.

~C

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

Re: [beagleboard] Using /etc/init/_.conf for autostarting services

[Colin Bester]

Thanks

On May 28, 2014, at 8:28 AM, Robert Nelson robertcnel...@gmail.com wrote:

 On Wed, May 28, 2014 at 8:15 AM, Colin Bester bester.co...@gmail.com wrote:
 I am looking to add a auto start service using conf file in /etc/init but it
 seems that debian version on BBB presently only supports older style
 /etc/init.d sys  init scripts.
 
 I thought I'd ask the group before starting to add packages to install on
 whether this newer version is supported or should I go straight to using
 systemd for startup of services.
 
 My aim is not to stray to far from base debian image in these early days.
 
 systemd is enabled in the debian image here:
 
 http://beagleboard.org/latest-images
 
 and /etc/init.d/* style script are still run in a systemd
 compatibility script.
 
 Regards,
 
 -- 
 Robert Nelson
 http://www.rcn-ee.com/
 
 -- 
 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/oLbHuHWUL2M/unsubscribe.
 To unsubscribe from this group and all its topics, send an email to 
 beagleboard+unsubscr...@googlegroups.com.
 For more options, visit https://groups.google.com/d/optout.

Internet Disclaimer
_

This message (including any attachments) contains confidential information 
intended for a specific individual and purpose, and may be protected by law. 
If you are not the intended recipient, you should delete this message and are 
hereby notified that any disclosure, copying, or distribution of this message, 
or the taking of any action based on it, is strictly prohibited.
_



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

Re: [beagleboard] Using /etc/init/_.conf for autostarting services

[Colin Bester]

No right or wrong, I just want to get away from init.d. I far prefer concept of 
systemd, but confusion reigns due to my lack of knowledge, time to read!

On May 28, 2014, at 1:36 PM, William Hermans yyrk...@gmail.com wrote:

 init.d can be made to run a service at boot up too. Is there a problem with 
 this ?
 
 http://www.embeddedhobbyist.com/debian-tips/beaglebone-black/beaglebone-black-init-scripts-default-gatewayand-ntpdate/
 
 
 On Wed, May 28, 2014 at 6:30 AM, Colin Bester bester.co...@gmail.com wrote:
 Thanks
 
 On May 28, 2014, at 8:28 AM, Robert Nelson robertcnel...@gmail.com wrote:
 
  On Wed, May 28, 2014 at 8:15 AM, Colin Bester bester.co...@gmail.com 
  wrote:
  I am looking to add a auto start service using conf file in /etc/init but 
  it
  seems that debian version on BBB presently only supports older style
  /etc/init.d sys  init scripts.
 
  I thought I'd ask the group before starting to add packages to install on
  whether this newer version is supported or should I go straight to using
  systemd for startup of services.
 
  My aim is not to stray to far from base debian image in these early days.
 
  systemd is enabled in the debian image here:
 
  http://beagleboard.org/latest-images
 
  and /etc/init.d/* style script are still run in a systemd
  compatibility script.
 
  Regards,
 
  --
  Robert Nelson
  http://www.rcn-ee.com/
 
  --
  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/oLbHuHWUL2M/unsubscribe.
  To unsubscribe from this group and all its topics, send an email to 
  beagleboard+unsubscr...@googlegroups.com.
  For more options, visit https://groups.google.com/d/optout.
 
 Internet Disclaimer
 _
 
 This message (including any attachments) contains confidential information 
 intended for a specific individual and purpose, and may be protected by law.
 If you are not the intended recipient, you should delete this message and are 
 hereby notified that any disclosure, copying, or distribution of this 
 message, or the taking of any action based on it, is strictly prohibited.
 _
 
 
 
 --
 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.
 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/oLbHuHWUL2M/unsubscribe.
 To unsubscribe from this group and all its topics, send an email to 
 beagleboard+unsubscr...@googlegroups.com.
 For more options, visit https://groups.google.com/d/optout.

Internet Disclaimer
_

This message (including any attachments) contains confidential information 
intended for a specific individual and purpose, and may be protected by law. 
If you are not the intended recipient, you should delete this message and are 
hereby notified that any disclosure, copying, or distribution of this message, 
or the taking of any action based on it, is strictly prohibited.
_



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

Re: [beagleboard] Using /etc/init/_.conf for autostarting services

[Colin Bester]

It's crazy. I have been in software for longer than I care to mention but last 
time I dug deep into Linux was about 8 maybe 10 years ago - so much is the 
same, but so much is different!

On May 28, 2014, at 1:56 PM, William Hermans yyrk...@gmail.com wrote:

 Or more correctly in this case I should say The Wheezy way, since Debian 
 things have been changing fairly rapidly the last few years it seems.
 
 
 On Wed, May 28, 2014 at 11:55 AM, William Hermans yyrk...@gmail.com wrote:
 Ah, ok, I get that. but I'm more of a traditional the Debian way kind of 
 person.
 
 
 On Wed, May 28, 2014 at 11:42 AM, Colin Bester bester.co...@gmail.com wrote:
 No right or wrong, I just want to get away from init.d. I far prefer concept 
 of systemd, but confusion reigns due to my lack of knowledge, time to read!
 
 On May 28, 2014, at 1:36 PM, William Hermans yyrk...@gmail.com wrote:
 
 init.d can be made to run a service at boot up too. Is there a problem with 
 this ?
 
 http://www.embeddedhobbyist.com/debian-tips/beaglebone-black/beaglebone-black-init-scripts-default-gatewayand-ntpdate/
 
 
 On Wed, May 28, 2014 at 6:30 AM, Colin Bester bester.co...@gmail.com wrote:
 Thanks
 
 On May 28, 2014, at 8:28 AM, Robert Nelson robertcnel...@gmail.com wrote:
 
  On Wed, May 28, 2014 at 8:15 AM, Colin Bester bester.co...@gmail.com 
  wrote:
  I am looking to add a auto start service using conf file in /etc/init but 
  it
  seems that debian version on BBB presently only supports older style
  /etc/init.d sys  init scripts.
 
  I thought I'd ask the group before starting to add packages to install on
  whether this newer version is supported or should I go straight to using
  systemd for startup of services.
 
  My aim is not to stray to far from base debian image in these early days.
 
  systemd is enabled in the debian image here:
 
  http://beagleboard.org/latest-images
 
  and /etc/init.d/* style script are still run in a systemd
  compatibility script.
 
  Regards,
 
  --
  Robert Nelson
  http://www.rcn-ee.com/
 
  --
  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/oLbHuHWUL2M/unsubscribe.
  To unsubscribe from this group and all its topics, send an email to 
  beagleboard+unsubscr...@googlegroups.com.
  For more options, visit https://groups.google.com/d/optout.
 
 Internet Disclaimer
 _
 
 This message (including any attachments) contains confidential information 
 intended for a specific individual and purpose, and may be protected by law.
 If you are not the intended recipient, you should delete this message and 
 are hereby notified that any disclosure, copying, or distribution of this 
 message, or the taking of any action based on it, is strictly prohibited.
 _
 
 
 
 --
 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.
 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/oLbHuHWUL2M/unsubscribe.
 To unsubscribe from this group and all its topics, send an email to 
 beagleboard+unsubscr...@googlegroups.com.
 For more options, visit https://groups.google.com/d/optout.
 
 Internet Disclaimer
 _
 
 This message (including any attachments) contains confidential information 
 intended for a specific individual and purpose, and may be protected by law. 
 If you are not the intended recipient, you should delete this message and are 
 hereby notified that any disclosure, copying, or distribution of this 
 message, or the taking of any action based on it, is strictly prohibited.
 _
 
 
 
 
 -- 
 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.
 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/oLbHuHWUL2M/unsubscribe.
 To unsubscribe from this group and all its topics, send an email to 
 beagleboard+unsubscr...@googlegroups.com.
 For more options

Re: [beagleboard] Using /etc/init/_.conf for autostarting services

[Colin Bester]

Yup, for now it's the way forward. Actually pretty easy all in all and I do 
like the concepts. I am battling a bit with ordering startup, but will push 
through!

~C

On May 28, 2014, at 2:05 PM, John Syn john3...@gmail.com wrote:

 
 From: William Hermans yyrk...@gmail.com
 Reply-To: beagleboard@googlegroups.com
 Date: Wednesday, May 28, 2014 at 11:56 AM
 To: beagleboard@googlegroups.com
 Subject: Re: [beagleboard] Using /etc/init/_.conf for autostarting services
 
 Or more correctly in this case I should say The Wheezy way, since Debian 
 things have been changing fairly rapidly the last few years it seems.
 
 Yeah, but systemd has won so we all have to get use to it ;-)
 
 
 
 On Wed, May 28, 2014 at 11:55 AM, William Hermans yyrk...@gmail.com wrote:
 Ah, ok, I get that. but I'm more of a traditional the Debian way kind of 
 person.
 
 
 On Wed, May 28, 2014 at 11:42 AM, Colin Bester bester.co...@gmail.com 
 wrote:
 No right or wrong, I just want to get away from init.d. I far prefer 
 concept of systemd, but confusion reigns due to my lack of knowledge, time 
 to read!
 
 On May 28, 2014, at 1:36 PM, William Hermans yyrk...@gmail.com wrote:
 
 init.d can be made to run a service at boot up too. Is there a problem 
 with this ?
 
 http://www.embeddedhobbyist.com/debian-tips/beaglebone-black/beaglebone-black-init-scripts-default-gatewayand-ntpdate/
 
 
 On Wed, May 28, 2014 at 6:30 AM, Colin Bester bester.co...@gmail.com 
 wrote:
 Thanks
 
 On May 28, 2014, at 8:28 AM, Robert Nelson robertcnel...@gmail.com 
 wrote:
 
  On Wed, May 28, 2014 at 8:15 AM, Colin Bester bester.co...@gmail.com 
  wrote:
  I am looking to add a auto start service using conf file in /etc/init 
  but it
  seems that debian version on BBB presently only supports older style
  /etc/init.d sys  init scripts.
 
  I thought I'd ask the group before starting to add packages to 
  install on
  whether this newer version is supported or should I go straight to 
  using
  systemd for startup of services.
 
  My aim is not to stray to far from base debian image in these early 
  days.
 
  systemd is enabled in the debian image here:
 
  http://beagleboard.org/latest-images
 
  and /etc/init.d/* style script are still run in a systemd
  compatibility script.
 
  Regards,
 
  --
  Robert Nelson
  http://www.rcn-ee.com/
 
  --
  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/oLbHuHWUL2M/unsubscribe.
  To unsubscribe from this group and all its topics, send an email to 
  beagleboard+unsubscr...@googlegroups.com.
  For more options, visit https://groups.google.com/d/optout.
 
 Internet Disclaimer
 _
 
 This message (including any attachments) contains confidential 
 information intended for a specific individual and purpose, and may be 
 protected by law.
 If you are not the intended recipient, you should delete this message 
 and are hereby notified that any disclosure, copying, or distribution of 
 this message, or the taking of any action based on it, is strictly 
 prohibited.
 _
 
 
 
 --
 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.
 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/oLbHuHWUL2M/unsubscribe.
 To unsubscribe from this group and all its topics, send an email to 
 beagleboard+unsubscr...@googlegroups.com.
 For more options, visit https://groups.google.com/d/optout.
 
 Internet Disclaimer
 _
 
 This message (including any attachments) contains confidential information 
 intended for a specific individual and purpose, and may be protected by 
 law. 
 If you are not the intended recipient, you should delete this message and 
 are hereby notified that any disclosure, copying, or distribution of this 
 message, or the taking of any action based on it, is strictly prohibited.
 _
 
 
 
 
 -- 
 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.
 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

Re: [beagleboard] Using /etc/init/_.conf for autostarting services

[Colin Bester]

Thanks!

On May 28, 2014, at 2:40 PM, John Syn john3...@gmail.com wrote:

 From: Colin Bester bester.co...@gmail.com
 Reply-To: beagleboard@googlegroups.com
 Date: Wednesday, May 28, 2014 at 12:22 PM
 To: beagleboard@googlegroups.com
 Subject: Re: [beagleboard] Using /etc/init/_.conf for autostarting services
 
 Yup, for now it's the way forward. Actually pretty easy all in all and I do 
 like the concepts. I am battling a bit with ordering startup, but will push 
 through!
 
 You should stop top posting as this isn't considered good etiquette. Rather 
 post your response just below the text you are responding to so everyone 
 understand the context of your response. With that out the way, the order is 
 determined by it's dependency. Systemd will wait for the dependency to 
 complete before starting this service. When there is no dependency, services 
 are started in parallel. This is why Systemd is so much faster. 
 
 systemd-analyze blame
 
 Will help you understand the startup order.
 
 Regards,
 John

Internet Disclaimer
_

This message (including any attachments) contains confidential information 
intended for a specific individual and purpose, and may be protected by law. 
If you are not the intended recipient, you should delete this message and are 
hereby notified that any disclosure, copying, or distribution of this message, 
or the taking of any action based on it, is strictly prohibited.
_



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

Re: [beagleboard] BBB LCD3 Cape and inactivity

[Colin Bester]

John, did you mean to attach files or are they available in a download 
bundle?

On Monday, May 26, 2014 8:03:23 PM UTC-5, john3909 wrote:


 From: Colin Bester bester...@gmail.com javascript:
 Reply-To: beagl...@googlegroups.com javascript:
 Date: Monday, May 26, 2014 at 4:54 PM
 To: beagl...@googlegroups.com javascript:
 Subject: Re: [beagleboard] BBB LCD3 Cape and inactivity

 Was wondering if you have come up with any further solution? I can write 
 '0' to backlight brightness but while this dims the display significantly 
 it doesn't switch if off.

 Have you checked that EHRPWM1A is low when you dim the display? Here are 
 two files that will control the backlight.

 /driver/video/backlight/pwm_bl.c
 /driver/pwm/pwm-tiehrpwm.c

 Regards
 John



 On Thursday, December 19, 2013 3:07:52 PM UTC-6, Daniel Metcalf wrote:

 Yes, I have experienced it and am still working on a solution.

 Dan
 On Dec 19, 2013 11:03 AM, Colin Bester bester...@gmail.com wrote:

 I have a beaglebone black with lcd3 cape installed and all appears find 
 on startup.

 After a while of inactivity, the displays appears to go into some form 
 of sleep or screen saver mode but backlight stays on. i.e., The normal GDM 
 screen with background and icons switches to an all white display (just 
 backlight).

 Is anyone else experiencing this?

 I would expect the backlight to switch off as well.

 Cheers
 Colin

 -- 
 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.
 For more options, visit https://groups.google.com/groups/opt_out.

 -- 
 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 javascript:.
 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.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] BBB LCD3 Cape and inactivity

[Colin Bester]

Was wondering if you have come up with any further solution? I can write 
'0' to backlight brightness but while this dims the display significantly 
it doesn't switch if off.

On Thursday, December 19, 2013 3:07:52 PM UTC-6, Daniel Metcalf wrote:

 Yes, I have experienced it and am still working on a solution.

 Dan
 On Dec 19, 2013 11:03 AM, Colin Bester bester...@gmail.comjavascript: 
 wrote:

 I have a beaglebone black with lcd3 cape installed and all appears find 
 on startup.

 After a while of inactivity, the displays appears to go into some form of 
 sleep or screen saver mode but backlight stays on. i.e., The normal GDM 
 screen with background and icons switches to an all white display (just 
 backlight).

 Is anyone else experiencing this?

 I would expect the backlight to switch off as well.

 Cheers
 Colin

 -- 
 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 javascript:.
 For more options, visit https://groups.google.com/groups/opt_out.



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

Re: [beagleboard] BBB LCD3 Cape and inactivity

[Colin Bester]

Thanks John, I will look deeper into this.I have actually just switched over to 
debian OS and will test.

One test I did do today was to write  a zero '0' to brightness by executing 
echo 0  /sys/class/backlight/backlight.11/brightness

This did reduce the brightness but didn't take it to zero light but does dim 
the display. Likewise a 50 is brighter and 100 is brightest.

I am not sure if this is related in any way at all but will look more tomorrow.

Cheers and thanks
Colin

On May 26, 2014, at 8:03 PM, John Syn john3...@gmail.com wrote:

 
 From: Colin Bester bester.co...@gmail.com
 Reply-To: beagleboard@googlegroups.com
 Date: Monday, May 26, 2014 at 4:54 PM
 To: beagleboard@googlegroups.com
 Subject: Re: [beagleboard] BBB LCD3 Cape and inactivity
 
 Was wondering if you have come up with any further solution? I can write '0' 
 to backlight brightness but while this dims the display significantly it 
 doesn't switch if off.
 Have you checked that EHRPWM1A is low when you dim the display? Here are two 
 files that will control the backlight.
 
 /driver/video/backlight/pwm_bl.c
 /driver/pwm/pwm-tiehrpwm.c
 
 Regards
 John
 
 
 On Thursday, December 19, 2013 3:07:52 PM UTC-6, Daniel Metcalf wrote:
 Yes, I have experienced it and am still working on a solution.
 Dan
 On Dec 19, 2013 11:03 AM, Colin Bester bester...@gmail.com wrote:
 I have a beaglebone black with lcd3 cape installed and all appears find on 
 startup.
 
 After a while of inactivity, the displays appears to go into some form of 
 sleep or screen saver mode but backlight stays on. i.e., The normal GDM 
 screen with background and icons switches to an all white display (just 
 backlight).
 
 Is anyone else experiencing this?
 
 I would expect the backlight to switch off as well.
 
 Cheers
 Colin
 
 -- 
 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.
 For more options, visit https://groups.google.com/groups/opt_out.
 
 -- 
 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.
 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/d_6HC6ps2RU/unsubscribe.
 To unsubscribe from this group and all its topics, send an email to 
 beagleboard+unsubscr...@googlegroups.com.
 For more options, visit https://groups.google.com/d/optout.

Internet Disclaimer
_

This message (including any attachments) contains confidential information 
intended for a specific individual and purpose, and may be protected by law. 
If you are not the intended recipient, you should delete this message and are 
hereby notified that any disclosure, copying, or distribution of this message, 
or the taking of any action based on it, is strictly prohibited.
_



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

[beagleboard] BBB, BB-View and I2C

[Colin Bester]

I am using  a beagle bone with angstrom os and bb-view 4.3 inch LCD and am 
wanting to use i2c as well.

I see that the bb-view uses pins P9-17/18 which are i2c1 but that is also 
uses P-20 as GPIO for LED1 which seems rather silly to blow a I2C port for 
simple digital output.

Question is can I still somehow use I2C 2 (Pins P9_19/20) as I2C? Can I 
somehow disable LCD's use of this pin?

~Colin

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

Re: [beagleboard] Beaglebone black, Debian, Setting up Wifi access point.

[Colin Bester]

Hi Jim, appreciate your feedback. After many devices I have also ended up using 
RT5370 chipset with no messing around - amazing how much time one can spend on 
this.

Thanks again
Colin

On May 6, 2014, at 5:53 AM, jim.blake...@gmail.com wrote:

 Hi Colin,
 
 I too have had some real bad experiences, but I now have an AP running 
 reliably. First thing to do is to get a USB Wireless dongle that uses the  
 RT5370 Chipset, its the easiest one to work with, and the most reliable, I've 
 found.
 
 I'm away from my office at the moment, otherwise I would post up the 
 hostapd.conf file I'm usingif you decide to use the 5370 chipset, respond 
 to this message and I'll give you the file.
 
 Aside from that, my deployment is a basic apt-get-driven job, on standard Arm 
 Wheezy...nothing clever
 
 Hope this helps
 
 Jim
 
 
 -- 
 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/Nx9kimlSoWE/unsubscribe.
 To unsubscribe from this group and all its topics, send an email to 
 beagleboard+unsubscr...@googlegroups.com.
 For more options, visit https://groups.google.com/d/optout.

Internet Disclaimer
_

This message (including any attachments) contains confidential information 
intended for a specific individual and purpose, and may be protected by law. 
If you are not the intended recipient, you should delete this message and are 
hereby notified that any disclosure, copying, or distribution of this message, 
or the taking of any action based on it, is strictly prohibited.
_



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

[beagleboard] Re: Wifi dongle uwn100 with Ralink chipset MT7610U can work in AP mode ?

[Colin Bester]

I am also having issues trying to get device to work as access point - 
maybe there is another solution but my problem appears to be due to missing 
nl80211. Any assistance appreciated.

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

[beagleboard] Beaglebone black, Debian, Setting up Wifi access point.

[Colin Bester]

Has anyone managed to get an access point up and running using latest 
debian image on beaglebone black?

I have installed latest debian image and have run apt-get update and 
apt-get upgrade. I have installed iw and hostapd.

My USB Wifi dongle (uwn100, which supports access point mode) is working 
and reliably connects to my external access point, but I am unable to 
configure the BBB to run as an access point.

Error seems to be related to missing NL80211 driver. Also running 'iw list' 
gives error stating that nl80211 can not be found.

I would appreciate input from anyone who has managed to get this working.

There are a ton of posts out there but non really address the issue or are 
pretty out of date.

Much appreciated,
Colin

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

Re: [beagleboard] Battery backed BBB shuts down on applying 5V external power

[Colin Bester]

It does appear as if some S/W will be in order. This is still a TODO on my 
list, just not as high a priority for now. Will post my findings.

On Tuesday, November 19, 2013 4:38:11 PM UTC-6, Gerald wrote:

 Sounds to me like the SW cannot handle the reapplication of the 5V. I 
 think it supplies an interrupt to the processor when 5V is reapplied  Check 
 the datasheet of the TPS65217C. If it does, all SW thinks is that the power 
 button was pressed and that you want to power down.

 Bottom line is I think you need to so some SW work to make this all work.

 Gerald



 On Tue, Nov 19, 2013 at 12:51 PM, Colin Bester 
 bester...@gmail.comjavascript:
  wrote:

 I have a Li-Ion battery connected to BBB (A6) to supply backup power in 
 case of 5V power failure. If starting with 5V connected and I remove 5V the 
 board continues to run as expected with no issues. If I then re-apply 5V 
 power to power connector after a short while the BBB shuts down. I assume 
 it's in the OFF mode as pressing the POWER button will cause board to wake 
 up.

 If I start with just battery power and no 5V connected by pressing the 
 POWER button to start (wake up) board then the board runs fine until I 
 apply 5V power which again causes board to shutdown.

 Has anyone experienced this or have any suggestions?

 Thanks,
 Colin

 -- 
 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 javascript:.
 For more options, visit https://groups.google.com/groups/opt_out.




-- 
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.
For more options, visit https://groups.google.com/groups/opt_out.

[beagleboard] Battery backed BBB shuts down on applying 5V external power

[Colin Bester]

I have a Li-Ion battery connected to BBB (A6) to supply backup power in 
case of 5V power failure. If starting with 5V connected and I remove 5V the 
board continues to run as expected with no issues. If I then re-apply 5V 
power to power connector after a short while the BBB shuts down. I assume 
it's in the OFF mode as pressing the POWER button will cause board to wake 
up.

If I start with just battery power and no 5V connected by pressing the 
POWER button to start (wake up) board then the board runs fine until I 
apply 5V power which again causes board to shutdown.

Has anyone experienced this or have any suggestions?

Thanks,
Colin

-- 
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.
For more options, visit https://groups.google.com/groups/opt_out.