[beagleboard] Debugging through Eclipse using remote GDB
I'm currently trying to set up cross-compiling for the Beaglebone Black. I am running Eclipse on my windows machine and Linaro-arm cross compiler. I can compile on Windows and run the program just fine on the BBB. My problem is trying to get the remote GDB to work. I'm run gdbserver on the BBB: gdbserver 192.168.7.2:12345 TestLED.elf Process TestLED.elf created; pid = 2415 Listening on port 12345 Remote debugging from host 192.168.7.1 I've set up remote debugging in Eclipse using the GDB in the Linaro toolchain. I get the following in the console when I start up GDB in Eclipse: $1 = 0xff Cannot access memory at address 0x0 Cannot access memory at address 0x0 The target endianness is set automatically (currently little endian) No source file named C:\Path\To\source\file\src\main.cpp. I've built it using the debug option. So I'm assuming it compiled it with the -g flag. I added the flag just in case and get the same error :( EDIT: It appears I can step through it just fine in GDB on the bbb. So the problem seems to something in Eclipse. -- 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] BeagleBoard XM rev c Boot Issue
Hello All , I was able to boot my beagle xm ...I used u-boot.img instead of u-boot.bin :) can anybody let me know the diff bw u-boot.bin and u-boot.img (previously i used to use u-boot.bin) Also please send me some links on spl bootloader. @Maxim thanks a lot for your support On 13 September 2014 10:28, pavan B.G bgpa...@gmail.com wrote: Hi Maxim , I used MLO and u-boot-spl.bin and tried booting the beagle-xm ...still no luck I get the same error . Regards Pavan On 13 September 2014 10:02, pavan B.G bgpa...@gmail.com wrote: Hi Maxim , Thanks for the git link . I have a question ...I could see 2 u-boot.bin files generated after cross compiling with codesourcery toolchain .one is u-boot.bin and the other is located in spl/u-boot-spl.bin. Do I need to use the MLO and u-boot-spl.bin ?? to boot the Beagleboard xm ??? Thanks in advance . Regards , Pavan On 8 September 2014 13:48, Maxim Podbereznyy lisar...@gmail.com wrote: Try this git clone git://git.denx.de/u-boot.git cd u-boot/ git checkout v2014.07 -b tmp 2014-09-07 17:31 GMT+04:00 pavan B.G bgpa...@gmail.com: Hi Maxim , Please let me know how to proceed further ??? On 7 September 2014 18:56, Maxim Podbereznyy lisar...@gmail.com wrote: Of course! Because changing u-boot environment variables means nothing for SPL bootloader :) 07 Сен 2014 г. 16:11 пользователь pavan B.G bgpa...@gmail.com написал: Hello John , I applied the patch,cross compiled U-boot and tried but its still the same ..:( Regards Pavan On 7 September 2014 13:12, John Syn john3...@gmail.com wrote: From: pavan bgpa...@gmail.com Reply-To: beagleboard@googlegroups.com beagleboard@googlegroups.com Date: Saturday, September 6, 2014 at 11:39 PM To: beagleboard@googlegroups.com beagleboard@googlegroups.com Subject: [beagleboard] BeagleBoard XM rev c Boot Issue Hello , I recently tried compiling and booting a fresh kernel and U-boot on Beagleboard -Xm rev c , i get the following error during board bootup U-Boot SPL 2014.10-rc2 (Sep 06 2014 - 18:31:00) SPL: Please implement spl_start_uboot() for your board SPL: Direct Linux boot not active! reading u-boot.img spl_load_image_fat: error reading image u-boot.img, err - -1 ### ERROR ### Please RESET the board ### Resetting the board dosen't help . The default angstrom distro i got from factory works very fine and the board boots .So there is no issue with the board .Please help me regarding this . I cloned the U-boot source via this *git clone git://git.denx.de/u-boot.git http://git.denx.de/u-boot.git u-boot/* Did you patch u-boot? http://eewiki.net/display/linuxonarm/BeagleBone+Black#BeagleBoneBlack-Bootloader:U-Boot But for the Beagle-xM you use 0001-omap3_beagle-uEnv.txt-bootz-n-fixes.patch Regards, John *Thanks and regards.* -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups BeagleBoard group. To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups BeagleBoard group. To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups BeagleBoard group. To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups BeagleBoard group. To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups BeagleBoard group. To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. -- LinkedIn - http://www.linkedin.com/in/maximpodbereznyy Company - http://www.linkedin.com/company/mentorel Facebook - https://www.facebook.com/mentorel.company -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups BeagleBoard group. To unsubscribe from this group and stop receiving emails
Re: [beagleboard] BeagleBoard XM rev c Boot Issue
Man, it was discussed very long ago. Anyway you should use these instructions and you will ask dumb questions then ;) http://eewiki.net/display/linuxonarm/BeagleBoard 13 Сен 2014 г. 11:07 пользователь pavan B.G bgpa...@gmail.com написал: Hello All , I was able to boot my beagle xm ...I used u-boot.img instead of u-boot.bin :) can anybody let me know the diff bw u-boot.bin and u-boot.img (previously i used to use u-boot.bin) Also please send me some links on spl bootloader. @Maxim thanks a lot for your support On 13 September 2014 10:28, pavan B.G bgpa...@gmail.com wrote: Hi Maxim , I used MLO and u-boot-spl.bin and tried booting the beagle-xm ...still no luck I get the same error . Regards Pavan On 13 September 2014 10:02, pavan B.G bgpa...@gmail.com wrote: Hi Maxim , Thanks for the git link . I have a question ...I could see 2 u-boot.bin files generated after cross compiling with codesourcery toolchain .one is u-boot.bin and the other is located in spl/u-boot-spl.bin. Do I need to use the MLO and u-boot-spl.bin ?? to boot the Beagleboard xm ??? Thanks in advance . Regards , Pavan On 8 September 2014 13:48, Maxim Podbereznyy lisar...@gmail.com wrote: Try this git clone git://git.denx.de/u-boot.git cd u-boot/ git checkout v2014.07 -b tmp 2014-09-07 17:31 GMT+04:00 pavan B.G bgpa...@gmail.com: Hi Maxim , Please let me know how to proceed further ??? On 7 September 2014 18:56, Maxim Podbereznyy lisar...@gmail.com wrote: Of course! Because changing u-boot environment variables means nothing for SPL bootloader :) 07 Сен 2014 г. 16:11 пользователь pavan B.G bgpa...@gmail.com написал: Hello John , I applied the patch,cross compiled U-boot and tried but its still the same ..:( Regards Pavan On 7 September 2014 13:12, John Syn john3...@gmail.com wrote: From: pavan bgpa...@gmail.com Reply-To: beagleboard@googlegroups.com beagleboard@googlegroups.com Date: Saturday, September 6, 2014 at 11:39 PM To: beagleboard@googlegroups.com beagleboard@googlegroups.com Subject: [beagleboard] BeagleBoard XM rev c Boot Issue Hello , I recently tried compiling and booting a fresh kernel and U-boot on Beagleboard -Xm rev c , i get the following error during board bootup U-Boot SPL 2014.10-rc2 (Sep 06 2014 - 18:31:00) SPL: Please implement spl_start_uboot() for your board SPL: Direct Linux boot not active! reading u-boot.img spl_load_image_fat: error reading image u-boot.img, err - -1 ### ERROR ### Please RESET the board ### Resetting the board dosen't help . The default angstrom distro i got from factory works very fine and the board boots .So there is no issue with the board .Please help me regarding this . I cloned the U-boot source via this *git clone git://git.denx.de/u-boot.git http://git.denx.de/u-boot.git u-boot/* Did you patch u-boot? http://eewiki.net/display/linuxonarm/BeagleBone+Black#BeagleBoneBlack-Bootloader:U-Boot But for the Beagle-xM you use 0001-omap3_beagle-uEnv.txt-bootz-n-fixes.patch Regards, John *Thanks and regards.* -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups BeagleBoard group. To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups BeagleBoard group. To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups BeagleBoard group. To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups BeagleBoard group. To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups BeagleBoard group. To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. -- LinkedIn - http://www.linkedin.com/in/maximpodbereznyy Company - http://www.linkedin.com/company/mentorel Facebook -
Re: [beagleboard] Beaglebone Black Rebooting Several Times Every Day
Update: I installed 3.14.17-ti-r19 yesterday about 3pm and set eth0 to auto so it comes up earlier than wicp. Ran fine until 7:13am this morning then did it's usual reset thing. Very frustrating. Guess I'll have to spring for that cable. On Friday, September 12, 2014 9:55:47 AM UTC-4, RobertCNelson wrote: On Fri, Sep 12, 2014 at 8:37 AM, Greg Kelley suekk...@gmail.com javascript: wrote: BTW, that 3.14.x isn't being worked on... If you have a new testnig image: sudo apt-get update sudo apt-get install linux-image-3.14.17-ti-r19 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] Beaglebone Black Rebooting Several Times Every Day
Update: the BBB just reset again at 7:49am. That's interesting, because it reset twice yesterday at almost the same times 7:35am and 8:13am and today at 7:13am and 7:49am. cron daily runs at 6:25am and I have no ctontab jobs at those times. Appears to be some sort of pattern due to the daily reset times being so close, but there is nothing is syslog except cron.hourly until the new boot sequence starts. On Saturday, September 13, 2014 7:25:57 AM UTC-4, Greg Kelley wrote: Update: I installed 3.14.17-ti-r19 yesterday about 3pm and set eth0 to auto so it comes up earlier than wicp. Ran fine until 7:13am this morning then did it's usual reset thing. Very frustrating. Guess I'll have to spring for that cable. On Friday, September 12, 2014 9:55:47 AM UTC-4, RobertCNelson wrote: On Fri, Sep 12, 2014 at 8:37 AM, Greg Kelley suekk...@gmail.com wrote: BTW, that 3.14.x isn't being worked on... If you have a new testnig image: sudo apt-get update sudo apt-get install linux-image-3.14.17-ti-r19 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] headless Debian
Can we get an official headless version of Debian for BBB? All the projects I have planned don't require a GUI or NodeJS, Cloud9, GNOME etc. -- 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] headless Debian
On 09/13/2014 08:42 AM, Bob Mancarella wrote: Can we get an official headless version of Debian for BBB? All the projects I have planned don't require a GUI or NodeJS, Cloud9, GNOME etc. -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups BeagleBoard group. To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscr...@googlegroups.com mailto:beagleboard+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. Already exists... http://elinux.org/Beagleboard:BeagleBoneBlack_Debian#Debian_Releases 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] headless Debian
Does that also include all the device tree stuff in /lib/firmware ? That's where I have had trouble in the past. On Saturday, September 13, 2014 8:59:33 AM UTC-4, Mike Bell wrote: On 09/13/2014 08:42 AM, Bob Mancarella wrote: Can we get an official headless version of Debian for BBB? All the projects I have planned don't require a GUI or NodeJS, Cloud9, GNOME etc. -- 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. Already exists... http://elinux.org/Beagleboard:BeagleBoneBlack_Debian#Debian_Releases 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] Re: registering asynchronous events on kernel thread in user space
Hi Brandon I am learning to use the BBB to interface a 802.15.4 radio to BBB without a MCU between BBB and CC2500. I want to remove the MCU and interface directly to the Kernel. So for this i have to service interrupts which will be a gpio interrupt to BBB if a new packet arrives. So that the reason for the Doubts n questions. And also the reason why i want to know which method is faster or better. But I think that i have to do some profiling as u pointed out. Will post the results ASAP here. Thanks for the reply On Friday, September 12, 2014 1:19:26 AM UTC+5:30, Brandon I wrote: OK, one more time. All userspace interrupts work the same, pru, network driver, *anything*. The process blocks until the interrupt handler unblocks the process with a semaphore or completion in the kernel. For example, when you read data for a socket connection, it blocks. When data comes in, the data is copied to userspace, the read function unblocks. Again, this is all explained in that LDD3 chapter I linked. There's no other way to do it, except going around the kernel and polling memory. 1. This isn't a realtime kernel. You will always have jitter. Does it matter? I don't know what you're doing. You don't need to use polling. UIO and select doesn't use polling. 2. Using select (and even poll() since it's just a wrapper for select()) on the gpio doesn't poll. It's interrupt driven. Same method as described. 3. Same method as described. If you use the PRU, it will be the same method to notify your userspace application with the same shortcomings, unless you put all of your code into the pru. If you want deterministic timing, you either need a realtime kernel, or put all your code on the pru. But, I can guarantee you don't need deterministic timing, and I can guess that you're worrying about nothing Seriously, do some benchmarks with sysfs. It's only a few lines of code. And, there are all sorts of userspace hardware drivers that use userspace interrupts out there including graphics and network. If you only need to know when a gpio event happened, and process it later (it will always be later since this isn't a realtime kernel or in the pru), you can timestamp the event. I believe you can do this with the enhanced timers, and I know you can do this in the pru. So it would go, event happens, pru/etimer hardware timestamps the event, sends interrupt, userspace gets interupt using the only way possible, userspace reads timestamp from hardware, pretends that the event happened at the timestamp for any calculations. If you explained what you were doing, we could advise you better. Good luck! On Thursday, September 11, 2014, neo prag@gmail.com javascript: wrote: Hi Brandon 1. I agree with jitter involved with processing interrupts and 100% cpu usage during polling for the same, so is there no way to let the user-space know that interrupt has occurred apart from polling ? 2. The reason why i said pseudo-interrupt is because we are polling and waiting there which is same as watching a flag in a UART register for RX flag to set. 3. I am curious as to how interrupts for Ethernet and usb are written. I am guessing that the ISR will use the DMA to transfer bytes to user-space. But even in that case the userspace should know that a new data has arrived. Then hoe to synchronize the kernel space and user-space if there are to share a data ? Thanks... On Thursday, September 11, 2014 2:26:15 AM UTC+5:30, Brandon I wrote: pseudo-interrupt from user space There's nothing pseudo about it. Again, any usual way to have a userspace application respond to an interrupt will be the exact same. The kernel will block the userspace process until the interrupt is seen. The only real alternative is burning up the cpu with memory polling, which appears to be what the BBIOlib method uses. So, your latency is limited to your poll speed (which can be faster than interrupts). But, if you have a constant poll for minimum latency, lets hope you're not trying to do something important elsewhere since your cpu usage will be at 100%, and you'll be maximizing process to process context switching! For 4, The only difference between a userspace and kernel space interrupt handler is where the code is that responds to the interrupt. You will only benefit from writing your own interrupt handler if you put all of your code that does something with that interrupt in the kernel. Otherwise, you're back to process blocked by kernel, interrupt occurs, kernel unblocks process, process does something after seeing the interruptback to the sysfs/UIO method. I would try some benchmarks. See if the regular UIO/sysfs interrupt method gives you sufficient performance. And definitely keep in mind John's statement. You're going to see a massive amount of jitter for anything in userspace or kernel space
[beagleboard] Re: Android running on BBB with Linux 3.8
I have installed Andrew's Android build on a BBB with a 4D 4.3 display. Most of it is working well. Has anyone succeeded getting keys mapped to Home, Menu, Back and Search? Thanks Mahen -- 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] headless Debian
On Sep 13, 2014 8:01 AM, Bob Manc bobm...@gmail.com wrote: Does that also include all the device tree stuff in /lib/firmware ? That's where I have had trouble in the past. They are 'built-in' this not under that Dir. On Saturday, September 13, 2014 8:59:33 AM UTC-4, Mike Bell wrote: On 09/13/2014 08:42 AM, Bob Mancarella wrote: Can we get an official headless version of Debian for BBB? All the projects I have planned don't require a GUI or NodeJS, Cloud9, GNOME etc. -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups BeagleBoard group. To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. Already exists... http://elinux.org/Beagleboard:BeagleBoneBlack_Debian#Debian_Releases 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. -- 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] headless Debian
Nothing is where it was on the other builds but it is working for me. Thanks. On Saturday, September 13, 2014 1:38:02 PM UTC-4, RobertCNelson wrote: On Sep 13, 2014 8:01 AM, Bob Manc bob...@gmail.com javascript: wrote: Does that also include all the device tree stuff in /lib/firmware ? That's where I have had trouble in the past. They are 'built-in' this not under that Dir. On Saturday, September 13, 2014 8:59:33 AM UTC-4, Mike Bell wrote: On 09/13/2014 08:42 AM, Bob Mancarella wrote: Can we get an official headless version of Debian for BBB? All the projects I have planned don't require a GUI or NodeJS, Cloud9, GNOME etc. -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups BeagleBoard group. To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. Already exists... http://elinux.org/Beagleboard:BeagleBoneBlack_Debian#Debian_Releases 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...@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] How to change GPIO Mode
From: david.berge...@gmail.com Reply-To: beagleboard@googlegroups.com beagleboard@googlegroups.com Date: Friday, September 12, 2014 at 3:50 AM To: beagleboard@googlegroups.com beagleboard@googlegroups.com Subject: [beagleboard] How to change GPIO Mode Hey Forum I hope you can help me. I'm on a education project and I have some questions. I have a problem with the config of the GPIO (I2C-HW-Controller) I have two diffrent usecases in my project. 1. I2C HW-Controller #1 is a master 2. I2C HW-Controller #1 is a slave So I have to change the I2C-controller config between the master and the slave mode. If it is possible, I should do that while the BBB and his phyton/c++ program is running. Now here are my questions: * How can I switch between I2C master and slave mode? (Device tree?) * * Can I do that while the BBB is running? (Or is a reboot of BBB necessary?) If its possible give my a nice explanation and not only a code piece. ;-) I have to learn understand how all that stuff works. Linux does not support slave mode for either I2C or SPI. Even though the BBB hardware can support SCL being generated on another device, the Linux I2C driver does not support this. Either you have to create your own I2C slave driver or you can do this with the PRU. Regards, John Thanks a lot -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups BeagleBoard group. To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups BeagleBoard group. To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[beagleboard] Re: prussdrv to remoteproc
I believe that PRUSpeak(https://github.com/deepakkarki/pruspeak/) makes use of remoteproc. I haven't made the transition yet, but I'm definitely curious about it. The complexity of implementing remoteproc seems much, much greater than using UIO or /dev/mem mapping. What is the benefit of using remoteproc over the other methods? On Friday, September 12, 2014 5:57:17 AM UTC-7, Cedric Malitte wrote: Le vendredi 12 septembre 2014 04:11:18 UTC-4, Jon E a écrit : Hi, Anyone know of example code that's using the newer remoteproc interface? Also, is there a way to convert pasm binary files to elf format for the firmware loader? Would like to play around with the latest 3.14 TI kernel, but haven't been able to find much info on the PRU side.. Thanks, Jon As I read here http://processors.wiki.ti.com/index.php/PRU-ICSS_Getting_Started_Guide There are some examples included in the SDK. I'm downloading it to check that, but for now i'm still using the old patch method to enable pruss :) Regards, Cedric -- 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 B - Embedded QT and X Sever - Deployment OS Ubuntu
On 9/12/14, 11:09 AM, Peter Gregory talkto...@gmail.com wrote: I've set up a cross compiler under Ubuntu 14.04 32 bit x86 in VMWare on my mac. I built the QT 5.3 source using Lenaro hard float gcc. I set up the kit for cross compiling using QT Creator and could remotely deploy console applications fine. I ran into problems getting QT graphics applications to work. I could compile them using the TI graphics SDK, but they would not run on the BBB. I suspect I'm missing packages on the non-X BBB. I'm learning more as I go, I'll probably try again and see if I can get Wayland working on BBB and get QTWayland plugin working. My original idea was to use LinuxFB, but X seems to be required for QT graphics applications. Have you tried to run the QT demos with ³-platform eglfs² You need the SGX libraries installed for this to work. Regards, John The QT 5.3 source won't compile the Quick libraries unless X or OpenGL libraries exist. I thought it would make sense to get QT Creator to work on BBB and make it build the QT graphics applications. At least to start. Then I can work on the minimum BBB deployment image that can run the QT graphics application. -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups BeagleBoard group. To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups BeagleBoard group. To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [beagleboard] Re: registering asynchronous events on kernel thread in user space
From: neo prag.in...@gmail.com Reply-To: beagleboard@googlegroups.com beagleboard@googlegroups.com Date: Saturday, September 13, 2014 at 6:17 AM To: beagleboard@googlegroups.com beagleboard@googlegroups.com Subject: Re: [beagleboard] Re: registering asynchronous events on kernel thread in user space Hi Brandon I am learning to use the BBB to interface a 802.15.4 radio to BBB without a MCU between BBB and CC2500. I want to remove the MCU and interface directly to the Kernel. Are you referring to the CC2520? If so, there is a driver in the linux-wpan repo: https://github.com/linux-wpan If you want support, send ³subscribe linux-wpan² e-mail to: majord...@vger.kernel.org Regards, John So for this i have to service interrupts which will be a gpio interrupt to BBB if a new packet arrives. So that the reason for the Doubts n questions. And also the reason why i want to know which method is faster or better. But I think that i have to do some profiling as u pointed out. Will post the results ASAP here. Thanks for the reply On Friday, September 12, 2014 1:19:26 AM UTC+5:30, Brandon I wrote: OK, one more time. All userspace interrupts work the same, pru, network driver, *anything*. The process blocks until the interrupt handler unblocks the process with a semaphore or completion in the kernel. For example, when you read data for a socket connection, it blocks. When data comes in, the data is copied to userspace, the read function unblocks. Again, this is all explained in that LDD3 chapter I linked. There's no other way to do it, except going around the kernel and polling memory. 1. This isn't a realtime kernel. You will always have jitter. Does it matter? I don't know what you're doing. You don't need to use polling. UIO and select doesn't use polling. 2. Using select (and even poll() since it's just a wrapper for select()) on the gpio doesn't poll. It's interrupt driven. Same method as described. 3. Same method as described. If you use the PRU, it will be the same method to notify your userspace application with the same shortcomings, unless you put all of your code into the pru. If you want deterministic timing, you either need a realtime kernel, or put all your code on the pru. But, I can guarantee you don't need deterministic timing, and I can guess that you're worrying about nothing Seriously, do some benchmarks with sysfs. It's only a few lines of code. And, there are all sorts of userspace hardware drivers that use userspace interrupts out there including graphics and network. If you only need to know when a gpio event happened, and process it later (it will always be later since this isn't a realtime kernel or in the pru), you can timestamp the event. I believe you can do this with the enhanced timers, and I know you can do this in the pru. So it would go, event happens, pru/etimer hardware timestamps the event, sends interrupt, userspace gets interupt using the only way possible, userspace reads timestamp from hardware, pretends that the event happened at the timestamp for any calculations. If you explained what you were doing, we could advise you better. Good luck! On Thursday, September 11, 2014, neo prag@gmail.com javascript: wrote: Hi Brandon 1. I agree with jitter involved with processing interrupts and 100% cpu usage during polling for the same, so is there no way to let the user-space know that interrupt has occurred apart from polling ? 2. The reason why i said pseudo-interrupt is because we are polling and waiting there which is same as watching a flag in a UART register for RX flag to set. 3. I am curious as to how interrupts for Ethernet and usb are written. I am guessing that the ISR will use the DMA to transfer bytes to user-space. But even in that case the userspace should know that a new data has arrived. Then hoe to synchronize the kernel space and user-space if there are to share a data ? Thanks... On Thursday, September 11, 2014 2:26:15 AM UTC+5:30, Brandon I wrote: pseudo-interrupt from user space There's nothing pseudo about it. Again, any usual way to have a userspace application respond to an interrupt will be the exact same. The kernel will block the userspace process until the interrupt is seen. The only real alternative is burning up the cpu with memory polling, which appears to be what the BBIOlib method uses. So, your latency is limited to your poll speed (which can be faster than interrupts). But, if you have a constant poll for minimum latency, lets hope you're not trying to do something important elsewhere since your cpu usage will be at 100%, and you'll be maximizing process to process context switching! For 4, The only difference between a userspace and kernel space interrupt handler is where the code is that responds to the interrupt. You will only benefit from writing your own interrupt handler if you put all of your code that does something with that
Re: [beagleboard] Beaglebone Black rev B - Embedded QT and X Sever - Deployment OS Ubuntu
I did not try -platform eglfs However, I did get QT applications running under lxde desktop, Ubuntu Designer (qtdelarative-ubuntu-ui-toolkit-plugin) It was very... very... slow. Dragging UI elements to the designer window was painful. So much for that experiment. However, I did learn a lot from the process. I'm now in the process of building a cross compiler on Ubuntu 14.04 LS using: linaro 4.8 arm hard float compiler TI GFX sdk (or do I use the source from RobertCNelson's bb-kernel?) QT Everywhere 5.3.1 QT Designer cross compiled Hopefully this time I can get it all to work... -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups BeagleBoard group. To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [beagleboard] Beaglebone Black rev B - Embedded QT and X Sever - Deployment OS Ubuntu
From: Peter Gregory talkto...@gmail.com Reply-To: beagleboard@googlegroups.com beagleboard@googlegroups.com Date: Saturday, September 13, 2014 at 3:42 PM To: beagleboard@googlegroups.com beagleboard@googlegroups.com Subject: Re: [beagleboard] Beaglebone Black rev B - Embedded QT and X Sever - Deployment OS Ubuntu I did not try -platform eglfs However, I did get QT applications running under lxde desktop, Ubuntu Designer (qtdelarative-ubuntu-ui-toolkit-plugin) It was very... very... slow. Dragging UI elements to the designer window was painful. So much for that experiment. However, I did learn a lot from the process. I'm now in the process of building a cross compiler on Ubuntu 14.04 LS using: linaro 4.8 arm hard float compiler TI GFX sdk (or do I use the source from RobertCNelson's bb-kernel?) QT Everywhere 5.3.1 QT Designer cross compiled Hopefully this time I can get it all to work... There is something else you should keep an eye on, that is LXQT. This is LXDE rewritten using QT combined with Razor-QT. Not sure if it will work on BBB. Regards, John -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups BeagleBoard group. To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups BeagleBoard group. To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [beagleboard] Re: registering asynchronous events on kernel thread in user space
Hi John Thanks for the link. On Sun, Sep 14, 2014 at 3:44 AM, John Syn john3...@gmail.com wrote: From: neo prag.in...@gmail.com Reply-To: beagleboard@googlegroups.com beagleboard@googlegroups.com Date: Saturday, September 13, 2014 at 6:17 AM To: beagleboard@googlegroups.com beagleboard@googlegroups.com Subject: Re: [beagleboard] Re: registering asynchronous events on kernel thread in user space Hi Brandon I am learning to use the BBB to interface a 802.15.4 radio to BBB without a MCU between BBB and CC2500. I want to remove the MCU and interface directly to the Kernel. Are you referring to the CC2520? If so, there is a driver in the linux-wpan repo: https://github.com/linux-wpan If you want support, send “subscribe linux-wpan” e-mail to: majord...@vger.kernel.org Regards, John So for this i have to service interrupts which will be a gpio interrupt to BBB if a new packet arrives. So that the reason for the Doubts n questions. And also the reason why i want to know which method is faster or better. But I think that i have to do some profiling as u pointed out. Will post the results ASAP here. Thanks for the reply On Friday, September 12, 2014 1:19:26 AM UTC+5:30, Brandon I wrote: OK, one more time. All userspace interrupts work the same, pru, network driver, *anything*. The process blocks until the interrupt handler unblocks the process with a semaphore or completion in the kernel. For example, when you read data for a socket connection, it blocks. When data comes in, the data is copied to userspace, the read function unblocks. Again, this is all explained in that LDD3 chapter I linked. There's no other way to do it, except going around the kernel and polling memory. 1. This isn't a realtime kernel. You will always have jitter. Does it matter? I don't know what you're doing. You don't need to use polling. UIO and select doesn't use polling. 2. Using select (and even poll() since it's just a wrapper for select()) on the gpio doesn't poll. It's interrupt driven. Same method as described. 3. Same method as described. If you use the PRU, it will be the same method to notify your userspace application with the same shortcomings, unless you put all of your code into the pru. If you want deterministic timing, you either need a realtime kernel, or put all your code on the pru. But, I can guarantee you don't need deterministic timing, and I can guess that you're worrying about nothing Seriously, do some benchmarks with sysfs. It's only a few lines of code. And, there are all sorts of userspace hardware drivers that use userspace interrupts out there including graphics and network. If you only need to know when a gpio event happened, and process it later (it will always be later since this isn't a realtime kernel or in the pru), you can timestamp the event. I believe you can do this with the enhanced timers, and I know you can do this in the pru. So it would go, event happens, pru/etimer hardware timestamps the event, sends interrupt, userspace gets interupt using the only way possible, userspace reads timestamp from hardware, pretends that the event happened at the timestamp for any calculations. If you explained what you were doing, we could advise you better. Good luck! On Thursday, September 11, 2014, neo prag@gmail.com wrote: Hi Brandon I agree with jitter involved with processing interrupts and 100% cpu usage during polling for the same, so is there no way to let the user-space know that interrupt has occurred apart from polling ? The reason why i said pseudo-interrupt is because we are polling and waiting there which is same as watching a flag in a UART register for RX flag to set. I am curious as to how interrupts for Ethernet and usb are written. I am guessing that the ISR will use the DMA to transfer bytes to user-space. But even in that case the userspace should know that a new data has arrived. Then hoe to synchronize the kernel space and user-space if there are to share a data ? Thanks... On Thursday, September 11, 2014 2:26:15 AM UTC+5:30, Brandon I wrote: pseudo-interrupt from user space There's nothing pseudo about it. Again, any usual way to have a userspace application respond to an interrupt will be the exact same. The kernel will block the userspace process until the interrupt is seen. The only real alternative is burning up the cpu with memory polling, which appears to be what the BBIOlib method uses. So, your latency is limited to your poll speed (which can be faster than interrupts). But, if you have a constant poll for minimum latency, lets hope you're not trying to do something important elsewhere since your cpu usage will be at 100%, and you'll be maximizing process to process context switching! For 4, The only difference between a userspace and kernel space interrupt handler is where the code is that responds to the interrupt. You will only benefit from writing your own
