[beagleboard] BBB pull contention

[Matthijs van Duin]

On 9 February 2016 at 17:46, Gerald Coley  wrote:

> If you don't run SW, that fixes a contention issue in the processor and
> let it sit, you will void the warranty and damage the processor after about
> 120 hours of operation..


Speaking of contention, I reported one in the BBB four months ago:
http://bugs.elinux.org/issues/155

Does anybody actually read the bug tracker?

Matthijs

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

[beagleboard] Re: BBB pull contention

[Matthijs van Duin]

On 12 February 2016 at 15:07, Robert Nelson  wrote:

> Nah, that one is my fault..  That bug report must be bad luck, as
> every time i started looking at it, something at the day job pulled me
> away..
>

OK, thing is, although it didn't seem particularly important to me when I
first found it since the pull current isn't much and the input is
smith-triggered, the am572x erratum makes it clear that keeping an input at
intermediate level for extended time is nevertheless harmful. It seems
likely to me the same thing will apply to the am335x.

Matthijs

-- 
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] Codec drivers and alsa support for custom cape with sta321mp

[Robin Scheibler]

Hi Pablo,

Any progress with your board ?

Also, to answer your question, I got the alsamixer working. You have to add a 
number of macros for predefined controls corresponding to register to update in 
the codec. You can see it directly in my code:

https://github.com/fakufaku/linux/blob/66e5bfa74df723ff64b48d2ae14f3543d6c47861/sound/soc/codecs/sta321mp.c#L74


static const DECLARE_TLV_DB_SCALE(mvol_tlv, -12700, 50, 1);
static const DECLARE_TLV_DB_SCALE(chvol_tlv, -7950, 50, 1);
static const struct snd_kcontrol_new sta321mp_snd_controls[] = {
SOC_SINGLE("Master Switch", STA321MP_MMUTE, 0, 1, 1),
SOC_SINGLE_TLV("Master Volume", STA321MP_MVOL, 0, 0xff, 1, mvol_tlv),
SOC_DOUBLE_R("Ch1 Capture Switch", STA321MP_C1VTMB, STA321MP_C2VTMB, 7, 1, 1),
SOC_DOUBLE_R("Ch2 Capture Switch", STA321MP_C3VTMB, STA321MP_C4VTMB, 7, 1, 1),
SOC_DOUBLE_R("Ch3 Capture Switch", STA321MP_C5VTMB, STA321MP_C6VTMB, 7, 1, 1),
SOC_DOUBLE_R_TLV("Ch1 Capture Volume", STA321MP_C1VOL, STA321MP_C2VOL, 0, 0xff, 
1, chvol_tlv),
SOC_DOUBLE_R_TLV("Ch2 Capture Volume", STA321MP_C3VOL, STA321MP_C4VOL, 0, 0xff, 
1, chvol_tlv),
SOC_DOUBLE_R_TLV("Ch3 Capture Volume", STA321MP_C5VOL, STA321MP_C6VOL, 0, 0xff, 
1, chvol_tlv),
};

This implements volume control for all six capture channels, as well as mute 
switches.

Best,
Robin



> On 12 janv. 2016, at 21:50, Pablo Fonovich  wrote:
> 
> Hi Robin:
> 
> I realized that although i was commenting the line you said, i was using and 
> old image of the compiled kernel, and that was why i kept getting the same 
> error! My bad... Now that is working, but i have an error in the line:
> 
> ret = regmap_update_bits(priv->regmap, PCM3168_DAC_FMT_CONTROL, 0x0f, val);
> 
> on my pcm3168.c file... ret gets the value -128 (error code). I use this 
> function to update some register on the codec... i suspected that my i2c 
> connection is not working properly, so i commented this line (althoug i'm not 
> sure if an error in i2c causes this function to crash) and finally the 
> arecord command works gives no error, but records nothing :( 
> 
> That was somehow expected, as my codec is not geting it's regmap updated... 
> One of this days i will use an ozscope to see if the signals out of the i2c 
> of the beaglebone are right... If you came up with some idea please tell 
> me... you've been of great help...
> 
> P.D: have you got alsamixer working in your project?
> 
> 2016-01-11 17:06 GMT-03:00 Pablo Fonovich  >:
> Hi:
> Thanks for your suggestions!
> i've already commented that line, as i said in the mail when i isolated the 
> problem to that function... the error persist but now in:
> 
>   ret = snd_soc_dai_set_sysclk(cpu_dai, 0, sysclk, SND_SOC_CLOCK_OUT);
>   if (ret < 0)
>   return ret;
> 
> I'm using the linux-cross-reference, that's how i find out what each 
> parameter means, but perhaps i still dont quite understand what the function 
> really does.
> 
> I've also read the mcasp section of the am335x datasheet when i was doing the 
> PCB for the codec, but i should re-read it, as many things where not clear 
> for me at that moment, and perhaps now they make a little more sense. Anyway, 
> the problem and same error code persists, now in that other line...
> 
> Thanks for your help! i'll post any progress i make
>  
> 
> 2016-01-11 5:12 GMT-03:00 Robin Scheibler  >:
> Hi Pablo,
> 
> I took a look at your code.
> 
>> static int pcm3168_hw_params(struct snd_pcm_substream *substream,
>>   struct snd_pcm_hw_params *params)
>> {
>>  struct snd_soc_pcm_runtime *rtd = substream->private_data;
>>  struct snd_soc_dai *codec_dai = rtd->codec_dai;
>>  struct snd_soc_dai *cpu_dai = rtd->cpu_dai;
>>  struct snd_soc_codec *codec = rtd->codec;
>>  struct snd_soc_card *soc_card = rtd->card;
>>  struct platform_device *pdev = to_platform_device(soc_card->dev);
>>  int ret = 0;
>>  unsigned sysclk = ((struct snd_soc_card_drvdata_davinci *)
>> snd_soc_card_get_drvdata(soc_card))->sysclk;
>> 
>>  /* set the codec system clock */
>>  ret = snd_soc_dai_set_sysclk(codec_dai, 0, sysclk, SND_SOC_CLOCK_OUT);
>>  if (ret < 0)
>>  return ret;
>> 
>>  /* set the CPU system clock */
>>  ret = snd_soc_dai_set_sysclk(cpu_dai, 0, sysclk, SND_SOC_CLOCK_OUT);
>>  if (ret < 0)
>>  return ret;
>> 
>>  return 0;
>> }
> 
> I see that you are calling snd_soc_dai_set_sysclk for both codec_dai and 
> cpu_dai. I think that is the error. In your case codec_dai is the PCM3168 
> chip and cpu_dai is the processor McASP module. Sysclk only makes sense for 
> McASP as far as I understand. Try commenting out 
> 
>> /* set the codec system clock */
>> ret = snd_soc_dai_set_sysclk(codec_dai, 0, sysclk, SND_SOC_CLOCK_OUT);
>> if (ret < 0)
>>  return ret;
> 
> I 

[beagleboard] lcd4 driver for beaglebone black.

[Alexander Hayman]

I believe you will have to modify and recompile the kernel.

Otherwise this link might be useful:
http://papermint-designs.com/community/node/331

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

[beagleboard] Re: BBB pull contention

[Robert Nelson]

On Fri, Feb 12, 2016 at 7:18 AM, Matthijs van Duin
 wrote:
> On 9 February 2016 at 17:46, Gerald Coley  wrote:
>>
>> If you don't run SW, that fixes a contention issue in the processor and
>> let it sit, you will void the warranty and damage the processor after about
>> 120 hours of operation..
>
>
> Speaking of contention, I reported one in the BBB four months ago:
> http://bugs.elinux.org/issues/155
>
> Does anybody actually read the bug tracker?

Nah, that one is my fault..  That bug report must be bad luck, as
every time i started looking at it, something at the day job pulled me
away..

I know Jason's been trying to get more software developers involved,
Mark's been hacking on bonescript and Drew (who's started a new job)
has been helping out too..

Otherwise, the org's a little undermanned. ;)

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.

[beagleboard] Re: BBB pull contention

[Robert Nelson]

On Fri, Feb 12, 2016 at 10:35 AM, Matthijs van Duin
 wrote:
> On 12 February 2016 at 16:37, Robert Nelson  wrote:
>>
>> So, P9.15, gpmc_a0 is setup as:
>>
>> {OFFSET(gpmc_ad0), (MODE(1) | RXACTIVE | PULLUP_EN)}, /* MMC1_DAT0 */
>
>
> Those are different pins. The only useful purpose of pin 16 ("gpmc_a0") on a
> BBB is as pwm 1 tripzone input.
>
> mmc1 pins are obviously not double-mapped with anything.

/* P9.15 */
{OFFSET(gpmc_a0), MODE(0) | PULLUDDIS},
{OFFSET(gpmc_csn3), (MODE(3) | RXACTIVE | PULLUP_EN)},

>> so, gpmc_csn3 (which is also used by the bbgw as mmc2_cmd)
>
>
> mmc2 cmd is indeed the only useful use of the other pin of the pair.
>
> I'm thinking just disable the pull of pin 16 ("gpmc_a0"). The pull of the
> other pin should already take care of things.
>
> In general in DTs I would also recommend disabling (gpio input, rx disabled,
> no pull) the "other pin" of any pin-pair whenever one is in use, but at a
> minimum they should avoid a pull conflict. There are three such pairs, see
> P9 tab of my pins spreadsheet -> https://goo.gl/Jkcg0w

Yeah, P9.41/42..

We do separate them out:

https://github.com/beagleboard/bb.org-overlays/blob/master/include/dt-bindings/board/am335x-bbw-bbb-base.h#L96-L101

I'll have to fix up:

bone_eqep0-00A0.dts

as it uses: BONE_P9_41B

But doesn't unset P9_41A

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] Using P9_41 as an input using 4.1 kernel.

[Robert Nelson]

On Fri, Feb 12, 2016 at 11:11 AM, Rafael Vega  wrote:
> Hi.
>
> I have the following DTO that I've been using successfully in kernel 3.8 to
> use pin P9_41 as an input:
>
>  ...
>  P9_41A_i: P9_41A_in{pinctrl-single,pins = <0x1B4 0x37>;};
>  P9_41A_o: P9_41A_out{pinctrl-single,pins = <0x1B4 0x0F  0x1A8
> 0x37>;};
>  ...
>  P9_41A_mux {
> compatible = "bone-pinmux-helper";
> status = "okay";
> pinctrl-names = "input", "output";
> pinctrl-0 = <_41A_i>;
> pinctrl-1 = <_41A_o>;
>  };
>
>
> After compiling and loading the DTO in kernel 3.8, the
> /sys/devices/ocp.4/P9_41_mux/status file is created and if I echo "input"
> into it, I can read the pin as an input. However, in kernel 4.1, the
> /sys/devices/platform/ocp/P9_41_mux/status file is created but when I echo
> "input" to it, nothing happens and I can't read the value of the pin.
>
> What am I missing? What else do I need to use to enable P9_42 as an input?

P9_41 is used by audio, so make sure you are using the
*-nhdmi-overlay.dtb, *-emmc-overlay.dtb or *-overlay.dtb

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.

[beagleboard] Using P9_41 as an input using 4.1 kernel.

[Rafael Vega]

Hi. 

I have the following DTO that I've been using successfully in kernel 3.8 to 
use pin P9_41 as an input:

 ...
 P9_41A_i: P9_41A_in{pinctrl-single,pins = <0x1B4 0x37>;};
 P9_41A_o: P9_41A_out{pinctrl-single,pins = <0x1B4 0x0F  0x1A8 0x37
>;};
 ...
 P9_41A_mux {
compatible = "bone-pinmux-helper";
status = "okay";
pinctrl-names = "input", "output";
pinctrl-0 = <_41A_i>;
pinctrl-1 = <_41A_o>;
 };


After compiling and loading the DTO in kernel 3.8, the 
/sys/devices/ocp.4/P9_41_mux/status file is created and if I echo "input" 
into it, I can read the pin as an input. However, in kernel 4.1, the 
/sys/devices/platform/ocp/P9_41_mux/status file is created but when I echo 
"input" to it, nothing happens and I can't read the value of the pin.

What am I missing? What else do I need to use to enable P9_42 as an input?

Thanks!

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

[beagleboard] RS485 support for BBB

[Taceant Omnes]

I would like to use RS485 with the BBB.

root@beaglebone:~/test# uname -a
Linux beaglebone 4.1.15-ti-r40 #1 SMP PREEMPT Thu Jan 7 23:32:17 UTC
2016 armv7l GNU/Linux

I am using the kernel above. Its source code is at
https://github.com/RobertCNelson/linux-stable-rcn-ee/tree/4.1.15-ti-rt-r40

... however it does not include the changes in this patch:
https://github.com/RobertCNelson/bb-kernel/blob/am33x-v3.8/patches/fixes/0007-omap-RS485-support-by-Michael-Musset.patch#L30

Which kernel should I use that includes the changes in the patch or
something similar?

-- 
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] RS485 support for BBB

[Taceant Omnes]

On 12 February 2016 at 16:04, arsi  wrote:
> Hi,
>
> Use MAX13487EESA+ It has an automatic direction control..

Thanks, Arsi. That is interesting.

I am using a prototype board designed by our hardware department that
uses another Maxim RS485 driver which is pin compatible with the one
you suggested except for two pins (RE and SHDBN).

I will ask the hardware engineer what he thinks about it.

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

[beagleboard] Re: BBB pull contention

[Matthijs van Duin]

On 12 February 2016 at 16:37, Robert Nelson  wrote:

> So, P9.15, gpmc_a0 is setup as:
>
> {OFFSET(gpmc_ad0), (MODE(1) | RXACTIVE | PULLUP_EN)}, /* MMC1_DAT0 */
>

Those are different pins. The only useful purpose of pin 16 ("gpmc_a0") on
a BBB is as pwm 1 tripzone input.

mmc1 pins are obviously not double-mapped with anything.


> so, gpmc_csn3 (which is also used by the bbgw as mmc2_cmd)
>

mmc2 cmd is indeed the only useful use of the other pin of the pair.

I'm thinking just disable the pull of pin 16 ("gpmc_a0"). The pull of the
other pin should already take care of things.

In general in DTs I would also recommend disabling (gpio input, rx
disabled, no pull) the "other pin" of any pin-pair whenever one is in use,
but at a minimum they should avoid a pull conflict. There are three such
pairs, see P9 tab of my pins spreadsheet -> https://goo.gl/Jkcg0w

Matthijs

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

[beagleboard] Re: BBB pull contention

[Robert Nelson]

On Fri, Feb 12, 2016 at 9:11 AM, Matthijs van Duin
 wrote:
> On 12 February 2016 at 15:07, Robert Nelson  wrote:
>>
>> Nah, that one is my fault..  That bug report must be bad luck, as
>> every time i started looking at it, something at the day job pulled me
>> away..
>
>
> OK, thing is, although it didn't seem particularly important to me when I
> first found it since the pull current isn't much and the input is
> smith-triggered, the am572x erratum makes it clear that keeping an input at
> intermediate level for extended time is nevertheless harmful. It seems
> likely to me the same thing will apply to the am335x.

So, P9.15, gpmc_a0 is setup as:

{OFFSET(gpmc_ad0), (MODE(1) | RXACTIVE | PULLUP_EN)}, /* MMC1_DAT0 */

so, gpmc_csn3 (which is also used by the bbgw as mmc2_cmd)

{OFFSET(gpmc_csn3), (MODE(3) | RXACTIVE | PULLUP_EN)},

So i'm thinking:

http://paste.debian.net/381383/

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] RS485 support for BBB

[Robert Nelson]

On Fri, Feb 12, 2016 at 9:33 AM, Taceant Omnes  wrote:
> I would like to use RS485 with the BBB.
>
> root@beaglebone:~/test# uname -a
> Linux beaglebone 4.1.15-ti-r40 #1 SMP PREEMPT Thu Jan 7 23:32:17 UTC
> 2016 armv7l GNU/Linux
>
> I am using the kernel above. Its source code is at
> https://github.com/RobertCNelson/linux-stable-rcn-ee/tree/4.1.15-ti-rt-r40

You need to rebuild and swap these two configs:

disable: CONFIG_SERIAL_8250_OMAP

enable: CONFIG_SERIAL_OMAP

> ... however it does not include the changes in this patch:
> https://github.com/RobertCNelson/bb-kernel/blob/am33x-v3.8/patches/fixes/0007-omap-RS485-support-by-Michael-Musset.patch#L30

485 is pretty much built-in to CONFIG_SERIAL_OMAP

It's the last thing still being talked about for integration into
CONFIG_SERIAL_8250_* for possibly 4.6.x

> Which kernel should I use that includes the changes in the patch or
> something similar?

and use this overlay as reference, as it's been reported to work with
that config chanage above..

https://github.com/beagleboard/bb.org-overlays/blob/master/src/arm/BB-UART4-RS485-00A0.dts

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] RS485 support for BBB

[Taceant Omnes]

On 12 February 2016 at 15:41, Robert Nelson  wrote:
> On Fri, Feb 12, 2016 at 9:33 AM, Taceant Omnes  wrote:
>> I would like to use RS485 with the BBB.
>>
>> root@beaglebone:~/test# uname -a
>> Linux beaglebone 4.1.15-ti-r40 #1 SMP PREEMPT Thu Jan 7 23:32:17 UTC
>> 2016 armv7l GNU/Linux
>>
>> I am using the kernel above. Its source code is at
>> https://github.com/RobertCNelson/linux-stable-rcn-ee/tree/4.1.15-ti-rt-r40
>
> You need to rebuild and swap these two configs:
>
> disable: CONFIG_SERIAL_8250_OMAP
>
> enable: CONFIG_SERIAL_OMAP
>
>> ... however it does not include the changes in this patch:
>> https://github.com/RobertCNelson/bb-kernel/blob/am33x-v3.8/patches/fixes/0007-omap-RS485-support-by-Michael-Musset.patch#L30
>
> 485 is pretty much built-in to CONFIG_SERIAL_OMAP
>
> It's the last thing still being talked about for integration into
> CONFIG_SERIAL_8250_* for possibly 4.6.x
>
>> Which kernel should I use that includes the changes in the patch or
>> something similar?
>
> and use this overlay as reference, as it's been reported to work with
> that config chanage above..
>
> https://github.com/beagleboard/bb.org-overlays/blob/master/src/arm/BB-UART4-RS485-00A0.dts

Thanks, Robert.

-- 
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] Using P9_41 as an input using 4.1 kernel.

[Rafael Vega]

> I think i've seen enough, and i'm just going to remove the default 
> clock2 setting and re-enable P9_41 in the overlays.. 
>
>
>
That's great, thanks!

How would I disable the default overlays that you linked?   

How soon would your changes reach the repos as a new version of the kernel 
(no pressure, just curiosity) ?

-- 
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] Using P9_41 as an input using 4.1 kernel.

[Robert Nelson]

On Fri, Feb 12, 2016 at 11:15 AM, Robert Nelson  wrote:
> On Fri, Feb 12, 2016 at 11:11 AM, Rafael Vega  wrote:
>> Hi.
>>
>> I have the following DTO that I've been using successfully in kernel 3.8 to
>> use pin P9_41 as an input:
>>
>>  ...
>>  P9_41A_i: P9_41A_in{pinctrl-single,pins = <0x1B4 0x37>;};
>>  P9_41A_o: P9_41A_out{pinctrl-single,pins = <0x1B4 0x0F  0x1A8
>> 0x37>;};
>>  ...
>>  P9_41A_mux {
>> compatible = "bone-pinmux-helper";
>> status = "okay";
>> pinctrl-names = "input", "output";
>> pinctrl-0 = <_41A_i>;
>> pinctrl-1 = <_41A_o>;
>>  };
>>
>>
>> After compiling and loading the DTO in kernel 3.8, the
>> /sys/devices/ocp.4/P9_41_mux/status file is created and if I echo "input"
>> into it, I can read the pin as an input. However, in kernel 4.1, the
>> /sys/devices/platform/ocp/P9_41_mux/status file is created but when I echo
>> "input" to it, nothing happens and I can't read the value of the pin.
>>
>> What am I missing? What else do I need to use to enable P9_42 as an input?
>
> P9_41 is used by audio, so make sure you are using the
> *-nhdmi-overlay.dtb, *-emmc-overlay.dtb or *-overlay.dtb

ah p9_41.. so on mainline it's setup as clkout2_pin:

https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/arch/arm/boot/dts/am335x-bone-common.dtsi#n98

I left it enabled for our 4.1.x branch:

https://github.com/beagleboard/linux/blob/4.1/arch/arm/boot/dts/am335x-bone-common.dtsi#L98-L102

It was first introduced here:

https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/arch/arm/boot/dts/am335x-bone-common.dtsi?id=2ba3549352277514a8e4790adff77a783ee1b9e2

anyone have a hint/reason why it should/shouldn't be enabled by default..

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] Using P9_41 as an input using 4.1 kernel.

[Rafael Vega]

> 

> > P9_41 is used by audio, so make sure you are using the 
> > *-nhdmi-overlay.dtb, *-emmc-overlay.dtb or *-overlay.dtb 
>
>
I have dtb=am335x-boneblack-emmc-overlay.dtb in /boot/uEnv.txt so it should 
be fine (?)

 

> ah p9_41.. so on mainline it's setup as clkout2_pin: 
>
>
> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/arch/arm/boot/dts/am335x-bone-common.dtsi#n98
>  
>
> I left it enabled for our 4.1.x branch: 
>
>
> https://github.com/beagleboard/linux/blob/4.1/arch/arm/boot/dts/am335x-bone-common.dtsi#L98-L102
>  
>
> It was first introduced here: 
>
>
> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/arch/arm/boot/dts/am335x-bone-common.dtsi?id=2ba3549352277514a8e4790adff77a783ee1b9e2
>  
>
> anyone have a hint/reason why it should/shouldn't be enabled by default.. 
>
>
I'm affraid I don't understand this... Does this mean that the pin is used 
for something else and I can't use it as GPIO? Or that I should disable 
something else before using it as GPIO?

Thanks for the replies! 
 

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

[beagleboard] Re: pinctrl for P8_10 and P9_41 with 4.1.12-ti-r26

[Rafael Vega]

In case someone reads this:

https://groups.google.com/forum/#!topic/beagleboard/e1do4oyo6RM

On Friday, February 12, 2016 at 5:42:27 PM UTC+1, Rafael Vega wrote:
>
> Hey, did you manage to use P9_41 on 4.1 kernel?
>
> On Saturday, October 31, 2015 at 11:56:33 PM UTC+1, Erik Stauber wrote:
>>
>> I'm trying to move from 3.8.X to the latest 4.1, and have 2 last issues 
>> with pin configurations that I'm stumped on.
>>
>> *config-pin P8.10 low*
>>
>>
>> *bash: /sys/devices/platform/ocp/ocp*P8_10_pinmux/state: No such file or 
>> directoryCannot write pinmux file: 
>> /sys/devices/platform/ocp/ocp*P8_10_pinmux/state*
>> Does anyone know why the state file isn't there for P8_10?
>>
>> *config-pin p9-41 in*
>>
>> *P9_41 pinmux file not found!*
>> *cape-universala overlay not found*
>> *run "config-pin overlay cape-universala" to load the cape*
>>
>> looking at line #570 of /opt/source/beaglebone-universal-io/config-pin, I 
>> see that cape-universal is listed one of the capes for P9_41.
>>
>> Ideas?
>>
>> Thanks,
>> Erik
>>
>>
>>
>>

-- 
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] Using P9_41 as an input using 4.1 kernel.

[Robert Nelson]

On Fri, Feb 12, 2016 at 12:03 PM, Rafael Vega  wrote:
>>
>>
>> > P9_41 is used by audio, so make sure you are using the
>> > *-nhdmi-overlay.dtb, *-emmc-overlay.dtb or *-overlay.dtb
>>
>
> I have dtb=am335x-boneblack-emmc-overlay.dtb in /boot/uEnv.txt so it should
> be fine (?)
>
>
>>
>> ah p9_41.. so on mainline it's setup as clkout2_pin:
>>
>>
>> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/arch/arm/boot/dts/am335x-bone-common.dtsi#n98
>>
>> I left it enabled for our 4.1.x branch:
>>
>>
>> https://github.com/beagleboard/linux/blob/4.1/arch/arm/boot/dts/am335x-bone-common.dtsi#L98-L102
>>
>> It was first introduced here:
>>
>>
>> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/arch/arm/boot/dts/am335x-bone-common.dtsi?id=2ba3549352277514a8e4790adff77a783ee1b9e2
>>
>> anyone have a hint/reason why it should/shouldn't be enabled by default..
>>
>
> I'm affraid I don't understand this... Does this mean that the pin is used
> for something else and I can't use it as GPIO? Or that I should disable
> something else before using it as GPIO?

Looking at the datasheet, it's only tied to the EMU3 on the
un-populated jtag connector..

It's also shared with GPIO3_20 mcaspo_axr1...

I think i've seen enough, and i'm just going to remove the default
clock2 setting and re-enable P9_41 in the overlays..

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.

[beagleboard] Re: BeagleBone Black won't startup (USR2 LED, always on)

[ajinkya . kohokade]

new image 8.3 works well


On Wednesday, 4 November 2015 21:21:53 UTC+5:30, Felix Müller-Irion wrote:
>
> Step by step:
> I plug in a power supply or the USB cable, doesn't matter.
> PWR LED comes on.
> USR 0, USR 1, USR 2, USR 3 come on in that order, then USR 1 and 3 flash, 
> then USR 0 gives one heartbeat and then USR 2 stays on indicating constant 
> use of the CPU.
> Nothing else happens.
> I tried with or without sdCard, no difference.
> With or without held down boot button, no difference.
>
> I flashed the eMMC unsuccessfully using the newest Debian iimage from the 
> website.
> Just the BeagleBone folder appeared.
> I powered it off last night and everything went completely normal.
> And then when I tried rebooting it today this is what happened.
> Already tried to format and reconfigure the sdCard.
> All I have available is a Linux mint 17.1 and an OS X 10.11, no windows.
> Any help or idea is greatly appreciated.
>
> Best, Felix
>
> https://drive.google.com/open?id=0B42xb53PydgcODQ2cnphejQtYTA
>

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

Re: [beagleboard] How do you enable analog on Beaglebone Black?

[John Syne]

Yeah, William did a nice job with this document.

Regards,
John




> On Feb 12, 2016, at 3:38 PM, Gunnar  wrote:
> 
> Ok, I followed William's instructions, and the sample code is working, so I 
> think I am good to go.
> 
> Thanks for the help!
> 
> Gunnar
> 
> On Thursday, February 11, 2016 at 7:13:58 PM UTC-8, john3909 wrote:
> Agreed.
> 
> Regards,
> John
> 
> 
> 
> 
>> On Feb 11, 2016, at 6:04 PM, William Hermans > > wrote:
>> 
>> My approach was wrong because you need the devicetree, so follow William’s 
>> docs.
>> Regards,
>> John
>> 
>> Not necessarily wrong. The ADC device tree file would, and will infact load 
>> the same device module. The only problem with just loading the kernel 
>> module, is the pins will be in whatever the default state is after boot up. 
>> Which I'm not certain what state that would be . . .
>> 
>> On Thu, Feb 11, 2016 at 6:00 PM, John Syne  
>> wrote:
>> My approach was wrong because you need the devicetree, so follow William’s 
>> docs.
>> 
>> Regards,
>> John
>> 
>> 
>> 
>> 
>>> On Feb 11, 2016, at 4:54 PM, William Hermans >> > wrote:
>>> 
>>> http://www.embeddedhobbyist.com/2015/10/beaglebone-black-adc/ 
>>> 
>>> 
>>> On Thu, Feb 11, 2016 at 5:52 PM, John Syne >> > wrote:
>>> Do you see /sys/bus/iio folder?
>>> 
>>> If you don’t, then load the kernel module:
>>> 
>>> modprobe ti_am335x_adc
>>> 
>>> Regards,
>>> John
>>> 
>>> 
>>> 
>>> 
 On Feb 11, 2016, at 2:04 PM, newqu...@gmail.com  wrote:
 
 Hi, I am new to Beaglebone, and it seems that analog is not enabled.  I am 
 using a new Beaglebone Black Rev C with debian linux version 4.4.  I tried 
 both the default image and the image on the board, and neither had the 
 analog enabled.
 
 How do you enable analog?
 
 Thanks!
 
 -- 
 For more options, visit http://beagleboard.org/discuss 
 
 --- 
 You received this message because you are subscribed to the Google Groups 
 "BeagleBoard" group.
 To unsubscribe from this group and stop receiving emails from it, send an 
 email to beagleboard...@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...@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...@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...@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...@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 

Re: [beagleboard] How to build Os to beaglebone with hardcoding some of the GPIOs of beaglebone?

[William Hermans]

>
> *When I refer, Beaglebone Black P8 Header, the GPIO 38, 39 (GPIO1[6],
> GPIO1[7]) are having note as "Used on Board (Group: pinmux_emmc2_pins).
> There are more other PINs having same note.*
>

The bolded text in the quote above should make it obvious as to why your
attempt as using these pins as gpio's fails. They're in use, and whats
more, they're in use by the eMMC interface is seems.

With older 3.8.x kernels is was possible to disable the eMMC by removing,
or commenting out loading the appropriate device tree file in uEnv.txt.
Then one could use the pin otherwise assigned to the eMMC how they saw fit.
One thing to note however. The hardware is still physically connected, so
it could be a bad idea to use some, or all of the pins other than how
they're meant to be used.  For this, you would need to consult with one of
the community members whose expertise with electronics is greater than mine.

With current 4.1.x kernels, I'd assume the above procedure has not changed
much, if at all. But I am unsure. As I have not had reason to check / test
this.

On Fri, Feb 12, 2016 at 12:51 AM, Gowri reddi 
wrote:

> Hi William,
>
> Thanks for your reply.
>
> On Beaglebone black, when I tried turn ON/OFF the LEDs connected to GPIOs
> like 38, 39 on Beaglebone, I am not able to do. With the same logic I am
> able turn ON/OFF of LEDs connected to GPIOs 44, 45 etc.
>
> When I refer, Beaglebone Black P8 Header, the GPIO 38, 39 (GPIO1[6],
> GPIO1[7]) are having note as "Used on Board (Group: pinmux_emmc2_pins).
> There are more other PINs having same note.
>
> I think, those are not by default available as GPIOs, rather used for
> internal purpose.
>
> So, I am looking for below
> - Is there any way to use them (ex: GPIO1[6], GPIO1[7]) as GPIOs
> - Is there any way to build Beaglebone OS such that those (ex: GPIO1[6],
> GPIO1[7]) pins can be used as GPIO directly without changing anything.
>
> Thanks,
> Gowri.
>
> On Fri, Feb 12, 2016 at 11:41 AM, William Hermans 
> wrote:
>
>> What ? Could you possibly ask a more obscure question ?
>>
>> On Thu, Feb 11, 2016 at 10:47 PM, Gowri reddi 
>> wrote:
>>
>>> How to build Os to beaglebone with hardcoding some of the GPIOs of
>>> beaglebone?
>>>
>>> --
>>> 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 a topic in the
>> Google Groups "BeagleBoard" group.
>> To unsubscribe from this topic, visit
>> https://groups.google.com/d/topic/beagleboard/yOhAH_kVxyI/unsubscribe.
>> To unsubscribe from this group and all its topics, 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] Using P9_41 as an input using 4.1 kernel.

[Robert Nelson]

On Fri, Feb 12, 2016 at 12:18 PM, Rafael Vega  wrote:
>
>> I think i've seen enough, and i'm just going to remove the default
>> clock2 setting and re-enable P9_41 in the overlays..

Yeah, it's tied to audio:

http://lists.infradead.org/pipermail/linux-arm-kernel/2013-May/166996.html

> That's great, thanks!
>
> How would I disable the default overlays that you linked?
>
>
> How soon would your changes reach the repos as a new version of the kernel
> (no pressure, just curiosity) ?

Right now you can use the dtb-rebuilder to first rebuild the *.dtb
with it removed, then rebuild the bb.org-overlays with it p9_41
un-commented out..

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] How do you enable analog on Beaglebone Black?

[Gunnar]

Ok, I followed William's instructions, and the sample code is working, so I 
think I am good to go.

Thanks for the help!

Gunnar

On Thursday, February 11, 2016 at 7:13:58 PM UTC-8, john3909 wrote:
>
> Agreed.
>
> Regards,
> John
>
>
>
>
> On Feb 11, 2016, at 6:04 PM, William Hermans  > wrote:
>
> *My approach was wrong because you need the devicetree, so follow 
>> William’s docs.*
>> *Regards,*
>>
> *John*
>
>
> Not necessarily wrong. The ADC device tree file would, and will infact 
> load the same device module. The only problem with just loading the kernel 
> module, is the pins will be in whatever the default state is after boot up. 
> Which I'm not certain what state that would be . . .
>
> On Thu, Feb 11, 2016 at 6:00 PM, John Syne  > wrote:
>
>> My approach was wrong because you need the devicetree, so follow 
>> William’s docs.
>>
>> Regards,
>> John
>>
>>
>>
>>
>> On Feb 11, 2016, at 4:54 PM, William Hermans > > wrote:
>>
>> http://www.embeddedhobbyist.com/2015/10/beaglebone-black-adc/
>>
>> On Thu, Feb 11, 2016 at 5:52 PM, John Syne > > wrote:
>>
>>> Do you see /sys/bus/iio folder?
>>>
>>> If you don’t, then load the kernel module:
>>>
>>> modprobe ti_am335x_adc
>>>
>>> Regards,
>>> John
>>>
>>>
>>>
>>>
>>> On Feb 11, 2016, at 2:04 PM, newqu...@gmail.com  wrote:
>>>
>>> Hi, I am new to Beaglebone, and it seems that analog is not enabled.  I 
>>> am using a new Beaglebone Black Rev C with debian linux version 4.4.  I 
>>> tried both the default image and the image on the board, and neither had 
>>> the analog enabled.
>>>
>>> How do you enable analog?
>>>
>>> Thanks!
>>>
>>> -- 
>>> For more options, visit http://beagleboard.org/discuss
>>> --- 
>>> You received this message because you are subscribed to the Google 
>>> Groups "BeagleBoard" group.
>>> To unsubscribe from this group and stop receiving emails from it, send 
>>> an email to beagleboard...@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...@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...@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...@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...@googlegroups.com .
> For more options, visit https://groups.google.com/d/optout.
>
>
>

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

[beagleboard] Re: Read voltage from ADC using an external power supply

[doog]

Chelsea,  As was mentioned, the BBB input pins can't be more than 1.8V so 
you will need a voltage divider to take your power supply voltage down 
between 0 and 1.8V.
This page might help you: http://www.alfonsomartone.itb.it/hclbmf.html

And it is possible you have already damaged that pin if you connected up 
anything more than 1.8V so when you make your resistor divider circuit and 
try it, if it doesn't work, try another ADC input pin.  Also test the 
divider circuit with a volt meter first to be sure the max voltage of your 
power supply presents a max of 1.8V on the voltage divider circuit.

Doug

On Wednesday, February 10, 
2016 at 1:54:54 PM UTC-8, Chelsea Orefice wrote:
>
> Hi All,
>
> I have a new BBB. I'm trying to read voltages from a DC power supply. I'm 
> having trouble doing so. I connected the output from the power supply to 
> AIN0, and the ground from the power supply to the ADC_GND, and tried to run 
> the code, but the voltages that I'm reading doesn't make sense.
>
> So I went back to the basic, and just ran the code without plugging 
> anything in, and yet the voltage value I'm printing says 1.6 instead of 0. 
> Below shows the code, which I got from adafruit. I'm aware that I'm not 
> supposed to connect BBB ADC to anything above 1.8V or below 0V, which I 
> don't believe I have.
>
> import Adafruit_BBIO.ADC as ADC
>> ADC.setup()
>> value = ADC.read("P9_40")
>> voltage = value * 1.8 
>> print (voltage)
>
>
>
> https://learn.adafruit.com/setting-up-io-python-library-on-beaglebone-black/adc
>
> I've also been reading somewhere that I may have to enable the ADC before 
> I can read it??
>
> Help?
>
> Thanks.
>

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