Re: [beagleboard] Cross Toolchain for Debian Wheezy
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 robert...@gmail.com wrote: On Tue, May 27, 2014 at 3:35 AM, family...@googlemail.com 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=showredirect=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] Enabling the ADC on the 3.8 BBB Kernel without the cape manager
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] Re: Enabling the ADC on the 3.8 BBB Kernel without the cape manager
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.
Re: [beagleboard] Re: Problem getting WIFI + PWM + PYTHON/PYGAME working on the same distro.
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 (ehprwm1ab) 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 vitormh...@gmail.com 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.
[beagleboard] Re: PWM in the 3.13 Kernel
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 (ehprwm1ab) 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.
Re: [beagleboard] Re: PWM in the 3.13 Kernel
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 javascript: 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 (ehprwm1ab) 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 javascript:. For more options, visit https://groups.google.com/d/optout. -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups BeagleBoard group. To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[beagleboard] Re: Help with Cross Compile of first HelloWorld App
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 -MFsrc/HelloBeagle.d -MTsrc/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] Disable autologin and lightdm on the BeagleBoard.org Latest Debian Firmware Image
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: Finally : did someone succeeded to have a Qt GUI app ?
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
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 (ehprwm1ab) 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
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] Device Tree in the 3.13 Kernel and pin mux
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.
[beagleboard] Kernel 3.13 Capemgr alternatives
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] Build Mainline U-Boot and Kernel
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! http://elinux.org/Building_BBB_Kernel -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups BeagleBoard group. To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
