[beagleboard] Map R30/R31 EGPIO pins
I have been struggling to find a way to map which gpio pins on the BBB map to the specific bit in the R30 & R31 registers. I am probably looking for the wrong thing, but I can't find many references. If they are fixed, can't be remapped, how do I find what pins are mapped? Thanks -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups "BeagleBoard" group. To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [beagleboard] Map R30/R31 EGPIO pins
On 10/6/2014 12:01 PM, Ray Madigan wrote: > I have been struggling to find a way to map which gpio pins on the BBB map > to the specific bit in the R30 & R31 registers. I am probably looking for > the wrong thing, but I can't find many references. If they are fixed, > can't be remapped, how do I find what pins are mapped? You have to configure the pinmux for the pin(s) you want. Remember to enable the input driver, as well (also in the pinmux register). You can do this with a custom device tree overlay or by using my "universal" cape overlay (with kernel 3.8, partly supported for kernel 3.14) and the config-pin utility. On a recent RCN Debian image, just (for instance): config-pin P8.15 pruin ...to connect P8.15 to PRU 0, R31, bit 15. You may also find the pinmux spreadsheet useful, if you don't want to crawl through the TI data-sheet for the AM3358 and the BeagleBone SRM: https://github.com/cdsteinkuehler/beaglebone-black-pinmux/blob/hal_pru_generic/pinmux.ods -- Charles Steinkuehler char...@steinkuehler.net -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups "BeagleBoard" group. To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [beagleboard] Map R30/R31 EGPIO pins
Thank you for your help, I do appreciate it. This is like drinking from a fire hose :) I have a couple of questions. I read your spreadsheet and find the following pru0 has for output bits [0 - 7] and 14, 15 pru0 has for input bits [0-7] and 14, 15, 16 pru1 has for outputs [0 - 15] pru1 has for inputs [0 - 16] I am currently using pru0 simply because it is before pru1. Is there a drawback to using pru1 over pru0. my application will be focused on using about 12 input pins and the only other resource on the beaglebone is the ethernet port. If I wanted all the pins for pru0 as are on the pru1 I would have to learn the pinmux utility. I will eventually figure this out, I'm just looking to make some progress before I have to move to the next step. On Monday, October 6, 2014 10:12:25 AM UTC-7, Charles Steinkuehler wrote: > > On 10/6/2014 12:01 PM, Ray Madigan wrote: > > I have been struggling to find a way to map which gpio pins on the BBB > map > > to the specific bit in the R30 & R31 registers. I am probably looking > for > > the wrong thing, but I can't find many references. If they are fixed, > > can't be remapped, how do I find what pins are mapped? > > You have to configure the pinmux for the pin(s) you want. Remember to > enable the input driver, as well (also in the pinmux register). > > You can do this with a custom device tree overlay or by using my > "universal" cape overlay (with kernel 3.8, partly supported for kernel > 3.14) and the config-pin utility. > > On a recent RCN Debian image, just (for instance): > > config-pin P8.15 pruin > > ...to connect P8.15 to PRU 0, R31, bit 15. > > You may also find the pinmux spreadsheet useful, if you don't want to > crawl through the TI data-sheet for the AM3358 and the BeagleBone SRM: > > > https://github.com/cdsteinkuehler/beaglebone-black-pinmux/blob/hal_pru_generic/pinmux.ods > > > -- > Charles Steinkuehler > cha...@steinkuehler.net > -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups "BeagleBoard" group. To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [beagleboard] Map R30/R31 EGPIO pins
On 10/7/2014 12:39 AM, Ray Madigan wrote: > > I am currently using pru0 simply because it is before pru1. Is there a > drawback to using pru1 over pru0. The two PRU cores are identical, other than the external pins they are tied to for direct I/O. Choose the PRU core to use based on the pins you want, or if you're not using direct I/O it doesn't matter which core you choose. -- Charles Steinkuehler char...@steinkuehler.net -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups "BeagleBoard" group. To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [beagleboard] Map R30/R31 EGPIO pins
After reading lots of stuff I have what I thought might work.
Segments from my .dts
exclusive-use =
"p9.25"; /* R30[7] */
fragment@0 {
target = <&am33xx_pinmux>;
__overlay__ {
mygpio: pinmux_mygpio{
pinctrl-single,pins = <
0x1AC 0x25 /* P9.25 mode 5 pulldown output */
>;
};
};
};
If I do nothing in my pru code this pin is always high even after I reboot
the bbb.
I tried
CLR R30.T7
and the pin still remained high.
Is there something else I need to do.
On Tuesday, October 7, 2014 4:00:44 AM UTC-7, Charles Steinkuehler wrote:
>
> On 10/7/2014 12:39 AM, Ray Madigan wrote:
> >
> > I am currently using pru0 simply because it is before pru1. Is there a
> > drawback to using pru1 over pru0.
>
> The two PRU cores are identical, other than the external pins they are
> tied to for direct I/O. Choose the PRU core to use based on the pins
> you want, or if you're not using direct I/O it doesn't matter which core
> you choose.
>
> --
> Charles Steinkuehler
> cha...@steinkuehler.net
>
--
For more options, visit http://beagleboard.org/discuss
---
You received this message because you are subscribed to the Google Groups
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to beagleboard+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Re: [beagleboard] Map R30/R31 EGPIO pins
On 10/8/2014 11:10 AM, Ray Madigan wrote:
> After reading lots of stuff I have what I thought might work.
>
> Segments from my .dts
>
> exclusive-use =
>"p9.25"; /* R30[7] */
>
>
> fragment@0 {
> target = <&am33xx_pinmux>;
> __overlay__ {
> mygpio: pinmux_mygpio{
> pinctrl-single,pins = <
> 0x1AC 0x25 /* P9.25 mode 5 pulldown output */
> >;
> };
> };
> };
>
> If I do nothing in my pru code this pin is always high even after I reboot
> the bbb.
>
> I tried
> CLR R30.T7
>
> and the pin still remained high.
>
> Is there something else I need to do.
Browse the live device tree (/proc/device-tree) and make sure it's what
you expect. Typically, you create a pinctrl-single,pin entry and refer
to that in some other device. When that device is loaded, the kernel
will implement the pinmux settings referred to.
Is there some reason you're not just using config-pin and loading one of
the universal overlays?
--
Charles Steinkuehler
char...@steinkuehler.net
--
For more options, visit http://beagleboard.org/discuss
---
You received this message because you are subscribed to the Google Groups
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to beagleboard+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Re: [beagleboard] Map R30/R31 EGPIO pins
The trouble is, I don't know what to expect. I will look and see whats
there to see if I can make sense out of it.
I looked at the universal overlay when you sent the link to it and it
seemed overwhelming because of the number of entries for each pin. Now
that I have a little more experience with it I can go back and see if I can
figure it out.
All I need to do is comment out the pins in exclusive-use section that I
don't want to use and comment out all of the entries for those pins in the
fragment. Then comment out the sections for the modes I don't want for the
pins I do want?
On Wednesday, October 8, 2014 9:27:28 AM UTC-7, Charles Steinkuehler wrote:
>
> On 10/8/2014 11:10 AM, Ray Madigan wrote:
> > After reading lots of stuff I have what I thought might work.
> >
> > Segments from my .dts
> >
> > exclusive-use =
> >"p9.25"; /* R30[7] */
> >
> >
> > fragment@0 {
> > target = <&am33xx_pinmux>;
> > __overlay__ {
> > mygpio: pinmux_mygpio{
> > pinctrl-single,pins = <
> > 0x1AC 0x25 /* P9.25 mode 5 pulldown output */
> > >;
> > };
> > };
> > };
> >
> > If I do nothing in my pru code this pin is always high even after I
> reboot
> > the bbb.
> >
> > I tried
> > CLR R30.T7
> >
> > and the pin still remained high.
> >
> > Is there something else I need to do.
>
> Browse the live device tree (/proc/device-tree) and make sure it's what
> you expect. Typically, you create a pinctrl-single,pin entry and refer
> to that in some other device. When that device is loaded, the kernel
> will implement the pinmux settings referred to.
>
> Is there some reason you're not just using config-pin and loading one of
> the universal overlays?
>
> --
> Charles Steinkuehler
> cha...@steinkuehler.net
>
--
For more options, visit http://beagleboard.org/discuss
---
You received this message because you are subscribed to the Google Groups
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to beagleboard+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Re: [beagleboard] Map R30/R31 EGPIO pins
On 10/8/2014 11:43 AM, Ray Madigan wrote: > > All I need to do is comment out the pins in exclusive-use section that I > don't want to use and comment out all of the entries for those pins in the > fragment. Then comment out the sections for the modes I don't want for the > pins I do want? If you use a "stripped down" version of the universal cape overlay, you'll still have the pinmux helper in control of the pin multiplexing. That means you'll need to either setup the proper pin choice using sysfs after loading the overlay or make the desired PRU pinmux mode the default (or both). Alternately, you could add your desired pinmux settings to a custom PRU overlay based off of one of the BB-BONE-PRU overlays provided with the standard kernel. This would prevent any changes to the pinmux setting after loading the overlay, which might be good or bad, depending on exactly what you're attempting to do. -- Charles Steinkuehler char...@steinkuehler.net -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups "BeagleBoard" group. To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [beagleboard] Map R30/R31 EGPIO pins
I can't thank you enough for your help. Every response is at least another two day learning activity. I just wish I didn't have to work to pay the bills. I went back to see what I did and it turns out I misspelled the name of the dtbo file that I was using so there is no wonder it didn't work. Now I get an error that the file exists when I: echo pru_enable > /sys/devices/bone_capemgr.8/slots echo: write error: File exists prussdrv_open open failed so I guess I have more to learn :( What I am really trying to do is learn how to work with this device. This activity is to learn to write to a set of 9 or 10 pins, 8 data and one enable or 2 handshake. My next step is to read fro a set of 9 or 10 pins, 8 for data and one for write enable or 2 for a handshake. So: If I add your desired pinmux settings to a custom PRU overlay based off of one of the BB-BONE-PRU overlays provided with the standard kernel. What would be the limitations? I figure I could work out the problems at a later time. after I see an led light up:) On Wednesday, October 8, 2014 12:21:37 PM UTC-7, Charles Steinkuehler wrote: > > On 10/8/2014 11:43 AM, Ray Madigan wrote: > > > > All I need to do is comment out the pins in exclusive-use section that I > > don't want to use and comment out all of the entries for those pins in > the > > fragment. Then comment out the sections for the modes I don't want for > the > > pins I do want? > > If you use a "stripped down" version of the universal cape overlay, > you'll still have the pinmux helper in control of the pin multiplexing. > > That means you'll need to either setup the proper pin choice using sysfs > after loading the overlay or make the desired PRU pinmux mode the > default (or both). > > Alternately, you could add your desired pinmux settings to a custom PRU > overlay based off of one of the BB-BONE-PRU overlays provided with the > standard kernel. This would prevent any changes to the pinmux setting > after loading the overlay, which might be good or bad, depending on > exactly what you're attempting to do. > > -- > Charles Steinkuehler > cha...@steinkuehler.net > -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups "BeagleBoard" group. To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [beagleboard] Map R30/R31 EGPIO pins
Taking your suggestion I went out to /lib/firmware and found several dts files that used pins like I want to use them. The number of pins in the list I want are 1 to all Plus some. The one that used all the pins I want to use include lots of stuff in the ocp fragment. Is there a way to use a modified version of this one. It is BB-BONE-PRU-04-00A0.dts On Wednesday, October 8, 2014 8:56:47 PM UTC-7, Ray Madigan wrote: > > I can't thank you enough for your help. Every response is at least > another two day learning activity. I just wish I didn't have to work to > pay the bills. > > I went back to see what I did and it turns out I misspelled the name of > the dtbo file that I was using so there is no wonder it didn't work. > Now I get an error that the file exists when I: > > echo pru_enable > /sys/devices/bone_capemgr.8/slots > > echo: write error: File exists > prussdrv_open open failed > > so I guess I have more to learn :( > > What I am really trying to do is learn how to work with this device. > This activity is to learn to write to a set of 9 or 10 pins, 8 data and > one enable or 2 handshake. > > My next step is to read fro a set of 9 or 10 pins, 8 for data and one for > write enable or 2 for a handshake. > > So: > > If I add your desired pinmux settings to a custom PRU overlay based off of > one of the BB-BONE-PRU overlays provided with the standard kernel. What > would be the limitations? > > I figure I could work out the problems at a later time. after I see an > led light up:) > > > On Wednesday, October 8, 2014 12:21:37 PM UTC-7, Charles Steinkuehler > wrote: >> >> On 10/8/2014 11:43 AM, Ray Madigan wrote: >> > >> > All I need to do is comment out the pins in exclusive-use section that >> I >> > don't want to use and comment out all of the entries for those pins in >> the >> > fragment. Then comment out the sections for the modes I don't want for >> the >> > pins I do want? >> >> If you use a "stripped down" version of the universal cape overlay, >> you'll still have the pinmux helper in control of the pin multiplexing. >> >> That means you'll need to either setup the proper pin choice using sysfs >> after loading the overlay or make the desired PRU pinmux mode the >> default (or both). >> >> Alternately, you could add your desired pinmux settings to a custom PRU >> overlay based off of one of the BB-BONE-PRU overlays provided with the >> standard kernel. This would prevent any changes to the pinmux setting >> after loading the overlay, which might be good or bad, depending on >> exactly what you're attempting to do. >> >> -- >> Charles Steinkuehler >> cha...@steinkuehler.net >> > -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups "BeagleBoard" group. To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [beagleboard] Map R30/R31 EGPIO pins
I also noticed in the exclusive-use list in the universal overlays you have "pru0", "pru1", "pruss" with no other reference. I don't have them in mine? What are they for? On Wednesday, October 8, 2014 11:47:04 PM UTC-7, Ray Madigan wrote: > > Taking your suggestion I went out to /lib/firmware and found several dts > files that used pins like I want to use them. The number of pins in the > list I want are 1 to all Plus some. The one that used all the pins I want > to use include lots of stuff in the ocp fragment. Is there a way to use a > modified version of this one. It is > > BB-BONE-PRU-04-00A0.dts > > On Wednesday, October 8, 2014 8:56:47 PM UTC-7, Ray Madigan wrote: >> >> I can't thank you enough for your help. Every response is at least >> another two day learning activity. I just wish I didn't have to work to >> pay the bills. >> >> I went back to see what I did and it turns out I misspelled the name of >> the dtbo file that I was using so there is no wonder it didn't work. >> Now I get an error that the file exists when I: >> >> echo pru_enable > /sys/devices/bone_capemgr.8/slots >> >> echo: write error: File exists >> prussdrv_open open failed >> >> so I guess I have more to learn :( >> >> What I am really trying to do is learn how to work with this device. >> This activity is to learn to write to a set of 9 or 10 pins, 8 data and >> one enable or 2 handshake. >> >> My next step is to read fro a set of 9 or 10 pins, 8 for data and one for >> write enable or 2 for a handshake. >> >> So: >> >> If I add your desired pinmux settings to a custom PRU overlay based off >> of one of the BB-BONE-PRU overlays provided with the standard kernel. What >> would be the limitations? >> >> I figure I could work out the problems at a later time. after I see an >> led light up:) >> >> >> On Wednesday, October 8, 2014 12:21:37 PM UTC-7, Charles Steinkuehler >> wrote: >>> >>> On 10/8/2014 11:43 AM, Ray Madigan wrote: >>> > >>> > All I need to do is comment out the pins in exclusive-use section that >>> I >>> > don't want to use and comment out all of the entries for those pins in >>> the >>> > fragment. Then comment out the sections for the modes I don't want >>> for the >>> > pins I do want? >>> >>> If you use a "stripped down" version of the universal cape overlay, >>> you'll still have the pinmux helper in control of the pin multiplexing. >>> >>> That means you'll need to either setup the proper pin choice using sysfs >>> after loading the overlay or make the desired PRU pinmux mode the >>> default (or both). >>> >>> Alternately, you could add your desired pinmux settings to a custom PRU >>> overlay based off of one of the BB-BONE-PRU overlays provided with the >>> standard kernel. This would prevent any changes to the pinmux setting >>> after loading the overlay, which might be good or bad, depending on >>> exactly what you're attempting to do. >>> >>> -- >>> Charles Steinkuehler >>> cha...@steinkuehler.net >>> >> -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups "BeagleBoard" group. To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [beagleboard] Map R30/R31 EGPIO pins
I found a problem that P9_31 conflicts with the HDMI Overlay so I will have to figure out if I try to eliminate it because it is not going to be used or if I can move the output to the pru1. On Wednesday, October 8, 2014 11:59:37 PM UTC-7, Ray Madigan wrote: > > I also noticed in the exclusive-use list in the universal overlays you > have "pru0", "pru1", "pruss" with no other reference. I don't have them in > mine? What are they for? > > On Wednesday, October 8, 2014 11:47:04 PM UTC-7, Ray Madigan wrote: >> >> Taking your suggestion I went out to /lib/firmware and found several dts >> files that used pins like I want to use them. The number of pins in the >> list I want are 1 to all Plus some. The one that used all the pins I want >> to use include lots of stuff in the ocp fragment. Is there a way to use a >> modified version of this one. It is >> >> BB-BONE-PRU-04-00A0.dts >> >> On Wednesday, October 8, 2014 8:56:47 PM UTC-7, Ray Madigan wrote: >>> >>> I can't thank you enough for your help. Every response is at least >>> another two day learning activity. I just wish I didn't have to work to >>> pay the bills. >>> >>> I went back to see what I did and it turns out I misspelled the name of >>> the dtbo file that I was using so there is no wonder it didn't work. >>> Now I get an error that the file exists when I: >>> >>> echo pru_enable > /sys/devices/bone_capemgr.8/slots >>> >>> echo: write error: File exists >>> prussdrv_open open failed >>> >>> so I guess I have more to learn :( >>> >>> What I am really trying to do is learn how to work with this device. >>> This activity is to learn to write to a set of 9 or 10 pins, 8 data and >>> one enable or 2 handshake. >>> >>> My next step is to read fro a set of 9 or 10 pins, 8 for data and one >>> for write enable or 2 for a handshake. >>> >>> So: >>> >>> If I add your desired pinmux settings to a custom PRU overlay based off >>> of one of the BB-BONE-PRU overlays provided with the standard kernel. What >>> would be the limitations? >>> >>> I figure I could work out the problems at a later time. after I see an >>> led light up:) >>> >>> >>> On Wednesday, October 8, 2014 12:21:37 PM UTC-7, Charles Steinkuehler >>> wrote: On 10/8/2014 11:43 AM, Ray Madigan wrote: > > All I need to do is comment out the pins in exclusive-use section that I > don't want to use and comment out all of the entries for those pins in the > fragment. Then comment out the sections for the modes I don't want for the > pins I do want? If you use a "stripped down" version of the universal cape overlay, you'll still have the pinmux helper in control of the pin multiplexing. That means you'll need to either setup the proper pin choice using sysfs after loading the overlay or make the desired PRU pinmux mode the default (or both). Alternately, you could add your desired pinmux settings to a custom PRU overlay based off of one of the BB-BONE-PRU overlays provided with the standard kernel. This would prevent any changes to the pinmux setting after loading the overlay, which might be good or bad, depending on exactly what you're attempting to do. -- Charles Steinkuehler cha...@steinkuehler.net >>> -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups "BeagleBoard" group. To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [beagleboard] Map R30/R31 EGPIO pins
On 10/8/2014 10:56 PM, Ray Madigan wrote: > I can't thank you enough for your help. Every response is at least another > two day learning activity. I just wish I didn't have to work to pay the > bills. > > I went back to see what I did and it turns out I misspelled the name of the > dtbo file that I was using so there is no wonder it didn't work. > Now I get an error that the file exists when I: > > echo pru_enable > /sys/devices/bone_capemgr.8/slots > > echo: write error: File exists > prussdrv_open open failed > > so I guess I have more to learn :( The errors from capemgr are really cryptic. You'll typically see "File exists" when something you're trying to add to the device tree is already in use. There may be slightly more information in dmesg or the kernel log. Also note it is not really possible to unload a device-tree overlay, so testing is a cycle of boot - test - shutdown. :( > What I am really trying to do is learn how to work with this device. > This activity is to learn to write to a set of 9 or 10 pins, 8 data and one > enable or 2 handshake. > > My next step is to read fro a set of 9 or 10 pins, 8 for data and one for > write enable or 2 for a handshake. > > So: > > If I add your desired pinmux settings to a custom PRU overlay based off of > one of the BB-BONE-PRU overlays provided with the standard kernel. What > would be the limitations? If you make a custom overlay and "hard-code" the pins you want to the desired mode, the limitation is from then on you won't be able to change them (without rebooting to unload your custom overlay). If you use the pinmux-helper as is done in the universal overlay, you can switch between the available modes at run-time (via the generated sysfs entries). -- Charles Steinkuehler char...@steinkuehler.net -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups "BeagleBoard" group. To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [beagleboard] Map R30/R31 EGPIO pins
On 10/9/2014 1:47 AM, Ray Madigan wrote: > Taking your suggestion I went out to /lib/firmware and found several dts > files that used pins like I want to use them. The number of pins in the > list I want are 1 to all Plus some. The one that used all the pins I want > to use include lots of stuff in the ocp fragment. Is there a way to use a > modified version of this one. It is > > BB-BONE-PRU-04-00A0.dts Sure, just edit, compile with dtc [1], copy to /lib/firmware, and load. ...the same as you would do for any other device-tree overlay. [1] dtc -O dtb -o file.dtbo -b 0 -@ file.dts -- Charles Steinkuehler char...@steinkuehler.net -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups "BeagleBoard" group. To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [beagleboard] Map R30/R31 EGPIO pins
On 10/9/2014 1:59 AM, Ray Madigan wrote: > I also noticed in the exclusive-use list in the universal overlays you have > "pru0", "pru1", "pruss" with no other reference. I don't have them in > mine? What are they for? I haven't delved through the source for what looks at the exclusive-use section, but it seems like a poor-man's "collision detection" for loading device-tree overlays. My entries were basically copied from the existing overlay files, which seemed to use an assortment of naming conventions (thus there are several near-duplicates in my universal overlay). :) -- Charles Steinkuehler char...@steinkuehler.net -- For more options, visit http://beagleboard.org/discuss --- You received this message because you are subscribed to the Google Groups "BeagleBoard" group. To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
