date:20140916

I have a rev A6 (I think) BBB with the 2Gb eMMC memory.  I installed a
microSd card with Ubuntu on it and it has been booting from that quite
happily for the past few months.

I now seem to have currupted the Ubuntu image on the microSD card such
that it no longer boots successfully.  If I remove the microSD then
the BBB boots OK from the eMMC into Angstrom.

Is there any way I can force the BBB to boot from eMMC even though
there's a microSD card plugged in?  I want to recover some files from
the microSD card and I'm away from home and don't have any other means
of reading the microSD.

I do also have a revC BBB here but I guess that isn't going to act any
differently from the older one.

-- 
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.

[beagleboard] Re: Adafruit serial UART library seems to have wrong tty names

Michel Lavoie lavoie.mic...@gmail.com wrote:
 [-- text/plain, encoding quoted-printable, charset: UTF-8, 81 lines --]
 
 I strongly recommend that you read Adafruit's guide regarding the BBB's 
 device tree overlay. It really help me put this all together: 
 https://learn.adafruit.com/introduction-to-the-beaglebone-black-device-tree/overview
 
 You will find there why and how to modify your uEnv.txt file in order to 
 enable ttyO1. In mine, the last line looks like this:
 
 ...
 optargs=coherent_pool=1M; capemgr.enable_partno=BB-UART1,BB-SPIDEV0
 
 optargs=coherent_pool=1M; capemgr.enable_partno=BB-UART1,BB-SPIDEV0
 
 optargs=coherent_pool=1M; capemgr.enable_partno=BB-UART1,BB-SPIDEV0
 
 optargs=coherent_pool=1M; capemgr.enable_partno=BB-UART1,BB-SPIDEV0
 
 
The Adafruit UART IO documentation specifically says that it *does*
export the overlays:-

The Adafruit IO Python library will export the UART device tree
overlays as a convenience. There are five serial ports brought to
the expansion headers (UART3 only has a single direction, TX), and
one (UART0) with dedicated headers that aren't available to use in
your Python programs.

... but not all the UARTs work.

In addition the use of the letter O in the device name is just silly! :-)

The devices it creates are called /dev/ttyO1, /dev/ttyO2, etc. with
the letter O.  There's not a mention anywhere that it's a letter
rather than a digit and given the context it's second nature to assume
it's a zero.  Still I did spot that eventually.

-- 
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] Re: prussdrv to remoteproc

2014-09-16 Thread Kumar Abhishek

Hi,

There isn't really a hello world for remoteproc as you would have to 
write a kernel module or modify the remoteproc kernel module to do anything 
concrete with the PRU remoteproc driver as of now. Plus if vrings do not 
really suit your application, then you will have to develop your own 
userspace layer to expose functionality to userspace. I've done it with a 
character device in BeagleLogic - the buffers can be read(), mmap()-ed, and 
poll()-ed, and there's some sysfs attributes and ioctl()'s for 
configuration. You might want to think of other possibilities depending 
upon your application.

The basic unit of communication between remoteproc and the PRU as of now is 
using *downcalls* and *syscalls*.

A *syscall *is when the PRU raises an IRQ and halts itself, storing some 
values in its registers. The kernel module handles the syscall IRQ, it 
reads the registers, manipulates them and resumes the PRU over the HALT 
instruction. See here 
https://github.com/abhishek-kakkar/BeagleLogic/blob/master/beaglelogic-firmware/pru_syscalls.asm
 
for an example code of the syscall on the PRU side.

A *downcall *is initiated by the kernel module. Think of it as calling a 
function in the PRU from the kernel module and receiving the return value 
back in the kernel module.
*The PRU has to be polling for the downcall, and it acknowledges with a 
special syscall. Then the function handle_downcall is called, which 
receives the downcall value and the parameters. So the handle_downcall 
(example 
https://github.com/abhishek-kakkar/BeagleLogic/blob/master/beaglelogic-firmware/beaglelogic-pru0.c#L106)
 
is a switch-case thing where the PRU does something and once it returns 
from this function, there is a syscall triggered which signals that the 
downcall is complete, the kernel module reads the return value of the 
function, after which the downcalling function in the kernel module returns 
with the return value.*

I can go on and make thjs post TL;DR but the crux is that remoteproc 
currently is very application-specific and you have to twist and adapt the 
kernel module to your needs. Once the remoteproc stuff gets finalized, 
ideally there would be a generic framework and userspace layer on top of 
the driver to allow you to write your own applications from userspace, in a 
similar way as it is currently done using libprussdrv.

I'm speaking all this from experience gained while developing BeagleLogic, 
and that was for the 3.8.13 kernel. With the BeagleBoard community now 
migrating to a 3.14 based kernel, BeagleLogic will have to be ported to 
3.14 which uses a new pru_rproc driver , and I will see how it can be done 
as there are differences between them, and some functionality will have to 
be added to the new driver.

Unfortunately I believe wading through thousands line of code would be the 
only option for now if you want to develop a new application.

On Tuesday, September 16, 2014 9:27:24 AM UTC+5:30, William Hermans wrote:

 And by examples, I mean an introductory hello world app. Not an already 
 working project with tens of thousands of lines of code to wade through.

 On Mon, Sep 15, 2014 at 8:51 PM, William Hermans yyr...@gmail.com 
 javascript: wrote:

 So where are the PRU examples of this ? To me this whole concept sounds 
 very far fetched, but I will be the first to admit this would be a very 
 very cool feature.

 On Mon, Sep 15, 2014 at 8:10 PM, Jason Kridner jkri...@beagleboard.org 
 javascript: wrote:

 On Sat, Sep 13, 2014 at 5:10 PM, Michael M mmcda...@gmail.com 
 javascript: wrote:
  I believe that PRUSpeak(https://github.com/deepakkarki/pruspeak/) 
 makes use
  of remoteproc. I haven't made the transition yet, but I'm definitely 
 curious
  about it. The complexity of implementing remoteproc seems much, much 
 greater
  than using UIO or /dev/mem mapping. What is the benefit of using 
 remoteproc
  over the other methods?

 I'm not sure of all the advantages, but here are some:
 * The more Linux way to do it with the remote processor being
 abstracted as a processor and not just some random memory mapped thing
 * Uses the kernel firmware loader making managing firmware something
 that can be easily coupled with the kernel and standard file formats
 * Processor-agnostic communication abstractions such that
 platform-specific remoteproc drivers only need to provide a few
 low-level handlers, and then all rpmsg drivers will then just work[1]
 * From a performance perspective, it enables handing of remote
 processor events from the kernel level which avoids a userspace
 context switch
 * Vring communication can be rather efficient as seen in the case of 
 BeagleLogic

 [1] 
 https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/Documentation/remoteproc.txt

 
 
  On Friday, September 12, 2014 5:57:17 AM UTC-7, Cedric Malitte wrote:
 
 
 
  Le vendredi 12 septembre 2014 04:11:18 UTC-4, Jon E a écrit :
 
  Hi,
 
  Anyone know of example code that's using the newer remoteproc

Re: [beagleboard] Re: Beaglebone Black Rebooting Several Times Every Day

2014-09-16 Thread Greg Kelley

Update: I changed power supplies back to the 5v2a and removed wicd 
yesterday at 3:20pm. Ran fine until 8:42am and reset after 16hrs. This 
time, it didn't bring up eth0 and was unreachable. I pulled the power and 
powered back up, booted normally. Interesting thing is that syslog only 
shows the second boot on power up and not the reset reboot. Syslog was 
fresh at 6:25am and shows only one bootup sequence. Strange. I was hoping 
resets were from wicd, guess not. Problem still exists. I could deal with a 
single reset every day, but not when eth0 fails as my weather server 
uploads ftp files to my website every 15 minutes. I lost eth0 on reset back 
on 9/11 at 8:13am, so loss of eth0 is random in the resets. I have a 
Phihong Switching Power Supply 5v2a that I'm going to put on there and see 
if that helps, but unlikely since Thomas has lab quality power and all of 
his are resetting. Here's what's left in rc2.d, I have removed S06weewx for 
now (as well as apache2 and saned).

README  S01motd S03cron S03ssh   S05cups
S01boot_scripts.sh  S01rsyslog  S03dbus S03udhcpdS06rc.local
S01capemgr.sh   S01sudo S03loadcpufreq  S04avahi-daemon 
 S06rmnologin
S01hostapd  S01xrdp S03ntp  S04cpufrequtils
S01leds-off S03acpidS03rsyncS05bootlogs




-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because 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: Beaglebone Black Rebooting Several Times Every Day

2014-09-16 Thread Greg Kelley

One other note, current Debian distro that comes with BBB has ntpdate 
installed. I have removed ntpdate and installed ntp in it's place.

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because 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: Beaglebone Black Rebooting Several Times Every Day

2014-09-16 Thread Greg Kelley

I just changed over to the Switching Power Supply and eth0 failed to come 
up on boot. I hit the reset button and a reboot brought it up. So now it 
seems there are eth0 issues as well as resets. Going from bad to worse.

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because 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] Custom Audio cape with TLV320AIC3107 codec.

2014-09-16 Thread Jesse Cobra

What happens when you try the CircuitCO audio cape?
Does it work fine?

On Mon, Sep 15, 2014 at 10:14 PM, Prakash Parmar prakash.parma...@gmail.com
 wrote:

 Hi,

 How I can check this two things ?

 2) check if SYS_RESET is actually deasserted and high
 3) check if DIN/DOUT are correctly connected and not flipped, because DIN
 data must go into CODEC, while DOUT must go out and vise versa

 I'm not clear about this. Actually I have two Boards one with 10K
 resistors and one with 4.6K .

 Thanks  Regards,
 Prakash P.

 On Tue, Sep 16, 2014 at 12:34 AM, Maxim Podbereznyy lisar...@gmail.com
 wrote:

 what is exactly not clear for you?

 how to change resistors or how to copy/paste commands in a shell?

 2014-09-15 21:46 GMT+04:00 prakash.parma...@gmail.com:

 HI,
 Thanks For reply.

 Can you please tell me how I can Do that ?


 Thanks  Regards,
 Prakash P.

 On Monday, September 15, 2014 8:01:19 PM UTC+5:30, liyaoshi wrote:

 Have you config the i2c pin pulled up ?
 and
 whats the speed of your i2c bus ?

 2014-09-15 2:09 GMT+08:00 prakash@gmail.com:

 Hi,

 I have made custom Audio cape using TLV320AIC3107. Here is a circuit
 diagram :


 http://e2e.ti.com/cfs-file.ashx/__key/telligent-evolution-components-attachments/00-64-01-00-01-29-55-62/audio.png


 I make it same  ( Pin configurations and all ) as what is available at
 CircuitCO using TLC320AIC3104 codec. I follow All steps like Disable HDMI
 and Load Device Tree BB-BONE-AUDI-02-00A0.dts  and I it works fine.

 But my problem is when I run speaker-test system hangs (freezes) and I
 have to Hard Reset BeagleBone.

 Here is what i did and what I get in dmesg.


 *root@beaglebone:~# speaker-test *

 speaker-test 1.0.25

 Playback device is default
 Stream parameters are 48000Hz, S16_LE, 1 channels
 Using 16 octaves of pink noise
 Rate set to 48000Hz (requested 48000Hz)
 Buffer size range from 128 to 32768
 Period size range from 8 to 2048
 Using max buffer size 32768
 Periods = 4


 *And in Dmesg : *

 [  205.540653] omap_i2c 4819c000.i2c: Arbitration lost
 [  206.572921] omap_i2c 4819c000.i2c: controller timed out
 [  206.580024] omap_i2c 4819c000.i2c: Arbitration lost
 [  207.611983] omap_i2c 4819c000.i2c: controller timed out
 [  207.618668] omap_i2c 4819c000.i2c: Arbitration lost
 [  212.626062] omap_i2c 4819c000.i2c: Arbitration lost
 [  213.658853] omap_i2c 4819c000.i2c: controller timed out
 [  213.666881] omap_i2c 4819c000.i2c: Arbitration lost
 [  214.699867] omap_i2c 4819c000.i2c: controller timed out
 [  214.707912] omap_i2c 4819c000.i2c: Arbitration lost
 [  215.740887] omap_i2c 4819c000.i2c: controller timed out
 [  215.748952] omap_i2c 4819c000.i2c: Arbitration lost


 I also cross check device tree file and I found that it also works
 for TLV320AIC3107 codec So I think it is not issue.

 An one have Idea what is wrong Please Help ME 


 Thanks  Regards

 Prakash P.

  --
 For more options, visit http://beagleboard.org/discuss
 ---
 You received this message because 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.




 --
 LinkedIn - http://www.linkedin.com/in/maximpodbereznyy
 Company - http://www.linkedin.com/company/mentorel
 Facebook - https://www.facebook.com/mentorel.company

 --
 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/0ickf2E6NNs/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.


-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because 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] Impossible to desactivate Multicast

2014-09-16 Thread Micka

I've tried

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because 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 MultiCast

2014-09-16 Thread Micka

I've tried to deactivate the Multicast with :

ifconfig eth0 -multicast

But when i check with this command, I can still see :

ip maddr show

2:  eth0
link  33:33:00:00:00:01
link  01:00:5e:00:00:01
link  33:33:ff:9a:05:07
*inet  224.0.0.1*
inet6 ff02::1:ff9a:507
inet6 ff02::1


Which is not good for me !


i've tried :

debian@beaglebone:/Distrib/Scripts$ sudo ip -r maddr delete 224.0.0.1 dev
eth0

ioctl: No such file or directory


I also tried to ping 224.0.0.1 from an another device .

And with the command tcpdump I can see that I'm receiving multicast packet :

debian@beaglebone:/Distrib/Scripts$ sudo tcpdump -p -i eth0 host 224.0.0.1
-n

tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes
16:09:28.679257 IP *190.190.167.1  224.0.0.1*: ICMP echo request, id 1,
seq 1913, length 40





Why ? I really don't know what to do about it, My idea is to deactivate
multicast in the kernel build config . Does it sounds good for you ?



Thank you,


Micka.

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because 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 3.14.17-ti-r19

On Mon, Sep 15, 2014 at 4:03 PM, Charles Steinkuehler
char...@steinkuehler.net wrote:
 On 9/15/2014 3:59 PM, Robert Nelson wrote:
 On Mon, Sep 15, 2014 at 3:54 PM, Charles Steinkuehler
 char...@steinkuehler.net wrote:

 I'm apparently missing some sort of secret sauce (a.k.a. clues).  :-/

 deb_pkg still hasn't learned to autodetect armhf, so we do some
 deb voodoo around that.. ;)

 otherwise, the ti-r19 comes from LOCALVERSION

 So:

 make ARCH=arm KBUILD_DEBARCH=armhf LOCALVERSION=-ti-r19
 CROSS_COMPILE=${CC} KDEB_PKGVERSION=1wheezy deb-pkg

 will generate:
 linux-image-3.14.17-ti-r19_1wheezy_armhf.deb


 Many thanks!

 I figured the missing LOCALVERSION was just something I didn't have vs.
 the official build scripts, but when I got armel packages instead of
 armhf I figured something was very wrong so I headed down a different path.

Hey Charles,

Ran into a problem last night with the pinmux, what's the proper way
to grab a pin.  For the lcd4, i need P9_27_gpio_pd_pin

diff --git a/arch/arm/boot/dts/am335x-bone-panel-480x272.dtsi
b/arch/arm/boot/dts/am335x-bone-panel-480x272.dtsi
index 2df34ce..6f3dceb 100644
--- a/arch/arm/boot/dts/am335x-bone-panel-480x272.dtsi
+++ b/arch/arm/boot/dts/am335x-bone-panel-480x272.dtsi
@@ -15,7 +15,7 @@
status = okay;
compatible = ti,tilcdc,panel;
pinctrl-names = default;
-   pinctrl-0 = bbcape_lcd_pins bbcape_lcd4_disen_pins;
+   pinctrl-0 = bbcape_lcd_pins P9_27_gpio_pd_pin;
panel-info {
ac-bias   = 255;
ac-bias-intrpt= 0;

but, P9_27_pinmux still grabs it:

[3.197699] pinctrl-single 44e10800.pinmux: pin 44e109a4.0 already
requested by P9_27_pinmux.32; cannot claim for panel.48
[3.209481] pinctrl-single 44e10800.pinmux: pin-105 (panel.48) status -22
[3.21] pinctrl-single 44e10800.pinmux: could not request pin
105 (44e109a4.0) from group pinmux_P9_27_gpio_pd_pin  on device
pinctrl-single

ps, i disabled my git mirror script, so:

https://github.com/RobertCNelson/ti-linux-kernel-dev

is safe today, i'm going to try and only update my ti mirror when i
already have my patchset rebased.

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 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: Ubuntu 14 - poor performance

2014-09-16 Thread Richard-tx


Unles I flashed it wrong twice in a row. I can't see how I could have 
botched the job.

I think that the next step is to report this as a bug.  Something in the 
kernel itself is causing the issue.

Does anyone have a url for reporting bugs?

Richard

On Monday, September 15, 2014 5:23:16 PM UTC-5, William Hermans wrote:

 There is also the chance that you somehow botched something on the Ubuntu 
 install. This can also cause performance issues. Such as if you did not 
 completely delete the root file system from debian before installing Ubuntu 
 on the same media. . . . You might think this would not be a problem. but 
 it can be . . .

 On Mon, Sep 15, 2014 at 3:20 PM, William Hermans yyr...@gmail.com 
 javascript: wrote:

 Ok so take a look at the output of pstree there. Notice how the init 
 system is all over the tree ? First you have init as pid 1. then way down 
 the tree you have systemd, followed by several upstart processes. This is 
 normal from what I can tell on my own PC based Ubuntu installs ( actually 
 Lubuntu, the same thing with different window manager ). But I also think 
 this helps Ubuntu perform noticeably slower compared to Debian.

 I notice a performance difference on PCs as well. Debian, being much 
 lighter just does some things faster.

 However, you can always google Ubuntu 14.04 performance tuning and see 
 what you turn up. With that said, is there a particular package that Ubuntu 
 has that Debian does not ? Otherwise ditch Ubuntu and go back to Debian . . 
 .

 On Mon, Sep 15, 2014 at 10:00 AM, Richard-tx rich.a...@gmail.com 
 javascript: wrote:

 Here is pstree -A

  pstree -A
 init-+-acpid
  |-avahi-daemon---avahi-daemon
  |-cron
  |-dbus-daemon
  |-dhclient
  |-7*[getty]
  |-rsyslogd---3*[{rsyslogd}]
  |-sshd---bash
  |-sshd-+-sshd---bash---tail
  |  |-sshd---bash---su---ksh---pstree
  |  `-sshd---ksh
  |-systemd-udevd
  |-udhcpd
  |-upstart-file-br
  |-upstart-socket-
  `-upstart-udev-br


 and top

 # top
 top - 11:59:28 up 1 day,  8:37,  4 users,  load average: 0.01, 0.05, 0.05
 Tasks:  82 total,   1 running,  81 sleeping,   0 stopped,   0 zombie
 %Cpu(s):  0.3 us,  0.3 sy,  0.0 ni, 99.3 id,  0.0 wa,  0.0 hi,  0.0 si,  
 0.0 st
 KiB Mem:508500 total,   474208 used,34292 free,13664 buffers
 KiB Swap:  1048572 total,  832 used,  1047740 free.   409384 cached 
 Mem




 On Monday, September 15, 2014 2:50:57 AM UTC-5, William Hermans wrote:

 Show us the output of pstree
 .

 On Mon, Sep 15, 2014 at 12:38 AM, Richard-tx rich.a...@gmail.com 
 wrote:

 Here is the output from vmstat 2  

 You can see where I start the build.

 # vmstat 2
 procs ---memory-- ---swap-- -io -system-- 
 --cpu-
  r  b   swpd   free   buff  cache   si   sobibo   in   cs us 
 sy id wa st
  1  0832  12476  14188 42766800 538   83   61 10  
 1 88  1  0
  0  0832  12420  14188 42766800 0 0   21   47  0  
 0 100  0  0
  0  0832  12452  14188 42766800 0 0   23   45  0  
 1 100  0  0
  0  0832  12452  14196 42766400 0 6   27   54  0  
 0 100  0  0
  0  0832  12452  14196 42766800 0 0   21   50  0  
 0 100  0  0
  0  0832  12296  14196 42766800 0 2   23   47  0  
 0 100  0  0
  0  0832  12328  14196 42766800 0 0   26   45  0  
 0 100  0  0
  0  0832  12328  14200 42766400 0 4   31   54  0  
 0 100  0  0
  0  0832  12296  14200 42766800 0 0   24   44  0  
 0 100  0  0
  0  0832  12320  14200 42766800 0 0   35   70  0  
 0 100  0  0
  1  0832   4308  14200 42678800 0   684  560  399 69 
 13 19  0  0
  0  0832  13136  14200 42565600 0   128  201   94 25  
 2 73  0  0
  0  1832   9392  14204 42541200 0   102  261  258 34  
 6 34 26  0
  1  0832   9020  14208 42552800 0   154  568  272 91  
 9  0  1  0
  1  0832   7160  14208 42558800 092  448  278 70  
 8 22  0  0
  1  0832  13300  14216 42566000 0   240  597  490 84 
 15  0  1  0
  1  0832  12152  14216 42570400 0   130  635  513 87 
 13  0  0  0
  2  0832  10540  14224 42575600 0   172  580  407 87 
 13  0  1  0
  1  0832   8308  14224 42587600 0   140  585  431 91  
 9  0  0  0
  2  0832  10540  14224 42592400 0   198  572  329 89 
 11  0  0  0
  1  0832   9300  14232 42601600 0   172  584  436 88 
 11  0  0  0
  1  0832   9548  14232 42607600 0   162  563  267 90 
 10  0  0  0
  1  0832   8152  14240 42614800 0   130  476  373 68 
 11 22  0  0
  1  0832   8680  14240 42621600 0   152  599  541 83 
 17  0  0  0
  1  0832   7068  14240 42626400 098  461  340 71  
 8 20  0  0


  -- 
 For

[beagleboard] SD card issue with beaglebone black

2014-09-16 Thread sanjay ahuja

Hi,

I tried using microSD card as extra storage for my beaglebone black. I 
followed the steps as mentioned 
at http://elinux.org/Beagleboard:MicroSD_As_Extra_Storage.

I was able to use mount microSD card successfully. However I am facing some 
strange issue.

when I do ls -lart on the mounted drive the permissions are

drwx--  5 root root 16384 Jan  1  1970 drive


If I try chmod o+rx,g+rx /media/drive, to change the permissions, it does 
not work. No error on issuing chmod command but permission does not get 
change.

Infact I am not even able to change the user permission for any executable 
file under directory 'drive'.

For ex. 
bash-4.2# ls -lart /media/drive/jdk1.7.0_60/bin/java
-rw-r--r-- 1 root root 5822 May  7 20:26 /media/drive/jdk1.7.0_60/bin/java

bash-4.2# chmod u+x /media/drive/jdk1.7.0_60/bin/java

bash-4.2# ls -lart /media/drive/jdk1.7.0_60/bin/java
-rw-r--r-- 1 root root 5822 May  7 20:26 /media/drive/jdk1.7.0_60/bin/java

Since 'x' permission is missing, I am not able to execute any binary file. 
I am logged in as root user only. The jdk directory is expanded from jdk 
installer zip using command
tar -xvf Downloads/jdk-7u60-linux-arm-vfp-sflt --owner root --group root 
--no-same-owner.

No issues are encountered if the jdk directory is expanded under home 
directory instead of SD card.

The partition details for SD Card:

Usage : Filesystem
Partition type: W95 FAT16 (LBA) (0x0e)
Type: FAT (16-bit version)
Device: /device/mmcblk1p1
Mount Point: Mounted at /media/drive

Any help will be really appreciated.

Thanks,
Sanjay Ahuja 


-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because 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 3.14.17-ti-r19

On Tue, Sep 16, 2014 at 10:07 AM, Robert Nelson robertcnel...@gmail.com wrote:
 On Mon, Sep 15, 2014 at 4:03 PM, Charles Steinkuehler
 char...@steinkuehler.net wrote:
 On 9/15/2014 3:59 PM, Robert Nelson wrote:
 On Mon, Sep 15, 2014 at 3:54 PM, Charles Steinkuehler
 char...@steinkuehler.net wrote:

 I'm apparently missing some sort of secret sauce (a.k.a. clues).  :-/

 deb_pkg still hasn't learned to autodetect armhf, so we do some
 deb voodoo around that.. ;)

 otherwise, the ti-r19 comes from LOCALVERSION

 So:

 make ARCH=arm KBUILD_DEBARCH=armhf LOCALVERSION=-ti-r19
 CROSS_COMPILE=${CC} KDEB_PKGVERSION=1wheezy deb-pkg

 will generate:
 linux-image-3.14.17-ti-r19_1wheezy_armhf.deb


 Many thanks!

 I figured the missing LOCALVERSION was just something I didn't have vs.
 the official build scripts, but when I got armel packages instead of
 armhf I figured something was very wrong so I headed down a different path.

 Hey Charles,

 Ran into a problem last night with the pinmux, what's the proper way
 to grab a pin.  For the lcd4, i need P9_27_gpio_pd_pin

 diff --git a/arch/arm/boot/dts/am335x-bone-panel-480x272.dtsi
 b/arch/arm/boot/dts/am335x-bone-panel-480x272.dtsi
 index 2df34ce..6f3dceb 100644
 --- a/arch/arm/boot/dts/am335x-bone-panel-480x272.dtsi
 +++ b/arch/arm/boot/dts/am335x-bone-panel-480x272.dtsi
 @@ -15,7 +15,7 @@
 status = okay;
 compatible = ti,tilcdc,panel;
 pinctrl-names = default;
 -   pinctrl-0 = bbcape_lcd_pins bbcape_lcd4_disen_pins;
 +   pinctrl-0 = bbcape_lcd_pins P9_27_gpio_pd_pin;
 panel-info {
 ac-bias   = 255;
 ac-bias-intrpt= 0;

 but, P9_27_pinmux still grabs it:

 [3.197699] pinctrl-single 44e10800.pinmux: pin 44e109a4.0 already
 requested by P9_27_pinmux.32; cannot claim for panel.48
 [3.209481] pinctrl-single 44e10800.pinmux: pin-105 (panel.48) status -22
 [3.21] pinctrl-single 44e10800.pinmux: could not request pin
 105 (44e109a4.0) from group pinmux_P9_27_gpio_pd_pin  on device
 pinctrl-single

 ps, i disabled my git mirror script, so:

 https://github.com/RobertCNelson/ti-linux-kernel-dev

 is safe today, i'm going to try and only update my ti mirror when i
 already have my patchset rebased.

NM, found a work around..

When we know what cape is installed, thus we are already building a
*.dtb for it, just disable the pinmux, as it's already tied to the
cape.

diff --git a/arch/arm/boot/dts/am335x-bone-panel-480x272.dtsi
b/arch/arm/boot/dts/am335x-bone-panel-480x272.dtsi
index 2df34ce..138a619 100644
--- a/arch/arm/boot/dts/am335x-bone-panel-480x272.dtsi
+++ b/arch/arm/boot/dts/am335x-bone-panel-480x272.dtsi
@@ -6,6 +6,12 @@
  * published by the Free Software Foundation.
  */

+ocp {
+   P9_27_pinmux {
+   status = disabled;
+   };
+};
+
 lcdc {
status = okay;
 };

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 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] SD card issue with beaglebone black

On Tue, Sep 16, 2014 at 10:22 AM, sanjay ahuja
sanjayahuja.i...@gmail.com wrote:
 Hi,

 I tried using microSD card as extra storage for my beaglebone black. I
 followed the steps as mentioned at
 http://elinux.org/Beagleboard:MicroSD_As_Extra_Storage.

 I was able to use mount microSD card successfully. However I am facing some
 strange issue.

 when I do ls -lart on the mounted drive the permissions are

 drwx--  5 root root 16384 Jan  1  1970 drive


 If I try chmod o+rx,g+rx /media/drive, to change the permissions, it does
 not work. No error on issuing chmod command but permission does not get
 change.

 Infact I am not even able to change the user permission for any executable
 file under directory 'drive'.

 For ex.
 bash-4.2# ls -lart /media/drive/jdk1.7.0_60/bin/java
 -rw-r--r-- 1 root root 5822 May  7 20:26 /media/drive/jdk1.7.0_60/bin/java

 bash-4.2# chmod u+x /media/drive/jdk1.7.0_60/bin/java

 bash-4.2# ls -lart /media/drive/jdk1.7.0_60/bin/java
 -rw-r--r-- 1 root root 5822 May  7 20:26 /media/drive/jdk1.7.0_60/bin/java

 Since 'x' permission is missing, I am not able to execute any binary file. I
 am logged in as root user only. The jdk directory is expanded from jdk
 installer zip using command
 tar -xvf Downloads/jdk-7u60-linux-arm-vfp-sflt --owner root --group root
 --no-same-owner.

 No issues are encountered if the jdk directory is expanded under home
 directory instead of SD card.

 The partition details for SD Card:

 Usage : Filesystem
 Partition type: W95 FAT16 (LBA) (0x0e)
 Type: FAT (16-bit version)
 Device: /device/mmcblk1p1
 Mount Point: Mounted at /media/drive

re-partition it as ext4... fat16 doesnt' support user permissions..

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 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: Beaglebone Black won't power on, did I do something wrong? :(

2014-09-16 Thread Benedek

Hi,

I updated the Angstrom Distribution 2013-09-04 image on my BBB. The process 
seem to run well. After it ended, I get the SD card out from the BBB, and 
restarted it, with plugging in again the BBB via USB. But then only the 
power led lits, and nothing else. 
I've repeated the process many times, even with Debian 2014-05-04, but the 
result is the same.

Could anyone help me?

Thanks,
Ben


2013. április 30., kedd 14:19:57 UTC+2 időpontban Jason Stapels a 
következőt írta:

 Hi all,

 Just wanted to share my experience with my dead BBB. It's my first 
 experience with the Beagle line so it's possible I did something wrong 
 somewhere so I thought it would be a good idea to share my experiences in 
 case other newb's read this. Feel free to skip to the bottom for the 
 symptoms.

 -- Begin Background Info --

 I was lucky enough to get my BBB almost right away from Digikey. I 
 immediately installed the drivers on my Mac and started playing around with 
 it the first night. Unfortunately, the second night I couldn't get my Mac 
 to allocate an IP address through the USB to talk to it so I thought maybe 
 I shouldn't have skipped that update software step. So next I downloaded 
 the latest flash eMMC image, wrote it to an SD card and then went through 
 the upgrade process.

 Here's where things went a little South. After the first attempt the USR 
 lights eventually went solid (presumably indicating the flashing process 
 was finished) but when I rebooted it without the SD card, the power light 
 would come on but it wouldn't boot. After a couple repower attempts I 
 decided to flash it again. This time, at some point during the flash 
 process, the board seemed to just lose power (all the LEDs were off). 
 Attempts to power the board resulted in the same as before, power light 
 comes on but no booting.

 So, my assumption was I messed up the SD card image. I downloaded/reimaged 
 the SD card again, went through the flash process and this time it seemed 
 to finish. Now when I powered on the board it appeared to boot up. However, 
 I still couldn't get it to pick up an IP address from the Mac (after 
 reinstalling both drivers and a couple reboots). I read somewhere that 
 someone had a similar issue and an update to Angstrom solved it.

 This time I plugged the board into my linux box and I was able to access 
 the running linux image (yay!). I immediately SSH'd in, and went through 
 the Angstrom upgrade (opkg update; opkg upgrade). The upgrade took awhile 
 and seemed to have a few issues with the new kernel modules 
 (/lib/modules/blah didn't exist). I figured it was just a warning and after 
 the upgrade finished I unplugged the board and plugged it back into my 
 Mac...

 -- End Background Info --

 The power light came on... the USR lights all went solid for a couple 
 seconds... and then the board died. I can no longer seem to power the board 
 up at all. I've tried multiple USB cables, multiple USB ports on multiple 
 machines, and even tried the DC jack with a 5v/2.2A supply. :( I submitted 
 an RMA (although my board doesn't seem to have a serial number) because I 
 don't think I did anything wrong, but I'm a very sad panda regardless.

 Any ideas? Anything I should check?

 ~ Jason


-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because 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: PWM: changing Period of EHRPWM

2014-09-16 Thread avterekhov

Hi,

In case someone still needs a solution to this problem, I've written a 
small kernel patch: ti_ehr_pwm.patch 
https://sites.google.com/site/avterekhov/ti_ehr_pwm.patch and a short 
description of how to apply it: 
https://randomlinuxhacks.wordpress.com/2014/09/16/changing-pwm-period-on-beaglebone-black/

So far it works for me.

On Thursday, June 26, 2014 8:10:26 AM UTC+2, jmc...@gmail.com wrote:

 I also tried this and had no luck :-/

 PWM on the BBB is turning out to be more work than I had thought.

 On Monday, January 6, 2014 12:13:37 PM UTC-8, Anto Dominic wrote:

 Thanks,

 Tried your trick even replaced the new dtbo file but even after 
 that I am getting the default value for Period ( ie, 500) and duty (ie, 
 0) ... Is there any step that you missed in between...??. Anyways thanks 
 for the tip..:)

 On Monday, 8 July 2013 08:44:54 UTC+5:30, tohr...@gmail.com wrote:

 Hello,

 you can change period by changing dtbo files.

 1 Generate dts file from original dtbo file
 dtc -I dtb -O dts -o /lib/firmware/bone_pwm_P8_13-00A0.dts /lib/firmware
 /bone_pwm_P8_13-00A0.dtbo

 2 Change period
 open file /lib/firmware/bone_pwm_P8_13-00A0.dts with editor at 
 lines around line 26:
 pwm_test_P8_13 {
 compatible = pwm_test;
 pwms = 0xdeadbeef 0x1 0x7a120 0x1;

  and change to following, for example change period to 10ns=0.1ms

 pwm_test_P8_13 {
 compatible = pwm_test;
 pwms = 0xdeadbeef 0x1 10 0x1;
   
 where
 -3rd parameter of linepwms = ~ is period.
 -period (and other parameters) can be written in either decimal or 
 hexadecimal of 0xABC format.
 -default period 0x7a120 is 500 in decimal.
 -As you mentioned, Both A and B output for one eHRPWM must have same 
 period setting.
  If not, the second device will fail to setup at echo (device) 
 /sys/devices/bone_capemgr.*/slots command.

 3 Compile to new dtbo file
 dtc -O dtb -o bone_pwm_P8_13-00A0.dtbo -b 0 -@ bone_pwm_P8_13-00A0.dts

  You'd better back up original dtbo file before overwriting it.

 4 Use new dtbo file. 
 echo bone_pwm_P8_13  /sys/devices/bone_capemgr.*/slots



 2013年6月4日火曜日 16時33分00秒 UTC+9 sultanof.ilo...@gmail.com:

 Hey, 
 yes sure, duty must be (0 = duty = period). Otherwise you would try 
 to to set a pwm duty cycle of less than 0% or more than 100%. Returning an 
 error to the user is a proper way to handle this. 

 As mentioned above EHRPWM1 and EHRPWM2 share the same base period (or 
 respectively the base frequency). If I enable both PWM ouputs, writing to 
 the period files always results in an error. Enabeling only one of the two 
 outputs lets me change the periods.
 This does make sense after all. I assume the necessary crosschecking of 
 the conditions (0 = duty = period) for related PWM outputs is simply not 
 implemented yet or mayby just faulty. 

 Am Montag, 3. Juni 2013 12:25:15 UTC+2 schrieb lawe...@gmail.com:

 Hi

 I'm just starting out, but here is what I found. Hopefully it can help 
 you.
 The period must be greater than duty.
 This worked fine for me:
 echo 10  /sys/devices/ocp.2/pwm_test_P9_14.12/period
 Period is given in ns. Duty is given in ns on/off depending on 
 polarity.




-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because 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: Beaglebone Black Rebooting Several Times Every Day

2014-09-16 Thread Thomas Olofsson

Greg we are experiencing the same issues as well with reset not bringing up
the eth0 interface. we were trying to do a hw watchdog that would reset the
board and when we press reset the eth0 interface fails as well. We are also
setting the interface config static in /etc/network/interfaces.




--Skjortan!

On Tue, Sep 16, 2014 at 2:28 PM, Greg Kelley suekkel...@gmail.com wrote:

 I just changed over to the Switching Power Supply and eth0 failed to come
 up on boot. I hit the reset button and a reboot brought it up. So now it
 seems there are eth0 issues as well as resets. Going from bad to worse.

 --
 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/vgeh336p0P4/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] Custom Audio cape with TLV320AIC3107 codec.

2014-09-16 Thread Prakash Parmar

Hi,

Here CircuitCo cape is not available So we decided to make our own.

On Tue, Sep 16, 2014 at 7:20 PM, Jesse Cobra jesseco...@gmail.com wrote:

What happens when you try the CircuitCO audio cape?
Does it work fine?

On Mon, Sep 15, 2014 at 10:14 PM, Prakash Parmar
prakash.parma...@gmail.com wrote:

Hi,

How I can check this two things ?

2) check if SYS_RESET is actually deasserted and high
3) check if DIN/DOUT are correctly connected and not flipped, because DIN
data must go into CODEC, while DOUT must go out and vise versa

I'm not clear about this. Actually I have two Boards one with 10K
resistors and one with 4.6K .

Thanks Regards,
Prakash P.

On Tue, Sep 16, 2014 at 12:34 AM, Maxim Podbereznyy lisar...@gmail.com
wrote:

what is exactly not clear for you?

how to change resistors or how to copy/paste commands in a shell?

2014-09-15 21:46 GMT+04:00 prakash.parma...@gmail.com:

HI,
Thanks For reply.

Can you please tell me how I can Do that ?

Thanks Regards,
Prakash P.

On Monday, September 15, 2014 8:01:19 PM UTC+5:30, liyaoshi wrote:

Have you config the i2c pin pulled up ?
and
whats the speed of your i2c bus ?

2014-09-15 2:09 GMT+08:00 prakash@gmail.com:

Hi,

I have made custom Audio cape using TLV320AIC3107. Here is a circuit
diagram :

http://e2e.ti.com/cfs-file.ashx/__key/telligent-evolution-components-attachments/00-64-01-00-01-29-55-62/audio.png

I make it same ( Pin configurations and all ) as what is available
at CircuitCO using TLC320AIC3104 codec. I follow All steps like Disable
HDMI and Load Device Tree BB-BONE-AUDI-02-00A0.dts and I it works fine.

But my problem is when I run speaker-test system hangs (freezes) and
I have to Hard Reset BeagleBone.

Here is what i did and what I get in dmesg.

*root@beaglebone:~# speaker-test *

speaker-test 1.0.25

Playback device is default
Stream parameters are 48000Hz, S16_LE, 1 channels
Using 16 octaves of pink noise
Rate set to 48000Hz (requested 48000Hz)
Buffer size range from 128 to 32768
Period size range from 8 to 2048
Using max buffer size 32768
Periods = 4

*And in Dmesg : *

[ 205.540653] omap_i2c 4819c000.i2c: Arbitration lost
[ 206.572921] omap_i2c 4819c000.i2c: controller timed out
[ 206.580024] omap_i2c 4819c000.i2c: Arbitration lost
[ 207.611983] omap_i2c 4819c000.i2c: controller timed out
[ 207.618668] omap_i2c 4819c000.i2c: Arbitration lost
[ 212.626062] omap_i2c 4819c000.i2c: Arbitration lost
[ 213.658853] omap_i2c 4819c000.i2c: controller timed out
[ 213.666881] omap_i2c 4819c000.i2c: Arbitration lost
[ 214.699867] omap_i2c 4819c000.i2c: controller timed out
[ 214.707912] omap_i2c 4819c000.i2c: Arbitration lost
[ 215.740887] omap_i2c 4819c000.i2c: controller timed out
[ 215.748952] omap_i2c 4819c000.i2c: Arbitration lost

I also cross check device tree file and I found that it also works
for TLV320AIC3107 codec So I think it is not issue.

An one have Idea what is wrong Please Help ME

Thanks Regards

Prakash P.

--
For more options, visit http://beagleboard.org/discuss
---
You received this message because 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.

--
LinkedIn - http://www.linkedin.com/in/maximpodbereznyy
Company - http://www.linkedin.com/company/mentorel
Facebook - https://www.facebook.com/mentorel.company

--
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/0ickf2E6NNs/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] Building kernel 3.14.17-ti-r19

On 9/16/2014 10:26 AM, Robert Nelson wrote:
 
 NM, found a work around..
 
 When we know what cape is installed, thus we are already building a
 *.dtb for it, just disable the pinmux, as it's already tied to the
 cape.
 
 diff --git a/arch/arm/boot/dts/am335x-bone-panel-480x272.dtsi
 b/arch/arm/boot/dts/am335x-bone-panel-480x272.dtsi
 index 2df34ce..138a619 100644
 --- a/arch/arm/boot/dts/am335x-bone-panel-480x272.dtsi
 +++ b/arch/arm/boot/dts/am335x-bone-panel-480x272.dtsi
 @@ -6,6 +6,12 @@
   * published by the Free Software Foundation.
   */
 
 +ocp {
 +   P9_27_pinmux {
 +   status = disabled;
 +   };
 +};
 +
  lcdc {
 status = okay;
  };

Yes, that's what you need to do for now, and this is why no cape pins
can be controlled at run-time without using a device-tree overlay (or
changeset).

What I'm working on is adding a setting to the pinmux helper, so rather
than trying to have the LCD cape own the pinmux setting, it would just
let the pinmux helper know it should start in a specific mode.

...but it looks like you might be assigning LEDs to the GPIO.  This
causes the GPIO pin to be owned by the gpio-leds driver, making it
impossible to use the pin as a GPIO for any other purpose.  I haven't
worked out a solution for this, other than to not use the kernel
gpio-leds driver (driving the LED from userspace) or just give up the
option to reconfigure the I/O and let the kernel LED driver own it.

-- 
Charles Steinkuehler
char...@steinkuehler.net

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
BeagleBoard group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] BBB with own cape stops working

2014-09-16 Thread Ulli

@Gerald: What else can be wrong except the hardware design?

Am Montag, 15. September 2014 23:25:11 UTC+2 schrieb Ulli:

I am not sure what you mean with to disable the buffer before until you
come up.
Directly connect the Beagle SYS_RESETn pin to the pin 29 of the Atmega`s?

What would be the positive effect by using the SYS_5V. I think it is
directly connected to the Beagle DC plug. So, it can drive more current?

Two more ideas:
* would it be helpful to add a 0,1µF capacitor to the beagle voltage
supply pins on the header, between VDD_3v3 and Gnd very close to the beagle
headers?
* would it be better to completely supply my cape from SYS_5V and create
the 3v for the Atmegas and the other components on the cape with the
MCP1703?

Am Montag, 15. September 2014 23:14:45 UTC+2 schrieb Gerald:

Nothing else jumps out at me. The 5V rail you are using is on before
the board is powered up, but I don't think that should matter. You could
switch to SYS_5V, no reason not to.As you only have four wires to the BBB,
you might try adding some isolation there, and use the RESET signal to
disable the buffer before until you cone up.

There may be something else in your setup. But, schematic wise
I don't see anything else.

Gerald

On Mon, Sep 15, 2014 at 4:09 PM, mitterma...@gmail.com wrote:

Yes of course. I added this option just to run the cape for first tries
on a USB port.

Could you find any other problems? I am currently thinking to connect
the SYS_RESETn of the BBB directly to the reset pin of the atmega`s?

Am Montag, 15. September 2014 23:06:09 UTC+2 schrieb Gerald:

Looks like you have shorting posts for your standalone versus cape
mode. If you ever by accident plug in the standalone mode into the BBB,
then you will damage the board for sure.

Gerald

On Mon, Sep 15, 2014 at 3:51 PM, ulli mitterma...@gmail.com wrote:

You are right, there must be something wrong but I do not know what.
I understood that the blocking capacitor is missing. But I do not know
if that is the only mistake and this is the reason why my beagle stopped
working because of my cape

I updated the circuit to that configuration like it is when I have it
connected to the beagle.
https://drive.google.com/file/d/0B8Fq4yYMgG7uTFlIRjdjcGRUYlE/
edit?usp=sharing

Am Montag, 15. September 2014 22:32:54 UTC+2 schrieb Gerald:

So your contention is that this is all correct? Do I read you right?

Gerald

On Mon, Sep 15, 2014 at 3:24 PM, mitterma...@gmail.com wrote:

Thanks for your quick answer and very helpful feedback!

I am not sure if I understood right.

Currently I have to options to power the cape.
1. Use the cape without the Beagle
-- Power supply over the FTDI connector and solder header
Pin2-Pin3 connected on the MCP1703 side.
-- 5V solder header Pin1-Pin2 connected
-- 3,3V will be generated with the MCP1703 from the input
voltage VIN

2. Use the cape with the Beagle
-- Power supply all over the beagle headers and solder header
Pin1-Pin2 connected on the MCP1703 side. Therefore no voltages will be
generated by the cape itself...
-- 5V solder header Pin2-Pin3 connected. 5V from the beagle.
-- 3,3V from the beagle

Therefore the atmega`s can only power up when the 3.3v supply of the
header is available.
The 5v supply is always on thats right. But 5v is only used for
LED`s and the Piezo Buzzer and this parts are
disconnected with a BC817 from ground.

Yes all wires which are named as GND are connected.

Do you really see an issue on that? What needs to be changed?

Am Montag, 15. September 2014 21:56:47 UTC+2 schrieb Gerald:

Your regulator must be turned off until the VDD_3V3 rail comes up.
Right now it comes up almost immediately as it is powered from either
the
expansion header or a weirdly designed 5V DC input. The idea of gating
the
ground to control power will not work as you already have a DC path to
ground, assuming that all of your grounds are connected together as
they should be.

Gerald

On Mon, Sep 15, 2014 at 2:45 PM, mitterma...@gmail.com wrote:

Oh I understood, I need to add the C1 on each Atmega 3V3 supply.
-- blocking
https://dict.leo.org/ende/index_de.html#/search=blockingsearchLoc=0resultOrder=basicmultiwordShowSingle=on

capacitor
https://dict.leo.org/ende/index_de.html#/search=capacitorsearchLoc=0resultOrder=basicmultiwordShowSingle=on
But could that really be the issue which stopps the BBB running. I
can also not boot the beagle up when I have removed the cape.
When I want to boot up the beagle alone the power led flashes up
one time...and thats it

Am Montag, 15. September 2014 21:29:20 UTC+2 schrieb Gerald:

IC1. Your regulator.

Gerald

On Mon, Sep 15, 2014 at 2:17 PM, mitterma...@gmail.com wrote:

What do you mean with C1?

Am Montag, 15. September 2014 21:08:59 UTC+2 schrieb Gerald:

Looks like C1 is not gated by the 3.3V rail from the
BBB

Re: [beagleboard] BBB with own cape stops working

It has to be HW or the application and use of the hardware. Maybe you have
a short or some other issue with your assembly.

Gerald

On Tue, Sep 16, 2014 at 11:13 AM, Ulli mittermaier.u...@gmail.com wrote:

@Gerald: What else can be wrong except the hardware design?

Am Montag, 15. September 2014 23:25:11 UTC+2 schrieb Ulli:

I am not sure what you mean with to disable the buffer before until you
come up.
Directly connect the Beagle SYS_RESETn pin to the pin 29 of the Atmega`s?

What would be the positive effect by using the SYS_5V. I think it is
directly connected to the Beagle DC plug. So, it can drive more current?

Am Montag, 15. September 2014 23:14:45 UTC+2 schrieb Gerald:

There may be something else in your setup. But, schematic wise
I don't see anything else.

Gerald

On Mon, Sep 15, 2014 at 4:09 PM, mitterma...@gmail.com wrote:

Yes of course. I added this option just to run the cape for first tries
on a USB port.

Could you find any other problems? I am currently thinking to connect
the SYS_RESETn of the BBB directly to the reset pin of the atmega`s?

Am Montag, 15. September 2014 23:06:09 UTC+2 schrieb Gerald:

Looks like you have shorting posts for your standalone versus cape
mode. If you ever by accident plug in the standalone mode into the BBB,
then you will damage the board for sure.

Gerald

On Mon, Sep 15, 2014 at 3:51 PM, ulli mitterma...@gmail.com wrote:

You are right, there must be something wrong but I do not know what.
I understood that the blocking capacitor is missing. But I do not
know if that is the only mistake and this is the reason why my beagle
stopped working because of my cape

I updated the circuit to that configuration like it is when I have it
connected to the beagle.
https://drive.google.com/file/d/0B8Fq4yYMgG7uTFlIRjdjcGRUYlE/
edit?usp=sharing

Am Montag, 15. September 2014 22:32:54 UTC+2 schrieb Gerald:

So your contention is that this is all correct? Do I read you right?

Gerald

On Mon, Sep 15, 2014 at 3:24 PM, mitterma...@gmail.com wrote:

Thanks for your quick answer and very helpful feedback!

I am not sure if I understood right.

Therefore the atmega`s can only power up when the 3.3v supply of
the header is available.
The 5v supply is always on thats right. But 5v is only used for
LED`s and the Piezo Buzzer and this parts are
disconnected with a BC817 from ground.

Yes all wires which are named as GND are connected.

Do you really see an issue on that? What needs to be changed?

Am Montag, 15. September 2014 21:56:47 UTC+2 schrieb Gerald:

Your regulator must be turned off until the VDD_3V3 rail comes up.
Right now it comes up almost immediately as it is powered from either
the
expansion header or a weirdly designed 5V DC input. The idea of
gating the
ground to control power will not work as you already have a DC path to
ground, assuming that all of your grounds are connected together as
they should be.

Gerald

On Mon, Sep 15, 2014 at 2:45 PM, mitterma...@gmail.com wrote:

Oh I understood, I need to add the C1 on each Atmega 3V3 supply.
-- blocking
https://dict.leo.org/ende/index_de.html#/search=blockingsearchLoc=0resultOrder=basicmultiwordShowSingle=on
capacitor
https://dict.leo.org/ende/index_de.html#/search=capacitorsearchLoc=0resultOrder=basicmultiwordShowSingle=on
But could that really be the issue which stopps the BBB running.
I can also not boot the beagle up when I have removed the cape.
When I want to boot up the beagle alone the power led flashes up
one time...and thats it

Am Montag, 15. September 2014 21:29:20 UTC+2 schrieb Gerald:

IC1. Your regulator.

Gerald

On Mon, Sep 15, 2014 at 2:17 PM,

[beagleboard] Re: RFM12Piv2 on BBB

2014-09-16 Thread jasonwxwcn


HI, We have turnkey solution for wireless communication. In this solution 
few code need to integrate with Beagle Board. It names RF4432.
RF4432 is an alternative for XBEE. It just needs four wire connecting with 
device when systems integrate. VCC, GND, TXD, RXD. It has much more range 
compared with XBEE. Anyway it is better than RFM12 and XRF and 
cost-effective. RF4432 transparent solution is based on Si4432 solution, 
which is 20dBm output power with line of sight range 1500m in the open. It 
provide standard UART port, which make it only need 4 wire to connect 
with Beagle Board. By the contrast , other solution such as RFM12 or XRF 
need 11 wire to connect with Beagle Board. We also can provide standard 
RS232 and RS485 port to meet any requirement. It is much convenient for the 
design. We already have built the checksum in the module like CRC, FEC, 
Manchester coding to implement the security, which users don’t need to care 
about that. When RFM12 integrate with ATmega328, engineers need to add 4 
feedback capacitance, 1 oscillator and antenna matching solution. What’s 
RF4432 need? Nothing. We provide standard SMA connector and user just screw 
up the antenna on the modules. The antenna matching determines the 
performance of RF solution. Our quotation is including the antenna price. I 
think it is an economic solution for you. 

Pls check this link for its datasheet: 
http://www.appconwireless.com/upload/file/RF4432.pdf

在 2014年1月26日星期日UTC+8上午4时19分24秒，NicoD写道：

 Hello
 Following this thread http://openenergymonitor.org/emon/node/2755 I 
 learn that there is a module that is capable to receive RF433 frames.
 this module is the RFM12PIV2 from EnergyMonitor
 So, I bought, receive it

 after updated my BBB under Ubuntu (13.10), I recompiled the drivers for 
 this distribution (https://github.com/gkaindl/rfm12b-linux)
 According this pinout 
 http://wiki.openenergymonitor.org/index.php?title=RFM12Pi_V2 I 
 connected the module to my BBB

 Loading the module with the ismod command produces the following lines 
 in dmesg :
 [304488.785541] rfm12b: added RFM12(B) transceiver rfm12b.1.1
 [304488.787064] rfm12b : driver loaded.
 -- everything seems to be okay

 in lsmod the module appears as
 Module  Size  Used by
 rfm12b 14897  0 

 a device is now present under /dev  : /dev/rfm12b.1.1

 And now, I don't know where to go to get raw frames



 any help would be welcome

 thank you

 ps:

 tech infos:

 uname -a
 Linux BeagleBoneBlack 3.8.13-bone32 #1 SMP Fri Dec 13 20:05:25 UTC 2013 
 armv7l armv7l armv7l GNU/Linux



-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because 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] Custom Audio cape with TLV320AIC3107 codec.

2014-09-16 Thread Prakash Parmar

Hi Maxim ,

I try with your suggestion of aplay -vv test.wav But still same things.
Please find attachment of dmesg log.

Hope listen from you soon. :)

Thanks Regards,
Prakash P.

On Tue, Sep 16, 2014 at 9:23 PM, Prakash Parmar prakash.parma...@gmail.com
wrote:

Hi,

Here CircuitCo cape is not available So we decided to make our own.

On Tue, Sep 16, 2014 at 7:20 PM, Jesse Cobra jesseco...@gmail.com wrote:

What happens when you try the CircuitCO audio cape?
Does it work fine?

On Mon, Sep 15, 2014 at 10:14 PM, Prakash Parmar
prakash.parma...@gmail.com wrote:

Hi,

How I can check this two things ?

2) check if SYS_RESET is actually deasserted and high
3) check if DIN/DOUT are correctly connected and not flipped, because
DIN data must go into CODEC, while DOUT must go out and vise versa

I'm not clear about this. Actually I have two Boards one with 10K
resistors and one with 4.6K .

Thanks Regards,
Prakash P.

On Tue, Sep 16, 2014 at 12:34 AM, Maxim Podbereznyy lisar...@gmail.com
wrote:

what is exactly not clear for you?

how to change resistors or how to copy/paste commands in a shell?

2014-09-15 21:46 GMT+04:00 prakash.parma...@gmail.com:

HI,
Thanks For reply.

Can you please tell me how I can Do that ?

Thanks Regards,
Prakash P.

On Monday, September 15, 2014 8:01:19 PM UTC+5:30, liyaoshi wrote:

Have you config the i2c pin pulled up ?
and
whats the speed of your i2c bus ?

2014-09-15 2:09 GMT+08:00 prakash@gmail.com:

Hi,

I have made custom Audio cape using TLV320AIC3107. Here is a circuit
diagram :

http://e2e.ti.com/cfs-file.ashx/__key/telligent-evolution-components-attachments/00-64-01-00-01-29-55-62/audio.png

But my problem is when I run speaker-test system hangs (freezes) and
I have to Hard Reset BeagleBone.

Here is what i did and what I get in dmesg.

*root@beaglebone:~# speaker-test *

speaker-test 1.0.25

*And in Dmesg : *

I also cross check device tree file and I found that it also works
for TLV320AIC3107 codec So I think it is not issue.

An one have Idea what is wrong Please Help ME

Thanks Regards

Prakash P.

--
For more options, visit http://beagleboard.org/discuss
---
You received this message because 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.

--
LinkedIn - http://www.linkedin.com/in/maximpodbereznyy
Company - http://www.linkedin.com/company/mentorel
Facebook - https://www.facebook.com/mentorel.company

--
For more options, visit http://beagleboard.org/discuss
---
You received this message because 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

[beagleboard] I2C read failed : LI-5M03 + BeagleBoard-xM Rev C2

2014-09-16 Thread steph

Hi,

I have Li-5M03 rev 3.1 and BB-xM rev C2.

*root@beagleboard:~# uname -a : *

Linux beagleboard 2.6.32 #3 PREEMPT Tue Jul 26 10:56:56 CEST 2011 armv7l 
unknown

I have follow this instructions to install kernel and have a mt9p031 
working (http://caganarslan.wordpress.com/2013/07/04/second-post/).

I can take snapshot and video with :
 
*mplayer tv:// -tv 
driver=v4l2:width=1280:height=720:device=/dev/video0:fps=5 -vo jpeg*

or

*mplayer tv:// -tv 
driver=v4l2:width=640:height=480:device=/dev/video0:fps=10 -vo x11*


And it works perfectly.

 But i have a problem, i can't read/write in register with i2c-tools. I 
have tried :

*root@beagleboard:~# i2cdetect -r 2*
 
WARNING! This program can confuse your I2C bus, cause data loss and worse!

I will probe file /dev/i2c-2 using read byte commands.

I will probe address range 0x03-0x77.

Continue? [Y/n] y

0 1 2 3 4 5 6 7 8 9 a b c d e f

00: -- -- -- -- -- -- -- -- -- -- -- -- -- 

10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 

20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 

30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 

40: -- -- -- -- -- -- -- -- UU -- -- -- -- -- -- -- 

50: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 

60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 

70: -- -- -- -- -- -- -- -- 


Sensor is well detect on 0x48 address.


But when i tried to modify gain or exposure, i get :
 
*root@beagleboard:~# echo 22  
/sys/devices/platform/i2c_omap.2/i2c-2/2-0048/gain_val* 

[ 3638.106781] mt9p031 2-0048: Error setting gain.-121

[ 3638.111511] mt9p031: Global gain write failed

*root@beagleboard:~/Desktop# dmesg | grep mt9*

[ 3304.832366] mt9p031 2-0048: mt9p031 chip ID 1801

[ 3638.106781] mt9p031 2-0048: Error setting gain.-121

[ 3638.111511] mt9p031: Global gain write failed


*root@beagleboard:~/Desktop# i2cget -y 2 0x48 000 w*

Error: Could not set address to 0x48: Device or resource busy


Any ideas ?


Thank you


-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because 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 with own cape stops working

2014-09-16 Thread Ulli

Can the 3V3 supply of the Beagle drive all the components regarding max
current?
Could that blow the beagle like described at the beginning?

Am Dienstag, 16. September 2014 18:18:25 UTC+2 schrieb Gerald:

It has to be HW or the application and use of the hardware. Maybe you have
a short or some other issue with your assembly.

Gerald

On Tue, Sep 16, 2014 at 11:13 AM, Ulli mitterma...@gmail.com
javascript: wrote:

@Gerald: What else can be wrong except the hardware design?

Am Montag, 15. September 2014 23:25:11 UTC+2 schrieb Ulli:

I am not sure what you mean with to disable the buffer before until you
come up.
Directly connect the Beagle SYS_RESETn pin to the pin 29 of the Atmega`s?

What would be the positive effect by using the SYS_5V. I think it is
directly connected to the Beagle DC plug. So, it can drive more current?

Two more ideas:
* would it be helpful to add a 0,1µF capacitor to the beagle voltage
supply pins on the header, between VDD_3v3 and Gnd very close to the beagle
headers?
* would it be better to completely supply my cape from SYS_5V and
create the 3v for the Atmegas and the other components on the cape with the
MCP1703?

Am Montag, 15. September 2014 23:14:45 UTC+2 schrieb Gerald:

There may be something else in your setup. But, schematic wise
I don't see anything else.

Gerald

On Mon, Sep 15, 2014 at 4:09 PM, mitterma...@gmail.com wrote:

Yes of course. I added this option just to run the cape for first
tries on a USB port.

Could you find any other problems? I am currently thinking to connect
the SYS_RESETn of the BBB directly to the reset pin of the atmega`s?

Am Montag, 15. September 2014 23:06:09 UTC+2 schrieb Gerald:

Looks like you have shorting posts for your standalone versus cape
mode. If you ever by accident plug in the standalone mode into the BBB,
then you will damage the board for sure.

Gerald

On Mon, Sep 15, 2014 at 3:51 PM, ulli mitterma...@gmail.com wrote:

You are right, there must be something wrong but I do not know what.
I understood that the blocking capacitor is missing. But I do not
know if that is the only mistake and this is the reason why my beagle
stopped working because of my cape

I updated the circuit to that configuration like it is when I have
it connected to the beagle.
https://drive.google.com/file/d/0B8Fq4yYMgG7uTFlIRjdjcGRUYlE/
edit?usp=sharing

Am Montag, 15. September 2014 22:32:54 UTC+2 schrieb Gerald:

So your contention is that this is all correct? Do I read you right?

Gerald

On Mon, Sep 15, 2014 at 3:24 PM, mitterma...@gmail.com wrote:

Thanks for your quick answer and very helpful feedback!

I am not sure if I understood right.

2. Use the cape with the Beagle
-- Power supply all over the beagle headers and solder header
Pin1-Pin2 connected on the MCP1703 side. Therefore no voltages will
be
generated by the cape itself...
-- 5V solder header Pin2-Pin3 connected. 5V from the beagle.
-- 3,3V from the beagle

Therefore the atmega`s can only power up when the 3.3v supply of
the header is available.
The 5v supply is always on thats right. But 5v is only used for
LED`s and the Piezo Buzzer and this parts are
disconnected with a BC817 from ground.

Yes all wires which are named as GND are connected.

Do you really see an issue on that? What needs to be changed?

Am Montag, 15. September 2014 21:56:47 UTC+2 schrieb Gerald:

Your regulator must be turned off until the VDD_3V3 rail comes
up. Right now it comes up almost immediately as it is powered from
either
the expansion header or a weirdly designed 5V DC input. The idea of
gating
the ground to control power will not work as you already have a DC
path to
ground, assuming that all of your grounds are connected together as
they should be.

Gerald

On Mon, Sep 15, 2014 at 2:45 PM, mitterma...@gmail.com wrote:

Oh I understood, I need to add the C1 on each Atmega 3V3 supply.
-- blocking
https://dict.leo.org/ende/index_de.html#/search=blockingsearchLoc=0resultOrder=basicmultiwordShowSingle=on

Re: [beagleboard] BBB with own cape stops working

The rail can drive it. No using the 3.3V rail will not cause damage to the
processor I/O pins as long as the reset lines is sued to make sure they are
not driven until reset is released..

Gerald

On Tue, Sep 16, 2014 at 11:25 AM, Ulli mittermaier.u...@gmail.com wrote:

Can the 3V3 supply of the Beagle drive all the components regarding max
current?
Could that blow the beagle like described at the beginning?

Am Dienstag, 16. September 2014 18:18:25 UTC+2 schrieb Gerald:

It has to be HW or the application and use of the hardware. Maybe you
have a short or some other issue with your assembly.

Gerald

On Tue, Sep 16, 2014 at 11:13 AM, Ulli mitterma...@gmail.com wrote:

@Gerald: What else can be wrong except the hardware design?

Am Montag, 15. September 2014 23:25:11 UTC+2 schrieb Ulli:

I am not sure what you mean with to disable the buffer before until
you come up.
Directly connect the Beagle SYS_RESETn pin to the pin 29 of the
Atmega`s?

What would be the positive effect by using the SYS_5V. I think it is
directly connected to the Beagle DC plug. So, it can drive more current?

Two more ideas:
* would it be helpful to add a 0,1µF capacitor to the beagle voltage
supply pins on the header, between VDD_3v3 and Gnd very close to the beagle
headers?
* would it be better to completely supply my cape from SYS_5V and
create the 3v for the Atmegas and the other components on the cape with the
MCP1703?

Am Montag, 15. September 2014 23:14:45 UTC+2 schrieb Gerald:

There may be something else in your setup. But, schematic wise
I don't see anything else.

Gerald

On Mon, Sep 15, 2014 at 4:09 PM, mitterma...@gmail.com wrote:

Yes of course. I added this option just to run the cape for first
tries on a USB port.

Could you find any other problems? I am currently thinking to connect
the SYS_RESETn of the BBB directly to the reset pin of the atmega`s?

Am Montag, 15. September 2014 23:06:09 UTC+2 schrieb Gerald:

Looks like you have shorting posts for your standalone versus cape
mode. If you ever by accident plug in the standalone mode into the BBB,
then you will damage the board for sure.

Gerald

On Mon, Sep 15, 2014 at 3:51 PM, ulli mitterma...@gmail.com wrote:

You are right, there must be something wrong but I do not know what.
I understood that the blocking capacitor is missing. But I do not
know if that is the only mistake and this is the reason why my beagle
stopped working because of my cape

I updated the circuit to that configuration like it is when I have
it connected to the beagle.
https://drive.google.com/file/d/0B8Fq4yYMgG7uTFlIRjdjcGRUYlE/
edit?usp=sharing

Am Montag, 15. September 2014 22:32:54 UTC+2 schrieb Gerald:

So your contention is that this is all correct? Do I read you
right?

Gerald

On Mon, Sep 15, 2014 at 3:24 PM, mitterma...@gmail.com wrote:

Thanks for your quick answer and very helpful feedback!

I am not sure if I understood right.

2. Use the cape with the Beagle
-- Power supply all over the beagle headers and solder header
Pin1-Pin2 connected on the MCP1703 side. Therefore no voltages will
be
generated by the cape itself...
-- 5V solder header Pin2-Pin3 connected. 5V from the beagle.
-- 3,3V from the beagle

Therefore the atmega`s can only power up when the 3.3v supply of
the header is available.
The 5v supply is always on thats right. But 5v is only used for
LED`s and the Piezo Buzzer and this parts are
disconnected with a BC817 from ground.

Yes all wires which are named as GND are connected.

Do you really see an issue on that? What needs to be changed?

Am Montag, 15. September 2014 21:56:47 UTC+2 schrieb Gerald:

Your regulator must be turned off until the VDD_3V3 rail comes
up. Right now it comes up almost immediately as it is powered from
either
the expansion header or a weirdly designed 5V DC input. The idea of
gating
the ground to control power will not work as you already have a DC
path to
ground, assuming that all of your grounds are connected together as
they should be.

Gerald

On Mon, Sep 15, 2014 at 2:45 PM, mitterma...@gmail.com wrote:

Oh I understood, I need to add the C1 on each Atmega 3V3
supply. -- blocking
https://dict.leo.org/ende/index_de.html#/search=blockingsearchLoc=0resultOrder=basicmultiwordShowSingle=on

Re: [beagleboard] Re: Beaglebone Black Rebooting Several Times Every Day

2014-09-16 Thread Chris Morgan

On Tue, Sep 16, 2014 at 11:42 AM, Thomas Olofsson skjor...@gmail.com wrote:
 Greg we are experiencing the same issues as well with reset not bringing up
 the eth0 interface. we were trying to do a hw watchdog that would reset the
 board and when we press reset the eth0 interface fails as well. We are also
 setting the interface config static in /etc/network/interfaces.




 --Skjortan!

 On Tue, Sep 16, 2014 at 2:28 PM, Greg Kelley suekkel...@gmail.com wrote:

 I just changed over to the Switching Power Supply and eth0 failed to come
 up on boot. I hit the reset button and a reboot brought it up. So now it
 seems there are eth0 issues as well as resets. Going from bad to worse.

 --
 For more options, visit http://beagleboard.org/discuss
 ---


I very much appreciate your efforts in looking at these issues. The
company I work for is planning to use a BBB in a commercial product,
after discussions with CircuitCo, and this issue has me a little bit
worried. We haven't had a wide enough scale usage to know if we are
seeing something similar here with the resets and eth0 issues.

Looking forward to observing as you guys continue to work through this stuff.

Chris

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because 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: Beaglebone Black Rebooting Several Times Every Day

I plan to address this on the Ethernet issue in the next revision of the
board in the form of a GPIO based recovery mechanism that will allow SW to
reset the Ethernet PHY.

Gerald


On Tue, Sep 16, 2014 at 11:53 AM, Chris Morgan chmor...@gmail.com wrote:

 On Tue, Sep 16, 2014 at 11:42 AM, Thomas Olofsson skjor...@gmail.com
 wrote:
  Greg we are experiencing the same issues as well with reset not bringing
 up
  the eth0 interface. we were trying to do a hw watchdog that would reset
 the
  board and when we press reset the eth0 interface fails as well. We are
 also
  setting the interface config static in /etc/network/interfaces.
 
 
 
 
  --Skjortan!
 
  On Tue, Sep 16, 2014 at 2:28 PM, Greg Kelley suekkel...@gmail.com
 wrote:
 
  I just changed over to the Switching Power Supply and eth0 failed to
 come
  up on boot. I hit the reset button and a reboot brought it up. So now it
  seems there are eth0 issues as well as resets. Going from bad to worse.
 
  --
  For more options, visit http://beagleboard.org/discuss
  ---


 I very much appreciate your efforts in looking at these issues. The
 company I work for is planning to use a BBB in a commercial product,
 after discussions with CircuitCo, and this issue has me a little bit
 worried. We haven't had a wide enough scale usage to know if we are
 seeing something similar here with the resets and eth0 issues.

 Looking forward to observing as you guys continue to work through this
 stuff.

 Chris

 --
 For more options, visit http://beagleboard.org/discuss
 ---
 You received this message because 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 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: Beaglebone Black Rebooting Several Times Every Day

On Tue, Sep 16, 2014 at 11:53 AM, Chris Morgan chmor...@gmail.com wrote:
 On Tue, Sep 16, 2014 at 11:42 AM, Thomas Olofsson skjor...@gmail.com wrote:
 Greg we are experiencing the same issues as well with reset not bringing up
 the eth0 interface. we were trying to do a hw watchdog that would reset the
 board and when we press reset the eth0 interface fails as well. We are also
 setting the interface config static in /etc/network/interfaces.




 --Skjortan!

 On Tue, Sep 16, 2014 at 2:28 PM, Greg Kelley suekkel...@gmail.com wrote:

 I just changed over to the Switching Power Supply and eth0 failed to come
 up on boot. I hit the reset button and a reboot brought it up. So now it
 seems there are eth0 issues as well as resets. Going from bad to worse.

 --
 For more options, visit http://beagleboard.org/discuss
 ---


 I very much appreciate your efforts in looking at these issues. The
 company I work for is planning to use a BBB in a commercial product,
 after discussions with CircuitCo, and this issue has me a little bit
 worried. We haven't had a wide enough scale usage to know if we are
 seeing something similar here with the resets and eth0 issues.

 Looking forward to observing as you guys continue to work through this stuff.

we do have a phy workaround:

https://github.com/RobertCNelson/bb-kernel/blob/am33x-v3.16/patches/beaglebone/phy/0003-cpsw-search-for-phy.patch

i need to rebase it to the 3.14-ti tree..

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 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: Adafruit serial UART library seems to have wrong tty names

2014-09-16 Thread Michel Lavoie

Sorry, I didn't notice that Adafruit took care of exporting the overlays. 
Can't help with UART3 and 5 not working, I've only used 0, 1 and 2 so far.

Michel

On Tuesday, September 16, 2014 6:48:57 AM UTC-4, c...@isbd.net wrote:

 Michel Lavoie lavoie...@gmail.com javascript: wrote: 
  [-- text/plain, encoding quoted-printable, charset: UTF-8, 81 lines --] 
  
  I strongly recommend that you read Adafruit's guide regarding the BBB's 
  device tree overlay. It really help me put this all together: 
  
 https://learn.adafruit.com/introduction-to-the-beaglebone-black-device-tree/overview
  
  
  You will find there why and how to modify your uEnv.txt file in order to 
  enable ttyO1. In mine, the last line looks like this: 
  
  ... 
  optargs=coherent_pool=1M; capemgr.enable_partno=BB-UART1,BB-SPIDEV0 
  
  optargs=coherent_pool=1M; capemgr.enable_partno=BB-UART1,BB-SPIDEV0 
  
  optargs=coherent_pool=1M; capemgr.enable_partno=BB-UART1,BB-SPIDEV0 
  
  optargs=coherent_pool=1M; capemgr.enable_partno=BB-UART1,BB-SPIDEV0 
  
  
 The Adafruit UART IO documentation specifically says that it *does* 
 export the overlays:- 

 The Adafruit IO Python library will export the UART device tree 
 overlays as a convenience. There are five serial ports brought to 
 the expansion headers (UART3 only has a single direction, TX), and 
 one (UART0) with dedicated headers that aren't available to use in 
 your Python programs. 

 ... but not all the UARTs work. 

 In addition the use of the letter O in the device name is just silly! :-) 

 The devices it creates are called /dev/ttyO1, /dev/ttyO2, etc. with 
 the letter O.  There's not a mention anywhere that it's a letter 
 rather than a digit and given the context it's second nature to assume 
 it's a zero.  Still I did spot that eventually. 

 -- 
 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] Re: Beaglebone Black Rebooting Several Times Every Day

Well. That would be nice to have everywhere.

Gerald


On Tue, Sep 16, 2014 at 12:00 PM, Robert Nelson robertcnel...@gmail.com
wrote:

 On Tue, Sep 16, 2014 at 11:53 AM, Chris Morgan chmor...@gmail.com wrote:
  On Tue, Sep 16, 2014 at 11:42 AM, Thomas Olofsson skjor...@gmail.com
 wrote:
  Greg we are experiencing the same issues as well with reset not
 bringing up
  the eth0 interface. we were trying to do a hw watchdog that would reset
 the
  board and when we press reset the eth0 interface fails as well. We are
 also
  setting the interface config static in /etc/network/interfaces.
 
 
 
 
  --Skjortan!
 
  On Tue, Sep 16, 2014 at 2:28 PM, Greg Kelley suekkel...@gmail.com
 wrote:
 
  I just changed over to the Switching Power Supply and eth0 failed to
 come
  up on boot. I hit the reset button and a reboot brought it up. So now
 it
  seems there are eth0 issues as well as resets. Going from bad to worse.
 
  --
  For more options, visit http://beagleboard.org/discuss
  ---
 
 
  I very much appreciate your efforts in looking at these issues. The
  company I work for is planning to use a BBB in a commercial product,
  after discussions with CircuitCo, and this issue has me a little bit
  worried. We haven't had a wide enough scale usage to know if we are
  seeing something similar here with the resets and eth0 issues.
 
  Looking forward to observing as you guys continue to work through this
 stuff.

 we do have a phy workaround:


 https://github.com/RobertCNelson/bb-kernel/blob/am33x-v3.16/patches/beaglebone/phy/0003-cpsw-search-for-phy.patch

 i need to rebase it to the 3.14-ti tree..

 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 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 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: Beaglebone Black Rebooting Several Times Every Day

On Tue, Sep 16, 2014 at 12:56 PM, Gerald Coley ger...@beagleboard.org wrote:
 Well. That would be nice to have everywhere.

It is all the bone branches, except in the new 3.14-ti tree...  It
was one of those, I was just tagging a new release, oh crap, should
have added that. But was in a race to leave work today to run some
errands. ;)  It'll be the first thing i add back later.

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 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: Beaglebone Black Rebooting Several Times Every Day

Thank you!

Gerald

On Tue, Sep 16, 2014 at 12:59 PM, Robert Nelson robertcnel...@gmail.com
wrote:

 On Tue, Sep 16, 2014 at 12:56 PM, Gerald Coley ger...@beagleboard.org
 wrote:
  Well. That would be nice to have everywhere.

 It is all the bone branches, except in the new 3.14-ti tree...  It
 was one of those, I was just tagging a new release, oh crap, should
 have added that. But was in a race to leave work today to run some
 errands. ;)  It'll be the first thing i add back later.

 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 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 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] SD card issue with beaglebone black

2014-09-16 Thread sanjay ahuja

Hi Robert,

Do you have any pointer to steps for partitioning it as ext4. The link I
followed specifically mentioned that partition type must be 'FAT'. The
content of uEnv.txt as provided there is
mmcdev=1
bootpart=1:2
mmcroot=/dev/mmcblk1p2 ro
optargs=quiet

Would it remain same if partition type is 'ext4' or some values would
change?

On Tue, Sep 16, 2014 at 8:58 PM, Robert Nelson robertcnel...@gmail.com
wrote:

 On Tue, Sep 16, 2014 at 10:22 AM, sanjay ahuja
 sanjayahuja.i...@gmail.com wrote:
  Hi,
 
  I tried using microSD card as extra storage for my beaglebone black. I
  followed the steps as mentioned at
  http://elinux.org/Beagleboard:MicroSD_As_Extra_Storage.
 
  I was able to use mount microSD card successfully. However I am facing
 some
  strange issue.
 
  when I do ls -lart on the mounted drive the permissions are
 
  drwx--  5 root root 16384 Jan  1  1970 drive
 
 
  If I try chmod o+rx,g+rx /media/drive, to change the permissions, it does
  not work. No error on issuing chmod command but permission does not get
  change.
 
  Infact I am not even able to change the user permission for any
 executable
  file under directory 'drive'.
 
  For ex.
  bash-4.2# ls -lart /media/drive/jdk1.7.0_60/bin/java
  -rw-r--r-- 1 root root 5822 May  7 20:26
 /media/drive/jdk1.7.0_60/bin/java
 
  bash-4.2# chmod u+x /media/drive/jdk1.7.0_60/bin/java
 
  bash-4.2# ls -lart /media/drive/jdk1.7.0_60/bin/java
  -rw-r--r-- 1 root root 5822 May  7 20:26
 /media/drive/jdk1.7.0_60/bin/java
 
  Since 'x' permission is missing, I am not able to execute any binary
 file. I
  am logged in as root user only. The jdk directory is expanded from jdk
  installer zip using command
  tar -xvf Downloads/jdk-7u60-linux-arm-vfp-sflt --owner root --group root
  --no-same-owner.
 
  No issues are encountered if the jdk directory is expanded under home
  directory instead of SD card.
 
  The partition details for SD Card:
 
  Usage : Filesystem
  Partition type: W95 FAT16 (LBA) (0x0e)
  Type: FAT (16-bit version)
  Device: /device/mmcblk1p1
  Mount Point: Mounted at /media/drive

 re-partition it as ext4... fat16 doesnt' support user permissions..

 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/BGri5BFH2W4/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] Can I prevent BBB from booting from microSD?

2014-09-16 Thread John Syn


On 9/16/14, 3:00 AM, c...@isbd.net c...@isbd.net wrote:

I have a rev A6 (I think) BBB with the 2Gb eMMC memory.  I installed a
microSd card with Ubuntu on it and it has been booting from that quite
happily for the past few months.

I now seem to have currupted the Ubuntu image on the microSD card such
that it no longer boots successfully.  If I remove the microSD then
the BBB boots OK from the eMMC into Angstrom.

Is there any way I can force the BBB to boot from eMMC even though
there's a microSD card plugged in?  I want to recover some files from
the microSD card and I'm away from home and don't have any other means
of reading the microSD.

I do also have a revC BBB here but I guess that isn't going to act any
differently from the older one.
Boot up Angstrom and then insert your SDCard. Use dmesg to confirm the
card was recognized and then mount the SDCard.

Regards,
John

-- 
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.


-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because 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] SD card issue with beaglebone black

2014-09-16 Thread sanjay ahuja

Basically what should be content of uEnv.txt if we are mounting external SD 
card with partition type 'ext4'?

On Tuesday, September 16, 2014 11:43:15 PM UTC+5:30, sanjay ahuja wrote:

 Hi Robert,

 Do you have any pointer to steps for partitioning it as ext4. The link I 
 followed specifically mentioned that partition type must be 'FAT'. The 
 content of uEnv.txt as provided there is
 mmcdev=1
 bootpart=1:2
 mmcroot=/dev/mmcblk1p2 ro
 optargs=quiet

 Would it remain same if partition type is 'ext4' or some values would 
 change?

 On Tue, Sep 16, 2014 at 8:58 PM, Robert Nelson robertcnel...@gmail.com 
 wrote:

 On Tue, Sep 16, 2014 at 10:22 AM, sanjay ahuja
 sanjayahuja.i...@gmail.com wrote:
  Hi,
 
  I tried using microSD card as extra storage for my beaglebone black. I
  followed the steps as mentioned at
  http://elinux.org/Beagleboard:MicroSD_As_Extra_Storage.
 
  I was able to use mount microSD card successfully. However I am facing 
 some
  strange issue.
 
  when I do ls -lart on the mounted drive the permissions are
 
  drwx--  5 root root 16384 Jan  1  1970 drive
 
 
  If I try chmod o+rx,g+rx /media/drive, to change the permissions, it 
 does
  not work. No error on issuing chmod command but permission does not get
  change.
 
  Infact I am not even able to change the user permission for any 
 executable
  file under directory 'drive'.
 
  For ex.
  bash-4.2# ls -lart /media/drive/jdk1.7.0_60/bin/java
  -rw-r--r-- 1 root root 5822 May  7 20:26 
 /media/drive/jdk1.7.0_60/bin/java
 
  bash-4.2# chmod u+x /media/drive/jdk1.7.0_60/bin/java
 
  bash-4.2# ls -lart /media/drive/jdk1.7.0_60/bin/java
  -rw-r--r-- 1 root root 5822 May  7 20:26 
 /media/drive/jdk1.7.0_60/bin/java
 
  Since 'x' permission is missing, I am not able to execute any binary 
 file. I
  am logged in as root user only. The jdk directory is expanded from jdk
  installer zip using command
  tar -xvf Downloads/jdk-7u60-linux-arm-vfp-sflt --owner root --group root
  --no-same-owner.
 
  No issues are encountered if the jdk directory is expanded under home
  directory instead of SD card.
 
  The partition details for SD Card:
 
  Usage : Filesystem
  Partition type: W95 FAT16 (LBA) (0x0e)
  Type: FAT (16-bit version)
  Device: /device/mmcblk1p1
  Mount Point: Mounted at /media/drive

 re-partition it as ext4... fat16 doesnt' support user permissions..

 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/BGri5BFH2W4/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.

[beagleboard] Re: Reading analog inputs fast in beaglebone black

2014-09-16 Thread mahmoud-ashi

Hello sir, I was following your steps but I got an error in the last step. 
I created a file in 
bbb_fbc-0.0.2/FB_prussdrv-0.0/libpruio-0.0.2/libpruio/src/c_wrapper and 
named it bbb-io.c and pasted the code you wrote. I then created another 
file named it Makefile and pasted all: bbb-io.c Makefile
gcc -Wall -o bbb-io bbb-io.c /usr/local/lib/freebasic/fbrt0.o 
-lpruio -L/usr/local/lib/freebasic/ -lfb -lpthread -lprussdrv -ltermcap 
-lsupc++ -Wno-unused-variable in it. after running make command, I got 
the following:

/usr/bin/ld: cannot find -lncurses
collect2: ld returned 1 exit status
make: *** [all] Error 1

Any ideas how to solve it? I'm running Linux beaglebone 3.8.13-bone50 #1 
SMP Tue May 13 13:24:52 UTC 2014 armv7l GNU/Linux on my beaglebone black.
I am setting the libpruio library to read from the all the 7 analog pins 
with a sampling rate of 40KHz at least for each pin. You're help os 
appreciated. Thanks.
On Sunday, June 22, 2014 1:39:56 AM UTC+3, Rafael Vega wrote:

 Here's what I did:


 1. Install FreeBasic compiler in BBB

 1.1. Download package from 
 http://www.freebasic-portal.de/downloads/fb-on-arm/bbb-fbc-fbc-fuer-beaglebone-black-283.html

wget http://www.freebasic-portal.de/dlfiles/452/bbb_fbc-0.0.2.tar.xz

 1.2. Uncompress and copy files

cd bbb_fbc-0.0.2
cp usr/local/bin/fbc /usr/local/bin/
cp -R usr/local/lib/freebasic /usr/local/lib/

 2. Install pruss driver kit for freebasic and BBB.

 2.1. Download and uncompress package from 
 http://www.freebasic-portal.de/dlfiles/539/FB_prussdrv-0.0.tar.bz2

 2.2. Copy files

cd FB_prussdrv-0.0
cp bin/libprussdrv.* /usr/local/lib
ldconfig
mkdir /usr/local/include/freebasic/BBB
cp include/* /usr/local/include/freebasic/BBB
cp bin/pasm/usr/local/bin
cp bin/PRUSSDRV-00A0.dtbo /lib/firmware

 2.3. Install am335x-pru-package 

apt-get install am335x-pru-package  

 2.4. Activate the PRUSS by enabling the tree overlay. This must be done 
 everytime, after each boot or before running your programs. 

echo PRUSSDRV /sys/devices/bone_capemgr.9/slots

 3. Install libpruio

 3.1. Download and uncompress package from 
 http://www.freebasic-portal.de/dlfiles/554/libpruio-0.0.2.tar.bz2

 3.2. Copy files

cd libpruio-0.0.2
cd src/c_wrapper/
cp libpruio.so /usr/local/lib
cp libpruio.a /usr/local/lib
ldconfig
cd ../pruio/
cp pruio.bi /usr/local/include/freebasic/BBB
cp pruio.hp /usr/local/include/freebasic/BBB
cp pruio_pins.bi /usr/local/include/freebasic/BBB

 4. Here's a simple example C program that uses the library

#include stdio.h
#include unistd.h
#include pruio_c_wrapper.h
#include pruio_pins.h

int main(int argc, const char *argv[]) { 
   PruIo *io = pruio_new(0, 0x98, 0, 1);
   if (io-Errr) {
  printf(Initialisation failed (%s)\n, io-Errr);
  return 1;
   }

   if(pruio_config(io, 0, 0x1FE, 0, 4, 0)){
  printf(Config failed (%s)\n, io-Errr); 
  return 1;
   }

   int a = 0;
   int i;
   while(1){
  printf(\r%12o  %12o  %12o  %12o  %4X %4X %4X %4X %4X %4X %4X 
 %4X\n, io-Gpio[0].Stat, io-Gpio[1].Stat, io-Gpio[2].Stat, 
 io-Gpio[3].Stat, io-Value[1], io-Value[2], io-Value[3], io-Value[4], 
 io-Value[5], io-Value[6], io-Value[7], io-Value[8]);
  fflush(STDIN_FILENO);
  usleep(1000);
}


   pruio_destroy(io);

return 0;
}

 5. To compile it, here's a makefile:

all: bbb-io.c Makefile
 gcc -Wall -o bbb-io bbb-io.c /usr/local/lib/freebasic/fbrt0.o 
 -lpruio -L/usr/local/lib/freebasic/ -lfb -lpthread -lprussdrv -ltermcap 
 -lsupc++ -Wno-unused-variable







-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because 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: Can I prevent BBB from booting from microSD?

John Syn john3...@gmail.com wrote:
 
 On 9/16/14, 3:00 AM, c...@isbd.net c...@isbd.net wrote:
 
 I have a rev A6 (I think) BBB with the 2Gb eMMC memory.  I installed a
 microSd card with Ubuntu on it and it has been booting from that quite
 happily for the past few months.
 
 I now seem to have currupted the Ubuntu image on the microSD card such
 that it no longer boots successfully.  If I remove the microSD then
 the BBB boots OK from the eMMC into Angstrom.
 
 Is there any way I can force the BBB to boot from eMMC even though
 there's a microSD card plugged in?  I want to recover some files from
 the microSD card and I'm away from home and don't have any other means
 of reading the microSD.
 
 I do also have a revC BBB here but I guess that isn't going to act any
 differently from the older one.
 Boot up Angstrom and then insert your SDCard. Use dmesg to confirm the
 card was recognized and then mount the SDCard.
 
So it's safe to insert the SD card into a powered up system is it?

-- 
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] Re: Can I prevent BBB from booting from microSD?

It is.

Gerald

On Tue, Sep 16, 2014 at 1:53 PM, c...@isbd.net wrote:

 John Syn john3...@gmail.com wrote:
 
  On 9/16/14, 3:00 AM, c...@isbd.net c...@isbd.net wrote:
 
  I have a rev A6 (I think) BBB with the 2Gb eMMC memory.  I installed a
  microSd card with Ubuntu on it and it has been booting from that quite
  happily for the past few months.
  
  I now seem to have currupted the Ubuntu image on the microSD card such
  that it no longer boots successfully.  If I remove the microSD then
  the BBB boots OK from the eMMC into Angstrom.
  
  Is there any way I can force the BBB to boot from eMMC even though
  there's a microSD card plugged in?  I want to recover some files from
  the microSD card and I'm away from home and don't have any other means
  of reading the microSD.
  
  I do also have a revC BBB here but I guess that isn't going to act any
  differently from the older one.
  Boot up Angstrom and then insert your SDCard. Use dmesg to confirm the
  card was recognized and then mount the SDCard.
 
 So it's safe to insert the SD card into a powered up system is it?

 --
 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.


-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because 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: Adafruit serial UART library seems to have wrong tty names

Michel Lavoie lavoie.mic...@gmail.com wrote:
 [-- text/plain, encoding quoted-printable, charset: UTF-8, 71 lines --]
 
 Sorry, I didn't notice that Adafruit took care of exporting the overlays. 
 Can't help with UART3 and 5 not working, I've only used 0, 1 and 2 so far.
 
How do you use 0 (zero), that would suit me well as it uses the header
that's not part of P8 or P9.

-- 
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] SD card issue with beaglebone black

2014-09-16 Thread William Hermans

sanjay, uEnv.txt should not have to change at all, content wise. Everything
in this file just tells uboot where:

1)  to load the kernel, and board file for the BBB

2) where the root file system is.

3) Lastly, optargs=quite means to be less verbose with kernel debug output
( I believe )

On Tue, Sep 16, 2014 at 11:38 AM, sanjay ahuja sanjayahuja.i...@gmail.com
wrote:

 Basically what should be content of uEnv.txt if we are mounting external
 SD card with partition type 'ext4'?


 On Tuesday, September 16, 2014 11:43:15 PM UTC+5:30, sanjay ahuja wrote:

 Hi Robert,

 Do you have any pointer to steps for partitioning it as ext4. The link I
 followed specifically mentioned that partition type must be 'FAT'. The
 content of uEnv.txt as provided there is
 mmcdev=1
 bootpart=1:2
 mmcroot=/dev/mmcblk1p2 ro
 optargs=quiet

 Would it remain same if partition type is 'ext4' or some values would
 change?

 On Tue, Sep 16, 2014 at 8:58 PM, Robert Nelson robertcnel...@gmail.com
 wrote:

 On Tue, Sep 16, 2014 at 10:22 AM, sanjay ahuja
 sanjayahuja.i...@gmail.com wrote:
  Hi,
 
  I tried using microSD card as extra storage for my beaglebone black. I
  followed the steps as mentioned at
  http://elinux.org/Beagleboard:MicroSD_As_Extra_Storage.
 
  I was able to use mount microSD card successfully. However I am facing
 some
  strange issue.
 
  when I do ls -lart on the mounted drive the permissions are
 
  drwx--  5 root root 16384 Jan  1  1970 drive
 
 
  If I try chmod o+rx,g+rx /media/drive, to change the permissions, it
 does
  not work. No error on issuing chmod command but permission does not get
  change.
 
  Infact I am not even able to change the user permission for any
 executable
  file under directory 'drive'.
 
  For ex.
  bash-4.2# ls -lart /media/drive/jdk1.7.0_60/bin/java
  -rw-r--r-- 1 root root 5822 May  7 20:26 /media/drive/jdk1.7.0_60/bin/
 java
 
  bash-4.2# chmod u+x /media/drive/jdk1.7.0_60/bin/java
 
  bash-4.2# ls -lart /media/drive/jdk1.7.0_60/bin/java
  -rw-r--r-- 1 root root 5822 May  7 20:26 /media/drive/jdk1.7.0_60/bin/
 java
 
  Since 'x' permission is missing, I am not able to execute any binary
 file. I
  am logged in as root user only. The jdk directory is expanded from jdk
  installer zip using command
  tar -xvf Downloads/jdk-7u60-linux-arm-vfp-sflt --owner root --group
 root
  --no-same-owner.
 
  No issues are encountered if the jdk directory is expanded under home
  directory instead of SD card.
 
  The partition details for SD Card:
 
  Usage : Filesystem
  Partition type: W95 FAT16 (LBA) (0x0e)
  Type: FAT (16-bit version)
  Device: /device/mmcblk1p1
  Mount Point: Mounted at /media/drive

 re-partition it as ext4... fat16 doesnt' support user permissions..

 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/BGri5BFH2W4/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.


-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because 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 3.14.17-ti-r19

I've been trying out
http://builds.beagleboard.org/builders/runtests/builds/39 that seems
to have several of these changes implemented...

On Tue, Sep 16, 2014 at 11:55 AM, Charles Steinkuehler
char...@steinkuehler.net wrote:
 On 9/16/2014 10:26 AM, Robert Nelson wrote:

 NM, found a work around..

 When we know what cape is installed, thus we are already building a
 *.dtb for it, just disable the pinmux, as it's already tied to the
 cape.

 diff --git a/arch/arm/boot/dts/am335x-bone-panel-480x272.dtsi
 b/arch/arm/boot/dts/am335x-bone-panel-480x272.dtsi
 index 2df34ce..138a619 100644
 --- a/arch/arm/boot/dts/am335x-bone-panel-480x272.dtsi
 +++ b/arch/arm/boot/dts/am335x-bone-panel-480x272.dtsi
 @@ -6,6 +6,12 @@
   * published by the Free Software Foundation.
   */

 +ocp {
 +   P9_27_pinmux {
 +   status = disabled;
 +   };
 +};
 +
  lcdc {
 status = okay;
  };

 Yes, that's what you need to do for now, and this is why no cape pins
 can be controlled at run-time without using a device-tree overlay (or
 changeset).

 What I'm working on is adding a setting to the pinmux helper, so rather
 than trying to have the LCD cape own the pinmux setting, it would just
 let the pinmux helper know it should start in a specific mode.

In general, I prefer leaving the pinmux helper in control, but I think
*some* of the lines might be *ok* to put under control of the LCD, no?


 ...but it looks like you might be assigning LEDs to the GPIO.  This
 causes the GPIO pin to be owned by the gpio-leds driver, making it
 impossible to use the pin as a GPIO for any other purpose.  I haven't
 worked out a solution for this, other than to not use the kernel
 gpio-leds driver (driving the LED from userspace) or just give up the
 option to reconfigure the I/O and let the kernel LED driver own it.

For normalcy, do we agree then to put everything possible into a
pinmux helper and simply impact the boot-up state of the helper?

I see one conflict here that needs to be resolved:
[   12.785659] pinctrl-single 44e10800.pinmux: pin 44e109ac.0 already
requested by P9_25_pinmux.30; cannot claim for 48038000.mcasp
[   12.798203] pinctrl-single 44e10800.pinmux: pin-107
(48038000.mcasp) status -22
[   12.806053] pinctrl-single 44e10800.pinmux: could not request pin
107 (44e109ac.0) from group mcasp0_pins  on device pinctrl-single
[   12.818665] davinci-mcasp 48038000.mcasp: Error applying setting,
reverse things back

Any idea why there isn't a status entry on the cape-universal node?
root@beaglebone:~# ls /sys/devices/ocp.3/cape-universal.41/
modalias  power  subsystem  uevent

Full boot log: http://pastebin.com/JJkRic8h

BTW, this build seems to have resolved the funny P9_14 issue being
associated with the uSD card.


 --
 Charles Steinkuehler
 char...@steinkuehler.net

 --
 For more options, visit http://beagleboard.org/discuss
 ---
 You received this message because you are subscribed to the Google Groups 
 BeagleBoard group.
 To unsubscribe from this group and stop receiving emails from it, send an 
 email to beagleboard+unsubscr...@googlegroups.com.
 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] Re: BBB MultiCast

2014-09-16 Thread Brandon I

First google result seems useful:

http://stackoverflow.com/questions/16374670/why-i-can-not-disable-multicast-request

On Tuesday, September 16, 2014 7:14:10 AM UTC-7, Mickae1 wrote:

 I've tried to deactivate the Multicast with :

 ifconfig eth0 -multicast

 But when i check with this command, I can still see :

 ip maddr show

 2:  eth0
 link  33:33:00:00:00:01
 link  01:00:5e:00:00:01
 link  33:33:ff:9a:05:07
 *inet  224.0.0.1*
 inet6 ff02::1:ff9a:507
 inet6 ff02::1


 Which is not good for me !


 i've tried :

 debian@beaglebone:/Distrib/Scripts$ sudo ip -r maddr delete 224.0.0.1 dev 
 eth0

 ioctl: No such file or directory


 I also tried to ping 224.0.0.1 from an another device . 

 And with the command tcpdump I can see that I'm receiving multicast packet 
 :

 debian@beaglebone:/Distrib/Scripts$ sudo tcpdump -p -i eth0 host 224.0.0.1 
 -n

 tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
 listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes
 16:09:28.679257 IP *190.190.167.1  224.0.0.1*: ICMP echo request, id 1, 
 seq 1913, length 40





 Why ? I really don't know what to do about it, My idea is to deactivate 
 multicast in the kernel build config . Does it sounds good for you ?



 Thank you,


 Micka.


-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because 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] Installing Kali Linux (Arm) onto BeagleBone Black Rev C

2014-09-16 Thread macubergeekster

Would anyone know of a set of instructions on how to install Kali to the 
BeagleBone Black Rev 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] Re: Build a QT/11 application for beagleboard black by cross compiling from ubuntu

2014-09-16 Thread Mirko Fucci

Hi Peter,

apologise for the delay, at the end I decided to develop for linuxfb cross
compiling QT embedded.
However in one of my attempts i had succesfull compiled QT for X-server and
the application run in X environment. I didn't need to solve X server
dependencies in this case but i really couldn't find the right
configuration i used to compile QT, sorry.

Mirko

2014-09-10 16:21 GMT+02:00 Peter Gregory talkto...@gmail.com:

 Hi Mirko,

 How did you get rid of the X server dependencies?
 I'm using QT Creator.  Building a new QT application seems to require X
 server.
 On a headless version of Ubuntu 14.04 I can get the pre-compiled demos to
 work using -platform linuxfb
 However, my custom compiled code bombs out trying to start X server.
 Is there a special way to build the project to target linuxfb?

 --
 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/mb1R6NF5RH4/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] Building kernel 3.14.17-ti-r19

On 9/16/2014 2:23 PM, Jason Kridner wrote:
 On Tue, Sep 16, 2014 at 11:55 AM, Charles Steinkuehler
 char...@steinkuehler.net wrote:

 What I'm working on is adding a setting to the pinmux helper, so rather
 than trying to have the LCD cape own the pinmux setting, it would just
 let the pinmux helper know it should start in a specific mode.
 
 In general, I prefer leaving the pinmux helper in control, but I think
 *some* of the lines might be *ok* to put under control of the LCD, no?

As Robert showed, the pinmux helper can easily be disabled for
particular pins, allowing them to be directly owned by the driver (and
making them difficult or impossible to change w/o DT overlays or
changesets).

If you want to leave pinmux in control, one needs faith in the end users
and some enlightenment of the config-pin utility is in order to help
keep folks from shooting themselves in the foot.  Any pins not needing
to be modified by user-space (ie: signals that don't go to the P8/P9
headers) can probably remain under control of the appropriate driver w/o
issue.

I've got a modified version of the pinmux-helper, device-tree, and
config-pin that allow modifying the i2c2 lines after boot.  Give me a
bit to get everything organized and pushed to github (three patch-sets
to push...ugh!) and I'll post an RFC.

-- 
Charles Steinkuehler
char...@steinkuehler.net

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
BeagleBoard group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Re: CAN bus recovery

2014-09-16 Thread Adrian Remonda

Witch kernel are you using?  Using the can cape that uses the can1
interface, I'm having some troubles with the 3.8 of Robert.

After I send some packages it just silently stop sending and I have to do a
ifdown ifup in order to make it run again. This didn't  happen with the
Kernel version of the Angstrom.
Any ideas?

Any hint how to activate the can1 in the device tree of the 3.15?


On 12 September 2014 02:21, Brent Sink brent.s...@gmail.com wrote:

 Ah, yes.  The TT3201 cape has three CAN channels, but two of them are over
 SPI.  This should help you out...


 https://github.com/beagleboard/devicetree-source/blob/master/arch/arm/boot/dts/TT3201-001-01.dts


 On Thu, Sep 11, 2014 at 8:00 PM, William Hermans yyrk...@gmail.com
 wrote:

 Thank Brent, However I was more curious about the bring up of the
 hardware on the BBB. IS there cape file I have not noticed yet ?
  If so I can probably figure it out on my own.

 On Thu, Sep 11, 2014 at 4:52 PM, Brent brent...@hotmail.com wrote:

 Well, I'm not reading a guide, but I'll share a few links that helped me
 get started.  I have a Qt application and I use the SocketCAN to read/write
 CAN messages.  This will work with J1939 as well.

 https://www.kernel.org/doc/Documentation/networking/can.txt
 http://en.wikipedia.org/wiki/SocketCAN
 http://www.can-cia.org/fileadmin/cia/files/icc/13/kleine-budde.pdf

 On Thursday, September 11, 2014 7:44:50 PM UTC-4, William Hermans wrote:

 Brent, what guide are you reading for CAN ? I've never used CAN
 personally, and am curious . . .

 On Thu, Sep 11, 2014 at 2:25 PM, Brent Sink brent...@gmail.com wrote:

 Adding restart-ms did the trick! Thanks so much, I never knew that was
 even there.

 On Wed, Sep 10, 2014 at 8:37 PM, Devan Lai deva...@gmail.com wrote:

 You can configure the controller to automatically recover from
 bus-off conditions by setting the restart-ms option.

 The python-can documentation has some useful notes on socket-can and
 bus-off conditions:

 http://python-can.readthedocs.org/en/latest/socketcan.html#can-errors


 On Wednesday, September 10, 2014 9:39:21 AM UTC-7, Brent wrote:

 I have noticed that if I short CAN_H and CAN_L together, or if there
 is noise on the bus, the BeagleBone will stop sending and receiving CAN
 messages.  When this happens, if I execute ifconfig can0 down and
 ifconfig can0 up, things start working again.  Is there a way to 
 detect
 this automatically and recover?  I'm using SocketCAN, but haven't found
 anything that would tell me when I get a bus off or bus heavy.

  --
 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/SdvoxYkgagc/unsubscribe.
 To unsubscribe from this group and all its topics, send an email to
 beagleboard...@googlegroups.com.
 For more options, visit https://groups.google.com/d/optout.




 --
 -brent

 --
 For more options, visit http://beagleboard.org/discuss
 ---
 You received this message because 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.


  --
 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/SdvoxYkgagc/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.




 --
 -brent

 --
 For more options, visit http://beagleboard.org/discuss
 ---
 You received this message because 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 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] RFC: Add mode setting to bone-pinmux-helper

Request For Comment
===

In order to make the cape-universal approach to modifying the BeagleBone
I/O setup at runtime via user-land (ie: no kernel driver and no
device-tree overlays or changesets), the bone-pinmux-helper driver needs
to be in control of the pinmux register for each I/O pin.  It is not
currently possible, however, to (easily) set the default pinmux mode for
the bone-pinmux-helper.

Therefore, I have modified the bone-pinmux-helper code to support a
mode parameter in the device tree:

https://github.com/cdsteinkuehler/linux/commit/e0e0f1da3f2df4bc4ee2b27a65ee99734bd3fb77

...which allows a device tree fragment to specify the startup default
mode of the pinmux from one of the available choices:

https://github.com/cdsteinkuehler/dtb-rebuilder/commit/b78226fdf0c420dcadf8a606e4795cefbc8c7428

...and a tweaked the config-pin utility supporting the new options:

https://github.com/cdsteinkuehler/beaglebone-universal-io/commit/e742ff15f7abbc2cf80141ea49269eb0a2f2a8b3

This will allow any initial hardware pinmux configuration to be
overridden by user-space code at run-time, making it possible to switch
(for instance) the i2c2 cape EEPROM bus to standard GPIO pins as shown
in this example.

Takeover of the i2c2 bus is intended mainly as a proof-of-concept, the
real power of this approach is the ability to do things like enable SPI
or a UART in the boot-time device tree and have the pin muxing correct,
but be able to override the pinmux settings once the system is booted
(perhaps turning an unused RxD line into a useful PWM or similar).  This
also makes it possible to modify the pinmux hardware configuration as
soon as sysfs is available (ie: very early in the system boot stage).
Who wants to write the user-mode version of cape-manager?!?

-- 
Charles Steinkuehler
char...@steinkuehler.net

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
BeagleBoard group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Re: Installing Kali Linux (Arm) onto BeagleBone Black Rev C

2014-09-16 Thread verminsky2

http://www.offensive-security.com/kali-linux-vmware-arm-image-download/



On Tuesday, September 16, 2014 12:47:59 PM UTC-7, macuber...@gmail.com 
wrote:

 Would anyone know of a set of instructions on how to install Kali to the 
 BeagleBone Black Rev 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] Custom Audio cape with TLV320AIC3107 codec.

2014-09-16 Thread Jesse Cobra

OK, and what is different between your board and CircuitCo schematic wise?
On Sep 16, 2014 8:53 AM, Prakash Parmar prakash.parma...@gmail.com
wrote:

Hi,

Here CircuitCo cape is not available So we decided to make our own.

On Tue, Sep 16, 2014 at 7:20 PM, Jesse Cobra jesseco...@gmail.com wrote:

What happens when you try the CircuitCO audio cape?
Does it work fine?

On Mon, Sep 15, 2014 at 10:14 PM, Prakash Parmar
prakash.parma...@gmail.com wrote:

Hi,

How I can check this two things ?

2) check if SYS_RESET is actually deasserted and high
3) check if DIN/DOUT are correctly connected and not flipped, because
DIN data must go into CODEC, while DOUT must go out and vise versa

I'm not clear about this. Actually I have two Boards one with 10K
resistors and one with 4.6K .

Thanks Regards,
Prakash P.

On Tue, Sep 16, 2014 at 12:34 AM, Maxim Podbereznyy lisar...@gmail.com
wrote:

what is exactly not clear for you?

how to change resistors or how to copy/paste commands in a shell?

2014-09-15 21:46 GMT+04:00 prakash.parma...@gmail.com:

HI,
Thanks For reply.

Can you please tell me how I can Do that ?

Thanks Regards,
Prakash P.

On Monday, September 15, 2014 8:01:19 PM UTC+5:30, liyaoshi wrote:

Have you config the i2c pin pulled up ?
and
whats the speed of your i2c bus ?

2014-09-15 2:09 GMT+08:00 prakash@gmail.com:

Hi,

I have made custom Audio cape using TLV320AIC3107. Here is a circuit
diagram :

http://e2e.ti.com/cfs-file.ashx/__key/telligent-evolution-components-attachments/00-64-01-00-01-29-55-62/audio.png

But my problem is when I run speaker-test system hangs (freezes) and
I have to Hard Reset BeagleBone.

Here is what i did and what I get in dmesg.

*root@beaglebone:~# speaker-test *

speaker-test 1.0.25

*And in Dmesg : *

I also cross check device tree file and I found that it also works
for TLV320AIC3107 codec So I think it is not issue.

An one have Idea what is wrong Please Help ME

Thanks Regards

Prakash P.

--
For more options, visit http://beagleboard.org/discuss
---
You received this message because 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.

--
LinkedIn - http://www.linkedin.com/in/maximpodbereznyy
Company - http://www.linkedin.com/company/mentorel
Facebook - https://www.facebook.com/mentorel.company

--
For more options, visit http://beagleboard.org/discuss
---
You received this message because 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

Re: [beagleboard] RFC: Add mode setting to bone-pinmux-helper

On Tue, Sep 16, 2014 at 4:53 PM, Charles Steinkuehler
char...@steinkuehler.net wrote:
 Request For Comment
 ===

 In order to make the cape-universal approach to modifying the BeagleBone
 I/O setup at runtime via user-land (ie: no kernel driver and no
 device-tree overlays or changesets), the bone-pinmux-helper driver needs
 to be in control of the pinmux register for each I/O pin.  It is not
 currently possible, however, to (easily) set the default pinmux mode for
 the bone-pinmux-helper.

 Therefore, I have modified the bone-pinmux-helper code to support a
 mode parameter in the device tree:

 https://github.com/cdsteinkuehler/linux/commit/e0e0f1da3f2df4bc4ee2b27a65ee99734bd3fb77

I did a quick read through that made sense, though I don't know the
specific functions.


 ...which allows a device tree fragment to specify the startup default
 mode of the pinmux from one of the available choices:

 https://github.com/cdsteinkuehler/dtb-rebuilder/commit/b78226fdf0c420dcadf8a606e4795cefbc8c7428

 ...and a tweaked the config-pin utility supporting the new options:

 https://github.com/cdsteinkuehler/beaglebone-universal-io/commit/e742ff15f7abbc2cf80141ea49269eb0a2f2a8b3

Approach looks good to me. I know the dropping of the pin assignment
in the i2c device tree itself will cause some heartache for some.

I don't see where you removed the definition of the i2c pin settings
themselves. Will not removing those entries cause headaches by someone
assuming they are used or is it comfortable for them to simply be
there by reference? I suspect it would only be an issue if a bug was
found in the setting and someone missed that the real mode was coming
from the helper.


 This will allow any initial hardware pinmux configuration to be
 overridden by user-space code at run-time, making it possible to switch
 (for instance) the i2c2 cape EEPROM bus to standard GPIO pins as shown
 in this example.

Woohoo! Hold on to your hats!


 Takeover of the i2c2 bus is intended mainly as a proof-of-concept, the
 real power of this approach is the ability to do things like enable SPI
 or a UART in the boot-time device tree and have the pin muxing correct,
 but be able to override the pinmux settings once the system is booted
 (perhaps turning an unused RxD line into a useful PWM or similar).  This
 also makes it possible to modify the pinmux hardware configuration as
 soon as sysfs is available (ie: very early in the system boot stage).
 Who wants to write the user-mode version of cape-manager?!?

It seems to me that the existing kernel module should be extended.
Extending config-pin to read cape EEPROMs and have a database of pin
settings is fine and I can understanding you wanting to find an owner
for that task, but if looking for a real replacement of cape-manager
(by that name) then real overlays still need to be
understood/supported as you still can't quite do all the
experimenting/fpga-ing you'd desire without being able to reconfigure
the rest of the device tree at runtime.


 --
 Charles Steinkuehler
 char...@steinkuehler.net

 --
 For more options, visit http://beagleboard.org/discuss
 ---
 You received this message because you are subscribed to the Google Groups 
 BeagleBoard group.
 To unsubscribe from this group and stop receiving emails from it, send an 
 email to beagleboard+unsubscr...@googlegroups.com.
 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] Re: RFC: Add mode setting to bone-pinmux-helper

2014-09-16 Thread Joshua Datko



Jason Kridner jkridner-hcmAuCOw+vXj4SYmN/t...@public.gmane.org writes:


 https://github.com/cdsteinkuehler/beaglebone-universal-io/commit/e742ff15f7abbc2cf80141ea49269eb0a2f2a8b3

 Approach looks good to me. I know the dropping of the pin assignment
 in the i2c device tree itself will cause some heartache for some.

 I don't see where you removed the definition of the i2c pin settings
 themselves. Will not removing those entries cause headaches by someone
 assuming they are used or is it comfortable for them to simply be
 there by reference? I suspect it would only be an issue if a bug was
 found in the setting and someone missed that the real mode was coming
 from the helper.


I've been trying to follow along with these changes and I admit, I
haven't been able to keep up.

Some questions:

1. My Cape DTS does not explicitly call out for i2c2 [1], with this
change does that, and all capes using i2c2, need to be fixed?

2. Is the default mode of pins P_19/20, once user space is reached, GPIO
or i2c2?

Josh


[1] 
https://github.com/RobertCNelson/linux-stable-rcn-ee/blob/29723a20cdfe75e81e964739284643ab32a38231/arch/arm/boot/dts/am335x-bone-crypto-00a0.dtsi

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because 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] RFC: Add mode setting to bone-pinmux-helper

On 9/16/2014 4:42 PM, Jason Kridner wrote:
 
 Approach looks good to me. I know the dropping of the pin assignment
 in the i2c device tree itself will cause some heartache for some.

Yes, but there's no other way to do this, AFAIK.  I would suggest
migrating the mode= settings and the device stanza into it's own include
file.  I tried more to make the minimal possible changes vs.
restructuring the whole device-tree layout (ie: I didn't want to try and
factor out the i2c2 device into it's own dtsi file).

 I don't see where you removed the definition of the i2c pin settings
 themselves. Will not removing those entries cause headaches by someone
 assuming they are used or is it comfortable for them to simply be
 there by reference? I suspect it would only be an issue if a bug was
 found in the setting and someone missed that the real mode was coming
 from the helper.

I didn't remove them, and they might still be useful.  It possible to
switch between the old style of pinmux control for devices and the
pinmux helper version, possibly even by using different dtsi include
files.  At this point I am not trying to advocate any particular device
tree layout (in terms of what goes into which include files), I'm simply
making the feature available.

If the modified pinmux helper is a sensible approach, we can start
talking about exactly what the device tree files should look like.

-- 
Charles Steinkuehler
char...@steinkuehler.net

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
BeagleBoard group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Re: RFC: Add mode setting to bone-pinmux-helper

On 9/16/2014 4:55 PM, Joshua Datko wrote:
 
 I've been trying to follow along with these changes and I admit, I
 haven't been able to keep up.
 
 Some questions:
 
 1. My Cape DTS does not explicitly call out for i2c2 [1], with this
 change does that, and all capes using i2c2, need to be fixed?

The i2c2 is typically defined by the base BeagleBone device tree (or
more specifically, am335x-bone-common-pinmux.dtsi in Robert's latest
device trees for 3.14).  The cape dtsi files (or overly files for 3.8)
generally only include things that need to be changed to support the
cape, so unless you were intentionally trying to modify the i2c2
hardware, you wouldn't reference it in you cape file.

Your cape file simply adds some target entries for the i2c2 bus, which
would work as expected and need no changes regardless of whether the
i2c2 pinmux is handled directly or by using the bone-pinmux-helper (the
device tree compiler will merge the main i2c2 definitions with your
additions).  By way of similar example, you're also not specifying the
base address of the i2c2 hardware, the interrupt(s) it uses, etc, but
that all works since it's pulled in from common dts files before your
cape file is included.

 2. Is the default mode of pins P_19/20, once user space is reached, GPIO
 or i2c2?

The purpose of this change is to allow the pinmux-helper to be in
control of the pin, but have it come up in the desired mode (i2c in this
case) instead of the default gpio mode, which is what would have
happened previously.

-- 
Charles Steinkuehler
char...@steinkuehler.net

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
BeagleBoard group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Loading kernel module for a network device with CAP_SYS_MODULE (deprecated). Use CAP_NET_ADMIN and alias netdev- instead.

2014-09-16 Thread Florian Hänel

I am getting these messages multiple times per second:

any idea whats going on here? how do I find out which device is causing it?

Sep 16 23:32:18 rgbmatrix cron[779]: (CRON) STARTUP (fork ok)
Sep 16 23:32:18 rgbmatrix cron[779]: (CRON) INFO (Running @reboot jobs)
Sep 16 23:32:20 rgbmatrix udhcpd[992]: udhcpd (v1.21.1) started
Sep 16 23:32:20 rgbmatrix udhcpd[992]: is interface usb0 up and configured?: 
Cannot assign requested address
Sep 16 23:32:20 rgbmatrix udhcpd[1022]: udhcpd (v1.21.1) started
Sep 16 23:32:20 rgbmatrix udhcpd[1022]: is interface usb0 up and configured?: 
Cannot assign requested address
Sep 16 23:32:20 rgbmatrix avahi-daemon[393]: Joining mDNS multicast group on 
interface usb0.IPv4 with address 192.168.7.2.
Sep 16 23:32:20 rgbmatrix avahi-daemon[393]: New relevant interface usb0.IPv4 
for mDNS.
Sep 16 23:32:20 rgbmatrix avahi-daemon[393]: Registering new address record for 
192.168.7.2 on usb0.IPv4.
Sep 16 23:32:20 rgbmatrix kernel: [   22.074688] IPv6: ADDRCONF(NETDEV_UP): 
usb0: link is not ready
Sep 16 23:32:20 rgbmatrix avahi-daemon[393]: Withdrawing address record for 
192.168.7.2 on usb0.
Sep 16 23:32:20 rgbmatrix avahi-daemon[393]: Leaving mDNS multicast group on 
interface usb0.IPv4 with address 192.168.7.2.
Sep 16 23:32:20 rgbmatrix avahi-daemon[393]: Interface usb0.IPv4 no longer 
relevant for mDNS.
Sep 16 23:32:20 rgbmatrix avahi-daemon[393]: Joining mDNS multicast group on 
interface usb0.IPv4 with address 192.168.7.2.
Sep 16 23:32:20 rgbmatrix avahi-daemon[393]: New relevant interface usb0.IPv4 
for mDNS.
Sep 16 23:32:20 rgbmatrix avahi-daemon[393]: Registering new address record for 
192.168.7.2 on usb0.IPv4.
Sep 16 23:32:20 rgbmatrix udhcpd[1031]: udhcpd (v1.21.1) started
Sep 16 23:32:25 rgbmatrix kernel: [   26.447805] init: plymouth-upstart-bridge 
main process ended, respawning
Sep 16 23:32:26 rgbmatrix kernel: [   27.339187] Loading kernel module for a 
network device with CAP_SYS_MODULE (deprecated).  Use CAP_NET_ADMIN and alias 
netdev- instead.
Sep 16 23:32:26 rgbmatrix kernel: [   27.408049] Loading kernel module for a 
network device with CAP_SYS_MODULE (deprecated).  Use CAP_NET_ADMIN and alias 
netdev- instead.
Sep 16 23:32:26 rgbmatrix kernel: [   27.515752] Loading kernel module for a 
network device with CAP_SYS_MODULE (deprecated).  Use CAP_NET_ADMIN and alias 
netdev- instead.
Sep 16 23:32:26 rgbmatrix kernel: [   27.631790] Loading kernel module for a 
network device with CAP_SYS_MODULE (deprecated).  Use CAP_NET_ADMIN and alias 
netdev- instead.
Sep 16 23:32:26 rgbmatrix ntpdate[978]: adjust time server 91.189.89.199 offset 
0.203703 sec
Sep 16 23:32:26 rgbmatrix kernel: [   27.757020] Loading kernel module for a 
network device with CAP_SYS_MODULE (deprecated).  Use CAP_NET_ADMIN and alias 
netdev- instead.
Sep 16 23:32:26 rgbmatrix kernel: [   27.849898] Loading kernel module for a 
network device with CAP_SYS_MODULE (deprecated).  Use CAP_NET_ADMIN and alias 
netdev- instead.
Sep 16 23:32:26 rgbmatrix kernel: [   27.904060] Loading kernel module for a 
network device with CAP_SYS_MODULE (deprecated).  Use CAP_NET_ADMIN and alias 
netdev- instead.
Sep 16 23:32:26 rgbmatrix kernel: [   27.955998] Loading kernel module for a 
network device with CAP_SYS_MODULE (deprecated).  Use CAP_NET_ADMIN and alias 
netdev- instead.
Sep 16 23:32:26 rgbmatrix kernel: [   28.008765] Loading kernel module for a 
network device with CAP_SYS_MODULE (deprecated).  Use CAP_NET_ADMIN and alias 
netdev- instead.
Sep 16 23:32:26 rgbmatrix kernel: [   28.064496] Loading kernel module for a 
network device with CAP_SYS_MODULE (deprecated).  Use CAP_NET_ADMIN and alias 
netdev- instead.
Sep 16 23:32:26 rgbmatrix kernel: [   28.123799] Loading kernel module for a 
network device with CAP_SYS_MODULE (deprecated).  Use CAP_NET_ADMIN and alias 
netdev- instead.
Sep 16 23:32:26 rgbmatrix kernel: [   28.181981] Loading kernel module for a 
network device with CAP_SYS_MODULE (deprecated).  Use CAP_NET_ADMIN and alias 
netdev- instead.
Sep 16 23:32:26 rgbmatrix kernel: [   28.239791] Loading kernel module for a 
network device with CAP_SYS_MODULE (deprecated).  Use CAP_NET_ADMIN and alias 
netdev- instead.
Sep 16 23:32:27 rgbmatrix kernel: [   28.297772] Loading kernel module for a 
network device with CAP_SYS_MODULE (deprecated).  Use CAP_NET_ADMIN and alias 
netdev- instead.


-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because 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: RFC: Add mode setting to bone-pinmux-helper

On Tue, Sep 16, 2014 at 6:06 PM, Charles Steinkuehler
char...@steinkuehler.net wrote:
 On 9/16/2014 4:55 PM, Joshua Datko wrote:

 I've been trying to follow along with these changes and I admit, I
 haven't been able to keep up.

 Some questions:

 1. My Cape DTS does not explicitly call out for i2c2 [1], with this
 change does that, and all capes using i2c2, need to be fixed?

 The i2c2 is typically defined by the base BeagleBone device tree (or
 more specifically, am335x-bone-common-pinmux.dtsi in Robert's latest
 device trees for 3.14).  The cape dtsi files (or overly files for 3.8)
 generally only include things that need to be changed to support the
 cape, so unless you were intentionally trying to modify the i2c2
 hardware, you wouldn't reference it in you cape file.

 Your cape file simply adds some target entries for the i2c2 bus, which
 would work as expected and need no changes regardless of whether the
 i2c2 pinmux is handled directly or by using the bone-pinmux-helper (the
 device tree compiler will merge the main i2c2 definitions with your
 additions).  By way of similar example, you're also not specifying the
 base address of the i2c2 hardware, the interrupt(s) it uses, etc, but
 that all works since it's pulled in from common dts files before your
 cape file is included.

 2. Is the default mode of pins P_19/20, once user space is reached, GPIO
 or i2c2?

 The purpose of this change is to allow the pinmux-helper to be in
 control of the pin, but have it come up in the desired mode (i2c in this
 case) instead of the default gpio mode, which is what would have
 happened previously.

Just going along to state the obvious...

eMMC and HDMI will be equally interesting tests and more practically
useful for more capes.

It will only be a matter of time before someone damages a board by:
A) setting an HDMI pin to a output without disabling the HDMI
B) driving an eMMC pin into conflict without putting the eMMC in reset

I don't think there is a simple way for the current pinmux helper to
check for these conditions, but it wouldn't hurt if any config-pin
sort of utility would check the state of those hardware control bits
before helping someone screw things up. :-)

Any way you can imagine a way to keep the current uEnv.txt lines to
disable both of those working without breaking compatibility?


 --
 Charles Steinkuehler
 char...@steinkuehler.net

 --
 For more options, visit http://beagleboard.org/discuss
 ---
 You received this message because you are subscribed to the Google Groups 
 BeagleBoard group.
 To unsubscribe from this group and stop receiving emails from it, send an 
 email to beagleboard+unsubscr...@googlegroups.com.
 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] Re: RFC: Add mode setting to bone-pinmux-helper

2014-09-16 Thread Sungjin Chun

Maybe somewhat off topic, however I cannot help but to ask this;

How can we disable HDMI in kernel version = 3.14? where we do not
have capemgr?

On Wed, Sep 17, 2014 at 7:37 AM, Jason Kridner jkrid...@beagleboard.org
wrote:

 On Tue, Sep 16, 2014 at 6:06 PM, Charles Steinkuehler
 char...@steinkuehler.net wrote:
  On 9/16/2014 4:55 PM, Joshua Datko wrote:
 
  I've been trying to follow along with these changes and I admit, I
  haven't been able to keep up.
 
  Some questions:
 
  1. My Cape DTS does not explicitly call out for i2c2 [1], with this
  change does that, and all capes using i2c2, need to be fixed?
 
  The i2c2 is typically defined by the base BeagleBone device tree (or
  more specifically, am335x-bone-common-pinmux.dtsi in Robert's latest
  device trees for 3.14).  The cape dtsi files (or overly files for 3.8)
  generally only include things that need to be changed to support the
  cape, so unless you were intentionally trying to modify the i2c2
  hardware, you wouldn't reference it in you cape file.
 
  Your cape file simply adds some target entries for the i2c2 bus, which
  would work as expected and need no changes regardless of whether the
  i2c2 pinmux is handled directly or by using the bone-pinmux-helper (the
  device tree compiler will merge the main i2c2 definitions with your
  additions).  By way of similar example, you're also not specifying the
  base address of the i2c2 hardware, the interrupt(s) it uses, etc, but
  that all works since it's pulled in from common dts files before your
  cape file is included.
 
  2. Is the default mode of pins P_19/20, once user space is reached, GPIO
  or i2c2?
 
  The purpose of this change is to allow the pinmux-helper to be in
  control of the pin, but have it come up in the desired mode (i2c in this
  case) instead of the default gpio mode, which is what would have
  happened previously.

 Just going along to state the obvious...

 eMMC and HDMI will be equally interesting tests and more practically
 useful for more capes.

 It will only be a matter of time before someone damages a board by:
 A) setting an HDMI pin to a output without disabling the HDMI
 B) driving an eMMC pin into conflict without putting the eMMC in reset

 I don't think there is a simple way for the current pinmux helper to
 check for these conditions, but it wouldn't hurt if any config-pin
 sort of utility would check the state of those hardware control bits
 before helping someone screw things up. :-)

 Any way you can imagine a way to keep the current uEnv.txt lines to
 disable both of those working without breaking compatibility?

 
  --
  Charles Steinkuehler
  char...@steinkuehler.net
 
  --
  For more options, visit http://beagleboard.org/discuss
  ---
  You received this message because you are subscribed to the Google
 Groups BeagleBoard group.
  To unsubscribe from this group and stop receiving emails from it, send
 an email to beagleboard+unsubscr...@googlegroups.com.
  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.


-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because 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: RFC: Add mode setting to bone-pinmux-helper

On 9/16/2014 5:43 PM, Sungjin Chun wrote:
 Maybe somewhat off topic, however I cannot help but to ask this;
 
 How can we disable HDMI in kernel version = 3.14? where we do not
 have capemgr?

Load a different device tree.  There's probably an easier way (there are
several available device trees already installed), but I would:

cd /opt/source/dtb-3.14-ti
vi src/arm/am335x-boneblack.dts

comment line 62, which loads am335x-boneblack-nxp-hdmi-audio.dtsi

make
sudo make install
sudo reboot

-- 
Charles Steinkuehler
char...@steinkuehler.net

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
BeagleBoard group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Kernel vs rootfs dependencies, general guidence, newbie

2014-09-16 Thread pthor

Hi guys,

I'm just about to start up my second try at learning more embedded linux, 
and got myself a BBB. I'm somewhat unexperienced with embedded linux, but 
have done some stuff (and reading) earlier: building kernels, applied some 
patches, building Qt, tslib, gstreamer for angstrom. But I have some doubts 
now and hope that you may help me with some guidence with a few specific 
and some more general questions.

My longterm goals is to set up a system where I can run newest Qt, support 
for display, audio and be able to play with driver and application 
development. 

Where I am:
- I've done some research lately and it seems like I want a newer kernel 
(3.14 for example) with SGX fixes, (for Qt 5) 
- The only graphical application I want to run is my own custom one, so I 
feel that non GUI Angstrom distro fits better than the supplied Debian 
distro. But I'm a little clueless regarding the roofs.
- Earlier I have relied on the distro provided with a development board, 
now I want better control and understanding.

*Is there any dependencies between the beaglebone 3.14 kernel and rootfs?*
Is it supposed to run with Debian rootfs only?
Can use the Angstrom build tool 
http://narcissus.angstrom-distribution.org/(or other method) to build a 
Angstrom rootfs and use the beaglebone 3.14 kernel out of the box?
Is there any version dependencies in the rootfs that I need to worry about?
Is there any benefit to look into yocto for me? It seems a bit overwhelming 
for me, at least now.

(With beaglebone 3.14 kernel i mean the kernel discussed in: BeagleBone 
Black switching to 3.14 kernel 
https://groups.google.com/forum/embed/?place=forum/beagleboardshowsearch=trueshowpopout=trueshowtabs=truehideforumtitle=trueparenturl=http%3A%2F%2Fbeagleboard.org%2FCommunity%2FForums#!category-topic/beagleboard/beaglebone-black/4eDQvQOkUkc
 )

*I dont understand all the details yet, but is all the beaglebone specific 
driver/cape/dts stuff provided with the kernel? Or is there some BSP stuff 
I need to provide in the rootfs? BSP is per definition a part of the 
kernel?*

*I have some books on device drivers and embedded linux from 2.6 kernel 
era. Is these books still relevant with 3.x kernels? Do you have some 
keywords regarding important topics that have changed? I guess Device tree 
is one.*

Sorry for a little long and unfocused thread, but I need some direction 
before I can contribiute more specific.
Any help is very much 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.

Re: [beagleboard] Re: RFC: Add mode setting to bone-pinmux-helper

On 9/16/2014 5:37 PM, Jason Kridner wrote:
 
 Just going along to state the obvious...
 
 eMMC and HDMI will be equally interesting tests and more practically
 useful for more capes.

I'll try and work up a patch set for HDMI, but it won't be until tomorrow.

 It will only be a matter of time before someone damages a board by:
 A) setting an HDMI pin to a output without disabling the HDMI

The worst that can happen with HDMI is a bus fight (driving an HDMI pin
without first configuring the BBB side as an input).  The HDMI framer
does not drive any signals back to the AM335x (other than I2C), so it
won't cause problems.  If you start playing with pinmux values you could
easily see wonky video, but that's not a break the hardware kind of
problem.

 B) driving an eMMC pin into conflict without putting the eMMC in reset

This is much more likely, and while it might not be easy to destroy the
hardware, it is probably pretty easy to corrupt the eMMC.  It might be
worth requiring loading an alternate device-tree to disable the eMMC,
which can make sure it stays in reset.

 I don't think there is a simple way for the current pinmux helper to
 check for these conditions, but it wouldn't hurt if any config-pin
 sort of utility would check the state of those hardware control bits
 before helping someone screw things up. :-)

Agreed!

 Any way you can imagine a way to keep the current uEnv.txt lines to
 disable both of those working without breaking compatibility?

Maybe, there's some groundwork to do first.  For instance I still don't
know what happens if you leave the HDMI enabled, but take all the pins
out from under it via the pinmux.  I'll keep this in mind and see what I
can come up with...

-- 
Charles Steinkuehler
char...@steinkuehler.net

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
BeagleBoard group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Re: RFC: Add mode setting to bone-pinmux-helper

2014-09-16 Thread Sungjin Chun

Thank you. I've just changed state of hdmi in
/boot/dtbs/am335x-boneblack.dtb as disabled, however,
which might not be a correct way of disabling HDMI, so I asked.

On Wed, Sep 17, 2014 at 7:57 AM, Charles Steinkuehler 
char...@steinkuehler.net wrote:

 On 9/16/2014 5:43 PM, Sungjin Chun wrote:
  Maybe somewhat off topic, however I cannot help but to ask this;
 
  How can we disable HDMI in kernel version = 3.14? where we do not
  have capemgr?

 Load a different device tree.  There's probably an easier way (there are
 several available device trees already installed), but I would:

 cd /opt/source/dtb-3.14-ti
 vi src/arm/am335x-boneblack.dts

 comment line 62, which loads am335x-boneblack-nxp-hdmi-audio.dtsi

 make
 sudo make install
 sudo reboot

 --
 Charles Steinkuehler
 char...@steinkuehler.net

 --
 For more options, visit http://beagleboard.org/discuss
 ---
 You received this message because you are subscribed to the Google Groups
 BeagleBoard group.
 To unsubscribe from this group and stop receiving emails from it, send an
 email to beagleboard+unsubscr...@googlegroups.com.
 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] uio_pruss in Ubuntu 12.04.

2014-09-16 Thread Alan Federman

How do I insert uio_pruss for ubuntu 12.04?   I am not sure were to get 
this module or if it exists for my kernel.

uname -a
Linux ubuntu-armhf 3.14.4.1-bone-armhf.com #1 SMP Tue Jun 3 12:37:22 UTC 
2014 armv7l armv7l armv7l GNU/Linux


Only pru mention in dtbs am335x-boneblack.dtb

 pruss_ocp_gclk {
#clock-cells = 0x0;
compatible = ti,mux-clock;
clocks = 0x10 0x11;
reg = 0x530;
};

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because 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: Adafruit serial UART library seems to have wrong tty names

2014-09-16 Thread Mike


On 09/16/2014 06:40 AM, c...@isbd.net wrote:

Michel Lavoie lavoie.mic...@gmail.com wrote:

[-- text/plain, encoding quoted-printable, charset: UTF-8, 81 lines --]

I strongly recommend that you read Adafruit's guide regarding the BBB's
device tree overlay. It really help me put this all together:
https://learn.adafruit.com/introduction-to-the-beaglebone-black-device-tree/overview

You will find there why and how to modify your uEnv.txt file in order to
enable ttyO1. In mine, the last line looks like this:

...
optargs=coherent_pool=1M; capemgr.enable_partno=BB-UART1,BB-SPIDEV0

optargs=coherent_pool=1M; capemgr.enable_partno=BB-UART1,BB-SPIDEV0

optargs=coherent_pool=1M; capemgr.enable_partno=BB-UART1,BB-SPIDEV0

optargs=coherent_pool=1M; capemgr.enable_partno=BB-UART1,BB-SPIDEV0



The Adafruit UART IO documentation specifically says that it *does*
export the overlays:-

 The Adafruit IO Python library will export the UART device tree
 overlays as a convenience. There are five serial ports brought to
 the expansion headers (UART3 only has a single direction, TX), and
 one (UART0) with dedicated headers that aren't available to use in
 your Python programs.

... but not all the UARTs work.

In addition the use of the letter O in the device name is just silly! :-)

The devices it creates are called /dev/ttyO1, /dev/ttyO2, etc. with
the letter O.  There's not a mention anywhere that it's a letter
rather than a digit and given the context it's second nature to assume
it's a zero.  Still I did spot that eventually.

Yes, the O and not zero threw me for a loop when I was first setting up 
serial on the BBB.  I have no clue where/why that choice was made.


I haven't looked into the Adafruit library, my hunch here is that to use 
uart5 you will have to disable HDMI as the pins used for that uart are 
in the HDMI group.  As noted above uart3 is TX only, and again those 
pins fall within the HDMI group.


For what it's worth I referenced that info from here.

https://github.com/derekmolloy/boneDeviceTree/blob/master/docs/BeagleboneBlackP8HeaderTable.pdf
https://github.com/derekmolloy/boneDeviceTree/blob/master/docs/BeagleboneBlackP9HeaderTable.pdf

Mike

--
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because 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: Angstrom USB networking Verizon Modem

2014-09-16 Thread edwin . j . slv

What specific information are you looking for from lsusb -vvv? I posted 
it below.  I am still not able to see the network option ppp0 or eth1. 
 I have tried Anstrom Distribution 3.8.13 and Ubuntu 14.04. 




lsusb -vvv

Bus 001 Device 002: ID 1410:b001 Novatel Wireless Ovation MC551
Couldn't open device, some information will be missing
Device Descriptor:
  bLength18
  bDescriptorType 1
  bcdUSB   2.00
  bDeviceClass  239 Miscellaneous Device
  bDeviceSubClass 2 ?
  bDeviceProtocol 1 Interface Association
  bMaxPacketSize064
  idVendor   0x1410 Novatel Wireless
  idProduct  0xb001 Ovation MC551
  bcdDevice0.15
  iManufacturer   4
  iProduct3
  iSerial 5
  bNumConfigurations  1
  Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength  231
bNumInterfaces  6
bConfigurationValue 1
iConfiguration  2
bmAttributes 0xe0
  Self Powered
  Remote Wakeup
MaxPower  500mA
Interface Descriptor:
  bLength 9
  bDescriptorType 4
  bInterfaceNumber0
  bAlternateSetting   0
  bNumEndpoints   3
  bInterfaceClass   255 Vendor Specific Class
  bInterfaceSubClass255 Vendor Specific Subclass
  bInterfaceProtocol255 Vendor Specific Protocol
  iInterface  0
  Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x81  EP 1 IN
bmAttributes3
  Transfer TypeInterrupt
  Synch Type   None
  Usage Type   Data
wMaxPacketSize 0x0040  1x 64 bytes
bInterval   5
  Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x82  EP 2 IN
bmAttributes2
  Transfer TypeBulk
  Synch Type   None
  Usage Type   Data
wMaxPacketSize 0x0200  1x 512 bytes
bInterval  32
  Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x01  EP 1 OUT
bmAttributes2
  Transfer TypeBulk
  Synch Type   None
  Usage Type   Data
wMaxPacketSize 0x0200  1x 512 bytes
bInterval  32
Interface Descriptor:
  bLength 9
  bDescriptorType 4
  bInterfaceNumber1
  bAlternateSetting   0
  bNumEndpoints   2
  bInterfaceClass   255 Vendor Specific Class
  bInterfaceSubClass255 Vendor Specific Subclass
  bInterfaceProtocol255 Vendor Specific Protocol
  iInterface  0
  Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x83  EP 3 IN
bmAttributes2
  Transfer TypeBulk
  Synch Type   None
  Usage Type   Data
wMaxPacketSize 0x0200  1x 512 bytes
bInterval  32
  Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x02  EP 2 OUT
bmAttributes2
  Transfer TypeBulk
  Synch Type   None
  Usage Type   Data
wMaxPacketSize 0x0200  1x 512 bytes
bInterval  32
Interface Descriptor:
  bLength 9
  bDescriptorType 4
  bInterfaceNumber2
  bAlternateSetting   0
  bNumEndpoints   2
  bInterfaceClass   255 Vendor Specific Class
  bInterfaceSubClass255 Vendor Specific Subclass
  bInterfaceProtocol255 Vendor Specific Protocol
  iInterface  0
  Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x84  EP 4 IN
bmAttributes2
  Transfer TypeBulk
  Synch Type   None
  Usage Type   Data
wMaxPacketSize 0x0200  1x 512 bytes
bInterval  32
  Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x03  EP 3 OUT
bmAttributes2
  Transfer TypeBulk
  Synch Type   None
  Usage Type   Data
wMaxPacketSize 0x0200  1x 512 bytes
bInterval  32
Interface Descriptor:
  bLength 9

Re: [beagleboard] Re: RFC: Add mode setting to bone-pinmux-helper

On Tue, Sep 16, 2014 at 7:09 PM, Charles Steinkuehler
char...@steinkuehler.net wrote:
 On 9/16/2014 5:37 PM, Jason Kridner wrote:

 Just going along to state the obvious...

 eMMC and HDMI will be equally interesting tests and more practically
 useful for more capes.

 I'll try and work up a patch set for HDMI, but it won't be until tomorrow.

 It will only be a matter of time before someone damages a board by:
 A) setting an HDMI pin to a output without disabling the HDMI

 The worst that can happen with HDMI is a bus fight (driving an HDMI pin
 without first configuring the BBB side as an input).  The HDMI framer
 does not drive any signals back to the AM335x (other than I2C), so it
 won't cause problems.  If you start playing with pinmux values you could
 easily see wonky video, but that's not a break the hardware kind of
 problem.

Yeah, brainfart.  Agreed, no potential damaging hardware issues.
Anything like an LCD add-on board would just have inputs on those
signals as well.


 B) driving an eMMC pin into conflict without putting the eMMC in reset

 This is much more likely, and while it might not be easy to destroy the
 hardware, it is probably pretty easy to corrupt the eMMC.  It might be
 worth requiring loading an alternate device-tree to disable the eMMC,
 which can make sure it stays in reset.

Getting all of those HDMI pins back for GPIO when not using HDMI w/o
needing to do anything special on boot should make a lot of people
happy, even if the eMMC pins aren't available.


 I don't think there is a simple way for the current pinmux helper to
 check for these conditions, but it wouldn't hurt if any config-pin
 sort of utility would check the state of those hardware control bits
 before helping someone screw things up. :-)

 Agreed!

 Any way you can imagine a way to keep the current uEnv.txt lines to
 disable both of those working without breaking compatibility?

 Maybe, there's some groundwork to do first.  For instance I still don't
 know what happens if you leave the HDMI enabled, but take all the pins
 out from under it via the pinmux.  I'll keep this in mind and see what I
 can come up with...

 --
 Charles Steinkuehler
 char...@steinkuehler.net

 --
 For more options, visit http://beagleboard.org/discuss
 ---
 You received this message because you are subscribed to the Google Groups 
 BeagleBoard group.
 To unsubscribe from this group and stop receiving emails from it, send an 
 email to beagleboard+unsubscr...@googlegroups.com.
 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] PyBBIO v0.9.2 update

2014-09-16 Thread Alexander Hiam



(http://www.alexanderhiam.com/blog/pybbio-update-version-0-9-2/)

A few new features have been added in version 0.9.2:
WebCam library 

The last of the GSoC 2014 additions from rseetham 
https://github.com/rseetham, the WebCam library allows live streaming of 
WebCam video over TCP, as well as capturing of still images to JPG files.
BBIOServer updates 

The included JQuery has been updated to version 1.11.1. Also merged an 
update from Ikario https://github.com/Ikario that adds a range slider 
input element.
I2C improvement 

ycoroneos https://github.com/ycoroneos added new *quickwrite()* and 
*readTransaction()* methods to the I2C objects that allow communicating 
with a wider range of devices.

To update to v0.9.2:
 # pip install --upgrade PyBBIO

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because 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] RFC: Add mode setting to bone-pinmux-helper

On Tue, Sep 16, 2014 at 3:53 PM, Charles Steinkuehler
char...@steinkuehler.net wrote:
 Request For Comment
 ===

 In order to make the cape-universal approach to modifying the BeagleBone
 I/O setup at runtime via user-land (ie: no kernel driver and no
 device-tree overlays or changesets), the bone-pinmux-helper driver needs
 to be in control of the pinmux register for each I/O pin.  It is not
 currently possible, however, to (easily) set the default pinmux mode for
 the bone-pinmux-helper.

 Therefore, I have modified the bone-pinmux-helper code to support a
 mode parameter in the device tree:

 https://github.com/cdsteinkuehler/linux/commit/e0e0f1da3f2df4bc4ee2b27a65ee99734bd3fb77

 ...which allows a device tree fragment to specify the startup default
 mode of the pinmux from one of the available choices:

Nice work, i like this!  I'll cherry-pick it tomorrow and also start
the conversion ttOx/i2c/spi..

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 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: RFC: Add mode setting to bone-pinmux-helper

On Tue, Sep 16, 2014 at 4:55 PM, Joshua Datko jbda...@gmail.com wrote:


 Jason Kridner jkridner-hcmAuCOw+vXj4SYmN/t...@public.gmane.org writes:


 https://github.com/cdsteinkuehler/beaglebone-universal-io/commit/e742ff15f7abbc2cf80141ea49269eb0a2f2a8b3

 Approach looks good to me. I know the dropping of the pin assignment
 in the i2c device tree itself will cause some heartache for some.

 I don't see where you removed the definition of the i2c pin settings
 themselves. Will not removing those entries cause headaches by someone
 assuming they are used or is it comfortable for them to simply be
 there by reference? I suspect it would only be an issue if a bug was
 found in the setting and someone missed that the real mode was coming
 from the helper.


 I've been trying to follow along with these changes and I admit, I
 haven't been able to keep up.

 Some questions:

 1. My Cape DTS does not explicitly call out for i2c2 [1], with this
 change does that, and all capes using i2c2, need to be fixed?

 2. Is the default mode of pins P_19/20, once user space is reached, GPIO
 or i2c2?

Hi Josh,

I'm going to make sure we do it both ways. The default
am335x-boneblack.dtb (device.dtb) will have every peripheral
enabled and it'll be up to Charles's userspace tool (and a cape
database file that we need to write, (it'll probably be bone-script))
to correctly setup the pinmux's for your cape.

But i'll also have a backup: device-cape.dtb, that'll just be the
minimal needed for your cape. Which the end user could enable other
stuff just like in this base dts:

https://github.com/RobertCNelson/dtb-rebuilder/blob/3.14-ti/src/arm/am335x-bone-crypto-00a0.dts

One of the big unknowns i have... How will the fat
am335x-boneblack.dtb compare with a device-cape.dtb power wise.
Switching i2c/spi/usart/gpio worked well with the 3.8 cape-universal.
The big one is getting the hdmi/drm stack to seamlessly work with this
setup.

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 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] Kernel vs rootfs dependencies, general guidence, newbie

On Tue, Sep 16, 2014 at 6:01 PM, pthor preben.tho...@gmail.com wrote:
 Hi guys,

 I'm just about to start up my second try at learning more embedded linux,
 and got myself a BBB. I'm somewhat unexperienced with embedded linux, but
 have done some stuff (and reading) earlier: building kernels, applied some
 patches, building Qt, tslib, gstreamer for angstrom. But I have some doubts
 now and hope that you may help me with some guidence with a few specific and
 some more general questions.

 My longterm goals is to set up a system where I can run newest Qt, support
 for display, audio and be able to play with driver and application
 development.

 Where I am:
 - I've done some research lately and it seems like I want a newer kernel
 (3.14 for example) with SGX fixes, (for Qt 5)
 - The only graphical application I want to run is my own custom one, so I
 feel that non GUI Angstrom distro fits better than the supplied Debian
 distro. But I'm a little clueless regarding the roofs.
 - Earlier I have relied on the distro provided with a development board, now
 I want better control and understanding.

 Is there any dependencies between the beaglebone 3.14 kernel and rootfs?
 Is it supposed to run with Debian rootfs only?

Really any current rootfs that can at-least run 2.6.32, will boot
fine with this 3.14.  The kernel config already includes all the
dependices for systemd by default. (I do need to re-add the Android
configs).  So, really, it should just work, if it doesn't just ping
this list and we will get that missing config enabled.

 Can use the Angstrom build tool(or other method) to build a Angstrom rootfs
 and use the beaglebone 3.14 kernel out of the box?
 Is there any version dependencies in the rootfs that I need to worry about?
 Is there any benefit to look into yocto for me? It seems a bit overwhelming
 for me, at least now.

 (With beaglebone 3.14 kernel i mean the kernel discussed in: BeagleBone
 Black switching to 3.14 kernel )

 I dont understand all the details yet, but is all the beaglebone specific
 driver/cape/dts stuff provided with the kernel? Or is there some BSP stuff I
 need to provide in the rootfs? BSP is per definition a part of the kernel?

Any tool not found in a current distro, can be found at:

https://github.com/beagleboard/

 I have some books on device drivers and embedded linux from 2.6 kernel era.
 Is these books still relevant with 3.x kernels? Do you have some keywords
 regarding important topics that have changed? I guess Device tree is one.

Device Tree should be in the books from 2.6 kernel, back then it was
mostly a powerpc thing. It wasn't till late in the 2.6.xx/ early 3.x
series did device tree's become bootable and till 3.10.x when it
became very* useful. (* multarch became useful, imx+omap same
kernel)

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 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: Why did my BB die ?

2014-09-16 Thread Andrew Daviel



Thanks everyone for the replies.

On Thu, 4 Sep 2014, ja...@acs4design.com wrote:


 1. The voltage sequencing mentioned by Gerald is big and is probably the real 
failure mode.  In this design, the AIN pins will see voltage
long before the CPU/PMIC (Power Management IC) is up and running.  
Basically, when a voltage is applied to the analog pins (or any IO
pins for that matter) before the IO rail is up, the chip tries to power 
itself through the pin clamping diodes and can really cause havoc
on the silicon. The chip just wasn't made to be powered this way.
 2. Did you check that the 1Ohm resistor didn't blow or that the voltage across 
it didn't exceed the limit for the ADC inputs?  If it does
fail open for some reason, the voltage would far exceed the max voltage on 
the Analog pins.  Might want to add some protection there in
case that resistor ever does blow, or the voltage across it exceeds the max 
analog voltage.
 3. Also note that the 1Ohm resistor isn't just powering the BBB, it's charging 
the battery!  Chances are the solar panel was putting too
much juice into the battery and caused the 1Ohm resistor to have a much 
larger voltage across it.
 4. You might move the 1Ohm resistor to the ground leg between the battery and 
the solar panel, instead of between the solar panel and the
battery.


This is a 4W panel, and a fairly hefty 1ohm resistor - 5W or something. It 
can't have blown.

Mmph, I think I've been stupid. The way I originally drew the circuit, it 
looked like AIN1 would be at +200mV, but now I think it would be at 
-200mV. I didn't have any more 150K in my box and thought I could put the 
resistor in the ground leg instead of the +ve leg.


With the ground connection to the battery loose, AIN5 could have been 
overpowered at about 3V, but limited to less than 200uA by the 150K 
resistor, while AIN1 had no current limit.


I'd have expected a problem on an AIN pin to have just blown that input, 
rather than the whole board, though.



Andrew

--
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because 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: RFC: Add mode setting to bone-pinmux-helper

On 9/16/2014 8:53 PM, Robert Nelson wrote:
 
 One of the big unknowns i have... How will the fat
 am335x-boneblack.dtb compare with a device-cape.dtb power wise.
 Switching i2c/spi/usart/gpio worked well with the 3.8 cape-universal.
 The big one is getting the hdmi/drm stack to seamlessly work with this
 setup.

Is there any chance working HDMI support can be compiled as a loadable
module?  When I was experimenting with trying to get sgx support
working, it seemed like there were circular dependencies that prevented
this.

-- 
Charles Steinkuehler
char...@steinkuehler.net

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
BeagleBoard group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Re: RFC: Add mode setting to bone-pinmux-helper

On Tue, Sep 16, 2014 at 9:17 PM, Charles Steinkuehler
char...@steinkuehler.net wrote:
 On 9/16/2014 8:53 PM, Robert Nelson wrote:

 One of the big unknowns i have... How will the fat
 am335x-boneblack.dtb compare with a device-cape.dtb power wise.
 Switching i2c/spi/usart/gpio worked well with the 3.8 cape-universal.
 The big one is getting the hdmi/drm stack to seamlessly work with this
 setup.

 Is there any chance working HDMI support can be compiled as a loadable
 module?  When I was experimenting with trying to get sgx support
 working, it seemed like there were circular dependencies that prevented
 this.

Sure, we can move those to modules:

I'll set them up exactly like ti has them by default in 3.14. ;)

CONFIG_BACKLIGHT_PWM=m
CONFIG_DRM=m
CONFIG_DRM_KMS_HELPER=m
CONFIG_DRM_KMS_FB_HELPER=y
CONFIG_DRM_GEM_CMA_HELPER=y
CONFIG_DRM_KMS_CMA_HELPER=y
CONFIG_DRM_I2C_NXP_TDA998X=m
CONFIG_DRM_TILCDC=m

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 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: Installing Kali Linux (Arm) onto BeagleBone Black Rev C

2014-09-16 Thread Don deJuan

On 09/16/2014 02:19 PM, vermins...@gmail.com wrote:
 http://www.offensive-security.com/kali-linux-vmware-arm-image-download/



 On Tuesday, September 16, 2014 12:47:59 PM UTC-7, macuber...@gmail.com
 wrote:

 Would anyone know of a set of instructions on how to install Kali
 to the BeagleBone Black Rev 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
 mailto:beagleboard+unsubscr...@googlegroups.com.
 For more options, visit https://groups.google.com/d/optout.

They also state it does not have great performance on BBB. Try out
ArchAssault, way more customizable and lightweight. Its exactly the
pwnbox you desire the only bloat that is there is what you put on it.

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
BeagleBoard group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Re: Installing Kali Linux (Arm) onto BeagleBone Black Rev C

Don't miss The Deck either.

On Tue, Sep 16, 2014 at 10:36 PM, Don deJuan donjuans...@gmail.com wrote:
 On 09/16/2014 02:19 PM, vermins...@gmail.com wrote:

 http://www.offensive-security.com/kali-linux-vmware-arm-image-download/



 On Tuesday, September 16, 2014 12:47:59 PM UTC-7, macuber...@gmail.com
 wrote:

 Would anyone know of a set of instructions on how to install Kali to the
 BeagleBone Black Rev 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.


 They also state it does not have great performance on BBB. Try out
 ArchAssault, way more customizable and lightweight. Its exactly the pwnbox
 you desire the only bloat that is there is what you put on it.

 --
 For more options, visit http://beagleboard.org/discuss
 ---
 You received this message because you are subscribed to the Google Groups
 BeagleBoard group.
 To unsubscribe from this group and stop receiving emails from it, send an
 email to beagleboard+unsubscr...@googlegroups.com.
 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] Re: RFC: Add mode setting to bone-pinmux-helper