Re: [beagleboard] Unlimited storage on Amazon cloud drive for $5

[John Syne]

I saw this yesterday. Amazing.

Regards,
John




> On Nov 27, 2015, at 11:24 PM, William Hermans  wrote:
> 
> Same price as the Raspberry PI zero. 5 Bux ;)
> 
> So, I'm not exactly an rPI fan, by far. But for 5 bux . . . Or even free if 
> you live in the UK, and have the ability to buy MagPI #40. As one comes in a 
> packet attached to this months dead tree copy of MagPI.
> 
> On Sat, Nov 28, 2015 at 12:10 AM, John Syne  > wrote:
> Hey guys, I read an article today which says Amazon is making their cloud 
> drive unlimited storage for 1 year available for $5. Seems like a crappy 
> interface, but for $5 for unlimited storage, who cares. 
> 
> http://mashable.com/2015/11/27/amazon-unlimited-cloud-storage-deal/#DmOVQBpWSaqs
>  
> 
> 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 
> .

-- 
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] Unlimited storage on Amazon cloud drive for $5

[John Syne]

By then there will be even cheaper options available ;-)

Regards,
John




> On Nov 27, 2015, at 11:37 PM, Rick Mann  wrote:
> 
> First one's free: you upload terabytes of data, then your year is up, and 
> what're you gonna do?
> 
>> On Nov 27, 2015, at 23:10 , John Syne  wrote:
>> 
>> Hey guys, I read an article today which says Amazon is making their cloud 
>> drive unlimited storage for 1 year available for $5. Seems like a crappy 
>> interface, but for $5 for unlimited storage, who cares. 
>> 
>> http://mashable.com/2015/11/27/amazon-unlimited-cloud-storage-deal/#DmOVQBpWSaqs
>> 
>> 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.
> 
> 
> -- 
> Rick Mann
> rm...@latencyzero.com
> 
> 
> -- 
> For more options, visit http://beagleboard.org/discuss
> --- 
> You received this message because you are subscribed to the Google Groups 
> "BeagleBoard" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to beagleboard+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Unlimited storage on Amazon cloud drive for $5

[Rick Mann]

First one's free: you upload terabytes of data, then your year is up, and 
what're you gonna do?

> On Nov 27, 2015, at 23:10 , John Syne  wrote:
> 
> Hey guys, I read an article today which says Amazon is making their cloud 
> drive unlimited storage for 1 year available for $5. Seems like a crappy 
> interface, but for $5 for unlimited storage, who cares. 
> 
> http://mashable.com/2015/11/27/amazon-unlimited-cloud-storage-deal/#DmOVQBpWSaqs
> 
> 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.


-- 
Rick Mann
rm...@latencyzero.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] Unlimited storage on Amazon cloud drive for $5

[William Hermans]

Same price as the Raspberry PI zero. 5 Bux ;)

So, I'm not exactly an rPI fan, by far. But for 5 bux . . . Or even free if
you live in the UK, and have the ability to buy MagPI #40. As one comes in
a packet attached to this months dead tree copy of MagPI.

On Sat, Nov 28, 2015 at 12:10 AM, John Syne  wrote:

> Hey guys, I read an article today which says Amazon is making their cloud
> drive unlimited storage for 1 year available for $5. Seems like a crappy
> interface, but for $5 for unlimited storage, who cares.
>
>
> http://mashable.com/2015/11/27/amazon-unlimited-cloud-storage-deal/#DmOVQBpWSaqs
>
> 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.

[beagleboard] Unlimited storage on Amazon cloud drive for $5

[John Syne]

Hey guys, I read an article today which says Amazon is making their cloud drive 
unlimited storage for 1 year available for $5. Seems like a crappy interface, 
but for $5 for unlimited storage, who cares. 

http://mashable.com/2015/11/27/amazon-unlimited-cloud-storage-deal/#DmOVQBpWSaqs
 

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.

Re: [beagleboard] Debian Overlay / Pinmux not working?

[William Hermans]

Unless you want to run the pin as GPIO Output mode, with the internal
pullup enabled.

gmail is really starting to annoy me today . . .

On Sat, Nov 28, 2015 at 12:04 AM, William Hermans  wrote:

> *I guess what you are saying is 0x17 is not a valid mode for the pins I
>> selected?  *
>>
>
> No. Read to comment in the code here:
>
> /* OUTPUT  GPIO(mode7) 0x07 pulldown, *0x17* pullup, 0x?f no pullup/down
> */
> /* INPUT   GPIO(mode7) *0x27* pulldown, 0x37 pullup, 0x?f no pullup/down
> */
>
> Whats the first word of each comment say ? I know the formating could be
> better for readability sake, but it's all explained right here in these two
> comments.
>
> In other words, 0x17 is the wrong pinmux for what you wanted to do. Unless
> you want to run the pin as GPI mode, with the internal pullup enabled.
>
>
> On Fri, Nov 27, 2015 at 11:52 PM, Riley Porter 
> wrote:
>
>> OK guys.
>>
>> dtc version here:
>>
>> root ~/bbb_stuff # dtc --version
>> Version: DTC 1.4.1-g71222ad7
>>
>> So after reading your comments I changed my overlay to 0x27 vs 0x17.  I
>> actually want an INPUT with a pulldown for my application.  I tried 0x17 to
>> see if I could control the pin modes for sure.  I guess what you are saying
>> is 0x17 is not a valid mode for the pins I selected?  Either way I changed
>> my overlay to this:
>>
>> /dts-v1/;
>> /plugin/;
>>
>> /{
>>compatible = "ti,beaglebone", "ti,beaglebone-black";
>>part-number = "EBB-GPIO-Example";
>>version = "00A0";
>>
>>fragment@0 {
>>  target = <&am33xx_pinmux>;
>>
>>  __overlay__ {
>>   ebb_example: EBB_GPIO_Example {
>> pinctrl-single,pins = <
>>
>>
>> /*= Player One Shmoo Deck
>> Inputs */
>> 0x070 0x27  // P9_11 PINS$28 GPIO0_30 =
>> 30 Input Mode7 pulldown
>> 0x078 0x27  // P9_12 PINS$30 GPIO1_28 =
>> 60 Input Mode7 pulldown
>> 0x074 0x27  // P9_13 PINS$29 GPIO0_31 =
>> 31 Input Mode7 pulldown
>> 0x048 0x27  // P9_14 PINS$18 GPIO1_18 =
>> 50 Input Mode7 pulldown
>> 0x040 0x27  // P9_15 PINS$16 GPIO1_16 =
>> 48 Input Mode7 pulldown
>> 0x04c 0x27  // P9_16 PINS$19 GPIO1_19 =
>> 51 Input Mode7 pulldown
>> 0x15c 0x27  // P9_17 PINS$87 GPIO0_5  =
>>  5 Input Mode7 pulldown
>> 0x158 0x27  // P9_18 PINS$86 GPIO0_4  =
>>  4 Input Mode7 pulldown
>>
>> /* OUTPUT  GPIO(mode7) 0x07 pulldown,
>> 0x17 pullup, 0x?f no pullup/down */
>> /* INPUT   GPIO(mode7) 0x27 pulldown,
>> 0x37 pullup, 0x?f no pullup/down */
>> >;
>>   };
>>  };
>>};
>>
>>fragment@1 {
>> target = <&ocp>;
>> __overlay__ {
>> gpio_helper {
>> compatible = "gpio-of-helper";
>> status = "okay";
>> pinctrl-names = "default";
>> pinctrl-0 = <&ebb_example>;
>> };
>> };
>> };
>> };
>>
>>
>> On boot this is the state of slots and the pins in my overlay that I will
>> be changing once its applied.
>>
>> root ~/bbb_stuff # ./getpins
>> ==
>> Reading Pinux Pins
>> ==
>> pin 16 (44e10840.0) 0027 pinctrl-single
>> pin 18 (44e10848.0) 0027 pinctrl-single
>> pin 19 (44e1084c.0) 0027 pinctrl-single
>> pin 28 (44e10870.0) 0037 pinctrl-single
>> pin 29 (44e10874.0) 0037 pinctrl-single
>> pin 30 (44e10878.0) 0037 pinctrl-single
>> pin 86 (44e10958.0) 0037 pinctrl-single
>> pin 87 (44e1095c.0) 0037 pinctrl-single
>> root ~/bbb_stuff # slots
>>  0: PF  -1
>>  1: PF  -1
>>  2: PF  -1
>>  3: PF  -1
>>  4: P-O-L-   0 Override Board Name,00A0,Override Manuf,cape-universaln
>>
>>
>> *I remove the auto loaded overlay (From where is this loaded I am not
>> sure??)*
>>
>> root ~/bbb_stuff # echo -4 > $SLOTS
>> root ~/bbb_stuff # slots
>>  0: PF  -1
>>  1: PF  -1
>>  2: PF  -1
>>  3: PF  -1
>>
>> *I install my overlay:*
>> root ~/bbb_stuff # make install
>> --
>> INSTALLING EBB-GPIO-Example-00A0.dtbo to /lib/firmware
>> cp EBB-GPIO-Example-00A0.dtbo /lib/firmware
>> Activating EBB-GPIO-Example-00A0.dtbo overlay
>> echo  EBB-GPIO-Example-00A0 > "/sys/devices/platform/bone_capemgr/slots"
>> --
>>
>>
>> *Check my slots*
>> root ~/bbb_stuff # slots
>>  0: PF  -1
>>  1: PF  -1
>>  2: PF  -1
>>  3: PF  -1
>>  5: P-O-L- 

Re: [beagleboard] Debian Overlay / Pinmux not working?

[William Hermans]

>
> *I guess what you are saying is 0x17 is not a valid mode for the pins I
> selected?  *
>

No. Read to comment in the code here:

/* OUTPUT  GPIO(mode7) 0x07 pulldown, *0x17* pullup, 0x?f no pullup/down */
/* INPUT   GPIO(mode7) *0x27* pulldown, 0x37 pullup, 0x?f no pullup/down */

Whats the first word of each comment say ? I know the formating could be
better for readability sake, but it's all explained right here in these two
comments.

In other words, 0x17 is the wrong pinmux for what you wanted to do. Unless
you want to run the pin as GPI mode, with the internal pullup enabled.


On Fri, Nov 27, 2015 at 11:52 PM, Riley Porter 
wrote:

> OK guys.
>
> dtc version here:
>
> root ~/bbb_stuff # dtc --version
> Version: DTC 1.4.1-g71222ad7
>
> So after reading your comments I changed my overlay to 0x27 vs 0x17.  I
> actually want an INPUT with a pulldown for my application.  I tried 0x17 to
> see if I could control the pin modes for sure.  I guess what you are saying
> is 0x17 is not a valid mode for the pins I selected?  Either way I changed
> my overlay to this:
>
> /dts-v1/;
> /plugin/;
>
> /{
>compatible = "ti,beaglebone", "ti,beaglebone-black";
>part-number = "EBB-GPIO-Example";
>version = "00A0";
>
>fragment@0 {
>  target = <&am33xx_pinmux>;
>
>  __overlay__ {
>   ebb_example: EBB_GPIO_Example {
> pinctrl-single,pins = <
>
>
> /*= Player One Shmoo Deck
> Inputs */
> 0x070 0x27  // P9_11 PINS$28 GPIO0_30 = 30
> Input Mode7 pulldown
> 0x078 0x27  // P9_12 PINS$30 GPIO1_28 = 60
> Input Mode7 pulldown
> 0x074 0x27  // P9_13 PINS$29 GPIO0_31 = 31
> Input Mode7 pulldown
> 0x048 0x27  // P9_14 PINS$18 GPIO1_18 = 50
> Input Mode7 pulldown
> 0x040 0x27  // P9_15 PINS$16 GPIO1_16 = 48
> Input Mode7 pulldown
> 0x04c 0x27  // P9_16 PINS$19 GPIO1_19 = 51
> Input Mode7 pulldown
> 0x15c 0x27  // P9_17 PINS$87 GPIO0_5  =  5
> Input Mode7 pulldown
> 0x158 0x27  // P9_18 PINS$86 GPIO0_4  =  4
> Input Mode7 pulldown
>
> /* OUTPUT  GPIO(mode7) 0x07 pulldown, 0x17
> pullup, 0x?f no pullup/down */
> /* INPUT   GPIO(mode7) 0x27 pulldown, 0x37
> pullup, 0x?f no pullup/down */
> >;
>   };
>  };
>};
>
>fragment@1 {
> target = <&ocp>;
> __overlay__ {
> gpio_helper {
> compatible = "gpio-of-helper";
> status = "okay";
> pinctrl-names = "default";
> pinctrl-0 = <&ebb_example>;
> };
> };
> };
> };
>
>
> On boot this is the state of slots and the pins in my overlay that I will
> be changing once its applied.
>
> root ~/bbb_stuff # ./getpins
> ==
> Reading Pinux Pins
> ==
> pin 16 (44e10840.0) 0027 pinctrl-single
> pin 18 (44e10848.0) 0027 pinctrl-single
> pin 19 (44e1084c.0) 0027 pinctrl-single
> pin 28 (44e10870.0) 0037 pinctrl-single
> pin 29 (44e10874.0) 0037 pinctrl-single
> pin 30 (44e10878.0) 0037 pinctrl-single
> pin 86 (44e10958.0) 0037 pinctrl-single
> pin 87 (44e1095c.0) 0037 pinctrl-single
> root ~/bbb_stuff # slots
>  0: PF  -1
>  1: PF  -1
>  2: PF  -1
>  3: PF  -1
>  4: P-O-L-   0 Override Board Name,00A0,Override Manuf,cape-universaln
>
>
> *I remove the auto loaded overlay (From where is this loaded I am not
> sure??)*
>
> root ~/bbb_stuff # echo -4 > $SLOTS
> root ~/bbb_stuff # slots
>  0: PF  -1
>  1: PF  -1
>  2: PF  -1
>  3: PF  -1
>
> *I install my overlay:*
> root ~/bbb_stuff # make install
> --
> INSTALLING EBB-GPIO-Example-00A0.dtbo to /lib/firmware
> cp EBB-GPIO-Example-00A0.dtbo /lib/firmware
> Activating EBB-GPIO-Example-00A0.dtbo overlay
> echo  EBB-GPIO-Example-00A0 > "/sys/devices/platform/bone_capemgr/slots"
> --
>
>
> *Check my slots*
> root ~/bbb_stuff # slots
>  0: PF  -1
>  1: PF  -1
>  2: PF  -1
>  3: PF  -1
>  5: P-O-L-   0 Override Board Name,00A0,Override Manuf,EBB-GPIO-Example
> root ~/bbb_stuff # ./getpins
> ==
> Reading Pinux Pins
> ==
> pin 16 (44e10840.0) 0027 pinctrl-single
> pin 18 (44e10848.0) 0027 pinctrl-single
> pin 19 (44e1084c.0) 0027 pinctr

Re: [beagleboard] Debian Overlay / Pinmux not working?

[Riley Porter]

OK guys.

dtc version here:

root ~/bbb_stuff # dtc --version
Version: DTC 1.4.1-g71222ad7

So after reading your comments I changed my overlay to 0x27 vs 0x17.  I
actually want an INPUT with a pulldown for my application.  I tried 0x17 to
see if I could control the pin modes for sure.  I guess what you are saying
is 0x17 is not a valid mode for the pins I selected?  Either way I changed
my overlay to this:

/dts-v1/;
/plugin/;

/{
   compatible = "ti,beaglebone", "ti,beaglebone-black";
   part-number = "EBB-GPIO-Example";
   version = "00A0";

   fragment@0 {
 target = <&am33xx_pinmux>;

 __overlay__ {
  ebb_example: EBB_GPIO_Example {
pinctrl-single,pins = <


/*= Player One Shmoo Deck
Inputs */
0x070 0x27  // P9_11 PINS$28 GPIO0_30 = 30
Input Mode7 pulldown
0x078 0x27  // P9_12 PINS$30 GPIO1_28 = 60
Input Mode7 pulldown
0x074 0x27  // P9_13 PINS$29 GPIO0_31 = 31
Input Mode7 pulldown
0x048 0x27  // P9_14 PINS$18 GPIO1_18 = 50
Input Mode7 pulldown
0x040 0x27  // P9_15 PINS$16 GPIO1_16 = 48
Input Mode7 pulldown
0x04c 0x27  // P9_16 PINS$19 GPIO1_19 = 51
Input Mode7 pulldown
0x15c 0x27  // P9_17 PINS$87 GPIO0_5  =  5
Input Mode7 pulldown
0x158 0x27  // P9_18 PINS$86 GPIO0_4  =  4
Input Mode7 pulldown

/* OUTPUT  GPIO(mode7) 0x07 pulldown, 0x17
pullup, 0x?f no pullup/down */
/* INPUT   GPIO(mode7) 0x27 pulldown, 0x37
pullup, 0x?f no pullup/down */
>;
  };
 };
   };

   fragment@1 {
target = <&ocp>;
__overlay__ {
gpio_helper {
compatible = "gpio-of-helper";
status = "okay";
pinctrl-names = "default";
pinctrl-0 = <&ebb_example>;
};
};
};
};


On boot this is the state of slots and the pins in my overlay that I will
be changing once its applied.

root ~/bbb_stuff # ./getpins
==
Reading Pinux Pins
==
pin 16 (44e10840.0) 0027 pinctrl-single
pin 18 (44e10848.0) 0027 pinctrl-single
pin 19 (44e1084c.0) 0027 pinctrl-single
pin 28 (44e10870.0) 0037 pinctrl-single
pin 29 (44e10874.0) 0037 pinctrl-single
pin 30 (44e10878.0) 0037 pinctrl-single
pin 86 (44e10958.0) 0037 pinctrl-single
pin 87 (44e1095c.0) 0037 pinctrl-single
root ~/bbb_stuff # slots
 0: PF  -1
 1: PF  -1
 2: PF  -1
 3: PF  -1
 4: P-O-L-   0 Override Board Name,00A0,Override Manuf,cape-universaln


*I remove the auto loaded overlay (From where is this loaded I am not
sure??)*

root ~/bbb_stuff # echo -4 > $SLOTS
root ~/bbb_stuff # slots
 0: PF  -1
 1: PF  -1
 2: PF  -1
 3: PF  -1

*I install my overlay:*
root ~/bbb_stuff # make install
--
INSTALLING EBB-GPIO-Example-00A0.dtbo to /lib/firmware
cp EBB-GPIO-Example-00A0.dtbo /lib/firmware
Activating EBB-GPIO-Example-00A0.dtbo overlay
echo  EBB-GPIO-Example-00A0 > "/sys/devices/platform/bone_capemgr/slots"
--


*Check my slots*
root ~/bbb_stuff # slots
 0: PF  -1
 1: PF  -1
 2: PF  -1
 3: PF  -1
 5: P-O-L-   0 Override Board Name,00A0,Override Manuf,EBB-GPIO-Example
root ~/bbb_stuff # ./getpins
==
Reading Pinux Pins
==
pin 16 (44e10840.0) 0027 pinctrl-single
pin 18 (44e10848.0) 0027 pinctrl-single
pin 19 (44e1084c.0) 0027 pinctrl-single
pin 28 (44e10870.0) 0027 pinctrl-single
pin 29 (44e10874.0) 0027 pinctrl-single
pin 30 (44e10878.0) 0027 pinctrl-single
pin 86 (44e10958.0) 0027 pinctrl-single
pin 87 (44e1095c.0) 0027 pinctrl-single


So it does look like its working?  My issue I guess was me overthinking
it.  I really wanted to make sure it was working so I changed the values to
0x17 to make sure it would "change" but it was apparently a dumb setting
and would not work.  Ugh  Sorry to have wasted your time guys!  But I
learned a bunch in the process.  I have had a beagle bone for a few years
now but always have seen it as a "little linux box" which it is so much
more!  This thing is great.  I am so glad its finally working now with the
4.1 kernel and overlays.

upward and onward.

One last question, do you guys know of any good indepth overlay device tree
tutorials that explai

Re: [beagleboard] Debian Overlay / Pinmux not working?

[John Syne]

Yeah, but they are both connected to P9 Pin15.

Regards,
John




> On Nov 27, 2015, at 10:28 PM, William Hermans  wrote:
> 
> That still does not explain how 0x40 == 0x880 in 
> /sys/kernel/debug/pinctrl/44e10800.pinmux/pins. It should be 840 . . . or  
> 44e10840 if you prefer.
> 
> On Fri, Nov 27, 2015 at 11:24 PM, John Syne  > wrote:
> P9 HEADER LINUX PIN   ADDR/OFFSET TRM NAMEGPIO NO.
> P9_15A16  0x840/040   GPIO1_1648
> P9_15B34  0x888/088   GPIO1_1664
> 
> Regards,
> John
> 
> 
> 
> 
>> On Nov 27, 2015, at 10:18 PM, John Syne > > wrote:
>> 
>> P9_15A   16  0x840/040   GPIO1_1648
>> P9_15B   34  0x888/088   GPIO1_1664
>> 
>> Regards,
>> John
>> 
>> 
>> 
>> 
>>> On Nov 27, 2015, at 10:10 PM, William Hermans >> > wrote:
>>> 
>>> Or, more correctly I suppose . . .
>>> 
>>> Pin value = 32 * GPIO bank + pin number.
>>> 
>>> Where. . .
>>> 
>>> GPIO Bank == 0-3
>>> Pin number == 0-31
>>> 
>>> On Fri, Nov 27, 2015 at 11:07 PM, William Hermans >> > wrote:
>>> BTW, 840 is connected to 888, so that pin might not be the best pin to 
>>> test. Either way, I don’t understand why the Overlay manager doesn’t 
>>> complain about a pin conflict. 
>>> 
>>> Ok you're going to have to explain that. Since the pin I checked changed. 
>>> And I've always understood that . . . 32*+=pin 
>>> value
>>> 
>>> On Fri, Nov 27, 2015 at 11:03 PM, John Syne >> > wrote:
>>> Hi William,
>>> 
>>> I think you are right, there must be some sort of conflict on Riley’s 
>>> system. BTW, 840 is connected to 888, so that pin might not be the best pin 
>>> to test. Either way, I don’t understand why the Overlay manager doesn’t 
>>> complain about a pin conflict. 
>>> 
>>> Regards,
>>> John
>>> 
>>> 
>>> 
>>> 
 On Nov 27, 2015, at 9:55 PM, William Hermans >>> > wrote:
 
 OK so I thought maybe I forgot to copy the newly compiled overlay over . . 
 .
 
 $ ls |grep pin
 pinctrl-test-7-00A0.dtbo
 pinctrl-test-7.dts
 
 $ rm pin*
 $ ls |grep pin
 < No output >
 
 $ cp /lib/firmware/pinctrl-test-7-00A0.dtbo .
 $ dtc -I dtb -O dts pinctrl-test-7-00A0.dtbo > pinctrl-test-7-00A0.dts
 
 /dts-v1/;
 
 / {
 compatible = "ti,beaglebone", "ti,beaglebone-black";
 part-number = "pinctrl-test-7";
 
 fragment@0 {
 target = <0xdeadbeef>;
 
 __overlay__ {
 
 pinctrl_test_7_pins {
 pinctrl-single,pins = <0x40 0x27>;
 linux,phandle = <0x1>;
 phandle = <0x1>;
 };
 };
 };
 
 fragment@1 {
 target = <0xdeadbeef>;
 
 __overlay__ {
 
 helper {
 compatible = "gpio-of-helper";
 pinctrl-names = "default";
 pinctrl-0 = <0x1>;
 status = "okay";
 linux,phandle = <0x2>;
 phandle = <0x2>;
 };
 };
 };
 
 __symbols__ {
 pinctrl_test = "/fragment@0/__overlay__/pinctrl_test_7_pins";
 test_helper = "/fragment@1/__overlay__/helper";
 };
 
 __local_fixups__ {
 
 fragment@1 {
 
 __overlay__ {
 
 helper {
 pinctrl-0 = <0x0>;
 };
 };
 };
 };
 
 __fixups__ {
 am33xx_pinmux = "/fragment@0:target:0";
 ocp = "/fragment@1:target:0";
 };
 };
 
 Ok, so this source mangling seems odd, but just looking things over, it 
 seems like it should work. Next, reboot, and reload, then see what happens.
 
 On Fri, Nov 27, 2015 at 10:40 PM, William Hermans >>> > wrote:
 Smells of a bug. But perhaps the GPIO pinmux's need to be explicity 
 cleared as I mentioned above ?
 
 On Fri, Nov 27, 2015 at 10:39 PM, William Hermans >>> > wrote:
 OK so I changed to this:
 
 fragment@0 {
 target = <&am33xx_pinmux>;
 __overlay__ {
 pinctrl_test: pinctrl_test_7_pins {
 pinctrl-single,pins = <
 0x040 0x27  // P9_15 PINS$16 GPIO1_16 = 48 Input Mode7 
 pullup
 >;
 };
 };
 };
 
 Compiled, copied, and then loaded the dtbo file. Then . . .
 
 $ dmesg |grep pinctrl-test-7
 [168784.685978] bone_capemgr bone_capemgr: part_number 'pinctrl-test-7', 
 version 'N/A'
 [168784.706649] bone_capemgr bo

Re: [beagleboard] Debian Overlay / Pinmux not working?

[William Hermans]

OK John, gotcha.

So now idea how to why this is happening. But, it kind of seems like
capemgr does not truly work "on the fly" as It is purported to do. e.g. it
works once, but then a reboot is needed to change the pinmux value.

*OR*

I do recall reading somewhere in the TRM, around the part you originally
talked about John( table 9-60 I think ) where you can clear the pin by
writing a value of '1' to a bit location . . . but it could be the TRM was
talking about something else perhaps

On Fri, Nov 27, 2015 at 11:28 PM, John Syne  wrote:

> Yeah, you are right, but he also tested on 870, which doesn’t have this
> conflict. I’m just trying to avoid any other problems that might influence
> this issue.
>
> Regards,
> John
>
>
>
>
> On Nov 27, 2015, at 10:22 PM, William Hermans  wrote:
>
> As per Riley's overlay source, I only copy pasted it. But changed the
> pinmux from 0x17, to 0x27 as a test.
>
> 0x040 0x27  // P9_15 PINS$16 GPIO1_16 = 48 Input Mode7 pullup
>
> On Fri, Nov 27, 2015 at 11:18 PM, John Syne  wrote:
>
>> P9_15A 16 0x840/040 GPIO1_16 48 P9_15B 34 0x888/088 GPIO1_16 64
>>
>> Regards,
>> John
>>
>>
>>
>>
>> On Nov 27, 2015, at 10:10 PM, William Hermans  wrote:
>>
>> Or, more correctly I suppose . . .
>>
>> Pin value = 32 * GPIO bank + pin number.
>>
>> Where. . .
>>
>> GPIO Bank == 0-3
>> Pin number == 0-31
>>
>> On Fri, Nov 27, 2015 at 11:07 PM, William Hermans 
>> wrote:
>>
>>> *BTW, 840 is connected to 888, so that pin might not be the best pin to
 test. Either way, I don’t understand why the Overlay manager doesn’t
 complain about a pin conflict. *

>>>
>>> Ok you're going to have to explain that. Since the pin I checked
>>> changed. And I've always understood that . . . 32*+>> pin #>=pin value
>>>
>>> On Fri, Nov 27, 2015 at 11:03 PM, John Syne  wrote:
>>>
 Hi William,

 I think you are right, there must be some sort of conflict on Riley’s
 system. BTW, 840 is connected to 888, so that pin might not be the best pin
 to test. Either way, I don’t understand why the Overlay manager doesn’t
 complain about a pin conflict.

 Regards,
 John




 On Nov 27, 2015, at 9:55 PM, William Hermans  wrote:

 OK so I thought maybe I forgot to copy the newly compiled overlay over
 . . .

 $ ls |grep pin
 pinctrl-test-7-00A0.dtbo
 pinctrl-test-7.dts

 $ rm pin*
 $ ls |grep pin
 < No output >

 $ cp /lib/firmware/pinctrl-test-7-00A0.dtbo .
 $ dtc -I dtb -O dts pinctrl-test-7-00A0.dtbo > pinctrl-test-7-00A0.dts

 /dts-v1/;

 / {
 compatible = "ti,beaglebone", "ti,beaglebone-black";
 part-number = "pinctrl-test-7";

 fragment@0 {
 target = <0xdeadbeef>;

 __overlay__ {

 pinctrl_test_7_pins {
 pinctrl-single,pins = <0x40 0x27>;
 linux,phandle = <0x1>;
 phandle = <0x1>;
 };
 };
 };

 fragment@1 {
 target = <0xdeadbeef>;

 __overlay__ {

 helper {
 compatible = "gpio-of-helper";
 pinctrl-names = "default";
 pinctrl-0 = <0x1>;
 status = "okay";
 linux,phandle = <0x2>;
 phandle = <0x2>;
 };
 };
 };

 __symbols__ {
 pinctrl_test = "/fragment@0/__overlay__/pinctrl_test_7_pins";
 test_helper = "/fragment@1/__overlay__/helper";
 };

 __local_fixups__ {

 fragment@1 {

 __overlay__ {

 helper {
 pinctrl-0 = <0x0>;
 };
 };
 };
 };

 __fixups__ {
 am33xx_pinmux = "/fragment@0:target:0";
 ocp = "/fragment@1:target:0";
 };
 };

 Ok, so this source mangling seems odd, but just looking things over, it
 seems like it should work. Next, reboot, and reload, then see what happens.

 On Fri, Nov 27, 2015 at 10:40 PM, William Hermans 
 wrote:

> Smells of a bug. But perhaps the GPIO pinmux's need to be explicity
> cleared as I mentioned above ?
>
> On Fri, Nov 27, 2015 at 10:39 PM, William Hermans 
> wrote:
>
>> OK so I changed to this:
>>
>> fragment@0 {
>> target = <&am33xx_pinmux>;
>> __overlay__ {
>> pinctrl_test: pinctrl_test_7_pins {
>> pinctrl-single,pins = <
>> 0x040 0x27  // P9_15 PINS$16 GPIO1_16 = 48 Input
>> Mode7 pullup
>> >;
>> };
>> };
>> };
>>
>> Compiled, copied, and then loaded the dtbo file. Then . . .
>>
>> $ dmesg |grep pinctrl-test

Re: [beagleboard] Debian Overlay / Pinmux not working?

[William Hermans]

That still does not explain how 0x40 == 0x880 in
/sys/kernel/debug/pinctrl/44e10800.pinmux/pins. It should be 840 . . . or
44e10840 if you prefer.

On Fri, Nov 27, 2015 at 11:24 PM, John Syne  wrote:

> P9 HEADER LINUX PIN ADDR/OFFSET TRM NAME GPIO NO. P9_15A 16 0x840/040
> GPIO1_16 48 P9_15B 34 0x888/088 GPIO1_16 64
>
> Regards,
> John
>
>
>
>
> On Nov 27, 2015, at 10:18 PM, John Syne  wrote:
>
> P9_15A 16 0x840/040 GPIO1_16 48 P9_15B 34 0x888/088 GPIO1_16 64
>
> Regards,
> John
>
>
>
>
> On Nov 27, 2015, at 10:10 PM, William Hermans  wrote:
>
> Or, more correctly I suppose . . .
>
> Pin value = 32 * GPIO bank + pin number.
>
> Where. . .
>
> GPIO Bank == 0-3
> Pin number == 0-31
>
> On Fri, Nov 27, 2015 at 11:07 PM, William Hermans 
> wrote:
>
>> *BTW, 840 is connected to 888, so that pin might not be the best pin to
>>> test. Either way, I don’t understand why the Overlay manager doesn’t
>>> complain about a pin conflict. *
>>>
>>
>> Ok you're going to have to explain that. Since the pin I checked changed.
>> And I've always understood that . . . 32*+=pin
>> value
>>
>> On Fri, Nov 27, 2015 at 11:03 PM, John Syne  wrote:
>>
>>> Hi William,
>>>
>>> I think you are right, there must be some sort of conflict on Riley’s
>>> system. BTW, 840 is connected to 888, so that pin might not be the best pin
>>> to test. Either way, I don’t understand why the Overlay manager doesn’t
>>> complain about a pin conflict.
>>>
>>> Regards,
>>> John
>>>
>>>
>>>
>>>
>>> On Nov 27, 2015, at 9:55 PM, William Hermans  wrote:
>>>
>>> OK so I thought maybe I forgot to copy the newly compiled overlay over .
>>> . .
>>>
>>> $ ls |grep pin
>>> pinctrl-test-7-00A0.dtbo
>>> pinctrl-test-7.dts
>>>
>>> $ rm pin*
>>> $ ls |grep pin
>>> < No output >
>>>
>>> $ cp /lib/firmware/pinctrl-test-7-00A0.dtbo .
>>> $ dtc -I dtb -O dts pinctrl-test-7-00A0.dtbo > pinctrl-test-7-00A0.dts
>>>
>>> /dts-v1/;
>>>
>>> / {
>>> compatible = "ti,beaglebone", "ti,beaglebone-black";
>>> part-number = "pinctrl-test-7";
>>>
>>> fragment@0 {
>>> target = <0xdeadbeef>;
>>>
>>> __overlay__ {
>>>
>>> pinctrl_test_7_pins {
>>> pinctrl-single,pins = <0x40 0x27>;
>>> linux,phandle = <0x1>;
>>> phandle = <0x1>;
>>> };
>>> };
>>> };
>>>
>>> fragment@1 {
>>> target = <0xdeadbeef>;
>>>
>>> __overlay__ {
>>>
>>> helper {
>>> compatible = "gpio-of-helper";
>>> pinctrl-names = "default";
>>> pinctrl-0 = <0x1>;
>>> status = "okay";
>>> linux,phandle = <0x2>;
>>> phandle = <0x2>;
>>> };
>>> };
>>> };
>>>
>>> __symbols__ {
>>> pinctrl_test = "/fragment@0/__overlay__/pinctrl_test_7_pins";
>>> test_helper = "/fragment@1/__overlay__/helper";
>>> };
>>>
>>> __local_fixups__ {
>>>
>>> fragment@1 {
>>>
>>> __overlay__ {
>>>
>>> helper {
>>> pinctrl-0 = <0x0>;
>>> };
>>> };
>>> };
>>> };
>>>
>>> __fixups__ {
>>> am33xx_pinmux = "/fragment@0:target:0";
>>> ocp = "/fragment@1:target:0";
>>> };
>>> };
>>>
>>> Ok, so this source mangling seems odd, but just looking things over, it
>>> seems like it should work. Next, reboot, and reload, then see what happens.
>>>
>>> On Fri, Nov 27, 2015 at 10:40 PM, William Hermans 
>>> wrote:
>>>
 Smells of a bug. But perhaps the GPIO pinmux's need to be explicity
 cleared as I mentioned above ?

 On Fri, Nov 27, 2015 at 10:39 PM, William Hermans 
 wrote:

> OK so I changed to this:
>
> fragment@0 {
> target = <&am33xx_pinmux>;
> __overlay__ {
> pinctrl_test: pinctrl_test_7_pins {
> pinctrl-single,pins = <
> 0x040 0x27  // P9_15 PINS$16 GPIO1_16 = 48 Input
> Mode7 pullup
> >;
> };
> };
> };
>
> Compiled, copied, and then loaded the dtbo file. Then . . .
>
> $ dmesg |grep pinctrl-test-7
> [168784.685978] bone_capemgr bone_capemgr: part_number
> 'pinctrl-test-7', version 'N/A'
> [168784.706649] bone_capemgr bone_capemgr: slot #4: 'Override Board
> Name,00A0,Override Manuf,pinctrl-test-7'
> [168784.723188] bone_capemgr bone_capemgr: slot #4: dtbo
> 'pinctrl-test-7-00A0.dtbo' loaded; overlay id #0
> [169658.533949] bone_capemgr bone_capemgr: part_number
> 'pinctrl-test-7', version 'N/A'
> [169658.554579] bone_capemgr bone_capemgr: slot #5: 'Override Board
> Name,00A0,Override Manuf,pinctrl-test-7'
> [169658.565013] bone_capemgr bone_capemgr: slot #5: dtbo
> 'pinctrl-test-7-00A0.dtbo' loaded; overlay id #1
>
> This shows that both device tree overlays have been sucessfully
> loaded. Despite the fact tha

Re: [beagleboard] Debian Overlay / Pinmux not working?

[John Syne]

Yeah, you are right, but he also tested on 870, which doesn’t have this 
conflict. I’m just trying to avoid any other problems that might influence this 
issue. 

Regards,
John




> On Nov 27, 2015, at 10:22 PM, William Hermans  wrote:
> 
> As per Riley's overlay source, I only copy pasted it. But changed the pinmux 
> from 0x17, to 0x27 as a test.
> 
> 0x040 0x27  // P9_15 PINS$16 GPIO1_16 = 48 Input Mode7 pullup
> 
> On Fri, Nov 27, 2015 at 11:18 PM, John Syne  > wrote:
> P9_15A16  0x840/040   GPIO1_1648
> P9_15B34  0x888/088   GPIO1_1664
> 
> Regards,
> John
> 
> 
> 
> 
>> On Nov 27, 2015, at 10:10 PM, William Hermans > > wrote:
>> 
>> Or, more correctly I suppose . . .
>> 
>> Pin value = 32 * GPIO bank + pin number.
>> 
>> Where. . .
>> 
>> GPIO Bank == 0-3
>> Pin number == 0-31
>> 
>> On Fri, Nov 27, 2015 at 11:07 PM, William Hermans > > wrote:
>> BTW, 840 is connected to 888, so that pin might not be the best pin to test. 
>> Either way, I don’t understand why the Overlay manager doesn’t complain 
>> about a pin conflict. 
>> 
>> Ok you're going to have to explain that. Since the pin I checked changed. 
>> And I've always understood that . . . 32*+=pin 
>> value
>> 
>> On Fri, Nov 27, 2015 at 11:03 PM, John Syne > > wrote:
>> Hi William,
>> 
>> I think you are right, there must be some sort of conflict on Riley’s 
>> system. BTW, 840 is connected to 888, so that pin might not be the best pin 
>> to test. Either way, I don’t understand why the Overlay manager doesn’t 
>> complain about a pin conflict. 
>> 
>> Regards,
>> John
>> 
>> 
>> 
>> 
>>> On Nov 27, 2015, at 9:55 PM, William Hermans >> > wrote:
>>> 
>>> OK so I thought maybe I forgot to copy the newly compiled overlay over . . .
>>> 
>>> $ ls |grep pin
>>> pinctrl-test-7-00A0.dtbo
>>> pinctrl-test-7.dts
>>> 
>>> $ rm pin*
>>> $ ls |grep pin
>>> < No output >
>>> 
>>> $ cp /lib/firmware/pinctrl-test-7-00A0.dtbo .
>>> $ dtc -I dtb -O dts pinctrl-test-7-00A0.dtbo > pinctrl-test-7-00A0.dts
>>> 
>>> /dts-v1/;
>>> 
>>> / {
>>> compatible = "ti,beaglebone", "ti,beaglebone-black";
>>> part-number = "pinctrl-test-7";
>>> 
>>> fragment@0 {
>>> target = <0xdeadbeef>;
>>> 
>>> __overlay__ {
>>> 
>>> pinctrl_test_7_pins {
>>> pinctrl-single,pins = <0x40 0x27>;
>>> linux,phandle = <0x1>;
>>> phandle = <0x1>;
>>> };
>>> };
>>> };
>>> 
>>> fragment@1 {
>>> target = <0xdeadbeef>;
>>> 
>>> __overlay__ {
>>> 
>>> helper {
>>> compatible = "gpio-of-helper";
>>> pinctrl-names = "default";
>>> pinctrl-0 = <0x1>;
>>> status = "okay";
>>> linux,phandle = <0x2>;
>>> phandle = <0x2>;
>>> };
>>> };
>>> };
>>> 
>>> __symbols__ {
>>> pinctrl_test = "/fragment@0/__overlay__/pinctrl_test_7_pins";
>>> test_helper = "/fragment@1/__overlay__/helper";
>>> };
>>> 
>>> __local_fixups__ {
>>> 
>>> fragment@1 {
>>> 
>>> __overlay__ {
>>> 
>>> helper {
>>> pinctrl-0 = <0x0>;
>>> };
>>> };
>>> };
>>> };
>>> 
>>> __fixups__ {
>>> am33xx_pinmux = "/fragment@0:target:0";
>>> ocp = "/fragment@1:target:0";
>>> };
>>> };
>>> 
>>> Ok, so this source mangling seems odd, but just looking things over, it 
>>> seems like it should work. Next, reboot, and reload, then see what happens.
>>> 
>>> On Fri, Nov 27, 2015 at 10:40 PM, William Hermans >> > wrote:
>>> Smells of a bug. But perhaps the GPIO pinmux's need to be explicity cleared 
>>> as I mentioned above ?
>>> 
>>> On Fri, Nov 27, 2015 at 10:39 PM, William Hermans >> > wrote:
>>> OK so I changed to this:
>>> 
>>> fragment@0 {
>>> target = <&am33xx_pinmux>;
>>> __overlay__ {
>>> pinctrl_test: pinctrl_test_7_pins {
>>> pinctrl-single,pins = <
>>> 0x040 0x27  // P9_15 PINS$16 GPIO1_16 = 48 Input Mode7 
>>> pullup
>>> >;
>>> };
>>> };
>>> };
>>> 
>>> Compiled, copied, and then loaded the dtbo file. Then . . .
>>> 
>>> $ dmesg |grep pinctrl-test-7
>>> [168784.685978] bone_capemgr bone_capemgr: part_number 'pinctrl-test-7', 
>>> version 'N/A'
>>> [168784.706649] bone_capemgr bone_capemgr: slot #4: 'Override Board 
>>> Name,00A0,Override Manuf,pinctrl-test-7'
>>> [168784.723188] bone_capemgr bone_capemgr: slot #4: dtbo 
>>> 'pinctrl-test-7-00A0.dtbo' loaded; overlay id #0
>>> [169658.533949] bone_capemgr bone_capemgr: part_number 'pinctrl-test-7', 
>>> version 'N/A'
>>> [169658.554579] bone_capemgr

Re: [beagleboard] Debian Overlay / Pinmux not working?

[John Syne]

P9 HEADER   LINUX PIN   ADDR/OFFSET TRM NAMEGPIO NO.
P9_15A  16  0x840/040   GPIO1_1648
P9_15B  34  0x888/088   GPIO1_1664

Regards,
John




> On Nov 27, 2015, at 10:18 PM, John Syne  wrote:
> 
> P9_15A16  0x840/040   GPIO1_1648
> P9_15B34  0x888/088   GPIO1_1664
> 
> Regards,
> John
> 
> 
> 
> 
>> On Nov 27, 2015, at 10:10 PM, William Hermans > > wrote:
>> 
>> Or, more correctly I suppose . . .
>> 
>> Pin value = 32 * GPIO bank + pin number.
>> 
>> Where. . .
>> 
>> GPIO Bank == 0-3
>> Pin number == 0-31
>> 
>> On Fri, Nov 27, 2015 at 11:07 PM, William Hermans > > wrote:
>> BTW, 840 is connected to 888, so that pin might not be the best pin to test. 
>> Either way, I don’t understand why the Overlay manager doesn’t complain 
>> about a pin conflict. 
>> 
>> Ok you're going to have to explain that. Since the pin I checked changed. 
>> And I've always understood that . . . 32*+=pin 
>> value
>> 
>> On Fri, Nov 27, 2015 at 11:03 PM, John Syne > > wrote:
>> Hi William,
>> 
>> I think you are right, there must be some sort of conflict on Riley’s 
>> system. BTW, 840 is connected to 888, so that pin might not be the best pin 
>> to test. Either way, I don’t understand why the Overlay manager doesn’t 
>> complain about a pin conflict. 
>> 
>> Regards,
>> John
>> 
>> 
>> 
>> 
>>> On Nov 27, 2015, at 9:55 PM, William Hermans >> > wrote:
>>> 
>>> OK so I thought maybe I forgot to copy the newly compiled overlay over . . .
>>> 
>>> $ ls |grep pin
>>> pinctrl-test-7-00A0.dtbo
>>> pinctrl-test-7.dts
>>> 
>>> $ rm pin*
>>> $ ls |grep pin
>>> < No output >
>>> 
>>> $ cp /lib/firmware/pinctrl-test-7-00A0.dtbo .
>>> $ dtc -I dtb -O dts pinctrl-test-7-00A0.dtbo > pinctrl-test-7-00A0.dts
>>> 
>>> /dts-v1/;
>>> 
>>> / {
>>> compatible = "ti,beaglebone", "ti,beaglebone-black";
>>> part-number = "pinctrl-test-7";
>>> 
>>> fragment@0 {
>>> target = <0xdeadbeef>;
>>> 
>>> __overlay__ {
>>> 
>>> pinctrl_test_7_pins {
>>> pinctrl-single,pins = <0x40 0x27>;
>>> linux,phandle = <0x1>;
>>> phandle = <0x1>;
>>> };
>>> };
>>> };
>>> 
>>> fragment@1 {
>>> target = <0xdeadbeef>;
>>> 
>>> __overlay__ {
>>> 
>>> helper {
>>> compatible = "gpio-of-helper";
>>> pinctrl-names = "default";
>>> pinctrl-0 = <0x1>;
>>> status = "okay";
>>> linux,phandle = <0x2>;
>>> phandle = <0x2>;
>>> };
>>> };
>>> };
>>> 
>>> __symbols__ {
>>> pinctrl_test = "/fragment@0/__overlay__/pinctrl_test_7_pins";
>>> test_helper = "/fragment@1/__overlay__/helper";
>>> };
>>> 
>>> __local_fixups__ {
>>> 
>>> fragment@1 {
>>> 
>>> __overlay__ {
>>> 
>>> helper {
>>> pinctrl-0 = <0x0>;
>>> };
>>> };
>>> };
>>> };
>>> 
>>> __fixups__ {
>>> am33xx_pinmux = "/fragment@0:target:0";
>>> ocp = "/fragment@1:target:0";
>>> };
>>> };
>>> 
>>> Ok, so this source mangling seems odd, but just looking things over, it 
>>> seems like it should work. Next, reboot, and reload, then see what happens.
>>> 
>>> On Fri, Nov 27, 2015 at 10:40 PM, William Hermans >> > wrote:
>>> Smells of a bug. But perhaps the GPIO pinmux's need to be explicity cleared 
>>> as I mentioned above ?
>>> 
>>> On Fri, Nov 27, 2015 at 10:39 PM, William Hermans >> > wrote:
>>> OK so I changed to this:
>>> 
>>> fragment@0 {
>>> target = <&am33xx_pinmux>;
>>> __overlay__ {
>>> pinctrl_test: pinctrl_test_7_pins {
>>> pinctrl-single,pins = <
>>> 0x040 0x27  // P9_15 PINS$16 GPIO1_16 = 48 Input Mode7 
>>> pullup
>>> >;
>>> };
>>> };
>>> };
>>> 
>>> Compiled, copied, and then loaded the dtbo file. Then . . .
>>> 
>>> $ dmesg |grep pinctrl-test-7
>>> [168784.685978] bone_capemgr bone_capemgr: part_number 'pinctrl-test-7', 
>>> version 'N/A'
>>> [168784.706649] bone_capemgr bone_capemgr: slot #4: 'Override Board 
>>> Name,00A0,Override Manuf,pinctrl-test-7'
>>> [168784.723188] bone_capemgr bone_capemgr: slot #4: dtbo 
>>> 'pinctrl-test-7-00A0.dtbo' loaded; overlay id #0
>>> [169658.533949] bone_capemgr bone_capemgr: part_number 'pinctrl-test-7', 
>>> version 'N/A'
>>> [169658.554579] bone_capemgr bone_capemgr: slot #5: 'Override Board 
>>> Name,00A0,Override Manuf,pinctrl-test-7'
>>> [169658.565013] bone_capemgr bone_capemgr: slot #5: dtbo 
>>> 'pinctrl-test-7-00A0.dtbo' loaded; overlay id #1
>>> 
>>> This shows that both device tree overlays have b

Re: [beagleboard] Debian Overlay / Pinmux not working?

[William Hermans]

As per Riley's overlay source, I only copy pasted it. But changed the
pinmux from 0x17, to 0x27 as a test.

0x040 0x27  // P9_15 PINS$16 GPIO1_16 = 48 Input Mode7 pullup

On Fri, Nov 27, 2015 at 11:18 PM, John Syne  wrote:

> P9_15A 16 0x840/040 GPIO1_16 48 P9_15B 34 0x888/088 GPIO1_16 64
>
> Regards,
> John
>
>
>
>
> On Nov 27, 2015, at 10:10 PM, William Hermans  wrote:
>
> Or, more correctly I suppose . . .
>
> Pin value = 32 * GPIO bank + pin number.
>
> Where. . .
>
> GPIO Bank == 0-3
> Pin number == 0-31
>
> On Fri, Nov 27, 2015 at 11:07 PM, William Hermans 
> wrote:
>
>> *BTW, 840 is connected to 888, so that pin might not be the best pin to
>>> test. Either way, I don’t understand why the Overlay manager doesn’t
>>> complain about a pin conflict. *
>>>
>>
>> Ok you're going to have to explain that. Since the pin I checked changed.
>> And I've always understood that . . . 32*+=pin
>> value
>>
>> On Fri, Nov 27, 2015 at 11:03 PM, John Syne  wrote:
>>
>>> Hi William,
>>>
>>> I think you are right, there must be some sort of conflict on Riley’s
>>> system. BTW, 840 is connected to 888, so that pin might not be the best pin
>>> to test. Either way, I don’t understand why the Overlay manager doesn’t
>>> complain about a pin conflict.
>>>
>>> Regards,
>>> John
>>>
>>>
>>>
>>>
>>> On Nov 27, 2015, at 9:55 PM, William Hermans  wrote:
>>>
>>> OK so I thought maybe I forgot to copy the newly compiled overlay over .
>>> . .
>>>
>>> $ ls |grep pin
>>> pinctrl-test-7-00A0.dtbo
>>> pinctrl-test-7.dts
>>>
>>> $ rm pin*
>>> $ ls |grep pin
>>> < No output >
>>>
>>> $ cp /lib/firmware/pinctrl-test-7-00A0.dtbo .
>>> $ dtc -I dtb -O dts pinctrl-test-7-00A0.dtbo > pinctrl-test-7-00A0.dts
>>>
>>> /dts-v1/;
>>>
>>> / {
>>> compatible = "ti,beaglebone", "ti,beaglebone-black";
>>> part-number = "pinctrl-test-7";
>>>
>>> fragment@0 {
>>> target = <0xdeadbeef>;
>>>
>>> __overlay__ {
>>>
>>> pinctrl_test_7_pins {
>>> pinctrl-single,pins = <0x40 0x27>;
>>> linux,phandle = <0x1>;
>>> phandle = <0x1>;
>>> };
>>> };
>>> };
>>>
>>> fragment@1 {
>>> target = <0xdeadbeef>;
>>>
>>> __overlay__ {
>>>
>>> helper {
>>> compatible = "gpio-of-helper";
>>> pinctrl-names = "default";
>>> pinctrl-0 = <0x1>;
>>> status = "okay";
>>> linux,phandle = <0x2>;
>>> phandle = <0x2>;
>>> };
>>> };
>>> };
>>>
>>> __symbols__ {
>>> pinctrl_test = "/fragment@0/__overlay__/pinctrl_test_7_pins";
>>> test_helper = "/fragment@1/__overlay__/helper";
>>> };
>>>
>>> __local_fixups__ {
>>>
>>> fragment@1 {
>>>
>>> __overlay__ {
>>>
>>> helper {
>>> pinctrl-0 = <0x0>;
>>> };
>>> };
>>> };
>>> };
>>>
>>> __fixups__ {
>>> am33xx_pinmux = "/fragment@0:target:0";
>>> ocp = "/fragment@1:target:0";
>>> };
>>> };
>>>
>>> Ok, so this source mangling seems odd, but just looking things over, it
>>> seems like it should work. Next, reboot, and reload, then see what happens.
>>>
>>> On Fri, Nov 27, 2015 at 10:40 PM, William Hermans 
>>> wrote:
>>>
 Smells of a bug. But perhaps the GPIO pinmux's need to be explicity
 cleared as I mentioned above ?

 On Fri, Nov 27, 2015 at 10:39 PM, William Hermans 
 wrote:

> OK so I changed to this:
>
> fragment@0 {
> target = <&am33xx_pinmux>;
> __overlay__ {
> pinctrl_test: pinctrl_test_7_pins {
> pinctrl-single,pins = <
> 0x040 0x27  // P9_15 PINS$16 GPIO1_16 = 48 Input
> Mode7 pullup
> >;
> };
> };
> };
>
> Compiled, copied, and then loaded the dtbo file. Then . . .
>
> $ dmesg |grep pinctrl-test-7
> [168784.685978] bone_capemgr bone_capemgr: part_number
> 'pinctrl-test-7', version 'N/A'
> [168784.706649] bone_capemgr bone_capemgr: slot #4: 'Override Board
> Name,00A0,Override Manuf,pinctrl-test-7'
> [168784.723188] bone_capemgr bone_capemgr: slot #4: dtbo
> 'pinctrl-test-7-00A0.dtbo' loaded; overlay id #0
> [169658.533949] bone_capemgr bone_capemgr: part_number
> 'pinctrl-test-7', version 'N/A'
> [169658.554579] bone_capemgr bone_capemgr: slot #5: 'Override Board
> Name,00A0,Override Manuf,pinctrl-test-7'
> [169658.565013] bone_capemgr bone_capemgr: slot #5: dtbo
> 'pinctrl-test-7-00A0.dtbo' loaded; overlay id #1
>
> This shows that both device tree overlays have been sucessfully
> loaded. Despite the fact that the previously overwritten overlay was never
> unloaded. Then . . .
>
> $ sudo cat /sys/kernel/debug/pinctrl/44e10800.pinmux/pins |grep 840
> pin 16 (44e1084

Re: [beagleboard] Debian Overlay / Pinmux not working?

[William Hermans]

OK, so 0x27 is


   - mode 7
   - pullup/pulldown enabled
   - pulldown selected
   - reciever enabled /* meaning input I guess */


On Fri, Nov 27, 2015 at 11:10 PM, William Hermans  wrote:

> Or, more correctly I suppose . . .
>
> Pin value = 32 * GPIO bank + pin number.
>
> Where. . .
>
> GPIO Bank == 0-3
> Pin number == 0-31
>
> On Fri, Nov 27, 2015 at 11:07 PM, William Hermans 
> wrote:
>
>> *BTW, 840 is connected to 888, so that pin might not be the best pin to
>>> test. Either way, I don’t understand why the Overlay manager doesn’t
>>> complain about a pin conflict. *
>>>
>>
>> Ok you're going to have to explain that. Since the pin I checked changed.
>> And I've always understood that . . . 32*+=pin
>> value
>>
>> On Fri, Nov 27, 2015 at 11:03 PM, John Syne  wrote:
>>
>>> Hi William,
>>>
>>> I think you are right, there must be some sort of conflict on Riley’s
>>> system. BTW, 840 is connected to 888, so that pin might not be the best pin
>>> to test. Either way, I don’t understand why the Overlay manager doesn’t
>>> complain about a pin conflict.
>>>
>>> Regards,
>>> John
>>>
>>>
>>>
>>>
>>> On Nov 27, 2015, at 9:55 PM, William Hermans  wrote:
>>>
>>> OK so I thought maybe I forgot to copy the newly compiled overlay over .
>>> . .
>>>
>>> $ ls |grep pin
>>> pinctrl-test-7-00A0.dtbo
>>> pinctrl-test-7.dts
>>>
>>> $ rm pin*
>>> $ ls |grep pin
>>> < No output >
>>>
>>> $ cp /lib/firmware/pinctrl-test-7-00A0.dtbo .
>>> $ dtc -I dtb -O dts pinctrl-test-7-00A0.dtbo > pinctrl-test-7-00A0.dts
>>>
>>> /dts-v1/;
>>>
>>> / {
>>> compatible = "ti,beaglebone", "ti,beaglebone-black";
>>> part-number = "pinctrl-test-7";
>>>
>>> fragment@0 {
>>> target = <0xdeadbeef>;
>>>
>>> __overlay__ {
>>>
>>> pinctrl_test_7_pins {
>>> pinctrl-single,pins = <0x40 0x27>;
>>> linux,phandle = <0x1>;
>>> phandle = <0x1>;
>>> };
>>> };
>>> };
>>>
>>> fragment@1 {
>>> target = <0xdeadbeef>;
>>>
>>> __overlay__ {
>>>
>>> helper {
>>> compatible = "gpio-of-helper";
>>> pinctrl-names = "default";
>>> pinctrl-0 = <0x1>;
>>> status = "okay";
>>> linux,phandle = <0x2>;
>>> phandle = <0x2>;
>>> };
>>> };
>>> };
>>>
>>> __symbols__ {
>>> pinctrl_test = "/fragment@0/__overlay__/pinctrl_test_7_pins";
>>> test_helper = "/fragment@1/__overlay__/helper";
>>> };
>>>
>>> __local_fixups__ {
>>>
>>> fragment@1 {
>>>
>>> __overlay__ {
>>>
>>> helper {
>>> pinctrl-0 = <0x0>;
>>> };
>>> };
>>> };
>>> };
>>>
>>> __fixups__ {
>>> am33xx_pinmux = "/fragment@0:target:0";
>>> ocp = "/fragment@1:target:0";
>>> };
>>> };
>>>
>>> Ok, so this source mangling seems odd, but just looking things over, it
>>> seems like it should work. Next, reboot, and reload, then see what happens.
>>>
>>> On Fri, Nov 27, 2015 at 10:40 PM, William Hermans 
>>> wrote:
>>>
 Smells of a bug. But perhaps the GPIO pinmux's need to be explicity
 cleared as I mentioned above ?

 On Fri, Nov 27, 2015 at 10:39 PM, William Hermans 
 wrote:

> OK so I changed to this:
>
> fragment@0 {
> target = <&am33xx_pinmux>;
> __overlay__ {
> pinctrl_test: pinctrl_test_7_pins {
> pinctrl-single,pins = <
> 0x040 0x27  // P9_15 PINS$16 GPIO1_16 = 48 Input
> Mode7 pullup
> >;
> };
> };
> };
>
> Compiled, copied, and then loaded the dtbo file. Then . . .
>
> $ dmesg |grep pinctrl-test-7
> [168784.685978] bone_capemgr bone_capemgr: part_number
> 'pinctrl-test-7', version 'N/A'
> [168784.706649] bone_capemgr bone_capemgr: slot #4: 'Override Board
> Name,00A0,Override Manuf,pinctrl-test-7'
> [168784.723188] bone_capemgr bone_capemgr: slot #4: dtbo
> 'pinctrl-test-7-00A0.dtbo' loaded; overlay id #0
> [169658.533949] bone_capemgr bone_capemgr: part_number
> 'pinctrl-test-7', version 'N/A'
> [169658.554579] bone_capemgr bone_capemgr: slot #5: 'Override Board
> Name,00A0,Override Manuf,pinctrl-test-7'
> [169658.565013] bone_capemgr bone_capemgr: slot #5: dtbo
> 'pinctrl-test-7-00A0.dtbo' loaded; overlay id #1
>
> This shows that both device tree overlays have been sucessfully
> loaded. Despite the fact that the previously overwritten overlay was never
> unloaded. Then . . .
>
> $ sudo cat /sys/kernel/debug/pinctrl/44e10800.pinmux/pins |grep 840
> pin 16 (44e10840.0) 0017 pinctrl-single
>
> So . . .
> i$ cat /sys/devices/platform/bone_capemgr/slots
>  0: PF  -1
>  1: PF  -1
>  2: PF  -1
>  3: PF 

Re: [beagleboard] Debian Overlay / Pinmux not working?

[John Syne]

P9_15A  16  0x840/040   GPIO1_1648
P9_15B  34  0x888/088   GPIO1_1664

Regards,
John




> On Nov 27, 2015, at 10:10 PM, William Hermans  wrote:
> 
> Or, more correctly I suppose . . .
> 
> Pin value = 32 * GPIO bank + pin number.
> 
> Where. . .
> 
> GPIO Bank == 0-3
> Pin number == 0-31
> 
> On Fri, Nov 27, 2015 at 11:07 PM, William Hermans  > wrote:
> BTW, 840 is connected to 888, so that pin might not be the best pin to test. 
> Either way, I don’t understand why the Overlay manager doesn’t complain about 
> a pin conflict. 
> 
> Ok you're going to have to explain that. Since the pin I checked changed. And 
> I've always understood that . . . 32*+=pin value
> 
> On Fri, Nov 27, 2015 at 11:03 PM, John Syne  > wrote:
> Hi William,
> 
> I think you are right, there must be some sort of conflict on Riley’s system. 
> BTW, 840 is connected to 888, so that pin might not be the best pin to test. 
> Either way, I don’t understand why the Overlay manager doesn’t complain about 
> a pin conflict. 
> 
> Regards,
> John
> 
> 
> 
> 
>> On Nov 27, 2015, at 9:55 PM, William Hermans > > wrote:
>> 
>> OK so I thought maybe I forgot to copy the newly compiled overlay over . . .
>> 
>> $ ls |grep pin
>> pinctrl-test-7-00A0.dtbo
>> pinctrl-test-7.dts
>> 
>> $ rm pin*
>> $ ls |grep pin
>> < No output >
>> 
>> $ cp /lib/firmware/pinctrl-test-7-00A0.dtbo .
>> $ dtc -I dtb -O dts pinctrl-test-7-00A0.dtbo > pinctrl-test-7-00A0.dts
>> 
>> /dts-v1/;
>> 
>> / {
>> compatible = "ti,beaglebone", "ti,beaglebone-black";
>> part-number = "pinctrl-test-7";
>> 
>> fragment@0 {
>> target = <0xdeadbeef>;
>> 
>> __overlay__ {
>> 
>> pinctrl_test_7_pins {
>> pinctrl-single,pins = <0x40 0x27>;
>> linux,phandle = <0x1>;
>> phandle = <0x1>;
>> };
>> };
>> };
>> 
>> fragment@1 {
>> target = <0xdeadbeef>;
>> 
>> __overlay__ {
>> 
>> helper {
>> compatible = "gpio-of-helper";
>> pinctrl-names = "default";
>> pinctrl-0 = <0x1>;
>> status = "okay";
>> linux,phandle = <0x2>;
>> phandle = <0x2>;
>> };
>> };
>> };
>> 
>> __symbols__ {
>> pinctrl_test = "/fragment@0/__overlay__/pinctrl_test_7_pins";
>> test_helper = "/fragment@1/__overlay__/helper";
>> };
>> 
>> __local_fixups__ {
>> 
>> fragment@1 {
>> 
>> __overlay__ {
>> 
>> helper {
>> pinctrl-0 = <0x0>;
>> };
>> };
>> };
>> };
>> 
>> __fixups__ {
>> am33xx_pinmux = "/fragment@0:target:0";
>> ocp = "/fragment@1:target:0";
>> };
>> };
>> 
>> Ok, so this source mangling seems odd, but just looking things over, it 
>> seems like it should work. Next, reboot, and reload, then see what happens.
>> 
>> On Fri, Nov 27, 2015 at 10:40 PM, William Hermans > > wrote:
>> Smells of a bug. But perhaps the GPIO pinmux's need to be explicity cleared 
>> as I mentioned above ?
>> 
>> On Fri, Nov 27, 2015 at 10:39 PM, William Hermans > > wrote:
>> OK so I changed to this:
>> 
>> fragment@0 {
>> target = <&am33xx_pinmux>;
>> __overlay__ {
>> pinctrl_test: pinctrl_test_7_pins {
>> pinctrl-single,pins = <
>> 0x040 0x27  // P9_15 PINS$16 GPIO1_16 = 48 Input Mode7 
>> pullup
>> >;
>> };
>> };
>> };
>> 
>> Compiled, copied, and then loaded the dtbo file. Then . . .
>> 
>> $ dmesg |grep pinctrl-test-7
>> [168784.685978] bone_capemgr bone_capemgr: part_number 'pinctrl-test-7', 
>> version 'N/A'
>> [168784.706649] bone_capemgr bone_capemgr: slot #4: 'Override Board 
>> Name,00A0,Override Manuf,pinctrl-test-7'
>> [168784.723188] bone_capemgr bone_capemgr: slot #4: dtbo 
>> 'pinctrl-test-7-00A0.dtbo' loaded; overlay id #0
>> [169658.533949] bone_capemgr bone_capemgr: part_number 'pinctrl-test-7', 
>> version 'N/A'
>> [169658.554579] bone_capemgr bone_capemgr: slot #5: 'Override Board 
>> Name,00A0,Override Manuf,pinctrl-test-7'
>> [169658.565013] bone_capemgr bone_capemgr: slot #5: dtbo 
>> 'pinctrl-test-7-00A0.dtbo' loaded; overlay id #1
>> 
>> This shows that both device tree overlays have been sucessfully loaded. 
>> Despite the fact that the previously overwritten overlay was never unloaded. 
>> Then . . .
>> 
>> $ sudo cat /sys/kernel/debug/pinctrl/44e10800.pinmux/pins |grep 840
>> pin 16 (44e10840.0) 0017 pinctrl-single
>> 
>> So . . .
>> i$ cat /sys/devices/platform/bone_capemgr/slots
>>  0: PF  -1
>>  1: PF  -1
>>  2: PF  -1
>>  3: PF  -1
>>  4: P-O-L-   0 Override Board Name,00A0,Override Manuf,pinctrl-test-7
>>  5: 

Re: [beagleboard] Debian Overlay / Pinmux not working?

[William Hermans]

Or, more correctly I suppose . . .

Pin value = 32 * GPIO bank + pin number.

Where. . .

GPIO Bank == 0-3
Pin number == 0-31

On Fri, Nov 27, 2015 at 11:07 PM, William Hermans  wrote:

> *BTW, 840 is connected to 888, so that pin might not be the best pin to
>> test. Either way, I don’t understand why the Overlay manager doesn’t
>> complain about a pin conflict. *
>>
>
> Ok you're going to have to explain that. Since the pin I checked changed.
> And I've always understood that . . . 32*+=pin
> value
>
> On Fri, Nov 27, 2015 at 11:03 PM, John Syne  wrote:
>
>> Hi William,
>>
>> I think you are right, there must be some sort of conflict on Riley’s
>> system. BTW, 840 is connected to 888, so that pin might not be the best pin
>> to test. Either way, I don’t understand why the Overlay manager doesn’t
>> complain about a pin conflict.
>>
>> Regards,
>> John
>>
>>
>>
>>
>> On Nov 27, 2015, at 9:55 PM, William Hermans  wrote:
>>
>> OK so I thought maybe I forgot to copy the newly compiled overlay over .
>> . .
>>
>> $ ls |grep pin
>> pinctrl-test-7-00A0.dtbo
>> pinctrl-test-7.dts
>>
>> $ rm pin*
>> $ ls |grep pin
>> < No output >
>>
>> $ cp /lib/firmware/pinctrl-test-7-00A0.dtbo .
>> $ dtc -I dtb -O dts pinctrl-test-7-00A0.dtbo > pinctrl-test-7-00A0.dts
>>
>> /dts-v1/;
>>
>> / {
>> compatible = "ti,beaglebone", "ti,beaglebone-black";
>> part-number = "pinctrl-test-7";
>>
>> fragment@0 {
>> target = <0xdeadbeef>;
>>
>> __overlay__ {
>>
>> pinctrl_test_7_pins {
>> pinctrl-single,pins = <0x40 0x27>;
>> linux,phandle = <0x1>;
>> phandle = <0x1>;
>> };
>> };
>> };
>>
>> fragment@1 {
>> target = <0xdeadbeef>;
>>
>> __overlay__ {
>>
>> helper {
>> compatible = "gpio-of-helper";
>> pinctrl-names = "default";
>> pinctrl-0 = <0x1>;
>> status = "okay";
>> linux,phandle = <0x2>;
>> phandle = <0x2>;
>> };
>> };
>> };
>>
>> __symbols__ {
>> pinctrl_test = "/fragment@0/__overlay__/pinctrl_test_7_pins";
>> test_helper = "/fragment@1/__overlay__/helper";
>> };
>>
>> __local_fixups__ {
>>
>> fragment@1 {
>>
>> __overlay__ {
>>
>> helper {
>> pinctrl-0 = <0x0>;
>> };
>> };
>> };
>> };
>>
>> __fixups__ {
>> am33xx_pinmux = "/fragment@0:target:0";
>> ocp = "/fragment@1:target:0";
>> };
>> };
>>
>> Ok, so this source mangling seems odd, but just looking things over, it
>> seems like it should work. Next, reboot, and reload, then see what happens.
>>
>> On Fri, Nov 27, 2015 at 10:40 PM, William Hermans 
>> wrote:
>>
>>> Smells of a bug. But perhaps the GPIO pinmux's need to be explicity
>>> cleared as I mentioned above ?
>>>
>>> On Fri, Nov 27, 2015 at 10:39 PM, William Hermans 
>>> wrote:
>>>
 OK so I changed to this:

 fragment@0 {
 target = <&am33xx_pinmux>;
 __overlay__ {
 pinctrl_test: pinctrl_test_7_pins {
 pinctrl-single,pins = <
 0x040 0x27  // P9_15 PINS$16 GPIO1_16 = 48 Input
 Mode7 pullup
 >;
 };
 };
 };

 Compiled, copied, and then loaded the dtbo file. Then . . .

 $ dmesg |grep pinctrl-test-7
 [168784.685978] bone_capemgr bone_capemgr: part_number
 'pinctrl-test-7', version 'N/A'
 [168784.706649] bone_capemgr bone_capemgr: slot #4: 'Override Board
 Name,00A0,Override Manuf,pinctrl-test-7'
 [168784.723188] bone_capemgr bone_capemgr: slot #4: dtbo
 'pinctrl-test-7-00A0.dtbo' loaded; overlay id #0
 [169658.533949] bone_capemgr bone_capemgr: part_number
 'pinctrl-test-7', version 'N/A'
 [169658.554579] bone_capemgr bone_capemgr: slot #5: 'Override Board
 Name,00A0,Override Manuf,pinctrl-test-7'
 [169658.565013] bone_capemgr bone_capemgr: slot #5: dtbo
 'pinctrl-test-7-00A0.dtbo' loaded; overlay id #1

 This shows that both device tree overlays have been sucessfully loaded.
 Despite the fact that the previously overwritten overlay was never
 unloaded. Then . . .

 $ sudo cat /sys/kernel/debug/pinctrl/44e10800.pinmux/pins |grep 840
 pin 16 (44e10840.0) 0017 pinctrl-single

 So . . .
 i$ cat /sys/devices/platform/bone_capemgr/slots
  0: PF  -1
  1: PF  -1
  2: PF  -1
  3: PF  -1
  4: P-O-L-   0 Override Board Name,00A0,Override Manuf,pinctrl-test-7
  5: P-O-L-   1 Override Board Name,00A0,Override Manuf,pinctrl-test-7

 oops, two overlays loaded lets see wha thappens when first one is
 unloaded.

 $ sudo sh -c "echo '-4' > /sys/devices/platform/bone_capemgr/slots"
 $ cat /sys/devices/platform/bone_cape

Re: [beagleboard] Debian Overlay / Pinmux not working?

[William Hermans]

>
> *BTW, 840 is connected to 888, so that pin might not be the best pin to
> test. Either way, I don’t understand why the Overlay manager doesn’t
> complain about a pin conflict. *
>

Ok you're going to have to explain that. Since the pin I checked changed.
And I've always understood that . . . 32*+=pin
value

On Fri, Nov 27, 2015 at 11:03 PM, John Syne  wrote:

> Hi William,
>
> I think you are right, there must be some sort of conflict on Riley’s
> system. BTW, 840 is connected to 888, so that pin might not be the best pin
> to test. Either way, I don’t understand why the Overlay manager doesn’t
> complain about a pin conflict.
>
> Regards,
> John
>
>
>
>
> On Nov 27, 2015, at 9:55 PM, William Hermans  wrote:
>
> OK so I thought maybe I forgot to copy the newly compiled overlay over . .
> .
>
> $ ls |grep pin
> pinctrl-test-7-00A0.dtbo
> pinctrl-test-7.dts
>
> $ rm pin*
> $ ls |grep pin
> < No output >
>
> $ cp /lib/firmware/pinctrl-test-7-00A0.dtbo .
> $ dtc -I dtb -O dts pinctrl-test-7-00A0.dtbo > pinctrl-test-7-00A0.dts
>
> /dts-v1/;
>
> / {
> compatible = "ti,beaglebone", "ti,beaglebone-black";
> part-number = "pinctrl-test-7";
>
> fragment@0 {
> target = <0xdeadbeef>;
>
> __overlay__ {
>
> pinctrl_test_7_pins {
> pinctrl-single,pins = <0x40 0x27>;
> linux,phandle = <0x1>;
> phandle = <0x1>;
> };
> };
> };
>
> fragment@1 {
> target = <0xdeadbeef>;
>
> __overlay__ {
>
> helper {
> compatible = "gpio-of-helper";
> pinctrl-names = "default";
> pinctrl-0 = <0x1>;
> status = "okay";
> linux,phandle = <0x2>;
> phandle = <0x2>;
> };
> };
> };
>
> __symbols__ {
> pinctrl_test = "/fragment@0/__overlay__/pinctrl_test_7_pins";
> test_helper = "/fragment@1/__overlay__/helper";
> };
>
> __local_fixups__ {
>
> fragment@1 {
>
> __overlay__ {
>
> helper {
> pinctrl-0 = <0x0>;
> };
> };
> };
> };
>
> __fixups__ {
> am33xx_pinmux = "/fragment@0:target:0";
> ocp = "/fragment@1:target:0";
> };
> };
>
> Ok, so this source mangling seems odd, but just looking things over, it
> seems like it should work. Next, reboot, and reload, then see what happens.
>
> On Fri, Nov 27, 2015 at 10:40 PM, William Hermans 
> wrote:
>
>> Smells of a bug. But perhaps the GPIO pinmux's need to be explicity
>> cleared as I mentioned above ?
>>
>> On Fri, Nov 27, 2015 at 10:39 PM, William Hermans 
>> wrote:
>>
>>> OK so I changed to this:
>>>
>>> fragment@0 {
>>> target = <&am33xx_pinmux>;
>>> __overlay__ {
>>> pinctrl_test: pinctrl_test_7_pins {
>>> pinctrl-single,pins = <
>>> 0x040 0x27  // P9_15 PINS$16 GPIO1_16 = 48 Input
>>> Mode7 pullup
>>> >;
>>> };
>>> };
>>> };
>>>
>>> Compiled, copied, and then loaded the dtbo file. Then . . .
>>>
>>> $ dmesg |grep pinctrl-test-7
>>> [168784.685978] bone_capemgr bone_capemgr: part_number 'pinctrl-test-7',
>>> version 'N/A'
>>> [168784.706649] bone_capemgr bone_capemgr: slot #4: 'Override Board
>>> Name,00A0,Override Manuf,pinctrl-test-7'
>>> [168784.723188] bone_capemgr bone_capemgr: slot #4: dtbo
>>> 'pinctrl-test-7-00A0.dtbo' loaded; overlay id #0
>>> [169658.533949] bone_capemgr bone_capemgr: part_number 'pinctrl-test-7',
>>> version 'N/A'
>>> [169658.554579] bone_capemgr bone_capemgr: slot #5: 'Override Board
>>> Name,00A0,Override Manuf,pinctrl-test-7'
>>> [169658.565013] bone_capemgr bone_capemgr: slot #5: dtbo
>>> 'pinctrl-test-7-00A0.dtbo' loaded; overlay id #1
>>>
>>> This shows that both device tree overlays have been sucessfully loaded.
>>> Despite the fact that the previously overwritten overlay was never
>>> unloaded. Then . . .
>>>
>>> $ sudo cat /sys/kernel/debug/pinctrl/44e10800.pinmux/pins |grep 840
>>> pin 16 (44e10840.0) 0017 pinctrl-single
>>>
>>> So . . .
>>> i$ cat /sys/devices/platform/bone_capemgr/slots
>>>  0: PF  -1
>>>  1: PF  -1
>>>  2: PF  -1
>>>  3: PF  -1
>>>  4: P-O-L-   0 Override Board Name,00A0,Override Manuf,pinctrl-test-7
>>>  5: P-O-L-   1 Override Board Name,00A0,Override Manuf,pinctrl-test-7
>>>
>>> oops, two overlays loaded lets see wha thappens when first one is
>>> unloaded.
>>>
>>> $ sudo sh -c "echo '-4' > /sys/devices/platform/bone_capemgr/slots"
>>> $ cat /sys/devices/platform/bone_capemgr/slots
>>>  0: PF  -1
>>>  1: PF  -1
>>>  2: PF  -1
>>>  3: PF  -1
>>>  5: P-O-L-   1 Override Board Name,00A0,Override Manuf,pinctrl-test-7
>>> $ sudo cat /sys/kernel/debug/pinctrl/44e10800.pinmux/pins |grep 840
>>> pin 16 (44e10840.0) 0017 pinctrl-single
>>>
>>> Just as I thought, the original pinmux is persistent. So . . 

Re: [beagleboard] Debian Overlay / Pinmux not working?

[William Hermans]

$ sudo reboot

Broadcast message from root@beaglebone (pts/0) (Fri Nov 27 22:56:19 2015):
The system is going down for reboot NOW!

$ Agent has been released /* Ok wtf is this ?! Bluetooth agent ? */

login as: william
Debian GNU/Linux 7

BeagleBoard.org Debian Image 2015-03-01

Support/FAQ: http://elinux.org/Beagleboard:BeagleBoneBlack_Debian

default username:password is [debian:temppwd]

william@192.168.254.167's password:
Last login: Wed Nov 25 23:21:15 2015 from 

$ sudo cat /sys/kernel/debug/pinctrl/44e10800.pinmux/pins |grep 840
pin 16 (44e10840.0) 0027 pinctrl-single

WTF is going on here ? Anyhow seems like a bonafied bug ? Or is this the
default state in which pins come up as auto-magically ?

On Fri, Nov 27, 2015 at 10:55 PM, William Hermans  wrote:

> OK so I thought maybe I forgot to copy the newly compiled overlay over . .
> .
>
> $ ls |grep pin
> pinctrl-test-7-00A0.dtbo
> pinctrl-test-7.dts
>
> $ rm pin*
> $ ls |grep pin
> < No output >
>
> $ cp /lib/firmware/pinctrl-test-7-00A0.dtbo .
> $ dtc -I dtb -O dts pinctrl-test-7-00A0.dtbo > pinctrl-test-7-00A0.dts
>
> /dts-v1/;
>
> / {
> compatible = "ti,beaglebone", "ti,beaglebone-black";
> part-number = "pinctrl-test-7";
>
> fragment@0 {
> target = <0xdeadbeef>;
>
> __overlay__ {
>
> pinctrl_test_7_pins {
> pinctrl-single,pins = <0x40 0x27>;
> linux,phandle = <0x1>;
> phandle = <0x1>;
> };
> };
> };
>
> fragment@1 {
> target = <0xdeadbeef>;
>
> __overlay__ {
>
> helper {
> compatible = "gpio-of-helper";
> pinctrl-names = "default";
> pinctrl-0 = <0x1>;
> status = "okay";
> linux,phandle = <0x2>;
> phandle = <0x2>;
> };
> };
> };
>
> __symbols__ {
> pinctrl_test = "/fragment@0/__overlay__/pinctrl_test_7_pins";
> test_helper = "/fragment@1/__overlay__/helper";
> };
>
> __local_fixups__ {
>
> fragment@1 {
>
> __overlay__ {
>
> helper {
> pinctrl-0 = <0x0>;
> };
> };
> };
> };
>
> __fixups__ {
> am33xx_pinmux = "/fragment@0:target:0";
> ocp = "/fragment@1:target:0";
> };
> };
>
> Ok, so this source mangling seems odd, but just looking things over, it
> seems like it should work. Next, reboot, and reload, then see what happens.
>
> On Fri, Nov 27, 2015 at 10:40 PM, William Hermans 
> wrote:
>
>> Smells of a bug. But perhaps the GPIO pinmux's need to be explicity
>> cleared as I mentioned above ?
>>
>> On Fri, Nov 27, 2015 at 10:39 PM, William Hermans 
>> wrote:
>>
>>> OK so I changed to this:
>>>
>>> fragment@0 {
>>> target = <&am33xx_pinmux>;
>>> __overlay__ {
>>> pinctrl_test: pinctrl_test_7_pins {
>>> pinctrl-single,pins = <
>>> 0x040 0x27  // P9_15 PINS$16 GPIO1_16 = 48 Input
>>> Mode7 pullup
>>> >;
>>> };
>>> };
>>> };
>>>
>>> Compiled, copied, and then loaded the dtbo file. Then . . .
>>>
>>> $ dmesg |grep pinctrl-test-7
>>> [168784.685978] bone_capemgr bone_capemgr: part_number 'pinctrl-test-7',
>>> version 'N/A'
>>> [168784.706649] bone_capemgr bone_capemgr: slot #4: 'Override Board
>>> Name,00A0,Override Manuf,pinctrl-test-7'
>>> [168784.723188] bone_capemgr bone_capemgr: slot #4: dtbo
>>> 'pinctrl-test-7-00A0.dtbo' loaded; overlay id #0
>>> [169658.533949] bone_capemgr bone_capemgr: part_number 'pinctrl-test-7',
>>> version 'N/A'
>>> [169658.554579] bone_capemgr bone_capemgr: slot #5: 'Override Board
>>> Name,00A0,Override Manuf,pinctrl-test-7'
>>> [169658.565013] bone_capemgr bone_capemgr: slot #5: dtbo
>>> 'pinctrl-test-7-00A0.dtbo' loaded; overlay id #1
>>>
>>> This shows that both device tree overlays have been sucessfully loaded.
>>> Despite the fact that the previously overwritten overlay was never
>>> unloaded. Then . . .
>>>
>>> $ sudo cat /sys/kernel/debug/pinctrl/44e10800.pinmux/pins |grep 840
>>> pin 16 (44e10840.0) 0017 pinctrl-single
>>>
>>> So . . .
>>> i$ cat /sys/devices/platform/bone_capemgr/slots
>>>  0: PF  -1
>>>  1: PF  -1
>>>  2: PF  -1
>>>  3: PF  -1
>>>  4: P-O-L-   0 Override Board Name,00A0,Override Manuf,pinctrl-test-7
>>>  5: P-O-L-   1 Override Board Name,00A0,Override Manuf,pinctrl-test-7
>>>
>>> oops, two overlays loaded lets see wha thappens when first one is
>>> unloaded.
>>>
>>> $ sudo sh -c "echo '-4' > /sys/devices/platform/bone_capemgr/slots"
>>> $ cat /sys/devices/platform/bone_capemgr/slots
>>>  0: PF  -1
>>>  1: PF  -1
>>>  2: PF  -1
>>>  3: PF  -1
>>>  5: P-O-L-   1 Override Board Name,00A0,Override Manuf,pinctrl-test-7
>>> $ sudo cat /sys/kernel/debug/pinctrl/44e10800.pinmux/pins |grep 840
>>> pin 16 (44e10840.0) 0017 pinctrl-single
>>>
>>> Just as I

Re: [beagleboard] Debian Overlay / Pinmux not working?

[John Syne]

Hi William,

I think you are right, there must be some sort of conflict on Riley’s system. 
BTW, 840 is connected to 888, so that pin might not be the best pin to test. 
Either way, I don’t understand why the Overlay manager doesn’t complain about a 
pin conflict. 

Regards,
John




> On Nov 27, 2015, at 9:55 PM, William Hermans  wrote:
> 
> OK so I thought maybe I forgot to copy the newly compiled overlay over . . .
> 
> $ ls |grep pin
> pinctrl-test-7-00A0.dtbo
> pinctrl-test-7.dts
> 
> $ rm pin*
> $ ls |grep pin
> < No output >
> 
> $ cp /lib/firmware/pinctrl-test-7-00A0.dtbo .
> $ dtc -I dtb -O dts pinctrl-test-7-00A0.dtbo > pinctrl-test-7-00A0.dts
> 
> /dts-v1/;
> 
> / {
> compatible = "ti,beaglebone", "ti,beaglebone-black";
> part-number = "pinctrl-test-7";
> 
> fragment@0 {
> target = <0xdeadbeef>;
> 
> __overlay__ {
> 
> pinctrl_test_7_pins {
> pinctrl-single,pins = <0x40 0x27>;
> linux,phandle = <0x1>;
> phandle = <0x1>;
> };
> };
> };
> 
> fragment@1 {
> target = <0xdeadbeef>;
> 
> __overlay__ {
> 
> helper {
> compatible = "gpio-of-helper";
> pinctrl-names = "default";
> pinctrl-0 = <0x1>;
> status = "okay";
> linux,phandle = <0x2>;
> phandle = <0x2>;
> };
> };
> };
> 
> __symbols__ {
> pinctrl_test = "/fragment@0/__overlay__/pinctrl_test_7_pins";
> test_helper = "/fragment@1/__overlay__/helper";
> };
> 
> __local_fixups__ {
> 
> fragment@1 {
> 
> __overlay__ {
> 
> helper {
> pinctrl-0 = <0x0>;
> };
> };
> };
> };
> 
> __fixups__ {
> am33xx_pinmux = "/fragment@0:target:0";
> ocp = "/fragment@1:target:0";
> };
> };
> 
> Ok, so this source mangling seems odd, but just looking things over, it seems 
> like it should work. Next, reboot, and reload, then see what happens.
> 
> On Fri, Nov 27, 2015 at 10:40 PM, William Hermans  > wrote:
> Smells of a bug. But perhaps the GPIO pinmux's need to be explicity cleared 
> as I mentioned above ?
> 
> On Fri, Nov 27, 2015 at 10:39 PM, William Hermans  > wrote:
> OK so I changed to this:
> 
> fragment@0 {
> target = <&am33xx_pinmux>;
> __overlay__ {
> pinctrl_test: pinctrl_test_7_pins {
> pinctrl-single,pins = <
> 0x040 0x27  // P9_15 PINS$16 GPIO1_16 = 48 Input Mode7 
> pullup
> >;
> };
> };
> };
> 
> Compiled, copied, and then loaded the dtbo file. Then . . .
> 
> $ dmesg |grep pinctrl-test-7
> [168784.685978] bone_capemgr bone_capemgr: part_number 'pinctrl-test-7', 
> version 'N/A'
> [168784.706649] bone_capemgr bone_capemgr: slot #4: 'Override Board 
> Name,00A0,Override Manuf,pinctrl-test-7'
> [168784.723188] bone_capemgr bone_capemgr: slot #4: dtbo 
> 'pinctrl-test-7-00A0.dtbo' loaded; overlay id #0
> [169658.533949] bone_capemgr bone_capemgr: part_number 'pinctrl-test-7', 
> version 'N/A'
> [169658.554579] bone_capemgr bone_capemgr: slot #5: 'Override Board 
> Name,00A0,Override Manuf,pinctrl-test-7'
> [169658.565013] bone_capemgr bone_capemgr: slot #5: dtbo 
> 'pinctrl-test-7-00A0.dtbo' loaded; overlay id #1
> 
> This shows that both device tree overlays have been sucessfully loaded. 
> Despite the fact that the previously overwritten overlay was never unloaded. 
> Then . . .
> 
> $ sudo cat /sys/kernel/debug/pinctrl/44e10800.pinmux/pins |grep 840
> pin 16 (44e10840.0) 0017 pinctrl-single
> 
> So . . .
> i$ cat /sys/devices/platform/bone_capemgr/slots
>  0: PF  -1
>  1: PF  -1
>  2: PF  -1
>  3: PF  -1
>  4: P-O-L-   0 Override Board Name,00A0,Override Manuf,pinctrl-test-7
>  5: P-O-L-   1 Override Board Name,00A0,Override Manuf,pinctrl-test-7
> 
> oops, two overlays loaded lets see wha thappens when first one is unloaded.
> 
> $ sudo sh -c "echo '-4' > /sys/devices/platform/bone_capemgr/slots"
> $ cat /sys/devices/platform/bone_capemgr/slots
>  0: PF  -1
>  1: PF  -1
>  2: PF  -1
>  3: PF  -1
>  5: P-O-L-   1 Override Board Name,00A0,Override Manuf,pinctrl-test-7
> $ sudo cat /sys/kernel/debug/pinctrl/44e10800.pinmux/pins |grep 840
> pin 16 (44e10840.0) 0017 pinctrl-single
> 
> Just as I thought, the original pinmux is persistent. So . . .
> $ sudo sh -c "echo '-5' > /sys/devices/platform/bone_capemgr/slots"
> $ cat /sys/devices/platform/bone_capemgr/slots
>  0: PF  -1
>  1: PF  -1
>  2: PF  -1
>  3: PF  -1
> $ sudo cat /sys/kernel/debug/pinctrl/44e10800.pinmux/pins |grep 840
> pin 16 (44e10840.0) 0017 pinctrl-single
> 
> Ok just as I expected. pinmux's are kept until explicitly changed. Let's try 
> loading it again.
> $ sudo sh -c 

Re: [beagleboard] Debian Overlay / Pinmux not working?

[William Hermans]

OK so I thought maybe I forgot to copy the newly compiled overlay over . . .

$ ls |grep pin
pinctrl-test-7-00A0.dtbo
pinctrl-test-7.dts

$ rm pin*
$ ls |grep pin
< No output >

$ cp /lib/firmware/pinctrl-test-7-00A0.dtbo .
$ dtc -I dtb -O dts pinctrl-test-7-00A0.dtbo > pinctrl-test-7-00A0.dts

/dts-v1/;

/ {
compatible = "ti,beaglebone", "ti,beaglebone-black";
part-number = "pinctrl-test-7";

fragment@0 {
target = <0xdeadbeef>;

__overlay__ {

pinctrl_test_7_pins {
pinctrl-single,pins = <0x40 0x27>;
linux,phandle = <0x1>;
phandle = <0x1>;
};
};
};

fragment@1 {
target = <0xdeadbeef>;

__overlay__ {

helper {
compatible = "gpio-of-helper";
pinctrl-names = "default";
pinctrl-0 = <0x1>;
status = "okay";
linux,phandle = <0x2>;
phandle = <0x2>;
};
};
};

__symbols__ {
pinctrl_test = "/fragment@0/__overlay__/pinctrl_test_7_pins";
test_helper = "/fragment@1/__overlay__/helper";
};

__local_fixups__ {

fragment@1 {

__overlay__ {

helper {
pinctrl-0 = <0x0>;
};
};
};
};

__fixups__ {
am33xx_pinmux = "/fragment@0:target:0";
ocp = "/fragment@1:target:0";
};
};

Ok, so this source mangling seems odd, but just looking things over, it
seems like it should work. Next, reboot, and reload, then see what happens.

On Fri, Nov 27, 2015 at 10:40 PM, William Hermans  wrote:

> Smells of a bug. But perhaps the GPIO pinmux's need to be explicity
> cleared as I mentioned above ?
>
> On Fri, Nov 27, 2015 at 10:39 PM, William Hermans 
> wrote:
>
>> OK so I changed to this:
>>
>> fragment@0 {
>> target = <&am33xx_pinmux>;
>> __overlay__ {
>> pinctrl_test: pinctrl_test_7_pins {
>> pinctrl-single,pins = <
>> 0x040 0x27  // P9_15 PINS$16 GPIO1_16 = 48 Input
>> Mode7 pullup
>> >;
>> };
>> };
>> };
>>
>> Compiled, copied, and then loaded the dtbo file. Then . . .
>>
>> $ dmesg |grep pinctrl-test-7
>> [168784.685978] bone_capemgr bone_capemgr: part_number 'pinctrl-test-7',
>> version 'N/A'
>> [168784.706649] bone_capemgr bone_capemgr: slot #4: 'Override Board
>> Name,00A0,Override Manuf,pinctrl-test-7'
>> [168784.723188] bone_capemgr bone_capemgr: slot #4: dtbo
>> 'pinctrl-test-7-00A0.dtbo' loaded; overlay id #0
>> [169658.533949] bone_capemgr bone_capemgr: part_number 'pinctrl-test-7',
>> version 'N/A'
>> [169658.554579] bone_capemgr bone_capemgr: slot #5: 'Override Board
>> Name,00A0,Override Manuf,pinctrl-test-7'
>> [169658.565013] bone_capemgr bone_capemgr: slot #5: dtbo
>> 'pinctrl-test-7-00A0.dtbo' loaded; overlay id #1
>>
>> This shows that both device tree overlays have been sucessfully loaded.
>> Despite the fact that the previously overwritten overlay was never
>> unloaded. Then . . .
>>
>> $ sudo cat /sys/kernel/debug/pinctrl/44e10800.pinmux/pins |grep 840
>> pin 16 (44e10840.0) 0017 pinctrl-single
>>
>> So . . .
>> i$ cat /sys/devices/platform/bone_capemgr/slots
>>  0: PF  -1
>>  1: PF  -1
>>  2: PF  -1
>>  3: PF  -1
>>  4: P-O-L-   0 Override Board Name,00A0,Override Manuf,pinctrl-test-7
>>  5: P-O-L-   1 Override Board Name,00A0,Override Manuf,pinctrl-test-7
>>
>> oops, two overlays loaded lets see wha thappens when first one is
>> unloaded.
>>
>> $ sudo sh -c "echo '-4' > /sys/devices/platform/bone_capemgr/slots"
>> $ cat /sys/devices/platform/bone_capemgr/slots
>>  0: PF  -1
>>  1: PF  -1
>>  2: PF  -1
>>  3: PF  -1
>>  5: P-O-L-   1 Override Board Name,00A0,Override Manuf,pinctrl-test-7
>> $ sudo cat /sys/kernel/debug/pinctrl/44e10800.pinmux/pins |grep 840
>> pin 16 (44e10840.0) 0017 pinctrl-single
>>
>> Just as I thought, the original pinmux is persistent. So . . .
>> $ sudo sh -c "echo '-5' > /sys/devices/platform/bone_capemgr/slots"
>> $ cat /sys/devices/platform/bone_capemgr/slots
>>  0: PF  -1
>>  1: PF  -1
>>  2: PF  -1
>>  3: PF  -1
>> $ sudo cat /sys/kernel/debug/pinctrl/44e10800.pinmux/pins |grep 840
>> pin 16 (44e10840.0) 0017 pinctrl-single
>>
>> Ok just as I expected. pinmux's are kept until explicitly changed. Let's
>> try loading it again.
>> $ sudo sh -c "echo 'pinctrl-test-7' >
>> /sys/devices/platform/bone_capemgr/slots"
>> $ sudo cat /sys/kernel/debug/pinctrl/44e10800.pinmux/pins |grep 840
>> pin 16 (44e10840.0) 0017 pinctrl-single
>>
>> Whoopsy . . ..
>>
>>
>>
>>
>>
>> On Fri, Nov 27, 2015 at 10:26 PM, William Hermans 
>> wrote:
>>
>>> Here is what I get by following
>>> https://github.com/jadonk/validation-scripts/blob/master/test-capemgr/README.md,
>>> and modifying it to reflect one of the pins Riley is using. So, what I
>>> sugg

Re: [beagleboard] Debian Overlay / Pinmux not working?

[William Hermans]

Smells of a bug. But perhaps the GPIO pinmux's need to be explicity cleared
as I mentioned above ?

On Fri, Nov 27, 2015 at 10:39 PM, William Hermans  wrote:

> OK so I changed to this:
>
> fragment@0 {
> target = <&am33xx_pinmux>;
> __overlay__ {
> pinctrl_test: pinctrl_test_7_pins {
> pinctrl-single,pins = <
> 0x040 0x27  // P9_15 PINS$16 GPIO1_16 = 48 Input Mode7
> pullup
> >;
> };
> };
> };
>
> Compiled, copied, and then loaded the dtbo file. Then . . .
>
> $ dmesg |grep pinctrl-test-7
> [168784.685978] bone_capemgr bone_capemgr: part_number 'pinctrl-test-7',
> version 'N/A'
> [168784.706649] bone_capemgr bone_capemgr: slot #4: 'Override Board
> Name,00A0,Override Manuf,pinctrl-test-7'
> [168784.723188] bone_capemgr bone_capemgr: slot #4: dtbo
> 'pinctrl-test-7-00A0.dtbo' loaded; overlay id #0
> [169658.533949] bone_capemgr bone_capemgr: part_number 'pinctrl-test-7',
> version 'N/A'
> [169658.554579] bone_capemgr bone_capemgr: slot #5: 'Override Board
> Name,00A0,Override Manuf,pinctrl-test-7'
> [169658.565013] bone_capemgr bone_capemgr: slot #5: dtbo
> 'pinctrl-test-7-00A0.dtbo' loaded; overlay id #1
>
> This shows that both device tree overlays have been sucessfully loaded.
> Despite the fact that the previously overwritten overlay was never
> unloaded. Then . . .
>
> $ sudo cat /sys/kernel/debug/pinctrl/44e10800.pinmux/pins |grep 840
> pin 16 (44e10840.0) 0017 pinctrl-single
>
> So . . .
> i$ cat /sys/devices/platform/bone_capemgr/slots
>  0: PF  -1
>  1: PF  -1
>  2: PF  -1
>  3: PF  -1
>  4: P-O-L-   0 Override Board Name,00A0,Override Manuf,pinctrl-test-7
>  5: P-O-L-   1 Override Board Name,00A0,Override Manuf,pinctrl-test-7
>
> oops, two overlays loaded lets see wha thappens when first one is unloaded.
>
> $ sudo sh -c "echo '-4' > /sys/devices/platform/bone_capemgr/slots"
> $ cat /sys/devices/platform/bone_capemgr/slots
>  0: PF  -1
>  1: PF  -1
>  2: PF  -1
>  3: PF  -1
>  5: P-O-L-   1 Override Board Name,00A0,Override Manuf,pinctrl-test-7
> $ sudo cat /sys/kernel/debug/pinctrl/44e10800.pinmux/pins |grep 840
> pin 16 (44e10840.0) 0017 pinctrl-single
>
> Just as I thought, the original pinmux is persistent. So . . .
> $ sudo sh -c "echo '-5' > /sys/devices/platform/bone_capemgr/slots"
> $ cat /sys/devices/platform/bone_capemgr/slots
>  0: PF  -1
>  1: PF  -1
>  2: PF  -1
>  3: PF  -1
> $ sudo cat /sys/kernel/debug/pinctrl/44e10800.pinmux/pins |grep 840
> pin 16 (44e10840.0) 0017 pinctrl-single
>
> Ok just as I expected. pinmux's are kept until explicitly changed. Let's
> try loading it again.
> $ sudo sh -c "echo 'pinctrl-test-7' >
> /sys/devices/platform/bone_capemgr/slots"
> $ sudo cat /sys/kernel/debug/pinctrl/44e10800.pinmux/pins |grep 840
> pin 16 (44e10840.0) 0017 pinctrl-single
>
> Whoopsy . . ..
>
>
>
>
>
> On Fri, Nov 27, 2015 at 10:26 PM, William Hermans 
> wrote:
>
>> Here is what I get by following
>> https://github.com/jadonk/validation-scripts/blob/master/test-capemgr/README.md,
>> and modifying it to reflect one of the pins Riley is using. So, what I
>> suggest is that Riley has an overlay loaded that has already claimed these
>> pins. Either by experimenting previously with different values, and not
>> unloading the previous overlay. Or An overlay unbeknownst to him. I'll
>> experiment now with changing up my overlay and see what happens. But the
>> only other option really is that something on Riley's system is broken.
>>
>> /*
>>  * Copyright (C) 2012 Texas Instruments Incorporated - http://www.ti.com/
>>  *
>>  * This program is free software; you can redistribute it and/or modify
>>  * it under the terms of the GNU General Public License version 2 as
>>  * published by the Free Software Foundation.
>>  */
>> /dts-v1/;
>> /plugin/;
>>
>> / {
>> compatible = "ti,beaglebone", "ti,beaglebone-black";
>>
>> /* identification */
>> part-number = "pinctrl-test-7";
>>
>> fragment@0 {
>> target = <&am33xx_pinmux>;
>> __overlay__ {
>> pinctrl_test: pinctrl_test_7_pins {
>> pinctrl-single,pins = <
>> 0x040 0x17  // P9_15 PINS$16 GPIO1_16 = 48 Input
>> Mode7 pullup
>> >;
>> };
>> };
>> };
>>
>> fragment@1 {
>> target = <&ocp>;
>> __overlay__ {
>> test_helper: helper {
>> compatible = "gpio-of-helper";
>> pinctrl-names = "default";
>> pinctrl-0 = <&pinctrl_test>;
>> status = "okay";
>> };
>> };
>> };
>> };
>>
>>  $ dtc -O dtb -o pinctrl-test-7-00A0.dtbo -b 0 -@ pinctrl-test-7.dts
>>  $ sudo cp pinctrl-test-7-00A0.dtbo /lib/firmware/
>>  $ cat /sys/devices/platform/bone_capemgr/slots
>>  0: PF  -1
>>  1: PF  -1
>>  2: PF  -1
>>  3: PF  -1
>> $ sudo sh -c "echo 'pinctrl-te

Re: [beagleboard] Debian Overlay / Pinmux not working?

[William Hermans]

OK so I changed to this:

fragment@0 {
target = <&am33xx_pinmux>;
__overlay__ {
pinctrl_test: pinctrl_test_7_pins {
pinctrl-single,pins = <
0x040 0x27  // P9_15 PINS$16 GPIO1_16 = 48 Input Mode7
pullup
>;
};
};
};

Compiled, copied, and then loaded the dtbo file. Then . . .

$ dmesg |grep pinctrl-test-7
[168784.685978] bone_capemgr bone_capemgr: part_number 'pinctrl-test-7',
version 'N/A'
[168784.706649] bone_capemgr bone_capemgr: slot #4: 'Override Board
Name,00A0,Override Manuf,pinctrl-test-7'
[168784.723188] bone_capemgr bone_capemgr: slot #4: dtbo
'pinctrl-test-7-00A0.dtbo' loaded; overlay id #0
[169658.533949] bone_capemgr bone_capemgr: part_number 'pinctrl-test-7',
version 'N/A'
[169658.554579] bone_capemgr bone_capemgr: slot #5: 'Override Board
Name,00A0,Override Manuf,pinctrl-test-7'
[169658.565013] bone_capemgr bone_capemgr: slot #5: dtbo
'pinctrl-test-7-00A0.dtbo' loaded; overlay id #1

This shows that both device tree overlays have been sucessfully loaded.
Despite the fact that the previously overwritten overlay was never
unloaded. Then . . .

$ sudo cat /sys/kernel/debug/pinctrl/44e10800.pinmux/pins |grep 840
pin 16 (44e10840.0) 0017 pinctrl-single

So . . .
i$ cat /sys/devices/platform/bone_capemgr/slots
 0: PF  -1
 1: PF  -1
 2: PF  -1
 3: PF  -1
 4: P-O-L-   0 Override Board Name,00A0,Override Manuf,pinctrl-test-7
 5: P-O-L-   1 Override Board Name,00A0,Override Manuf,pinctrl-test-7

oops, two overlays loaded lets see wha thappens when first one is unloaded.

$ sudo sh -c "echo '-4' > /sys/devices/platform/bone_capemgr/slots"
$ cat /sys/devices/platform/bone_capemgr/slots
 0: PF  -1
 1: PF  -1
 2: PF  -1
 3: PF  -1
 5: P-O-L-   1 Override Board Name,00A0,Override Manuf,pinctrl-test-7
$ sudo cat /sys/kernel/debug/pinctrl/44e10800.pinmux/pins |grep 840
pin 16 (44e10840.0) 0017 pinctrl-single

Just as I thought, the original pinmux is persistent. So . . .
$ sudo sh -c "echo '-5' > /sys/devices/platform/bone_capemgr/slots"
$ cat /sys/devices/platform/bone_capemgr/slots
 0: PF  -1
 1: PF  -1
 2: PF  -1
 3: PF  -1
$ sudo cat /sys/kernel/debug/pinctrl/44e10800.pinmux/pins |grep 840
pin 16 (44e10840.0) 0017 pinctrl-single

Ok just as I expected. pinmux's are kept until explicitly changed. Let's
try loading it again.
$ sudo sh -c "echo 'pinctrl-test-7' >
/sys/devices/platform/bone_capemgr/slots"
$ sudo cat /sys/kernel/debug/pinctrl/44e10800.pinmux/pins |grep 840
pin 16 (44e10840.0) 0017 pinctrl-single

Whoopsy . . ..





On Fri, Nov 27, 2015 at 10:26 PM, William Hermans  wrote:

> Here is what I get by following
> https://github.com/jadonk/validation-scripts/blob/master/test-capemgr/README.md,
> and modifying it to reflect one of the pins Riley is using. So, what I
> suggest is that Riley has an overlay loaded that has already claimed these
> pins. Either by experimenting previously with different values, and not
> unloading the previous overlay. Or An overlay unbeknownst to him. I'll
> experiment now with changing up my overlay and see what happens. But the
> only other option really is that something on Riley's system is broken.
>
> /*
>  * Copyright (C) 2012 Texas Instruments Incorporated - http://www.ti.com/
>  *
>  * This program is free software; you can redistribute it and/or modify
>  * it under the terms of the GNU General Public License version 2 as
>  * published by the Free Software Foundation.
>  */
> /dts-v1/;
> /plugin/;
>
> / {
> compatible = "ti,beaglebone", "ti,beaglebone-black";
>
> /* identification */
> part-number = "pinctrl-test-7";
>
> fragment@0 {
> target = <&am33xx_pinmux>;
> __overlay__ {
> pinctrl_test: pinctrl_test_7_pins {
> pinctrl-single,pins = <
> 0x040 0x17  // P9_15 PINS$16 GPIO1_16 = 48 Input Mode7
> pullup
> >;
> };
> };
> };
>
> fragment@1 {
> target = <&ocp>;
> __overlay__ {
> test_helper: helper {
> compatible = "gpio-of-helper";
> pinctrl-names = "default";
> pinctrl-0 = <&pinctrl_test>;
> status = "okay";
> };
> };
> };
> };
>
>  $ dtc -O dtb -o pinctrl-test-7-00A0.dtbo -b 0 -@ pinctrl-test-7.dts
>  $ sudo cp pinctrl-test-7-00A0.dtbo /lib/firmware/
>  $ cat /sys/devices/platform/bone_capemgr/slots
>  0: PF  -1
>  1: PF  -1
>  2: PF  -1
>  3: PF  -1
> $ sudo sh -c "echo 'pinctrl-test-7' >
> /sys/devices/platform/bone_capemgr/slots"
> $ cat /sys/devices/platform/bone_capemgr/slots
> $ cat /sys/devices/platform/bone_capemgr/slots
>  0: PF  -1
>  1: PF  -1
>  2: PF  -1
>  3: PF  -1
>  4: P-O-L-   0 Override Board Name,00A0,Override Manuf,pinctrl-test-7
> $ dmesg |grep pinctrl-test-7
> [168784.685978] bone_capemgr bone_capemgr: pa

Re: [beagleboard] Debian Overlay / Pinmux not working?

[William Hermans]

Here is what I get by following
https://github.com/jadonk/validation-scripts/blob/master/test-capemgr/README.md,
and modifying it to reflect one of the pins Riley is using. So, what I
suggest is that Riley has an overlay loaded that has already claimed these
pins. Either by experimenting previously with different values, and not
unloading the previous overlay. Or An overlay unbeknownst to him. I'll
experiment now with changing up my overlay and see what happens. But the
only other option really is that something on Riley's system is broken.

/*
 * Copyright (C) 2012 Texas Instruments Incorporated - http://www.ti.com/
 *
 * This program is free software; you can redistribute it and/or modify
 * it under the terms of the GNU General Public License version 2 as
 * published by the Free Software Foundation.
 */
/dts-v1/;
/plugin/;

/ {
compatible = "ti,beaglebone", "ti,beaglebone-black";

/* identification */
part-number = "pinctrl-test-7";

fragment@0 {
target = <&am33xx_pinmux>;
__overlay__ {
pinctrl_test: pinctrl_test_7_pins {
pinctrl-single,pins = <
0x040 0x17  // P9_15 PINS$16 GPIO1_16 = 48 Input Mode7
pullup
>;
};
};
};

fragment@1 {
target = <&ocp>;
__overlay__ {
test_helper: helper {
compatible = "gpio-of-helper";
pinctrl-names = "default";
pinctrl-0 = <&pinctrl_test>;
status = "okay";
};
};
};
};

 $ dtc -O dtb -o pinctrl-test-7-00A0.dtbo -b 0 -@ pinctrl-test-7.dts
 $ sudo cp pinctrl-test-7-00A0.dtbo /lib/firmware/
 $ cat /sys/devices/platform/bone_capemgr/slots
 0: PF  -1
 1: PF  -1
 2: PF  -1
 3: PF  -1
$ sudo sh -c "echo 'pinctrl-test-7' >
/sys/devices/platform/bone_capemgr/slots"
$ cat /sys/devices/platform/bone_capemgr/slots
$ cat /sys/devices/platform/bone_capemgr/slots
 0: PF  -1
 1: PF  -1
 2: PF  -1
 3: PF  -1
 4: P-O-L-   0 Override Board Name,00A0,Override Manuf,pinctrl-test-7
$ dmesg |grep pinctrl-test-7
[168784.685978] bone_capemgr bone_capemgr: part_number 'pinctrl-test-7',
version 'N/A'
[168784.706649] bone_capemgr bone_capemgr: slot #4: 'Override Board
Name,00A0,Override Manuf,pinctrl-test-7'
[168784.723188] bone_capemgr bone_capemgr: slot #4: dtbo
'pinctrl-test-7-00A0.dtbo' loaded; overlay id #0

$ sudo cat /sys/kernel/debug/pinctrl/44e10800.pinmux/pins |grep 840
pin 16 (44e10840.0) 0017 pinctrl-single

On Fri, Nov 27, 2015 at 10:14 PM, John Syne  wrote:

> I believe the pinmux gets setup in pinctrl_bind_pins() found in
> drivers/pinctrl.c.
>
> pinctrl_bind_pins() gets called by really_probe(), line 291 of
> drivers/dd.c and then calls the gpio_of_helper_probe on line 316 or 320, so
> I don’t think this has anything to do with gpio-of-helper.c driver.
> Probably need to setup some debug statements in pinctrl_bind_pins() to see
> why this does not work.
>
> Regards,
> John
>
>
>
>
> > On Nov 27, 2015, at 7:25 PM, Charles Steinkuehler <
> char...@steinkuehler.net> wrote:
> >
> > I don't have time to dig into the full details, but IIRC this has
> > popped up before.  I don't think the gpio-of-helper driver actually
> > does anything (like setup the pinmux) if you're not actually
> > _exporting_ any gpios.  But I could be wrong...it's been a while since
> > I crawled through the code.
> >
> > Oh, and your pinmux settings don't match the comments.  If you really
> > want inputs with the pullup enabled, the value to use is 0x37, *NOT*
> > 0x17.  It's important to enable the gpio receive buffer (bit 0x20) or
> > you won't be able to read the value on the GPIO pin (IIRC it will
> > always return zero).  If you really want outputs and just didn't
> > update the comments, 0x17 is fine.
> >
> > On 11/27/2015 2:14 PM, Riley Porter wrote:
> >> Yes I am running:
> >>
> >> *Linux beaglebone 4.1.1-bone10 #1 Tue Jul 7 01:15:35 UTC 2015 armv7l
> >> GNU/Linux*
> >>
> >> I followed your instructions but still am at a loss.  I was able to
> update
> >> the device tree compiler and the kernel which is now:
> >>
> >> *Linux beaglebone 4.1.13-ti-r33 #1 SMP PREEMPT Fri Nov 20 11:00:50 UTC
> 2015
> >> armv7l GNU/Linux*
> >>
> >> Perhaps describing my exact steps might shed some light on my screw up?
> >>
> >>
> >> *This is the device tree I am testing with:*
> >>
> >>
> >> /*
> >>> snip for space
> >>> */
> >>> /dts-v1/;
> >>> /plugin/;
> >>>
> >>> /{
> >>>   compatible = "ti,beaglebone", "ti,beaglebone-black";
> >>>   part-number = "EBB-GPIO-Example";
> >>>   version = "00A0";
> >>>
> >>>   fragment@0 {
> >>> target = <&am33xx_pinmux>;
> >>>
> >>>
> >>> __overlay__ {
> >>>  ebb_example: EBB_GPIO_Example {
> >>>pinctrl-single,pins = <
> >>>
> >>>
> >>>/*=  Inputs
> */
> >>> 

Re: [beagleboard] Debian Overlay / Pinmux not working?

[John Syne]

I believe the pinmux gets setup in pinctrl_bind_pins() found in 
drivers/pinctrl.c.

pinctrl_bind_pins() gets called by really_probe(), line 291 of drivers/dd.c and 
then calls the gpio_of_helper_probe on line 316 or 320, so I don’t think this 
has anything to do with gpio-of-helper.c driver. Probably need to setup some 
debug statements in pinctrl_bind_pins() to see why this does not work. 

Regards,
John




> On Nov 27, 2015, at 7:25 PM, Charles Steinkuehler  
> wrote:
> 
> I don't have time to dig into the full details, but IIRC this has
> popped up before.  I don't think the gpio-of-helper driver actually
> does anything (like setup the pinmux) if you're not actually
> _exporting_ any gpios.  But I could be wrong...it's been a while since
> I crawled through the code.
> 
> Oh, and your pinmux settings don't match the comments.  If you really
> want inputs with the pullup enabled, the value to use is 0x37, *NOT*
> 0x17.  It's important to enable the gpio receive buffer (bit 0x20) or
> you won't be able to read the value on the GPIO pin (IIRC it will
> always return zero).  If you really want outputs and just didn't
> update the comments, 0x17 is fine.
> 
> On 11/27/2015 2:14 PM, Riley Porter wrote:
>> Yes I am running:
>> 
>> *Linux beaglebone 4.1.1-bone10 #1 Tue Jul 7 01:15:35 UTC 2015 armv7l
>> GNU/Linux*
>> 
>> I followed your instructions but still am at a loss.  I was able to update
>> the device tree compiler and the kernel which is now:
>> 
>> *Linux beaglebone 4.1.13-ti-r33 #1 SMP PREEMPT Fri Nov 20 11:00:50 UTC 2015
>> armv7l GNU/Linux*
>> 
>> Perhaps describing my exact steps might shed some light on my screw up?
>> 
>> 
>> *This is the device tree I am testing with:*
>> 
>> 
>> /*
>>> snip for space
>>> */
>>> /dts-v1/;
>>> /plugin/;
>>> 
>>> /{
>>>   compatible = "ti,beaglebone", "ti,beaglebone-black";
>>>   part-number = "EBB-GPIO-Example";
>>>   version = "00A0";
>>> 
>>>   fragment@0 {
>>> target = <&am33xx_pinmux>;
>>> 
>>> 
>>> __overlay__ {
>>>  ebb_example: EBB_GPIO_Example {
>>>pinctrl-single,pins = <
>>> 
>>> 
>>>/*=  Inputs */
>>>0x070 0x17  // P9_11 PINS$28 GPIO0_30 = 30
>>> Input Mode7 pullup
>>>0x078 0x17  // P9_12 PINS$30 GPIO1_28 = 60
>>> Input Mode7 pullup
>>>0x074 0x17  // P9_13 PINS$29 GPIO0_31 = 31
>>> Input Mode7 pullup
>>>0x048 0x17  // P9_14 PINS$18 GPIO1_18 = 50
>>> Input Mode7 pullup
>>>0x040 0x17  // P9_15 PINS$16 GPIO1_16 = 48
>>> Input Mode7 pullup
>>>0x04c 0x17  // P9_16 PINS$19 GPIO1_19 = 51
>>> Input Mode7 pullup
>>>0x15c 0x17  // P9_17 PINS$87 GPIO0_5  =  5
>>> Input Mode7 pullup
>>>0x158 0x17  // P9_18 PINS$86 GPIO0_4  =  4
>>> Input Mode7 pullup
>>> 
>>>/* OUTPUT  GPIO(mode7) 0x07 pulldown, 0x17
>>> pullup, 0x?f no pullup/down */
>>>/* INPUT   GPIO(mode7) 0x27 pulldown, 0x37
>>> pullup, 0x?f no pullup/down */
 ;
>>>  };
>>> };
>>>   };
>>> 
>>>   fragment@1 {
>>>target = <&ocp>;
>>>__overlay__ {
>>>gpio_helper {
>>>compatible = "gpio-of-helper";
>>>status = "okay";
>>>pinctrl-names = "default";
>>>pinctrl-0 = <&ebb_example>;
>>>};
>>>};
>>>};
>>> };
>> 
>> 
>> 
>> I also removed ALL overlays from my system before doing this below.
>> Here is my output from slots and a python program to get the pins i wrote:
>> 
>> *root ~/bbb_stuff # **slots*
>> 
>> 
>> 
>> 
>> * 0: PF  -1  1: PF  -1  2: PF  -1  3: PF  -1  9: P-O-L-   0
>> Override Board Name,00A0,Override Manuf,EBB-GPIO-Example*
>> 
>> *root ~/bbb_stuff # ./getpins *
>> 
>> 
>> 
>> *==Reading Pinux
>> Pins==*
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> *pin 16 (44e10840.0) 0027 pinctrl-singlepin 18 (44e10848.0) 0027
>> pinctrl-singlepin 19 (44e1084c.0) 0027 pinctrl-singlepin 28
>> (44e10870.0) 0017 pinctrl-singlepin 29 (44e10874.0) 0027
>> pinctrl-singlepin 30 (44e10878.0) 0027 pinctrl-singlepin 86
>> (44e10958.0) 0027 pinctrl-singlepin 87 (44e1095c.0) 0027
>> pinctrl-single*
>> 
>> You can clearly see I have requested them all to be 0x17?
>> 
>> *Here are the alias's I am using:*
>> 
>> *pins='cat /sys/kernel/debug/pinctrl/44e10800.pinmux/pins'**slots='cat
>> /sys/devices/platform/bone_capemgr/slots'*
>> 
>> 
>> *This is the command i used to compile the d

Re: [beagleboard] Debian Overlay / Pinmux not working?

[William Hermans]

A good overview of GPIO's and device tree overlays:
http://derekmolloy.ie/gpios-on-the-beaglebone-black-using-device-tree-overlays/

Which is something I've been meaning to read myself for a long time . . .

On Fri, Nov 27, 2015 at 8:25 PM, Charles Steinkuehler <
char...@steinkuehler.net> wrote:

> I don't have time to dig into the full details, but IIRC this has
> popped up before.  I don't think the gpio-of-helper driver actually
> does anything (like setup the pinmux) if you're not actually
> _exporting_ any gpios.  But I could be wrong...it's been a while since
> I crawled through the code.
>
> Oh, and your pinmux settings don't match the comments.  If you really
> want inputs with the pullup enabled, the value to use is 0x37, *NOT*
> 0x17.  It's important to enable the gpio receive buffer (bit 0x20) or
> you won't be able to read the value on the GPIO pin (IIRC it will
> always return zero).  If you really want outputs and just didn't
> update the comments, 0x17 is fine.
>
> On 11/27/2015 2:14 PM, Riley Porter wrote:
> > Yes I am running:
> >
> > *Linux beaglebone 4.1.1-bone10 #1 Tue Jul 7 01:15:35 UTC 2015 armv7l
> > GNU/Linux*
> >
> > I followed your instructions but still am at a loss.  I was able to
> update
> > the device tree compiler and the kernel which is now:
> >
> > *Linux beaglebone 4.1.13-ti-r33 #1 SMP PREEMPT Fri Nov 20 11:00:50 UTC
> 2015
> > armv7l GNU/Linux*
> >
> >  Perhaps describing my exact steps might shed some light on my screw up?
> >
> >
> > *This is the device tree I am testing with:*
> >
> >
> > /*
> >> snip for space
> >> */
> >> /dts-v1/;
> >> /plugin/;
> >>
> >> /{
> >>compatible = "ti,beaglebone", "ti,beaglebone-black";
> >>part-number = "EBB-GPIO-Example";
> >>version = "00A0";
> >>
> >>fragment@0 {
> >>  target = <&am33xx_pinmux>;
> >>
> >>
> >>  __overlay__ {
> >>   ebb_example: EBB_GPIO_Example {
> >> pinctrl-single,pins = <
> >>
> >>
> >> /*=  Inputs
> */
> >> 0x070 0x17  // P9_11 PINS$28 GPIO0_30 =
> 30
> >> Input Mode7 pullup
> >> 0x078 0x17  // P9_12 PINS$30 GPIO1_28 =
> 60
> >> Input Mode7 pullup
> >> 0x074 0x17  // P9_13 PINS$29 GPIO0_31 =
> 31
> >> Input Mode7 pullup
> >> 0x048 0x17  // P9_14 PINS$18 GPIO1_18 =
> 50
> >> Input Mode7 pullup
> >> 0x040 0x17  // P9_15 PINS$16 GPIO1_16 =
> 48
> >> Input Mode7 pullup
> >> 0x04c 0x17  // P9_16 PINS$19 GPIO1_19 =
> 51
> >> Input Mode7 pullup
> >> 0x15c 0x17  // P9_17 PINS$87 GPIO0_5
> =  5
> >> Input Mode7 pullup
> >> 0x158 0x17  // P9_18 PINS$86 GPIO0_4
> =  4
> >> Input Mode7 pullup
> >>
> >> /* OUTPUT  GPIO(mode7) 0x07 pulldown,
> 0x17
> >> pullup, 0x?f no pullup/down */
> >> /* INPUT   GPIO(mode7) 0x27 pulldown,
> 0x37
> >> pullup, 0x?f no pullup/down */
> >> >;
> >>   };
> >>  };
> >>};
> >>
> >>fragment@1 {
> >> target = <&ocp>;
> >> __overlay__ {
> >> gpio_helper {
> >> compatible = "gpio-of-helper";
> >> status = "okay";
> >> pinctrl-names = "default";
> >> pinctrl-0 = <&ebb_example>;
> >> };
> >> };
> >> };
> >> };
> >
> >
> >
> > I also removed ALL overlays from my system before doing this below.
> > Here is my output from slots and a python program to get the pins i
> wrote:
> >
> > *root ~/bbb_stuff # **slots*
> >
> >
> >
> >
> > * 0: PF  -1  1: PF  -1  2: PF  -1  3: PF  -1  9: P-O-L-
>  0
> > Override Board Name,00A0,Override Manuf,EBB-GPIO-Example*
> >
> > *root ~/bbb_stuff # ./getpins *
> >
> >
> >
> > *==Reading Pinux
> > Pins==*
> >
> >
> >
> >
> >
> >
> >
> >
> > *pin 16 (44e10840.0) 0027 pinctrl-singlepin 18 (44e10848.0) 0027
> > pinctrl-singlepin 19 (44e1084c.0) 0027 pinctrl-singlepin 28
> > (44e10870.0) 0017 pinctrl-singlepin 29 (44e10874.0) 0027
> > pinctrl-singlepin 30 (44e10878.0) 0027 pinctrl-singlepin 86
> > (44e10958.0) 0027 pinctrl-singlepin 87 (44e1095c.0) 0027
> > pinctrl-single*
> >
> > You can clearly see I have requested them all to be 0x17?
> >
> > *Here are the alias's I am using:*
> >
> > *pins='cat /sys/kernel/debug/pinctrl/44e10800.pinmux/pins'**slots='cat
> > /sys/devices/platform/bone_capemgr/slots'*
> >
> >
> > *This is the command i used to compile the dt.*
> > *dtc -O dtb 

Re: [beagleboard] Debian Overlay / Pinmux not working?

[Charles Steinkuehler]

I don't have time to dig into the full details, but IIRC this has
popped up before.  I don't think the gpio-of-helper driver actually
does anything (like setup the pinmux) if you're not actually
_exporting_ any gpios.  But I could be wrong...it's been a while since
I crawled through the code.

Oh, and your pinmux settings don't match the comments.  If you really
want inputs with the pullup enabled, the value to use is 0x37, *NOT*
0x17.  It's important to enable the gpio receive buffer (bit 0x20) or
you won't be able to read the value on the GPIO pin (IIRC it will
always return zero).  If you really want outputs and just didn't
update the comments, 0x17 is fine.

On 11/27/2015 2:14 PM, Riley Porter wrote:
> Yes I am running:
> 
> *Linux beaglebone 4.1.1-bone10 #1 Tue Jul 7 01:15:35 UTC 2015 armv7l
> GNU/Linux*
> 
> I followed your instructions but still am at a loss.  I was able to update
> the device tree compiler and the kernel which is now:
> 
> *Linux beaglebone 4.1.13-ti-r33 #1 SMP PREEMPT Fri Nov 20 11:00:50 UTC 2015
> armv7l GNU/Linux*
> 
>  Perhaps describing my exact steps might shed some light on my screw up?
> 
> 
> *This is the device tree I am testing with:*
> 
> 
> /*
>> snip for space
>> */
>> /dts-v1/;
>> /plugin/;
>>
>> /{
>>compatible = "ti,beaglebone", "ti,beaglebone-black";
>>part-number = "EBB-GPIO-Example";
>>version = "00A0";
>>
>>fragment@0 {
>>  target = <&am33xx_pinmux>;
>>
>>
>>  __overlay__ {
>>   ebb_example: EBB_GPIO_Example {
>> pinctrl-single,pins = <
>>
>>
>> /*=  Inputs */
>> 0x070 0x17  // P9_11 PINS$28 GPIO0_30 = 30
>> Input Mode7 pullup
>> 0x078 0x17  // P9_12 PINS$30 GPIO1_28 = 60
>> Input Mode7 pullup
>> 0x074 0x17  // P9_13 PINS$29 GPIO0_31 = 31
>> Input Mode7 pullup
>> 0x048 0x17  // P9_14 PINS$18 GPIO1_18 = 50
>> Input Mode7 pullup
>> 0x040 0x17  // P9_15 PINS$16 GPIO1_16 = 48
>> Input Mode7 pullup
>> 0x04c 0x17  // P9_16 PINS$19 GPIO1_19 = 51
>> Input Mode7 pullup
>> 0x15c 0x17  // P9_17 PINS$87 GPIO0_5  =  5
>> Input Mode7 pullup
>> 0x158 0x17  // P9_18 PINS$86 GPIO0_4  =  4
>> Input Mode7 pullup
>>
>> /* OUTPUT  GPIO(mode7) 0x07 pulldown, 0x17
>> pullup, 0x?f no pullup/down */
>> /* INPUT   GPIO(mode7) 0x27 pulldown, 0x37
>> pullup, 0x?f no pullup/down */
>> >;
>>   };
>>  };
>>};
>>
>>fragment@1 {
>> target = <&ocp>;
>> __overlay__ {
>> gpio_helper {
>> compatible = "gpio-of-helper";
>> status = "okay";
>> pinctrl-names = "default";
>> pinctrl-0 = <&ebb_example>;
>> };
>> };
>> };
>> };
> 
> 
> 
> I also removed ALL overlays from my system before doing this below.
> Here is my output from slots and a python program to get the pins i wrote:
> 
> *root ~/bbb_stuff # **slots*
> 
> 
> 
> 
> * 0: PF  -1  1: PF  -1  2: PF  -1  3: PF  -1  9: P-O-L-   0
> Override Board Name,00A0,Override Manuf,EBB-GPIO-Example*
> 
> *root ~/bbb_stuff # ./getpins *
> 
> 
> 
> *==Reading Pinux
> Pins==*
> 
> 
> 
> 
> 
> 
> 
> 
> *pin 16 (44e10840.0) 0027 pinctrl-singlepin 18 (44e10848.0) 0027
> pinctrl-singlepin 19 (44e1084c.0) 0027 pinctrl-singlepin 28
> (44e10870.0) 0017 pinctrl-singlepin 29 (44e10874.0) 0027
> pinctrl-singlepin 30 (44e10878.0) 0027 pinctrl-singlepin 86
> (44e10958.0) 0027 pinctrl-singlepin 87 (44e1095c.0) 0027
> pinctrl-single*
> 
> You can clearly see I have requested them all to be 0x17?
> 
> *Here are the alias's I am using:*
> 
> *pins='cat /sys/kernel/debug/pinctrl/44e10800.pinmux/pins'**slots='cat
> /sys/devices/platform/bone_capemgr/slots'*
> 
> 
> *This is the command i used to compile the dt.*
> *dtc -O dtb -o EBB-GPIO-Example-00A0.dtbo -b 0 -@ EBB-GPIO-Example.dts*
> 
> *This is the command I used to install it:*
> *echo  EBB-GPIO-Example-00A0 > "/sys/devices/platform/bone_capemgr/slots"*
> 
> 
> *This is the dmesg output after installing the overlay:*
> 
> 
> 
> 
> 
> 
> *[ 2629.259630] bone_capemgr bone_capemgr: part_number
> 'EBB-GPIO-Example-00A0', version 'N/A'[ 2629.259679] bone_capemgr
> bone_capemgr: slot #11: override[ 2629.259700] bone_capemgr bone_capemgr:
> Using override eeprom data at slot 11[ 2629.259722] bone_capemgr
> bone_capemgr: slot #1

Re: [beagleboard] Debian Overlay / Pinmux not working?

[William Hermans]

Riley, confirm device tree compiler version. As such. . .

$ dtc -v
Version: DTC 1.4.1-g5cadadd9

If it's not version 1.4.1-, then you have the wrong version.

On Fri, Nov 27, 2015 at 6:57 PM, William Hermans  wrote:

> One is done as root, the other is not. I would guess he is probably logged
> in as root.
>
> On Fri, Nov 27, 2015 at 6:56 PM, John Syne  wrote:
>
>> Thanks William,
>>
>> He uses the command:
>>
>> *echo  EBB-GPIO-Example-00A0 > "/sys/devices/platform/bone_capemgr/slots”*
>>
>> but I think he should be using the command:
>>
>> sudo sh -c “echo '*EBB-GPIO-Example-00A0' >
>> /sys/devices/platform/bone_capemgr/slots”*
>>
>> Other than that, I don’t see why he has this problem.
>>
>> Regards,
>> John
>>
>>
>>
>>
>> On Nov 27, 2015, at 4:26 PM, William Hermans  wrote:
>>
>> Err sorry his second post.
>>
>> On Fri, Nov 27, 2015 at 5:26 PM, William Hermans 
>> wrote:
>>
>>> His overlay is in the first post John.
>>>
>>> On Fri, Nov 27, 2015 at 5:07 PM, John Syne  wrote:
>>>
 One more thing, just defining pinmux in the overlay will have no
 effect. The pinmux will only be configured as part of installing the
 driver. Just before the kernel calls the driver probe function, it sets up
 the pinmux as defined by the pinctrl definition.

 Regards,
 John




 On Nov 27, 2015, at 3:58 PM, John Syne  wrote:

 GPIO MODE SETTINGS Bit 6 Bit 5 Bit 4 Bit 3 Bit 2,1,0 Slew Control Receiver
 Active Pullup/Pulldown Enable Pullup/down Mux Mode 0 Fast 0 Disable 0
 Pulldown select 0 Enabled 000 Mode 0 to 1 Enable 1 Pullup select 1
 Disabled 111 Mode 7   e.g. OUTPUT GPIO(mode7) 0x07 pulldown, 0x17
 pullup, 0x?f no pullup/down e.g. INPUT GPIO(mode7) 0x27 pulldown, 0x37
 pullup, 0x?f no pullup/down TRM Table 9-60


 From the table above, 0x27 in an input and 0x17 is an output. My guess
 is that there is some conflict that occurs and that is why the config isn’t
 set correctly. What does your overlay look like and what do you see when
 you install the overlay?

 Regards,
 John




 On Nov 27, 2015, at 1:03 PM, Riley Porter 
 wrote:

 William,

 Thanks.  This basically is exactly what I did reading johns reply.  I
 guess my main disconnect here is.  I can apply a device tree overlay that I
 make.  I see it "applied" in dmesg and in slots.  However the pinmux output
 from *cat /sys/kernel/debug/pinctrl/44e10800.pinmux/pins *continues to
 show 0x27 for their modes when I specifically set the dtc to 0x17.

 I have not actually tried to use it as an input in code yet.  Merely
 have been seeing that it is not "applying" what i thought it should.
 Perhaps I am looking at the wrong pinoutput?

 for example P9_11's offset is 0x70 and its PIN value is 28.  So * |
 grep 870*

 root ~/bb.org-overlays # *cat
 /sys/kernel/debug/pinctrl/44e10800.pinmux/pins* | grep 870
 pin 28 (44e10870.0) 00*27* pinctrl-single

 which is not 0x17?

 I am being very wordy here just to make sure you guys know exactly what
 I am doing and my expectations.


 So does anything I am doing look wrong?


 Again thanks a bunch guys for the help.  I have been at this for the
 better part of a week now and I agree William it's a step in the WRONG
 direction going to Angstrom.

 ril3y



 On Fri, Nov 27, 2015 at 3:45 PM, William Hermans 
 wrote:

> *Unfortunately the "answer" was to install angstrom.  I was hoping
>> someone on the list would have some secret answer as to why applying an
>> overlay was not changing the pinmux's?*
>>
>> *I would very much like to stick with debian but if the answer is go
>> back angstrom I guess I can live with that.*
>>
>> *Thanks*
>
> You do not have to go back to Angstrom, and if you ask me that is very
> counter productive. Read my guide here:
> http://www.embeddedhobbyist.com/2015/09/beaglebone-black-updating-device-tree-files/
>
> Do note, that the kernel I talk about at the beginning is just an
> example. You do not have to use the exact kernel I demonstrated. Any 4.x
> kernel should work with that guide.
>
>
> On Fri, Nov 27, 2015 at 1:14 PM, Riley Porter 
> wrote:
>
>> Yes I am running:
>>
>> *Linux beaglebone 4.1.1-bone10 #1 Tue Jul 7 01:15:35 UTC 2015 armv7l
>> GNU/Linux*
>>
>> I followed your instructions but still am at a loss.  I was able to
>> update the device tree compiler and the kernel which is now:
>>
>> *Linux beaglebone 4.1.13-ti-r33 #1 SMP PREEMPT Fri Nov 20 11:00:50
>> UTC 2015 armv7l GNU/Linux*
>>
>>  Perhaps describing my exact steps might shed some light on my screw
>> up?
>>
>>
>> *This is the device tree I am testing with:*
>>
>>
>> /*
>>> snip for

Re: [beagleboard] Debian Overlay / Pinmux not working?

[William Hermans]

One is done as root, the other is not. I would guess he is probably logged
in as root.

On Fri, Nov 27, 2015 at 6:56 PM, John Syne  wrote:

> Thanks William,
>
> He uses the command:
>
> *echo  EBB-GPIO-Example-00A0 > "/sys/devices/platform/bone_capemgr/slots”*
>
> but I think he should be using the command:
>
> sudo sh -c “echo '*EBB-GPIO-Example-00A0' >
> /sys/devices/platform/bone_capemgr/slots”*
>
> Other than that, I don’t see why he has this problem.
>
> Regards,
> John
>
>
>
>
> On Nov 27, 2015, at 4:26 PM, William Hermans  wrote:
>
> Err sorry his second post.
>
> On Fri, Nov 27, 2015 at 5:26 PM, William Hermans 
> wrote:
>
>> His overlay is in the first post John.
>>
>> On Fri, Nov 27, 2015 at 5:07 PM, John Syne  wrote:
>>
>>> One more thing, just defining pinmux in the overlay will have no effect.
>>> The pinmux will only be configured as part of installing the driver. Just
>>> before the kernel calls the driver probe function, it sets up the pinmux as
>>> defined by the pinctrl definition.
>>>
>>> Regards,
>>> John
>>>
>>>
>>>
>>>
>>> On Nov 27, 2015, at 3:58 PM, John Syne  wrote:
>>>
>>> GPIO MODE SETTINGS Bit 6 Bit 5 Bit 4 Bit 3 Bit 2,1,0 Slew Control Receiver
>>> Active Pullup/Pulldown Enable Pullup/down Mux Mode 0 Fast 0 Disable 0
>>> Pulldown select 0 Enabled 000 Mode 0 to 1 Enable 1 Pullup select 1
>>> Disabled 111 Mode 7   e.g. OUTPUT GPIO(mode7) 0x07 pulldown, 0x17
>>> pullup, 0x?f no pullup/down e.g. INPUT GPIO(mode7) 0x27 pulldown, 0x37
>>> pullup, 0x?f no pullup/down TRM Table 9-60
>>>
>>>
>>> From the table above, 0x27 in an input and 0x17 is an output. My guess
>>> is that there is some conflict that occurs and that is why the config isn’t
>>> set correctly. What does your overlay look like and what do you see when
>>> you install the overlay?
>>>
>>> Regards,
>>> John
>>>
>>>
>>>
>>>
>>> On Nov 27, 2015, at 1:03 PM, Riley Porter  wrote:
>>>
>>> William,
>>>
>>> Thanks.  This basically is exactly what I did reading johns reply.  I
>>> guess my main disconnect here is.  I can apply a device tree overlay that I
>>> make.  I see it "applied" in dmesg and in slots.  However the pinmux output
>>> from *cat /sys/kernel/debug/pinctrl/44e10800.pinmux/pins *continues to
>>> show 0x27 for their modes when I specifically set the dtc to 0x17.
>>>
>>> I have not actually tried to use it as an input in code yet.  Merely
>>> have been seeing that it is not "applying" what i thought it should.
>>> Perhaps I am looking at the wrong pinoutput?
>>>
>>> for example P9_11's offset is 0x70 and its PIN value is 28.  So * |
>>> grep 870*
>>>
>>> root ~/bb.org-overlays # *cat
>>> /sys/kernel/debug/pinctrl/44e10800.pinmux/pins* | grep 870
>>> pin 28 (44e10870.0) 00*27* pinctrl-single
>>>
>>> which is not 0x17?
>>>
>>> I am being very wordy here just to make sure you guys know exactly what
>>> I am doing and my expectations.
>>>
>>>
>>> So does anything I am doing look wrong?
>>>
>>>
>>> Again thanks a bunch guys for the help.  I have been at this for the
>>> better part of a week now and I agree William it's a step in the WRONG
>>> direction going to Angstrom.
>>>
>>> ril3y
>>>
>>>
>>>
>>> On Fri, Nov 27, 2015 at 3:45 PM, William Hermans 
>>> wrote:
>>>
 *Unfortunately the "answer" was to install angstrom.  I was hoping
> someone on the list would have some secret answer as to why applying an
> overlay was not changing the pinmux's?*
>
> *I would very much like to stick with debian but if the answer is go
> back angstrom I guess I can live with that.*
>
> *Thanks*

 You do not have to go back to Angstrom, and if you ask me that is very
 counter productive. Read my guide here:
 http://www.embeddedhobbyist.com/2015/09/beaglebone-black-updating-device-tree-files/

 Do note, that the kernel I talk about at the beginning is just an
 example. You do not have to use the exact kernel I demonstrated. Any 4.x
 kernel should work with that guide.


 On Fri, Nov 27, 2015 at 1:14 PM, Riley Porter 
 wrote:

> Yes I am running:
>
> *Linux beaglebone 4.1.1-bone10 #1 Tue Jul 7 01:15:35 UTC 2015 armv7l
> GNU/Linux*
>
> I followed your instructions but still am at a loss.  I was able to
> update the device tree compiler and the kernel which is now:
>
> *Linux beaglebone 4.1.13-ti-r33 #1 SMP PREEMPT Fri Nov 20 11:00:50 UTC
> 2015 armv7l GNU/Linux*
>
>  Perhaps describing my exact steps might shed some light on my screw
> up?
>
>
> *This is the device tree I am testing with:*
>
>
> /*
>> snip for space
>> */
>> /dts-v1/;
>> /plugin/;
>>
>> /{
>>compatible = "ti,beaglebone", "ti,beaglebone-black";
>>part-number = "EBB-GPIO-Example";
>>version = "00A0";
>>
>>fragment@0 {
>>  target = <&am33xx_pinmux>;
>>
>>
>>  __overlay__ {
>>   ebb_ex

Re: [beagleboard] Debian Overlay / Pinmux not working?

[John Syne]

Thanks William,

He uses the command:

echo  EBB-GPIO-Example-00A0 > "/sys/devices/platform/bone_capemgr/slots”

but I think he should be using the command:

sudo sh -c “echo 'EBB-GPIO-Example-00A0' > 
/sys/devices/platform/bone_capemgr/slots”

Other than that, I don’t see why he has this problem. 

Regards,
John




> On Nov 27, 2015, at 4:26 PM, William Hermans  wrote:
> 
> Err sorry his second post.
> 
> On Fri, Nov 27, 2015 at 5:26 PM, William Hermans  > wrote:
> His overlay is in the first post John.
> 
> On Fri, Nov 27, 2015 at 5:07 PM, John Syne  > wrote:
> One more thing, just defining pinmux in the overlay will have no effect. The 
> pinmux will only be configured as part of installing the driver. Just before 
> the kernel calls the driver probe function, it sets up the pinmux as defined 
> by the pinctrl definition. 
> 
> Regards,
> John
> 
> 
> 
> 
>> On Nov 27, 2015, at 3:58 PM, John Syne > > wrote:
>> 
>> GPIO MODE SETTINGS
>> Bit 6Bit 5   Bit 4   Bit 3   Bit 2,1,0
>> Slew Control Receiver Active Pullup/Pulldown Enable Pullup/down  Mux Mode
>> 0 Fast   0 Disable   0 Pulldown select   0 Enabled   000 
>> Mode 0 to
>> 1 Enable 1 Pullup select 1 Disabled  111 Mode 7   
>> e.g. OUTPUT GPIO(mode7) 0x07 pulldown, 0x17 pullup, 0x?f no pullup/down
>> e.g. INPUT GPIO(mode7) 0x27 pulldown, 0x37 pullup, 0x?f no pullup/down
>> TRM Table 9-60   
>> 
>> 
>> 
>> From the table above, 0x27 in an input and 0x17 is an output. My guess is 
>> that there is some conflict that occurs and that is why the config isn’t set 
>> correctly. What does your overlay look like and what do you see when you 
>> install the overlay?
>> 
>> Regards,
>> John
>> 
>> 
>> 
>> 
>>> On Nov 27, 2015, at 1:03 PM, Riley Porter >> > wrote:
>>> 
>>> William,
>>> 
>>> Thanks.  This basically is exactly what I did reading johns reply.  I guess 
>>> my main disconnect here is.  I can apply a device tree overlay that I make. 
>>>  I see it "applied" in dmesg and in slots.  However the pinmux output from 
>>> cat /sys/kernel/debug/pinctrl/44e10800.pinmux/pins continues to show 0x27 
>>> for their modes when I specifically set the dtc to 0x17.  
>>> 
>>> I have not actually tried to use it as an input in code yet.  Merely have 
>>> been seeing that it is not "applying" what i thought it should.  Perhaps I 
>>> am looking at the wrong pinoutput?
>>> 
>>> for example P9_11's offset is 0x70 and its PIN value is 28.  So  | grep 870
>>> 
>>> root ~/bb.org -overlays # cat 
>>> /sys/kernel/debug/pinctrl/44e10800.pinmux/pins | grep 870
>>> pin 28 (44e10870.0) 0027 pinctrl-single 
>>> 
>>> which is not 0x17?
>>> 
>>> I am being very wordy here just to make sure you guys know exactly what I 
>>> am doing and my expectations.  
>>> 
>>> 
>>> 
>>> So does anything I am doing look wrong?
>>> 
>>> 
>>> 
>>> Again thanks a bunch guys for the help.  I have been at this for the better 
>>> part of a week now and I agree William it's a step in the WRONG direction 
>>> going to Angstrom.
>>> 
>>> ril3y
>>> 
>>> 
>>> 
>>> 
>>> On Fri, Nov 27, 2015 at 3:45 PM, William Hermans >> > wrote:
>>> Unfortunately the "answer" was to install angstrom.  I was hoping someone 
>>> on the list would have some secret answer as to why applying an overlay was 
>>> not changing the pinmux's?
>>> 
>>> I would very much like to stick with debian but if the answer is go back 
>>> angstrom I guess I can live with that.
>>> 
>>> Thanks
>>> You do not have to go back to Angstrom, and if you ask me that is very 
>>> counter productive. Read my guide here: 
>>> http://www.embeddedhobbyist.com/2015/09/beaglebone-black-updating-device-tree-files/
>>>  
>>> 
>>> 
>>> Do note, that the kernel I talk about at the beginning is just an example. 
>>> You do not have to use the exact kernel I demonstrated. Any 4.x kernel 
>>> should work with that guide.
>>> 
>>> 
>>> On Fri, Nov 27, 2015 at 1:14 PM, Riley Porter >> > wrote:
>>> Yes I am running:
>>> Linux beaglebone 4.1.1-bone10 #1 Tue Jul 7 01:15:35 UTC 2015 armv7l 
>>> GNU/Linux
>>> 
>>> I followed your instructions but still am at a loss.  I was able to update 
>>> the device tree compiler and the kernel which is now:
>>> 
>>> Linux beaglebone 4.1.13-ti-r33 #1 SMP PREEMPT Fri Nov 20 11:00:50 UTC 2015 
>>> armv7l GNU/Linux
>>> 
>>>  Perhaps describing my exact steps might shed some light on my screw up?
>>> 
>>> 
>>> 
>>> This is the device tree I am testing with:
>>> 
>>> 
>>> 
>>> /* 
>>> snip for space
>>> */
>>> /dts-v1/;
>>> /plugin/;
>>> 
>>> /{
>>>compatible = "ti,beaglebone", "ti,beaglebone-black";
>>>part-number = "EBB-GPIO-Example";
>>>version = "00A0";
>>> 
>>>fragment@0 {
>>> 

Re: [beagleboard] Debian Overlay / Pinmux not working?

[William Hermans]

His overlay is in the first post John.

On Fri, Nov 27, 2015 at 5:07 PM, John Syne  wrote:

> One more thing, just defining pinmux in the overlay will have no effect.
> The pinmux will only be configured as part of installing the driver. Just
> before the kernel calls the driver probe function, it sets up the pinmux as
> defined by the pinctrl definition.
>
> Regards,
> John
>
>
>
>
> On Nov 27, 2015, at 3:58 PM, John Syne  wrote:
>
> GPIO MODE SETTINGS Bit 6 Bit 5 Bit 4 Bit 3 Bit 2,1,0 Slew Control Receiver
> Active Pullup/Pulldown Enable Pullup/down Mux Mode 0 Fast 0 Disable 0
> Pulldown select 0 Enabled 000 Mode 0 to 1 Enable 1 Pullup select 1
> Disabled 111 Mode 7   e.g. OUTPUT GPIO(mode7) 0x07 pulldown, 0x17 pullup,
> 0x?f no pullup/down e.g. INPUT GPIO(mode7) 0x27 pulldown, 0x37 pullup,
> 0x?f no pullup/down TRM Table 9-60
>
>
> From the table above, 0x27 in an input and 0x17 is an output. My guess is
> that there is some conflict that occurs and that is why the config isn’t
> set correctly. What does your overlay look like and what do you see when
> you install the overlay?
>
> Regards,
> John
>
>
>
>
> On Nov 27, 2015, at 1:03 PM, Riley Porter  wrote:
>
> William,
>
> Thanks.  This basically is exactly what I did reading johns reply.  I
> guess my main disconnect here is.  I can apply a device tree overlay that I
> make.  I see it "applied" in dmesg and in slots.  However the pinmux output
> from *cat /sys/kernel/debug/pinctrl/44e10800.pinmux/pins *continues to
> show 0x27 for their modes when I specifically set the dtc to 0x17.
>
> I have not actually tried to use it as an input in code yet.  Merely have
> been seeing that it is not "applying" what i thought it should.  Perhaps I
> am looking at the wrong pinoutput?
>
> for example P9_11's offset is 0x70 and its PIN value is 28.  So * | grep
> 870*
>
> root ~/bb.org-overlays # *cat
> /sys/kernel/debug/pinctrl/44e10800.pinmux/pins* | grep 870
> pin 28 (44e10870.0) 00*27* pinctrl-single
>
> which is not 0x17?
>
> I am being very wordy here just to make sure you guys know exactly what I
> am doing and my expectations.
>
>
> So does anything I am doing look wrong?
>
>
> Again thanks a bunch guys for the help.  I have been at this for the
> better part of a week now and I agree William it's a step in the WRONG
> direction going to Angstrom.
>
> ril3y
>
>
>
> On Fri, Nov 27, 2015 at 3:45 PM, William Hermans 
> wrote:
>
>> *Unfortunately the "answer" was to install angstrom.  I was hoping
>>> someone on the list would have some secret answer as to why applying an
>>> overlay was not changing the pinmux's?*
>>>
>>> *I would very much like to stick with debian but if the answer is go
>>> back angstrom I guess I can live with that.*
>>>
>>> *Thanks*
>>
>> You do not have to go back to Angstrom, and if you ask me that is very
>> counter productive. Read my guide here:
>> http://www.embeddedhobbyist.com/2015/09/beaglebone-black-updating-device-tree-files/
>>
>> Do note, that the kernel I talk about at the beginning is just an
>> example. You do not have to use the exact kernel I demonstrated. Any 4.x
>> kernel should work with that guide.
>>
>>
>> On Fri, Nov 27, 2015 at 1:14 PM, Riley Porter 
>> wrote:
>>
>>> Yes I am running:
>>>
>>> *Linux beaglebone 4.1.1-bone10 #1 Tue Jul 7 01:15:35 UTC 2015 armv7l
>>> GNU/Linux*
>>>
>>> I followed your instructions but still am at a loss.  I was able to
>>> update the device tree compiler and the kernel which is now:
>>>
>>> *Linux beaglebone 4.1.13-ti-r33 #1 SMP PREEMPT Fri Nov 20 11:00:50 UTC
>>> 2015 armv7l GNU/Linux*
>>>
>>>  Perhaps describing my exact steps might shed some light on my screw up?
>>>
>>>
>>> *This is the device tree I am testing with:*
>>>
>>>
>>> /*
 snip for space
 */
 /dts-v1/;
 /plugin/;

 /{
compatible = "ti,beaglebone", "ti,beaglebone-black";
part-number = "EBB-GPIO-Example";
version = "00A0";

fragment@0 {
  target = <&am33xx_pinmux>;


  __overlay__ {
   ebb_example: EBB_GPIO_Example {
 pinctrl-single,pins = <


 /*=  Inputs
 */
 0x070 0x17  // P9_11 PINS$28 GPIO0_30 =
 30 Input Mode7 pullup
 0x078 0x17  // P9_12 PINS$30 GPIO1_28 =
 60 Input Mode7 pullup
 0x074 0x17  // P9_13 PINS$29 GPIO0_31 =
 31 Input Mode7 pullup
 0x048 0x17  // P9_14 PINS$18 GPIO1_18 =
 50 Input Mode7 pullup
 0x040 0x17  // P9_15 PINS$16 GPIO1_16 =
 48 Input Mode7 pullup
 0x04c 0x17  // P9_16 PINS$19 GPIO1_19 =
 51 Input Mode7 pullup
 0x15c 0x17  // P9_17 PINS$87 GPIO0_5  =
  5 Input Mode7 pullup
 

Re: [beagleboard] Debian Overlay / Pinmux not working?

[William Hermans]

Err sorry his second post.

On Fri, Nov 27, 2015 at 5:26 PM, William Hermans  wrote:

> His overlay is in the first post John.
>
> On Fri, Nov 27, 2015 at 5:07 PM, John Syne  wrote:
>
>> One more thing, just defining pinmux in the overlay will have no effect.
>> The pinmux will only be configured as part of installing the driver. Just
>> before the kernel calls the driver probe function, it sets up the pinmux as
>> defined by the pinctrl definition.
>>
>> Regards,
>> John
>>
>>
>>
>>
>> On Nov 27, 2015, at 3:58 PM, John Syne  wrote:
>>
>> GPIO MODE SETTINGS Bit 6 Bit 5 Bit 4 Bit 3 Bit 2,1,0 Slew Control Receiver
>> Active Pullup/Pulldown Enable Pullup/down Mux Mode 0 Fast 0 Disable 0
>> Pulldown select 0 Enabled 000 Mode 0 to 1 Enable 1 Pullup select 1
>> Disabled 111 Mode 7   e.g. OUTPUT GPIO(mode7) 0x07 pulldown, 0x17
>> pullup, 0x?f no pullup/down e.g. INPUT GPIO(mode7) 0x27 pulldown, 0x37
>> pullup, 0x?f no pullup/down TRM Table 9-60
>>
>>
>> From the table above, 0x27 in an input and 0x17 is an output. My guess is
>> that there is some conflict that occurs and that is why the config isn’t
>> set correctly. What does your overlay look like and what do you see when
>> you install the overlay?
>>
>> Regards,
>> John
>>
>>
>>
>>
>> On Nov 27, 2015, at 1:03 PM, Riley Porter  wrote:
>>
>> William,
>>
>> Thanks.  This basically is exactly what I did reading johns reply.  I
>> guess my main disconnect here is.  I can apply a device tree overlay that I
>> make.  I see it "applied" in dmesg and in slots.  However the pinmux output
>> from *cat /sys/kernel/debug/pinctrl/44e10800.pinmux/pins *continues to
>> show 0x27 for their modes when I specifically set the dtc to 0x17.
>>
>> I have not actually tried to use it as an input in code yet.  Merely have
>> been seeing that it is not "applying" what i thought it should.  Perhaps I
>> am looking at the wrong pinoutput?
>>
>> for example P9_11's offset is 0x70 and its PIN value is 28.  So * | grep
>> 870*
>>
>> root ~/bb.org-overlays # *cat
>> /sys/kernel/debug/pinctrl/44e10800.pinmux/pins* | grep 870
>> pin 28 (44e10870.0) 00*27* pinctrl-single
>>
>> which is not 0x17?
>>
>> I am being very wordy here just to make sure you guys know exactly what I
>> am doing and my expectations.
>>
>>
>> So does anything I am doing look wrong?
>>
>>
>> Again thanks a bunch guys for the help.  I have been at this for the
>> better part of a week now and I agree William it's a step in the WRONG
>> direction going to Angstrom.
>>
>> ril3y
>>
>>
>>
>> On Fri, Nov 27, 2015 at 3:45 PM, William Hermans 
>> wrote:
>>
>>> *Unfortunately the "answer" was to install angstrom.  I was hoping
 someone on the list would have some secret answer as to why applying an
 overlay was not changing the pinmux's?*

 *I would very much like to stick with debian but if the answer is go
 back angstrom I guess I can live with that.*

 *Thanks*
>>>
>>> You do not have to go back to Angstrom, and if you ask me that is very
>>> counter productive. Read my guide here:
>>> http://www.embeddedhobbyist.com/2015/09/beaglebone-black-updating-device-tree-files/
>>>
>>> Do note, that the kernel I talk about at the beginning is just an
>>> example. You do not have to use the exact kernel I demonstrated. Any 4.x
>>> kernel should work with that guide.
>>>
>>>
>>> On Fri, Nov 27, 2015 at 1:14 PM, Riley Porter 
>>> wrote:
>>>
 Yes I am running:

 *Linux beaglebone 4.1.1-bone10 #1 Tue Jul 7 01:15:35 UTC 2015 armv7l
 GNU/Linux*

 I followed your instructions but still am at a loss.  I was able to
 update the device tree compiler and the kernel which is now:

 *Linux beaglebone 4.1.13-ti-r33 #1 SMP PREEMPT Fri Nov 20 11:00:50 UTC
 2015 armv7l GNU/Linux*

  Perhaps describing my exact steps might shed some light on my screw
 up?


 *This is the device tree I am testing with:*


 /*
> snip for space
> */
> /dts-v1/;
> /plugin/;
>
> /{
>compatible = "ti,beaglebone", "ti,beaglebone-black";
>part-number = "EBB-GPIO-Example";
>version = "00A0";
>
>fragment@0 {
>  target = <&am33xx_pinmux>;
>
>
>  __overlay__ {
>   ebb_example: EBB_GPIO_Example {
> pinctrl-single,pins = <
>
>
> /*=  Inputs
> */
> 0x070 0x17  // P9_11 PINS$28 GPIO0_30
> = 30 Input Mode7 pullup
> 0x078 0x17  // P9_12 PINS$30 GPIO1_28
> = 60 Input Mode7 pullup
> 0x074 0x17  // P9_13 PINS$29 GPIO0_31
> = 31 Input Mode7 pullup
> 0x048 0x17  // P9_14 PINS$18 GPIO1_18
> = 50 Input Mode7 pullup
> 0x040 0x17  // P9_15 PINS$16 GPIO1_16
> =

Re: [beagleboard] Debian Overlay / Pinmux not working?

[John Syne]

One more thing, just defining pinmux in the overlay will have no effect. The 
pinmux will only be configured as part of installing the driver. Just before 
the kernel calls the driver probe function, it sets up the pinmux as defined by 
the pinctrl definition. 

Regards,
John




> On Nov 27, 2015, at 3:58 PM, John Syne  wrote:
> 
> GPIO MODE SETTINGS
> Bit 6 Bit 5   Bit 4   Bit 3   Bit 2,1,0
> Slew Control  Receiver Active Pullup/Pulldown Enable Pullup/down  Mux Mode
> 0 Fast0 Disable   0 Pulldown select   0 Enabled   000 
> Mode 0 to
> 1 Enable  1 Pullup select 1 Disabled  111 Mode 7   
> e.g. OUTPUT GPIO(mode7) 0x07 pulldown, 0x17 pullup, 0x?f no pullup/down
> e.g. INPUT GPIO(mode7) 0x27 pulldown, 0x37 pullup, 0x?f no pullup/down
> TRM Table 9-60
> 
> 
> 
> From the table above, 0x27 in an input and 0x17 is an output. My guess is 
> that there is some conflict that occurs and that is why the config isn’t set 
> correctly. What does your overlay look like and what do you see when you 
> install the overlay?
> 
> Regards,
> John
> 
> 
> 
> 
>> On Nov 27, 2015, at 1:03 PM, Riley Porter > > wrote:
>> 
>> William,
>> 
>> Thanks.  This basically is exactly what I did reading johns reply.  I guess 
>> my main disconnect here is.  I can apply a device tree overlay that I make.  
>> I see it "applied" in dmesg and in slots.  However the pinmux output from 
>> cat /sys/kernel/debug/pinctrl/44e10800.pinmux/pins continues to show 0x27 
>> for their modes when I specifically set the dtc to 0x17.  
>> 
>> I have not actually tried to use it as an input in code yet.  Merely have 
>> been seeing that it is not "applying" what i thought it should.  Perhaps I 
>> am looking at the wrong pinoutput?
>> 
>> for example P9_11's offset is 0x70 and its PIN value is 28.  So  | grep 870
>> 
>> root ~/bb.org -overlays # cat 
>> /sys/kernel/debug/pinctrl/44e10800.pinmux/pins | grep 870
>> pin 28 (44e10870.0) 0027 pinctrl-single 
>> 
>> which is not 0x17?
>> 
>> I am being very wordy here just to make sure you guys know exactly what I am 
>> doing and my expectations.  
>> 
>> 
>> 
>> So does anything I am doing look wrong?
>> 
>> 
>> 
>> Again thanks a bunch guys for the help.  I have been at this for the better 
>> part of a week now and I agree William it's a step in the WRONG direction 
>> going to Angstrom.
>> 
>> ril3y
>> 
>> 
>> 
>> 
>> On Fri, Nov 27, 2015 at 3:45 PM, William Hermans > > wrote:
>> Unfortunately the "answer" was to install angstrom.  I was hoping someone on 
>> the list would have some secret answer as to why applying an overlay was not 
>> changing the pinmux's?
>> 
>> I would very much like to stick with debian but if the answer is go back 
>> angstrom I guess I can live with that.
>> 
>> Thanks
>> You do not have to go back to Angstrom, and if you ask me that is very 
>> counter productive. Read my guide here: 
>> http://www.embeddedhobbyist.com/2015/09/beaglebone-black-updating-device-tree-files/
>>  
>> 
>> 
>> Do note, that the kernel I talk about at the beginning is just an example. 
>> You do not have to use the exact kernel I demonstrated. Any 4.x kernel 
>> should work with that guide.
>> 
>> 
>> On Fri, Nov 27, 2015 at 1:14 PM, Riley Porter > > wrote:
>> Yes I am running:
>> Linux beaglebone 4.1.1-bone10 #1 Tue Jul 7 01:15:35 UTC 2015 armv7l GNU/Linux
>> 
>> I followed your instructions but still am at a loss.  I was able to update 
>> the device tree compiler and the kernel which is now:
>> 
>> Linux beaglebone 4.1.13-ti-r33 #1 SMP PREEMPT Fri Nov 20 11:00:50 UTC 2015 
>> armv7l GNU/Linux
>> 
>>  Perhaps describing my exact steps might shed some light on my screw up?
>> 
>> 
>> 
>> This is the device tree I am testing with:
>> 
>> 
>> 
>> /* 
>> snip for space
>> */
>> /dts-v1/;
>> /plugin/;
>> 
>> /{
>>compatible = "ti,beaglebone", "ti,beaglebone-black";
>>part-number = "EBB-GPIO-Example";
>>version = "00A0";
>> 
>>fragment@0 {
>>  target = <&am33xx_pinmux>;
>>
>> 
>>  __overlay__ {
>>   ebb_example: EBB_GPIO_Example {
>> pinctrl-single,pins = <
>> 
>> 
>> /*=  Inputs */
>> 0x070 0x17  // P9_11 PINS$28 GPIO0_30 = 30 
>> Input Mode7 pullup
>> 0x078 0x17  // P9_12 PINS$30 GPIO1_28 = 60 
>> Input Mode7 pullup
>> 0x074 0x17  // P9_13 PINS$29 GPIO0_31 = 31 
>> Input Mode7 pullup
>> 0x048 0x17  // P9_14 PINS$18 GPIO1_18 = 50 
>> Input Mode7 pullup
>> 0x040 0x17  // P9_15 PINS$16 GPIO1_16 = 48 
>> Input Mode7 pullup
>>   

Re: [beagleboard] Debian Overlay / Pinmux not working?

[John Syne]

GPIO MODE SETTINGS
Bit 6   Bit 5   Bit 4   Bit 3   Bit 2,1,0
Slew ControlReceiver Active Pullup/Pulldown Enable Pullup/down  Mux Mode
0 Fast  0 Disable   0 Pulldown select   0 Enabled   000 Mode 0 to
1 Enable1 Pullup select 1 Disabled  111 Mode 7   
e.g. OUTPUT GPIO(mode7) 0x07 pulldown, 0x17 pullup, 0x?f no pullup/down
e.g. INPUT GPIO(mode7) 0x27 pulldown, 0x37 pullup, 0x?f no pullup/down
TRM Table 9-60  



>From the table above, 0x27 in an input and 0x17 is an output. My guess is that 
>there is some conflict that occurs and that is why the config isn’t set 
>correctly. What does your overlay look like and what do you see when you 
>install the overlay?

Regards,
John




> On Nov 27, 2015, at 1:03 PM, Riley Porter  wrote:
> 
> William,
> 
> Thanks.  This basically is exactly what I did reading johns reply.  I guess 
> my main disconnect here is.  I can apply a device tree overlay that I make.  
> I see it "applied" in dmesg and in slots.  However the pinmux output from cat 
> /sys/kernel/debug/pinctrl/44e10800.pinmux/pins continues to show 0x27 for 
> their modes when I specifically set the dtc to 0x17.  
> 
> I have not actually tried to use it as an input in code yet.  Merely have 
> been seeing that it is not "applying" what i thought it should.  Perhaps I am 
> looking at the wrong pinoutput?
> 
> for example P9_11's offset is 0x70 and its PIN value is 28.  So  | grep 870
> 
> root ~/bb.org-overlays # cat /sys/kernel/debug/pinctrl/44e10800.pinmux/pins | 
> grep 870
> pin 28 (44e10870.0) 0027 pinctrl-single 
> 
> which is not 0x17?
> 
> I am being very wordy here just to make sure you guys know exactly what I am 
> doing and my expectations.  
> 
> 
> 
> So does anything I am doing look wrong?
> 
> 
> 
> Again thanks a bunch guys for the help.  I have been at this for the better 
> part of a week now and I agree William it's a step in the WRONG direction 
> going to Angstrom.
> 
> ril3y
> 
> 
> 
> 
> On Fri, Nov 27, 2015 at 3:45 PM, William Hermans  > wrote:
> Unfortunately the "answer" was to install angstrom.  I was hoping someone on 
> the list would have some secret answer as to why applying an overlay was not 
> changing the pinmux's?
> 
> I would very much like to stick with debian but if the answer is go back 
> angstrom I guess I can live with that.
> 
> Thanks
> You do not have to go back to Angstrom, and if you ask me that is very 
> counter productive. Read my guide here: 
> http://www.embeddedhobbyist.com/2015/09/beaglebone-black-updating-device-tree-files/
>  
> 
> 
> Do note, that the kernel I talk about at the beginning is just an example. 
> You do not have to use the exact kernel I demonstrated. Any 4.x kernel should 
> work with that guide.
> 
> 
> On Fri, Nov 27, 2015 at 1:14 PM, Riley Porter  > wrote:
> Yes I am running:
> Linux beaglebone 4.1.1-bone10 #1 Tue Jul 7 01:15:35 UTC 2015 armv7l GNU/Linux
> 
> I followed your instructions but still am at a loss.  I was able to update 
> the device tree compiler and the kernel which is now:
> 
> Linux beaglebone 4.1.13-ti-r33 #1 SMP PREEMPT Fri Nov 20 11:00:50 UTC 2015 
> armv7l GNU/Linux
> 
>  Perhaps describing my exact steps might shed some light on my screw up?
> 
> 
> 
> This is the device tree I am testing with:
> 
> 
> 
> /* 
> snip for space
> */
> /dts-v1/;
> /plugin/;
> 
> /{
>compatible = "ti,beaglebone", "ti,beaglebone-black";
>part-number = "EBB-GPIO-Example";
>version = "00A0";
> 
>fragment@0 {
>  target = <&am33xx_pinmux>;
>
> 
>  __overlay__ {
>   ebb_example: EBB_GPIO_Example {
> pinctrl-single,pins = <
> 
> 
> /*=  Inputs */
> 0x070 0x17  // P9_11 PINS$28 GPIO0_30 = 30 
> Input Mode7 pullup
> 0x078 0x17  // P9_12 PINS$30 GPIO1_28 = 60 
> Input Mode7 pullup
> 0x074 0x17  // P9_13 PINS$29 GPIO0_31 = 31 
> Input Mode7 pullup
> 0x048 0x17  // P9_14 PINS$18 GPIO1_18 = 50 
> Input Mode7 pullup
> 0x040 0x17  // P9_15 PINS$16 GPIO1_16 = 48 
> Input Mode7 pullup
> 0x04c 0x17  // P9_16 PINS$19 GPIO1_19 = 51 
> Input Mode7 pullup
> 0x15c 0x17  // P9_17 PINS$87 GPIO0_5  =  5 
> Input Mode7 pullup
> 0x158 0x17  // P9_18 PINS$86 GPIO0_4  =  4 
> Input Mode7 pullup
> 
> /* OUTPUT  GPIO(mode7) 0x07 pulldown, 0x17 
> pullup, 0x?f no pullup/down */
> /* INPUT   GPIO(mode7) 0x27 pulldown, 0x37 
> pullup, 0x?f no pullup/down */
> >;
>

Re: [beagleboard] Debian Overlay / Pinmux not working?

[William Hermans]

>
> *essentially, I think all that matter is the first 8 bits. Someone correct
> me here if I'm wrong.*
>

Never mind, my brain was off some where in la la land. Anyway . . . have
you check to see what mux 0x27 means versus 0x17 ?  For all I know the
pull-up bit field could be shifted left one bit( left most nibble ), which
is what the difference between 0x17, and 0x27 is.


On Fri, Nov 27, 2015 at 4:02 PM, William Hermans  wrote:

> essentially, I think all that matter is the first 8 bits. Someone correct
> me here if I'm wrong.
>
> On Fri, Nov 27, 2015 at 4:00 PM, William Hermans 
> wrote:
>
>> *Again thanks a bunch guys for the help.  I have been at this for the
>>> better part of a week now and I agree William it's a step in the WRONG
>>> direction going to Angstrom.*
>>>
>> I agree, and in fact, I've been a supporter of Robert's debian images
>> since long before they were official. Well, actually early on, I built my
>> own images based on his Debian on ARM guide.
>>
>>
>> *William,*
>>>
>>> *Thanks.  This basically is exactly what I did reading johns reply.  I
>> guess my main disconnect here is.  I can apply a device tree overlay that I
>> make.  I see it "applied" in dmesg and in slots.  However the pinmux output
>> from cat /sys/kernel/debug/pinctrl/44e10800.pinmux/pins **continues to
>> show 0x27 for their modes when I specifically set the dtc to 0x17.*
>>
>>
>> Ok, so let me say first that I'm no expert.*BUT* I've seen similar to
>> this when setting pin mode 0x7 on the USR LED "pins". In the debugfs pins/
>> directory as you mention above. When checked, over other one's pin mode
>> would be 0x17 so in effect . . .
>>
>> 0x7, 0x17, 0x7, 0x17. It stands to reason, that this is by design. How or
>> why, I'm not sure, but I've seen this many times over the last 3 or so
>> years. I've never looked into it however. So, with that said, perhaps this
>> is the same as your case. But of course, slightly different.
>>
>>
>>
>> On Fri, Nov 27, 2015 at 2:03 PM, Riley Porter 
>> wrote:
>>
>>> William,
>>>
>>> Thanks.  This basically is exactly what I did reading johns reply.  I
>>> guess my main disconnect here is.  I can apply a device tree overlay that I
>>> make.  I see it "applied" in dmesg and in slots.  However the pinmux output
>>> from *cat /sys/kernel/debug/pinctrl/44e10800.pinmux/pins *continues to
>>> show 0x27 for their modes when I specifically set the dtc to 0x17.
>>>
>>> I have not actually tried to use it as an input in code yet.  Merely
>>> have been seeing that it is not "applying" what i thought it should.
>>> Perhaps I am looking at the wrong pinoutput?
>>>
>>> for example P9_11's offset is 0x70 and its PIN value is 28.  So * |
>>> grep 870*
>>>
>>> root ~/bb.org-overlays # *cat
>>> /sys/kernel/debug/pinctrl/44e10800.pinmux/pins* | grep 870
>>> pin 28 (44e10870.0) 00*27* pinctrl-single
>>>
>>> which is not 0x17?
>>>
>>> I am being very wordy here just to make sure you guys know exactly what
>>> I am doing and my expectations.
>>>
>>>
>>> So does anything I am doing look wrong?
>>>
>>>
>>> Again thanks a bunch guys for the help.  I have been at this for the
>>> better part of a week now and I agree William it's a step in the WRONG
>>> direction going to Angstrom.
>>>
>>> ril3y
>>>
>>>
>>>
>>> On Fri, Nov 27, 2015 at 3:45 PM, William Hermans 
>>> wrote:
>>>
 *Unfortunately the "answer" was to install angstrom.  I was hoping
> someone on the list would have some secret answer as to why applying an
> overlay was not changing the pinmux's?*
>
> *I would very much like to stick with debian but if the answer is go
> back angstrom I guess I can live with that.*
>
> *Thanks*

 You do not have to go back to Angstrom, and if you ask me that is very
 counter productive. Read my guide here:
 http://www.embeddedhobbyist.com/2015/09/beaglebone-black-updating-device-tree-files/

 Do note, that the kernel I talk about at the beginning is just an
 example. You do not have to use the exact kernel I demonstrated. Any 4.x
 kernel should work with that guide.


 On Fri, Nov 27, 2015 at 1:14 PM, Riley Porter 
 wrote:

> Yes I am running:
>
> *Linux beaglebone 4.1.1-bone10 #1 Tue Jul 7 01:15:35 UTC 2015 armv7l
> GNU/Linux*
>
> I followed your instructions but still am at a loss.  I was able to
> update the device tree compiler and the kernel which is now:
>
> *Linux beaglebone 4.1.13-ti-r33 #1 SMP PREEMPT Fri Nov 20 11:00:50 UTC
> 2015 armv7l GNU/Linux*
>
>  Perhaps describing my exact steps might shed some light on my screw
> up?
>
>
> *This is the device tree I am testing with:*
>
>
> /*
>> snip for space
>> */
>> /dts-v1/;
>> /plugin/;
>>
>> /{
>>compatible = "ti,beaglebone", "ti,beaglebone-black";
>>part-number = "EBB-GPIO-Example";
>>version = "00A0";
>>
>>fragment@0 {
>

Re: [beagleboard] Debian Overlay / Pinmux not working?

[William Hermans]

essentially, I think all that matter is the first 8 bits. Someone correct
me here if I'm wrong.

On Fri, Nov 27, 2015 at 4:00 PM, William Hermans  wrote:

> *Again thanks a bunch guys for the help.  I have been at this for the
>> better part of a week now and I agree William it's a step in the WRONG
>> direction going to Angstrom.*
>>
> I agree, and in fact, I've been a supporter of Robert's debian images
> since long before they were official. Well, actually early on, I built my
> own images based on his Debian on ARM guide.
>
>
> *William,*
>>
>> *Thanks.  This basically is exactly what I did reading johns reply.  I
> guess my main disconnect here is.  I can apply a device tree overlay that I
> make.  I see it "applied" in dmesg and in slots.  However the pinmux output
> from cat /sys/kernel/debug/pinctrl/44e10800.pinmux/pins **continues to
> show 0x27 for their modes when I specifically set the dtc to 0x17.*
>
>
> Ok, so let me say first that I'm no expert.*BUT* I've seen similar to this
> when setting pin mode 0x7 on the USR LED "pins". In the debugfs pins/
> directory as you mention above. When checked, over other one's pin mode
> would be 0x17 so in effect . . .
>
> 0x7, 0x17, 0x7, 0x17. It stands to reason, that this is by design. How or
> why, I'm not sure, but I've seen this many times over the last 3 or so
> years. I've never looked into it however. So, with that said, perhaps this
> is the same as your case. But of course, slightly different.
>
>
>
> On Fri, Nov 27, 2015 at 2:03 PM, Riley Porter 
> wrote:
>
>> William,
>>
>> Thanks.  This basically is exactly what I did reading johns reply.  I
>> guess my main disconnect here is.  I can apply a device tree overlay that I
>> make.  I see it "applied" in dmesg and in slots.  However the pinmux output
>> from *cat /sys/kernel/debug/pinctrl/44e10800.pinmux/pins *continues to
>> show 0x27 for their modes when I specifically set the dtc to 0x17.
>>
>> I have not actually tried to use it as an input in code yet.  Merely have
>> been seeing that it is not "applying" what i thought it should.  Perhaps I
>> am looking at the wrong pinoutput?
>>
>> for example P9_11's offset is 0x70 and its PIN value is 28.  So * | grep
>> 870*
>>
>> root ~/bb.org-overlays # *cat
>> /sys/kernel/debug/pinctrl/44e10800.pinmux/pins* | grep 870
>> pin 28 (44e10870.0) 00*27* pinctrl-single
>>
>> which is not 0x17?
>>
>> I am being very wordy here just to make sure you guys know exactly what I
>> am doing and my expectations.
>>
>>
>> So does anything I am doing look wrong?
>>
>>
>> Again thanks a bunch guys for the help.  I have been at this for the
>> better part of a week now and I agree William it's a step in the WRONG
>> direction going to Angstrom.
>>
>> ril3y
>>
>>
>>
>> On Fri, Nov 27, 2015 at 3:45 PM, William Hermans 
>> wrote:
>>
>>> *Unfortunately the "answer" was to install angstrom.  I was hoping
 someone on the list would have some secret answer as to why applying an
 overlay was not changing the pinmux's?*

 *I would very much like to stick with debian but if the answer is go
 back angstrom I guess I can live with that.*

 *Thanks*
>>>
>>> You do not have to go back to Angstrom, and if you ask me that is very
>>> counter productive. Read my guide here:
>>> http://www.embeddedhobbyist.com/2015/09/beaglebone-black-updating-device-tree-files/
>>>
>>> Do note, that the kernel I talk about at the beginning is just an
>>> example. You do not have to use the exact kernel I demonstrated. Any 4.x
>>> kernel should work with that guide.
>>>
>>>
>>> On Fri, Nov 27, 2015 at 1:14 PM, Riley Porter 
>>> wrote:
>>>
 Yes I am running:

 *Linux beaglebone 4.1.1-bone10 #1 Tue Jul 7 01:15:35 UTC 2015 armv7l
 GNU/Linux*

 I followed your instructions but still am at a loss.  I was able to
 update the device tree compiler and the kernel which is now:

 *Linux beaglebone 4.1.13-ti-r33 #1 SMP PREEMPT Fri Nov 20 11:00:50 UTC
 2015 armv7l GNU/Linux*

  Perhaps describing my exact steps might shed some light on my screw
 up?


 *This is the device tree I am testing with:*


 /*
> snip for space
> */
> /dts-v1/;
> /plugin/;
>
> /{
>compatible = "ti,beaglebone", "ti,beaglebone-black";
>part-number = "EBB-GPIO-Example";
>version = "00A0";
>
>fragment@0 {
>  target = <&am33xx_pinmux>;
>
>
>  __overlay__ {
>   ebb_example: EBB_GPIO_Example {
> pinctrl-single,pins = <
>
>
> /*=  Inputs
> */
> 0x070 0x17  // P9_11 PINS$28 GPIO0_30
> = 30 Input Mode7 pullup
> 0x078 0x17  // P9_12 PINS$30 GPIO1_28
> = 60 Input Mode7 pullup
> 0x074 0x17  // P9_1

Re: [beagleboard] Debian Overlay / Pinmux not working?

[William Hermans]

*Again thanks a bunch guys for the help.  I have been at this for the
> better part of a week now and I agree William it's a step in the WRONG
> direction going to Angstrom.*
>
I agree, and in fact, I've been a supporter of Robert's debian images since
long before they were official. Well, actually early on, I built my own
images based on his Debian on ARM guide.


*William,*
>
> *Thanks.  This basically is exactly what I did reading johns reply.  I
guess my main disconnect here is.  I can apply a device tree overlay that I
make.  I see it "applied" in dmesg and in slots.  However the pinmux output
from cat /sys/kernel/debug/pinctrl/44e10800.pinmux/pins **continues to show
0x27 for their modes when I specifically set the dtc to 0x17.*


Ok, so let me say first that I'm no expert.*BUT* I've seen similar to this
when setting pin mode 0x7 on the USR LED "pins". In the debugfs pins/
directory as you mention above. When checked, over other one's pin mode
would be 0x17 so in effect . . .

0x7, 0x17, 0x7, 0x17. It stands to reason, that this is by design. How or
why, I'm not sure, but I've seen this many times over the last 3 or so
years. I've never looked into it however. So, with that said, perhaps this
is the same as your case. But of course, slightly different.



On Fri, Nov 27, 2015 at 2:03 PM, Riley Porter  wrote:

> William,
>
> Thanks.  This basically is exactly what I did reading johns reply.  I
> guess my main disconnect here is.  I can apply a device tree overlay that I
> make.  I see it "applied" in dmesg and in slots.  However the pinmux output
> from *cat /sys/kernel/debug/pinctrl/44e10800.pinmux/pins *continues to
> show 0x27 for their modes when I specifically set the dtc to 0x17.
>
> I have not actually tried to use it as an input in code yet.  Merely have
> been seeing that it is not "applying" what i thought it should.  Perhaps I
> am looking at the wrong pinoutput?
>
> for example P9_11's offset is 0x70 and its PIN value is 28.  So * | grep
> 870*
>
> root ~/bb.org-overlays # *cat
> /sys/kernel/debug/pinctrl/44e10800.pinmux/pins* | grep 870
> pin 28 (44e10870.0) 00*27* pinctrl-single
>
> which is not 0x17?
>
> I am being very wordy here just to make sure you guys know exactly what I
> am doing and my expectations.
>
>
> So does anything I am doing look wrong?
>
>
> Again thanks a bunch guys for the help.  I have been at this for the
> better part of a week now and I agree William it's a step in the WRONG
> direction going to Angstrom.
>
> ril3y
>
>
>
> On Fri, Nov 27, 2015 at 3:45 PM, William Hermans 
> wrote:
>
>> *Unfortunately the "answer" was to install angstrom.  I was hoping
>>> someone on the list would have some secret answer as to why applying an
>>> overlay was not changing the pinmux's?*
>>>
>>> *I would very much like to stick with debian but if the answer is go
>>> back angstrom I guess I can live with that.*
>>>
>>> *Thanks*
>>
>> You do not have to go back to Angstrom, and if you ask me that is very
>> counter productive. Read my guide here:
>> http://www.embeddedhobbyist.com/2015/09/beaglebone-black-updating-device-tree-files/
>>
>> Do note, that the kernel I talk about at the beginning is just an
>> example. You do not have to use the exact kernel I demonstrated. Any 4.x
>> kernel should work with that guide.
>>
>>
>> On Fri, Nov 27, 2015 at 1:14 PM, Riley Porter 
>> wrote:
>>
>>> Yes I am running:
>>>
>>> *Linux beaglebone 4.1.1-bone10 #1 Tue Jul 7 01:15:35 UTC 2015 armv7l
>>> GNU/Linux*
>>>
>>> I followed your instructions but still am at a loss.  I was able to
>>> update the device tree compiler and the kernel which is now:
>>>
>>> *Linux beaglebone 4.1.13-ti-r33 #1 SMP PREEMPT Fri Nov 20 11:00:50 UTC
>>> 2015 armv7l GNU/Linux*
>>>
>>>  Perhaps describing my exact steps might shed some light on my screw up?
>>>
>>>
>>> *This is the device tree I am testing with:*
>>>
>>>
>>> /*
 snip for space
 */
 /dts-v1/;
 /plugin/;

 /{
compatible = "ti,beaglebone", "ti,beaglebone-black";
part-number = "EBB-GPIO-Example";
version = "00A0";

fragment@0 {
  target = <&am33xx_pinmux>;


  __overlay__ {
   ebb_example: EBB_GPIO_Example {
 pinctrl-single,pins = <


 /*=  Inputs
 */
 0x070 0x17  // P9_11 PINS$28 GPIO0_30 =
 30 Input Mode7 pullup
 0x078 0x17  // P9_12 PINS$30 GPIO1_28 =
 60 Input Mode7 pullup
 0x074 0x17  // P9_13 PINS$29 GPIO0_31 =
 31 Input Mode7 pullup
 0x048 0x17  // P9_14 PINS$18 GPIO1_18 =
 50 Input Mode7 pullup
 0x040 0x17  // P9_15 PINS$16 GPIO1_16 =
 48 Input Mode7 pullup
 0x04c 0x17  // P9_16 PI

Re: [beagleboard] Debian Overlay / Pinmux not working?

[Riley Porter]

William,

Thanks.  This basically is exactly what I did reading johns reply.  I guess
my main disconnect here is.  I can apply a device tree overlay that I
make.  I see it "applied" in dmesg and in slots.  However the pinmux output
from *cat /sys/kernel/debug/pinctrl/44e10800.pinmux/pins *continues to show
0x27 for their modes when I specifically set the dtc to 0x17.

I have not actually tried to use it as an input in code yet.  Merely have
been seeing that it is not "applying" what i thought it should.  Perhaps I
am looking at the wrong pinoutput?

for example P9_11's offset is 0x70 and its PIN value is 28.  So * | grep
870*

root ~/bb.org-overlays # *cat
/sys/kernel/debug/pinctrl/44e10800.pinmux/pins* | grep 870
pin 28 (44e10870.0) 00*27* pinctrl-single

which is not 0x17?

I am being very wordy here just to make sure you guys know exactly what I
am doing and my expectations.


So does anything I am doing look wrong?


Again thanks a bunch guys for the help.  I have been at this for the better
part of a week now and I agree William it's a step in the WRONG direction
going to Angstrom.

ril3y



On Fri, Nov 27, 2015 at 3:45 PM, William Hermans  wrote:

> *Unfortunately the "answer" was to install angstrom.  I was hoping someone
>> on the list would have some secret answer as to why applying an overlay was
>> not changing the pinmux's?*
>>
>> *I would very much like to stick with debian but if the answer is go back
>> angstrom I guess I can live with that.*
>>
>> *Thanks*
>
> You do not have to go back to Angstrom, and if you ask me that is very
> counter productive. Read my guide here:
> http://www.embeddedhobbyist.com/2015/09/beaglebone-black-updating-device-tree-files/
>
> Do note, that the kernel I talk about at the beginning is just an example.
> You do not have to use the exact kernel I demonstrated. Any 4.x kernel
> should work with that guide.
>
>
> On Fri, Nov 27, 2015 at 1:14 PM, Riley Porter 
> wrote:
>
>> Yes I am running:
>>
>> *Linux beaglebone 4.1.1-bone10 #1 Tue Jul 7 01:15:35 UTC 2015 armv7l
>> GNU/Linux*
>>
>> I followed your instructions but still am at a loss.  I was able to
>> update the device tree compiler and the kernel which is now:
>>
>> *Linux beaglebone 4.1.13-ti-r33 #1 SMP PREEMPT Fri Nov 20 11:00:50 UTC
>> 2015 armv7l GNU/Linux*
>>
>>  Perhaps describing my exact steps might shed some light on my screw up?
>>
>>
>> *This is the device tree I am testing with:*
>>
>>
>> /*
>>> snip for space
>>> */
>>> /dts-v1/;
>>> /plugin/;
>>>
>>> /{
>>>compatible = "ti,beaglebone", "ti,beaglebone-black";
>>>part-number = "EBB-GPIO-Example";
>>>version = "00A0";
>>>
>>>fragment@0 {
>>>  target = <&am33xx_pinmux>;
>>>
>>>
>>>  __overlay__ {
>>>   ebb_example: EBB_GPIO_Example {
>>> pinctrl-single,pins = <
>>>
>>>
>>> /*=  Inputs
>>> */
>>> 0x070 0x17  // P9_11 PINS$28 GPIO0_30 =
>>> 30 Input Mode7 pullup
>>> 0x078 0x17  // P9_12 PINS$30 GPIO1_28 =
>>> 60 Input Mode7 pullup
>>> 0x074 0x17  // P9_13 PINS$29 GPIO0_31 =
>>> 31 Input Mode7 pullup
>>> 0x048 0x17  // P9_14 PINS$18 GPIO1_18 =
>>> 50 Input Mode7 pullup
>>> 0x040 0x17  // P9_15 PINS$16 GPIO1_16 =
>>> 48 Input Mode7 pullup
>>> 0x04c 0x17  // P9_16 PINS$19 GPIO1_19 =
>>> 51 Input Mode7 pullup
>>> 0x15c 0x17  // P9_17 PINS$87 GPIO0_5  =
>>>  5 Input Mode7 pullup
>>> 0x158 0x17  // P9_18 PINS$86 GPIO0_4  =
>>>  4 Input Mode7 pullup
>>>
>>> /* OUTPUT  GPIO(mode7) 0x07 pulldown,
>>> 0x17 pullup, 0x?f no pullup/down */
>>> /* INPUT   GPIO(mode7) 0x27 pulldown,
>>> 0x37 pullup, 0x?f no pullup/down */
>>> >;
>>>   };
>>>  };
>>>};
>>>
>>>fragment@1 {
>>> target = <&ocp>;
>>> __overlay__ {
>>> gpio_helper {
>>> compatible = "gpio-of-helper";
>>> status = "okay";
>>> pinctrl-names = "default";
>>> pinctrl-0 = <&ebb_example>;
>>> };
>>> };
>>> };
>>> };
>>
>>
>>
>> I also removed ALL overlays from my system before doing this below.
>> Here is my output from slots and a python program to get the pins i wrote:
>>
>> *root ~/bbb_stuff # **slots*
>>
>>
>>
>>
>> * 0: PF  -1  1: PF  -1  2: PF  -1  3: PF  -1  9: P-O-L-
>> 0 Override Board Name,00A0,Override Manuf,EBB-GPIO-Example*
>>
>> *root ~/bbb_stuff # ./getpins *
>>
>>
>>
>> *

Re: [beagleboard] Debian Overlay / Pinmux not working?

[William Hermans]

>
> *Unfortunately the "answer" was to install angstrom.  I was hoping someone
> on the list would have some secret answer as to why applying an overlay was
> not changing the pinmux's?*
>
> *I would very much like to stick with debian but if the answer is go back
> angstrom I guess I can live with that.*
>
> *Thanks*

You do not have to go back to Angstrom, and if you ask me that is very
counter productive. Read my guide here:
http://www.embeddedhobbyist.com/2015/09/beaglebone-black-updating-device-tree-files/

Do note, that the kernel I talk about at the beginning is just an example.
You do not have to use the exact kernel I demonstrated. Any 4.x kernel
should work with that guide.


On Fri, Nov 27, 2015 at 1:14 PM, Riley Porter  wrote:

> Yes I am running:
>
> *Linux beaglebone 4.1.1-bone10 #1 Tue Jul 7 01:15:35 UTC 2015 armv7l
> GNU/Linux*
>
> I followed your instructions but still am at a loss.  I was able to update
> the device tree compiler and the kernel which is now:
>
> *Linux beaglebone 4.1.13-ti-r33 #1 SMP PREEMPT Fri Nov 20 11:00:50 UTC
> 2015 armv7l GNU/Linux*
>
>  Perhaps describing my exact steps might shed some light on my screw up?
>
>
> *This is the device tree I am testing with:*
>
>
> /*
>> snip for space
>> */
>> /dts-v1/;
>> /plugin/;
>>
>> /{
>>compatible = "ti,beaglebone", "ti,beaglebone-black";
>>part-number = "EBB-GPIO-Example";
>>version = "00A0";
>>
>>fragment@0 {
>>  target = <&am33xx_pinmux>;
>>
>>
>>  __overlay__ {
>>   ebb_example: EBB_GPIO_Example {
>> pinctrl-single,pins = <
>>
>>
>> /*=  Inputs */
>> 0x070 0x17  // P9_11 PINS$28 GPIO0_30 =
>> 30 Input Mode7 pullup
>> 0x078 0x17  // P9_12 PINS$30 GPIO1_28 =
>> 60 Input Mode7 pullup
>> 0x074 0x17  // P9_13 PINS$29 GPIO0_31 =
>> 31 Input Mode7 pullup
>> 0x048 0x17  // P9_14 PINS$18 GPIO1_18 =
>> 50 Input Mode7 pullup
>> 0x040 0x17  // P9_15 PINS$16 GPIO1_16 =
>> 48 Input Mode7 pullup
>> 0x04c 0x17  // P9_16 PINS$19 GPIO1_19 =
>> 51 Input Mode7 pullup
>> 0x15c 0x17  // P9_17 PINS$87 GPIO0_5  =
>>  5 Input Mode7 pullup
>> 0x158 0x17  // P9_18 PINS$86 GPIO0_4  =
>>  4 Input Mode7 pullup
>>
>> /* OUTPUT  GPIO(mode7) 0x07 pulldown,
>> 0x17 pullup, 0x?f no pullup/down */
>> /* INPUT   GPIO(mode7) 0x27 pulldown,
>> 0x37 pullup, 0x?f no pullup/down */
>> >;
>>   };
>>  };
>>};
>>
>>fragment@1 {
>> target = <&ocp>;
>> __overlay__ {
>> gpio_helper {
>> compatible = "gpio-of-helper";
>> status = "okay";
>> pinctrl-names = "default";
>> pinctrl-0 = <&ebb_example>;
>> };
>> };
>> };
>> };
>
>
>
> I also removed ALL overlays from my system before doing this below.
> Here is my output from slots and a python program to get the pins i wrote:
>
> *root ~/bbb_stuff # **slots*
>
>
>
>
> * 0: PF  -1  1: PF  -1  2: PF  -1  3: PF  -1  9: P-O-L-
> 0 Override Board Name,00A0,Override Manuf,EBB-GPIO-Example*
>
> *root ~/bbb_stuff # ./getpins *
>
>
>
> *==Reading Pinux
> Pins==*
>
>
>
>
>
>
>
>
> *pin 16 (44e10840.0) 0027 pinctrl-singlepin 18 (44e10848.0) 0027
> pinctrl-singlepin 19 (44e1084c.0) 0027 pinctrl-singlepin 28
> (44e10870.0) 0017 pinctrl-singlepin 29 (44e10874.0) 0027
> pinctrl-singlepin 30 (44e10878.0) 0027 pinctrl-singlepin 86
> (44e10958.0) 0027 pinctrl-singlepin 87 (44e1095c.0) 0027
> pinctrl-single*
>
> You can clearly see I have requested them all to be 0x17?
>
> *Here are the alias's I am using:*
>
> *pins='cat /sys/kernel/debug/pinctrl/44e10800.pinmux/pins'**slots='cat
> /sys/devices/platform/bone_capemgr/slots'*
>
>
> *This is the command i used to compile the dt.*
> *dtc -O dtb -o EBB-GPIO-Example-00A0.dtbo -b 0 -@ EBB-GPIO-Example.dts*
>
> *This is the command I used to install it:*
> *echo  EBB-GPIO-Example-00A0 > "/sys/devices/platform/bone_capemgr/slots"*
>
>
> *This is the dmesg output after installing the overlay:*
>
>
>
>
>
>
> *[ 2629.259630] bone_capemgr bone_capemgr: part_number
> 'EBB-GPIO-Example-00A0', version 'N/A'[ 2629.259679] bone_capemgr
> bone_capemgr: slot #11: override[ 2629.259700] bone_capemgr bone_capemgr:
> Using override eeprom data at slot 11[ 2629.259722] bone_capemgr
> bone_capemgr: slot #11: 'Over

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

[gnu gnu]

yes it does 
thanks for help.

regards
nagla

On Thursday, November 26, 2015 at 3:29:37 AM UTC+5:30, RobertCNelson wrote:
>
> On Wed, Nov 25, 2015 at 3:52 PM, gnu gnu > 
> wrote: 
> > sorry, but I do not seem to understand your point here. 
> > 
> > Do you mean I can not use earlyprintk and low level bootup messages on 
> BBB? 
> > Or since the kernel is multiplatform, so you can not possibly decide 
> which 
> > platform it'll be used and enable that particular early console. 
> > 
> > But as a user should not I have option ? I just want to know which uart 
> port 
> > option I can use for BBB. Possibly : DEBUG_AM33XXUART1 ? 
>
> Sure give that config a shot.. 
>
> Regards, 
>
> -- 
> Robert Nelson 
> https://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] Debian Overlay / Pinmux not working?

[Riley Porter]

Yes I am running:

*Linux beaglebone 4.1.1-bone10 #1 Tue Jul 7 01:15:35 UTC 2015 armv7l
GNU/Linux*

I followed your instructions but still am at a loss.  I was able to update
the device tree compiler and the kernel which is now:

*Linux beaglebone 4.1.13-ti-r33 #1 SMP PREEMPT Fri Nov 20 11:00:50 UTC 2015
armv7l GNU/Linux*

 Perhaps describing my exact steps might shed some light on my screw up?


*This is the device tree I am testing with:*


/*
> snip for space
> */
> /dts-v1/;
> /plugin/;
>
> /{
>compatible = "ti,beaglebone", "ti,beaglebone-black";
>part-number = "EBB-GPIO-Example";
>version = "00A0";
>
>fragment@0 {
>  target = <&am33xx_pinmux>;
>
>
>  __overlay__ {
>   ebb_example: EBB_GPIO_Example {
> pinctrl-single,pins = <
>
>
> /*=  Inputs */
> 0x070 0x17  // P9_11 PINS$28 GPIO0_30 = 30
> Input Mode7 pullup
> 0x078 0x17  // P9_12 PINS$30 GPIO1_28 = 60
> Input Mode7 pullup
> 0x074 0x17  // P9_13 PINS$29 GPIO0_31 = 31
> Input Mode7 pullup
> 0x048 0x17  // P9_14 PINS$18 GPIO1_18 = 50
> Input Mode7 pullup
> 0x040 0x17  // P9_15 PINS$16 GPIO1_16 = 48
> Input Mode7 pullup
> 0x04c 0x17  // P9_16 PINS$19 GPIO1_19 = 51
> Input Mode7 pullup
> 0x15c 0x17  // P9_17 PINS$87 GPIO0_5  =  5
> Input Mode7 pullup
> 0x158 0x17  // P9_18 PINS$86 GPIO0_4  =  4
> Input Mode7 pullup
>
> /* OUTPUT  GPIO(mode7) 0x07 pulldown, 0x17
> pullup, 0x?f no pullup/down */
> /* INPUT   GPIO(mode7) 0x27 pulldown, 0x37
> pullup, 0x?f no pullup/down */
> >;
>   };
>  };
>};
>
>fragment@1 {
> target = <&ocp>;
> __overlay__ {
> gpio_helper {
> compatible = "gpio-of-helper";
> status = "okay";
> pinctrl-names = "default";
> pinctrl-0 = <&ebb_example>;
> };
> };
> };
> };



I also removed ALL overlays from my system before doing this below.
Here is my output from slots and a python program to get the pins i wrote:

*root ~/bbb_stuff # **slots*




* 0: PF  -1  1: PF  -1  2: PF  -1  3: PF  -1  9: P-O-L-   0
Override Board Name,00A0,Override Manuf,EBB-GPIO-Example*

*root ~/bbb_stuff # ./getpins *



*==Reading Pinux
Pins==*








*pin 16 (44e10840.0) 0027 pinctrl-singlepin 18 (44e10848.0) 0027
pinctrl-singlepin 19 (44e1084c.0) 0027 pinctrl-singlepin 28
(44e10870.0) 0017 pinctrl-singlepin 29 (44e10874.0) 0027
pinctrl-singlepin 30 (44e10878.0) 0027 pinctrl-singlepin 86
(44e10958.0) 0027 pinctrl-singlepin 87 (44e1095c.0) 0027
pinctrl-single*

You can clearly see I have requested them all to be 0x17?

*Here are the alias's I am using:*

*pins='cat /sys/kernel/debug/pinctrl/44e10800.pinmux/pins'**slots='cat
/sys/devices/platform/bone_capemgr/slots'*


*This is the command i used to compile the dt.*
*dtc -O dtb -o EBB-GPIO-Example-00A0.dtbo -b 0 -@ EBB-GPIO-Example.dts*

*This is the command I used to install it:*
*echo  EBB-GPIO-Example-00A0 > "/sys/devices/platform/bone_capemgr/slots"*


*This is the dmesg output after installing the overlay:*






*[ 2629.259630] bone_capemgr bone_capemgr: part_number
'EBB-GPIO-Example-00A0', version 'N/A'[ 2629.259679] bone_capemgr
bone_capemgr: slot #11: override[ 2629.259700] bone_capemgr bone_capemgr:
Using override eeprom data at slot 11[ 2629.259722] bone_capemgr
bone_capemgr: slot #11: 'Override Board Name,00A0,Override
Manuf,EBB-GPIO-Example'[ 2629.271307] gpio-of-helper ocp:gpio_helper:
ready[ 2629.271555] bone_capemgr bone_capemgr: slot #11: dtbo
'EBB-GPIO-Example-00A0.dtbo' loaded; overlay id #0*



So any help guys would be really appreciated!  I am thinking that I must be
just doing something wrong.  Perhaps the example device tree I am using is
outdated?  Would someone be willing to share with me a GPIO device tree
that works with kernel 4.1?  Also I have tried the dt builder online:

http://kilobaser.com/blog/2014-07-28-beaglebone-black-devicetreeoverlay-generator#1gpiodto

But this seems to not work also.  Thanks again everyone.


Riley

On Thu, Nov 26, 2015 at 2:13 PM, John Syne  wrote:

> That is strange because it seems to be working for everyone else. What is
> your kernel version?
>
> If you are using kernel version 4.1 or higher, then do the following on
> your BBB
>
> git clone htt

Re: [beagleboard] kernel updates thread

[dinuxbg]

One more URL with examples: 
https://github.com/dinuxbg/pru-software-support-package . This is a fork of 
the TI PRU Traning that is ported to GCC. So far lab5 is finished and was 
tested successfully on RCN's 2015-11-15 image (kernel 4.1.13-ti-r30).

понеделник, 2 ноември 2015 г., 23:35:42 UTC+2, RobertCNelson написа:
>
> On Mon, Nov 2, 2015 at 3:31 PM, William Hermans  > wrote: 
> > John, 
> > 
> > Not an argument so much as a concern . . . those hands-on labs are 
> specific 
> > to CCS, with no clear way of proceeding otherwise. e.g. I'd much prefer 
> a 
> > GNU approach. But I'll gloss over those labs yet again . . . and read 
> what 
> > other information is out there to see if this can be done with a gcc 
> > toolchain. 
> > 
> > CCS is a fine IDE, and set of tools, but not everyone has the need, or 
> even 
> > want / capability to use such a tool. 
>
> The ti-pru compiler is available by default in the beagleboard.org 
> images..  So ccs project's just be transferable/buildable on the 
> beagle.. 
>
> btw, the pru gnu examples are here, and i've gotten a patch from it's 
> author, so they should also be working in v4.1.x ;) 
>
> https://github.com/dinuxbg/pru-gcc-examples 
>
> Regards, 
>
> -- 
> Robert Nelson 
> https://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] HW Timestamping on beaglebone black

[John Syne]

Everyone is making the transition to PRU RemoteProc/RPMSG. Look at 
samples/rpmsg for an example of how to communicate between Linux and PRU. 
Instructions on how to build the 4.1 kernel:

https://eewiki.net/display/linuxonarm/BeagleBone+Black#BeagleBoneBlack-LinuxKernel
 


Follow TI-BSP instructions.
 
Regards,
John




> On Nov 27, 2015, at 2:28 AM, hllpc  wrote:
> 
> Hi John,
> thanks for the infos. The problem is that I need to use the PRUSS, right now 
> my bbb runs a 3.8.13 kernel with pru support and I've read here 
> 
>  that the newest versions could be a bit problematic on this front. But I 
> won't need the TI PRU cape support so maybe just building the kernel would be 
> fine, I still need to do a bit of googling about this.
> 
> Thanks again!
> 
> Il giorno giovedì 26 novembre 2015 22:40:17 UTC+1, john3909 ha scritto:
> BTW, CPTS and PTP_1588_CLOCK are enabled in the ti-linux-kernel-dev repo, so 
> if you use 4.1.13-ti-r34, you have everything you need. Now if you look in 
> drivers’ptp you will find code for PTP. Not sure if any of this will work on 
> the BBB, but it is a good place to start. 
> 
> Regards, 
> John 
> 
> 
> 
> 
> > On Nov 26, 2015, at 11:55 AM, hllpc > 
> > wrote: 
> > 
> > Hi John, 
> > strangely enough I haven't found anything specific for the bbb, I was 
> > thinking about using linuxptp (which allow both sw and hw timestamping). 
> > The only reference I've found is hete in the forum (   
> > https://groups.google.com/forum/m/#!topic/beagleboard/QHXb2hm72A8 
> >  ) and 
> > it seems like i have to enable the CPTS driver on the bbb, but i've no idea 
> > how to do it! I was hoping in any kind advice from the community! 
> > 
> > -- 
> > 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 
> > . 
> 
> 
> -- 
> 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: Not able to boot via SD Card in my beaglebone black element14

[Madhukar Sah]

I have beaglebone black element14 rev C.
Is there any problem in rev C related to booting from SDcard?


On Fri, Nov 27, 2015 at 7:16 PM, Madhukar Sah  wrote:

> I also did all the instruction give at 
> *http://www.armhf.com/boards/beaglebone-black/bbb-sd-install/
>  *except i
> gave the boot partition type as *'c(W95 FAT32 (LBA)'* rather than *'e(W95
> FAT16 (LBA))'*
>
> That did not work as well.
>
>
>
> Regards,
> Madhukar Sah
>
> On Fri, Nov 27, 2015 at 7:10 PM, Madhukar Sah 
> wrote:
>
>> I followed the above given site instructions but that failed as well.
>> Steps followed according to
>> https://eewiki.net/display/linuxonarm/BeagleBone+Black#BeagleBoneBlack-SetupmicroSDcard
>>
>> 
>> 1. Cross compiler set-up
>>
>>   ~/prakash-bbb$ wget -c
>> https://releases.linaro.org/14.09/components/toolchain/binaries/gcc-linaro-arm-linux-gnueabihf-4.9-2014.09_linux.tar.xz
>>   ~/prakash-bbb$ tar xf
>> gcc-linaro-arm-linux-gnueabihf-4.9-2014.09_linux.tar.xz
>>   ~/prakash-bbb$ export
>> CC=`pwd`/gcc-linaro-arm-linux-gnueabihf-4.9-2014.09_linux/bin/arm-linux-gnueabihf-
>>
>>   ~/prakash-bbb$ ${CC}gcc --version
>>   arm-linux-gnueabihf-gcc (crosstool-NG linaro-1.13.1-4.9-2014.09 -
>> Linaro GCC 4.9-2014.09) 4.9.2 20140904 (prerelease)
>>   Copyright (C) 2014 Free Software Foundation, Inc.
>>   This is free software; see the source for copying conditions.  There is
>> NO
>>   warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR
>> PURPOSE.
>>
>> 2. Bootloader
>>
>>   ~/prakash-bbb$ git clone git://git.denx.de/u-boot.git
>>   ~/prakash-bbb$ cd u-boot/
>>   ~/prakash-bbb$ git checkout v2015.10 -b tmp
>>
>>   ~/prakash-bbb$ wget -c
>> https://rcn-ee.com/repos/git/u-boot-patches/v2015.10/0001-am335x_evm-uEnv.txt-bootz-n-fixes.patch
>>
>>   ~/prakash-bbb$ patch -p1 < 0001-am335x_evm-uEnv.txt-bootz-n-fixes.patch
>>
>>   ~/prakash-bbb$ make ARCH=arm CROSS_COMPILE=${CC} distclean
>>   ~/prakash-bbb$ make ARCH=arm CROSS_COMPILE=${CC} am335x_evm_defconfig
>>   ~/prakash-bbb$ make ARCH=arm CROSS_COMPILE=${CC}
>>
>> 3. Linux Kernel
>>
>>   ~/prakash-bbb$ git clone https://github.com/RobertCNelson/bb-kernel
>>   ~/prakash-bbb$ cd bb-kernel/
>>   ~/prakash-bbb$ ./build_kernel.sh
>>   -
>>   Script Complete
>>   eewiki.net: [user@localhost:~$ export kernel_version=4.1.13-bone16]
>>   -
>>
>>
>> 4. Setup Micro SD card
>>
>>  ~/prakash-bbb$ lsblk
>> NAME   MAJ:MIN RM   SIZE RO TYPE MOUNTPOINT
>> sda  8:00 298.1G  0 disk
>> ├─sda1   8:10  30.2G  0 part
>> ├─sda2   8:20 1K  0 part
>> ├─sda5   8:50   7.5G  0 part [SWAP]
>> ├─sda6   8:60 127.2G  0 part
>> ├─sda7   8:70   7.5G  0 part [SWAP]
>> └─sda8   8:80 125.8G  0 part /
>> sdb  8:16   1   3.7G  0 disk
>> └─sdb1   8:17   1   3.7G  0 part
>>
>> ~/prakash-bbb$ export DISK=/dev/sdb
>>
>> ~/prakash-bbb$ sudo dd if=/dev/zero of=${DISK} bs=1M count=10
>> [sudo] password for utl:
>> 10+0 records in
>> 10+0 records out
>> 10485760 bytes (10 MB) copied, 2.97229 s, 3.5 MB/s
>>
>> ~/prakash-bbb$ sudo dd if=./u-boot/MLO of=${DISK} count=1 seek=1 bs=128k
>> 0+1 records in
>> 0+1 records out
>> 65812 bytes (66 kB) copied, 0.0452465 s, 1.5 MB/s
>>
>> ~/prakash-bbb$ sudo dd if=./u-boot/u-boot.img of=${DISK} count=2 seek=1
>> bs=384k
>> 0+1 records in
>> 0+1 records out
>> 318004 bytes (318 kB) copied, 0.0554741 s, 5.7 MB/s
>>
>> ~/prakash-bbb$ sudo sfdisk --version
>> sfdisk from util-linux 2.20.1
>>
>> ~/prakash-bbb$ sudo sfdisk --in-order --Linux --unit M ${DISK} <<-__EOF__
>> > 1,,L,*
>> > __EOF__
>>
>> Checking that no-one is using this disk right now ...
>> OK
>>
>> Disk /dev/sdb: 1017 cylinders, 124 heads, 62 sectors/track
>>
>> sfdisk: ERROR: sector 0 does not have an msdos signature
>>  /dev/sdb: unrecognized partition table type
>> Old situation:
>> No partitions found
>> New situation:
>> Warning: The partition table looks like it was made
>>   for C/H/S=*/43/12 (instead of 1017/124/62).
>> For this listing I'll assume that geometry.
>> Units = mebibytes of 1048576 bytes, blocks of 1024 bytes, counting from 0
>>
>>Device Boot Start   EndMiB#blocks   Id  System
>> /dev/sdb1   * 1   3818   38183909632   83  Linux
>> start: (c,h,s) expected (3,41,9) found (0,33,3)
>> end: (c,h,s) expected (1023,42,12) found (1017,42,12)
>> /dev/sdb2 0  -  0  00  Empty
>> /dev/sdb3 0  -  0  00  Empty
>> /dev/sdb4 0  -  0  00  Empty
>> Successfully wrote the new partition table
>>
>> Re-reading the partition table ...
>>
>> If you created or changed a DOS partition, /dev/foo7, say, then use dd(1)
>> to zero the first 512 bytes:  dd if=/dev/zero o

Re: [beagleboard] Re: Not able to boot via SD Card in my beaglebone black element14

[Madhukar Sah]

I also did all the instruction give at
*http://www.armhf.com/boards/beaglebone-black/bbb-sd-install/
 *except i
gave the boot partition type as *'c(W95 FAT32 (LBA)'* rather than *'e(W95
FAT16 (LBA))'*

That did not work as well.



Regards,
Madhukar Sah

On Fri, Nov 27, 2015 at 7:10 PM, Madhukar Sah  wrote:

> I followed the above given site instructions but that failed as well.
> Steps followed according to
> https://eewiki.net/display/linuxonarm/BeagleBone+Black#BeagleBoneBlack-SetupmicroSDcard
>
> 
> 1. Cross compiler set-up
>
>   ~/prakash-bbb$ wget -c
> https://releases.linaro.org/14.09/components/toolchain/binaries/gcc-linaro-arm-linux-gnueabihf-4.9-2014.09_linux.tar.xz
>   ~/prakash-bbb$ tar xf
> gcc-linaro-arm-linux-gnueabihf-4.9-2014.09_linux.tar.xz
>   ~/prakash-bbb$ export
> CC=`pwd`/gcc-linaro-arm-linux-gnueabihf-4.9-2014.09_linux/bin/arm-linux-gnueabihf-
>
>   ~/prakash-bbb$ ${CC}gcc --version
>   arm-linux-gnueabihf-gcc (crosstool-NG linaro-1.13.1-4.9-2014.09 - Linaro
> GCC 4.9-2014.09) 4.9.2 20140904 (prerelease)
>   Copyright (C) 2014 Free Software Foundation, Inc.
>   This is free software; see the source for copying conditions.  There is
> NO
>   warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR
> PURPOSE.
>
> 2. Bootloader
>
>   ~/prakash-bbb$ git clone git://git.denx.de/u-boot.git
>   ~/prakash-bbb$ cd u-boot/
>   ~/prakash-bbb$ git checkout v2015.10 -b tmp
>
>   ~/prakash-bbb$ wget -c
> https://rcn-ee.com/repos/git/u-boot-patches/v2015.10/0001-am335x_evm-uEnv.txt-bootz-n-fixes.patch
>
>   ~/prakash-bbb$ patch -p1 < 0001-am335x_evm-uEnv.txt-bootz-n-fixes.patch
>
>   ~/prakash-bbb$ make ARCH=arm CROSS_COMPILE=${CC} distclean
>   ~/prakash-bbb$ make ARCH=arm CROSS_COMPILE=${CC} am335x_evm_defconfig
>   ~/prakash-bbb$ make ARCH=arm CROSS_COMPILE=${CC}
>
> 3. Linux Kernel
>
>   ~/prakash-bbb$ git clone https://github.com/RobertCNelson/bb-kernel
>   ~/prakash-bbb$ cd bb-kernel/
>   ~/prakash-bbb$ ./build_kernel.sh
>   -
>   Script Complete
>   eewiki.net: [user@localhost:~$ export kernel_version=4.1.13-bone16]
>   -
>
>
> 4. Setup Micro SD card
>
>  ~/prakash-bbb$ lsblk
> NAME   MAJ:MIN RM   SIZE RO TYPE MOUNTPOINT
> sda  8:00 298.1G  0 disk
> ├─sda1   8:10  30.2G  0 part
> ├─sda2   8:20 1K  0 part
> ├─sda5   8:50   7.5G  0 part [SWAP]
> ├─sda6   8:60 127.2G  0 part
> ├─sda7   8:70   7.5G  0 part [SWAP]
> └─sda8   8:80 125.8G  0 part /
> sdb  8:16   1   3.7G  0 disk
> └─sdb1   8:17   1   3.7G  0 part
>
> ~/prakash-bbb$ export DISK=/dev/sdb
>
> ~/prakash-bbb$ sudo dd if=/dev/zero of=${DISK} bs=1M count=10
> [sudo] password for utl:
> 10+0 records in
> 10+0 records out
> 10485760 bytes (10 MB) copied, 2.97229 s, 3.5 MB/s
>
> ~/prakash-bbb$ sudo dd if=./u-boot/MLO of=${DISK} count=1 seek=1 bs=128k
> 0+1 records in
> 0+1 records out
> 65812 bytes (66 kB) copied, 0.0452465 s, 1.5 MB/s
>
> ~/prakash-bbb$ sudo dd if=./u-boot/u-boot.img of=${DISK} count=2 seek=1
> bs=384k
> 0+1 records in
> 0+1 records out
> 318004 bytes (318 kB) copied, 0.0554741 s, 5.7 MB/s
>
> ~/prakash-bbb$ sudo sfdisk --version
> sfdisk from util-linux 2.20.1
>
> ~/prakash-bbb$ sudo sfdisk --in-order --Linux --unit M ${DISK} <<-__EOF__
> > 1,,L,*
> > __EOF__
>
> Checking that no-one is using this disk right now ...
> OK
>
> Disk /dev/sdb: 1017 cylinders, 124 heads, 62 sectors/track
>
> sfdisk: ERROR: sector 0 does not have an msdos signature
>  /dev/sdb: unrecognized partition table type
> Old situation:
> No partitions found
> New situation:
> Warning: The partition table looks like it was made
>   for C/H/S=*/43/12 (instead of 1017/124/62).
> For this listing I'll assume that geometry.
> Units = mebibytes of 1048576 bytes, blocks of 1024 bytes, counting from 0
>
>Device Boot Start   EndMiB#blocks   Id  System
> /dev/sdb1   * 1   3818   38183909632   83  Linux
> start: (c,h,s) expected (3,41,9) found (0,33,3)
> end: (c,h,s) expected (1023,42,12) found (1017,42,12)
> /dev/sdb2 0  -  0  00  Empty
> /dev/sdb3 0  -  0  00  Empty
> /dev/sdb4 0  -  0  00  Empty
> Successfully wrote the new partition table
>
> Re-reading the partition table ...
>
> If you created or changed a DOS partition, /dev/foo7, say, then use dd(1)
> to zero the first 512 bytes:  dd if=/dev/zero of=/dev/foo7 bs=512 count=1
> (See fdisk(8).)
>
> ~/prakash-bbb$ sudo mkfs.ext4 ${DISK}1 -L rootfs
>
> ~/prakash-bbb$ sudo mkfs.ext4 ${DISK}1 -L rootfs
> mke2fs 1.42 (29-Nov-2011)
> Filesystem label=rootfs
> OS type: Linux
> Block size=4096 (log=2)
> Fragment size=4096 (log=2)
> Stride=0 blocks, Stripe w

Re: [beagleboard] Re: Not able to boot via SD Card in my beaglebone black element14

[Madhukar Sah]

I followed the above given site instructions but that failed as well.
Steps followed according to
https://eewiki.net/display/linuxonarm/BeagleBone+Black#BeagleBoneBlack-SetupmicroSDcard

1. Cross compiler set-up

  ~/prakash-bbb$ wget -c
https://releases.linaro.org/14.09/components/toolchain/binaries/gcc-linaro-arm-linux-gnueabihf-4.9-2014.09_linux.tar.xz
  ~/prakash-bbb$ tar xf
gcc-linaro-arm-linux-gnueabihf-4.9-2014.09_linux.tar.xz
  ~/prakash-bbb$ export
CC=`pwd`/gcc-linaro-arm-linux-gnueabihf-4.9-2014.09_linux/bin/arm-linux-gnueabihf-

  ~/prakash-bbb$ ${CC}gcc --version
  arm-linux-gnueabihf-gcc (crosstool-NG linaro-1.13.1-4.9-2014.09 - Linaro
GCC 4.9-2014.09) 4.9.2 20140904 (prerelease)
  Copyright (C) 2014 Free Software Foundation, Inc.
  This is free software; see the source for copying conditions.  There is NO
  warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR
PURPOSE.

2. Bootloader

  ~/prakash-bbb$ git clone git://git.denx.de/u-boot.git
  ~/prakash-bbb$ cd u-boot/
  ~/prakash-bbb$ git checkout v2015.10 -b tmp

  ~/prakash-bbb$ wget -c
https://rcn-ee.com/repos/git/u-boot-patches/v2015.10/0001-am335x_evm-uEnv.txt-bootz-n-fixes.patch

  ~/prakash-bbb$ patch -p1 < 0001-am335x_evm-uEnv.txt-bootz-n-fixes.patch

  ~/prakash-bbb$ make ARCH=arm CROSS_COMPILE=${CC} distclean
  ~/prakash-bbb$ make ARCH=arm CROSS_COMPILE=${CC} am335x_evm_defconfig
  ~/prakash-bbb$ make ARCH=arm CROSS_COMPILE=${CC}

3. Linux Kernel

  ~/prakash-bbb$ git clone https://github.com/RobertCNelson/bb-kernel
  ~/prakash-bbb$ cd bb-kernel/
  ~/prakash-bbb$ ./build_kernel.sh
  -
  Script Complete
  eewiki.net: [user@localhost:~$ export kernel_version=4.1.13-bone16]
  -


4. Setup Micro SD card

 ~/prakash-bbb$ lsblk
NAME   MAJ:MIN RM   SIZE RO TYPE MOUNTPOINT
sda  8:00 298.1G  0 disk
├─sda1   8:10  30.2G  0 part
├─sda2   8:20 1K  0 part
├─sda5   8:50   7.5G  0 part [SWAP]
├─sda6   8:60 127.2G  0 part
├─sda7   8:70   7.5G  0 part [SWAP]
└─sda8   8:80 125.8G  0 part /
sdb  8:16   1   3.7G  0 disk
└─sdb1   8:17   1   3.7G  0 part

~/prakash-bbb$ export DISK=/dev/sdb

~/prakash-bbb$ sudo dd if=/dev/zero of=${DISK} bs=1M count=10
[sudo] password for utl:
10+0 records in
10+0 records out
10485760 bytes (10 MB) copied, 2.97229 s, 3.5 MB/s

~/prakash-bbb$ sudo dd if=./u-boot/MLO of=${DISK} count=1 seek=1 bs=128k
0+1 records in
0+1 records out
65812 bytes (66 kB) copied, 0.0452465 s, 1.5 MB/s

~/prakash-bbb$ sudo dd if=./u-boot/u-boot.img of=${DISK} count=2 seek=1
bs=384k
0+1 records in
0+1 records out
318004 bytes (318 kB) copied, 0.0554741 s, 5.7 MB/s

~/prakash-bbb$ sudo sfdisk --version
sfdisk from util-linux 2.20.1

~/prakash-bbb$ sudo sfdisk --in-order --Linux --unit M ${DISK} <<-__EOF__
> 1,,L,*
> __EOF__

Checking that no-one is using this disk right now ...
OK

Disk /dev/sdb: 1017 cylinders, 124 heads, 62 sectors/track

sfdisk: ERROR: sector 0 does not have an msdos signature
 /dev/sdb: unrecognized partition table type
Old situation:
No partitions found
New situation:
Warning: The partition table looks like it was made
  for C/H/S=*/43/12 (instead of 1017/124/62).
For this listing I'll assume that geometry.
Units = mebibytes of 1048576 bytes, blocks of 1024 bytes, counting from 0

   Device Boot Start   EndMiB#blocks   Id  System
/dev/sdb1   * 1   3818   38183909632   83  Linux
start: (c,h,s) expected (3,41,9) found (0,33,3)
end: (c,h,s) expected (1023,42,12) found (1017,42,12)
/dev/sdb2 0  -  0  00  Empty
/dev/sdb3 0  -  0  00  Empty
/dev/sdb4 0  -  0  00  Empty
Successfully wrote the new partition table

Re-reading the partition table ...

If you created or changed a DOS partition, /dev/foo7, say, then use dd(1)
to zero the first 512 bytes:  dd if=/dev/zero of=/dev/foo7 bs=512 count=1
(See fdisk(8).)

~/prakash-bbb$ sudo mkfs.ext4 ${DISK}1 -L rootfs

~/prakash-bbb$ sudo mkfs.ext4 ${DISK}1 -L rootfs
mke2fs 1.42 (29-Nov-2011)
Filesystem label=rootfs
OS type: Linux
Block size=4096 (log=2)
Fragment size=4096 (log=2)
Stride=0 blocks, Stripe width=0 blocks
244800 inodes, 977408 blocks
48870 blocks (5.00%) reserved for the super user
First data block=0
Maximum filesystem blocks=1002438656
30 block groups
32768 blocks per group, 32768 fragments per group
8160 inodes per group
Superblock backups stored on blocks:
32768, 98304, 163840, 229376, 294912, 819200, 884736

Allocating group tables: done
Writing inode tables: done
Creating journal (16384 blocks): done
Writing superblocks and filesystem accounting information: done

~/prakash-bbb$ sudo mkdir -p /media/rootfs/
~/prakash-bbb$ sudo mount ${DISK}1 /media/rootfs/

Backup-bootloade

Re: [beagleboard] HW Timestamping on beaglebone black

[hllpc]

Hi John,
thanks for the infos. The problem is that I need to use the PRUSS, right 
now my bbb runs a 3.8.13 kernel with pru support and I've read here 
 
that the newest versions could be a bit problematic on this front. But I 
won't need the TI PRU cape support so maybe just building the kernel would 
be fine, I still need to do a bit of googling about this.

Thanks again!

Il giorno giovedì 26 novembre 2015 22:40:17 UTC+1, john3909 ha scritto:
>
> BTW, CPTS and PTP_1588_CLOCK are enabled in the ti-linux-kernel-dev repo, 
> so if you use 4.1.13-ti-r34, you have everything you need. Now if you look 
> in drivers’ptp you will find code for PTP. Not sure if any of this will 
> work on the BBB, but it is a good place to start. 
>
> Regards, 
> John 
>
>
>
>
> > On Nov 26, 2015, at 11:55 AM, hllpc > 
> wrote: 
> > 
> > Hi John, 
> > strangely enough I haven't found anything specific for the bbb, I was 
> thinking about using linuxptp (which allow both sw and hw timestamping). 
> > The only reference I've found is hete in the forum (   
> https://groups.google.com/forum/m/#!topic/beagleboard/QHXb2hm72A8 ) and 
> it seems like i have to enable the CPTS driver on the bbb, but i've no idea 
> how to do it! I was hoping in any kind advice from the community! 
> > 
> > -- 
> > 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. 
>
>

-- 
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] android bbb

[Maxim Podbereznyy]

Hi!

Does anyone know where I can find sources for rowboat android for BBB while
gitorous is dead? I need to compile Android myself but all free
instructions have links to gitorous, which is "migrating" and that
migration continues for ages

-- 
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 from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.