Re: [beagleboard] Re: Surefire PRU Example

OK Success. Got it working. I blended two types of overlays I have seen on the web, this is what the final working version looked like. My notable changes were in fragment 1 - pru_pru_pins_pinmux { } addition and the compatible = "bone-pinmux-helper"; (whatever that is :) seemed

Re: [beagleboard] Re: Surefire PRU Example

I am working on a generic * 0x1A4 0x05* mode setting, just sitting down now for some more punishment. two other good resources on this are http://www.ofitselfso.com/BeagleNotes/UsingDeviceTreesToConfigurePRUIOPins.php and this video at this time https://youtu.be/wui_wU1AeQc?t=630 it talks

Re: [beagleboard] Re: Surefire PRU Example

> > Then here: http://beaglebone.cameon.net/home/pin-muxing says a couple of > my assumptions were wrong. 0x25h seems correct. Blah, I got it wrong again. Seems 0xD was correct. But anyway, you have the means to do what you need. Just make sure you read the second link correctly. I got it wrong

Re: [beagleboard] Re: Surefire PRU Example

Additionally, I have no idea what 0x20h is meant to do. I'm assuming it's either for pull up or pull down enable, but I have not checked the documentation. I would think you could do away with the pullup / pulldown, for an output. But I honestly do not know what you're attempting to do. In which

Re: [beagleboard] Re: Surefire PRU Example

*grep comes back empty, implies dtbo has no effect?* Can someone please post a working PRU Pin P9.27 dts config with confirmation out put like below? I am trying to build one that uses the *compatible = "bone-pinmux-helper"* target atm to see if that makes a difference. syntax errors

Re: [beagleboard] Re: Surefire PRU Example

Something like this, but replace grep pwm with grep pru: root@beaglebone:/home/william# *cat /sys/kernel/debug/pinctrl/44e10800.pinmux/pinmux-pins |grep pwm* pin 8 (44e10820.0): ocp:P8_19_pinmux (GPIO UNCLAIMED) function pinmux_P8_19_pwm_pin group pinmux_P8_19_pwm_pin pin 9 (44e10824.0):

Re: [beagleboard] Re: Surefire PRU Example

Does anyone know how to verify a pinmux config is truly in place? I am trying to set 0x1A4 mode 5 0x05 . The dts compiles and loads but I have a feeling it is not taking. Is there a static file somewhere that holds the pru pin configs in the current state? Neil On Monday, November 7,

Re: [beagleboard] Re: Surefire PRU Example

On Mon, Nov 7, 2016 at 5:39 PM, Greg wrote: > I didn't adjust anything in the device tree. I never had to do that > before to successfully run the Remoteproc examples. The only thing I have > ever had to tweak is the pull-up/down resistors in the pads. > > When I run

Re: [beagleboard] Re: Surefire PRU Example

It's also described here: https://groups.google.com/forum/#!searchin/beagleboard/Robert$20Nelson$20remoteproc|sort:date/beagleboard/LOaTgWH7Tpo/T0eote3TAQAJ in John's first post. Which was from Roberts original "how to" post several months back it seems. On Mon, Nov 7, 2016 at 6:03 PM, William

Re: [beagleboard] Re: Surefire PRU Example

Yeah, Gregs' working kernel is from before this change. So only had remoteproc ability. Where these new kernels have the ability to enable either / or. On Mon, Nov 7, 2016 at 5:58 PM, Neil Jubinville wrote: > Look up in this thread to Robert's post I believe both are

Re: [beagleboard] Re: Surefire PRU Example

OK - *I tried to modify the BB-BONE-PRU overlay and change the pimux mode of the target pin of P9.27 and check for change* *root@beaglebone:/lib/firmware# cat $PINS | grep 9a4* *pin 105 (44e109a4.0) 0027 pinctrl-single* No change - always stays at 027 - Seems like it is ignoring

Re: [beagleboard] Re: Surefire PRU Example

I didn't adjust anything in the device tree. I never had to do that before to successfully run the Remoteproc examples. The only thing I have ever had to tweak is the pull-up/down resistors in the pads. When I run lsmod, I am seeing normal Remoteproc drivers after modprobe commands, except

Re: [beagleboard] Re: Surefire PRU Example

On Mon, Nov 7, 2016 at 5:07 PM, Greg wrote: > I'm also using 4.4.27-ti-r62. In particular, the IOT distribution. > > I'm seeing strange behavior attempting to run Remoteproc. It's like the > PRUs are missing from the device tree. I think. > > I'm comparing a working

Re: [beagleboard] Re: Surefire PRU Example

I'm also using 4.4.27-ti-r62. In particular, the IOT distribution. I'm seeing strange behavior attempting to run Remoteproc. It's like the PRUs are missing from the device tree. I think. I'm comparing a working board built with 4.4.12-ti-r31 from a few months ago. This one works perfectly.

Re: [beagleboard] Use PWM and UART at the same time

On Mon, Nov 7, 2016 at 3:56 PM, Theodosis Ntegiannakis < tntegianna...@gmail.com> wrote: > I tried twice to implement my own overlay but I gave up because I had a > significant lack of knowledge at this point. > > Finally i used cape-universala (in which pwm works fine) and enabled uart2 > and

Re: [beagleboard] Re: Surefire PRU Example

5 is for output I recall... To add root@beaglebone:~/pru/pru-gcc-examples/blinking-led/host-uio# cat $PINS | grep 9a4 pin 105 (44e109a4.0) 0027 pinctrl-single Still no toggle. Tonight I'll try to get the pin mode to change and see it in the pin debug. Neil On Monday, November 7,

Re: [beagleboard] Use PWM and UART at the same time

I tried twice to implement my own overlay but I gave up because I had a significant lack of knowledge at this point. Finally i used cape-universala (in which pwm works fine) and enabled uart2 and uart4 pins by using config-pin. Now it works! (hope nothing else has broken!) Thank you very much!

Re: [beagleboard] Re: Surefire PRU Example

Ah, I think I see. Perhaps the left most bit is to indicate input( 0 ) or output( 1 ). On Mon, Nov 7, 2016 at 2:32 PM, William Hermans wrote: > I'm not sure what the first one i trying to do other than put the pin in > GPIO mux mode. > > The second seems to be the correct

Re: [beagleboard] Re: Surefire PRU Example

I'm not sure what the first one i trying to do other than put the pin in GPIO mux mode. The second seems to be the correct one. I'd have to look up what 0x20 is ( probably pull up or down ) but mux mode 5, and 6 is generally PRU mux mode. DO also keep in mind mode 5, and 6, one mode is input,

[beagleboard] Re: does the BBGW wifi hardware have a power saving mode?

Hi Stephane, Yes WL18xx does have a power save mode which is on by default. It can be disabled with echo 0 > /sys/kernel/debug/ieee80211/phy0/wlcore/sleep_auth The SW interrupt message means that the linux driver did not get a response from the WL18xx firmware within a defined time and so

Re: [beagleboard] Re: Surefire PRU Example

Does this look right? fragment@0 { target = <_pinmux>; __overlay__ { pru_gpio_pins: pinmux_pru_gpio_pins { pinctrl-single,pins = < 0x1a4 0x0f /* P9 27 GPIO3_19:

Re: [beagleboard] Use PWM and UART at the same time

On Mon, Nov 7, 2016 at 2:18 PM, Charles Steinkuehler < char...@steinkuehler.net> wrote: > On 11/7/2016 2:38 PM, Theodosis Ntegiannakis wrote: > > > > On Monday, November 7, 2016 at 3:29:07 PM UTC+2, Charles Steinkuehler > wrote: > > > > You have to set the pins to the proper pinmux values for

Re: [beagleboard] Use PWM and UART at the same time

On Mon, Nov 7, 2016 at 1:39 PM, Theodosis Ntegiannakis < tntegianna...@gmail.com> wrote: > > > On Monday, November 7, 2016 at 9:19:58 PM UTC+2, William Hermans wrote: >> >> > and with sudo sh -c "echo 'BB-UART2' > /sys/devices/platform/bone_cap >>> emgr/slots" >>> > i get sh: echo: I/O-error >>>

Re: [beagleboard] Use PWM and UART at the same time

So if this continues to be a problem for you. Once you unload a cape, you should instead just reboot. This is not ideal, but it's what we have right now . . . On Mon, Nov 7, 2016 at 2:18 PM, William Hermans wrote: > > > On Mon, Nov 7, 2016 at 1:39 PM, Theodosis Ntegiannakis <

Re: [beagleboard] Use PWM and UART at the same time

On 11/7/2016 2:38 PM, Theodosis Ntegiannakis wrote: > > On Monday, November 7, 2016 at 3:29:07 PM UTC+2, Charles Steinkuehler wrote: > > You have to set the pins to the proper pinmux values for UART and PWM, > not just load the overlay. > > How do you suggest i should enable all the

Re: [beagleboard] Use PWM and UART at the same time

On Monday, November 7, 2016 at 9:19:58 PM UTC+2, William Hermans wrote: > > > and with sudo sh -c "echo 'BB-UART2' > >> /sys/devices/platform/bone_capemgr/slots" >> > i get sh: echo: I/O-error >> >> This generally means the cape couldn't be loaded. You can sometimes >> find more detail at the

Re: [beagleboard] Use PWM and UART at the same time

On Monday, November 7, 2016 at 3:29:07 PM UTC+2, Charles Steinkuehler wrote: > > You have to set the pins to the proper pinmux values for UART and PWM, > not just load the overlay. > > How do you suggest i should enable all the pins needed? If i try to enable BB-PWM0,1,2 overlays pwm still

Re: [beagleboard] WakeUp GPIO features is missing

william@beaglebone:~$ ls /sys/class/gpio/gpio3 active_low device direction *edge* power subsystem uevent value Set the "edge" file to "rising", "falling:, or "both". You can then perform a blocking read on the value file. Using poll(), select(), etc. This is about as close as it gets for

Re: [beagleboard] Use PWM and UART at the same time

> > > and with sudo sh -c "echo 'BB-UART2' > /sys/devices/platform/bone_ > capemgr/slots" > > i get sh: echo: I/O-error > > This generally means the cape couldn't be loaded. You can sometimes > find more detail at the end of dmesg output, but failures when trying > to load capes are usually

Re: [beagleboard] Re: Surefire PRU Example

I am using 4.4.27-ti-r62. On Monday, November 7, 2016 at 11:39:50 AM UTC-7, Neil Jubinville wrote: > > Looks like a pinmux issue - I know the LED wiring is good - tested that. > > > root@beaglebone:~/pru/pru-gcc-examples/blinking-led/pru# cat > /sys/kernel/debug/pinctrl/44e10800.pinmux/pins |

Re: [beagleboard] Re: Boot issue with ti-linux-4.1.y + TFTP + NFS

Hi Jay, The quick answer is no. If I remember correctly, I hacked the device tree fragment to set the GPIOs correctly, but found that cape would not work for my application. Using RTS to set the transmit enable is very slow for turn around. I needed to receive right away. My solution was to use a

Re: [beagleboard] Re: Where to purchase?

It is on the latest Bill of material. On Nov 7, 2016 12:32 PM, "Catudal Michel" wrote: > What is the part number for the header for the fan on the board? My Rev 2 > of the board doesn't have it. > > Le vendredi 23 septembre 2016 09:55:37 UTC-4, Gerald a écrit : >> >>

Re: [beagleboard] Re: Where to purchase?

Thank you Le 7 nov. 2016 13:36, "Gerald Coley" a écrit : > It is on the latest Bill of material. > > On Nov 7, 2016 12:32 PM, "Catudal Michel" wrote: > >> What is the part number for the header for the fan on the board? My Rev 2 >> of the board

Re: [beagleboard] Re: Surefire PRU Example

Looks like a pinmux issue - I know the LED wiring is good - tested that. root@beaglebone:~/pru/pru-gcc-examples/blinking-led/pru# cat /sys/kernel/debug/pinctrl/44e10800.pinmux/pins | grep -i 44e109a4 *pin 105 (44e109a4.0) 0027 pinctrl-single*

Re: [beagleboard] Re: Where to purchase?

What is the part number for the header for the fan on the board? My Rev 2 of the board doesn't have it. Le vendredi 23 septembre 2016 09:55:37 UTC-4, Gerald a écrit : > > Can you send me some pictures? Which inductors were rusty? > > Gerald > > On Fri, Sep 23, 2016 at 8:51 AM,

Re: [beagleboard] Re: Surefire PRU Example

Could you double check that your pin mux is correct? On my kernel I can do it with this command: $ cat /sys/kernel/debug/pinctrl/44e10800.pinmux/pins | grep -i 44e109a4 Which kernel are you using? You may also try the "md5-check" example. If md5-check passes, then the PRU firmware is loaded

[beagleboard] Re: Unable to boot or debug Ubuntu linux on beagle board rev. C3

Try changing the ttyO2 to ttyS2. On Monday, November 7, 2016 at 8:14:34 AM UTC-6, mkstart wrote: > > First of all, I am new in this field, > I am trying to boot linux on Beagle Board Rev. C3 with no success. Steps I > took for booting is taken from this wiki >

[beagleboard] Updated MacOSX RNDIS driver released

If you are running El Capitan or Sierra on a Mac, you've probably experienced the pain of getting a network connection over USB to your BeagleBone. Well, about 3 weeks ago, Joshua Wise made a new release of HoRNDIS that fixes this issue (personally confirmed on Sierra).

Re: [beagleboard] Re: Surefire PRU Example

Thx Dimitar, Ok so still no voltage toggle / led lighting on that P9_27.Any idea why the PRU will load but I am not seeing any I/O work? I am using this overlay : root@beaglebone:~/pru/pru-gcc-examples/blinking-led/host-uio# cat /lib/firmware/BB-BONE-PRU-00A0.dts /* * Copyright (C)

Re: [beagleboard] Re: Boot issue with ti-linux-4.1.y + TFTP + NFS

Colin, Did you get resolution to this? I've been trying for a couple of days to get an example python script to work. When it first runs I see the entire message transmitted while transmit enable is high. Subsequent attempts show transmit enable going low after the first byte is written.

[beagleboard] WakeUp GPIO features is missing

Hi there I want to use a GPIO interrupt wakeup for my BBB, unfortunately (and also in contrary what some people postet) i dont have the wakeup folder when i export pins. I know that only the first pin bank GPIO0_x is usable for the wakeup. Does anyone know what to initialize it and what to

[beagleboard] Unable to boot or debug Ubuntu linux on beagle board rev. C3

First of all, I am new in this field, I am trying to boot linux on Beagle Board Rev. C3 with no success. Steps I took for booting is taken from this wiki https://eewiki.net/display/linuxonarm/BeagleBoard . It is created by Robert Nelson. I can see that U-Boot is started and trying to start

Re: [beagleboard] Use PWM and UART at the same time

On 11/6/2016 4:46 PM, Theodosis Ntegiannakis wrote: > > With the above settings ADC and PWM works fine, but not UART... > Although /dev/ttyO2 and /dev/ttyO4 are present it doesn't work. You have to set the pins to the proper pinmux values for UART and PWM, not just load the overlay. > I am

[beagleboard] INPUT always reads HIGH

Hi all!. Struggling with GPIO inputs. Outputs work as expected but inputs are driving me nuts. I have unloaded all default overlays from Debian and created my own with BBB Overlay generator. Tried to put P8_37 (PIN P8.3) into input modes with 0x27, 0x37, 0x67. If it was with pulldown when i

[beagleboard] Server X & USB Keyboard

Hi, I'm trying to use xterm with the server X. THe mouse work without problem. But the I'm having an issue with the keyboard. The keyboard is detecting : [229689.444] (**) Option "config_info"