Re: [beagleboard] Re: BBB Booting Without (Volatile) Memory Loss? - For UAV
You think so? I don't think that somebody, preparing for a masters degree in engineering, is a rank beginner. At least he should know how to use the internet. I'm sorry if he felt offended, but this is what a formal studies is all about. Finding things out yourself, not being told how to. Yes I was a bit harsh, I meant to be, but unfair? I don't think so. LP On Thursday, June 12, 2014 1:44:05 AM UTC+2, john3909 wrote: From: PLyttle rkst...@gmail.com javascript: Reply-To: beagl...@googlegroups.com javascript: Date: Wednesday, June 11, 2014 at 1:52 PM To: beagl...@googlegroups.com javascript: Subject: [beagleboard] Re: BBB Booting Without (Volatile) Memory Loss? - For UAV You are pulling my leg, right? You know how to find this forum, but fail to locate beagleboard.org? Delete /Community/Forums from the current URL and follow the links to http://beagleboard.org/Getting%20Started. You are currently building a UAV flight controller for your masters thesis It is *your* masters degree. *You* do the research! There are very few matters more documented on the web than linux if you want to know what a ramdisk is, use google or wiki. That was a little bit harsh. Dustin already said he was new to BBB and Linux so cut him a little slack. We all started out like Dustin and there were people along the way that had the patience to answer our questions. I’m sure your e-mail was well meaning but it did come across as quite critical and really personal. success with your project LP On Wednesday, June 11, 2014 4:23:30 PM UTC+2, R. Dustin Kahawita wrote: Hi PLyttle, Thanks for your response. I apologize, I'm very much new to the BBB and Linux, what exactly do you mean by RamDisk? I've currently booted from my microSD card with Ubuntu 13.10. I installed several programs and made several configuration changes that were lost when I powered down my BBB and then rebooted from the microSD card again. I half expected these changes to be saved on the microSD card but this unfortunately wasn't the case. Must I flash the eMMC with Ubuntu and then configure my microSD card to run as a RamDisk? Could you possible point me in the direction of some documentation on how exactly to do this? Cheers! RDK -- For more options, visit http://beagleboard.org/discuss --- You received this message because you 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] control over uarts and capes under kernel v. 3.15
On Wednesday, June 11, 2014 11:33:25 AM UTC+2, krd wrote: On Wednesday, June 4, 2014 4:50:44 PM UTC+2, RobertCNelson wrote: On Wed, Jun 4, 2014 at 9:29 AM, krd k...@dacsystem.pl wrote: Hey, I'm testing a new kernel - 3.15.0-rc5-bone0.1 from RCN's github - for my BBB under Debian. What I've found out recently is lack of /sys/devices/bone_capemgr.* directory. Also my atempts to turn off hdmi via uEnv file fizzle out. Is it me doing something wrong or this is how it should be? Is there a way to get back my control over uarts, and ability to turn off hdmi under new kernel? capemgr hasn't been ported fully from 3.8 Use this repo: https://github.com/RobertCNelson/bb-kernel/tree/am33x-v3.15 You can enable extra usarts by adding this to uEnv.txt cape=ttyO1 Regards, -- Robert Nelson http://www.rcn-ee.com/ I have switched to the image you've recommended and succeeded only with enabling ttyO1, The other ones are not enabled. I've defined them like that in uEnv.txt: *cape=ttyO1cape=ttyO4cape=ttyO2cape=ttyO5* Is there a way to disable HDMI? cape_disable=capemgr.disable_ partno=BB-BONELT-HDMI,BB-BONELT-HDMIN in uEnv.txt is not working, but since you said that capemgr had not been ported to new kernel I'm not surprised. If it's not possible to do in some other way, which is the latest system where capemgr works? Ok, I managed to switch off hdmi by removing all hdmi-related entries from dts files and recompile the kernel. That's not the most elegant solution for sure, but it works;) The uarts' issue still waits for the solution. -- For more options, visit http://beagleboard.org/discuss --- You received this message because you 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: How to disable udhcpd on the latest (6/5/2014) debian flasher image?
Thank you very much. If I am reading the script correctly, I can disable this by deleting /etc/udhcpd.conf. I did that and rebooted, and I don't see the processes. For whatever radon, it was causing problems with my routers dhcp server. Other devices on the subnet (192.168.1.0) would get a correct ip, and then it would be replaced with an ip on the 192.168.0.0 subnet. I didn't see that with the May image. It appears to be working now, so again, thank you for your help. On Wednesday, June 11, 2014 8:30:52 PM UTC-4, Charles Kerr wrote: I put the latest console image of debian on beagle bone, and notice that when I do a ps aux I see /usr/sbin/udhcpd -S /usr/sbin/udhcpd -S /etc/udhcpd.conf I believe this is for a dhcp server, which I don't need (I only use dhcp as a client on the beagle bone) I attempted to disable it with: update-rc.d udhcpd remove and then rebooted, but they still show up. Is there a way to disable these if they are dhcpd servers? -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups BeagleBoard group. To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[beagleboard] Installing SGX /OPENGL on BBB Angstrom Distribution (3.8.13) so as QT library gets installed onto it
Hello Beagle-bone Geeks, After a long time of about 2 Weeks I have finally gave up. I ahve been trying to get QT4 Embedded running over my BBB on ANgstrom 3.8.13 kernal.It is a project for my self but I am stuced in this section,I am wondering why is it soo much messed up to get these things running! But what can we say. Peoples like you all are helping each other to get these thiings running for us. So my basic problems are as follow:- 1) Installed Angstrom Latest Image 3.8.13 kernal. 2) opkg update 3)opkg upgrade-(installed YOCTO PROJECT) 4)opkg install qt4-embedded --force-depends 5)ERROR- Cannot install qt4 EMbedded another Problem GTK isnt getting running into the system. 1) Error shown on a basic program is PKG-CONF isn't a directory or destination Another problem 1)Simple Hello world Program isn't getting executed on the machine. -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups BeagleBoard group. To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[beagleboard] Re: BeagleBone Black rev C + Ubuntu 13.04 + UWN200 wifi adapter?
This issue is exactly mine, too, I'll try Robert's answer! The Debian install instructions for ROS don't seem to work well, so I switched to Ubuntu. On Tuesday, June 10, 2014 10:02:32 AM UTC-5, Zach Cox wrote: Hi - I just received an element14 BeagleBone Black revC and a Logic Supply UWN200 USB wifi adapter. I flashed Ubuntu 13.04 to the eMMC (replacing the Debian distro that shipped on the eMMC) and that worked fine - I can ssh into the BBB when it's connected via ethernet cable. However, I cannot seem to get the UWN200 wifi adapter to work with BBB and Ubuntu 13.04. Has anyone gotten this to work? I've tried the instructions http://www.logicsupply.com/media/resources/manuals/Tutorial_Installing-Compact-USB-Wifi-Adapter-on-BBB.pdf but they don't seem to work on ubuntu 13.04. Or is there a different usb wifi adapter that will work out-of-the-box with BBB and Ubuntu 13.04? Thanks, Zach -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups BeagleBoard group. To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [beagleboard] Can't make UART work with Python and AdaFruitBBB
Hi Again I try this configuration on /boot/uEnv.txt optargs=capemgr.enable_partno=BB-UART1,BB-UART2,BB-UART4 but it doesn't work. The only way I could do this, is by using this command echo BB-UART2 /sys/devices/bone_capemgr.*/slots Can someone explain me why ? On Tuesday, June 10, 2014 5:37:26 PM UTC-3, cla...@logmatch.com.br wrote: Thanks Robert !!! On Tuesday, June 10, 2014 11:43:28 AM UTC-3, RobertCNelson wrote: On Tue, Jun 10, 2014 at 9:34 AM, cla...@logmatch.com.br wrote: Well, that was one problem. After searching in this forum I discover that I could use /dev/ttyO1 So I use # dmesg |grep serial and # cat /proc/tty/driver/OMAP-SERIAL to confirm that. # cat /proc/tty/driver/OMAP-SERIAL serinfo:1.0 driver revision: 0: uart:OMAP UART0 mmio:0x44E09000 irq:88 tx:558 rx:0 RTS|CTS|DTR|DSR 1: uart:OMAP UART1 mmio:0x48022000 irq:89 tx:75 rx:37 brk:1 CTS|DSR|CD|RI # dmesg |grep serial [0.210444] omap_uart 44e09000.serial: did not get pins for uart0 error: -19 [0.210719] 44e09000.serial: ttyO0 at MMIO 0x44e09000 (irq = 88) is a OMAP UART0 [5.035048] gserial_setup: registered 1 ttyGS* device [ 1763.473407] 48022000.serial: ttyO1 at MMIO 0x48022000 (irq = 89) is a OMAP UART1 But now I have other doubts. Why there are only 2 serials ? because you only loaded two.. Add this to your u-boot bootargs and you'll get a few more: capemgr.enable_partno=BB-UART1,BB-UART2,BB-UART4 (depending on factory v3.8.x kernel) Regards, -- Robert Nelson http://www.rcn-ee.com/ -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups BeagleBoard group. To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [beagleboard] Can't make UART work with Python and AdaFruitBBB
On Thu, Jun 12, 2014 at 8:16 AM, clau...@logmatch.com.br wrote: Hi Again I try this configuration on /boot/uEnv.txt optargs=capemgr.enable_partno=BB-UART1,BB-UART2,BB-UART4 but it doesn't work. The only way I could do this, is by using this command echo BB-UART2 /sys/devices/bone_capemgr.*/slots Can someone explain me why ? probally the wrong uEnv.txt dmesg | grep console would prove that 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] Mounting a SD card for storage
I just wanted to close this out as resolved. I believe the hanging had to do with enabling the audio cape (when I removed that from the uEnv.txt it worked fine). I do appreciate the help and insight. I didn't mean to play a guessing game. I dont have a serial connection, or was aware of a serial log. I under estimated what all one has to learn about to just get setup to write the program one wants to do (linux admin, etc). I have spent hours searching and such, but apparently I need to do more. Anyway, I have it working using the information you provided. It was helpful, and I appreciate it. On Tuesday, June 10, 2014 6:48:42 PM UTC-4, RobertCNelson wrote: On Tue, Jun 10, 2014 at 5:27 PM, Charles Kerr charle...@gmail.com javascript: wrote: That seems to hang up my beablebone on boot if I add to my stab The ethernet never comes up to ssh into. Even without a SD card, after I add that, it never connects to the ethernet after boot. Well... Serial boot log? Or we can keep playing the guessing game... 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] SD Card containing OS and apps dead after three months use
Hi everyone, I've been using the BeagleBone Black for a while now. I got my apps running just fine for like *2-3 months* straight, not a single problem. OS : Debian Wheezy installed on Samsung 4GB µSD card. Cross compilation platform : ELDK (armv7-hf) I've tested my apps on *different brands of SD Cards* (Kingston, samsung, sandisk ...) and have killed several *Kingston* cards in a matter of days. By killing, I mean the BeagleBone wasn't booting on them anymore and they were no longer mounted when plugged via a USB-Card-reader. I had this kind of dmesg output (the [...] here means a lot of the same 7 lines in a loop): [626903.528266] sd 11:0:0:0: [sdd] Device not ready [626903.528268] sd 11:0:0:0: [sdd] Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE [626903.528272] sd 11:0:0:0: [sdd] Sense Key : Not Ready [current] [626903.528275] sd 11:0:0:0: [sdd] Add. Sense: Medium not present [626903.528279] sd 11:0:0:0: [sdd] CDB: Read(10): 28 00 00 00 00 00 00 00 08 00 [626903.528287] end_request: I/O error, dev sdd, sector 0 [626903.528290] Buffer I/O error on device sdd, logical block 0 [626903.530266] sd 11:0:0:0: [sdd] Device not ready [626903.530269] sd 11:0:0:0: [sdd] Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE [626903.530272] sd 11:0:0:0: [sdd] Sense Key : Not Ready [current] [626903.530275] sd 11:0:0:0: [sdd] Add. Sense: Medium not present [626903.530279] sd 11:0:0:0: [sdd] CDB: Read(10): 28 00 00 00 00 00 00 00 08 00 [626903.530287] end_request: I/O error, dev sdd, sector 0 [626903.530290] Buffer I/O error on device sdd, logical block 0 [626903.532391] sd 11:0:0:0: [sdd] Device not ready [626903.532393] sd 11:0:0:0: [sdd] Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE [626903.532396] sd 11:0:0:0: [sdd] Sense Key : Not Ready [current] [626903.532400] sd 11:0:0:0: [sdd] Add. Sense: Medium not present [626903.532404] sd 11:0:0:0: [sdd] CDB: Read(10): 28 00 00 00 00 08 00 00 08 00 [626903.532412] end_request: I/O error, dev sdd, sector 8 [...] [626903.812724] sd 11:0:0:0: [sdd] Device not ready [626903.812725] sd 11:0:0:0: [sdd] Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE [626903.812728] sd 11:0:0:0: [sdd] Sense Key : Not Ready [current] [626903.812731] sd 11:0:0:0: [sdd] Add. Sense: Medium not present [626903.812734] sd 11:0:0:0: [sdd] CDB: Read(10): 28 00 00 00 00 00 00 00 08 00 [626903.812740] end_request: I/O error, dev sdd, sector 0 [626903.814725] sd 11:0:0:0: [sdd] Device not ready [626903.814728] sd 11:0:0:0: [sdd] Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE [626903.814731] sd 11:0:0:0: [sdd] Sense Key : Not Ready [current] [626903.814735] sd 11:0:0:0: [sdd] Add. Sense: Medium not present [626903.814739] sd 11:0:0:0: [sdd] CDB: Read(10): 28 00 00 00 00 00 00 00 08 00 [626903.814747] end_request: I/O error, dev sdd, sector 0 [626903.820536] sdd: detected capacity change from 3947888640 to 0 That's why I chose to use *Samsung* sd cards instead. Everything was fine for *2-3 whole months*, but now I had one of my systems getting the *exact same symptoms* as when using the Kingston cards. Did anyone experience this kind of problem using his beagle bone so far ? Does anyone have an idea of something that could damage the SD card so much which is or isn't directly related to the use of a beagle bone black (Heat, compulsive logging, ...) ? Can anyone suggest a brand that has solid and enduring SD Cards for an app that is logging quite regularly ? Thank you for your time, FT -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups BeagleBoard group. To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [beagleboard] SD Card containing OS and apps dead after three months use
On Thu, Jun 12, 2014 at 9:14 AM, Frank Talamy talam...@gmail.com wrote: Hi everyone, I've been using the BeagleBone Black for a while now. I got my apps running just fine for like 2-3 months straight, not a single problem. OS : Debian Wheezy installed on Samsung 4GB µSD card. Cross compilation platform : ELDK (armv7-hf) I've tested my apps on different brands of SD Cards (Kingston, samsung, sandisk ...) and have killed several Kingston cards in a matter of days. By killing, I mean the BeagleBone wasn't booting on them anymore and they were no longer mounted when plugged via a USB-Card-reader. I had this kind of dmesg output (the [...] here means a lot of the same 7 lines in a loop): [626903.528266] sd 11:0:0:0: [sdd] Device not ready [626903.528268] sd 11:0:0:0: [sdd] Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE [626903.528272] sd 11:0:0:0: [sdd] Sense Key : Not Ready [current] [626903.528275] sd 11:0:0:0: [sdd] Add. Sense: Medium not present [626903.528279] sd 11:0:0:0: [sdd] CDB: Read(10): 28 00 00 00 00 00 00 00 08 00 [626903.528287] end_request: I/O error, dev sdd, sector 0 [626903.528290] Buffer I/O error on device sdd, logical block 0 [626903.530266] sd 11:0:0:0: [sdd] Device not ready [626903.530269] sd 11:0:0:0: [sdd] Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE [626903.530272] sd 11:0:0:0: [sdd] Sense Key : Not Ready [current] [626903.530275] sd 11:0:0:0: [sdd] Add. Sense: Medium not present [626903.530279] sd 11:0:0:0: [sdd] CDB: Read(10): 28 00 00 00 00 00 00 00 08 00 [626903.530287] end_request: I/O error, dev sdd, sector 0 [626903.530290] Buffer I/O error on device sdd, logical block 0 [626903.532391] sd 11:0:0:0: [sdd] Device not ready [626903.532393] sd 11:0:0:0: [sdd] Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE [626903.532396] sd 11:0:0:0: [sdd] Sense Key : Not Ready [current] [626903.532400] sd 11:0:0:0: [sdd] Add. Sense: Medium not present [626903.532404] sd 11:0:0:0: [sdd] CDB: Read(10): 28 00 00 00 00 08 00 00 08 00 [626903.532412] end_request: I/O error, dev sdd, sector 8 [...] [626903.812724] sd 11:0:0:0: [sdd] Device not ready [626903.812725] sd 11:0:0:0: [sdd] Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE [626903.812728] sd 11:0:0:0: [sdd] Sense Key : Not Ready [current] [626903.812731] sd 11:0:0:0: [sdd] Add. Sense: Medium not present [626903.812734] sd 11:0:0:0: [sdd] CDB: Read(10): 28 00 00 00 00 00 00 00 08 00 [626903.812740] end_request: I/O error, dev sdd, sector 0 [626903.814725] sd 11:0:0:0: [sdd] Device not ready [626903.814728] sd 11:0:0:0: [sdd] Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE [626903.814731] sd 11:0:0:0: [sdd] Sense Key : Not Ready [current] [626903.814735] sd 11:0:0:0: [sdd] Add. Sense: Medium not present [626903.814739] sd 11:0:0:0: [sdd] CDB: Read(10): 28 00 00 00 00 00 00 00 08 00 [626903.814747] end_request: I/O error, dev sdd, sector 0 [626903.820536] sdd: detected capacity change from 3947888640 to 0 That's why I chose to use Samsung sd cards instead. Everything was fine for 2-3 whole months, but now I had one of my systems getting the exact same symptoms as when using the Kingston cards. Did anyone experience this kind of problem using his beagle bone so far ? Does anyone have an idea of something that could damage the SD card so much which is or isn't directly related to the use of a beagle bone black (Heat, compulsive logging, ...) ? Can anyone suggest a brand that has solid and enduring SD Cards for an app that is logging quite regularly ? I use SanDisk Ultra's 16GB's on my bbw bbb's on my gcc testing farm. Those microSD's have been running fine for almost a year now, under 100% load for 24/7 bulding/testing gcc stable branches. (lots of file deletions/creations). Previously to that i had been running SanDisk Ultra's 8GB variants, but starting with gcc-4_8-branch i began to run out of build space. http://rcn-ee.homeip.net:81/dl/gcc/archive/20140610-11:24-gitb28747e-gcc-4_9-branch-am335x-boneblack-512mb-1/ Regards, -- Robert Nelson http://www.rcn-ee.com/ -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups BeagleBoard group. To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [beagleboard] kernel 3.14 upgrade in debian, BeagleBoard xM
Thank you I've been trying out this option. Actually I started this project with your custom images, so thumbs up ;) I've opted for a native compile on the BBxm with your scripts (on an additional SD card to have enough space). When git fetches from https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable and tags, e.g.: * [new tag] v3.9.9 - v3.9.9 I get: error: Your local changes to the following files would be overwritten by checkout: tools/testing/selftests/rcutorture/configs/rcu/v3.12/P7-4-T-NH-SD-SMP-HP Please, commit your changes or stash them before you can switch branches. Aborting I'm not very familiar with git, but I'll try to follow the script step by step to find this out. However if you have an insight or quick suggestion please let me know. Also: when I first tried the script, on the root file system microSD the compile process started and I didn't have git problems. I had to stop unfortunately, since the uSD space was almost over. I'm wondering whether I screwed up something with git. Regards On Friday, June 6, 2014 5:08:11 PM UTC+2, RobertCNelson wrote: On Fri, Jun 6, 2014 at 9:54 AM, Leonardo Gabrielli leod...@gmail.com javascript: wrote: Hello group, a rather newbie-ish question. I created my own customized Debian Wheezy system for a Beagleboard xM from armhf builds at rcn-ee.net (specifically: debian-7.4-console-armhf). Now I am happy with all the tweaks I've done so far in the last months but I'd like to upgrade the kernel to a 3.14 release, in order to make use of the new SCHED_DEADLINE. There are no backports of linux 3.14 for Wheezy but there are Jessie packages for linux-headers-3.14-1-all linux-headers-3.14-1-common linux-headers-3.14-1-all-armhf etc. What's the best option to upgrade the kernel? Tweeak /etc/apt/sources.list to add Jessie repos or trying compile it natively (I'm too lazy for setting up a cross-compile chain). I don't think Jessie's 3.14-1 will boot the xm.. or just use this branch: https://github.com/RobertCNelson/armv7-multiplatform/tree/v3.14.x with your config tweak and really easy to copy the kernel files: http://eewiki.net/display/linuxonarm/BeagleBoard#BeagleBoard-CopyKernelFiles Also, once I've got them compiled, I guess I should modify the BOOT partition of my uSD card to point to the proper image? An outline of the steps would be immensely appreciated! Pretty straight forward: zImage/vmlinux - /boot/uboot/zImage dtbs - /boot/uboot/dtbs modules - /lib/modules/ 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: qt4-embedded will not install on 3.8 kernel
* opkg_install_cmd: Cannot install package qt4-embedded. Is there a simple configuration somewhere that can be changed to allow it to work on 3.8 kernels? I am using Angstrom YOCTO project 3.8 Kernal. Kindly help me out a bit on this. Stucked for about a week and couldn't get qt4 Embedded running on bbb. opkg install qt4-embedded --force-dependsisnt working at all...Same problem persists. -- For more options, visit http://beagleboard.org/discuss --- You received this message because you 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] SD Card containing OS and apps dead after three months use, any suggestions ?
Hi everyone, I've been using the BeagleBone Black for a while now. I got my apps running just fine for like *2-3 months* straight, not a single problem. OS : Debian Wheezy installed on Samsung 4GB µSD card. Cross compilation platform : ELDK (armv7-hf) I've tested my apps on *different brands of SD Cards* (Kingston, samsung, sandisk ...) and have killed several *Kingston* cards in a matter of days. By killing, I mean the BeagleBone wasn't booting on them anymore and they were no longer mounted when plugged via a USB-Card-reader. I had this kind of dmesg output (the [...] here means a lot of the same 7 lines in a loop): [626903.528266] sd 11:0:0:0: [sdd] Device not ready [626903.528268] sd 11:0:0:0: [sdd] Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE [626903.528272] sd 11:0:0:0: [sdd] Sense Key : Not Ready [current] [626903.528275] sd 11:0:0:0: [sdd] Add. Sense: Medium not present [626903.528279] sd 11:0:0:0: [sdd] CDB: Read(10): 28 00 00 00 00 00 00 00 08 00 [626903.528287] end_request: I/O error, dev sdd, sector 0 [626903.528290] Buffer I/O error on device sdd, logical block 0 [626903.530266] sd 11:0:0:0: [sdd] Device not ready [626903.530269] sd 11:0:0:0: [sdd] Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE [626903.530272] sd 11:0:0:0: [sdd] Sense Key : Not Ready [current] [626903.530275] sd 11:0:0:0: [sdd] Add. Sense: Medium not present [626903.530279] sd 11:0:0:0: [sdd] CDB: Read(10): 28 00 00 00 00 00 00 00 08 00 [626903.530287] end_request: I/O error, dev sdd, sector 0 [626903.530290] Buffer I/O error on device sdd, logical block 0 [626903.532391] sd 11:0:0:0: [sdd] Device not ready [626903.532393] sd 11:0:0:0: [sdd] Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE [626903.532396] sd 11:0:0:0: [sdd] Sense Key : Not Ready [current] [626903.532400] sd 11:0:0:0: [sdd] Add. Sense: Medium not present [626903.532404] sd 11:0:0:0: [sdd] CDB: Read(10): 28 00 00 00 00 08 00 00 08 00 [626903.532412] end_request: I/O error, dev sdd, sector 8 [...] [626903.812724] sd 11:0:0:0: [sdd] Device not ready [626903.812725] sd 11:0:0:0: [sdd] Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE [626903.812728] sd 11:0:0:0: [sdd] Sense Key : Not Ready [current] [626903.812731] sd 11:0:0:0: [sdd] Add. Sense: Medium not present [626903.812734] sd 11:0:0:0: [sdd] CDB: Read(10): 28 00 00 00 00 00 00 00 08 00 [626903.812740] end_request: I/O error, dev sdd, sector 0 [626903.814725] sd 11:0:0:0: [sdd] Device not ready [626903.814728] sd 11:0:0:0: [sdd] Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE [626903.814731] sd 11:0:0:0: [sdd] Sense Key : Not Ready [current] [626903.814735] sd 11:0:0:0: [sdd] Add. Sense: Medium not present [626903.814739] sd 11:0:0:0: [sdd] CDB: Read(10): 28 00 00 00 00 00 00 00 08 00 [626903.814747] end_request: I/O error, dev sdd, sector 0 [626903.820536] sdd: detected capacity change from 3947888640 to 0 That's why I chose to use *Samsung* sd cards instead. Everything was fine for *2-3 whole months*, but now I had one of my systems getting the *exact same symptoms* as when using the Kingston cards. Did anyone experience this kind of problem using his beagle bone so far ? Does anyone have an idea of something that could damage the SD card so much which is or isn't directly related to the use of a beagle bone black (Heat, compulsive logging, ...) ? Can anyone suggest a brand that has solid and enduring SD Cards for an app that is logging quite regularly ? Thank you for your time, FT -- For more options, visit http://beagleboard.org/discuss --- You received this message because you 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: Mainline kernel status
Am Donnerstag, 5. Juni 2014 16:42:58 UTC+2 schrieb rh_: On Wed, 4 Jun 2014 02:20:37 -0700 (PDT) markus@gmail.com javascript: wrote: Hi, I am looking for a board we want to use in a automation project. One of the critical features (on software side) is the mainline kernel support. One of the boards we are looking at is the BBB. I found that Robert Nelson is maintaining patches to get the latest mainline running. https://github.com/RobertCNelson/linux-dev What is the status of pushing the patches to the mainline kernel? Good question. Did I asked the wrong/false question earlier as nobody could/wants to answer it? Is there somewhere an overview what is currently working in the latest kernel? The answer to the above will answer this I think. Also what drivers will come in next version or are being worked on? Might be easier to answer what tech do you need and then ask if those capabilities are available in mainline kernel. Headless setup with Ethernet, USB, eMMC (storage and booting), RTC as a cape Later maybe as an option: display with touchscreen -- For more options, visit http://beagleboard.org/discuss --- You received this message because you 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 BeagleBoard-xM
all information on the internet, has not helped me to activate the PWM, please someone help me!! Thank you!! -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups BeagleBoard group. To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [beagleboard] control over uarts and capes under kernel v. 3.15
Em 12-06-2014 07:04, krd escreveu:
On Wednesday, June 11, 2014 11:33:25 AM UTC+2, krd wrote:
On Wednesday, June 4, 2014 4:50:44 PM UTC+2, RobertCNelson wrote:
On Wed, Jun 4, 2014 at 9:29 AM, krd k...@dacsystem.pl wrote:
Hey,
I'm testing a new kernel - 3.15.0-rc5-bone0.1 from RCN's
github - for my BBB
under Debian. What I've found out recently is lack of
/sys/devices/bone_capemgr.* directory. Also my atempts to
turn off hdmi via
uEnv file fizzle out. Is it me doing something wrong or this
is how it
should be? Is there a way to get back my control over uarts,
and ability to
turn off hdmi under new kernel?
capemgr hasn't been ported fully from 3.8
Use this repo:
https://github.com/RobertCNelson/bb-kernel/tree/am33x-v3.15
https://github.com/RobertCNelson/bb-kernel/tree/am33x-v3.15
You can enable extra usarts by adding this to uEnv.txt
cape=ttyO1
Regards,
--
Robert Nelson
http://www.rcn-ee.com/
I have switched to the image you've recommended and succeeded only
with enabling ttyO1, The other ones are not enabled. I've defined
them like that in uEnv.txt:
/cape=ttyO1
cape=ttyO4
cape=ttyO2
cape=ttyO5/
Is there a way to disable HDMI? cape_disable=capemgr.disable_
partno=BB-BONELT-HDMI,BB-BONELT-HDMIN in uEnv.txt is not working,
but since you said that capemgr had not been ported to new kernel
I'm not surprised. If it's not possible to do in some other way,
which is the latest system where capemgr works?
Ok, I managed to switch off hdmi by removing all hdmi-related entries
from dts files and recompile the kernel. That's not the most elegant
solution for sure, but it works;) The uarts' issue still waits for the
solution.
Well, I think there is a better solution, but since you already
recompiled the kernel, I did just like you and edited
am335x-boneblack.dts:
/*
* Copyright (C) 2012 Texas Instruments Incorporated - http://www.ti.com/
*
* This program is free software; you can redistribute it and/or modify
* it under the terms of the GNU General Public License version 2 as
* published by the Free Software Foundation.
*/
/dts-v1/;
#include am33xx.dtsi
#include am335x-bone-common.dtsi
ldo3_reg {
regulator-min-microvolt = 180;
regulator-max-microvolt = 180;
regulator-always-on;
};
mmc1 {
vmmc-supply = vmmcsd_fixed;
};
mmc2 {
vmmc-supply = vmmcsd_fixed;
pinctrl-names = default;
pinctrl-0 = emmc_pins;
bus-width = 8;
status = okay;
ti,vcc-aux-disable-is-sleep;
};
uart2 {
pinctrl-names = default;
pinctrl-0 = uart2_pins;
status = okay;
};
uart4 {
pinctrl-names = default;
pinctrl-0 = uart4_pins;
status = okay;
};
uart5 {
pinctrl-names = default;
pinctrl-0 = uart5_pins;
status = okay;
};
am33xx_pinmux {
};
/ {
cpus {
cpu@0 {
cpu0-supply = dcdc2_reg;
/*
* To consider voltage drop between PMIC and SoC,
* tolerance value is reduced to 2% from 4% and
* voltage value is increased as a precaution.
*/
operating-points =
/* kHzuV */
1001325000
80130
60 1112000
30 969000
;
};
};
};
--
For more options, visit http://beagleboard.org/discuss
---
You received this message because you 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] Is Debian 7.5 2014-05-14 using init.d, systemd, or something else?
On 06/11/2014 10:58 PM, Robert Nelson wrote: On Wed, Jun 11, 2014 at 9:56 PM, Justin Morgan jdm...@gmail.com wrote: I am very new to systemd. Where would I find the systemd equivalent of the init.d scripts? Yeah, i haven't figured it out either, hence why you see both my boot_script.sh and capemgr.sh scripts under /etc/init.d/.. but it boots 40 seconds faster. ;) Regards, systemctl will show you all the details. Most of the gory details live under /lib/systemd/system These two links are great starting points. I'm still trying to wrap my brain around the whole systemd concept. I will say that it does boot every piece of hardware I've used it on very fast. http://0pointer.de/blog/projects/systemd-for-admins-1.html http://www.freedesktop.org/wiki/Software/systemd/ Mike -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups BeagleBoard group. To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [beagleboard] When and where is Is Debian 7.5 2014-05-14 synchronizing omap_rtc with the system clock?
On 06/11/2014 11:58 PM, John Syn wrote: From: Justin Morgan jdm...@gmail.com mailto:jdm...@gmail.com Reply-To: beagleboard@googlegroups.com mailto:beagleboard@googlegroups.com Date: Wednesday, June 11, 2014 at 7:54 PM To: beagleboard@googlegroups.com mailto:beagleboard@googlegroups.com Subject: [beagleboard] When and where is Is Debian 7.5 2014-05-14 synchronizing omap_rtc with the system clock? I have installed the Debian 7.5 2014-05-14 image onto my BeagleBone Black. Very early in the boot process, Debian appears to synchronize (or attempt thereof) the time reported by the omap_rtc device (that would be the RTC built into the AM3359 processor that gets mapped to /dev/rtc0). This can be demonstrated by the following line in dmsg: [1.025090] omap_rtc 44e3e000.rtc: setting system clock to 2000-01-01 00:00:00 UTC (946684800) I am trying to determine exactly when and where the event that logs *this* dmesg entry happens in the boot process. You need to change CONFIG_RTC_HCTOSYS_DEVICE to rtc1 in your kernel .config file. Regards, John -- This will get the kernel to use rtc1. I'm unable to verify it right now, but one will have to make sure the proper module is loaded if required. You will also have to disable hwclock in systemd or it's going to reset the time back to whatever rtc0 thinks the time is. The systemd authors have chosen to rewrite hwclock and the rtc0 value is hardcoded into the binary. There also is *NO* way to change the rtc used in their version as in the original version of hwclock. I've been beating my head against the wall on this for some time now. When I'm able to get my BBB plugged in again and get a bit of spare time I dig into it more again. Mike -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups BeagleBoard group. To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [beagleboard] Can't make UART work with Python and AdaFruitBBB
You are right. root@beaglebone1:~# dmesg |grep console [0.00] Kernel command line: console=ttyO0,115200n8 quiet drm.debug=7 root=/dev/mmcblk0p2 ro rootfstype=ext4 rootwait [0.222807] console [ttyO0] enabled but I can't found another uEnv.txt in Angstrom system. So I probably will have to generate one that's correct ? These are the things people had to do when they will use UART in their systems? I believe that we could have a more prepared system for development ;) Anyway I'll try to look what can i do here Thank you all you help Robert Cláudio B. -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups BeagleBoard group. To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[beagleboard] kernel oops related to omap_i2c 48060000.i2c
Dear all,
I'm looking for suggestions for this kernel oops.
I recently discovered that when pushing the CPU too high (scaling_governor
set to performance, audio processes taking 100%) I often encounter a kernel
oops (reported on bottom) after several lines of:
omap_i2c 4806.i2c: controller timed out
Looking at sysfs I see that 4806.i2c is related to the SD card slot. Am
I right?
So maybe the problem with my system is that the I2C controller gets crazy
(maybe because of delays caused by the high CPU load? Or maybe because of
the heat? One month ago the same configuration did work well, but even
putting a fan in front of the board doesn't help now).
I'm working on a debian Wheezy version from Robert Nelson rcn-ee:
Linux debian-BB1 3.13.3-armv7-x10 #1 SMP Sat Feb 15 01:03:40 UTC 2014
armv7l GNU/Linux
BeagleBoard xM, rev.c
The kern.log output. At 193 the jack is started and ALSA allocates the
buffers. After some time the controller timed out messages start. I can
reproduce the bug by forcing a bit the CPU (e.g. running top and cat from a
big file).
Jun 12 15:44:00 debian-BB1 kernel: [ 193.192321] omap-dma-engine
48056000.dma-controller: allocating channel for 33
Jun 12 15:44:00 debian-BB1 kernel: [ 193.214355] omap-dma-engine
48056000.dma-controller: allocating channel for 34
Jun 12 15:44:24 debian-BB1 kernel: [ 216.959320] [sched_delayed] sched: RT
throttling activated
Jun 12 15:44:33 debian-BB1 kernel: [ 225.959625] omap_i2c 4806.i2c:
controller timed out
Jun 12 15:44:44 debian-BB1 kernel: [ 236.979858] omap_i2c 4806.i2c:
controller timed out
Jun 12 15:44:56 debian-BB1 kernel: [ 248.949737] omap_i2c 4806.i2c:
controller timed out
Jun 12 15:45:04 debian-BB1 kernel: [ 256.098236] Unhandled fault: external
abort on non-linefetch (0x1028) at 0xfa060004
Jun 12 15:45:04 debian-BB1 kernel: [ 256.106933] Internal error: : 1028
[#1] SMP ARM
Jun 12 15:45:04 debian-BB1 kernel: [ 256.112091] Modules linked in:
leds_pwm smsc95xx usbnet gpio_keys rtc_twl omap_aes uio_pdrv_genirq uio
Jun 12 15:45:04 debian-BB1 kernel: [ 256.122863] CPU: 0 PID: 25 Comm:
irq/77-4806 Not tainted 3.13.3-armv7-x10 #1
Jun 12 15:45:04 debian-BB1 kernel: [ 256.131225] task: df1bcb00 ti:
df1c6000 task.ti: df1c6000
Jun 12 15:45:04 debian-BB1 kernel: [ 256.137359] PC is at
omap_i2c_isr_thread+0x38/0x378
Jun 12 15:45:04 debian-BB1 kernel: [ 256.142913] LR is at
omap_i2c_isr_thread+0x10/0x378
Jun 12 15:45:04 debian-BB1 kernel: [ 256.148437] pc : [c05a4ee4]lr :
[c05a4ebc]psr: 6093
Jun 12 15:45:04 debian-BB1 kernel: [ 256.148437] sp : df1c7f08 ip :
fp : 0001
Jun 12 15:45:04 debian-BB1 kernel: [ 256.161376] r10: 0010 r9 :
0004 r8 : 0266
Jun 12 15:45:04 debian-BB1 kernel: [ 256.167297] r7 : df1c6000 r6 :
6013 r5 : 0065 r4 : df1b1410
Jun 12 15:45:04 debian-BB1 kernel: [ 256.174652] r3 : fa060004 r2 :
fa06 r1 : 0001 r0 : 6013
Jun 12 15:45:04 debian-BB1 kernel: [ 256.182037] Flags: nZCv IRQs off
FIQs on Mode SVC_32 ISA ARM Segment kernel
Jun 12 15:45:04 debian-BB1 kernel: [ 256.190399] Control: 10c5387d Table:
9e7e4019 DAC: 0015
Jun 12 15:45:04 debian-BB1 kernel: [ 256.196899] Process irq/77-4806
(pid: 25, stack limit = 0xdf1c6248)
Jun 12 15:45:04 debian-BB1 kernel: [ 256.204376] Stack: (0xdf1c7f08 to
0xdf1c8000)
Jun 12 15:45:04 debian-BB1 kernel: [ 256.209320] 7f00:
df1a74c0 df007a80 df1c6000 df1c6000 df1a74e0
Jun 12 15:45:04 debian-BB1 kernel: [ 256.218597] 7f20: c007d78c c007d7a8
df007a80 df1a74c0 df1c6000 c007d524 c007d6d4
Jun 12 15:45:04 debian-BB1 kernel: [ 256.227844] 7f40: df1c7f50 df1a7500
df1a74c0 c007d48c
Jun 12 15:45:04 debian-BB1 kernel: [ 256.237091] 7f60: c0058bd4
00900800 02e02408 df1a74c0
Jun 12 15:45:04 debian-BB1 kernel: [ 256.246337] 7f80: df1c7f80 df1c7f80
df1c7f90 df1c7f90 df1c7fac df1a7500
Jun 12 15:45:04 debian-BB1 kernel: [ 256.255584] 7fa0: c0058b0c
c000db98
Jun 12 15:45:04 debian-BB1 kernel: [ 256.264831] 7fc0:
Jun 12 15:45:04 debian-BB1 kernel: [ 256.274108] 7fe0:
0013 80200800 00050040
Jun 12 15:45:04 debian-BB1 kernel: [ 256.283386] [c05a4ee4]
(omap_i2c_isr_thread+0x38/0x378) from [c007d7a8] (irq_thread_fn+0x1c/0x40)
Jun 12 15:45:04 debian-BB1 kernel: [ 256.293823] [c007d7a8]
(irq_thread_fn+0x1c/0x40) from [c007d524] (irq_thread+0x98/0x160)
Jun 12 15:45:04 debian-BB1 kernel: [ 256.303405] [c007d524]
(irq_thread+0x98/0x160) from [c0058bd4] (kthread+0xc8/0xdc)
Jun 12 15:45:04 debian-BB1 kernel: [ 256.312377] [c0058bd4]
(kthread+0xc8/0xdc) from [c000db98] (ret_from_fork+0x14/0x3c)
Jun 12 15:45:04 debian-BB1 kernel: [ 256.321533] Code: e5942008
Re: [beagleboard] kernel oops related to omap_i2c 48060000.i2c
On Thu, Jun 12, 2014 at 11:17 AM, Leonardo Gabrielli leoda...@gmail.com wrote: Dear all, I'm looking for suggestions for this kernel oops. I recently discovered that when pushing the CPU too high (scaling_governor set to performance, audio processes taking 100%) I often encounter a kernel oops (reported on bottom) after several lines of: omap_i2c 4806.i2c: controller timed out Looking at sysfs I see that 4806.i2c is related to the SD card slot. Am I right? So maybe the problem with my system is that the I2C controller gets crazy (maybe because of delays caused by the high CPU load? Or maybe because of the heat? One month ago the same configuration did work well, but even putting a fan in front of the board doesn't help now). I'm working on a debian Wheezy version from Robert Nelson rcn-ee: Linux debian-BB1 3.13.3-armv7-x10 #1 SMP Sat Feb 15 01:03:40 UTC 2014 armv7l GNU/Linux BeagleBoard xM, rev.c any improvement with v3.15.x? wget http://rcn-ee.net/deb/wheezy-armhf/v3.15.0-armv7-x2/install-me.sh sudo /bin/bash install-me.sh (reboot) Regards, -- Robert Nelson http://www.rcn-ee.com/ -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups BeagleBoard group. To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [beagleboard] SD Card containing OS and apps dead after three months use, any suggestions ?
I have not, and I've been running my beaglebone Black since release last year(on, and off, with uptimes of over months at a time. ). The difference between you and I ? Most likely that I am running my rootfs from an NFS share over our network. So, with this in mind, I would think you need to investigate running read only, and / or you need to stop logging to the sd media you're using. On Thu, Jun 12, 2014 at 7:06 AM, talam...@gmail.com wrote: Hi everyone, I've been using the BeagleBone Black for a while now. I got my apps running just fine for like *2-3 months* straight, not a single problem. OS : Debian Wheezy installed on Samsung 4GB µSD card. Cross compilation platform : ELDK (armv7-hf) I've tested my apps on *different brands of SD Cards* (Kingston, samsung, sandisk ...) and have killed several *Kingston* cards in a matter of days. By killing, I mean the BeagleBone wasn't booting on them anymore and they were no longer mounted when plugged via a USB-Card-reader. I had this kind of dmesg output (the [...] here means a lot of the same 7 lines in a loop): [626903.528266] sd 11:0:0:0: [sdd] Device not ready [626903.528268] sd 11:0:0:0: [sdd] Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE [626903.528272] sd 11:0:0:0: [sdd] Sense Key : Not Ready [current] [626903.528275] sd 11:0:0:0: [sdd] Add. Sense: Medium not present [626903.528279] sd 11:0:0:0: [sdd] CDB: Read(10): 28 00 00 00 00 00 00 00 08 00 [626903.528287] end_request: I/O error, dev sdd, sector 0 [626903.528290] Buffer I/O error on device sdd, logical block 0 [626903.530266] sd 11:0:0:0: [sdd] Device not ready [626903.530269] sd 11:0:0:0: [sdd] Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE [626903.530272] sd 11:0:0:0: [sdd] Sense Key : Not Ready [current] [626903.530275] sd 11:0:0:0: [sdd] Add. Sense: Medium not present [626903.530279] sd 11:0:0:0: [sdd] CDB: Read(10): 28 00 00 00 00 00 00 00 08 00 [626903.530287] end_request: I/O error, dev sdd, sector 0 [626903.530290] Buffer I/O error on device sdd, logical block 0 [626903.532391] sd 11:0:0:0: [sdd] Device not ready [626903.532393] sd 11:0:0:0: [sdd] Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE [626903.532396] sd 11:0:0:0: [sdd] Sense Key : Not Ready [current] [626903.532400] sd 11:0:0:0: [sdd] Add. Sense: Medium not present [626903.532404] sd 11:0:0:0: [sdd] CDB: Read(10): 28 00 00 00 00 08 00 00 08 00 [626903.532412] end_request: I/O error, dev sdd, sector 8 [...] [626903.812724] sd 11:0:0:0: [sdd] Device not ready [626903.812725] sd 11:0:0:0: [sdd] Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE [626903.812728] sd 11:0:0:0: [sdd] Sense Key : Not Ready [current] [626903.812731] sd 11:0:0:0: [sdd] Add. Sense: Medium not present [626903.812734] sd 11:0:0:0: [sdd] CDB: Read(10): 28 00 00 00 00 00 00 00 08 00 [626903.812740] end_request: I/O error, dev sdd, sector 0 [626903.814725] sd 11:0:0:0: [sdd] Device not ready [626903.814728] sd 11:0:0:0: [sdd] Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE [626903.814731] sd 11:0:0:0: [sdd] Sense Key : Not Ready [current] [626903.814735] sd 11:0:0:0: [sdd] Add. Sense: Medium not present [626903.814739] sd 11:0:0:0: [sdd] CDB: Read(10): 28 00 00 00 00 00 00 00 08 00 [626903.814747] end_request: I/O error, dev sdd, sector 0 [626903.820536] sdd: detected capacity change from 3947888640 to 0 That's why I chose to use *Samsung* sd cards instead. Everything was fine for *2-3 whole months*, but now I had one of my systems getting the *exact same symptoms* as when using the Kingston cards. Did anyone experience this kind of problem using his beagle bone so far ? Does anyone have an idea of something that could damage the SD card so much which is or isn't directly related to the use of a beagle bone black (Heat, compulsive logging, ...) ? Can anyone suggest a brand that has solid and enduring SD Cards for an app that is logging quite regularly ? Thank you for your time, FT -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups BeagleBoard group. To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups BeagleBoard group. To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[beagleboard] Connect rfid reader RDM6300 viva serial TX/RX to the Beaglebord mx
Hi I want to connect the rfid reader RDM6300 viva serial TX/RX Beaglebord mx. http://imall.iteadstudio.com/wireless/rfid/im120618002.html Any Ideas how to manage it ? friendly regards Kai -- For more options, visit http://beagleboard.org/discuss --- You received this message because you 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: Two BBBs on same host's USB
I'm not sure you're ending up with a sane network configuration using the same subnet mask for each, but did you change the udhcpd config file to give the host a different ip for each usb connection? The host gets its ip from the beaglebone's dhcp server. I say not sane, because the beaglebone's wont be able to communicate with each other because there's no route between them. For a more proper (?) configuration, you could use use the 192.168.7.2, subnet 255.255.255.252, host ip range of 192.168.7.1 (start and stop in the udhcpd config file). For the other (looking at this subnet calculator http://www.subnet-calculator.com/), 192.168.7.6, subnet 255.255.255.252, host ip 192.168.7.5 (start and stop in its udhcpd config file). I ended up making a python script to set the usb ip based on the hash of the board id stored in eeprom so I wouldn't have to worry (too much, only 14 bits) about any two beaglebone's clashing --Brandon On Tuesday, June 10, 2014 11:58:10 AM UTC-7, ec1...@gmail.com wrote: Hi, I have two BBBs, and each can connect to a host via USB0 with no problems. One as IP 192.168.7.2 and subnet mask 255.255.255.0 (changed from ...252) and another on 192.168.7.7. For some reason they both cannot connect at the same time as PuTTY gives me a conn timeout. Is there a way to have more than one BBB on a single USB host network? Thanks! E C -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups BeagleBoard group. To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [beagleboard] SD Card containing OS and apps dead after three months use
With a 16Gb card, you'll most likely get about 2 years use before the card fails, assuming you had 2gb free on your failing cards card, the 16Gb card has the same number of writes until failure for the memory blocks, and the same disk activity. This assumes that you're have a perfect power supply that never shuts off during a write (which will damage the memory cells) or unflushed operation (which can corrupt the filesystem). If you're writing to flash media, it will eventually fail. :-\ Ideally, you would have your os disk read only (read only partition doesn't necessarily work due to sd card wear leveling controller not being aware of partitions), and log files logged elsewhere where your software could gracefully handle the eventual failure of the log file flash disk. Have this log file disk easily accessible for customers to change. You could not flush your log file writes until some sort of failure or buffer size, so that you're not writing whole erase blocks for a sentence worth of log message. And, of course, turn off all the access time capabilities with your mount options (noatime, nodiratime). The only solution is to reduce the number of writes each memory block is seeing in a day, and be aware that eventual failure can't be avoided if writing anything. On Thursday, June 12, 2014 7:24:14 AM UTC-7, RobertCNelson wrote: On Thu, Jun 12, 2014 at 9:14 AM, Frank Talamy tala...@gmail.com javascript: wrote: Hi everyone, I've been using the BeagleBone Black for a while now. I got my apps running just fine for like 2-3 months straight, not a single problem. OS : Debian Wheezy installed on Samsung 4GB µSD card. Cross compilation platform : ELDK (armv7-hf) I've tested my apps on different brands of SD Cards (Kingston, samsung, sandisk ...) and have killed several Kingston cards in a matter of days. By killing, I mean the BeagleBone wasn't booting on them anymore and they were no longer mounted when plugged via a USB-Card-reader. I had this kind of dmesg output (the [...] here means a lot of the same 7 lines in a loop): [626903.528266] sd 11:0:0:0: [sdd] Device not ready [626903.528268] sd 11:0:0:0: [sdd] Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE [626903.528272] sd 11:0:0:0: [sdd] Sense Key : Not Ready [current] [626903.528275] sd 11:0:0:0: [sdd] Add. Sense: Medium not present [626903.528279] sd 11:0:0:0: [sdd] CDB: Read(10): 28 00 00 00 00 00 00 00 08 00 [626903.528287] end_request: I/O error, dev sdd, sector 0 [626903.528290] Buffer I/O error on device sdd, logical block 0 [626903.530266] sd 11:0:0:0: [sdd] Device not ready [626903.530269] sd 11:0:0:0: [sdd] Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE [626903.530272] sd 11:0:0:0: [sdd] Sense Key : Not Ready [current] [626903.530275] sd 11:0:0:0: [sdd] Add. Sense: Medium not present [626903.530279] sd 11:0:0:0: [sdd] CDB: Read(10): 28 00 00 00 00 00 00 00 08 00 [626903.530287] end_request: I/O error, dev sdd, sector 0 [626903.530290] Buffer I/O error on device sdd, logical block 0 [626903.532391] sd 11:0:0:0: [sdd] Device not ready [626903.532393] sd 11:0:0:0: [sdd] Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE [626903.532396] sd 11:0:0:0: [sdd] Sense Key : Not Ready [current] [626903.532400] sd 11:0:0:0: [sdd] Add. Sense: Medium not present [626903.532404] sd 11:0:0:0: [sdd] CDB: Read(10): 28 00 00 00 00 08 00 00 08 00 [626903.532412] end_request: I/O error, dev sdd, sector 8 [...] [626903.812724] sd 11:0:0:0: [sdd] Device not ready [626903.812725] sd 11:0:0:0: [sdd] Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE [626903.812728] sd 11:0:0:0: [sdd] Sense Key : Not Ready [current] [626903.812731] sd 11:0:0:0: [sdd] Add. Sense: Medium not present [626903.812734] sd 11:0:0:0: [sdd] CDB: Read(10): 28 00 00 00 00 00 00 00 08 00 [626903.812740] end_request: I/O error, dev sdd, sector 0 [626903.814725] sd 11:0:0:0: [sdd] Device not ready [626903.814728] sd 11:0:0:0: [sdd] Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE [626903.814731] sd 11:0:0:0: [sdd] Sense Key : Not Ready [current] [626903.814735] sd 11:0:0:0: [sdd] Add. Sense: Medium not present [626903.814739] sd 11:0:0:0: [sdd] CDB: Read(10): 28 00 00 00 00 00 00 00 08 00 [626903.814747] end_request: I/O error, dev sdd, sector 0 [626903.820536] sdd: detected capacity change from 3947888640 to 0 That's why I chose to use Samsung sd cards instead. Everything was fine for 2-3 whole months, but now I had one of my systems getting the exact same symptoms as when using the Kingston cards. Did anyone experience this kind of problem using his beagle bone so far ? Does anyone have an idea of something that could damage the SD card so much which is or isn't directly related to the use of a beagle bone black (Heat, compulsive logging, ...)
[beagleboard] SSH issues when doing first connection
Hey, I got my first BBB today and when I tried to connect it through ssh ssh root@192.168.7.2 I got an error saying ssh_exchange_identification: Connection closed by remote host I tried googling the error and finding out what is the cause of the error but all in vain. Any suggestions to resolve the issue ? -- For more options, visit http://beagleboard.org/discuss --- You received this message because you 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] Trying to compile pcsclite from debian
The problem is peculiar to some Angstrom images such as the v2012.12 one. Turns out /usr/bin/flex uses a hard-wired reference to the m4 executable where it lay on the machine where the Angstrom image was cross-compiled! (Thanks to Rob Clark for finding this out, http://gstreamer-devel.966125.n4.nabble.com/Installation-error-td969071.html ) The ugly but simple fix is to create a symbolic link at the place flex looks for m4: # mkdir -p /build/v2012.12/build/tmp-angstrom_v2012_12-eglibc/sysroots/x86_64-linux/usr/bin # ln -s /usr/bin/m4 /build/v2012.12/build/tmp-angstrom_v2012_12-eglibc/sysroots/x86_64-linux/usr/bin/m4 You can find the path by using a hex editor to look at the /usr/bin/flex binary (search for /m4). Or you can define the M4 environment variable before calling flex: # M4=/usr/bin/m4 flex *file*.l -- For more options, visit http://beagleboard.org/discuss --- You received this message because you 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: Using MMC1_DAT pins as GPIO
Thanks TJF... I had tried changing the pin-muxing using the device tree overlay and that works for all other pins but not the MMC1 pins... would libpruio work..? On Thursday, June 12, 2014 1:19:10 AM UTC-4, TJF wrote: You can use libpruio http://beagleboard.org/project/libpruio/ to do the pin-muxing. -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups BeagleBoard group. To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [beagleboard] Can't make pwm work on cape-universal
Thank you - unfortunately the boot order of the pwm indexes as applied to pins is random (i.e. pin P8_13 is 6 one day and something else another.) On Thursday, June 5, 2014 1:23:50 PM UTC-7, Charles Steinkuehler wrote: On 6/5/2014 12:11 PM, Charles Steinkuehler wrote: On 6/5/2014 11:52 AM, maxmike wrote: No need to modify cape-universal. Since I'm on the clock what I'll do is remove the pwm pins I need from cape-universal .dts and recompile; then load the perfectly good, existing /lib/firmware entries for pwm. That will work, of course, but the whole reason I went through this exercise was to make it unnecessary for folks to fiddle with editing overlay files. OK, I got a chance to review this, and as I thought you just need to export the PWM channels so you can play with them via sysfs. Some details are available on the TI wiki: http://processors.wiki.ti.com/index.php/Linux_Core_PWM_User%27s_Guide Executive summary...as root: for PWM in 0 1 2 3 4 5 6 7 ; do echo $PWM /sys/class/pwm/export done ...and you'll have your period and duty files: find /sys/devices/ocp.*/ -name '*_ns' /sys/devices/ocp.3/48302000.epwmss/48302200.ehrpwm/pwm/pwm3/duty_ns /sys/devices/ocp.3/48302000.epwmss/48302200.ehrpwm/pwm/pwm3/period_ns /sys/devices/ocp.3/48302000.epwmss/48302200.ehrpwm/pwm/pwm4/duty_ns /sys/devices/ocp.3/48302000.epwmss/48302200.ehrpwm/pwm/pwm4/period_ns /sys/devices/ocp.3/48304000.epwmss/48304100.ecap/pwm/pwm7/duty_ns /sys/devices/ocp.3/48304000.epwmss/48304100.ecap/pwm/pwm7/period_ns /sys/devices/ocp.3/48304000.epwmss/48304200.ehrpwm/pwm/pwm5/duty_ns /sys/devices/ocp.3/48304000.epwmss/48304200.ehrpwm/pwm/pwm5/period_ns /sys/devices/ocp.3/48304000.epwmss/48304200.ehrpwm/pwm/pwm6/duty_ns /sys/devices/ocp.3/48304000.epwmss/48304200.ehrpwm/pwm/pwm6/period_ns /sys/devices/ocp.3/4830.epwmss/48300200.ehrpwm/pwm/pwm0/duty_ns /sys/devices/ocp.3/4830.epwmss/48300200.ehrpwm/pwm/pwm0/period_ns /sys/devices/ocp.3/4830.epwmss/48300200.ehrpwm/pwm/pwm1/duty_ns /sys/devices/ocp.3/4830.epwmss/48300200.ehrpwm/pwm/pwm1/period_ns /sys/devices/ocp.3/4830.epwmss/48300100.ecap/pwm/pwm2/duty_ns /sys/devices/ocp.3/4830.epwmss/48300100.ecap/pwm/pwm2/period_ns -- 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] Can't make pwm work on cape-universal
I believe Jason indicated the numbering was based on the order they are listed in the device tree, so it should be consistent if you're not changing overlays. On 6/12/2014 2:12 PM, maxmike wrote: Thank you - unfortunately the boot order of the pwm indexes as applied to pins is random (i.e. pin P8_13 is 6 one day and something else another.) On Thursday, June 5, 2014 1:23:50 PM UTC-7, Charles Steinkuehler wrote: On 6/5/2014 12:11 PM, Charles Steinkuehler wrote: On 6/5/2014 11:52 AM, maxmike wrote: No need to modify cape-universal. Since I'm on the clock what I'll do is remove the pwm pins I need from cape-universal .dts and recompile; then load the perfectly good, existing /lib/firmware entries for pwm. That will work, of course, but the whole reason I went through this exercise was to make it unnecessary for folks to fiddle with editing overlay files. OK, I got a chance to review this, and as I thought you just need to export the PWM channels so you can play with them via sysfs. Some details are available on the TI wiki: http://processors.wiki.ti.com/index.php/Linux_Core_PWM_User%27s_Guide Executive summary...as root: for PWM in 0 1 2 3 4 5 6 7 ; do echo $PWM /sys/class/pwm/export done ...and you'll have your period and duty files: find /sys/devices/ocp.*/ -name '*_ns' /sys/devices/ocp.3/48302000.epwmss/48302200.ehrpwm/pwm/pwm3/duty_ns /sys/devices/ocp.3/48302000.epwmss/48302200.ehrpwm/pwm/pwm3/period_ns /sys/devices/ocp.3/48302000.epwmss/48302200.ehrpwm/pwm/pwm4/duty_ns /sys/devices/ocp.3/48302000.epwmss/48302200.ehrpwm/pwm/pwm4/period_ns /sys/devices/ocp.3/48304000.epwmss/48304100.ecap/pwm/pwm7/duty_ns /sys/devices/ocp.3/48304000.epwmss/48304100.ecap/pwm/pwm7/period_ns /sys/devices/ocp.3/48304000.epwmss/48304200.ehrpwm/pwm/pwm5/duty_ns /sys/devices/ocp.3/48304000.epwmss/48304200.ehrpwm/pwm/pwm5/period_ns /sys/devices/ocp.3/48304000.epwmss/48304200.ehrpwm/pwm/pwm6/duty_ns /sys/devices/ocp.3/48304000.epwmss/48304200.ehrpwm/pwm/pwm6/period_ns /sys/devices/ocp.3/4830.epwmss/48300200.ehrpwm/pwm/pwm0/duty_ns /sys/devices/ocp.3/4830.epwmss/48300200.ehrpwm/pwm/pwm0/period_ns /sys/devices/ocp.3/4830.epwmss/48300200.ehrpwm/pwm/pwm1/duty_ns /sys/devices/ocp.3/4830.epwmss/48300200.ehrpwm/pwm/pwm1/period_ns /sys/devices/ocp.3/4830.epwmss/48300100.ecap/pwm/pwm2/duty_ns /sys/devices/ocp.3/4830.epwmss/48300100.ecap/pwm/pwm2/period_ns -- Charles Steinkuehler cha...@steinkuehler.net javascript: -- Charles Steinkuehler char...@steinkuehler.net -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups BeagleBoard group. To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [beagleboard] BeagleBone Black rev C + Ubuntu 13.04 + UWN200 wifi adapter?
Yes, this worked fine for me, too, thanks! On Tuesday, June 10, 2014 5:52:24 PM UTC-5, RobertCNelson wrote: On Tue, Jun 10, 2014 at 5:23 PM, Zach Cox zco...@gmail.com javascript: wrote: Laughs, so we had setup that initial debian image to work with UWN200 out of the box. Yeah I know :) and it did work on that debian after a few simple commands, but I need Ubuntu 13.04 specifically for ROS. Sure, we can make 13.04 work too.. So the question, who's 13.04 are you using? I believe I'm using your 13.04, here are the instructions I followed to successfully flash 13.04 to the emmc: http://avedo.net/653/flashing-ubuntu-13-04-or-debian-wheezy-to-the-beaglebone-black-emmc/ http://elinux.org/Beagleboard:Ubuntu_On_BeagleBone_Black Well, we will see how old that is.. First, check that a /etc/rcn-ee.conf exists.. If it does, add: third_party_modules=enable If it's not, echo distro=Ubuntu /tmp/rcn-ee.conf echo deb_distribution=Ubuntu /tmp/rcn-ee.conf echo third_party_modules=enable /tmp/rcn-ee.conf sudo mv /tmp/rcn-ee.conf /etc/rcn-ee.conf Then run: wget http://rcn-ee.net/deb/raring-armhf/v3.8.13-bone56/install-me.sh sudo /bin/bash install-me.sh 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] Can both USB connections be used the same?
My WiFi antennea seems to need to be plugged directly into the BBB to work. In the powered USB hub it isn't recognized on boot. Ditto for the Logitech 920 webcam. Can I make a USB female-female adapter to plug one device into the USB client (mini) port on the BBB? Will that work? What are the rest of you doing about this limitation? -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups BeagleBoard group. To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [beagleboard] Can both USB connections be used the same?
On Thu, Jun 12, 2014 at 2:53 PM, Russ Hall rllf...@gmail.com wrote: My WiFi antennea seems to need to be plugged directly into the BBB to work. In the powered USB hub it isn't recognized on boot. Ditto for the Logitech 920 webcam. Can I make a USB female-female adapter to plug one device into the USB client (mini) port on the BBB? Will that work? What are the rest of you doing about this limitation? Nope, it's wired for device mode only.. 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: beagle bone for tft on spi + dac on I2C + analog potentiometer
Have you done your project? Hi, im trying to conect a tft 1.8 to beaglebone. Can you list the couplers and others componentes that you use? I´m afraid about do some damage the board . Thank you. Em segunda-feira, 16 de abril de 2012 13h47min58s UTC-3, lwi escreveu: Hi, I am planning to start a project based on a beagle bone. I want to ba able to connect a tft display by spi and a microcontroller (DAC) by I2C bus. The tft display is http://www.adafruit.com/products/358. I also need to : - plug a analog potentiometer - drive relays So what should I need to plug everything ? I have a level shifter to plug the beagle bone I2C (1.8V I think) on the 5V I2C bus of the dac (adum part). I have also some opto coupler like TIL111. Thanks for your help. Sincerely, Lwi. -- For more options, visit http://beagleboard.org/discuss --- You received this message because you 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] setting up a cross compile
I was curious if anyone has insight into the issue I am having.
I have setup LinuxMintDebian in a VMWare session on my Mac. I then went
and installed gcc/g++ with an apt-get install build-essential
I then went here Robert's kernel build
http://eewiki.net/display/linuxonarm/BeagleBone+Black#BeagleBoneBlack-BasicRequirements:
and
did the following:
dpkg --add-architecture i386
wget -c https:
//releases.linaro.org/14.03/components/toolchain/binaries/gcc-linaro-arm-linux-gnueabihf-4.8-2014.03_linux.tar.xz
tar xf gcc-linaro-arm-linux-gnueabihf-4.8-2014.03_linux.tar.xz
export CC=`pwd`/gcc-linaro-arm-linux-gnueabihf-4.8-2014
.03_linux/bin/arm-linux-gnueabihf-
However, when I do the test
${CC}gcc --version
I get the following:
/root/toolchain/gcc-linaro-arm-linux-gnueabihf-4.8-2014.03_linux/bin/arm-linux-gnueabihf-gcc:
No such file or directory
Yes, I can do an ls and see the file at the location it specifies:
ls
/root/toolchain/gcc-linaro-arm-linux-gnueabihf-4.8-2014.03_linux/bin/arm-linux-gnueabihf-gcc
Gives this:
/root/toolchain/gcc-linaro-arm-linux-gnueabihf-4.8-2014.03_linux/bin/arm-linux-gnueabihf-gcc
The wiki indicates an error is the libraries not loaded, but I got no error
from the dpkg command that was indicated in the wiki
Is there something else I missed?
--
For more options, visit http://beagleboard.org/discuss
---
You received this message because you 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] setting up a cross compile
On Thu, Jun 12, 2014 at 3:09 PM, Charles Kerr charlesker...@gmail.com wrote:
I was curious if anyone has insight into the issue I am having.
I have setup LinuxMintDebian in a VMWare session on my Mac. I then went and
installed gcc/g++ with an apt-get install build-essential
I then went here Robert's kernel build and did the following:
dpkg --add-architecture i386
did you actually install the lib's listed?
sudo apt-get update ; sudo apt-get install libc6:i386 libstdc++6:i386
libncurses5:i386 zlib1g:i386
wget -c
https://releases.linaro.org/14.03/components/toolchain/binaries/gcc-linaro-arm-linux-gnueabihf-4.8-2014.03_linux.tar.xz
tar xf gcc-linaro-arm-linux-gnueabihf-4.8-2014.03_linux.tar.xz
export
CC=`pwd`/gcc-linaro-arm-linux-gnueabihf-4.8-2014.03_linux/bin/arm-linux-gnueabihf-
However, when I do the test
${CC}gcc --version
I get the following:
/root/toolchain/gcc-linaro-arm-linux-gnueabihf-4.8-2014.03_linux/bin/arm-linux-gnueabihf-gcc:
No such file or directory
Yes, I can do an ls and see the file at the location it specifies:
ls
/root/toolchain/gcc-linaro-arm-linux-gnueabihf-4.8-2014.03_linux/bin/arm-linux-gnueabihf-gcc
Gives this:
/root/toolchain/gcc-linaro-arm-linux-gnueabihf-4.8-2014.03_linux/bin/arm-linux-gnueabihf-gcc
The wiki indicates an error is the libraries not loaded, but I got no error
from the dpkg command that was indicated in the wiki
Is there something else I missed?
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] Can't make pwm work on cape-universal
Aaaah - that's the pinmux order; had it wrong. Thanks. On Thursday, June 12, 2014 12:19:35 PM UTC-7, Charles Steinkuehler wrote: I believe Jason indicated the numbering was based on the order they are listed in the device tree, so it should be consistent if you're not changing overlays. On 6/12/2014 2:12 PM, maxmike wrote: Thank you - unfortunately the boot order of the pwm indexes as applied to pins is random (i.e. pin P8_13 is 6 one day and something else another.) On Thursday, June 5, 2014 1:23:50 PM UTC-7, Charles Steinkuehler wrote: On 6/5/2014 12:11 PM, Charles Steinkuehler wrote: On 6/5/2014 11:52 AM, maxmike wrote: No need to modify cape-universal. Since I'm on the clock what I'll do is remove the pwm pins I need from cape-universal .dts and recompile; then load the perfectly good, existing /lib/firmware entries for pwm. That will work, of course, but the whole reason I went through this exercise was to make it unnecessary for folks to fiddle with editing overlay files. OK, I got a chance to review this, and as I thought you just need to export the PWM channels so you can play with them via sysfs. Some details are available on the TI wiki: http://processors.wiki.ti.com/index.php/Linux_Core_PWM_User%27s_Guide Executive summary...as root: for PWM in 0 1 2 3 4 5 6 7 ; do echo $PWM /sys/class/pwm/export done ...and you'll have your period and duty files: find /sys/devices/ocp.*/ -name '*_ns' /sys/devices/ocp.3/48302000.epwmss/48302200.ehrpwm/pwm/pwm3/duty_ns /sys/devices/ocp.3/48302000.epwmss/48302200.ehrpwm/pwm/pwm3/period_ns /sys/devices/ocp.3/48302000.epwmss/48302200.ehrpwm/pwm/pwm4/duty_ns /sys/devices/ocp.3/48302000.epwmss/48302200.ehrpwm/pwm/pwm4/period_ns /sys/devices/ocp.3/48304000.epwmss/48304100.ecap/pwm/pwm7/duty_ns /sys/devices/ocp.3/48304000.epwmss/48304100.ecap/pwm/pwm7/period_ns /sys/devices/ocp.3/48304000.epwmss/48304200.ehrpwm/pwm/pwm5/duty_ns /sys/devices/ocp.3/48304000.epwmss/48304200.ehrpwm/pwm/pwm5/period_ns /sys/devices/ocp.3/48304000.epwmss/48304200.ehrpwm/pwm/pwm6/duty_ns /sys/devices/ocp.3/48304000.epwmss/48304200.ehrpwm/pwm/pwm6/period_ns /sys/devices/ocp.3/4830.epwmss/48300200.ehrpwm/pwm/pwm0/duty_ns /sys/devices/ocp.3/4830.epwmss/48300200.ehrpwm/pwm/pwm0/period_ns /sys/devices/ocp.3/4830.epwmss/48300200.ehrpwm/pwm/pwm1/duty_ns /sys/devices/ocp.3/4830.epwmss/48300200.ehrpwm/pwm/pwm1/period_ns /sys/devices/ocp.3/4830.epwmss/48300100.ecap/pwm/pwm2/duty_ns /sys/devices/ocp.3/4830.epwmss/48300100.ecap/pwm/pwm2/period_ns -- Charles Steinkuehler cha...@steinkuehler.net javascript: -- 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.
[beagleboard] Re: Reading analog inputs fast in beaglebone black
I ended up using libpruio, the installation instrucions are kind of scattered but it works really well. 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/d/optout.
[beagleboard] Problems with Multiple Device Tree Overlays
I was having an issue loading multiple device tree overlays. I was hoping that someone could help me or maybe point me to a discussion thread I have overlooked. The issue is that I have three device tree overlays that I would like to manually upload on my beaglebone. However, only the first of the overlays that I echo to slots will show up on pingroups and be recognized by the machine. My device info: root@arm:/boot/uboot# uname -a Linux arm 3.8.13-bone40 #1 SMP Fri Jan 31 07:31:37 UTC 2014 armv7l GNU/Linux This is how my slot configuration appears upon starting. As can be seen there are 4 overlays that are automatically loaded: root@arm:/lib/firmware# cat /sys/devices/bone_capemgr.8/slots 0: 54:PF--- 1: 55:PF--- 2: 56:PF--- 3: 57:PF--- 4: ff:P-O-L Override Board Name,00A0,Override Manuf,BB-UART2 6: ff:P-O-L Override Board Name,00A0,Override Manuf,BB-UART4 7: ff:P-O-L Override Board Name,00A0,Override Manuf,BB-UART5 8: ff:P-O-L Override Board Name,00A0,Override Manuf,BB-SPIDEV1 Using the command below I am able to manually add an overlay. This will be recognized in the pingroups without issue. root@arm:/lib/firmware# echo enable-uart3 /sys/devices/bone_capemgr.8/slots How my slots appear after the addition. 0: 54:PF--- 1: 55:PF--- 2: 56:PF--- 3: 57:PF--- 4: ff:P-O-L Override Board Name,00A0,Override Manuf,BB-UART2 6: ff:P-O-L Override Board Name,00A0,Override Manuf,BB-UART4 7: ff:P-O-L Override Board Name,00A0,Override Manuf,BB-UART5 8: ff:P-O-L Override Board Name,00A0,Override Manuf,BB-SPIDEV1 11: ff:P-O-L Override Board Name,00A0,Override Manuf,enable-uart3 However when I try to add another overlay, it appears in slots but does have any effect in pingroups. The commands I used are below. root@arm:/lib/firmware# echo enable-gpio32 /sys/devices/bone_capemgr.8/slots root@arm:/boot/uboot# cat /sys/devices/bone_capemgr.8/slots 0: 54:PF--- 1: 55:PF--- 2: 56:PF--- 3: 57:PF--- 4: ff:P-O-L Override Board Name,00A0,Override Manuf,BB-UART2 6: ff:P-O-L Override Board Name,00A0,Override Manuf,BB-UART4 7: ff:P-O-L Override Board Name,00A0,Override Manuf,BB-UART5 8: ff:P-O-L Override Board Name,00A0,Override Manuf,BB-SPIDEV1 11: ff:P-O-L Override Board Name,00A0,Override Manuf,enable-uart3 12: ff:P-O-L Override Board Name,00A0,Override Manuf,enable-gpio32 My third overlay is called enable-dcan1 but it exhibits the same behavior as above so I will not show the process of adding it. Initially assumed that I had compiled an overlay incorrectly, but upon further experimentation I realized that the first overlay was always the one that got recognized by the machine and the other two were ignored. A few of my thoughts: Could the skipping of slots (4-6) and (8-11) be causing some sort of issue. Is there a maximum number of possible overlays that I have reached which prevents any more from being recognized. I would appreciate any help that people can supply. Thanks, Tim Rackers -- For more options, visit http://beagleboard.org/discuss --- You received this message because you 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] setting up a cross compile
I had interpreted the command listed in the table:
dpkg --add-architecture i386
as what was to install them. I realized now that was in error.
I did an apt-get install gcc-multilibs and it is now working.
Thank you
On Thursday, June 12, 2014 4:14:09 PM UTC-4, RobertCNelson wrote:
On Thu, Jun 12, 2014 at 3:09 PM, Charles Kerr charle...@gmail.com
javascript: wrote:
I was curious if anyone has insight into the issue I am having.
I have setup LinuxMintDebian in a VMWare session on my Mac. I then went
and
installed gcc/g++ with an apt-get install build-essential
I then went here Robert's kernel build and did the following:
dpkg --add-architecture i386
did you actually install the lib's listed?
sudo apt-get update ; sudo apt-get install libc6:i386 libstdc++6:i386
libncurses5:i386 zlib1g:i386
wget -c
https://releases.linaro.org/14.03/components/toolchain/binaries/gcc-linaro-arm-linux-gnueabihf-4.8-2014.03_linux.tar.xz
tar xf gcc-linaro-arm-linux-gnueabihf-4.8-2014.03_linux.tar.xz
export
CC=`pwd`/gcc-linaro-arm-linux-gnueabihf-4.8-2014.03_linux/bin/arm-linux-gnueabihf-
However, when I do the test
${CC}gcc --version
I get the following:
/root/toolchain/gcc-linaro-arm-linux-gnueabihf-4.8-2014.03_linux/bin/arm-linux-gnueabihf-gcc:
No such file or directory
Yes, I can do an ls and see the file at the location it specifies:
ls
/root/toolchain/gcc-linaro-arm-linux-gnueabihf-4.8-2014.03_linux/bin/arm-linux-gnueabihf-gcc
Gives this:
/root/toolchain/gcc-linaro-arm-linux-gnueabihf-4.8-2014.03_linux/bin/arm-linux-gnueabihf-gcc
The wiki indicates an error is the libraries not loaded, but I got no
error
from the dpkg command that was indicated in the wiki
Is there something else I missed?
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: Dude, where's my BeagleBone Black?
SparkFun has 24 in stock as of a few minutes ago 6/12/2014 On Sunday, April 13, 2014 7:07:00 PM UTC-4, Jason Kridner wrote: Just about to post this to http://beagleboard.org/blog, but it wouldn't hurt to get a bit of community feedback before pushing this out there Dude, where's my BeagleBone Black? I hear that question a LOT. No, we weren't sleeping, but sometimes it takes a minute for a plan to come together. And don't you love it when a plan comes together? Your BeagleBone Black is on the way and below are the whys and hows. Buying a BeagleBone Black back around October last year was easy---and then suddenly they were gone. Having a big launch and then slowing down to a more steady pace of production is what is normally expected. Demand was strong, but distributors were showing a small amount of stock and people were getting their boards on demand. Based on the status, distributors had requested CircuitCo (the Richardson, Texas based manufacturer of all official BeagleBoard.org boards) to provide boards at a certain pace, and production dropped from about 6,000 a week at launch to around 3,000 a week. Then came Radio Shack, filling their stores with Make's Getting Started with BeagleBone kit. Then the Christmas rush. Then the Georgia Tech massively open online course on control of mobile robots hosted on Coursera. We had a couple of small production boosts, but haven't been able to make any dent in the demand. Everyone is starting to find out what BeagleBone Black can do, using it in their classes, hobbies, prototypes---and products. When it comes to those people using a BeagleBone Black in an end product, well, the BeagleBoard.org terms and conditions clearly say we aren't responsible for the quality in those cases. Nevertheless, the quality speaks for itself and many people are choosing to simply drop them into things beyond just a few prototype units. In practice, we'll never know unless you try to return a bunch of boards at once for repairs. Our desire is that people using the boards in products work directly with a contract manufacturer or distributor to enable boards builds to be planned out in time and with terms and conditions that won't hurt BeagleBoard.org's ability to supply classrooms, hobbyists and professionals building prototypes. Still, if distributors show stock, I expect people building products to continue to chew up some of the board supply. While these people building products are certainly sucking up a lot of boards, it is clear they aren't the only source of the high demand. Some of our distribution partners, most notably Adafruit and Special Computing, put quantity limits of one board per customer on their orders to help keep supply going to individual makers. I took a look at Adafruit's website while they were showing some sock and observed board disappearing at the rate of about 2-3 PER MINUTE. One tweet from me and they were sold out again. This all leads to the obvious conclusion: we need more capacity. To accomplish this, we are taking a multiple prong approach of increasing capacity at CircuitCo as well as bringing on an additional manufacturer. These two prongs are summarized below. Prong #1 - Ramping up production at CircuitCo Ramping up production costs money. More test equipment is needed. Orders on various parts must be accelerated. Additional staff must be hired to run additional shifts. CircuitCo has been fantastic at taking the risk for us, but the margins for BeagleBone Black aren't the friendliest for them to take on these additional costs. At initial launch, it is a benefit for them to get exposed to more customers for their core business, complex circuit assembly and engineering services, but shipping more of the exact same board isn't going to give them a lot more exposure. We're really close to shifting the distribution shipped on our boards from Angstrom Distribution to Debian. Feedback from different people, especially Adafruit, tells us this will improve usability in the largest segments of our community. Angstrom Distribution is much more customizable and is very friendly to professional developers looking to tweak the most out of the system, but for many novices it introduces a barrier to learning. Debian is the basis for Ubuntu, includes ARM Cortex-A8 support in their mainline and is very familiar to a huge population of developers. It also takes a bit more space on the flash storage to provide the best user experience. To provide the best experience of using Debian on BeagleBone Black, we are connecting the switch-over to an increase in the on-board eMMC flash storage from 2GB to 4GB, leaving more free room in which you can work. The eMMC is faster and more reliable than micro-SD cards, so this is adding a lot of value---and a little bit of cost. These BeagleBone Blacks with Debian and
[beagleboard] Re: SSH issues when doing first connection
meetshah1...@gmail.com wrote: [-- text/plain, encoding 7bit, charset: UTF-8, 21 lines --] Hey, I got my first BBB today and when I tried to connect it through ssh ssh root@192.168.7.2 I got an error saying ssh_exchange_identification: Connection closed by remote host I tried googling the error and finding out what is the cause of the error but all in vain. Any suggestions to resolve the issue ? Are you able to connect using ssh at all or does it always fail like this? I'm having similar problems but I *can* connect using ssh, it's just that it fails sometimes with the above error. -- Chris Green · -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups BeagleBoard group. To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [beagleboard] Can't make UART work with Python and AdaFruitBBB
I don't understand your complaint. If you're using the Adafruit BBIO library, it creates the necessary UART devices in the device tree on the fly (by placing its own ADAFRUIT-UART files in /lib/firmware and writing to /sys/devices/bone_capmgr.*/slots). So it really is pretty easy to use -- it's designed for non-tech types to get maker projects running on the BBB. Surprised you asked over here rather than in the more-relevant Adafruit forum on BBIO. On Thursday, June 12, 2014 8:43:33 AM UTC-7, cla...@logmatch.com.br wrote: You are right. root@beaglebone1:~# dmesg |grep console [0.00] Kernel command line: console=ttyO0,115200n8 quiet drm.debug=7 root=/dev/mmcblk0p2 ro rootfstype=ext4 rootwait [0.222807] console [ttyO0] enabled but I can't found another uEnv.txt in Angstrom system. So I probably will have to generate one that's correct ? These are the things people had to do when they will use UART in their systems? I believe that we could have a more prepared system for development ;) Anyway I'll try to look what can i do here Thank you all you help Robert Cláudio B. -- For more options, visit http://beagleboard.org/discuss --- You received this message because you 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: Dude, where's my BeagleBone Black?
Hi, FWIW I got an email overnight (4am Aussie time) saying Adafruit had restocked. By the time I'd woken up and got to my computer about 4 hours later, they'd sold out. I note that Sparkfun have also sold out. I did have email notifications set up from Element 14, but I've not heard about their stock level. Cheers, Pete. On 13/06/14 06:45, armstrong.ja...@gmail.com wrote: SparkFun has 24 in stock as of a few minutes ago 6/12/2014 On Sunday, April 13, 2014 7:07:00 PM UTC-4, Jason Kridner wrote: Just about to post this to http://beagleboard.org/blog, but it wouldn't hurt to get a bit of community feedback before pushing this out there Dude, where's my BeagleBone Black? I hear that question a LOT. No, we weren't sleeping, but sometimes it takes a minute for a plan to come together. And don't you love it when a plan comes together? Your BeagleBone Black is on the way and below are the whys and hows. Buying a BeagleBone Black back around October last year was easy---and then suddenly they were gone. Having a big launch and then slowing down to a more steady pace of production is what is normally expected. Demand was strong, but distributors were showing a small amount of stock and people were getting their boards on demand. Based on the status, distributors had requested CircuitCo (the Richardson, Texas based manufacturer of all official BeagleBoard.org boards) to provide boards at a certain pace, and production dropped from about 6,000 a week at launch to around 3,000 a week. Then came Radio Shack, filling their stores with Make's Getting Started with BeagleBone kit. Then the Christmas rush. Then the Georgia Tech massively open online course on control of mobile robots hosted on Coursera. We had a couple of small production boosts, but haven't been able to make any dent in the demand. Everyone is starting to find out what BeagleBone Black can do, using it in their classes, hobbies, prototypes---and products. When it comes to those people using a BeagleBone Black in an end product, well, the BeagleBoard.org terms and conditions clearly say we aren't responsible for the quality in those cases. Nevertheless, the quality speaks for itself and many people are choosing to simply drop them into things beyond just a few prototype units. In practice, we'll never know unless you try to return a bunch of boards at once for repairs. Our desire is that people using the boards in products work directly with a contract manufacturer or distributor to enable boards builds to be planned out in time and with terms and conditions that won't hurt BeagleBoard.org's ability to supply classrooms, hobbyists and professionals building prototypes. Still, if distributors show stock, I expect people building products to continue to chew up some of the board supply. While these people building products are certainly sucking up a lot of boards, it is clear they aren't the only source of the high demand. Some of our distribution partners, most notably Adafruit and Special Computing, put quantity limits of one board per customer on their orders to help keep supply going to individual makers. I took a look at Adafruit's website while they were showing some sock and observed board disappearing at the rate of about 2-3 PER MINUTE. One tweet from me and they were sold out again. This all leads to the obvious conclusion: we need more capacity. To accomplish this, we are taking a multiple prong approach of increasing capacity at CircuitCo as well as bringing on an additional manufacturer. These two prongs are summarized below. Prong #1 - Ramping up production at CircuitCo Ramping up production costs money. More test equipment is needed. Orders on various parts must be accelerated. Additional staff must be hired to run additional shifts. CircuitCo has been fantastic at taking the risk for us, but the margins for BeagleBone Black aren't the friendliest for them to take on these additional costs. At initial launch, it is a benefit for them to get exposed to more customers for their core business, complex circuit assembly and engineering services, but shipping more of the exact same board isn't going to give them a lot more exposure. We're really close to shifting the distribution shipped on our boards from Angstrom Distribution to Debian. Feedback from different people, especially Adafruit, tells us this will improve usability in the largest segments of our community. Angstrom Distribution is much more customizable and is very friendly to professional developers looking to tweak the most out of the system, but for many novices it introduces a barrier to learning. Debian is the basis for Ubuntu, includes ARM Cortex-A8 support in their mainline and is very familiar to a huge population of developers. It also takes a bit more space on the flash storage to provide the best user experience. To provide the best experience of using Debian on BeagleBone Black, we are connecting the switch-over to an increase in the on-board
[beagleboard] issues with instructions for u-boot for beagleboard-xm
from http://eewiki.net/display/linuxonarm/BeagleBoard we have the following procedure: git clone git://git.denx.de/u-boot.git cd u-boot/ git checkout v2014.07-rc3 -b tmp git revert --no-edit a704a6d615179a25f556c99d31cbc4ee366ffb54 currently the git revert doesn't work. Error message is: error: could not revert a704a6d... ARM: omap3: Implement dpll5 (HSUSB clk) workaround for OMAP36xx/AM/DM37xx according to errata sprz318e. hint: after resolving the conflicts, mark the corrected paths hint: with 'git add paths' or 'git rm paths' hint: and commit the result with 'git commit' -- For more options, visit http://beagleboard.org/discuss --- You received this message because you 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] issues with instructions for u-boot for beagleboard-xm
On Thu, Jun 12, 2014 at 6:07 PM, Ivan Nazarenko ivan.nazare...@gmail.com wrote: from http://eewiki.net/display/linuxonarm/BeagleBoard we have the following procedure: git clone git://git.denx.de/u-boot.git cd u-boot/ git checkout v2014.07-rc3 -b tmp git revert --no-edit a704a6d615179a25f556c99d31cbc4ee366ffb54 currently the git revert doesn't work. Error message is: error: could not revert a704a6d... ARM: omap3: Implement dpll5 (HSUSB clk) workaround for OMAP36xx/AM/DM37xx according to errata sprz318e. hint: after resolving the conflicts, mark the corrected paths hint: with 'git add paths' or 'git rm paths' hint: and commit the result with 'git commit' Considering the v3.15.x branch is pretty feature complete, I guess it's time i drop that revert' and the ancient board file instructions from that wiki. 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] issues with instructions for u-boot for beagleboard-xm
On Thu, 12 Jun 2014 18:34:33 -0500 Robert Nelson robertcnel...@gmail.com wrote: On Thu, Jun 12, 2014 at 6:07 PM, Ivan Nazarenko ivan.nazare...@gmail.com wrote: from http://eewiki.net/display/linuxonarm/BeagleBoard we have the following procedure: git clone git://git.denx.de/u-boot.git cd u-boot/ git checkout v2014.07-rc3 -b tmp git revert --no-edit a704a6d615179a25f556c99d31cbc4ee366ffb54 currently the git revert doesn't work. Error message is: error: could not revert a704a6d... ARM: omap3: Implement dpll5 (HSUSB clk) workaround for OMAP36xx/AM/DM37xx according to errata sprz318e. hint: after resolving the conflicts, mark the corrected paths hint: with 'git add paths' or 'git rm paths' hint: and commit the result with 'git commit' Considering the v3.15.x branch is pretty feature complete, I guess it's time i drop that revert' and the ancient board file instructions from that wiki. Regards, -- Robert Nelson http://www.rcn-ee.com/ Ok, I will try to make it work with 3.15 then. Regards, Ivan -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups BeagleBoard group. To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [beagleboard] issues with instructions for u-boot for beagleboard-xm
Ok, I will try to make it work with 3.15 then. v3.15.x works fine on the xM, the usb pll errata is enabled, 1Ghz operation, DRM kms video, etc.. The old board file stuff was just old.. 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: Dude, where's my BeagleBone Black?
On 13/06/14 09:33, Bill Mar wrote: Special Computing has stock in BBB kits and boards. https://specialcomp.com/beaglebone/ Special Computing +1-480-818-5745 I must be missing something... What's with the three different prices? The difference as pictured between 'Kit (Hobbyist)' and 'Kit' seems non-existent, and I find it hard to imagine that the 'Board' (a) isn't shipped in a box (b) costs $15 more for not having a box or USB cable. I don't get it. Pete. On Thu, Jun 12, 2014 at 3:49 PM, Peter Lawler blee...@gmail.com wrote: Hi, FWIW I got an email overnight (4am Aussie time) saying Adafruit had restocked. By the time I'd woken up and got to my computer about 4 hours later, they'd sold out. I note that Sparkfun have also sold out. I did have email notifications set up from Element 14, but I've not heard about their stock level. Cheers, Pete. On 13/06/14 06:45, armstrong.ja...@gmail.com wrote: SparkFun has 24 in stock as of a few minutes ago 6/12/2014 On Sunday, April 13, 2014 7:07:00 PM UTC-4, Jason Kridner wrote: Just about to post this to http://beagleboard.org/blog, but it wouldn't hurt to get a bit of community feedback before pushing this out there Dude, where's my BeagleBone Black? I hear that question a LOT. No, we weren't sleeping, but sometimes it takes a minute for a plan to come together. And don't you love it when a plan comes together? Your BeagleBone Black is on the way and below are the whys and hows. Buying a BeagleBone Black back around October last year was easy---and then suddenly they were gone. Having a big launch and then slowing down to a more steady pace of production is what is normally expected. Demand was strong, but distributors were showing a small amount of stock and people were getting their boards on demand. Based on the status, distributors had requested CircuitCo (the Richardson, Texas based manufacturer of all official BeagleBoard.org boards) to provide boards at a certain pace, and production dropped from about 6,000 a week at launch to around 3,000 a week. Then came Radio Shack, filling their stores with Make's Getting Started with BeagleBone kit. Then the Christmas rush. Then the Georgia Tech massively open online course on control of mobile robots hosted on Coursera. We had a couple of small production boosts, but haven't been able to make any dent in the demand. Everyone is starting to find out what BeagleBone Black can do, using it in their classes, hobbies, prototypes---and products. When it comes to those people using a BeagleBone Black in an end product, well, the BeagleBoard.org terms and conditions clearly say we aren't responsible for the quality in those cases. Nevertheless, the quality speaks for itself and many people are choosing to simply drop them into things beyond just a few prototype units. In practice, we'll never know unless you try to return a bunch of boards at once for repairs. Our desire is that people using the boards in products work directly with a contract manufacturer or distributor to enable boards builds to be planned out in time and with terms and conditions that won't hurt BeagleBoard.org's ability to supply classrooms, hobbyists and professionals building prototypes. Still, if distributors show stock, I expect people building products to continue to chew up some of the board supply. While these people building products are certainly sucking up a lot of boards, it is clear they aren't the only source of the high demand. Some of our distribution partners, most notably Adafruit and Special Computing, put quantity limits of one board per customer on their orders to help keep supply going to individual makers. I took a look at Adafruit's website while they were showing some sock and observed board disappearing at the rate of about 2-3 PER MINUTE. One tweet from me and they were sold out again. This all leads to the obvious conclusion: we need more capacity. To accomplish this, we are taking a multiple prong approach of increasing capacity at CircuitCo as well as bringing on an additional manufacturer. These two prongs are summarized below. Prong #1 - Ramping up production at CircuitCo Ramping up production costs money. More test equipment is needed. Orders on various parts must be accelerated. Additional staff must be hired to run additional shifts. CircuitCo has been fantastic at taking the risk for us, but the margins for BeagleBone Black aren't the friendliest for them to take on these additional costs. At initial launch, it is a benefit for them to get exposed to more customers for their core business, complex circuit assembly and engineering services, but shipping more of the exact same board isn't going to give them a lot more exposure. We're really close to shifting the distribution shipped on our boards from Angstrom Distribution to Debian. Feedback from different people, especially Adafruit, tells us this will improve usability in the largest segments of our community. Angstrom
[beagleboard] Why Do Angstrom and Debian Enumerate the RTC Differently?
I've noticed a difference in behavior between the latest Angstrom Linux image and the latest Debian image available for the BeagleBone Black when it comes to enumerating the real-time clocks present when a RTC Cape is present. [I have the actual clock present by use of a generic breakout board, but not the actual cape.] I am trying to determine if Angstrom Linux has a patch that is not present in Debian, as I prefer the RTC behavior I am seeing in Angstrom. (I'd think Debian would want the Angstrom behavior, because if the user has attached an RTC, then there is most likely a battery backing it; the BBB currently does not support shutdown to the RTC rail only, so the on-board RTC is going to be wrong on a cold boot.) When I tell Angstrom that I have a BB-BONE-RTC cape attached, my RTC (the DS1307) is enumerated as /dev/rtc0. As such, my clock becomes the clock that is used to set the system clock, and is otherwise going to get all of the privileges of being the first RTC. When I tell Debian that I have a BBB-RTC-01 cape attached, the on-board RTC is still enumerated as /dev/rtc0. My RTC is enumerated as /dev/rtc1. As such, the clock is wrong on boot. I used different capes because I was going for firmware already on the BBB. I don't see anything about either DTO that explains the difference in behavior. -- For more options, visit http://beagleboard.org/discuss --- You received this message because you 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] Why Do Angstrom and Debian Enumerate the RTC Differently?
On Thu, Jun 12, 2014 at 9:56 PM, Justin Morgan jdm...@gmail.com wrote: I've noticed a difference in behavior between the latest Angstrom Linux image and the latest Debian image available for the BeagleBone Black when it comes to enumerating the real-time clocks present when a RTC Cape is present. [I have the actual clock present by use of a generic breakout board, but not the actual cape.] I am trying to determine if Angstrom Linux has a patch that is not present in Debian, as I prefer the RTC behavior I am seeing in Angstrom. (I'd think Debian would want the Angstrom behavior, because if the user has attached an RTC, then there is most likely a battery backing it; the BBB currently does not support shutdown to the RTC rail only, so the on-board RTC is going to be wrong on a cold boot.) When I tell Angstrom that I have a BB-BONE-RTC cape attached, my RTC (the DS1307) is enumerated as /dev/rtc0. As such, my clock becomes the clock that is used to set the system clock, and is otherwise going to get all of the privileges of being the first RTC. When I tell Debian that I have a BBB-RTC-01 cape attached, the on-board RTC is still enumerated as /dev/rtc0. My RTC is enumerated as /dev/rtc1. As such, the clock is wrong on boot. I used different capes because I was going for firmware already on the BBB. I don't see anything about either DTO that explains the difference in behavior. Well, i just compared Angstrom's config with the one i've been pushing out for our 3.8 branch.. No difference an any RTC config's.. Probally comes down to Angstrom's much newer version of systemd, or something custom. 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] Why Do Angstrom and Debian Enumerate the RTC Differently?
On 6/12/14, 8:01 PM, Robert Nelson robertcnel...@gmail.com wrote: On Thu, Jun 12, 2014 at 9:56 PM, Justin Morgan jdm...@gmail.com wrote: I've noticed a difference in behavior between the latest Angstrom Linux image and the latest Debian image available for the BeagleBone Black when it comes to enumerating the real-time clocks present when a RTC Cape is present. [I have the actual clock present by use of a generic breakout board, but not the actual cape.] I am trying to determine if Angstrom Linux has a patch that is not present in Debian, as I prefer the RTC behavior I am seeing in Angstrom. (I'd think Debian would want the Angstrom behavior, because if the user has attached an RTC, then there is most likely a battery backing it; the BBB currently does not support shutdown to the RTC rail only, so the on-board RTC is going to be wrong on a cold boot.) When I tell Angstrom that I have a BB-BONE-RTC cape attached, my RTC (the DS1307) is enumerated as /dev/rtc0. As such, my clock becomes the clock that is used to set the system clock, and is otherwise going to get all of the privileges of being the first RTC. When I tell Debian that I have a BBB-RTC-01 cape attached, the on-board RTC is still enumerated as /dev/rtc0. My RTC is enumerated as /dev/rtc1. As such, the clock is wrong on boot. I used different capes because I was going for firmware already on the BBB. I don't see anything about either DTO that explains the difference in behavior. Well, i just compared Angstrom's config with the one i've been pushing out for our 3.8 branch.. No difference an any RTC config's.. Probally comes down to Angstrom's much newer version of systemd, or something custom. Is systemd really creating /dev/rtc0? Isn't initcall starting the driver and posting an event to udev which then creates /dev/rtc0. I think this is simply a race condition on which driver gets started first. Here is a test that Justin can do to resolve this. Add ³initial_debug² to his kernel command line (on both Debian and Angstrom) and after he has booted each BBB OS, see which driver gets started first by running the ³dmesg command. Regards, John 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] Why Do Angstrom and Debian Enumerate the RTC Differently?
Am 13.06.2014 05:01, schrieb Robert Nelson: On Thu, Jun 12, 2014 at 9:56 PM, Justin Morgan jdm...@gmail.com wrote: I've noticed a difference in behavior between the latest Angstrom Linux image and the latest Debian image available for the BeagleBone Black when it comes to enumerating the real-time clocks present when a RTC Cape is present. [I have the actual clock present by use of a generic breakout board, but not the actual cape.] I am trying to determine if Angstrom Linux has a patch that is not present in Debian, as I prefer the RTC behavior I am seeing in Angstrom. (I'd think Debian would want the Angstrom behavior, because if the user has attached an RTC, then there is most likely a battery backing it; the BBB currently does not support shutdown to the RTC rail only, so the on-board RTC is going to be wrong on a cold boot.) When I tell Angstrom that I have a BB-BONE-RTC cape attached, my RTC (the DS1307) is enumerated as /dev/rtc0. As such, my clock becomes the clock that is used to set the system clock, and is otherwise going to get all of the privileges of being the first RTC. When I tell Debian that I have a BBB-RTC-01 cape attached, the on-board RTC is still enumerated as /dev/rtc0. My RTC is enumerated as /dev/rtc1. As such, the clock is wrong on boot. I used different capes because I was going for firmware already on the BBB. I don't see anything about either DTO that explains the difference in behavior. Well, i just compared Angstrom's config with the one i've been pushing out for our 3.8 branch.. No difference an any RTC config's.. Probally comes down to Angstrom's much newer version of systemd, or something custom. You might have an interest in 3 old patches from me I've just posted again for someone else: https://lkml.org/lkml/2014/6/13/6 These patches make it possible to choose the used RTC by driver name. Regards, Alexander Holler -- For more options, visit http://beagleboard.org/discuss --- You received this message because you 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.
