Re: [beagleboard] BeagleBone Black powers down when AC adapter is removed while the USB is connected.
Sorry to revive an old thread but I wanted to add my solution to this
problem somewhere and this seems like the most appropriate place to do it.
I was also experiencing the Bone shutting itself down on AC Power removal
regardless of a battery present. The logs showed it was registering the
removal as a button press condition and powering down the unit. I had a
product running on 4.1.19-bone20 and did not want to update to a later
kernel but it appears to be resolved in later kernels already.
To fix on 4.1.19-bone20, I modified the file mentioned here
(/drivers/mfd/tps65217.c) and commented out this code entirely:
/*
if (int_reg & TPS65217_INT_ACI) {
/* Handle AC power status change
dev_dbg(tps->dev, "AC power status change\n");
/* Press KEY_POWER when AC not present
input_report_key(tps->pwr_but, KEY_POWER,
~status_reg & TPS65217_STATUS_ACPWR);
input_sync(tps->pwr_but);
}
*/
After I rebuilt and deployed the modified kernel, the problem was resolved,
no more power down on AC removal.
For anyone who needs further instructions, I'd be happy to help.
On Wednesday, November 19, 2014 at 10:12:05 AM UTC-5,
dhi...@schneiderdcim.com wrote:
>
> in /drivers/mfd/tps65217.c i believe this is where the magic happens, and
> needs to be changed
>
>
> if (int_reg & TPS65217_INT_PBI) {
> /* Handle push button */
> dev_dbg(tps->dev, "power button status change\n");
>input_report_key(tps->pwr_
> but, KEY_POWER,
> status_reg & TPS65217_STATUS_PB);
> input_sync(tps->pwr_but);
> }
> if (int_reg & TPS65217_INT_ACI) {
> /* Handle AC power status change */
>
>
>
> On Tuesday, November 18, 2014 1:57:47 PM UTC-5, Gerald wrote:
>>
>> Then the SW needs to be changed to change that behavior.
>>
>> Gerald
>>
>>
>> On Tue, Nov 18, 2014 at 10:37 AM, David Hirst wrote:
>>
>>> The fact that it powers down is a problem to me, if for instance a
>>> slight power interruption occurs ( lets say 5 seconds) during which time
>>> the CPU is powered by the battery backup I would like to carry on running,
>>> if its longer then I would like to make the decision when to shutdown.
>>> As it stands now I have no option but to have the system power down.
>>> With the current implementation In the event of a small interruption,
>>> the system will start to power down but if that the power has now returned
>>> prior to the shutdown occurring the system needs intervention to power
>>> back up, by power cycling either the USB or AC. I want to smooth out short
>>> power cycles and let the long power outages re-power the board when the
>>> power returns
>>>
>>>
>>> On Monday, November 17, 2014 10:04:21 AM UTC-5, Gerald wrote:
That should be bale to be fixed by changing the behavior of the SW. You
can look at the datasheet for the TPS65217C to see what registers to
change.
Gerald
On Mon, Nov 17, 2014 at 8:58 AM, Michel Gerin
wrote:
> Attn Gerald Coley,
>
> Hello,
> In order to avoid any misunderstanding, I wrote "I had a similar
> problem". But I didn't use the USB connection.
> Only 5V DC and battery were connected to the BBB.
> As soon as 5V DC PS was off, the Debian LXDE version was shutting down
> but a warning was appearing telling the user the system was shutting down
> within 60s if this procedure wasn't canceled.
> Maybe David Hirst's problem is related to the same software
> "mecanism".
>
> Kind regards
>
> Michel.
>
>
> 2014-11-17 12:31 GMT+01:00 Gerald Coley :
>
>> Interesting. Sounds like something I need to get fixed.
>>
>> Gerald
>>
>>
>> On Monday, November 17, 2014, Michel Gerin
>> wrote:
>>
>>> Hello,
>>> I had a similar problem. David mentions perhaps this thread:
>>>
>>> https://mail.google.com/mail/u/0/?tab=wm#inbox/149198bbf7826f64
>>>
>>> Bremenpl suggested to use the debian console version instead of the
>>> LXDE version. It solved my problem.
>>>
>>> We just encontered a 2 hours mains power outage this saterday.The
>>> BBB went on running flawless with the battery backup.
>>>
>>> Michel
>>>
>>> 2014-11-17 1:09 GMT+01:00 David Funk :
>>>
There is a previous thread, several weeks ago about this same
behavior. That thread involved an application that ran off mains but
had
battery backup and everytime mains failed, and 5V goes away, the BBB
shutdown.
IIRC, this is a known software default behavior when the 5V goes
away, it is programmable and needs to be set accordingly to how the
end
user whats it to behave.
-david
.
On Sun, Nov 16, 2014 at 5:52 PM, William Hermans >>> > wrote
[beagleboard] Updated to 4.14.26-bone13 and cannot get PCA9544 I2C-mux to initialize, ideas?
We have had a solution running on 4.1.19-bone20 kernel for over a year. Now
I am trying to add battery controlled shutdown to the Bone but came to the
conclusion that the unit treats power removal as a push button event and
immediately powers down. This doesn't work for our application, we need to
be able to control the shutdown. After some scrounging around Groups I saw
the (https://groups.google.com/forum/#!topic/beagleboard/DfkWz9qlqA8) problem
was that the tps65217 kernel code needed modification. I decided to update
to the latest kernel (4.14.26-bone13) to see if it was resolved. I did that
and it is indeed fixed. Now I have to re-work my Device Tree Blob for this
kernel.
No problem, I downloaded the kernel source and made by changes and compiled
it. I moved the dtb to the Bone and rebooted. Everything comes online as
expected except the PCA9544 I2C mux.
I checked dmesg and there are no entries, good or bad, relating to the mux.
According to /Kernel/Documentation/devicetree/bindings/i2c/i2c-mux.txt,
nothing should have dramatically changed between the two kernels.
After much experimentation, trying the various options, etc, I've decided
to seek help.
Here is my entry made in am335x-bone-common.dtsi.
&i2c1 {
#address-cells = <1>;
#size-cells = <0>;
clock-frequency = <40>;
status = "okay";
pinctrl-names = "default";
pinctrl-0 = <&i2c1_pins>;
mux@70 {
#address-cells = <1>;
#size-cells = <0>;
compatible = "nxp,pca9544";
reg = <0x70>;
i2c@3 {
#address-cells = <1>;
#size-cells = <0>;
reg = <0x03>;
};
i2c@4 {
#address-cells = <1>;
#size-cells = <0>;
reg = <0x04>;
};
i2c@5 {
#address-cells = <1>;
#size-cells = <0>;
reg = <0x05>;
};
i2c@6 {
#address-cells = <1>;
#size-cells = <0>;
reg = <0x06>;
};
};
};
I can confirm that the mux is available and functioning using i2cget/set
commands.
Can anyone recommend an approach to troubleshoot this further? Any useful
logs that I am not seeing?
Also just for reference, this is how I had the entry structured on
4.1.19-bone20 before changing it to what is shown above.
&i2c1 {
pinctrl-names = "default";
pinctrl-0 = <&i2c1_pins>;
status = "okay";
clock-frequency = <40>;
mux@70 {
compatible = "nxp,pca9544";
#address-cells = <1>;
#size-cells = <0>;
reg = <0x70>;
};
};
Thank you!
Bruce
--
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.
To view this discussion on the web visit
https://groups.google.com/d/msgid/beagleboard/a5e40037-01d2-4f4b-a6b6-98889d57796f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Re: [beagleboard] 4.1 repo
I'm getting an overrun error at this point and not an underflow. I am also
measuring 24MHz on MCLK regardless of what I specify.
These clocks are defined within the default am335x-boneblack.dtb. I pay
special attention to the clk_mcasp0 as it specified the gpio-gate-clock
which uses external oscillator, Y4, on the BBB to generate that signal.
I've attempted modifying the clock-frequency value but it does not have an
effect, I still see 24MHz on the output.
clk_mcasp0_fixed {
#clock-cells = <0x0>;
compatible = "fixed-clock";
clock-frequency = <0x177>;
linux,phandle = <0x51>;
phandle = <0x51>;
};
clk_mcasp0 {
#clock-cells = <0x0>;
compatible = "gpio-gate-clock";
clocks = <0x51>;
enable-gpios = <0x48 0x1b 0x0>;
linux,phandle = <0x54>;
phandle = <0x54>;
};
Also I've specified the clock within the simple-card binding as follows:
sound_master:simple-audio-card,codec {
sound-dai = <&tlv320aic3104_aq1>;
clocks = <0x54>;
/* system-clock-frequency = <1200>; */
};
This allows me to use the defined clock, referenced by its phandle, for my
codec. In this configuration it is the codec that is doing the clock
generation as it is defined as the master. In my case, it is generating a
BCLK and a WCLK but at a much higher frequency that what is expected, i.e,
I issue an arecord test.wav, I should see BCLK at 8KHz but it is instead at
16KHz. Or is that what I should expect for BCLK considering Nyquist
Theorem, etc, need to sample at twice the desired frequency? On second
thought, this entire thing is configured for TDM and I am not very familiar
with what I should be seeing vs. what I am seeing.
I'd also like to add that I am seeing data on both AIN and AOUT but its
coming in much faster than we'd expect hence the:
*root@beaglebone:~# arecord test.wavRecording WAVE 'test.wav' : Unsigned 8
bit, Rate 8000 Hz, Monooverrun!!! (at least 0.109 ms long)overrun!!! (at
least 0.064 ms long)overrun!!! (at least 0.754 ms long)*or the
*root@beaglebone:~# speaker-testspeaker-test 1.0.28Playback device is
defaultStream parameters are 48000Hz, S16_LE, 1 channelsUsing 16 octaves of
pink noiseRate set to 48000Hz (requested 48000Hz)Buffer size range from 256
to 32768Period size range from 128 to 16384Using max buffer size
32768Periods = 4was set period_size = 8192was set buffer_size = 32768 0 -
Front LeftWrite error: -32,Broken pipeWrite error: -32,Broken pipeWrite
error: -32,Broken pipeTime per period = 0.101305 0 - Front LeftWrite error:
-32,Broken pipeWrite error: -32,Broken pipeTime per period = 0.054033*
Not sure what to make of the Broken Pipe but there you have 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.
Re: [beagleboard] Transmit buffer underflow when trying to play audio using an externally attached codec board
Hi Shadi, Just curious, did you make any progress on this front? I am working on a similar project so I'd be curious if you discovered anything more. Thanks, Bruce On Monday, October 19, 2015 at 2:06:05 AM UTC-4, Shadi Abdu-Rahman wrote: > > I’m using the v4.1.3-bone15 linux kernel with > debian-8.1-minimal-armhf-2015-06-09. > > So yeah, it seems something broke between 3.8 and 4.1. I did look at the > relevant McAsp registers and they all looked properly setup from what I > could see. > > I'm not sure what could be wrong. Looking a the relevant code is like > trying to find a needle in a haystack. Could be anything (dma engine, etc) > > Kind Regards, > Shadi > > Den måndag 19 oktober 2015 kl. 03:58:12 UTC+2 skrev Rick M: >> >> My DTS (for both types of sound card) call for a 12MHz McASP master >> clock, but in 4.x kernels, I would actually see a 24MHz signal come off the >> master clock, and I think that's what led to the underflow. >> > > I think there's more to it. My configuration is feeding McASP with an > external clock from the codec board (24.576 MHz). I've verified that the > internal BBB master clock is disabled by my code and that the external > clock signal doesn't get doubled or anything. > > Kind Regards, > Shadi > -- 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] dtc Unable to parse input tree - gpio-reset
I created an overlay that utilizes a pca9544 i2c multiplexer and it finally
works.
I found this in
linux-4.1.13-ti-r35\Documentation\devicetree\bindings\i2c\i2c-mux-pca954x.txt
*Optional Properties: - reset-gpios: Reference to the GPIO connected to the
reset input.*And in
linux-4.1.13-ti-r35\Documentation\devicetree\bindings\i2c\i2c-mux-gpio.txt
they have it used within the example as follows
*i2cmux {compatible = "i2c-mux-gpio";#address-cells =
<1>;#size-cells = <0>;mux-gpios = <&gpio1 22 0 &gpio1 23
0>;i2c-parent = <&i2c1>;i2c@1 {reg = <1>;
#address-cells = <1>;#size-cells = <0>;
ssd1307: oled@3c {compatible = "solomon,ssd1307fb-i2c";
reg = <0x3c>;pwms = <&pwm 4 3000>;
reset-gpios = <&gpio2 7 1>;reset-active-low;
};};*Issue is I cannot compile my overlay IF the line *reset-gpios
= <&gpio1 18 0> *is present,
I've also tried adding this to my &am33xx_pinmux fragment:
*gpio50: gpio50{pinctrl-single,pins = <0x048 0x17>; /*
Define gpio50, set fast, pull-up, Mode 7 */ };*and changing the line in
question to:
*reset-gpios = <&gpio50>*I've also seen it written as "reset-gpio ="
without the s but that also fails.
Currently I can get around not having a reset by having my bootscript
toggle that GPIO on boot but without the script, I cannot get it to work.
I don't understand if I am suppose to "include" or reference anything
within my dts in order to use certain syntax and I have no idea how to do
it.
So I'd like two questions answered if possible,
*1) What am I doing wrong by adding that line2) How do I compile a dts with
"includes"?*Thank you in advance.
--
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] Overlay loaded elsewhere?
Issue was resolved, I failed to define an array of control pins in my overlay and as a result I was seeing the following error message: [4.043248] of_resolve_phandles: Could not find symbol 'i2c1_pins' I didn't see this error message since I was using 'dmesg | grep bone' to narrow the search field. Thanks for the help Robert. On Wednesday, December 16, 2015 at 10:22:58 AM UTC-5, RobertCNelson wrote: > > On Wed, Dec 16, 2015 at 9:18 AM, Bruce Glazier > wrote: > > I did a dmesg | grep bone and I gave you the only relevant error > messages > > but here is the entire result: > > > > [0.00] Kernel command line: console=tty0 console=ttyO0,115200n8 > > bone_cap > > emgr.disable_partno=BB-BONELT-HDMI bone_capemgr.enable_partno=EARS-NST > > root=/dev > > /mmcblk0p2 rootfstype=ext4 rootwait coherent_pool=1M quiet > > [3.801573] bone_capemgr bone_capemgr: Baseboard: > > 'A335BNLT,00C0,2315BBBK28A8 > > ' > > [3.801614] bone_capemgr bone_capemgr: > > compatible-baseboard=ti,beaglebone-bla > > ck - #slots=4 > > [3.842926] bone_capemgr bone_capemgr: Invalid signature '' > at > > slot 0 > > [3.850178] bone_capemgr bone_capemgr: slot #0: No cape found > > [3.908696] bone_capemgr bone_capemgr: slot #1: No cape found > > [3.968691] bone_capemgr bone_capemgr: slot #2: No cape found > > [4.028692] bone_capemgr bone_capemgr: slot #3: No cape found > > [4.034505] bone_capemgr bone_capemgr: enabled_partno PARTNO > 'EARS-NST' > > VER ' > > N/A' PR '0' > > [4.034519] bone_capemgr bone_capemgr: slot #4: override > > [4.034534] bone_capemgr bone_capemgr: Using override eeprom data at > slot > > 4 > > [4.034550] bone_capemgr bone_capemgr: slot #4: 'Override Board > > Name,00A0,Ove > > rride Manuf,EARS-NST' > > [4.034950] bone_capemgr bone_capemgr: initialized OK. > > [5.048949] bone_capemgr bone_capemgr: loader: failed to load slot-4 > > EARS-NST > > :00A0 (prio 0) > > > > I'm wondering if I can get specifics on why it failed to load. > > I'm willing to go threw any measures (no matter how daunting) to have > that > > capability but I do need a little guidance. > > Okay, usually you should see a pin-conflict. But this looks like maybe > the wrong dtc compiler.. > > which version? (we usually install it to /usr/local/bin/dtc as the > 3.8-dtc is in bin) > > /usr/local/bin/dtc --version > > https://github.com/beagleboard/bb.org-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] Overlay loaded elsewhere?
So I am trying to figure out where the capemgr is loading my overlay from because when I replace the existing file in /lib/firmware I am not seeing any of the changes I've made becoming active. In fact, if I delete my .dtbo from /lib/firmware and any other directory the system is still able to load that overlay. Some system information: BeagleBoard.org Debian Image 2015-10-11 4.1.13-ti-r35 Also I am running the image from a microSD card but I also have a working image on the eMMC. I've ensured that the file doesn't exist on the eMMC image, although I'm not sure if that matters. Is the file stored somewhere else other than /lib/firmware after being loaded? Thank you, Bruce -- 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] 4.1 repo
Robert, Any updates on this? I just moved from r21 to r35 and created the DTC for my TLV320AIC3104 as specified here: https://github.com/beagleboard/bb.org-overlays/commits/master/src/arm/BB-BONE-AUDI-02-00A0.dts I can see and configure the device but it chokes on speaker-test; it makes one blip on the output then freezes. Does the audio output bug persist? Thank you, Bruce On Monday, August 10, 2015 at 10:19:10 AM UTC-4, RobertCNelson wrote: > > On Mon, Aug 10, 2015 at 9:05 AM, Shadi Abdu-Rahman > wrote: > > > >> > >> there are some issues with the audio rev b, but i can't find that > >> board for sale anywhere anymore. (i have the rev a) > >> > > > > Hi Robert, > > > > Could you elaborate on the issues you're seeing with the Audio Cape? I'm > > having trouble using the audio system as described here, and I'm > wondering > > if it's the same Transmit Buffer Underflow problems you're seeing. > > Most of the issues are now fixed: > > > https://github.com/beagleboard/bb.org-overlays/blob/master/src/arm/BB-BONE-AUDI-02-00A0.dts > > > > https://github.com/beagleboard/bb.org-overlays/commits/master/src/arm/BB-BONE-AUDI-02-00A0.dts > > > But i think audio (output) was still not working.. > > Now that the reset bug has a workaround, i'll try and look at audio > again today.. > > 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: Windows 7 (64bit) USB issue, BeagleBoneBlack shows up under "Other devices"
Hi Steve, I am having this problem and I was hoping you could clarify on what you said. You rebuilt the g_multi.ko and copied to the BBB, what exactly is involved in doing that? Could you recommend a resource that will provide instructions? I will continue to look as I research this myself. Thanks, Bruce On Thursday, January 22, 2015 at 5:49:57 AM UTC-5, Steve Osselton wrote: > > I had a problem using the latest TI kernel and the windows USB/ethernet > driver. Seemed to be some issue with the > windows driver expecting RNDIS where the kernel USB gadget support was > configured to support both CDC ECM and > RNDIS by default. Changing the USB gadget support to just support RNDIS > solved the problem (usb/ethernet worked > with both Linux and Windows). In fact just copied in a rebuilt g_multi.ko > and rebooted to fix. > > Cheers Steve. > -- 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.
