[beagleboard] TTYO0 mystery
Hi board, I'm working on a project and there are some comms traditionally done by RS232. The cape already has a FTDI chip connected to J1 for convenience. So I thought that might just be the easiest solution, tell C to latch onto ttyO0 and call it a day. Well it worked alright but the open terminal on that port kinda got in the way. So I went into uEnv.txt and moved the terminal (the splurge of info on boot isn't a big deal). However now TTYO0 is basically unresponsive. When I open TTYUSB1 on my PC with screen the boot splurge happens and then after the kernel is booted there is no more output and it won't accept input. When I run my application screen stays unresponsive. Finally I wanted to see if I could finagle it working even with the terminal running on TTYO0 (login and run a program that doesn't poll the resource). However, after changing uenv.txt back the terminal hasn't come back after several reboots. I might have changed other stuff in trying to get it to work but I can't remember what. What else controls the function of TTYO0? -- 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: TTYO0 mystery
Also if I sudo echo to ttyO0 it doesn't show on the terminal monitoring it on the other side. On Tuesday, November 25, 2014 3:35:18 PM UTC-6, foreverska wrote: Hi board, I'm working on a project and there are some comms traditionally done by RS232. The cape already has a FTDI chip connected to J1 for convenience. So I thought that might just be the easiest solution, tell C to latch onto ttyO0 and call it a day. Well it worked alright but the open terminal on that port kinda got in the way. So I went into uEnv.txt and moved the terminal (the splurge of info on boot isn't a big deal). However now TTYO0 is basically unresponsive. When I open TTYUSB1 on my PC with screen the boot splurge happens and then after the kernel is booted there is no more output and it won't accept input. When I run my application screen stays unresponsive. Finally I wanted to see if I could finagle it working even with the terminal running on TTYO0 (login and run a program that doesn't poll the resource). However, after changing uenv.txt back the terminal hasn't come back after several reboots. I might have changed other stuff in trying to get it to work but I can't remember what. What else controls the function of TTYO0? -- 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: TTYO0 mystery
It does. On Tuesday, November 25, 2014 7:06:48 PM UTC-6, William Hermans wrote: Does the file */etc/inittab* Contain a line similar to this - *T0:23:respawn:/sbin/getty -L ttyO0 115200 vt102* ?? On Tue, Nov 25, 2014 at 2:41 PM, foreverska chezz...@gmail.com javascript: wrote: Also if I sudo echo to ttyO0 it doesn't show on the terminal monitoring it on the other side. On Tuesday, November 25, 2014 3:35:18 PM UTC-6, foreverska wrote: Hi board, I'm working on a project and there are some comms traditionally done by RS232. The cape already has a FTDI chip connected to J1 for convenience. So I thought that might just be the easiest solution, tell C to latch onto ttyO0 and call it a day. Well it worked alright but the open terminal on that port kinda got in the way. So I went into uEnv.txt and moved the terminal (the splurge of info on boot isn't a big deal). However now TTYO0 is basically unresponsive. When I open TTYUSB1 on my PC with screen the boot splurge happens and then after the kernel is booted there is no more output and it won't accept input. When I run my application screen stays unresponsive. Finally I wanted to see if I could finagle it working even with the terminal running on TTYO0 (login and run a program that doesn't poll the resource). However, after changing uenv.txt back the terminal hasn't come back after several reboots. I might have changed other stuff in trying to get it to work but I can't remember what. What else controls the function of TTYO0? -- 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] Re: TTYO0 mystery
console=tty0 console=/dev/ttyO0,115200n8 capemgr.disable_partno=BB-BONELT-HDMI,BB-BONELT-HDMIN,BB-BONE-EMMC-2G root=/dev/mmcblk0p2 ro rootfstype=ext4 rootwait fixrtc quiet init=/lib/systemd/systemd On Tuesday, November 25, 2014 7:12:54 PM UTC-6, William Hermans wrote: Finally I wanted to see if I could finagle it working even with the terminal running on TTYO0 (login and run a program that doesn't poll the resource). However, after changing uenv.txt back the terminal hasn't come back after several reboots. I might have changed other stuff in trying to get it to work but I can't remember what. What else controls the function of TTYO0? Double check to make sure the changes stuck. Also what is the pout put of : *$ cat /proc/cmdline* ? On Tue, Nov 25, 2014 at 6:06 PM, William Hermans yyr...@gmail.com javascript: wrote: Does the file */etc/inittab* Contain a line similar to this - *T0:23:respawn:/sbin/getty -L ttyO0 115200 vt102* ?? On Tue, Nov 25, 2014 at 2:41 PM, foreverska chezz...@gmail.com javascript: wrote: Also if I sudo echo to ttyO0 it doesn't show on the terminal monitoring it on the other side. On Tuesday, November 25, 2014 3:35:18 PM UTC-6, foreverska wrote: Hi board, I'm working on a project and there are some comms traditionally done by RS232. The cape already has a FTDI chip connected to J1 for convenience. So I thought that might just be the easiest solution, tell C to latch onto ttyO0 and call it a day. Well it worked alright but the open terminal on that port kinda got in the way. So I went into uEnv.txt and moved the terminal (the splurge of info on boot isn't a big deal). However now TTYO0 is basically unresponsive. When I open TTYUSB1 on my PC with screen the boot splurge happens and then after the kernel is booted there is no more output and it won't accept input. When I run my application screen stays unresponsive. Finally I wanted to see if I could finagle it working even with the terminal running on TTYO0 (login and run a program that doesn't poll the resource). However, after changing uenv.txt back the terminal hasn't come back after several reboots. I might have changed other stuff in trying to get it to work but I can't remember what. What else controls the function of TTYO0? -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups BeagleBoard group. To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard...@googlegroups.com javascript:. For more options, visit https://groups.google.com/d/optout. -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups BeagleBoard group. To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[beagleboard] Re: TTYO0 mystery
/etc/initab does have that line the output of cat /proc/cmdline is console=tty0 console=/dev/ttyO0,115200n8 capemgr.disable_partno=BB-BONELT-HDMI,BB-BONELT-HDMIN,BB-BONE-EMMC-2G root=/dev/mmcblk0p2 ro rootfstype=ext4 rootwait fixrtc quiet init=/lib/systemd/systemd I got the program working I think by sudo killall screen although I don't remember starting a screen since reboot so I'm not 100% that was the fix. I still don't get a terminal on ttyO0 anyway. -- 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] cross compilation of kernel
Alright so I've been going in circles with this for hours, I'm using debian sid and I'm trying to compile a kernel for my BBB and I keep stumbling over this error: sudo apt-get install gcc-4.4-arm-linux-gnueabi Reading package lists... Done Building dependency tree Reading state information... Done Some packages could not be installed. This may mean that you have requested an impossible situation or if you are using the unstable distribution that some required packages have not yet been created or been moved out of Incoming. The following information may help to resolve the situation: The following packages have unmet dependencies: gcc-4.4-arm-linux-gnueabi : Depends: libgomp1-armel-cross (= 4.4.6-15) but it is not going to be installed E: Unable to correct problems, you have held broken packages. Why is it not going to be installed? Because it depends on gcc-4.8-base-armel-cross which has no installation candidate. People have fixed this in the past by using the unstable emdebian repo but that doesn't work. It doesn't exist in the unstable repo. I've also read to only use stable and that has even more dependency errors. What's the fix here? my sources.list ## DEBIAN deb http://http.debian.net/debian sid main contrib non-free #deb-src http://http.debian.net/debian wheezy main contrib non-free ## DEBIAN SECURITY deb http://security.debian.org/ jessie/updates main #deb-src http://security.debian.org/ wheezy/updates main deb http://www.emdebian.org/debian/ unstable main -- 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: PRU Pin Mux
I understand man and no rush. Heck I may tackle it one weekend. For the time being I've disable the eMMC and used it's pins for inputs and I'm using pru0 for the heavy lifting. pru1 is still just slightly better for that purpose. On Saturday, May 24, 2014 2:07:46 PM UTC-5, Charles Steinkuehler wrote: Well it's straight-forward to craft a device tree overlay for just the pins you need. I'll try to get the missing HDMI overlay added soon, but no guarantees. I've got a bunch of other stuff I'm working on right now. On 5/23/2014 9:54 PM, foreverska wrote: Oh... I'm barely getting by with what I'm doing much less figuring that out. I really really really would love it done or any sort of work around that would allow me to assign those pins to the PRU config-pin or not. This project is very cramped without those pins. Doable on entry level stages but very cramped. On Friday, May 23, 2014 3:45:42 PM UTC-5, Charles Steinkuehler wrote: On 5/23/2014 3:29 PM, foreverska wrote: I thought we disabled the HDM in the first place... it's disabled in my uENv. Yes, recall I said: If you want to use P8.45 you need to disable the HDMI output (and someone needs to finish the missing cape-univ-hdmi). Feel free to send a pull request adding cape-uinv-hdmi! :) -- 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.
Re: [beagleboard] Re: PRU Pin Mux
I thought we disabled the HDM in the first place... it's disabled in my uENv. Note that you can access almost as many PRU0 pins (11 out, 10 in) without needing to disable either eMMC or HDMI. Unfortuantely I need both processors. If I could even find two inputs on PRU1 I would just move that core over to it and make PRU0 the talkative one. What's the deal with STC/LFC? Its in the AM18xx instruction list but they talk about depreciating it. If one core could write to the other's R30 it's a wasted cycle but if I could free up the LCD pins and have all of the other PRU's excess pins I could definitely use that. On Friday, May 23, 2014 6:27:12 AM UTC-5, Charles Steinkuehler wrote: On 5/22/2014 11:14 PM, foreverska wrote: There we are. I got it working using C24. That's incredibly confusing. What's config pin's deal here: debian@beaglebone:~/Desktop/riot_bin$ sudo config-pin -q P8.15 P8_15 Mode: pruin debian@beaglebone:~/Desktop/riot_bin$ sudo config-pin -q P8.45 Pin is not modifyable: P8_45 lcd_data0 debian@beaglebone:~/Desktop/riot_bin$ sudo config-pin -q P8.20 cape-univ-emmc overlay not found run config-pin overlay cape-univ-emmc to load the cape debian@beaglebone:~/Desktop/riot_bin$ config-pin overlay cape-univ-emmc Loading cape-univ-emmc overlay bash: line 0: echo: write error: File exists Error loading device tree overlay file: cape-univ-emmc I mean the muxing on P8.15 works splendedly but then P8.20 is inaccessible. Also most of the pins on PRU1 are covered up by lcd pins which will quickly become unacceptable in my project. If you want to use P8.20, you need to disable the eMMC. If you want to use P8.45 you need to disable the HDMI output (and someone needs to finish the missing cape-univ-hdmi). Note that you can access almost as many PRU0 pins (11 out, 10 in) without needing to disable either eMMC or HDMI. -- 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] Re: PRU Pin Mux
Oh... I'm barely getting by with what I'm doing much less figuring that out. I really really really would love it done or any sort of work around that would allow me to assign those pins to the PRU config-pin or not. This project is very cramped without those pins. Doable on entry level stages but very cramped. On Friday, May 23, 2014 3:45:42 PM UTC-5, Charles Steinkuehler wrote: On 5/23/2014 3:29 PM, foreverska wrote: I thought we disabled the HDM in the first place... it's disabled in my uENv. Yes, recall I said: If you want to use P8.45 you need to disable the HDMI output (and someone needs to finish the missing cape-univ-hdmi). Feel free to send a pull request adding cape-uinv-hdmi! :) -- 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] Re: PRU Pin Mux
There we are. I got it working using C24. That's incredibly confusing. What's config pin's deal here: debian@beaglebone:~/Desktop/riot_bin$ sudo config-pin -q P8.15 P8_15 Mode: pruin debian@beaglebone:~/Desktop/riot_bin$ sudo config-pin -q P8.45 Pin is not modifyable: P8_45 lcd_data0 debian@beaglebone:~/Desktop/riot_bin$ sudo config-pin -q P8.20 cape-univ-emmc overlay not found run config-pin overlay cape-univ-emmc to load the cape debian@beaglebone:~/Desktop/riot_bin$ config-pin overlay cape-univ-emmc Loading cape-univ-emmc overlay bash: line 0: echo: write error: File exists Error loading device tree overlay file: cape-univ-emmc I mean the muxing on P8.15 works splendedly but then P8.20 is inaccessible. Also most of the pins on PRU1 are covered up by lcd pins which will quickly become unacceptable in my project. On Wednesday, May 21, 2014 11:11:47 AM UTC-5, Charles Steinkuehler wrote: Use the real TRM and data sheet. The page you linked to is for an earlier version of the PRU. At the top it says: This arcticle is part of a collection of articles describing the PRU subsystem included in OMAP-L1x8/C674m/AM18xx devices (where m is an even number). The PRU cores are upgraded in the AM335x parts vs. the AM18xx. On 5/21/2014 10:57 AM, foreverska wrote: I got C3 from TI's website: http://processors.wiki.ti.com/index.php/Programmable_Realtime_Unit#PRU_Internal_Constants_Table_Entry_Register_n_.280x0480_.2B_4.2An.29 On Wednesday, May 21, 2014 5:31:19 AM UTC-5, Charles Steinkuehler wrote: On 5/21/2014 1:16 AM, foreverska wrote: Code never seems to work out of the box for me on these things. Now that I have operational code looking at R31 I have issues putting the results int datamemory which is just absurd. Here's the code: #define CONST_PRUDRAM C3 #define TOOTH_COUNTER R5 lpe: ADD TOOTH_COUNTER, TOOTH_COUNTER, 1 QBEQ lpe, r31, 0 SBCO TOOTH_COUNTER, CONST_PRUDRAM, 0, 4 I have also done this with SBBO pointed to 0x0 with no success. In prudebugger R5 has a non zero value but the memory comes up as 0x0 in the debugger. The C program I have agrees with the bugger's reported values on that value and surrounding values. Is there a setup for the pru to access DM? That feels absurd. It is it's own local ram. I suspect you are writing to the wrong address. Note that C3 which you use above points to the local eCAP timer, I have no idea why you think it should be writing to memory. As an aside, a C program should be able to look down in dram and see registers at the 0x7000 offset right? It looks empty to the bugger and my C program. Or are those different registers than the R0-R31? Read the PRU Reference Guide. The documentation for these registers indicates they are valid while the PRU is disabled. See the RUNSTATE and ENABLE bits in the CONTROL register (section 5.4.1 of the PRU Reference Guide). -- 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: Interconnecting two Beagle Bone Blacks
I'm not 100% that the driver for that exists in ArmHF. What's dmesg say after you plug it in? At any rate why not a crossover cable? or through your home router? On Thursday, May 22, 2014 7:38:09 AM UTC-5, Rasmus Prentow wrote: Hi I'm trying to connect two beagle bones, such that they can communicate using TCP. My first attempt is to use the USB cable by plugin the USB-cable into USB port one one machine and the MicroUSB port on the other. The machine with the main USB port does not add the interface for the USB as it normally would on any other linux machine. Here is the ifconfig root@beaglebone:~# ifconfig eth0 Link encap:Ethernet HWaddr 1c:ba:8c:a7:ac:26 UP BROADCAST MULTICAST MTU:1500 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:0 (0.0 B) TX bytes:0 (0.0 B) Interrupt:40 loLink encap:Local Loopback inet addr:127.0.0.1 Mask:255.0.0.0 inet6 addr: ::1/128 Scope:Host UP LOOPBACK RUNNING MTU:65536 Metric:1 RX packets:63312 errors:0 dropped:0 overruns:0 frame:0 TX packets:63312 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:5546794 (5.2 MiB) TX bytes:5546794 (5.2 MiB) usb0 Link encap:Ethernet HWaddr 96:9f:43:e9:77:c6 inet addr:192.168.7.2 Bcast:192.168.7.3 Mask:255.255.255.252 inet6 addr: fe80::949f:43ff:fee9:77c6/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:7244 errors:0 dropped:0 overruns:0 frame:0 TX packets:6820 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:377882 (369.0 KiB) TX bytes:906342 (885.0 KiB) I run debian on both BBBs. -- 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: PRU Pin Mux
Code never seems to work out of the box for me on these things. Now that I have operational code looking at R31 I have issues putting the results int datamemory which is just absurd. Here's the code: #define CONST_PRUDRAM C3 #define TOOTH_COUNTER R5 lpe: ADD TOOTH_COUNTER, TOOTH_COUNTER, 1 QBEQ lpe, r31, 0 SBCO TOOTH_COUNTER, CONST_PRUDRAM, 0, 4 I have also done this with SBBO pointed to 0x0 with no success. In prudebugger R5 has a non zero value but the memory comes up as 0x0 in the debugger. The C program I have agrees with the bugger's reported values on that value and surrounding values. Is there a setup for the pru to access DM? That feels absurd. It is it's own local ram. As an aside, a C program should be able to look down in dram and see registers at the 0x7000 offset right? It looks empty to the bugger and my C program. Or are those different registers than the R0-R31? -- 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] PRU Pin Mux
That did it. Helpful as always Charles. On Monday, May 19, 2014 11:58:55 PM UTC-5, Charles Steinkuehler wrote: On 5/19/2014 6:53 PM, foreverska wrote: debian@beaglebone:~/Desktop/riot/pru_test$ cat /sys/devices/bone_capemgr.9/slots 0: 54:PF--- 1: 55:PF--- 2: 56:PF--- 3: 57:PF--- 4: ff:P-O-L Bone-LT-eMMC-2G,00A0,Texas Instrument,BB-BONE-EMMC-2G 5: ff:P-O-L Bone-Black-HDMI,00A0,Texas Instrument,BB-BONELT-HDMI debian@beaglebone:~/Desktop/riot/pru_test$ config-pin overlay cape-universal Loading cape-universal overlay bash: line 0: echo: write error: File exists Error loading device tree overlay file: cape-universal debian@beaglebone:~/Desktop/riot/pru_test$ You have the full HDMI interface enabled, which includes the audio signals. You either need to load the cape-universaln overlay that doesn't try to grab the audio lines, or disable HDMI (which allows the HDMIN overlay without audio to load, leaving the audio pins free for your use). I need to make the code smarter so it looks to see if HDMI or HDMIN is loaded and selects the proper overlay automatically. I am not concerned with HDMI at all so I am more than willing to turn that off if need be but I'm not 100% on where to do that. Edit /boot/uboot/uEnv.txt, and look for the optargs= line. -- 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] PRU Pin Mux
I use the Debian image and never ran across config-pin. I'm going to start with this and see how it goes. On Monday, May 19, 2014 8:25:41 AM UTC-5, Charles Steinkuehler wrote: Inputs won't work using 0x06, you need to select the proper pinmux setting *AND* enable the input buffer. Also, with the provided device tree it is still necessary to reboot if you want to change anything. I have a universal device tree (available pre-installed on current Debian based BeagleBone images) that allows dynamic reconfiguration of the I/O pins without rebooting. Simply use the config-pin utility to setup the I/O pins as needed: config-pin -a P8.15 pruin# The -a automatically loads the overlay config-pin P8.20 pruout Once the overlay is loaded you can reconfigure the pin muxing as much as needed without having to reboot. On 5/19/2014 7:41 AM, Florian Hänel wrote: Here's a dts file that works for me for r30/31 You can comment out or in pins you need or don't need. All pins are configured for r30 (output), to use r31 (input) change the 0x05 to 0x06 respectively. Note that this uses pins used by hdmi/lcd and mmc1 (the onboard emmc of the BBB). You need to disable the capes for these first if you want to use these pins as well: http://www.logicsupply.com/blog/2013/07/18/disabling-the-beaglebone-black-hdmi-cape/ I tested all pins with my oscilloscope, they appear to work in this configuration. Florian On 19.05.2014 07:08, foreverska wrote: Has anyone used the Pin Mux Utility? I'm trying to enable R30 and R31 on my PRUs. I've had a rough time enabling device trees so I decided to try and use the Pin Mux Utility. It seems relatively easy to use and it produces nice .h files but the compiler has an issue with some of the code. | #define MUX_VAL(OFFSET,VALUE)\ writel((VALUE), AM335X_CTRL_BASE + (OFFSET)); | Neither GCC or G++ know what to make of writel(). They say it's not defined and such. I've read something about linux/io.h but I haven't been able to find it. Am I barking up a tree with this utility? Those who have successfully done Pin Muxing, by what means? I've tried doing the hipster circuit tutorial but debian doesn't like the tree so says dmesg. I'm not sold on the tree method anyways because I wouldn't mind being able to alter the muxing between compiles not restarts. -- Charles Steinkuehler cha...@steinkuehler.net javascript: I am also interested in this method. It might help the end product to be able to adjust muxing on the fly. I'll have to look into this. On Monday, May 19, 2014 12:58:00 PM UTC-5, TJF wrote: Am Montag, 19. Mai 2014 07:08:21 UTC+2 schrieb foreverska: Has anyone used the Pin Mux Utility? I'm trying to enable R30 and R31 on my PRUs. When you've software running on the PRUSS, you neither need a device tree overlay nor any other tools to change the pinmuxing. Just enable the OCP master port and write the desired configurations in to the registers of the Control Module (0x44E10800 on AM33xx). Device tree overlays can get created later when you finished the development. -- 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] PRU Pin Mux
I tried running this and: debian@beaglebone:~/Desktop/riot/pru_test$ config-pin -a P8.15 pruincape-universal overlay not found Loading cape-universal overlay bash: line 0: echo: write error: File exists Error loading device tree overlay file: cape-universal Whats going on here? On Monday, May 19, 2014 8:25:41 AM UTC-5, Charles Steinkuehler wrote: Inputs won't work using 0x06, you need to select the proper pinmux setting *AND* enable the input buffer. Also, with the provided device tree it is still necessary to reboot if you want to change anything. I have a universal device tree (available pre-installed on current Debian based BeagleBone images) that allows dynamic reconfiguration of the I/O pins without rebooting. Simply use the config-pin utility to setup the I/O pins as needed: config-pin -a P8.15 pruin# The -a automatically loads the overlay config-pin P8.20 pruout Once the overlay is loaded you can reconfigure the pin muxing as much as needed without having to reboot. On 5/19/2014 7:41 AM, Florian Hänel wrote: Here's a dts file that works for me for r30/31 You can comment out or in pins you need or don't need. All pins are configured for r30 (output), to use r31 (input) change the 0x05 to 0x06 respectively. Note that this uses pins used by hdmi/lcd and mmc1 (the onboard emmc of the BBB). You need to disable the capes for these first if you want to use these pins as well: http://www.logicsupply.com/blog/2013/07/18/disabling-the-beaglebone-black-hdmi-cape/ I tested all pins with my oscilloscope, they appear to work in this configuration. Florian On 19.05.2014 07:08, foreverska wrote: Has anyone used the Pin Mux Utility? I'm trying to enable R30 and R31 on my PRUs. I've had a rough time enabling device trees so I decided to try and use the Pin Mux Utility. It seems relatively easy to use and it produces nice .h files but the compiler has an issue with some of the code. | #define MUX_VAL(OFFSET,VALUE)\ writel((VALUE), AM335X_CTRL_BASE + (OFFSET)); | Neither GCC or G++ know what to make of writel(). They say it's not defined and such. I've read something about linux/io.h but I haven't been able to find it. Am I barking up a tree with this utility? Those who have successfully done Pin Muxing, by what means? I've tried doing the hipster circuit tutorial but debian doesn't like the tree so says dmesg. I'm not sold on the tree method anyways because I wouldn't mind being able to alter the muxing between compiles not restarts. -- 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] PRU Pin Mux
debian@beaglebone:~/Desktop/riot/pru_test$ cat /sys/devices/bone_capemgr.9/slots 0: 54:PF--- 1: 55:PF--- 2: 56:PF--- 3: 57:PF--- 4: ff:P-O-L Bone-LT-eMMC-2G,00A0,Texas Instrument,BB-BONE-EMMC-2G 5: ff:P-O-L Bone-Black-HDMI,00A0,Texas Instrument,BB-BONELT-HDMI debian@beaglebone:~/Desktop/riot/pru_test$ config-pin overlay cape-universal Loading cape-universal overlay bash: line 0: echo: write error: File exists Error loading device tree overlay file: cape-universal debian@beaglebone:~/Desktop/riot/pru_test$ I am not concerned with HDMI at all so I am more than willing to turn that off if need be but I'm not 100% on where to do that. On Monday, May 19, 2014 5:38:54 PM UTC-5, Charles Steinkuehler wrote: On 5/19/2014 5:26 PM, foreverska wrote: I tried running this and: debian@beaglebone:~/Desktop/riot/pru_test$ config-pin -a P8.15 pruincape-universal overlay not found Loading cape-universal overlay bash: line 0: echo: write error: File exists Error loading device tree overlay file: cape-universal Whats going on here? What does your slots file look like? The overlay tries to claim all available pins, so if you loaded anything else previously it won't work. If you leave the HDMI (with audio) enabled, there's a universaln overlay that doesn't try to grab the audio pins. Try loading the overlay manually and see if that helps, the -a switch was recently added, so might have some issues. -- 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] Re: Beginner PRU Issue
Not the entire thing but I definitely didn't know about a SOC bridge. That section of code is a derivation on: http://boxysean.com/blog/2012/08/12/first-steps-with-the-beaglebone-pru/ Nothing is ever said about that and it worked for quite a few runs before becoming lost. However, I'm more than willing to try enabling it but I'm having trouble finding mention of it. Is that the entire program? You have to enable the bridge to the SoC interconnect bus before doing memory accesses to things like the GPIO banks. That could be why your program is getting lost. -- 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] Re: Beginner PRU Issue
Fantastic. That restored SBBO for me. Thanks a bunch! On Friday, May 16, 2014 5:11:53 PM UTC-5, Charles Steinkuehler wrote: In the PRU Reference Guide, see section 11.1.2 on the SYSCFG register. This is why you typically see something like the following at the start of most PRU programs: // Clear syscfg[standby_init] to enable ocp master port LBCO r0, CONST_PRUCFG, 4, 4 CLR r0, r0, 4 SBCO r0, CONST_PRUCFG, 4, 4 On 5/16/2014 5:05 PM, foreverska wrote: Not the entire thing but I definitely didn't know about a SOC bridge. That section of code is a derivation on: http://boxysean.com/blog/2012/08/12/first-steps-with-the-beaglebone-pru/ Nothing is ever said about that and it worked for quite a few runs before becoming lost. However, I'm more than willing to try enabling it but I'm having trouble finding mention of it. Is that the entire program? You have to enable the bridge to the SoC interconnect bus before doing memory accesses to things like the GPIO banks. That could be why your program is getting lost. -- 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: Beginner PRU Issue
I found tonight someone has made a CLI debugger called prudebugger. Beautiful piece of work. In single stepping and general breaking in my code I realized the code was getting lost in an SBBO. When it does that it seems to stop responding to resets. It has to be halted manually and then reset. Anyone seen this? the code is very standard #define GPIO1 0x4804c000 #define GPIO_CLEARDATAOUT 0x190 MOV r2, 121 MOV r3, GPIO1 | GPIO_CLEARDATAOUT SBBO r2, r3, 0, 4 On Wednesday, May 14, 2014 11:39:03 PM UTC-5, foreverska wrote: Okay so this is weird. It's been working fine for the past few days. I uploaded code that I was testing and it wasn't responding like I expected so I ctl-c out of the program. I edited the code and ran it again but it failed to exit like normal. So I restarted the BB, modprobed, edited the code so all it does is turn on a light and exit. I run it but the light doesn't come on and it doesn't exit. How is it fine one second and not loading the next? Is it possible for PRUs to be hard hung? I wouldn't think they could keep code after a reset. On Sunday, May 11, 2014 3:55:29 PM UTC-5, foreverska wrote: You have responded to this at a fortuitous time. I JUST got it working on an example code. - I edited the device tree turning on the PRUSS system and turning off the status lights - modprobe uio_pruss - sudo ./[program name] and boom it started blinking just as it should. Now it doesn't exit properly and I will have to play with the clear_event() to see if that's the root but I'm very happy with it right this second. On Sunday, May 11, 2014 3:38:36 PM UTC-5, CEB wrote: It stopped segfaulting when I sudoed the program so I copied in the whole code. The compiler complains that there aren't enough parameters for prussdrv_pru_clear_event. The header does have two parameters but all other TI documentation only has one. If I just throw a zero as the second parameter it will run but does nothing because who knows what I'm doing. - show quoted text - In several examples I see:prussdrv_pru_clear_event (PRU_EVTOUT_0, PRU0_ARM_INTERRUPT); I'm trying to get a feel for this too. Maybe this will help. -- 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: Beginner PRU Issue
Okay so this is weird. It's been working fine for the past few days. I uploaded code that I was testing and it wasn't responding like I expected so I ctl-c out of the program. I edited the code and ran it again but it failed to exit like normal. So I restarted the BB, modprobed, edited the code so all it does is turn on a light and exit. I run it but the light doesn't come on and it doesn't exit. How is it fine one second and not loading the next? Is it possible for PRUs to be hard hung? I wouldn't think they could keep code after a reset. On Sunday, May 11, 2014 3:55:29 PM UTC-5, foreverska wrote: You have responded to this at a fortuitous time. I JUST got it working on an example code. - I edited the device tree turning on the PRUSS system and turning off the status lights - modprobe uio_pruss - sudo ./[program name] and boom it started blinking just as it should. Now it doesn't exit properly and I will have to play with the clear_event() to see if that's the root but I'm very happy with it right this second. On Sunday, May 11, 2014 3:38:36 PM UTC-5, CEB wrote: It stopped segfaulting when I sudoed the program so I copied in the whole code. The compiler complains that there aren't enough parameters for prussdrv_pru_clear_event. The header does have two parameters but all other TI documentation only has one. If I just throw a zero as the second parameter it will run but does nothing because who knows what I'm doing. - show quoted text - In several examples I see:prussdrv_pru_clear_event (PRU_EVTOUT_0, PRU0_ARM_INTERRUPT); I'm trying to get a feel for this too. Maybe this will help. -- 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: Beginner PRU Issue
You have responded to this at a fortuitous time. I JUST got it working on an example code. - I edited the device tree turning on the PRUSS system and turning off the status lights - modprobe uio_pruss - sudo ./[program name] and boom it started blinking just as it should. Now it doesn't exit properly and I will have to play with the clear_event() to see if that's the root but I'm very happy with it right this second. On Sunday, May 11, 2014 3:38:36 PM UTC-5, CEB wrote: It stopped segfaulting when I sudoed the program so I copied in the whole code. The compiler complains that there aren't enough parameters for prussdrv_pru_clear_event. The header does have two parameters but all other TI documentation only has one. If I just throw a zero as the second parameter it will run but does nothing because who knows what I'm doing. - show quoted text - In several examples I see:prussdrv_pru_clear_event (PRU_EVTOUT_0, PRU0_ARM_INTERRUPT); I'm trying to get a feel for this too. Maybe this will help. -- 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] Beginner PRU Issue
I'm trying to get the hang of the pru and all the examples segfault out of the gate. So I grabbed TI's skeleton code and tried compiling and running that, segfault. I reduced it down to the first line, fine. First 3, segfault. Comment out prussdrv_open, fine. Thow -g at the compiler and run it under gdb and that really narrows it down: Program received signal SIGSEGV, Segmentation fault. 0xb6fc9eec in __pruss_detect_hw_version () from /usr/lib/libprussdrv.so gdb doesn't really have a reference once it gets into that library so I can't see my surroundings. There are zero results for this in google. Has anyone seen this before? I must be missing something pretty simple. -- 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: BBB re-flash
Well I can explain this in linux but not so much in windows, haven't used it in years. So with the BBB plugged in via USB fdisk -l should have a 73MB~ device on this list. From what I gather this needs to be a FAT partition, I did this with gparted personally. This may not be true but since it worked once I will do as the crow does. Then you boot off the sdcard with nothing but USB or a power adapter plugged in. If you can SSH into the system then something has gone wrong and the system has booted instead of gone into flashing. For me it finished somewhere during my second episode of TV I was watching. On Monday, March 10, 2014 4:30:00 AM UTC-5, wharms wrote: hi could you elaborate this a bit more ? bgnd: I had the problem at testing, the system refused to start and i tried to flash it via SD-card. The card itself booted fine but i was unable to flash. re, wh Am 10.03.2014 03:34, schrieb foreverska: Well I got it to go finally by: using gparted to format the 73mb boot partition as FAT rewriting the flasher SD card Still no luck with TTYLinux though -- 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: BBB re-flash
Well I got it to go finally by: using gparted to format the 73mb boot partition as FAT rewriting the flasher SD card Still no luck with TTYLinux though -- 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.
