Re: [beagleboard] Cross Toolchain for Debian Wheezy

[halherta]

Robert,
Can't we simply use one of the Linaro cross compiling toolchains to 
cross-compile for a Debian based BBB installation?
Does this mean we absolutely must run Wheezy on our PC to be able to 
cross-compile for the BBB with a Debian image.?

Thanks Hussam.

On Wednesday, May 28, 2014 4:57:37 AM UTC-4, family...@googlemail.com wrote:
>
> Back again!
>
> I your script did run a while on my machine, now I have some .deb packages 
> in the ./deploy folder.
> (I'm using my debian wheezy 32Bit vm (Linux debian-wheezy-vm 3.2.0-4-486 
> #1 Debian 3.2.51-1 i686 GNU/Linux)
>
> As far as I could see the script did run without problems.
>
> Binutils and some other stuff already did get installed to my /usr/bin 
> folder.
> g++ is not installed.
> As far as I understand your script as a linux novice it should have been 
> installed by some call to dpkg_cross.
>
> I already tried to manually install all the .deb packages from deploy 
> folder with 
> dpkg -i xzz.deb -force
> but this is failing because of dependency problems.
>
> Two questions:
> 1. Is there a possibility to specify a prefix for the whole toolchain? 
> (like angstrom toolchain has /usr/local/angstrom)
> 2. how to install the .deb packages 
>
> Regards,
> Ben
> Am Dienstag, 27. Mai 2014 17:05:55 UTC+2 schrieb RobertCNelson:
>>
>> On Tue, May 27, 2014 at 9:48 AM, Robert Nelson  
>> wrote: 
>> > On Tue, May 27, 2014 at 3:35 AM,   wrote: 
>> >> Hi, I'm having trouble in finding a gcc cross toolchain for BBB. 
>> >> 
>> >> I'm using the latest debian image for BBB from 
>> >> beagleboard.org/latest-images. 
>> >> 
>> >> As host I have a debian wheezy VM. now I'm looking for some days to 
>> find a 
>> >> way to compile my project for the debian version. 
>> >> (I already had it working on angstrom, but now as you move on t debian 
>> I 
>> >> need to port my code to debian) 
>> >> 
>> >> I already tried emdebian.org 
>> >> (https://wiki.debian.org/EmdebianToolchain#Get_the_binaries) but got 
>> stuck 
>> >> anywhere. (Can't remember where) 
>> >> I tried miltiarch support from 
>> >> 
>> https://wiki.debian.org/MultiarchCrossToolchainBuild?action=show&redirect=MultiarchCrossToolchains
>>  
>> >> but this doesn't work. 
>> >> 
>> >> Has anybody a working toolchain for 32bit debian wheezy as tar.gz 
>> file. 
>> >> 
>> >> I'm stuck, please help. 
>> > 
>> > Well, i posted 64 bit test versions here: 
>> > http://rcn-ee.net/deb/cross/test/ 
>> > 
>> > The script to generate them should run fine for 32 bit. 
>> > 
>> > 
>> https://github.com/RobertCNelson/cross-compiler/blob/master/build-wheezy-compiler.sh
>>  
>> > 
>> > Just make sure you build it in a 100% Debian Wheezy distro (no 
>> > testing/sid/etc), and we "might" have to bump some of the file 
>> > versions as it was a month or ago that i wrote it. 
>>
>> Yeap, new tzdata and linux-libc-dev versions in stable, so i just pushed 
>> a bump: 
>>
>>
>> https://github.com/RobertCNelson/cross-compiler/commit/1eae13c2948ba548a98aef0585ad6bcc26d1ddd9
>>  
>>
>> Regards, 
>>
>> -- 
>> Robert Nelson 
>> http://www.rcn-ee.com/ 
>>
>

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

[beagleboard] Re: Enabling the ADC on the 3.8 BBB Kernel without the cape manager

[halherta]

Figured it out

To enable the ADC in the global device tree file (am335x-boneblack.dts) I 
needed to replace this:

 713 tscadc@44e0d000 {
 714 compatible = "ti,ti-tscadc";
 715 reg = <0x44e0d000 0x1000>;
 716 interrupt-parent = <0x1>;
 717 interrupts = <0x10>;
 718 ti,hwmods = "adc_tsc";
 719 status = "disabled";
 720 linux,phandle = <0x3d>;
 721 phandle = <0x3d>;
 722 };

with this:

 713 tscadc@44e0d000 {
 714 compatible = "ti,ti-tscadc";
 715 reg = <0x44e0d000 0x1000>;
 716 interrupt-parent = <0x1>;
 717 interrupts = <0x10>;
 718 ti,hwmods = "adc_tsc";
 719 status = "okay";
 720 linux,phandle = <0x3d>;
 721 phandle = <0x3d>;
 722 
 723 adc{
 724 ti,adc-channels = <0 1 2 3 4 5 6 7>;
 725 };
 726 };

basically enable the tsadc peripheral (status = "okay") and add an adc 
section listing all channels to be used.



On Sunday, May 25, 2014 7:48:22 PM UTC-4, halh...@gmail.com wrote:
>
> Hello all,
> I'm trying to get in the habit of enabling all the hardware that I need on 
> the beaglebone black via modifying the main device tree 
> file am335x-boneblack.dts which I derive with the dtc from the 
> am335x-boneblack.dtb file available under /boot/dtbs or /boot/uboot/dtbs in 
> a Debian installation. I'm specifically trying to avoid device tree 
> overlays and using the cape manager altogether. I've had success with 
>  GPIO, SPI, I2C, UART and PWM but I'm unable to get this to work for the 
> ADC. 
>
> In the am335x-boneblack.dts file the only section that relates to the ADC 
> is:
>
>
>  713 tscadc@44e0d000 {
>  714 compatible = "ti,ti-tscadc";
>  715 reg = <0x44e0d000 0x1000>;
>  716 interrupt-parent = <0x1>;
>  717 interrupts = <0x10>;
>  718 ti,hwmods = "adc_tsc";
>  719 status = "disabled";
>  720 linux,phandle = <0x3d>;
>  721 phandle = <0x3d>;
>  722 };
>
> For some insight I took a peak at the BB-ADC-00A0.dts (again created from 
> the BB-ADC-00A0.dtb file in /lib/firmware via the dtc)
>
>   1 /dts-v1/;
>   2 
>   3 / {
>   4 compatible = "ti,beaglebone", "ti,beaglebone-black";
>   5 part-number = "BB-ADC";
>   6 exclusive-use = "P9.39", "P9.40", "P9.37", "P9.38", "P9.33", 
> "P9.36", "P9.35", "tscadc";
>   7 
>   8 fragment@0 {
>   9 target = <0xdeadbeef>;
>  10 
>  11 __overlay__ {
>  12 #address-cells = <0x1>;
>  13 #size-cells = <0x1>;
>  14 
>  15 tscadc {
>  16 compatible = "ti,ti-tscadc";
>  17 reg = <0x44e0d000 0x1000>;
>  18 interrupt-parent = <0xdeadbeef>;
>  19 interrupts = <0x10>;
>  20 ti,hwmods = "adc_tsc";
>  21 status = "okay";
>  22 
>  23 adc {
>  24 ti,adc-channels = <0x0 0x1 0x2 0x3 0x4 0x5 0x6 
> 0x7>;
>  25 };
>  26 };
>  27 
>  28 helper {
>  29 compatible = "bone-iio-helper";
>  30 vsense-name = "AIN0", "AIN1", "AIN2", "AIN3", "AIN4", 
> "AIN5", "AIN6", "AIN7";
>  31 vsense-scale = <0x64 0x64 0x64 0x64 0x64 0x64 0x64 
> 0x64>;
>  32 status = "okay";
>  33 linux,phandle = <0x1>;
>  34 phandle = <0x1>;
>  35 };
>  36 };
>  37 };
>
> In additions to enabling the tscadc section and adding an adc section 
> within the tscadc section, the ADC device overlay seems to create a 
> 'helper' section with the 'bone-iio-helper' driver. What exactly is the 
> purpose of this section?  I'm having trouble integrating this section 
> directly into the main am335x-boneblack.dtb file. Any ideas on how to do 
> this or enable the adc in the main device tree file in general, would be 
> highly appreciated.
>
> Hussam
>
>
>
>

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to 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] Enabling the ADC on the 3.8 BBB Kernel without the cape manager

[halherta]

Hello all,
I'm trying to get in the habit of enabling all the hardware that I need on 
the beaglebone black via modifying the main device tree 
file am335x-boneblack.dts which I derive with the dtc from the 
am335x-boneblack.dtb file available under /boot/dtbs or /boot/uboot/dtbs in 
a Debian installation. I'm specifically trying to avoid device tree 
overlays and using the cape manager altogether. I've had success with 
 GPIO, SPI, I2C, UART and PWM but I'm unable to get this to work for the 
ADC. 

In the am335x-boneblack.dts file the only section that relates to the ADC 
is:


 713 tscadc@44e0d000 {
 714 compatible = "ti,ti-tscadc";
 715 reg = <0x44e0d000 0x1000>;
 716 interrupt-parent = <0x1>;
 717 interrupts = <0x10>;
 718 ti,hwmods = "adc_tsc";
 719 status = "disabled";
 720 linux,phandle = <0x3d>;
 721 phandle = <0x3d>;
 722 };

For some insight I took a peak at the BB-ADC-00A0.dts (again created from 
the BB-ADC-00A0.dtb file in /lib/firmware via the dtc)

  1 /dts-v1/;
  2 
  3 / {
  4 compatible = "ti,beaglebone", "ti,beaglebone-black";
  5 part-number = "BB-ADC";
  6 exclusive-use = "P9.39", "P9.40", "P9.37", "P9.38", "P9.33", 
"P9.36", "P9.35", "tscadc";
  7 
  8 fragment@0 {
  9 target = <0xdeadbeef>;
 10 
 11 __overlay__ {
 12 #address-cells = <0x1>;
 13 #size-cells = <0x1>;
 14 
 15 tscadc {
 16 compatible = "ti,ti-tscadc";
 17 reg = <0x44e0d000 0x1000>;
 18 interrupt-parent = <0xdeadbeef>;
 19 interrupts = <0x10>;
 20 ti,hwmods = "adc_tsc";
 21 status = "okay";
 22 
 23 adc {
 24 ti,adc-channels = <0x0 0x1 0x2 0x3 0x4 0x5 0x6 0x7>;
 25 };
 26 };
 27 
 28 helper {
 29 compatible = "bone-iio-helper";
 30 vsense-name = "AIN0", "AIN1", "AIN2", "AIN3", "AIN4", 
"AIN5", "AIN6", "AIN7";
 31 vsense-scale = <0x64 0x64 0x64 0x64 0x64 0x64 0x64 
0x64>;
 32 status = "okay";
 33 linux,phandle = <0x1>;
 34 phandle = <0x1>;
 35 };
 36 };
 37 };

In additions to enabling the tscadc section and adding an adc section 
within the tscadc section, the ADC device overlay seems to create a 
'helper' section with the 'bone-iio-helper' driver. What exactly is the 
purpose of this section?  I'm having trouble integrating this section 
directly into the main am335x-boneblack.dtb file. Any ideas on how to do 
this or enable the adc in the main device tree file in general, would be 
highly appreciated.

Hussam



-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to 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: Problem getting WIFI + PWM + PYTHON/PYGAME working on the same distro.

[halherta]

Vitor last time I checked (early April) The default device tree  that comes 
with the 3.13 kernel registered 3 PWM channels on P9_14, P9_16 (ehprwm1a&b) 
& P9_42 (ecap0). But when i took a peek at the contents of the "/sys/devices
/ocp.#/pwm_test_P9_14.#/" directory I do not see the 'period', 'duty', 
'run' or 'polarity' files needed to control the PWM channels. Its been 2 
months since I checked so it might be worth having a look at it again at 
this point...

As root, 'cd' & 'ls' into "/sys/devices/ocp.#/pwm_test_P9_14.#/", "/sys/
devices/ocp.#/pwm_test_P9_16.#/" and "/sys/devices/ocp.#/pwm_test_P9_42.#/" 
do you see 'period', 'duty' files ? if so then  PWM is supportedbut I 
highly doubt it

I very much prefer the approach of editing the device tree file directly 
instead of using the cape manager or even device tree overlays. It's more 
complicated to pick up, but is portable across kernel versions. The cape 
manager is hard to support across kernel versions and is probably the main 
reason why BBB users stick with the 3.8 Kernel. 

 

On Tuesday, May 6, 2014 3:18:02 PM UTC-4, vitor de miranda henrique wrote:
>
> Thanks Robert! 
>
> I'll take a look on the power management as soon as i get back home.
>
> For the 3.13 i guess i wont be able to use adafruit python library on the 
> new kernel right? 
>
> Vitor Henrique
>
> Em terça-feira, 6 de maio de 2014 13h49min22s UTC-5, RobertCNelson 
> escreveu:
>>
>> On Tue, May 6, 2014 at 1:42 PM, vitor de miranda henrique 
>>  wrote: 
>> > I'll try to disable power management, already used usb powered hub and 
>> a 
>> > extension cable without success. 
>>
>>  /sbin/iwconfig wlan0 power off 
>>
>> > And i could not get the PWM working on 3.13. Do i need to compile it 
>> with a 
>> > special module? 
>>
>> First, "capemgr" hasn't been ported past v3.8. So what you did in v3.8 
>> will not work in v3.13/v3.14. That said in v3.13/v3.14 i did enable 
>> the pwm used by the "proto-cape" 
>> http://elinux.org/CircuitCo:Basic_Proto_Cape 
>>
>> I have no idea if they work in v3.13/v3.14.. 
>>
>> Regards, 
>>
>> -- 
>> Robert Nelson 
>> http://www.rcn-ee.com/ 
>>
>

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

Re: [beagleboard] Re: PWM in the 3.13 Kernel

[halherta]

Thanks  Sungjin!
I'll take a look a your codeI'm still curious as to what exactly 
happened to the pwm sysfs interface in the 3.13 kernel though. If anyone 
knows please let me/us know

Thanks!

On Friday, April 18, 2014 8:48:12 AM UTC-4, Sungjin Chun wrote:
>
> If properly enabled in dtb file during booting, you can always use any 
> peripherals in AM335X SoC.
> Refer https://github.com/chunsj/nxctrl/blob/master/pwm-test.c, which uses 
> /dev/mem for control
> pwm. Of course this code does not provide sysfs interface.
>
> Sent from my iPad
>
> On Apr 18, 2014, at 9:12 PM, halh...@gmail.com  wrote:
>
> I retried accessing PWM in the latest 3.13 kernel.with no luck. Is PWM 
> still not supported in 3.13 (under /sys/devices/ocp.#/pwm_test_P9_14.#/) 
> or is there simply a new way to access PWM that I'm not aware of ?
>
> Hussam
>
> On Tuesday, March 25, 2014 5:29:03 PM UTC-4, halh...@gmail.com wrote:
>>
>> I'm having problems with PWM under the latest 3.13 kernel (built as per 
>> the instructions provided @ 
>> http://www.eewiki.net/display/linuxonarm/BeagleBone+Black) with a Debian 
>> root filesystem.The Device tree seems to support 3 PWM channels on P9_14, 
>> P9_16 (ehprwm1a&b) & P9_42 (ecap0). But when i take a peek at the 
>> contents of the "/sys/devices/ocp.#/pwm_test_P9_14.#/" directory I do 
>> not see the 'period', 'duty', 'run' or 'polarity' files needed to control 
>> the PWM channels.
>>
>> Is PWM supported in the 3.13 Kernel yet? 
>>
>> Thanks!
>> Hussam
>>
>  -- 
> For more options, visit http://beagleboard.org/discuss
> --- 
> You received this message because you 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.

[beagleboard] Re: PWM in the 3.13 Kernel

[halherta]

I retried accessing PWM in the latest 3.13 kernel.with no luck. Is PWM 
still not supported in 3.13 (under /sys/devices/ocp.#/pwm_test_P9_14.#/) or 
is there simply a new way to access PWM that I'm not aware of ?

Hussam

On Tuesday, March 25, 2014 5:29:03 PM UTC-4, halh...@gmail.com wrote:
>
> I'm having problems with PWM under the latest 3.13 kernel (built as per 
> the instructions provided @ 
> http://www.eewiki.net/display/linuxonarm/BeagleBone+Black) with a Debian 
> root filesystem.The Device tree seems to support 3 PWM channels on P9_14, 
> P9_16 (ehprwm1a&b) & P9_42 (ecap0). But when i take a peek at the 
> contents of the "/sys/devices/ocp.#/pwm_test_P9_14.#/" directory I do not 
> see the 'period', 'duty', 'run' or 'polarity' files needed to control the 
> PWM channels.
>
> Is PWM supported in the 3.13 Kernel yet? 
>
> Thanks!
> Hussam
>

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to 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] Is it possible to configure a GPIO for both input and output in the Device Tree Overlay

[halherta]

Hello all,
I was wondering if it's possible to configure a GPIO pin on the Beaglebone 
black as a bidirectional GPIO via device tree overlays. Essentially 
allowing the developer to control the pins direction via the 
/sys/class/gpio/gpioxx/direction file in sysfs.

A close look at the pinmux table/registers in the TRM reveals that setting 
bit 5 enables the receiver (input) and clearing bit 5 disables the receiver 
(input). If I enable the receiver can I use the GPIO pin as both input and 
output or would it have to be input only ?

And if that isn't possible is there any other way to use the GPIO pins 
bidirectionally without having to dynamically load device tree overlays 
every time we need to change the direction of a GPIO ?

 
Thanks!  
Hussam

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to 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] Disable autologin and lightdm on the BeagleBoard.org Latest Debian Firmware Image

[halherta]

Hello,
I lately decided to install the latest BeagleBoard.org Debian FIrmware 
image on the Beaglebone Black (MicroSD version). When the image boots it 
automatically logs into LXDE. I'd like to disable autologin and have the 
BBB boot to the command line; with the option of starting LXDE later as 
needed with the startLXDE command. What do I have to do to make these 
modifications?

Regards,
Hussam   

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to 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: Help with Cross Compile of first HelloWorld App

[halherta]

RV9Flyer,
the arm-none-eabi-gcc cross-compiler is in my humble understanding intended 
for use with' bare-metal' 'non-mmu' 'sans Linux' ARM 
microcontrollers..specifically the Cortex-R/Cortex-M cores.

You need to use a different toolchain for Linux-based, MMU-based Cortex-A 
setups such as that of the beaglebone black. typically the cross-compiler 
toolchain that you should use should be called  arm-linux-gnueabiXX-gcc. 
I'm not sure where you can get such a toolchain for angstromyou could 
probably build it with openembedded/yocto.

Hussam


On Wednesday, April 9, 2014 7:20:47 PM UTC-4, RV9Flyer wrote:
>
> I'm a newbie and this is my first post.
>
> I just got started with building my first HelloWorld style app to test the 
> cross-compile capabilities of Eclipse/CDT, The app compiles successfully 
> and generate the expected HelloBeagle.elf executable. However, when I 
> transfer it to my beagle and attempt to run, I get an "Illegal instruction" 
> error. 
>
> I've watched every video I could find (Thanks Derek Malloy) and I still 
> can't find the reason for the error. Obviously it's not generating the 
> right code base, but the build output does show that it it aimed for the 
> cortex-a8 processor which I believe is correct for the beaglebone black.  
>
> I would appreciate any suggestions or ideas!!
>
> Thanks
>
> *Here is my environment info and build output:*
>
> *Build Environment:*
> Windows 7
> Eclipse Kepler SR2
> CDT 
> GNU ARM Eclipse Plug-in
> MinGW
>
> *Beaglebone Black:* (Angstrom Distro)
> Linux beaglebone 3.8.13 #1 SMP Wed Sep 4 09:09:32 CEST 2013 armv7l 
> GNU/Linux
>
> *Build output:*
> 16:11:12  Build of configuration Debug for project HelloBeagle 
> make pre-build main-build 
> arm-none-eabi-gcc --version
> arm-none-eabi-gcc.exe (GNU Tools for ARM Embedded Processors) 4.8.3 
> 20140228 (release) [ARM/embedded-4_8-branch revision 208322]
> Copyright (C) 2013 Free Software Foundation, Inc.
> This is free software; see the source for copying conditions.  There is NO
> warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
>
>  
> Building file: ../src/HelloBeagle.cpp
> Invoking: Cross ARM C++ Compiler
> arm-none-eabi-g++ -mcpu=cortex-a8 -O0 -fmessage-length=0 -fsigned-char 
> -ffunction-sections -fdata-sections -Wall  -g3 -MMD -MP 
> -MF"src/HelloBeagle.d" -MT"src/HelloBeagle.d" -c -o "src/HelloBeagle.o" 
> "../src/HelloBeagle.cpp"
> Finished building: ../src/HelloBeagle.cpp
>  
> Building target: HelloBeagle.elf
> Invoking: Cross ARM C++ Linker
> arm-none-eabi-g++ -mcpu=cortex-a8 -O0 -fmessage-length=0 -fsigned-char 
> -ffunction-sections -fdata-sections -Wall  -g3 -Xlinker --gc-sections 
> -Wl,-Map,"HelloBeagle.map" --specs=rdimon.specs -Wl,--start-group -lgcc -lc 
> -lc -lm -lrdimon -Wl,--end-group -o "HelloBeagle.elf"  ./src/HelloBeagle.o 
>   
> Finished building target: HelloBeagle.elf
>  
> Invoking: Cross ARM GNU Create Flash Image
> arm-none-eabi-objcopy -O ihex "HelloBeagle.elf"  "HelloBeagle.hex"
> Finished building: HelloBeagle.hex
>  
> Invoking: Cross ARM GNU Print Size
> arm-none-eabi-size --format=berkeley "HelloBeagle.elf"
>text   databssdechex filename
>  211304   2732   7776 221812  36274 HelloBeagle.elf
> Finished building: HelloBeagle.siz
>  
>
> 16:11:28 Build Finished (took 16s.236ms)
>
>
>

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to 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: Finally : did someone succeeded to have a Qt GUI app ?

[halherta]

David, 
 Put "export DISPLAY=:0.0" in the /etc/profile, reboot and start X11 i.e 
lightdm/or LXDE. then try running the qt app binary again. I will retry 
this again myself and report back. 

Hussam

On Tuesday, April 8, 2014 11:26:34 AM UTC-4, dlewin555 wrote:
>
> Hi,
>
> Is there finally someone who succeeded to have a GUI compiled with Qt 
> (from Debian for example ) ?
>
> I've tested many things, and they either rely on Angstrom (which I'd like 
> to avoid) or don't work at all (Timesys included)
>
> So I'm looking for a successful try ...
>

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to 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: Finally : did someone succeeded to have a Qt GUI app ?

[halherta]

dlewin,

Assuming you have LXDE & X installed under Debian you can install qt4 with 
apt-get: "sudo apt-get install libqt4-dev". For a more comprehensive QT4 
install including qtCreator (natively on the BBB) try  "sudo apt-get 
install qt-sdk". To build a QT app from the command line, create a 
directory..add  source code for your project in that directory, cd into the 
directory then run:
 i) "qmake -project"  (create .pro file), 
ii) "qmake" (create makefile) and finally 
iii) "make" ("build qt app)

You can also try Qtcreator natively on the RPiit may be a little laggy 
though
 

On Tuesday, April 8, 2014 11:26:34 AM UTC-4, dlewin555 wrote:
>
> Hi,
>
> Is there finally someone who succeeded to have a GUI compiled with Qt 
> (from Debian for example ) ?
>
> I've tested many things, and they either rely on Angstrom (which I'd like 
> to avoid) or don't work at all (Timesys included)
>
> So I'm looking for a successful try ...
>

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

[halherta]

I'm having problems with PWM under the latest 3.13 kernel (built as per the 
instructions provided @ 
http://www.eewiki.net/display/linuxonarm/BeagleBone+Black) with a Debian 
root filesystem.The Device tree seems to support 3 PWM channels on P9_14, 
P9_16 (ehprwm1a&b) & P9_42 (ecap0). But when i take a peek at the contents 
of the "/sys/devices/ocp.#/pwm_test_P9_14.#/" directory I do not see the 
'period', 'duty', 'run' or 'polarity' files needed to control the PWM 
channels.

Is PWM supported in the 3.13 Kernel yet? 

Thanks!
Hussam

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to 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: Understanding i2c on BBB: a different approach : help needed

[halherta]

Ritu, have a look at Free Electron's Embedded Linux kernel and driver 
development training materials 
http://free-electrons.com/doc/training/linux-kernel/ They demonstrate step 
by step how to write an I2C driver under Linux for the beaglebone. 

Frankly I've given up on learning Linux device driversI just use 
userspace interfaces i2cdev/spidev/sysfs e.t.c

Hussam

On Tuesday, February 11, 2014 2:35:56 PM UTC-5, Ritu Sharma wrote:
>
> Hi All,
>
> I'm an experienced rtos driver developer but new to linux i2c subsystem :)
>
> For quite some time I was trying to learn i2c subsystem by looking at 
> sources... but may be its way too much for me to understand the 
> terminologies : bus driver/adapters/clients... I keep confusing between 
> them... which is i2c controller driver out of them... what are adapters 
> so on and so forth.
>
> I decided to work on it practically and understand it completely for once 
> and all ofcourse with community support.
> Below is the plan I have for this:
>
> 1. remove i2c support from BBB kernel sources
> 2. add one by one after understanding what is being added
> 3. final aim is to make one RTC and eeprom over i2c to work with BBB
>
> For step 1, I would be grateful if some one could tells us what files I 
> need to remove and what those files do an outline.
>
> I think this sort of understanding many newbies in kernel would like to 
> have. I call upon them to add on this thread with related info.
>
> Cheers
> Ritu  
>
>

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

[halherta]

Dorian, 

I haven't tried any of these myself but I see no reason why they shouldn't 
work. 

   - you could use a fork to create a child process. In this child process 
   use the poll()/select() calls to detect a change in the edge file. When 
   this happens a variable could be incremented  and piped back to the parent 
   process. 
   - You could use threads...i.e. a thread calls poll()/select() to detect 
   a change in the edge file and then updates a counts variables.with 
   threads all threads share the variables so this will be easier. but could 
   be more convoluted.
   - You could try monitoring the edge file with GDK/GTK libs monitoring 
   I/O calls https://developer.gnome.org/gtk-tutorial/2.90/x1770.html. Qt has 
   a QIODevice class that does the same thing.
   - You could also attach the SIGIO signal to the file descriptor for the 
   edge file and write a signal handler that increments a variable...though 
   Linux purists do not recommend this 

Hussam


On Saturday, February 22, 2014 1:41:02 PM UTC-5, Dorian Levy wrote:
>
> I want to use a hall effect motor encoder to determine the number of 
> revolutions of a wheel. Using the BB-KEYS I am able to set 
> up /dev/inputs/event1 that captures the event and records the number of 
> interrupts in /proc/interrupts. I believe setting 
> /sys/class/gpio/gpioxx/edge will do pretty much the same. I haven't been 
> able to figure out how to count them in a C/C++ code. Is it bes to set up 
> an interrupt and count or try to read the /proc/interrupt file? Polling is 
> not an option because there are two wheel that need to be counted. I would 
> prefer to have and ISR that counts each time it is triggered, but I have 
> not been able to figure out how to set it up. Any help would be greatly 
> appreciated since I have spent the last few days trying to research this 
> without much luck. 
>
> Thanks,
> Dorian 
>

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

[beagleboard] Kernel 3.13 & Capemgr alternatives

[halherta]

OK I'm still somewhat new to using the I/O interfaces on the 
BeagleboneBlack. I'm currently interested  in utilizing the 3.13 Kernel. I 
realize that there is no capemgr  for the newer kernel.


   - Is there a capmgr in the works for 3.13 ?
   - I've taken a brief look at Roberts really simple cape manager 
   https://github.com/RobertCNelson/rscm and it looks very promising. It 
   seems to currently be usable with I2C/SPI/UARTs. Is this something that is 
   being actively worked on. Will there be a sample patches for GPIO (perhaps 
   only one or two example pins) , PWM and ADC  added in the future?
   - Also I've looked at the solution of including device tree overlays in 
   the uEnv.txt file. Is it possible to include more than one .dtbo file in 
   the uEnv.txt file? If so I'd appreciate it if someone can show me an 
   example of the syntax.  


Thanks!

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

[beagleboard] Device Tree in the 3.13 Kernel and pin mux

[halherta]

OK I'm still somewhat new to using the I/O interfaces on the 
BeagleboneBlack. I'm currently interested  in utilizing the 3.13 Kernel. I 
realize that there is no capemgr  for the newer kernel.


   - Is there a capmgr in the works for 3.13 ?
   - I've taken a brief look at Roberts really simple cape manager 
   https://github.com/RobertCNelson/rscm and it looks very promising. It seems 
   to currently be usable with I2C/SPI/UARTs. Is this something that is being 
   actively worked on. Will there be a sample patches for GPIO (perhaps only 
   one or two example pins) , PWM and ADC  added in the future?
   - Also I've looked at the solution of including device tree overlays in 
   the uEnv.txt file. Is it possible to include more than one .dtbo file in 
   the uEnv.txt file? If so I'd appreciate it if someone can show me an 
   example of the syntax.  


   - If I have a GPIO configured with its receiver enabled (bit 5 set to 1) 
   can the pin still be used as an output (output/input) pin or just an input 
   pin ? In some cases, say when interfacing to a HD44780 LCD you need to have 
   a bidirectional data bus...trying to do this from the user space will be 
   impossible if pinmux can't be accessed from user space. I tried looking at 
   the TRM for the AM335x but couldn't quite zone in on this info.
   - Finally if I reserve say two GPIO pins for use with a UART in the 
   device tree. Can I still access these pins as gpio via sysfs if the UART is 
   not being used (i.e. open () system call has not been called on 
   (/dev/tty???)). Or is it simply not usable as GPIO whatsoever ?


Thanks!
Hussam

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

Re: [beagleboard] Build Mainline U-Boot and Kernel

[halherta]

Robert & Nick, Thanks for this info! Its great that we now have mainline 
U-boot support for the BBB.

Since I didn't get a response for the other question that I had ( TImeline 
for Mainline Linux Kernel support) I'm going to assume that it's a touchy 
subject. I thank all parties involved for all their hard work and effort in 
making the Beaglebone Black project succeed!
 

On Thursday, October 10, 2013 12:47:10 PM UTC-4, Robert P. J. Day wrote:
>
> On Thu, 10 Oct 2013, halh...@gmail.com  wrote: 
>
> > I'm trying to build the Kernel and U-boot/MLO for the beaglebone black 
> from scratch. The directions for 
> > building the Kernel found at http://elinux.org/Building_BBB_Kernel 
> > 
> > seems to be straightforward. However I'm not sure about the instructions 
> for building u-boot. Would 
> > something like what's shown below suffice ? 
> > 
> > 
> > get it : � � �� wget 
> ftp://ftp.denx.de/pub/u-boot/u-boot-latest.tar.bz2 
> > 
> > extract it:���� tar -xjf u-boot-latest.tar.bz2 
> > 
> > make it:�������� CROSS_COMPILE=arm-linux-gnueabi- make 
> am335x_boneblack_config 
> > 
> > 
> > Or will I have to somehow patch mainline u-boot as Robert has done in 
> his instructions at 
> > 
> http://eewiki.net/display/AOA/BeagleBone+Black#BeagleBoneBlack-Debian/Ubuntu? 
>
>   here: 
>
> http://www.crashcourse.ca/wiki/index.php/Minimal_scratch_build_for_BBB 
>
> as of yesterday(?), mainline u-boot now totally supports BBB and by 
> default boots from a zImage. no patching necessary. 
>
> rday 
>
> -- 
>
>  
> Robert P. J. Day Ottawa, Ontario, CANADA 
> http://crashcourse.ca 
>
> Twitter:   http://twitter.com/rpjday 
> LinkedIn:   http://ca.linkedin.com/in/rpjday 
> 

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

[beagleboard] Build Mainline U-Boot and Kernel

[halherta]

I'm trying to build the Kernel and U-boot/MLO for the beaglebone black from 
scratch. The directions for building the Kernel found at 
http://elinux.org/Building_BBB_Kernel 


seems to be straightforward. However I'm not sure about the instructions 
for building u-boot. Would something like what's shown below suffice ?


get it :wget ftp://ftp.denx.de/pub/u-boot/u-boot-latest.tar.bz2

extract it: tar -xjf u-boot-latest.tar.bz2

make it: CROSS_COMPILE=arm-linux-gnueabi- make 
am335x_boneblack_config


Or will I have to somehow patch mainline u-boot as Robert has done in his 
instructions at 
http://eewiki.net/display/AOA/BeagleBone+Black#BeagleBoneBlack-Debian/Ubuntu?


Also, as far as the kernel goes, is there an expected time frame by which 
we could expect the Beaglebone Black to be fully supported by the mainline 
kernel?   


Thanks!


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