date:20140731

The error message is probably misleading, I had it several times until I 
realized that the native binary was not properly compiled for the am335x. 
The file was indeed there at the location but it just would not load. The 
problem can probably be solved by compiling the native binary for am335x.

The PureJavaComm documentation sais that - if you want to support other 
platforms, you have to create a custom JTermios Wrapper for the ARM 
platform. There's a section for it ('Adding more platforms') on the 
website. Makre sure you build your libraries for arm with soft 
floatingpoints.
http://www.sparetimelabs.com/purejavacomm/purejavacomm.php

Many APIs package the native binary inside their java jar and upon program 
execution unzip it to a temp folder. That is a quite common practice, but I 
found it to be error prone.

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to 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 Rev C: Debian: PureJavaComm/JNA test fails

Uhm, to correct myself: It's probably not even necessary to implement the 
Java part of JTermios, the wrapper. Just make sure you build the native 
binary for arm with softfp. I suspect that the one you use has been built 
for i386.

You can use the linaro toolchain to crosscompile it on windows or compile 
it directly on the bone.

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to 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: RIP Never Used BBB

2014-07-31 Thread sa_Penguin

I must admit, I have often wondered if anyone will create a mains-powered 
supply with +5V and +3.3V output.
Designers would still need the occasional 2.4 and 1.8V regulators but overall 
design should be simpler.

Board costs less, supply costs more - may include features like shutdown under 
software (shutdown -h now)
Could be used with other dev boards : Arduino, Pi, etc.
Add a HDD compatible connector for future expansion, or the Cubieboard which 
already has SATA.

Would you buy such a dev board / supply combination?

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

2014-07-31 Thread docasio63

I need to disable the serial console or at least move it to a different 
serial port . 
I need to use the first uart. 
I have replaced the angstrom distro with Ubuntu and I boot off the sd card 
as opposed to the MMC.

my distro is
ubuntu-saucy-13.10-armhf-3.8.13-bone30 both on the mmc and the sd card.

can anyone assist me on how to do that

I'ved googled a lot of stuff but none seems to work

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to 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: RIP Never Used BBB

2014-07-31 Thread David Funk

They are called PC power supplies . . . :-)




-david




On Thu, Jul 31, 2014 at 9:15 AM, sa_Penguin soupi...@gmail.com wrote:

 I must admit, I have often wondered if anyone will create a mains-powered
 supply with +5V and +3.3V output.
 Designers would still need the occasional 2.4 and 1.8V regulators but
 overall design should be simpler.

 Board costs less, supply costs more - may include features like shutdown
 under software (shutdown -h now)
 Could be used with other dev boards : Arduino, Pi, etc.
 Add a HDD compatible connector for future expansion, or the Cubieboard
 which already has SATA.

 Would you buy such a dev board / supply combination?

 --
 For more options, visit http://beagleboard.org/discuss
 ---
 You received this message because you are subscribed to 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] BBB Rev C: Debian: PureJavaComm/JNA test fails

So what is the point of using Java if binaries like this do not work cross
platform ?


On Thu, Jul 31, 2014 at 7:12 AM, Datenheld datenh...@gmail.com wrote:

 Uhm, to correct myself: It's probably not even necessary to implement the
 Java part of JTermios, the wrapper. Just make sure you build the native
 binary for arm with softfp. I suspect that the one you use has been built
 for i386.

 You can use the linaro toolchain to crosscompile it on windows or compile
 it directly on the bone.

 --
 For more options, visit http://beagleboard.org/discuss
 ---
 You received this message because you are subscribed to 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] Cannot boot from microsd

http://eewiki.net/display/linuxonarm/BeagleBone+Black


On Thu, Jul 31, 2014 at 2:01 AM, Mario Giammarco mgiamma...@gmail.com
wrote:

 Thanks for reply but how can I update u-boot on the emmc? Reading
 documentation it seems that I must boot from an sd to update emmc and so I
 cannot...

 Il giorno mercoledì 30 luglio 2014 19:28:26 UTC+2, john3909 ha scritto:


 From: Mario Giammarco mgiam...@gmail.com
 Reply-To: beagl...@googlegroups.com beagl...@googlegroups.com
 Date: Wednesday, July 30, 2014 at 10:02 AM
 To: beagl...@googlegroups.com beagl...@googlegroups.com
 Subject: [beagleboard] Cannot boot from microsd

 Hello,
 I am trying to boot from microsd.

 1) I have prepared an 8gb sdhc, tried with asterisk image and with debian
 image from beagleboard site
 2) I have checked that sd contains boot images
 3) I have attached beagleboard power cable keeping user/boot button
 pressed

 It boots always internal angstrom image

 What can I do? How can I debug?

 Update u-boot on the eMMC

 Regards,
 John



 Thanks,
 Mario

 --
 For more options, visit http://beagleboard.org/discuss
 ---
 You received this message because you 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 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 Rev C: Debian: PureJavaComm/JNA test fails

Maybe you are very proficient in java and many of its libraries. It has got 
some really nice features. I never cared about the platform indepence that 
much. Many, many people worldwise use it and are proficient in it and there 
are lots of libraries available.

Am Donnerstag, 31. Juli 2014 17:28:00 UTC+2 schrieb William Hermans:

 So what is the point of using Java if binaries like this do not work cross 
 platform ?


 On Thu, Jul 31, 2014 at 7:12 AM, Datenheld date...@gmail.com 
 javascript: wrote:

 Uhm, to correct myself: It's probably not even necessary to implement the 
 Java part of JTermios, the wrapper. Just make sure you build the native 
 binary for arm with softfp. I suspect that the one you use has been built 
 for i386.

 You can use the linaro toolchain to crosscompile it on windows or compile 
 it directly on the bone.

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




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

Re: [beagleboard] Using GPIO

2014-07-31 Thread maxmike

I'm setting up cape-universal on a production machine - minor item,
but I noticed the syntax *in+* works whereas the equivalent *in_pu* does 
not.

On Saturday, May 3, 2014 3:01:51 PM UTC-7, Charles Steinkuehler wrote:

 You beat me to the answer...use the config-pin utility!  :) 

 Let me know if you run into any problems.  I haven't tested every 
 combination of features and there was a lot of cut-and-paste, so there 
 could be some bugs. 

 On 5/3/2014 1:59 AM, Hannes Hörting wrote: 
  Sorry. You already answered: 
  
  Once loaded, all pins default to inputs with their power-on reset 
  default pull up/down settings.  To change the pin functions, use the 
  config-pin utility: 
  config-pin p9.24 uart 
  config-pin p9.25 high 
  Just type config-pin (with no options) to get usage info. 

 -- 
 Charles Steinkuehler 
 cha...@steinkuehler.net javascript: 


-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to 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 Rev C: Debian: PureJavaComm/JNA test fails

Datenheld, My point was why use a language, when if key feature is taken
away . . . also it is not very proficient especially considering you've
spent how many days here trying to troubleshoot an issue that should never
have existed ? People who write libraries that brake key features in
languages such as this should be shot.

I could go on all day, but THIS is one reason why Java is a horrible
language.  People are taught to write sloppy / crappy code like this, and
told  that it's fine / good. It's not fine, when you break a key feature in
a language.

Anyway, do not take the above personally. but please do try to expand your
horizons some.


On Thu, Jul 31, 2014 at 8:39 AM, Datenheld datenh...@gmail.com wrote:

 Maybe you are very proficient in java and many of its libraries. It has
 got some really nice features. I never cared about the platform indepence
 that much. Many, many people worldwise use it and are proficient in it and
 there are lots of libraries available.

 Am Donnerstag, 31. Juli 2014 17:28:00 UTC+2 schrieb William Hermans:

 So what is the point of using Java if binaries like this do not work
 cross platform ?


 On Thu, Jul 31, 2014 at 7:12 AM, Datenheld date...@gmail.com wrote:

 Uhm, to correct myself: It's probably not even necessary to implement
 the Java part of JTermios, the wrapper. Just make sure you build the native
 binary for arm with softfp. I suspect that the one you use has been built
 for i386.

 You can use the linaro toolchain to crosscompile it on windows or
 compile it directly on the bone.

 --
 For more options, visit http://beagleboard.org/discuss
 ---
 You received this message because you 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 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 Rev C: Debian: PureJavaComm/JNA test fails

You're being too harsh on the topic. Most people didn't really use java 
because of platform independence. In the beginnings of Java, applets were 
the killer feature. You could easily deliver fat client software with the 
webbrowser. It wasn't that much about platform independence. Java is a lot 
more than platform independence.

Platform independence hast its limits by design. When you want to be 
independent of something, you need abstractions. Abstractions are leaky, 
though. When you then want to do something, which is not common to all(!) 
platforms you support, then you cannot generalize it. Or you make it 
possible but then you depend  upon the details of the platform. Those 
details are for example the native library that PureJavaComm delivers.

also it is not very proficient especially considering you've spent how 
many days here trying to troubleshoot an issue that should never have 
existed

Well, I'm arguing against that by saying, that you will potentially have 
the same problem in every language that uses a runtime and does not compile 
to native code.

I could go on all day, but THIS is one reason why Java is a horrible 
language.  People are taught to write sloppy / crappy code like this, and 
told  that it's fine / good. It's not fine, when you break a key feature in 
a language.

Why is it a key feature to communicate with low level peripherals? Once you 
go beneath a leaky abstraction (and every abstraction is leaky), you will 
have tight dependencies. You cannot say the code is crappy. The things you 
want to do are simply not possible without writing native code. When you 
choose to write such code in Java, it is by design and not necessarily 
crappy. It's all about the API for Java.

I could take a native i386 lib with a python API, pull it over to arm and 
then complain that it does not work as well. This is basically what you are 
doing currently, no offense meant.

Anyway, do not take the above personally. but please do try to expand your 
horizons some.  

Well, personally, I am proficient in quite a lot languages. So I feel like 
I can judge languages quite well. Java has its flaws, but as a language, it 
is quite decent. You can write bad code in any language and Java code is 
not necessarily bad code, just because it breaks platform independence 
(reasoning: see above). I like Java because it's object oriented and does 
not need extensive resource managing like C++. I can handle complexity with 
it much better, than in C. And since I use it at work, I am getting results 
very fast.

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to 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] best kernel version for bbb

2014-07-31 Thread David Lambert


Robert,
I seem to have an issue with my 
am335x-boneblack-cape-bone-argus.dts in 3.16.0-rc7-bone1. This time it 
appears that there is a clash with the Ethernet subsystem. Has something 
changed in this area from 3.15?


Regards,

Dave.


On 07/16/2014 08:13 AM, David Lambert wrote:

Thanks Robert. That works fine!

Regards,
Dave.

On 07/15/2014 07:04 PM, Robert Nelson wrote:

On Tue, Jul 15, 2014 at 6:52 PM, David Lambert d...@lambsys.com wrote:

On 07/15/2014 04:40 PM, Robert Nelson wrote:
On Tue, Jul 15, 2014 at 4:35 PM, David Lambert d...@lambsys.com 
wrote:
Thanks so much Robert - I think you nailed it! Unfortunately I did 
not
inherit this change as I could not import am335x-bone-common.dtsi 
due to

the
clash:

/*pinctrl-0 = clkout2_pin; clash with argus-ups */

I'll clean that up in a bit and push it.. I have another patch from
John for audio too, so i'll get a new bone tag released this evening..

Regards,


Also I found this one.
/*pinctrl-0 = ecap0_pin_p9_42;  clash with Argus */
Here's what i came up for the v3.15.x branch. This should make usb 
work now..


https://github.com/RobertCNelson/bb-kernel/commit/e34510a7b5c6712386590818ba84e8ea8752f7f0 



Not sure of the best way to handle these sort of situations. 
Currently I am
just copying then editing the contents of am335x-bone-common.dtsi 
into my

dts. This is obviously a very messy hack. Maybe am335x-bone-common.dtsi
could be subdivided into smaller chunks

Yeah, it needs to be cleaned up badly.. It's only getting worse with
more patches on linux-omap.. We just need a weekend, few kegs and do a
cleanup..

1: am335x-bone-common.dtsi (only common stuff and all pinmux's)
2: am335x-boneblack-common.dtsi (no eMMC/HDMI/HDMI Audio)
3: am335x-boneblack-eMMC.dtsi
4: am335x-boneblack-HDMI.dtsi
5: am335x-boneblack-HDMIA.dtsi

am335x-bone.dtb = (1)
am335x-boneblack.dtb = (1+2+3+4+5)

Then it should be easy to expand on am335x-boneblack-common.dtsi and
enable your cape.

Regards,





--
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups BeagleBoard group.

To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] unable to boot Beaglebone Black from NFS

From:  Giles Godart-Brown ggodartbr...@gmail.com
Reply-To:  beagleboard@googlegroups.com beagleboard@googlegroups.com
Date:  Thursday, July 31, 2014 at 1:41 AM
To:  beagleboard@googlegroups.com beagleboard@googlegroups.com
Subject:  Re: [beagleboard] unable to boot Beaglebone Black from NFS

 HURRAH it now works, thanks to all your help and no need to make a new kernel
 or uboot!  

 Here is how its done at a high level, I will be writing it up in more detail
 on the Misterhouse on Beglebone instructions
 http://misterhouse.wikispaces.com/BeagleBoneBlack .

 1) Flash an SD card with the standard (non eMMC flashing) Debian image from
 here http://beagleboard.org/latest-images
 2) Set up an NFS share on your NAS/PC/whatever
 3) Boot your Bone with the SD Card
 4) Set the Bone to have a static IP address by editing /etc/netwotk/interfaces
 reboot and check it works
 4) NFS mount the shared drive from the Bone ( e.g. mount -o nfsvers=3
 192.168.10.118:/home/bone /mnt/nfs)
 5) sudo to root on the Bone and do all the rest of the Bone stuff as root
 6) copy everything to the NFS drive.  The second step seems unnecessary, but
 its quick compared with the first
cp -axv /. /mnt/nfs/.
cp -axv /dev/. /mnt/nfs/dev/.
 7)  edit the /mnt/nfs/etc/fstab to add
/dev/nfs / nfs defaults 0 0
 and comment out the other root partition,
 8) Edit your  /boot/uboot/uEnv.txt add the following lines - changed  to match
 your configuration
 serverip=192.168.10.118
 ipaddr=192.168.10.47
 hostname=MH_bbb
 netmask=255.255.255.0
 gateway=192.168.10.1
 nfsdevice=eth0:off
 nfsopts=vers=3
 rootpath=/home/bone/rootfs
 comment out the line that starts mmcargs as follows;
 #mmcargs=setenv bootargs
 add a new netargs line - note all on one line, not broken as here
 netargs=setenv bootargs console=${console} ${optargs} root=/dev/nfs
 nfsroot=${serverip}:${rootpath}
 ip=${ipaddr}:${serverip}:${gateway}:${netmask}:${hostname}:${nfsdevice}
 and finally replace the uenvcmd with this;
 uenvcmd=run loadfiles; run netargs; bootz ${loadaddr}
 ${initrd_addr}:${initrd_size} ${fdtaddr}

 Reboot and you should be able to ssh into your Bone, hear your disk drive
 whizzing and see your extra disk space with a df.
 For completeness I've attached my uEnv.txt
As I said in my previous e-mail, all this above is unnecessary if you are
using the latest u-boot. All you need is the 5 lines I showed below. As long
as you define client_ip, the default u-boot env will use NFS. No need for
uenvcmd, etc. Robert made NFS booting really simple:

http://elinux.org/Beagleboard:U-boot_partitioning_layout_2.0#nfs_support

Regards,
John

 Thanks again
 Giles

 On Wednesday, 30 July 2014 17:43:50 UTC+1, john3909  wrote:

 From:  Giles Godart-Brown ggodar...@gmail.com javascript: 
 Reply-To:  beagl...@googlegroups.com javascript: 
 beagl...@googlegroups.com javascript: 
 Date:  Wednesday, July 30, 2014 at 12:24 AM
 To:  beagl...@googlegroups.com javascript:  beagl...@googlegroups.com
 javascript: 
 Subject:  Re: [beagleboard] unable to boot Beaglebone Black from NFS

 Thanks for your help, but sadly, on this version a uEnv.txt just containing;
 console=ttyO0,115200n8
 client_ip=192.168.10.47
 server_ip=192.168.10.118
 gw_ip=192.168.10.1
 root_dir=/home/bone/bbb_nfs_root

 does not work, it doesn't even fire up the ethernet port (no activity
 lights), I'm guessing because there is no eth0 defined and its perhaps
 trying to fire up the USB network or something.
 Make sure you are using the latest version of u-boot. I¹m using

 U-Boot 2014.07-00014-gdc7e38e

 This is the v2014.07 with Robert Nelsons u-boot patch

 https://github.com/RobertCNelson/Bootloader-Builder/blob/master/patches/v2014
 .07/0001-am335x_evm-uEnv.txt-bootz-n-fixes.patch

 Or follow the instructions here:

 http://eewiki.net/display/linuxonarm/BeagleBone+Black#BeagleBoneBlack-Bootloa
 der:U-Boot

 Regards,
 John

 I'll try the rsync method once I can ping the beaglebone

 G

 On Wednesday, 30 July 2014 03:05:41 UTC+1, john3909  wrote:

 From:  Giles Godart-Brown ggodar...@gmail.com
 Reply-To:  beagl...@googlegroups.com beagl...@googlegroups.com
 Date:  Tuesday, July 29, 2014 at 2:26 PM
 To:  beagl...@googlegroups.com beagl...@googlegroups.com
 Subject:  [beagleboard] unable to boot Beaglebone Black from NFS

 I've seen many posts about how to boot a Beaglebone black via an NFS
 mounted root partition, but none seem to work with the latest version.
 I started by creating an NFS mount on my Ubuntu PC and successfully
 mounting it from the Beaglebone when booted from an SD image of the latest
 version dated 2013.06.20
 https://s3.amazonaws.com/angstrom/demo/beaglebone/Angstrom-Cloud9-IDE-GNO
 ME-eglibc-ipk-v2012.12-beaglebone-2013.06.20.img.xz  from the Beaglebone
 site. All the commands below were done as root.;
 uname -a
 Linux beaglebone 3.8.13-bone50 
 Then test the mount with;
 mount -o nfsvers=3 192.168.10.118:/home/bone /mnt/nfs
 Next I copied the entire filesystem to the nfs

[beagleboard] Re: RTC on BBB stop working after opkg upgrade

2014-07-31 Thread ivan . deftones13

Hi Fernando, 

Im having the same problem as you had after the update, but I'm using the 
BBB Rev C under Debian, and it does not get the time from the RTC during 
boot, but it does if I perform the commands (mentioned in the tutorial) 
manually:

hwclock -s -f /dev/rtc1
hwclock -w

So I'd like to ask you what did you do about the /etc/localtime to make it 
work, or how does this impact the RTC ?

Besides, I see in your bash script *clock_init.sh*, you are using:


   1. *echo ds1307 0x68  /sys/class/i2c-adapter/i2c-0/new_device*
   2. *hwclock -s -f /dev/rtc0*
   3. *hwclock -w*


and as far as I know this is the BBB built-in RTC's path (not battery 
backened) so I wonder how is this working on your BBB ?

The Adafruit Tutorial is made for a RTC Battery Backened registered under 
/dev/rtc1, as follows:

echo ds1307 0x68  /sys/class/i2c-adapter/i2c-1/new_device
hwclock -s -f /dev/rtc1
hwclock -w

Any suggestion, comment, idea is welcome

Thanks

Regards


On Monday, February 24, 2014 12:24:00 PM UTC-6, Fernando Derkoski wrote:

 Yeah noob here, My /etc/localtime was not correct. Now the whole thing 
 work just fine.

 On Monday, February 24, 2014 1:45:18 PM UTC-3, Fernando Derkoski wrote:

 I tried *echo ds1307 0x68  /sys/class/i2c-adapter/i2c-0/new_device*

 and now is working, sort of, because the time it is not being set on 
 restart.
 here is my bash script:

 /usr/share/rtc_ds1307/clock_init.sh


1. *echo ds1307 0x68  /sys/class/i2c-adapter/i2c-0/new_device*
2. *hwclock -s -f /dev/rtc0*
3. *hwclock -w*


 And here is my service:

 /lib/systemd/system/rtc-ds1307.service


1. *[Unit]*
2. *Description=DS1307 RTC Service*
3.  
4. *[Service]*
5. *Type=simple*
6. *WorkingDirectory=/usr/share/rtc_ds1307*
7. *ExecStart=/bin/bash clock_init.sh*
8. *SyslogIdentifier=rtc_ds1307*
9.  
10. *[Install]*
11. *WantedBy=multi-user.target*


 My service is running on the restart, but if I run 
 dmesg | grep ds1307 I get:
 *[5.934660] rtc-ds1307: probe of 0-0068 failed with error -5*
 *[5.970362] i2c i2c-0: new_device: Instantiated device ds1307 at 0x68*


 On Monday, February 24, 2014 9:58:23 AM UTC-3, Fernando Derkoski wrote:

 Hello,

 Before the upgrade I was testing the RTC and it was normal, but after I 
 runned the okpg upgrade this happens:

 *root@beaglebone:~# i2cdetect -y -r 1*
 *] 0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f*
 *00:  -- -- -- -- -- -- -- -- -- -- -- -- --*
 *10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --*
 *20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --*
 *30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --*
 *40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --*
 *50: -- -- -- -- UU UU UU UU -- -- -- -- -- -- -- --*
 *60: -- -- -- -- -- -- -- -- 68 -- -- -- -- -- -- --*
 *70: -- -- -- -- -- -- -- --*
 *root@beaglebone:~# echo ds1307 0x68  
 /sys/class/i2c-adapter/i2c-1/new_device*
 *-sh: echo: write error: Invalid argument*
 *root@beaglebone:~#*

 I was doing this tutorial: 

 http://learn.adafruit.com/adding-a-real-time-clock-to-beaglebone-black/set-rtc-time

 Anyone could help me?



-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to 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: not flashing the eMMC (not blinking 4 user leds) problem

2014-07-31 Thread Jacob Travis

False alarm.  Now mine starts but I don't think it's starting the flash
procedure.  So the above problem was fixed but now I have a different issue.


On Wed, Jul 30, 2014 at 3:28 PM, Jacob Travis nerevarja...@gmail.com
wrote:

 Ok, so my problem was I didn't specify the bs=1m on my copy command.
 There is a typo in the first link, it should be bs=1M.  Stupid problem but
 it's working now.


 On Wed, Jul 30, 2014 at 1:21 PM, nerevarja...@gmail.com wrote:

 I'm having the same problem.  I'm putting the latest angstrom onto an ssd
 card following the instructions provided in the links below.  I formatted
 the SD card to fat32, labeled it BBB_ANSTROM, used dd to copy the image
 (after running unxz on it), put the sd card in, held the user button, apply
 power, no LEDs light up.


 https://learn.adafruit.com/downloads/pdf/beaglebone-black-installing-operating-systems.pdf

 https://learn.adafruit.com/beaglebone-black-installing-operating-systems/flashing-the-beaglebone-black

 On Tuesday, April 15, 2014 2:22:48 AM UTC-4, chirag panchal wrote:

 Hello,
   I download the Android image file for BBB from link:
 http://icculus.org/~hendersa/BBB_JB_Android_3_8_13.img.bz2
   then by using *win32disk imager*, I write that image file
 into my microSDcard.
   then I put microSD card into microSDcard slot of Beagle Bone
 Black. and *press the boot button*, then* still holding that boot
 button, I apply power supply*.
   But *No user LEDs are blinking*. so many times I have done
 this procedure for a long time. But nothing happend with LED.

 *Anybody can please help me*
 *Thanks in advance.*

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




 --
 Jacob Travis
 nerevarja...@gmail.com
 Electrical Engineering student
 University of Kentucky




-- 
Jacob Travis
nerevarja...@gmail.com
Electrical Engineering student
University of Kentucky

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to 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] Cannot boot from microsd


From:  Mario Giammarco mgiamma...@gmail.com
Reply-To:  beagleboard@googlegroups.com beagleboard@googlegroups.com
Date:  Thursday, July 31, 2014 at 2:01 AM
To:  beagleboard@googlegroups.com beagleboard@googlegroups.com
Subject:  Re: [beagleboard] Cannot boot from microsd

 Thanks for reply but how can I update u-boot on the emmc? Reading
 documentation it seems that I must boot from an sd to update emmc and so I
 cannot...
When you press the boot button as you power the board the BBB will use
u-boot from the SDCard. You can update u-boot on the eMMC by using a SDCard
with the flash image (replaces everything on the eMMC) or you can boot with
the SDCard, mount the eMMC boot partition and replace the u-boot with a
simple cp command. 

Regards,
John
 
 
 Il giorno mercoledì 30 luglio 2014 19:28:26 UTC+2, john3909 ha scritto:
 
 From:  Mario Giammarco mgiam...@gmail.com javascript: 
 Reply-To:  beagl...@googlegroups.com javascript: 
 beagl...@googlegroups.com javascript: 
 Date:  Wednesday, July 30, 2014 at 10:02 AM
 To:  beagl...@googlegroups.com javascript:  beagl...@googlegroups.com
 javascript: 
 Subject:  [beagleboard] Cannot boot from microsd
 
 Hello,
 I am trying to boot from microsd.
 
 1) I have prepared an 8gb sdhc, tried with asterisk image and with debian
 image from beagleboard site
 2) I have checked that sd contains boot images
 3) I have attached beagleboard power cable keeping user/boot button pressed
 
 It boots always internal angstrom image
 
 What can I do? How can I debug?
 Update u-boot on the eMMC
 
 Regards,
 John
 
 
 Thanks,
 Mario
 
 -- 
 For more options, visit http://beagleboard.org/discuss
 --- 
 You received this message because you are subscribed to the Google Groups
 BeagleBoard group.
 To unsubscribe from this group and stop receiving emails from it, send an
 email to beagleboard...@googlegroups.com javascript: .
 For more options, visit https://groups.google.com/d/optout.
 
 -- 
 For more options, visit http://beagleboard.org/discuss
 --- 
 You received this message because you are subscribed to the Google Groups
 BeagleBoard group.
 To unsubscribe from this group and stop receiving emails from it, send an
 email to beagleboard+unsubscr...@googlegroups.com.
 For more options, visit https://groups.google.com/d/optout.


-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to 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: Maximum current on GPIO?

2014-07-31 Thread Brandon I

Serge, I was talking about the pin driver circuit inside the package
(something like this http://i.stack.imgur.com/f3Dz6.png) not an external
connection to 3.3V or ground, but I totally agree for external connections.
Always make sure the current in and out of the pin, in any oops type
configuration, will be limited to what the pin can handle.




On Wed, Jul 30, 2014 at 10:37 PM, serge.ns...@gmail.com wrote:



 On Thursday, July 31, 2014 12:39:42 AM UTC+6, Brandon I wrote:

 The gpio are push pull/pseudo open drain, so there's a transistor/switch
 going from 3.3V to the pin,...


 At boot time the respective Sitara pins become outputs high/low level as
 needed.
 Then, please never assume your GPIO is tri-state.


 In theory you may connect 3.3v power line direct to the pin if:
 1) you are sure it is not used at boot time as the output
 2) it is 3.3v domain power related pin.

 Feel free to ground the pin if:
 1) you are sure it is never used at boot time as an output, and you never
 drive it High.


 To live safe and feel happy always add pulling resistors, never connect
 pin to the VCC or GND dorectly.

 --
 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/cWGCEtg9syY/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] unable to boot Beaglebone Black from NFS

Who wrote that wiki John ? It's kind of a mess. I have a hard time
following that, and I have experience with this sort of thing.

On Thu, Jul 31, 2014 at 11:50 AM, John Syn john3...@gmail.com wrote:

 From: Giles Godart-Brown ggodartbr...@gmail.com
 Reply-To: beagleboard@googlegroups.com beagleboard@googlegroups.com
 Date: Thursday, July 31, 2014 at 1:41 AM
 To: beagleboard@googlegroups.com beagleboard@googlegroups.com

 Subject: Re: [beagleboard] unable to boot Beaglebone Black from NFS

 HURRAH it now works, thanks to all your help and no need to make a new
 kernel or uboot!

 Here is how its done at a high level, I will be writing it up in more
 detail on the Misterhouse on Beglebone instructions
 http://misterhouse.wikispaces.com/BeagleBoneBlack.

 1) Flash an SD card with the standard (non eMMC flashing) Debian image
 from here http://beagleboard.org/latest-images
 2) Set up an NFS share on your NAS/PC/whatever
 3) Boot your Bone with the SD Card
 4) Set the Bone to have a static IP address by editing
 /etc/netwotk/interfaces reboot and check it works
 4) NFS mount the shared drive from the Bone ( e.g. mount -o nfsvers=3
 192.168.10.118:/home/bone /mnt/nfs)
 5) sudo to root on the Bone and do all the rest of the Bone stuff as root
 6) copy everything to the NFS drive.  The second step seems unnecessary,
 but its quick compared with the first
cp -axv /. /mnt/nfs/.
cp -axv /dev/. /mnt/nfs/dev/.
 7)  edit the /mnt/nfs/etc/fstab to add
/dev/nfs / nfs defaults 0 0
 and comment out the other root partition,
 8) Edit your  /boot/uboot/uEnv.txt add the following lines - changed  to
 match your configuration
 serverip=192.168.10.118
 ipaddr=192.168.10.47
 hostname=MH_bbb
 netmask=255.255.255.0
 gateway=192.168.10.1
 nfsdevice=eth0:off
 nfsopts=vers=3
 rootpath=/home/bone/rootfs
 comment out the line that starts mmcargs as follows;
 #mmcargs=setenv bootargs
 add a new netargs line - note all on one line, not broken as here
 netargs=setenv bootargs console=${console} ${optargs} root=/dev/nfs
 nfsroot=${serverip}:${rootpath}
 ip=${ipaddr}:${serverip}:${gateway}:${netmask}:${hostname}:${nfsdevice}
 and finally replace the uenvcmd with this;
 uenvcmd=run loadfiles; run netargs; bootz ${loadaddr}
 ${initrd_addr}:${initrd_size} ${fdtaddr}

 Reboot and you should be able to ssh into your Bone, hear your disk drive
 whizzing and see your extra disk space with a df.
 For completeness I've attached my uEnv.txt

 As I said in my previous e-mail, all this above is unnecessary if you are
 using the latest u-boot. All you need is the 5 lines I showed below. As
 long as you define client_ip, the default u-boot env will use NFS. No need
 for uenvcmd, etc. Robert made NFS booting really simple:

 http://elinux.org/Beagleboard:U-boot_partitioning_layout_2.0#nfs_support

 Regards,
 John

 Thanks again
 Giles

 On Wednesday, 30 July 2014 17:43:50 UTC+1, john3909 wrote:

 From: Giles Godart-Brown ggodar...@gmail.com
 Reply-To: beagl...@googlegroups.com beagl...@googlegroups.com
 Date: Wednesday, July 30, 2014 at 12:24 AM
 To: beagl...@googlegroups.com beagl...@googlegroups.com
 Subject: Re: [beagleboard] unable to boot Beaglebone Black from NFS

 Thanks for your help, but sadly, on this version a uEnv.txt just
 containing;
 console=ttyO0,115200n8
 client_ip=192.168.10.47
 server_ip=192.168.10.118
 gw_ip=192.168.10.1
 root_dir=/home/bone/bbb_nfs_root

 does not work, it doesn't even fire up the ethernet port (no activity
 lights), I'm guessing because there is no eth0 defined and its perhaps
 trying to fire up the USB network or something.

 Make sure you are using the latest version of u-boot. I’m using

 U-Boot 2014.07-00014-gdc7e38e

 This is the v2014.07 with Robert Nelsons u-boot patch

 https://github.com/RobertCNelson/Bootloader-Builder/blob/master/patches/
 v2014.07/0001-am335x_evm-uEnv.txt-bootz-n-fixes.patch

 Or follow the instructions here:

 http://eewiki.net/display/linuxonarm/BeagleBone+Black#
 BeagleBoneBlack-Bootloader:U-Boot

 Regards,
 John

 I'll try the rsync method once I can ping the beaglebone

 G

 On Wednesday, 30 July 2014 03:05:41 UTC+1, john3909 wrote:

 From: Giles Godart-Brown ggodar...@gmail.com
 Reply-To: beagl...@googlegroups.com beagl...@googlegroups.com
 Date: Tuesday, July 29, 2014 at 2:26 PM
 To: beagl...@googlegroups.com beagl...@googlegroups.com
 Subject: [beagleboard] unable to boot Beaglebone Black from NFS

 I've seen many posts about how to boot a Beaglebone black via an NFS
 mounted root partition, but none seem to work with the latest version.
 I started by creating an NFS mount on my Ubuntu PC and successfully
 mounting it from the Beaglebone when booted from an SD image of the latest
 version dated 2013.06.20
 https://s3.amazonaws.com/angstrom/demo/beaglebone/Angstrom-Cloud9-IDE-GNOME-eglibc-ipk-v2012.12-beaglebone-2013.06.20.img.xz
  from
 the Beaglebone site. All the commands below were done as root.;
 uname -a
 Linux beaglebone 3.8.13-bone50 
 Then test the

[beagleboard] Re: RTC on BBB stop working after opkg upgrade

2014-07-31 Thread Fernando Derkoski

Hi there Ivan,

So my RTC was the problem, I fix it and now in my bash reads /rtc1 again 
and it is working fine.

To get my localtime working I did this

root@beaglebone:~# ntpdate -b -s -u pool.ntp.org
root@beaglebone:/etc# rm localtime
root@beaglebone:/etc# ln -s /usr/share/zoneinfo/America/Sao_Paulo 
/etc/localtime

You can replace with your zone. But besides the correct timezone I don't 
think that localtime have something to do with the RTC.

Here is my bash:

echo ds1307 0x68  /sys/class/i2c-adapter/i2c-1/new_device
hwclock -s -f /dev/rtc1
hwclock -w


and the service:


[Unit]
Description=DS1307 RTC Service

[Service]
Type=simple
WorkingDirectory=/usr/share/rtc_ds1307
ExecStart=/bin/bash clock_init.sh
SyslogIdentifier=rtc_ds1307

[Install]
WantedBy=multi-user.target

You enable the service? because if not when you restart he will not gonna 
start.

Regards.


On Thursday, July 31, 2014 2:58:32 PM UTC-3, ivan.de...@gmail.com wrote:

 Hi Fernando, 

 Im having the same problem as you had after the update, but I'm using the 
 BBB Rev C under Debian, and it does not get the time from the RTC during 
 boot, but it does if I perform the commands (mentioned in the tutorial) 
 manually:

 hwclock -s -f /dev/rtc1
 hwclock -w

 So I'd like to ask you what did you do about the /etc/localtime to make it 
 work, or how does this impact the RTC ?

 Besides, I see in your bash script *clock_init.sh*, you are using:


1. *echo ds1307 0x68  /sys/class/i2c-adapter/i2c-0/new_device*
2. *hwclock -s -f /dev/rtc0*
3. *hwclock -w*


 and as far as I know this is the BBB built-in RTC's path (not battery 
 backened) so I wonder how is this working on your BBB ?

 The Adafruit Tutorial is made for a RTC Battery Backened registered under 
 /dev/rtc1, as follows:

 echo ds1307 0x68  /sys/class/i2c-adapter/i2c-1/new_device
 hwclock -s -f /dev/rtc1
 hwclock -w

 Any suggestion, comment, idea is welcome

 Thanks

 Regards


 On Monday, February 24, 2014 12:24:00 PM UTC-6, Fernando Derkoski wrote:

 Yeah noob here, My /etc/localtime was not correct. Now the whole thing 
 work just fine.

 On Monday, February 24, 2014 1:45:18 PM UTC-3, Fernando Derkoski wrote:

 I tried *echo ds1307 0x68  /sys/class/i2c-adapter/i2c-0/new_device*

 and now is working, sort of, because the time it is not being set on 
 restart.
 here is my bash script:

 /usr/share/rtc_ds1307/clock_init.sh


1. *echo ds1307 0x68  /sys/class/i2c-adapter/i2c-0/new_device*
2. *hwclock -s -f /dev/rtc0*
3. *hwclock -w*


 And here is my service:

 /lib/systemd/system/rtc-ds1307.service


1. *[Unit]*
2. *Description=DS1307 RTC Service*
3.  
4. *[Service]*
5. *Type=simple*
6. *WorkingDirectory=/usr/share/rtc_ds1307*
7. *ExecStart=/bin/bash clock_init.sh*
8. *SyslogIdentifier=rtc_ds1307*
9.  
10. *[Install]*
11. *WantedBy=multi-user.target*


 My service is running on the restart, but if I run 
 dmesg | grep ds1307 I get:
 *[5.934660] rtc-ds1307: probe of 0-0068 failed with error -5*
 *[5.970362] i2c i2c-0: new_device: Instantiated device ds1307 at 
 0x68*


 On Monday, February 24, 2014 9:58:23 AM UTC-3, Fernando Derkoski wrote:

 Hello,

 Before the upgrade I was testing the RTC and it was normal, but after I 
 runned the okpg upgrade this happens:

 *root@beaglebone:~# i2cdetect -y -r 1*
 *] 0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f*
 *00:  -- -- -- -- -- -- -- -- -- -- -- -- --*
 *10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --*
 *20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --*
 *30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --*
 *40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --*
 *50: -- -- -- -- UU UU UU UU -- -- -- -- -- -- -- --*
 *60: -- -- -- -- -- -- -- -- 68 -- -- -- -- -- -- --*
 *70: -- -- -- -- -- -- -- --*
 *root@beaglebone:~# echo ds1307 0x68  
 /sys/class/i2c-adapter/i2c-1/new_device*
 *-sh: echo: write error: Invalid argument*
 *root@beaglebone:~#*

 I was doing this tutorial: 

 http://learn.adafruit.com/adding-a-real-time-clock-to-beaglebone-black/set-rtc-time

 Anyone could help me?



-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to 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] unable to boot Beaglebone Black from NFS

2014-07-31 Thread Robert Nelson

On Thu, Jul 31, 2014 at 2:02 PM, William Hermans yyrk...@gmail.com wrote:
 Who wrote that wiki John ? It's kind of a mess. I have a hard time following
 that, and I have experience with this sort of thing.

Yeah, a few more beers and i'll have it cleaned up... ;)

Right now it's still more of a spec page.

As it's a radical partition layout change.  While maintaining some
backward compatibility and giving upstream distros (debian) options
they need to work out of the box.

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] best kernel version for bbb

2014-07-31 Thread David Lambert


Robert,
For your perusal, I have attached my patch to get my cape 
peacefully coexisting (I hope) with the changes in 3.16.


Best regards,

Dave.

On 07/31/2014 01:32 PM, David Lambert wrote:

Robert,
I seem to have an issue with my 
am335x-boneblack-cape-bone-argus.dts in 3.16.0-rc7-bone1. This time it 
appears that there is a clash with the Ethernet subsystem. Has 
something changed in this area from 3.15?


Regards,

Dave.


On 07/16/2014 08:13 AM, David Lambert wrote:

Thanks Robert. That works fine!

Regards,
Dave.

On 07/15/2014 07:04 PM, Robert Nelson wrote:
On Tue, Jul 15, 2014 at 6:52 PM, David Lambert d...@lambsys.com 
wrote:

On 07/15/2014 04:40 PM, Robert Nelson wrote:
On Tue, Jul 15, 2014 at 4:35 PM, David Lambert d...@lambsys.com 
wrote:
Thanks so much Robert - I think you nailed it! Unfortunately I 
did not
inherit this change as I could not import am335x-bone-common.dtsi 
due to

the
clash:

/*pinctrl-0 = clkout2_pin; clash with argus-ups */

I'll clean that up in a bit and push it.. I have another patch from
John for audio too, so i'll get a new bone tag released this 
evening..


Regards,


Also I found this one.
/*pinctrl-0 = ecap0_pin_p9_42;  clash with Argus */
Here's what i came up for the v3.15.x branch. This should make usb 
work now..


https://github.com/RobertCNelson/bb-kernel/commit/e34510a7b5c6712386590818ba84e8ea8752f7f0 



Not sure of the best way to handle these sort of situations. 
Currently I am
just copying then editing the contents of am335x-bone-common.dtsi 
into my
dts. This is obviously a very messy hack. Maybe 
am335x-bone-common.dtsi

could be subdivided into smaller chunks

Yeah, it needs to be cleaned up badly.. It's only getting worse with
more patches on linux-omap.. We just need a weekend, few kegs and do a
cleanup..

1: am335x-bone-common.dtsi (only common stuff and all pinmux's)
2: am335x-boneblack-common.dtsi (no eMMC/HDMI/HDMI Audio)
3: am335x-boneblack-eMMC.dtsi
4: am335x-boneblack-HDMI.dtsi
5: am335x-boneblack-HDMIA.dtsi

am335x-bone.dtb = (1)
am335x-boneblack.dtb = (1+2+3+4+5)

Then it should be easy to expand on am335x-boneblack-common.dtsi and
enable your cape.

Regards,







--
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups BeagleBoard group.

To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
From 97426cfbbf2ae9942ad36682e10a6f3f7ac0867e Mon Sep 17 00:00:00 2001
From: Dave Lambert d...@lambsys.com
Date: Thu, 31 Jul 2014 14:33:48 -0500
Subject: Updated dts to be in line with 3.16 changes.

---
 .../boot/dts/am335x-boneblack-cape-bone-argus.dts  |  215 +---
 1 file changed, 186 insertions(+), 29 deletions(-)

diff --git a/arch/arm/boot/dts/am335x-boneblack-cape-bone-argus.dts b/arch/arm/boot/dts/am335x-boneblack-cape-bone-argus.dts
index fd864e3..a3e300a 100644
--- a/arch/arm/boot/dts/am335x-boneblack-cape-bone-argus.dts
+++ b/arch/arm/boot/dts/am335x-boneblack-cape-bone-argus.dts
@@ -59,7 +59,15 @@
 		};
 	};
 
-	vmmcsd_fixed: fixedregulator@0 {
+	vbat: fixedregulator@0 {
+		compatible = regulator-fixed;
+		regulator-name = vbat;
+		regulator-min-microvolt = 500;
+		regulator-max-microvolt = 500;
+		regulator-boot-on;
+	};
+
+	vmmcsd_fixed: fixedregulator@1 {
 		compatible = regulator-fixed;
 		regulator-name = vmmcsd_fixed;
 		regulator-min-microvolt = 330;
@@ -101,6 +109,20 @@
 		;
 	};
 
+	uart1_pins: pinmux_uart1_pins {
+		pinctrl-single,pins = 
+			0x180 (PIN_INPUT_PULLUP | MUX_MODE0)	/* uart1_rxd.uart1_rxd */
+			0x184 (PIN_OUTPUT_PULLDOWN | MUX_MODE0)	/* uart1_txd.uart1_txd */
+		;
+	};
+
+	uart2_pins: pinmux_uart2_pins {
+		pinctrl-single,pins = 
+			0x150 0x21	/* spi0_sclk.uart2_rxd | MODE1 */
+			0x154 0x01	/* spi0_d0.uart2_txd | MODE1 */
+		;
+	};
+
 	uart4_pins: pinmux_uart4_pins {
 		pinctrl-single,pins = 
 			0x070 0x26	/* gpmc_wait0.uart4_rxd | MODE6 */
@@ -108,6 +130,13 @@
 		;
 	};
 
+	uart5_pins: pinmux_uart5_pins {
+		pinctrl-single,pins = 
+			0x0C4 0x24	/* lcd_data9.uart5_rxd | MODE4 */
+			0x0C0 0x04	/* lcd_data8.uart5_txd | MODE4 */
+		;
+	};
+
 	clkout2_pin: pinmux_clkout2_pin {
 		pinctrl-single,pins = 
 			0x1b4 (PIN_OUTPUT_PULLDOWN | MUX_MODE3)	/* xdma_event_intr1.clkout2 */
@@ -173,6 +202,47 @@
 			0x160 (PIN_INPUT | MUX_MODE7) /* GPIO0_6 */
 		;
 	};
+	emmc_pins: pinmux_emmc_pins {
+		pinctrl-single,pins = 
+			0x80 (PIN_INPUT_PULLUP | MUX_MODE2) /* gpmc_csn1.mmc1_clk */
+			0x84 (PIN_INPUT_PULLUP | MUX_MODE2) /* gpmc_csn2.mmc1_cmd */
+			0x00 (PIN_INPUT_PULLUP | MUX_MODE1) /* gpmc_ad0.mmc1_dat0 */
+			0x04 (PIN_INPUT_PULLUP | MUX_MODE1) /* gpmc_ad1.mmc1_dat1 */
+			0x08 (PIN_INPUT_PULLUP | MUX_MODE1) /* gpmc_ad2.mmc1_dat2 */
+			0x0c (PIN_INPUT_PULLUP | MUX_MODE1) /* gpmc_ad3.mmc1_dat3 */
+			0x10 (PIN_INPUT_PULLUP | MUX_MODE1) /* gpmc_ad4.mmc1_dat4

Re: [beagleboard] BBB Rev C: Debian: PureJavaComm/JNA test fails

Well, it should be very obvious by now that I have a strong dislike for
Java, and I was being too literal. This sort of situation really upsets me,
and I've seen it happen on more than Java too. Most recently was with
Nodejs, and an older package manager pulling in x86 / i386 specific code
for my own BBB. This does not happen at all with NPM, at least not that
I've seen yet.

Also since I do not use Java at all, I was under the impression that the
JVM was supposed to handle all the hardware abstraction, but from what
you're saying here I was probably wrong. At least in the context of
hardware architecture. This is how I feel it should be done however.

I still wont touch Java, and there is at least one more language I try to
avoid at all costs too. But if it works for you, I say more power to you.
It was not my intention to start a holy crusade in the name of
development.. Despite the fact that seems where I've taken us.


On Thu, Jul 31, 2014 at 10:01 AM, Datenheld datenh...@gmail.com wrote:

 You're being too harsh on the topic. Most people didn't really use java
 because of platform independence. In the beginnings of Java, applets were
 the killer feature. You could easily deliver fat client software with the
 webbrowser. It wasn't that much about platform independence. Java is a lot
 more than platform independence.

 Platform independence hast its limits by design. When you want to be
 independent of something, you need abstractions. Abstractions are leaky,
 though. When you then want to do something, which is not common to all(!)
 platforms you support, then you cannot generalize it. Or you make it
 possible but then you depend  upon the details of the platform. Those
 details are for example the native library that PureJavaComm delivers.

 also it is not very proficient especially considering you've spent how
 many days here trying to troubleshoot an issue that should never have
 existed

 Well, I'm arguing against that by saying, that you will potentially have
 the same problem in every language that uses a runtime and does not compile
 to native code.

 I could go on all day, but THIS is one reason why Java is a horrible
 language.  People are taught to write sloppy / crappy code like this, and
 told  that it's fine / good. It's not fine, when you break a key feature in
 a language.

 Why is it a key feature to communicate with low level peripherals? Once
 you go beneath a leaky abstraction (and every abstraction is leaky), you
 will have tight dependencies. You cannot say the code is crappy. The things
 you want to do are simply not possible without writing native code. When
 you choose to write such code in Java, it is by design and not necessarily
 crappy. It's all about the API for Java.

 I could take a native i386 lib with a python API, pull it over to arm and
 then complain that it does not work as well. This is basically what you are
 doing currently, no offense meant.

 Anyway, do not take the above personally. but please do try to expand
 your horizons some.

 Well, personally, I am proficient in quite a lot languages. So I feel like
 I can judge languages quite well. Java has its flaws, but as a language, it
 is quite decent. You can write bad code in any language and Java code is
 not necessarily bad code, just because it breaks platform independence
 (reasoning: see above). I like Java because it's object oriented and does
 not need extensive resource managing like C++. I can handle complexity with
 it much better, than in C. And since I use it at work, I am getting results
 very fast.

 --
 For more options, visit http://beagleboard.org/discuss
 ---
 You received this message because you are subscribed to 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] unable to boot Beaglebone Black from NFS

From:  William Hermans yyrk...@gmail.com
Reply-To:  beagleboard@googlegroups.com beagleboard@googlegroups.com
Date:  Thursday, July 31, 2014 at 12:02 PM
To:  beagleboard@googlegroups.com beagleboard@googlegroups.com
Subject:  Re: [beagleboard] unable to boot Beaglebone Black from NFS

 Who wrote that wiki John ? It's kind of a mess. I have a hard time following
 that, and I have experience with this sort of thing.
OK, so now you have to apologize to Robert for pissing over his hard work.
LOL

 On Thu, Jul 31, 2014 at 11:50 AM, John Syn john3...@gmail.com wrote:

 From:  Giles Godart-Brown ggodartbr...@gmail.com
 Reply-To:  beagleboard@googlegroups.com beagleboard@googlegroups.com
 Date:  Thursday, July 31, 2014 at 1:41 AM
 To:  beagleboard@googlegroups.com beagleboard@googlegroups.com

 Subject:  Re: [beagleboard] unable to boot Beaglebone Black from NFS

 HURRAH it now works, thanks to all your help and no need to make a new
 kernel or uboot!

 Here is how its done at a high level, I will be writing it up in more detail
 on the Misterhouse on Beglebone instructions
 http://misterhouse.wikispaces.com/BeagleBoneBlack .

 1) Flash an SD card with the standard (non eMMC flashing) Debian image from
 here http://beagleboard.org/latest-images
 2) Set up an NFS share on your NAS/PC/whatever
 3) Boot your Bone with the SD Card
 4) Set the Bone to have a static IP address by editing
 /etc/netwotk/interfaces reboot and check it works
 4) NFS mount the shared drive from the Bone ( e.g. mount -o nfsvers=3
 192.168.10.118:/home/bone /mnt/nfs)
 5) sudo to root on the Bone and do all the rest of the Bone stuff as root
 6) copy everything to the NFS drive.  The second step seems unnecessary, but
 its quick compared with the first
cp -axv /. /mnt/nfs/.
cp -axv /dev/. /mnt/nfs/dev/.
 7)  edit the /mnt/nfs/etc/fstab to add
/dev/nfs / nfs defaults 0 0
 and comment out the other root partition,
 8) Edit your  /boot/uboot/uEnv.txt add the following lines - changed  to
 match your configuration
 serverip=192.168.10.118
 ipaddr=192.168.10.47
 hostname=MH_bbb
 netmask=255.255.255.0
 gateway=192.168.10.1
 nfsdevice=eth0:off
 nfsopts=vers=3
 rootpath=/home/bone/rootfs
 comment out the line that starts mmcargs as follows;
 #mmcargs=setenv bootargs
 add a new netargs line - note all on one line, not broken as here
 netargs=setenv bootargs console=${console} ${optargs} root=/dev/nfs
 nfsroot=${serverip}:${rootpath}
 ip=${ipaddr}:${serverip}:${gateway}:${netmask}:${hostname}:${nfsdevice}
 and finally replace the uenvcmd with this;
 uenvcmd=run loadfiles; run netargs; bootz ${loadaddr}
 ${initrd_addr}:${initrd_size} ${fdtaddr}

 Reboot and you should be able to ssh into your Bone, hear your disk drive
 whizzing and see your extra disk space with a df.
 For completeness I've attached my uEnv.txt
 As I said in my previous e-mail, all this above is unnecessary if you are
 using the latest u-boot. All you need is the 5 lines I showed below. As long
 as you define client_ip, the default u-boot env will use NFS. No need for
 uenvcmd, etc. Robert made NFS booting really simple:

 http://elinux.org/Beagleboard:U-boot_partitioning_layout_2.0#nfs_support

 Regards,
 John

 Thanks again
 Giles

 On Wednesday, 30 July 2014 17:43:50 UTC+1, john3909  wrote:

 From:  Giles Godart-Brown ggodar...@gmail.com
 Reply-To:  beagl...@googlegroups.com beagl...@googlegroups.com
 Date:  Wednesday, July 30, 2014 at 12:24 AM
 To:  beagl...@googlegroups.com beagl...@googlegroups.com
 Subject:  Re: [beagleboard] unable to boot Beaglebone Black from NFS

 Thanks for your help, but sadly, on this version a uEnv.txt just
 containing;
 console=ttyO0,115200n8
 client_ip=192.168.10.47
 server_ip=192.168.10.118
 gw_ip=192.168.10.1
 root_dir=/home/bone/bbb_nfs_root

 does not work, it doesn't even fire up the ethernet port (no activity
 lights), I'm guessing because there is no eth0 defined and its perhaps
 trying to fire up the USB network or something.
 Make sure you are using the latest version of u-boot. I¹m using

 U-Boot 2014.07-00014-gdc7e38e

 This is the v2014.07 with Robert Nelsons u-boot patch

 https://github.com/RobertCNelson/Bootloader-Builder/blob/master/patches/v20
 14.07/0001-am335x_evm-uEnv.txt-bootz-n-fixes.patch
 https://github.com/RobertCNelson/Bootloader-Builder/blob/master/patches/v2
 014.07/0001-am335x_evm-uEnv.txt-bootz-n-fixes.patch

 Or follow the instructions here:

 http://eewiki.net/display/linuxonarm/BeagleBone+Black#BeagleBoneBlack-Bootl
 oader:U-Boot 
 http://eewiki.net/display/linuxonarm/BeagleBone+Black#BeagleBoneBlack-Boot
 loader:U-Boot

 Regards,
 John

 I'll try the rsync method once I can ping the beaglebone

 G

 On Wednesday, 30 July 2014 03:05:41 UTC+1, john3909  wrote:

 From:  Giles Godart-Brown ggodar...@gmail.com
 Reply-To:  beagl...@googlegroups.com beagl...@googlegroups.com
 Date:  Tuesday, July 29, 2014 at 2:26 PM
 To:  beagl...@googlegroups.com beagl...@googlegroups.com
 Subject:

Re: [beagleboard] BBB Rev C: Debian: PureJavaComm/JNA test fails

By the way, the only reason why I brought up cross platform as a key
feature. Is that many languages out there have a strong framework to back
them up. .NET( pick your language ), Nodejs ( which by its self technically
isn't a language ), Python, etc.


On Thu, Jul 31, 2014 at 12:53 PM, William Hermans yyrk...@gmail.com wrote:

 Well, it should be very obvious by now that I have a strong dislike for
 Java, and I was being too literal. This sort of situation really upsets me,
 and I've seen it happen on more than Java too. Most recently was with
 Nodejs, and an older package manager pulling in x86 / i386 specific code
 for my own BBB. This does not happen at all with NPM, at least not that
 I've seen yet.

 Also since I do not use Java at all, I was under the impression that the
 JVM was supposed to handle all the hardware abstraction, but from what
 you're saying here I was probably wrong. At least in the context of
 hardware architecture. This is how I feel it should be done however.

 I still wont touch Java, and there is at least one more language I try to
 avoid at all costs too. But if it works for you, I say more power to you.
 It was not my intention to start a holy crusade in the name of
 development.. Despite the fact that seems where I've taken us.


 On Thu, Jul 31, 2014 at 10:01 AM, Datenheld datenh...@gmail.com wrote:

 You're being too harsh on the topic. Most people didn't really use java
 because of platform independence. In the beginnings of Java, applets were
 the killer feature. You could easily deliver fat client software with the
 webbrowser. It wasn't that much about platform independence. Java is a lot
 more than platform independence.

 Platform independence hast its limits by design. When you want to be
 independent of something, you need abstractions. Abstractions are leaky,
 though. When you then want to do something, which is not common to all(!)
 platforms you support, then you cannot generalize it. Or you make it
 possible but then you depend  upon the details of the platform. Those
 details are for example the native library that PureJavaComm delivers.

 also it is not very proficient especially considering you've spent how
 many days here trying to troubleshoot an issue that should never have
 existed

 Well, I'm arguing against that by saying, that you will potentially have
 the same problem in every language that uses a runtime and does not compile
 to native code.

 I could go on all day, but THIS is one reason why Java is a horrible
 language.  People are taught to write sloppy / crappy code like this, and
 told  that it's fine / good. It's not fine, when you break a key feature in
 a language.

 Why is it a key feature to communicate with low level peripherals? Once
 you go beneath a leaky abstraction (and every abstraction is leaky), you
 will have tight dependencies. You cannot say the code is crappy. The things
 you want to do are simply not possible without writing native code. When
 you choose to write such code in Java, it is by design and not necessarily
 crappy. It's all about the API for Java.

 I could take a native i386 lib with a python API, pull it over to arm and
 then complain that it does not work as well. This is basically what you are
 doing currently, no offense meant.

 Anyway, do not take the above personally. but please do try to expand
 your horizons some.

 Well, personally, I am proficient in quite a lot languages. So I feel
 like I can judge languages quite well. Java has its flaws, but as a
 language, it is quite decent. You can write bad code in any language and
 Java code is not necessarily bad code, just because it breaks platform
 independence (reasoning: see above). I like Java because it's object
 oriented and does not need extensive resource managing like C++. I can
 handle complexity with it much better, than in C. And since I use it at
 work, I am getting results very fast.

 --
 For more options, visit http://beagleboard.org/discuss
 ---
 You received this message because you are subscribed to 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] unable to boot Beaglebone Black from NFS


On 7/31/14, 12:10 PM, Robert Nelson robertcnel...@gmail.com wrote:

On Thu, Jul 31, 2014 at 2:02 PM, William Hermans yyrk...@gmail.com
wrote:
 Who wrote that wiki John ? It's kind of a mess. I have a hard time
following
 that, and I have experience with this sort of thing.

Yeah, a few more beers and i'll have it cleaned up... ;)
Home brew?

Right now it's still more of a spec page.

As it's a radical partition layout change.  While maintaining some
backward compatibility and giving upstream distros (debian) options
they need to work out of the box.

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] unable to boot Beaglebone Black from NFS

Robert, heh . . . sorry, but it's true  At least you have a valid reason
though. Too busy making all this work. ;)

On Thu, Jul 31, 2014 at 1:01 PM, John Syn john3...@gmail.com wrote:

 From: William Hermans yyrk...@gmail.com
 Reply-To: beagleboard@googlegroups.com beagleboard@googlegroups.com
 Date: Thursday, July 31, 2014 at 12:02 PM

 To: beagleboard@googlegroups.com beagleboard@googlegroups.com
 Subject: Re: [beagleboard] unable to boot Beaglebone Black from NFS

 Who wrote that wiki John ? It's kind of a mess. I have a hard time
 following that, and I have experience with this sort of thing.

 OK, so now you have to apologize to Robert for pissing over his hard work.
 LOL

 On Thu, Jul 31, 2014 at 11:50 AM, John Syn john3...@gmail.com wrote:

 From: Giles Godart-Brown ggodartbr...@gmail.com
 Reply-To: beagleboard@googlegroups.com beagleboard@googlegroups.com
 Date: Thursday, July 31, 2014 at 1:41 AM
 To: beagleboard@googlegroups.com beagleboard@googlegroups.com

 Subject: Re: [beagleboard] unable to boot Beaglebone Black from NFS

 HURRAH it now works, thanks to all your help and no need to make a new
 kernel or uboot!

 Here is how its done at a high level, I will be writing it up in more
 detail on the Misterhouse on Beglebone instructions
 http://misterhouse.wikispaces.com/BeagleBoneBlack.

 1) Flash an SD card with the standard (non eMMC flashing) Debian image
 from here http://beagleboard.org/latest-images
 2) Set up an NFS share on your NAS/PC/whatever
 3) Boot your Bone with the SD Card
 4) Set the Bone to have a static IP address by editing
 /etc/netwotk/interfaces reboot and check it works
 4) NFS mount the shared drive from the Bone ( e.g. mount -o nfsvers=3
 192.168.10.118:/home/bone /mnt/nfs)
 5) sudo to root on the Bone and do all the rest of the Bone stuff as root
 6) copy everything to the NFS drive.  The second step seems unnecessary,
 but its quick compared with the first
cp -axv /. /mnt/nfs/.
cp -axv /dev/. /mnt/nfs/dev/.
 7)  edit the /mnt/nfs/etc/fstab to add
/dev/nfs / nfs defaults 0 0
 and comment out the other root partition,
 8) Edit your  /boot/uboot/uEnv.txt add the following lines - changed  to
 match your configuration
 serverip=192.168.10.118
 ipaddr=192.168.10.47
 hostname=MH_bbb
 netmask=255.255.255.0
 gateway=192.168.10.1
 nfsdevice=eth0:off
 nfsopts=vers=3
 rootpath=/home/bone/rootfs
 comment out the line that starts mmcargs as follows;
 #mmcargs=setenv bootargs
 add a new netargs line - note all on one line, not broken as here
 netargs=setenv bootargs console=${console} ${optargs} root=/dev/nfs
 nfsroot=${serverip}:${rootpath}
 ip=${ipaddr}:${serverip}:${gateway}:${netmask}:${hostname}:${nfsdevice}
 and finally replace the uenvcmd with this;
 uenvcmd=run loadfiles; run netargs; bootz ${loadaddr}
 ${initrd_addr}:${initrd_size} ${fdtaddr}

 Reboot and you should be able to ssh into your Bone, hear your disk drive
 whizzing and see your extra disk space with a df.
 For completeness I've attached my uEnv.txt

 As I said in my previous e-mail, all this above is unnecessary if you are
 using the latest u-boot. All you need is the 5 lines I showed below. As
 long as you define client_ip, the default u-boot env will use NFS. No need
 for uenvcmd, etc. Robert made NFS booting really simple:

 http://elinux.org/Beagleboard:U-boot_partitioning_layout_2.0#nfs_support

 Regards,
 John

 Thanks again
 Giles

 On Wednesday, 30 July 2014 17:43:50 UTC+1, john3909 wrote:

 From: Giles Godart-Brown ggodar...@gmail.com
 Reply-To: beagl...@googlegroups.com beagl...@googlegroups.com
 Date: Wednesday, July 30, 2014 at 12:24 AM
 To: beagl...@googlegroups.com beagl...@googlegroups.com
 Subject: Re: [beagleboard] unable to boot Beaglebone Black from NFS

 Thanks for your help, but sadly, on this version a uEnv.txt just
 containing;
 console=ttyO0,115200n8
 client_ip=192.168.10.47
 server_ip=192.168.10.118
 gw_ip=192.168.10.1
 root_dir=/home/bone/bbb_nfs_root

 does not work, it doesn't even fire up the ethernet port (no activity
 lights), I'm guessing because there is no eth0 defined and its perhaps
 trying to fire up the USB network or something.

 Make sure you are using the latest version of u-boot. I’m using

 U-Boot 2014.07-00014-gdc7e38e

 This is the v2014.07 with Robert Nelsons u-boot patch

 https://github.com/RobertCNelson/Bootloader-Builder/blob/master/patches/
 v2014.07/0001-am335x_evm-uEnv.txt-bootz-n-fixes.patch

 Or follow the instructions here:

 http://eewiki.net/display/linuxonarm/BeagleBone+Black#
 BeagleBoneBlack-Bootloader:U-Boot

 Regards,
 John

 I'll try the rsync method once I can ping the beaglebone

 G

 On Wednesday, 30 July 2014 03:05:41 UTC+1, john3909 wrote:

 From: Giles Godart-Brown ggodar...@gmail.com
 Reply-To: beagl...@googlegroups.com beagl...@googlegroups.com
 Date: Tuesday, July 29, 2014 at 2:26 PM
 To: beagl...@googlegroups.com beagl...@googlegroups.com
 Subject: [beagleboard] unable to boot Beaglebone Black from NFS

 I've seen

[beagleboard] Re: I2C Problem using TMP_006

2014-07-31 Thread Noah Wesche

I have solved my own problem! 

When installing i2c and tmp_006 I didn't install them globally. here is my 
revised terminal commands.

$ npm install -g i2c

$ npm install -g sensor_tmp006





On Tuesday, July 29, 2014 6:13:02 PM UTC-6, Noah Wesche wrote:

 *Hello,*

 *   I am having difficulty understanding why I cannot get my TMP_006 I2C 
 device to output a value. *

 *I have followed these instructions to put I2C library on my BBB:*

 https://www.npmjs.org/package/i2c

 *This tutorial has a section for BBB which has the following Terminal 
 commands which completed successfully:*


 $ ntpdate -b -s -u pool.ntp.org
 $ opkg update
 $ opkg install python-compile
 $ opkg install python-modules
 $ npm config set strict-ssl false
 $ npm install i2c

 *NOTE* opkg is used on Angstrom and I used apt-get on Debian

 *I Then used the following instructions for the TMP_006:*

 https://www.npmjs.org/package/sensor_tmp006

 *Which told me to do this...*

 $ npm install sensor_tmp006

 *Which I did without issue. *

 *Then I ran the code in the Simple Usage area to see if my TMP_006 will 
 work:*

 var TMP006 = require('sensor_tmp006');
 var sense = new TMP006();
 sense.init(function(err, val) {
   if (!err) {
 sense.getObjTemp(function(error, val) {
   if (!error) console.log(val + ' °C');
 });
   } 

 }); 



 *I get an error that says:*

 Error: Cannot find module 'sensor_tmp006'
 at Function.Module._resolveFilename (module.js:338:15)
 at Function.Module._load (module.js:280:25)
 at Module.require (module.js:364:17)
 at require (module.js:380:17)
 at Object.anonymous (/var/lib/cloud9/Noah/i2ctest.js:1:76)
 at Module._compile (module.js:456:26)
 at Object.Module._extensions..js (module.js:474:10)
 at Module.load (module.js:356:32)
 at Function.Module._load (module.js:312:12)
 at Module.runMain [as _onTimeout] (module.js:497:10)

 [Process stopped]

 *Can anyone please help me solve this issue? My I2C address is 0X40 and 
 this was confirmed using i2cdetect in terminal:*

  0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f
 00:  -- -- -- -- -- -- -- -- -- -- -- -- -- 
 10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
 20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
 30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
 40: 40 -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
 50: -- -- -- -- UU UU UU UU -- -- -- -- -- -- -- -- 
 60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- 
 70: -- -- -- -- -- -- -- -- 
 root@beaglebone:~# 






-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to 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] SPi, I2C, GPIO and Qt5 on BBB

From:  William Hermans yyrk...@gmail.com
Reply-To:  beagleboard@googlegroups.com beagleboard@googlegroups.com
Date:  Tuesday, July 29, 2014 at 12:00 AM
To:  beagleboard@googlegroups.com beagleboard@googlegroups.com
Subject:  Re: [beagleboard] SPi, I2C, GPIO and Qt5 on BBB

 Ah right, I was thinking in the context of 3.8.x version. 3.13.x is EOL I
 believe ( meaning end of life )  That appears to be OpenGLES2, but frame
 buffer support only.

 From what I understand, TI made the choice of supporting 3.13.x branch with
 the SGX hardware. capremgr was in 3.8.x, and based on Roberts guide, 3.15.x
 has better ethernet, and usb support.

 As for why the branches are done this way ? I'm not a kernel developer so I'm
 not 100% sure. However I could imagine that it is a lot of work setting all
 this up plus scripts / instructions for building etc. I've seen Robert say
 several times patches welcome, so I'm assuming he may not wish to duplicate
 his own work across branches. But this is just speculation on my own behalf.

 I'd be willing myself to work on getting capemgr as is working on 3.8.x into
 3.15.x myself. But since I'm fairly inexperienced in this area I'd need time,
 and a mentor ( as in to guide me, not to pay me ).
Looks like the capemgr functionality will be in V3.17:

https://lkml.org/lkml/2014/7/27/57

Regards,
John

 On Mon, Jul 28, 2014 at 11:18 PM, Cedric Malitte cedric.mali...@gmail.com
 wrote:
 I just followed 
 http://eewiki.net/display/linuxonarm/BeagleBone+Black#BeagleBoneBlack-SGX for
 the opengl part, built against v3.13.11-bone12

 Must say I feel lost with all those features appearing and disappearing with
 the kernel releases.

 Le mardi 29 juillet 2014 00:38:32 UTC-4, William Hermans a écrit :
 If you get OpenGLES working on the BBB I'd be interested in how you did it.
 I like to read about geeky things like this ;)  However last I remember this
 was not possible with the way software support is. Hopefully that will
 change if not already.

 On Mon, Jul 28, 2014 at 8:35 PM, Cedric Malitte cedric@gmail.com
 wrote:
 Thanks William,

 I tried to compile kernel 3.13, GFX libraries , all fine.
 Copied all the stuff on a SD card and booted... well, everything here but
 screen ! 

 I need to find how to enable LCD4 cape with new kernel.

 That said, I tried to compile qt4.8.6 with opengl es2 and I have an error:
 make[4]: entrant dans le répertoire «
 /home/cedric/qt4-bbb/downloads/qt-everywhere-opensource-src-4.8.6/src/plugi
 ns/gfxdrivers/powervr/QWSWSEGL »
 /home/cedric/bb-kernel/dl/gcc-linaro-arm-linux-gnueabihf-4.8-2014.04_linux/
 bin/arm-linux-gnueabihf-gcc -c -pipe -O3 -march=armv7-a -mtune=cortex-a8
 -mfpu=neon -mfloat-abi=hard -Wall -W -fPIC -DQT_NO_QWS_CURSOR
 -DQT_QWS_CLIENTBLIT -I../../../../../mkspecs/qws/linux-TIarmv7-sgx-g++ -I.
 -I/home/cedric/qt4-bbb/downloads/tslib/src
 -I/home/cedric/bb-kernel/ignore/SDK_BIN/Graphics_SDK_setuplinux_5_01_01_01/
 GFX_Linux_SDK/OGLES2/SDKPackage/Builds/OGLES2/Include
 -I/home/cedric/bb-kernel/ignore/SDK_BIN/Graphics_SDK_setuplinux_5_01_01_01/
 GFX_Linux_SDK/OGLES2/SDKPackage/Builds/OGLES2/LinuxOMAP3/Include/
 -I/home/cedric/bb-kernel/ignore/SDK_BIN/Graphics_SDK_setuplinux_5_01_01_01/
 include 
 -I/home/cedric/bb-kernel/ignore/SDK_BIN/Graphics_SDK_setuplinux_5_01_01_01/
 GFX_Linux_SDK/OGLES/SDKPackage/Builds/OGLES/Include -o
 .obj/release-shared-emb-arm/pvrqwsdrawable.o pvrqwsdrawable.c
 In file included from pvrqwsdrawable.c:42:0:
 pvrqwsdrawable_p.h:56:19: fatal error: pvr2d.h: Aucun fichier ou dossier de
 ce type
  #include pvr2d.h

 Means no such file, although I have applied patches from
 https://github.com/prabindh/qt-configs/tree/master/qt4.8
 https://github.com/prabindh/qt-configs/tree/master/qt4.8

 Still trying.

 2014-07-27 23:56 GMT-04:00 William Hermans yyr...@gmail.com:
 Cedric, Hi,

 For starters: http://eewiki.net/display/linuxonarm/BeagleBone+Black
 http://eewiki.net/display/linuxonarm/BeagleBone+Black  this is Roberts
 build your own guide.

 http://eewiki.net/display/linuxonarm/BeagleBone+Black#BeagleBoneBlack-Root
 FileSystem%28smallflash%29
 http://eewiki.net/display/linuxonarm/BeagleBone+Black#BeagleBoneBlack-Roo
 tFileSystem%28smallflash%29  This base image is around 75M in size for me
 without anything else installed. WIth openssh-server, and ntpdate, I think
 around 91M size total.

 As for the rest of your questions: I do not know personally. I do not use
 QT, or an LCD. As I run headless, and have no interest in either for my
 own purposes. Instead I use my own BBB as kind of a network appliance by
 using Nodejs.

 On Sun, Jul 27, 2014 at 3:18 PM, Cedric Malitte cedric@gmail.com
 wrote:
 Hi all,

 while waiting for the new kernel to compile, I ask for advices !

 I have a new project about reading sensors, analyzing them, and graph
 them on a portable unit.

 I studied the doable thing on a PIC. It was fine to a certain point
 using a FT800 Eve chip for graphical LCD.

[beagleboard] Looking for Device Tree file for Beaglebone (White) and 3.8 Kernel optimized for Beaglebone

2014-07-31 Thread bbaskii



Hi,


I am having Beaglebone white board which contains AM3359 Processor. I 
wanted to load the latest 3.8 kernel with device tree on that board. Is 
there any one tried that? If so can you please post the device tree file 
for AM3359. Also the link to latest Linux 3.8 kernel optimized for 
Beaglebone.

Thank you,

Baskaran

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to 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] SPi, I2C, GPIO and Qt5 on BBB

So all that remains is SGX / OGL support too . . . Is this likely ?

On Thu, Jul 31, 2014 at 1:39 PM, John Syn john3...@gmail.com wrote:

 From: William Hermans yyrk...@gmail.com
 Reply-To: beagleboard@googlegroups.com beagleboard@googlegroups.com
 Date: Tuesday, July 29, 2014 at 12:00 AM
 To: beagleboard@googlegroups.com beagleboard@googlegroups.com
 Subject: Re: [beagleboard] SPi, I2C, GPIO and Qt5 on BBB

 Ah right, I was thinking in the context of 3.8.x version. 3.13.x is EOL I
 believe ( meaning end of life )  That appears to be OpenGLES2, but frame
 buffer support only.

 From what I understand, TI made the choice of supporting 3.13.x branch
 with the SGX hardware. capremgr was in 3.8.x, and based on Roberts guide,
 3.15.x has better ethernet, and usb support.

 As for why the branches are done this way ? I'm not a kernel developer so
 I'm not 100% sure. However I could imagine that it is a lot of work setting
 all this up plus scripts / instructions for building etc. I've seen Robert
 say several times patches welcome, so I'm assuming he may not wish to
 duplicate his own work across branches. But this is just speculation on my
 own behalf.

 I'd be willing myself to work on getting capemgr as is working on 3.8.x
 into 3.15.x myself. But since I'm fairly inexperienced in this area I'd
 need time, and a mentor ( as in to guide me, not to pay me ).

 Looks like the capemgr functionality will be in V3.17:

 https://lkml.org/lkml/2014/7/27/57

 Regards,
 John

 On Mon, Jul 28, 2014 at 11:18 PM, Cedric Malitte cedric.mali...@gmail.com
  wrote:

 I just followed
 http://eewiki.net/display/linuxonarm/BeagleBone+Black#BeagleBoneBlack-SGX for
 the opengl part, built against v3.13.11-bone12

 Must say I feel lost with all those features appearing and disappearing
 with the kernel releases.

 Le mardi 29 juillet 2014 00:38:32 UTC-4, William Hermans a écrit :

 If you get OpenGLES working on the BBB I'd be interested in how you did
 it. I like to read about geeky things like this ;)  However last I remember
 this was not possible with the way software support is. Hopefully that will
 change if not already.

 On Mon, Jul 28, 2014 at 8:35 PM, Cedric Malitte cedric@gmail.com
 wrote:

 Thanks William,

 I tried to compile kernel 3.13, GFX libraries , all fine.
 Copied all the stuff on a SD card and booted... well, everything here
 but screen !

 I need to find how to enable LCD4 cape with new kernel.

 That said, I tried to compile qt4.8.6 with opengl es2 and I have an
 error:
 make[4]: entrant dans le répertoire « /home/cedric/qt4-bbb/
 downloads/qt-everywhere-opensource-src-4.8.6/src/
 plugins/gfxdrivers/powervr/QWSWSEGL »
 /home/cedric/bb-kernel/dl/gcc-linaro-arm-linux-gnueabihf-4.
 8-2014.04_linux/bin/arm-linux-gnueabihf-gcc -c -pipe -O3
 -march=armv7-a -mtune=cortex-a8 -mfpu=neon -mfloat-abi=hard -Wall -W -fPIC
 -DQT_NO_QWS_CURSOR -DQT_QWS_CLIENTBLIT 
 -I../../../../../mkspecs/qws/linux-TIarmv7-sgx-g++
 -I. -I/home/cedric/qt4-bbb/downloads/tslib/src
 -I/home/cedric/bb-kernel/ignore/SDK_BIN/Graphics_SDK_
 setuplinux_5_01_01_01/GFX_Linux_SDK/OGLES2/SDKPackage/Builds/OGLES2/Include
 -I/home/cedric/bb-kernel/ignore/SDK_BIN/Graphics_SDK_
 setuplinux_5_01_01_01/GFX_Linux_SDK/OGLES2/SDKPackage/
 Builds/OGLES2/LinuxOMAP3/Include/ -I/home/cedric/bb-kernel/
 ignore/SDK_BIN/Graphics_SDK_setuplinux_5_01_01_01/include
 -I/home/cedric/bb-kernel/ignore/SDK_BIN/Graphics_SDK_
 setuplinux_5_01_01_01/GFX_Linux_SDK/OGLES/SDKPackage/Builds/OGLES/Include
 -o .obj/release-shared-emb-arm/pvrqwsdrawable.o pvrqwsdrawable.c
 In file included from pvrqwsdrawable.c:42:0:
 pvrqwsdrawable_p.h:56:19: fatal error: pvr2d.h: Aucun fichier ou
 dossier de ce type
  #include pvr2d.h

 Means no such file, although I have applied patches from
 https://github.com/prabindh/qt-configs/tree/master/qt4.8

 Still trying.

 2014-07-27 23:56 GMT-04:00 William Hermans yyr...@gmail.com:

 Cedric, Hi,

 For starters: http://eewiki.net/display/linuxonarm/BeagleBone+Black
 this is Roberts build your own guide.

 http://eewiki.net/display/linuxonarm/BeagleBone+Black#BeagleBoneBlack-
 RootFileSystem%28smallflash%29 This base image is around 75M in size
 for me without anything else installed. WIth openssh-server, and ntpdate, 
 I
 think around 91M size total.

 As for the rest of your questions: I do not know personally. I do not
 use QT, or an LCD. As I run headless, and have no interest in either for 
 my
 own purposes. Instead I use my own BBB as kind of a network appliance by
 using Nodejs.

 On Sun, Jul 27, 2014 at 3:18 PM, Cedric Malitte cedric@gmail.com
 wrote:

 Hi all,

 while waiting for the new kernel to compile, I ask for advices !

 I have a new project about reading sensors, analyzing them, and graph
 them on a portable unit.

 I studied the doable thing on a PIC. It was fine to a certain point
 using a FT800 Eve chip for graphical LCD.
 Until... the mechanical engineer asked for new features like 20KSps
 sampling of 4

Re: [beagleboard] SPi, I2C, GPIO and Qt5 on BBB

From:  William Hermans yyrk...@gmail.com
Reply-To:  beagleboard@googlegroups.com beagleboard@googlegroups.com
Date:  Thursday, July 31, 2014 at 2:36 PM
To:  beagleboard@googlegroups.com beagleboard@googlegroups.com
Subject:  Re: [beagleboard] SPi, I2C, GPIO and Qt5 on BBB

 So all that remains is SGX / OGL support too . . . Is this likely ?
Robert¹s build script does do this for you now. Perhaps he will find a way
to simplify the process when he has time. TI still have to add xorg support.
Not sure when that is going to happen.

I think that adding QT5 + Wayland to the BBB repository would be helpful.
Several people are working on this so hopefully something will happen soon.

Regards,
John

 On Thu, Jul 31, 2014 at 1:39 PM, John Syn john3...@gmail.com wrote:

 From:  William Hermans yyrk...@gmail.com
 Reply-To:  beagleboard@googlegroups.com beagleboard@googlegroups.com
 Date:  Tuesday, July 29, 2014 at 12:00 AM
 To:  beagleboard@googlegroups.com beagleboard@googlegroups.com
 Subject:  Re: [beagleboard] SPi, I2C, GPIO and Qt5 on BBB

 Ah right, I was thinking in the context of 3.8.x version. 3.13.x is EOL I
 believe ( meaning end of life )  That appears to be OpenGLES2, but frame
 buffer support only.

 From what I understand, TI made the choice of supporting 3.13.x branch
 with the SGX hardware. capremgr was in 3.8.x, and based on Roberts guide,
 3.15.x has better ethernet, and usb support.

 As for why the branches are done this way ? I'm not a kernel developer so
 I'm not 100% sure. However I could imagine that it is a lot of work setting
 all this up plus scripts / instructions for building etc. I've seen Robert
 say several times patches welcome, so I'm assuming he may not wish to
 duplicate his own work across branches. But this is just speculation on my
 own behalf.

 I'd be willing myself to work on getting capemgr as is working on 3.8.x into
 3.15.x myself. But since I'm fairly inexperienced in this area I'd need
 time, and a mentor ( as in to guide me, not to pay me ).
 Looks like the capemgr functionality will be in V3.17:

 https://lkml.org/lkml/2014/7/27/57

 Regards,
 John

 On Mon, Jul 28, 2014 at 11:18 PM, Cedric Malitte cedric.mali...@gmail.com
 wrote:
 I just followed
 http://eewiki.net/display/linuxonarm/BeagleBone+Black#BeagleBoneBlack-SGX
 for the opengl part, built against v3.13.11-bone12

 Must say I feel lost with all those features appearing and disappearing
 with the kernel releases.

 Le mardi 29 juillet 2014 00:38:32 UTC-4, William Hermans a écrit :
 If you get OpenGLES working on the BBB I'd be interested in how you did
 it. I like to read about geeky things like this ;)  However last I
 remember this was not possible with the way software support is. Hopefully
 that will change if not already.

 On Mon, Jul 28, 2014 at 8:35 PM, Cedric Malitte cedric@gmail.com
 wrote:
 Thanks William,

 I tried to compile kernel 3.13, GFX libraries , all fine.
 Copied all the stuff on a SD card and booted... well, everything here but
 screen ! 

 I need to find how to enable LCD4 cape with new kernel.

 That said, I tried to compile qt4.8.6 with opengl es2 and I have an
 error:
 make[4]: entrant dans le répertoire «
 /home/cedric/qt4-bbb/downloads/qt-everywhere-opensource-src-4.8.6/src/plu
 gins/gfxdrivers/powervr/QWSWSEGL »
 /home/cedric/bb-kernel/dl/gcc-linaro-arm-linux-gnueabihf-4.8-2014.04_linu
 x/bin/arm-linux-gnueabihf-gcc -c -pipe -O3 -march=armv7-a
 -mtune=cortex-a8 -mfpu=neon -mfloat-abi=hard -Wall -W -fPIC
 -DQT_NO_QWS_CURSOR -DQT_QWS_CLIENTBLIT
 -I../../../../../mkspecs/qws/linux-TIarmv7-sgx-g++ -I.
 -I/home/cedric/qt4-bbb/downloads/tslib/src
 -I/home/cedric/bb-kernel/ignore/SDK_BIN/Graphics_SDK_setuplinux_5_01_01_0
 1/GFX_Linux_SDK/OGLES2/SDKPackage/Builds/OGLES2/Include
 -I/home/cedric/bb-kernel/ignore/SDK_BIN/Graphics_SDK_setuplinux_5_01_01_0
 1/GFX_Linux_SDK/OGLES2/SDKPackage/Builds/OGLES2/LinuxOMAP3/Include/
 -I/home/cedric/bb-kernel/ignore/SDK_BIN/Graphics_SDK_setuplinux_5_01_01_0
 1/include 
 -I/home/cedric/bb-kernel/ignore/SDK_BIN/Graphics_SDK_setuplinux_5_01_01_0
 1/GFX_Linux_SDK/OGLES/SDKPackage/Builds/OGLES/Include -o
 .obj/release-shared-emb-arm/pvrqwsdrawable.o pvrqwsdrawable.c
 In file included from pvrqwsdrawable.c:42:0:
 pvrqwsdrawable_p.h:56:19: fatal error: pvr2d.h: Aucun fichier ou dossier
 de ce type
  #include pvr2d.h

 Means no such file, although I have applied patches from
 https://github.com/prabindh/qt-configs/tree/master/qt4.8
 https://github.com/prabindh/qt-configs/tree/master/qt4.8

 Still trying.

 2014-07-27 23:56 GMT-04:00 William Hermans yyr...@gmail.com:
 Cedric, Hi,

 For starters: http://eewiki.net/display/linuxonarm/BeagleBone+Black
 http://eewiki.net/display/linuxonarm/BeagleBone+Black  this is Roberts
 build your own guide.

 http://eewiki.net/display/linuxonarm/BeagleBone+Black#BeagleBoneBlack-Ro
 otFileSystem%28smallflash%29
 http://eewiki.net/display/linuxonarm/BeagleBone+Black#BeagleBoneBlack-R

[beagleboard] [Q] Any project like PiFM, GPIO only FM transmission on BeagleBone Black?

2014-07-31 Thread Sungjin Chun

I'd like to create similar thing like PiFM in BeagleBone Black. Can anyone 
provide me reference on this?

Thanks in advance.

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to 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] SPi, I2C, GPIO and Qt5 on BBB

2014-07-31 Thread Cédric Malitte

Looks like promising.

Yes Qt5 and wayland would be great for devs like me.
Qt without quick is like going steps back

Cédric Malitte

Le 2014-07-31 à 17:46, John Syn john3...@gmail.com a écrit :

From: William Hermans yyrk...@gmail.com
Reply-To: beagleboard@googlegroups.com beagleboard@googlegroups.com
Date: Thursday, July 31, 2014 at 2:36 PM
To: beagleboard@googlegroups.com beagleboard@googlegroups.com
Subject: Re: [beagleboard] SPi, I2C, GPIO and Qt5 on BBB

So all that remains is SGX / OGL support too . . . Is this likely ?
Robert’s build script does do this for you now. Perhaps he will find a way to
simplify the process when he has time. TI still have to add xorg support. Not
sure when that is going to happen.

I think that adding QT5 + Wayland to the BBB repository would be helpful.
Several people are working on this so hopefully something will happen soon.

Regards,
John

On Thu, Jul 31, 2014 at 1:39 PM, John Syn john3...@gmail.com wrote:

From: William Hermans yyrk...@gmail.com
Reply-To: beagleboard@googlegroups.com beagleboard@googlegroups.com
Date: Tuesday, July 29, 2014 at 12:00 AM
To: beagleboard@googlegroups.com beagleboard@googlegroups.com
Subject: Re: [beagleboard] SPi, I2C, GPIO and Qt5 on BBB

Ah right, I was thinking in the context of 3.8.x version. 3.13.x is EOL I
believe ( meaning end of life ) That appears to be OpenGLES2, but frame
buffer support only.

From what I understand, TI made the choice of supporting 3.13.x branch
with the SGX hardware. capremgr was in 3.8.x, and based on Roberts guide,
3.15.x has better ethernet, and usb support.

As for why the branches are done this way ? I'm not a kernel developer so
I'm not 100% sure. However I could imagine that it is a lot of work setting
all this up plus scripts / instructions for building etc. I've seen Robert
say several times patches welcome, so I'm assuming he may not wish to
duplicate his own work across branches. But this is just speculation on my
own behalf.

I'd be willing myself to work on getting capemgr as is working on 3.8.x into
3.15.x myself. But since I'm fairly inexperienced in this area I'd need
time, and a mentor ( as in to guide me, not to pay me ).
Looks like the capemgr functionality will be in V3.17:

https://lkml.org/lkml/2014/7/27/57

Regards,
John

On Mon, Jul 28, 2014 at 11:18 PM, Cedric Malitte cedric.mali...@gmail.com
wrote:
I just followed
http://eewiki.net/display/linuxonarm/BeagleBone+Black#BeagleBoneBlack-SGX
for the opengl part, built against v3.13.11-bone12

Must say I feel lost with all those features appearing and disappearing
with the kernel releases.

Le mardi 29 juillet 2014 00:38:32 UTC-4, William Hermans a écrit :

If you get OpenGLES working on the BBB I'd be interested in how you did
it. I like to read about geeky things like this ;) However last I
remember this was not possible with the way software support is. Hopefully
that will change if not already.

On Mon, Jul 28, 2014 at 8:35 PM, Cedric Malitte cedric@gmail.com
wrote:
Thanks William,

I tried to compile kernel 3.13, GFX libraries , all fine.
Copied all the stuff on a SD card and booted... well, everything here but
screen !

I need to find how to enable LCD4 cape with new kernel.

That said, I tried to compile qt4.8.6 with opengl es2 and I have an error:
make[4]: entrant dans le répertoire «
/home/cedric/qt4-bbb/downloads/qt-everywhere-opensource-src-4.8.6/src/plugins/gfxdrivers/powervr/QWSWSEGL
»
/home/cedric/bb-kernel/dl/gcc-linaro-arm-linux-gnueabihf-4.8-2014.04_linux/bin/arm-linux-gnueabihf-gcc
-c -pipe -O3 -march=armv7-a -mtune=cortex-a8 -mfpu=neon -mfloat-abi=hard
-Wall -W -fPIC -DQT_NO_QWS_CURSOR -DQT_QWS_CLIENTBLIT
-I../../../../../mkspecs/qws/linux-TIarmv7-sgx-g++ -I.
-I/home/cedric/qt4-bbb/downloads/tslib/src
-I/home/cedric/bb-kernel/ignore/SDK_BIN/Graphics_SDK_setuplinux_5_01_01_01/GFX_Linux_SDK/OGLES2/SDKPackage/Builds/OGLES2/Include

-I/home/cedric/bb-kernel/ignore/SDK_BIN/Graphics_SDK_setuplinux_5_01_01_01/GFX_Linux_SDK/OGLES2/SDKPackage/Builds/OGLES2/LinuxOMAP3/Include/

-I/home/cedric/bb-kernel/ignore/SDK_BIN/Graphics_SDK_setuplinux_5_01_01_01/include

-I/home/cedric/bb-kernel/ignore/SDK_BIN/Graphics_SDK_setuplinux_5_01_01_01/GFX_Linux_SDK/OGLES/SDKPackage/Builds/OGLES/Include
-o .obj/release-shared-emb-arm/pvrqwsdrawable.o pvrqwsdrawable.c
In file included from pvrqwsdrawable.c:42:0:
pvrqwsdrawable_p.h:56:19: fatal error: pvr2d.h: Aucun fichier ou dossier
de ce type
#include pvr2d.h

Means no such file, although I have applied patches from
https://github.com/prabindh/qt-configs/tree/master/qt4.8

Still trying.

2014-07-27 23:56 GMT-04:00 William Hermans yyr...@gmail.com:
Cedric, Hi,

For starters: http://eewiki.net/display/linuxonarm/BeagleBone+Black this
is Roberts build your own guide.

[beagleboard] Re: ALSA program for capture and play audio file

2014-07-31 Thread Jesse Forgues

Stumbled upon this thread while trying to write an ALSA audio envelope to 
run on a BeagleBone Black.

Mark do you have a valid link for your work? This has gone the way of the 
404... http://www.rose-hulman.edu/~yoder/Beagle/AudioThru.tar.bz2

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to 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] [Q] Any project like PiFM, GPIO only FM transmission on BeagleBone Black?

Its impossible .
bcm2835 have flex pwm and dma transfer for fm turning .
while am335x pwm is only for fixed clock div .


2014-08-01 6:34 GMT+08:00 Sungjin Chun chu...@gmail.com:

 I'd like to create similar thing like PiFM in BeagleBone Black. Can anyone
 provide me reference on this?

 Thanks in advance.

 --
 For more options, visit http://beagleboard.org/discuss
 ---
 You received this message because you are subscribed to 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] [Q] Any project like PiFM, GPIO only FM transmission on BeagleBone Black?

2014-07-31 Thread Sungjin Chun

Oh, sad.. thank you for kind and detailed explanation :-)


On Fri, Aug 1, 2014 at 10:21 AM, liyaoshi liyao...@gmail.com wrote:

 Its impossible .
 bcm2835 have flex pwm and dma transfer for fm turning .
 while am335x pwm is only for fixed clock div .


 2014-08-01 6:34 GMT+08:00 Sungjin Chun chu...@gmail.com:

 I'd like to create similar thing like PiFM in BeagleBone Black. Can
 anyone provide me reference on this?

 Thanks in advance.

 --
 For more options, visit http://beagleboard.org/discuss
 ---
 You received this message because you are subscribed to 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] SPi, I2C, GPIO and Qt5 on BBB

I have made a demo on iMX6

https://www.dropbox.com/s/ltnedy59gv5i70j/VID_20140723_084207.mp4


2014-08-01 6:45 GMT+08:00 Cédric Malitte cedric.mali...@gmail.com:

 Looks like promising.

 Yes Qt5 and wayland would be great for devs like me.
 Qt without quick is like going steps back

 Cédric Malitte

 Le 2014-07-31 à 17:46, John Syn john3...@gmail.com a écrit :


 From: William Hermans yyrk...@gmail.com
 Reply-To: beagleboard@googlegroups.com beagleboard@googlegroups.com
 Date: Thursday, July 31, 2014 at 2:36 PM
 To: beagleboard@googlegroups.com beagleboard@googlegroups.com
 Subject: Re: [beagleboard] SPi, I2C, GPIO and Qt5 on BBB

 So all that remains is SGX / OGL support too . . . Is this likely ?

 Robert’s build script does do this for you now. Perhaps he will find a way
 to simplify the process when he has time. TI still have to add xorg
 support. Not sure when that is going to happen.

 I think that adding QT5 + Wayland to the BBB repository would be helpful.
 Several people are working on this so hopefully something will happen soon.

 Regards,
 John




 On Thu, Jul 31, 2014 at 1:39 PM, John Syn john3...@gmail.com wrote:


 From: William Hermans yyrk...@gmail.com
 Reply-To: beagleboard@googlegroups.com beagleboard@googlegroups.com
 Date: Tuesday, July 29, 2014 at 12:00 AM
 To: beagleboard@googlegroups.com beagleboard@googlegroups.com
 Subject: Re: [beagleboard] SPi, I2C, GPIO and Qt5 on BBB

 Ah right, I was thinking in the context of 3.8.x version. 3.13.x is EOL I
 believe ( meaning end of life )  That appears to be OpenGLES2, but frame
 buffer support only.

 From what I understand, TI made the choice of supporting 3.13.x branch
 with the SGX hardware. capremgr was in 3.8.x, and based on Roberts guide,
 3.15.x has better ethernet, and usb support.

 As for why the branches are done this way ? I'm not a kernel developer so
 I'm not 100% sure. However I could imagine that it is a lot of work setting
 all this up plus scripts / instructions for building etc. I've seen Robert
 say several times patches welcome, so I'm assuming he may not wish to
 duplicate his own work across branches. But this is just speculation on my
 own behalf.

 I'd be willing myself to work on getting capemgr as is working on 3.8.x
 into 3.15.x myself. But since I'm fairly inexperienced in this area I'd
 need time, and a mentor ( as in to guide me, not to pay me ).

 Looks like the capemgr functionality will be in V3.17:

 https://lkml.org/lkml/2014/7/27/57

 Regards,
 John




 On Mon, Jul 28, 2014 at 11:18 PM, Cedric Malitte 
 cedric.mali...@gmail.com wrote:

 I just followed
 http://eewiki.net/display/linuxonarm/BeagleBone+Black#BeagleBoneBlack-SGX 
 for
 the opengl part, built against v3.13.11-bone12

 Must say I feel lost with all those features appearing and disappearing
 with the kernel releases.

 Le mardi 29 juillet 2014 00:38:32 UTC-4, William Hermans a écrit :

 If you get OpenGLES working on the BBB I'd be interested in how you did
 it. I like to read about geeky things like this ;)  However last I remember
 this was not possible with the way software support is. Hopefully that will
 change if not already.


 On Mon, Jul 28, 2014 at 8:35 PM, Cedric Malitte cedric@gmail.com
 wrote:

 Thanks William,

 I tried to compile kernel 3.13, GFX libraries , all fine.
 Copied all the stuff on a SD card and booted... well, everything here
 but screen !

 I need to find how to enable LCD4 cape with new kernel.

 That said, I tried to compile qt4.8.6 with opengl es2 and I have an
 error:
 make[4]: entrant dans le répertoire « /home/cedric/qt4-bbb/
 downloads/qt-everywhere-opensource-src-4.8.6/src/
 plugins/gfxdrivers/powervr/QWSWSEGL »
 /home/cedric/bb-kernel/dl/gcc-linaro-arm-linux-gnueabihf-4.
 8-2014.04_linux/bin/arm-linux-gnueabihf-gcc -c -pipe -O3
 -march=armv7-a -mtune=cortex-a8 -mfpu=neon -mfloat-abi=hard -Wall -W -fPIC
 -DQT_NO_QWS_CURSOR -DQT_QWS_CLIENTBLIT 
 -I../../../../../mkspecs/qws/linux-TIarmv7-sgx-g++
 -I. -I/home/cedric/qt4-bbb/downloads/tslib/src
 -I/home/cedric/bb-kernel/ignore/SDK_BIN/Graphics_SDK_
 setuplinux_5_01_01_01/GFX_Linux_SDK/OGLES2/SDKPackage/Builds/OGLES2/Include
 -I/home/cedric/bb-kernel/ignore/SDK_BIN/Graphics_SDK_
 setuplinux_5_01_01_01/GFX_Linux_SDK/OGLES2/SDKPackage/
 Builds/OGLES2/LinuxOMAP3/Include/ -I/home/cedric/bb-kernel/
 ignore/SDK_BIN/Graphics_SDK_setuplinux_5_01_01_01/include
 -I/home/cedric/bb-kernel/ignore/SDK_BIN/Graphics_SDK_
 setuplinux_5_01_01_01/GFX_Linux_SDK/OGLES/SDKPackage/Builds/OGLES/Include
 -o .obj/release-shared-emb-arm/pvrqwsdrawable.o pvrqwsdrawable.c
 In file included from pvrqwsdrawable.c:42:0:
 pvrqwsdrawable_p.h:56:19: fatal error: pvr2d.h: Aucun fichier ou
 dossier de ce type
  #include pvr2d.h

 Means no such file, although I have applied patches from
 https://github.com/prabindh/qt-configs/tree/master/qt4.8

 Still trying.



 2014-07-27 23:56 GMT-04:00 William Hermans yyr...@gmail.com:

 Cedric, Hi,

 For starters:

Re: [beagleboard] androidvncserver disables software keyboard

busybox killall -9 android-vncserver ?

But root your phone first


2014-07-31 21:13 GMT+08:00 Efecan Yilmaz yilmaz.efeca...@gmail.com:

 Hi,

 I'm using adb shell to start vnc server:

 androidvncserver

 But after then my software keyboard gets disabled. So is there a way to
 prevent this. Or can I stop android vnc server??

 --
 For more options, visit http://beagleboard.org/discuss
 ---
 You received this message because you are subscribed to 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] wifi ap with debian and Adafruit usb dongle