[beagleboard] Beaglebone black power-up fail.

[Hee-cheol Yang]

Hello
I bought beagle bone balck a few days ago (<= 1 week), decause my previous BBB 
doesn’t work suddenly. But the new one also got the same problem after using it 
for several days.
To be specific, when I plugged-in the 5V-2A adapter or mini-USB connector to 
the board, the power LED blinks one time for <= 1sec. Then the board doesn’t 
wake up.

Is it the hardware or software issue? And any suggestions to revive my boards?

Best regards
Heecheol yang.

-- 
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/BY2PR14MB0328105636E5D24835684450E6360%40BY2PR14MB0328.namprd14.prod.outlook.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] PocketBeagle USB1 power using VIN or BATT

[Patrick Poirier]

I am planning to feed the Pocket using VIN (VIN_AC), or Battery (VIN_BAT)

I am using USB WIFI dongle connected as the wiki 
https://github.com/beagleboard/pocketbeagle/wiki/FAQ#how-do-i-get-additional-usb-connections.
And according to this:  = The Pocket is a HOST By default in the current 
software, the system should be configured to use this port as a host. 

When I supply power using USB0 , WIFI works ok, 
but when I feed from P1_1 (VIN) or P2_14, the systems gives this error at 
boot:
[1.269429] musb-hdrc musb-hdrc.1: VBUS_ERROR in a_wait_vrise (81, 
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/add49795-fff9-4ba6-80f1-4e75e08cedd5%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Re: PocketBeagle USB1 power using VIN or BATT

[Patrick Poirier]

Le dimanche 10 décembre 2017 12:57:53 UTC-5, Patrick Poirier a écrit :
>
> I am planning to feed the Pocket using VIN (VIN_AC), or Battery (VIN_BAT)
>
> I am using USB WIFI dongle connected as the wiki 
>
> https://github.com/beagleboard/pocketbeagle/wiki/FAQ#how-do-i-get-additional-usb-connections
> .
> And according to this:  = The Pocket is a HOST By default in the current 
> software, the system should be configured to use this port as a host. 
>
> When I supply power using USB0 , WIFI works ok, 
> but when I feed from P1_1 (VIN) or P2_14, the systems gives this error at 
> boot:
> [1.269429] musb-hdrc musb-hdrc.1: VBUS_ERROR in a_wait_vrise (81, 
>  [1.421860] musb-hdrc musb-hdrc.1: VBUS_ERROR in a_wait_vrise (80, 
> 
> Do I have to implement a full USB host system using a TPS2051 to get the 
> WIFI dongle working with VIN or Battery?
>
> Note: I see a reference here about jumping VIN to USB , is it really safe ?
https://beagleboard.org/pocket?place=msg%2Fbeagleboard%2FSWNBrgsjIeA%2F3VZCRZ-vAAAJ
 

-- 
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/047ee32f-b139-477d-8329-beaf8a4e4f92%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Re: PocketBeagle USB1 Question

[Patrick Poirier]

Hello, I am planning to use this setup, Have you successfully implemented 
and completed tests ?

Regards


Le vendredi 17 novembre 2017 13:11:59 UTC-5, wi...@geomonkey.com a écrit :

> Graham --
>
> Thanks for the advice! That totally makes sense. I now intend to try this 
> configuration to get the added USB1 working in host mode (e.g., to control 
> a Sony camera using the gphoto2 library):
>
>
> 
>
> These USB power switch ICs (e.g., Diodes Incorporated AP2822AKATR-G1, Richtek 
> RT9711CGB, 
> Richtek RT9742JNGV) limit current, prevent reverse current, etc., and 
> cost less than a dollar. I'll report back about whether this ends up 
> working okay.
>
> -- Will
>  
>
> On Thursday, November 16, 2017 at 5:10:48 PM UTC-7, Graham wrote:
>>
>> Your first connection does not work, because you are trying to power the 
>> USB1 from the USB_VIN, but since the is no power going into USB_VIN on 
>> USB-0, there is no power to come out USB-1.
>> This only works when the board is powered from USB-0
>> The schematic does not tell you, but USB_VIN, USB0_VIN and USB1_VIN are 
>> all connected together.
>>
>> VIN is a totally separate power supply input
>>
>> Since you are powering the board from VIN (P1-01) you need to hook the 5V 
>> line on your Micro-USB board to P1-01 and P1-05.
>>
>> In this case, it will work, although you have no current limit protection 
>> from a short on the 5V line in a downstream USB device, which is required 
>> by the USB spec.
>> So, only plug in USB devices and cables you trust.
>>
>> I would not power the USB-5V-VBUS from the SYS-VOUT, because SYS-VOUT is 
>> limited to 0.2 A or so, and many USB devices draw more current than this 
>> (USB-2 devices are allowed to draw up to 0.9 A)
>>
>> --- Graham
>>
>> ==
>>
>> On Thursday, November 16, 2017 at 5:11:52 PM UTC-6, wi...@geomonkey.com 
>> wrote:
>>>
>>> I, too, am wondering about the best way to provide power to the board 
>>> and to a device connected to USB1 as host. Here is how I learned to hook up 
>>> a micro-b breakout to USB1 and also how I intend to provide power to the 
>>> board. The problem is that there is no measured voltage at USB1:
>>>
>>>
>>> 
>>>
>>> I was wondering if I could just power the USB1 device from P1_24 SYS 
>>> VOUT (which does have power when board is supplied by P1_01 SYS VIN) like 
>>> this:
>>>
>>>
>>> 
>>> Would it be harmful to do it this way? Are there better ways to 
>>> accomplish this? Thanks!
>>>
>>> -- Will Bain
>>>
>>>
>>> On Sunday, November 5, 2017 at 6:59:39 PM UTC-7, Graham wrote:

 Further research, looking at the Eagle board and schematic files for 
 the PB, it appears that USB0.VIN and USB1.VIN are both directly connected 
 to VIN.USB
 Which explains why I had no power on my USB1 host port when connected 
 like the Fritzing diagram, since I am powering from VIN currently.

 So the question becomes,,,
 What is the best way to power USB1 VBUS as a host if I don't know in 
 advance whether the customer application will run from VIN or VIN.USB?

 --- Graham

 ==

 On Sunday, November 5, 2017 at 6:58:06 PM UTC-6, Graham wrote:
>
> I note that there is a PocketBeagle pin P1-7 named USB1-VIN.
>
> I don't find any connection on the PB schematic, other than to P1-7.
>
> It was connected externally in all of the USB1 host discussions and 
> Fritzing diagrams.
>
> The name would imply that it is a way to deliver power to the board 
> when USB1 has an external 5 Volt power source.
>
> I guess the basic question is whether this needs to be used/connected 
> when USB1 is functioning as a host.
>
> --- Graham
>
> ==
>


-- 
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/d3044b29-28b0-4b78-8dbd-5fe7d845206a%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] problem logging in with getty on beaglebone black

[onio]

I am learning Embedded Linux using the book titled "Mastering Embedded 
Linux Programming" by Chris Simmonds on page 131 of the second edition. He 
speak about adding the following lines to an "inittab" file in /etc when 
building a ram file system.

> There is a version of getty in BusyBox. You launch it from inittab using 
>> the keyword
>
> respawn, which restarts getty when a login shell is terminated, so inittab 
>> should read
>
> like this:
>
>
::sysinit:/etc/init.d/rcS
::respawn:/sbin/getty 115200 console

My problem is when I do this I can't seem to log in I get re-occurring 
message 
getty: can't open '/dev/null': No such file or directory

Any insight would be appreciated.

-- 
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/0e7a49e0-7c49-429a-8b12-2f05a23a932a%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] problem logging in with getty on beaglebone black

[Robert Nelson]

On Sun, Dec 10, 2017 at 2:37 PM, onio  wrote:
> I am learning Embedded Linux using the book titled "Mastering Embedded Linux
> Programming" by Chris Simmonds on page 131 of the second edition. He speak
> about adding the following lines to an "inittab" file in /etc when building
> a ram file system.
>>>
>>> There is a version of getty in BusyBox. You launch it from inittab using
>>> the keyword
>>>
>>> respawn, which restarts getty when a login shell is terminated, so
>>> inittab should read
>>>
>>> like this:
>
>
> ::sysinit:/etc/init.d/rcS
> ::respawn:/sbin/getty 115200 console
>
> My problem is when I do this I can't seem to log in I get re-occurring
> message
> getty: can't open '/dev/null': No such file or directory

Replace "console" with your actual serial link name..

BeagleBone Black: ttyO0

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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/CAOCHtYhpr9S%3DRtrHXt3er0vuNOoxJwzhPp8e39%3Dv4DfBXkMM8A%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Re: problem logging in with getty on beaglebone black

[onio]

All,

Please ignore my previous post. The last rootf I built didn't have the 
correct nodes installed 
$ cd ~/rootfs
$ sudo mknod -m 666 dev/null c 1 3
$ sudo mknod -m 600 dev/console c 5 1

Added the following command rebuilt the ram file system and all is well 
again. Thanks.



On Sunday, 10 December 2017 20:37:30 UTC, onio wrote:
>
> I am learning Embedded Linux using the book titled "Mastering Embedded 
> Linux Programming" by Chris Simmonds on page 131 of the second edition. He 
> speak about adding the following lines to an "inittab" file in /etc when 
> building a ram file system.
>
>> There is a version of getty in BusyBox. You launch it from inittab using 
>>> the keyword
>>
>> respawn, which restarts getty when a login shell is terminated, so 
>>> inittab should read
>>
>> like this:
>>
>>
> ::sysinit:/etc/init.d/rcS
> ::respawn:/sbin/getty 115200 console
>
> My problem is when I do this I can't seem to log in I get re-occurring 
> message 
> getty: can't open '/dev/null': No such file or directory
>
> Any insight would be appreciated.
>

-- 
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/205f88cf-96ef-45a3-965a-4e017a1c04f6%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] problem logging in with getty on beaglebone black

[onio]

Thanks Robert,

I fixed the issue as shown in my last post. Appreciate your time taken to 
reply.

Regards

onio

On Sunday, 10 December 2017 20:41:57 UTC, RobertCNelson wrote:
>
> On Sun, Dec 10, 2017 at 2:37 PM, onio > 
> wrote: 
> > I am learning Embedded Linux using the book titled "Mastering Embedded 
> Linux 
> > Programming" by Chris Simmonds on page 131 of the second edition. He 
> speak 
> > about adding the following lines to an "inittab" file in /etc when 
> building 
> > a ram file system. 
> >>> 
> >>> There is a version of getty in BusyBox. You launch it from inittab 
> using 
> >>> the keyword 
> >>> 
> >>> respawn, which restarts getty when a login shell is terminated, so 
> >>> inittab should read 
> >>> 
> >>> like this: 
> > 
> > 
> > ::sysinit:/etc/init.d/rcS 
> > ::respawn:/sbin/getty 115200 console 
> > 
> > My problem is when I do this I can't seem to log in I get re-occurring 
> > message 
> > getty: can't open '/dev/null': No such file or directory 
>
> Replace "console" with your actual serial link name.. 
>
> BeagleBone Black: ttyO0 
>
> 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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/12f2ebf0-b747-4633-84dc-5233eec9b954%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Re: PocketBeagle USB1 Question

[Graham Haddock]

Works fine.  As long as power/Vusb is on Vi  (P1-pin 7)
--- Graham

On Sun, Dec 10, 2017 at 12:18 PM, Patrick Poirier <
patrickpoirie...@gmail.com> wrote:

> Hello, I am planning to use this setup, Have you successfully implemented
> and completed tests ?
>
> Regards
>
>
> Le vendredi 17 novembre 2017 13:11:59 UTC-5, wi...@geomonkey.com a écrit :
>
>> Graham --
>>
>> Thanks for the advice! That totally makes sense. I now intend to try this
>> configuration to get the added USB1 working in host mode (e.g., to control
>> a Sony camera using the gphoto2 library):
>>
>>
>> 
>>
>> These USB power switch ICs (e.g., Diodes Incorporated AP2822AKATR-G1, 
>> Richtek RT9711CGB,
>> Richtek RT9742JNGV) limit current, prevent reverse current, etc., and
>> cost less than a dollar. I'll report back about whether this ends up
>> working okay.
>>
>> -- Will
>>
>>
>> On Thursday, November 16, 2017 at 5:10:48 PM UTC-7, Graham wrote:
>>>
>>> Your first connection does not work, because you are trying to power the
>>> USB1 from the USB_VIN, but since the is no power going into USB_VIN on
>>> USB-0, there is no power to come out USB-1.
>>> This only works when the board is powered from USB-0
>>> The schematic does not tell you, but USB_VIN, USB0_VIN and USB1_VIN are
>>> all connected together.
>>>
>>> VIN is a totally separate power supply input
>>>
>>> Since you are powering the board from VIN (P1-01) you need to hook the
>>> 5V line on your Micro-USB board to P1-01 and P1-05.
>>>
>>> In this case, it will work, although you have no current limit
>>> protection from a short on the 5V line in a downstream USB device, which is
>>> required by the USB spec.
>>> So, only plug in USB devices and cables you trust.
>>>
>>> I would not power the USB-5V-VBUS from the SYS-VOUT, because SYS-VOUT is
>>> limited to 0.2 A or so, and many USB devices draw more current than this
>>> (USB-2 devices are allowed to draw up to 0.9 A)
>>>
>>> --- Graham
>>>
>>> ==
>>>
>>> On Thursday, November 16, 2017 at 5:11:52 PM UTC-6, wi...@geomonkey.com
>>> wrote:

 I, too, am wondering about the best way to provide power to the board
 and to a device connected to USB1 as host. Here is how I learned to hook up
 a micro-b breakout to USB1 and also how I intend to provide power to the
 board. The problem is that there is no measured voltage at USB1:


 

 I was wondering if I could just power the USB1 device from P1_24 SYS
 VOUT (which does have power when board is supplied by P1_01 SYS VIN) like
 this:


 
 Would it be harmful to do it this way? Are there better ways to
 accomplish this? Thanks!

 -- Will Bain


 On Sunday, November 5, 2017 at 6:59:39 PM UTC-7, Graham wrote:
>
> Further research, looking at the Eagle board and schematic files for
> the PB, it appears that USB0.VIN and USB1.VIN are both directly connected
> to VIN.USB
> Which explains why I had no power on my USB1 host port when connected
> like the Fritzing diagram, since I am powering from VIN currently.
>
> So the question becomes,,,
> What is the best way to power USB1 VBUS as a host if I don't know in
> advance whether the customer application will run from VIN or VIN.USB?
>
> --- Graham
>
> ==
>
> On Sunday, November 5, 2017 at 6:58:06 PM UTC-6, Graham wrote:
>>
>> I note that there is a PocketBeagle pin P1-7 named USB1-VIN.
>>
>> I don't find any connection on the PB schematic, other than to P1-7.
>>
>> It was connected externally in all of the USB1 host discussions and
>> Fritzing diagrams.
>>
>> The name would imply that it is a way to deliver power to the board
>> when USB1 has an external 5 Volt power source.
>>
>> I guess the basic question is whether this needs to be used/connected
>> when USB1 is functioning as a host.
>>
>> --- Graham
>>
>> ==
>>
> --
> 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/SWNBrgsjIeA/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> beagleboard+unsubscr...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/
> msgid/beagleboard/d3044b29-28b0-4b78-8dbd-5fe7d845206a%40googlegroups.com
> 

Re: [beagleboard] Re: PocketBeagle USB1 Question

[William Bain]

I have had it running almost like this (but with just a wire in place of
the USB power switch module) for a few hours each day for the last couple
weeks or so, and haven't let the magic blue smoke out of my device yet! I
plugged a wi-fi dongle into the added USB jack, and the dongle gets pretty
hot to the touch, but it works fine and the heat doesn't seem to cause any
problems. Haven't tried controlling a camera with it yet.

-- Will

On Sun, Dec 10, 2017 at 2:08 PM, Graham Haddock 
wrote:

> Works fine.  As long as power/Vusb is on Vi  (P1-pin 7)
> --- Graham
>
> On Sun, Dec 10, 2017 at 12:18 PM, Patrick Poirier <
> patrickpoirie...@gmail.com> wrote:
>
>> Hello, I am planning to use this setup, Have you successfully implemented
>> and completed tests ?
>>
>> Regards
>>
>>
>> Le vendredi 17 novembre 2017 13:11:59 UTC-5, wi...@geomonkey.com a
>> écrit :
>>
>>> Graham --
>>>
>>> Thanks for the advice! That totally makes sense. I now intend to try
>>> this configuration to get the added USB1 working in host mode (e.g., to
>>> control a Sony camera using the gphoto2 library):
>>>
>>>
>>> 
>>>
>>> These USB power switch ICs (e.g., Diodes Incorporated AP2822AKATR-G1, 
>>> Richtek RT9711CGB,
>>> Richtek RT9742JNGV) limit current, prevent reverse current, etc., and
>>> cost less than a dollar. I'll report back about whether this ends up
>>> working okay.
>>>
>>> -- Will
>>>
>>>
>>> On Thursday, November 16, 2017 at 5:10:48 PM UTC-7, Graham wrote:

 Your first connection does not work, because you are trying to power
 the USB1 from the USB_VIN, but since the is no power going into USB_VIN on
 USB-0, there is no power to come out USB-1.
 This only works when the board is powered from USB-0
 The schematic does not tell you, but USB_VIN, USB0_VIN and USB1_VIN are
 all connected together.

 VIN is a totally separate power supply input

 Since you are powering the board from VIN (P1-01) you need to hook the
 5V line on your Micro-USB board to P1-01 and P1-05.

 In this case, it will work, although you have no current limit
 protection from a short on the 5V line in a downstream USB device, which is
 required by the USB spec.
 So, only plug in USB devices and cables you trust.

 I would not power the USB-5V-VBUS from the SYS-VOUT, because SYS-VOUT
 is limited to 0.2 A or so, and many USB devices draw more current than this
 (USB-2 devices are allowed to draw up to 0.9 A)

 --- Graham

 ==

 On Thursday, November 16, 2017 at 5:11:52 PM UTC-6, wi...@geomonkey.com
 wrote:
>
> I, too, am wondering about the best way to provide power to the board
> and to a device connected to USB1 as host. Here is how I learned to hook 
> up
> a micro-b breakout to USB1 and also how I intend to provide power to the
> board. The problem is that there is no measured voltage at USB1:
>
>
> 
>
> I was wondering if I could just power the USB1 device from P1_24 SYS
> VOUT (which does have power when board is supplied by P1_01 SYS VIN) like
> this:
>
>
> 
> Would it be harmful to do it this way? Are there better ways to
> accomplish this? Thanks!
>
> -- Will Bain
>
>
> On Sunday, November 5, 2017 at 6:59:39 PM UTC-7, Graham wrote:
>>
>> Further research, looking at the Eagle board and schematic files for
>> the PB, it appears that USB0.VIN and USB1.VIN are both directly connected
>> to VIN.USB
>> Which explains why I had no power on my USB1 host port when connected
>> like the Fritzing diagram, since I am powering from VIN currently.
>>
>> So the question becomes,,,
>> What is the best way to power USB1 VBUS as a host if I don't know in
>> advance whether the customer application will run from VIN or VIN.USB?
>>
>> --- Graham
>>
>> ==
>>
>> On Sunday, November 5, 2017 at 6:58:06 PM UTC-6, Graham wrote:
>>>
>>> I note that there is a PocketBeagle pin P1-7 named USB1-VIN.
>>>
>>> I don't find any connection on the PB schematic, other than to P1-7.
>>>
>>> It was connected externally in all of the USB1 host discussions and
>>> Fritzing diagrams.
>>>
>>> The name would imply that it is a way to deliver power to the board
>>> when USB1 has an external 5 Volt power source.
>>>
>>> I guess the basic question is whether this needs to be
>>> used/connected when USB1 is functioning as a host.
>>>
>>> ---

[beagleboard] Problems with BeagleBoard-X15 GPIO fan control and lm-sensors

[David Stein]

I'm working with an X15, and the fan is driving me crazy.

I'm using the recommended heatsink and fan from Digi-Key (the 5V 
F251R: https://www.digikey.com/products/en?keywords=X15FANKIT-ND ). The fan 
works, but it constantly turns on and off on what seems to be a completely 
random basis. Has no relationship with actual CPU load, either.

I'm delving into Debian's fan control package, lm-sensors, and I've found 
this:

sensors


...which outputs this:

gpio_fan-isa-
Adapter: ISA adapter
fan1:   0 RPM  (min =0 RPM, max = 13000 RPM)

tmp102-i2c-0-48
Adapter: OMAP I2C adapter
temp1:+41.4°C  (high = +160.0°C, hyst = +150.0°C)


That's certainly informative, but those set points are insane: I don't want 
it getting anywhere near 160°C, or even 150°C for that matter. I presume 
that someone was aiming for Fahrenheit values. These settings also indicate 
a problem: if tmp102-i2c-0-48 were actually controlling the fan, it would 
never turn on - it would probably be fried long before it hit either of 
those values.

The settings command allows me to query both devices for settable 
properties:

gpio_fan-isa-
Adapter: ISA adapter
fan1:
  fan1_input: 13000.000
  fan1_min: 0.000
  fan1_max: 13000.000

tmp102-i2c-0-48
Adapter: OMAP I2C adapter
temp1:
  temp1_input: 42.375
  temp1_max: 160.000
  temp1_max_hyst: 150.000


And I can also change them by creating /etc/sensors.d/x15-config with the 
following:

chip "tmp102*"
set temp1_max 41
set temp1_max_hyst 39

 
After either running "sensors -s" to reload settings or just rebooting, the 
sensors -u command shows that tmp102-i2c has accepted the override values. 
Unfortunately, it doesn't affect the annoying fan behavior one bit. 
Reported CPU temperature is over 41, so it should run constantly until it's 
under 39... no dice. Same behavior.

At this point, I can't figure out what is actually controlling the fan, 
especially not in this manner. I'm ready to chalk it up to either a flaky 
fan or a faulty GPIO or... something.

Anyone have any ideas?

-- 
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/a025c298-c6ff-4ae5-97c5-dc06884d0744%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Re: PocketBeagle USB1 Question

[Patrick Poirier]

OK its working, decided to play safe, so everything is on jumpers ;-)




Le dimanche 10 décembre 2017 17:37:50 UTC-5, William Bain a écrit :
>
> I have had it running almost like this (but with just a wire in place of 
> the USB power switch module) for a few hours each day for the last couple 
> weeks or so, and haven't let the magic blue smoke out of my device yet! I 
> plugged a wi-fi dongle into the added USB jack, and the dongle gets pretty 
> hot to the touch, but it works fine and the heat doesn't seem to cause any 
> problems. Haven't tried controlling a camera with it yet.
>
> -- Will
>
> On Sun, Dec 10, 2017 at 2:08 PM, Graham Haddock  > wrote:
>
>> Works fine.  As long as power/Vusb is on Vi  (P1-pin 7)
>> --- Graham
>>
>> On Sun, Dec 10, 2017 at 12:18 PM, Patrick Poirier > > wrote:
>>
>>> Hello, I am planning to use this setup, Have you successfully 
>>> implemented and completed tests ?
>>>
>>> Regards
>>>
>>>
>>> Le vendredi 17 novembre 2017 13:11:59 UTC-5, wi...@geomonkey.com a 
>>> écrit :
>>>
 Graham --

 Thanks for the advice! That totally makes sense. I now intend to try 
 this configuration to get the added USB1 working in host mode (e.g., to 
 control a Sony camera using the gphoto2 library):


 

 These USB power switch ICs (e.g., Diodes Incorporated AP2822AKATR-G1, 
 Richtek RT9711CGB, 
 Richtek RT9742JNGV) limit current, prevent reverse current, etc., and 
 cost less than a dollar. I'll report back about whether this ends up 
 working okay.

 -- Will
  

 On Thursday, November 16, 2017 at 5:10:48 PM UTC-7, Graham wrote:
>
> Your first connection does not work, because you are trying to power 
> the USB1 from the USB_VIN, but since the is no power going into USB_VIN 
> on 
> USB-0, there is no power to come out USB-1.
> This only works when the board is powered from USB-0
> The schematic does not tell you, but USB_VIN, USB0_VIN and USB1_VIN 
> are all connected together.
>
> VIN is a totally separate power supply input
>
> Since you are powering the board from VIN (P1-01) you need to hook the 
> 5V line on your Micro-USB board to P1-01 and P1-05.
>
> In this case, it will work, although you have no current limit 
> protection from a short on the 5V line in a downstream USB device, which 
> is 
> required by the USB spec.
> So, only plug in USB devices and cables you trust.
>
> I would not power the USB-5V-VBUS from the SYS-VOUT, because SYS-VOUT 
> is limited to 0.2 A or so, and many USB devices draw more current than 
> this 
> (USB-2 devices are allowed to draw up to 0.9 A)
>
> --- Graham
>
> ==
>
> On Thursday, November 16, 2017 at 5:11:52 PM UTC-6, 
> wi...@geomonkey.com wrote:
>>
>> I, too, am wondering about the best way to provide power to the board 
>> and to a device connected to USB1 as host. Here is how I learned to hook 
>> up 
>> a micro-b breakout to USB1 and also how I intend to provide power to the 
>> board. The problem is that there is no measured voltage at USB1:
>>
>>
>> 
>>
>> I was wondering if I could just power the USB1 device from P1_24 SYS 
>> VOUT (which does have power when board is supplied by P1_01 SYS VIN) 
>> like 
>> this:
>>
>>
>> 
>> Would it be harmful to do it this way? Are there better ways to 
>> accomplish this? Thanks!
>>
>> -- Will Bain
>>
>>
>> On Sunday, November 5, 2017 at 6:59:39 PM UTC-7, Graham wrote:
>>>
>>> Further research, looking at the Eagle board and schematic files for 
>>> the PB, it appears that USB0.VIN and USB1.VIN are both directly 
>>> connected 
>>> to VIN.USB
>>> Which explains why I had no power on my USB1 host port when 
>>> connected like the Fritzing diagram, since I am powering from VIN 
>>> currently.
>>>
>>> So the question becomes,,,
>>> What is the best way to power USB1 VBUS as a host if I don't know in 
>>> advance whether the customer application will run from VIN or VIN.USB?
>>>
>>> --- Graham
>>>
>>> ==
>>>
>>> On Sunday, November 5, 2017 at 6:58:06 PM UTC-6, Graham wrote:

 I note that there is a PocketBeagle pin P1-7 named USB1-VIN.

 I don't find a

Re: [beagleboard] Problems with BeagleBoard-X15 GPIO fan control and lm-sensors

[Robert Nelson]

On Sun, Dec 10, 2017 at 5:50 PM, David Stein  wrote:
> I'm working with an X15, and the fan is driving me crazy.
>
> I'm using the recommended heatsink and fan from Digi-Key (the 5V F251R:
> https://www.digikey.com/products/en?keywords=X15FANKIT-ND ). The fan works,
> but it constantly turns on and off on what seems to be a completely random
> basis. Has no relationship with actual CPU load, either.
>
> I'm delving into Debian's fan control package, lm-sensors, and I've found
> this:
>
> sensors
>
>
> ...which outputs this:
>
> gpio_fan-isa-
> Adapter: ISA adapter
> fan1:   0 RPM  (min =0 RPM, max = 13000 RPM)
>
> tmp102-i2c-0-48
> Adapter: OMAP I2C adapter
> temp1:+41.4°C  (high = +160.0°C, hyst = +150.0°C)
>
>
> That's certainly informative, but those set points are insane: I don't want
> it getting anywhere near 160°C, or even 150°C for that matter. I presume
> that someone was aiming for Fahrenheit values. These settings also indicate
> a problem: if tmp102-i2c-0-48 were actually controlling the fan, it would
> never turn on - it would probably be fried long before it hit either of
> those values.
>
> The settings command allows me to query both devices for settable
> properties:
>
> gpio_fan-isa-
> Adapter: ISA adapter
> fan1:
>   fan1_input: 13000.000
>   fan1_min: 0.000
>   fan1_max: 13000.000
>
> tmp102-i2c-0-48
> Adapter: OMAP I2C adapter
> temp1:
>   temp1_input: 42.375
>   temp1_max: 160.000
>   temp1_max_hyst: 150.000
>
>
> And I can also change them by creating /etc/sensors.d/x15-config with the
> following:
>
> chip "tmp102*"
> set temp1_max 41
> set temp1_max_hyst 39
>
>
> After either running "sensors -s" to reload settings or just rebooting, the
> sensors -u command shows that tmp102-i2c has accepted the override values.
> Unfortunately, it doesn't affect the annoying fan behavior one bit. Reported
> CPU temperature is over 41, so it should run constantly until it's under
> 39... no dice. Same behavior.
>
> At this point, I can't figure out what is actually controlling the fan,
> especially not in this manner. I'm ready to chalk it up to either a flaky
> fan or a faulty GPIO or... something.
>
> Anyone have any ideas?

So here's the patch:

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/arch/arm/boot/dts/am57xx-beagle-x15.dts?h=v4.15-rc2&id=d723cfeafc7b4c73e89ed3d4b1a4d747e990872c

You'll need to patch the dtb to play* around with different C values
for cpu_trips/thermal_zones..  The values originally used where just a
best guess.  (the am5728 is rated for -40 <-> 105 C)

You can use dtb-rebuilder for this:

https://github.com/RobertCNelson/dtb-rebuilder

Use either the 4.4-ti, 4.9-ti, or 4.14-ti branches matching your
booting kernel..

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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/CAOCHtYjG5M01vmSvW0FtMVJHgrY8_-CkEAddYP0EXp6vnO3dKg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] Problems with BeagleBoard-X15 GPIO fan control and lm-sensors

[David Stein]

Robert:

Wow - thank you! I'll give it a shot.

Regards,

David Stein

On Sunday, December 10, 2017 at 7:29:50 PM UTC-5, RobertCNelson wrote:
>
> On Sun, Dec 10, 2017 at 5:50 PM, David Stein  > wrote: 
> > I'm working with an X15, and the fan is driving me crazy. 
> > 
> > I'm using the recommended heatsink and fan from Digi-Key (the 5V F251R: 
> > https://www.digikey.com/products/en?keywords=X15FANKIT-ND ). The fan 
> works, 
> > but it constantly turns on and off on what seems to be a completely 
> random 
> > basis. Has no relationship with actual CPU load, either. 
> > 
> > I'm delving into Debian's fan control package, lm-sensors, and I've 
> found 
> > this: 
> > 
> > sensors 
> > 
> > 
> > ...which outputs this: 
> > 
> > gpio_fan-isa- 
> > Adapter: ISA adapter 
> > fan1:   0 RPM  (min =0 RPM, max = 13000 RPM) 
> > 
> > tmp102-i2c-0-48 
> > Adapter: OMAP I2C adapter 
> > temp1:+41.4°C  (high = +160.0°C, hyst = +150.0°C) 
> > 
> > 
> > That's certainly informative, but those set points are insane: I don't 
> want 
> > it getting anywhere near 160°C, or even 150°C for that matter. I presume 
> > that someone was aiming for Fahrenheit values. These settings also 
> indicate 
> > a problem: if tmp102-i2c-0-48 were actually controlling the fan, it 
> would 
> > never turn on - it would probably be fried long before it hit either of 
> > those values. 
> > 
> > The settings command allows me to query both devices for settable 
> > properties: 
> > 
> > gpio_fan-isa- 
> > Adapter: ISA adapter 
> > fan1: 
> >   fan1_input: 13000.000 
> >   fan1_min: 0.000 
> >   fan1_max: 13000.000 
> > 
> > tmp102-i2c-0-48 
> > Adapter: OMAP I2C adapter 
> > temp1: 
> >   temp1_input: 42.375 
> >   temp1_max: 160.000 
> >   temp1_max_hyst: 150.000 
> > 
> > 
> > And I can also change them by creating /etc/sensors.d/x15-config with 
> the 
> > following: 
> > 
> > chip "tmp102*" 
> > set temp1_max 41 
> > set temp1_max_hyst 39 
> > 
> > 
> > After either running "sensors -s" to reload settings or just rebooting, 
> the 
> > sensors -u command shows that tmp102-i2c has accepted the override 
> values. 
> > Unfortunately, it doesn't affect the annoying fan behavior one bit. 
> Reported 
> > CPU temperature is over 41, so it should run constantly until it's under 
> > 39... no dice. Same behavior. 
> > 
> > At this point, I can't figure out what is actually controlling the fan, 
> > especially not in this manner. I'm ready to chalk it up to either a 
> flaky 
> > fan or a faulty GPIO or... something. 
> > 
> > Anyone have any ideas? 
>
> So here's the patch: 
>
>
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/arch/arm/boot/dts/am57xx-beagle-x15.dts?h=v4.15-rc2&id=d723cfeafc7b4c73e89ed3d4b1a4d747e990872c
>  
>
> You'll need to patch the dtb to play* around with different C values 
> for cpu_trips/thermal_zones..  The values originally used where just a 
> best guess.  (the am5728 is rated for -40 <-> 105 C) 
>
> You can use dtb-rebuilder for this: 
>
> https://github.com/RobertCNelson/dtb-rebuilder 
>
> Use either the 4.4-ti, 4.9-ti, or 4.14-ti branches matching your 
> booting kernel.. 
>
> 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.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/80f5ac6f-e4eb-4d7f-9d2f-4dbdc9a1d19f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Re: Problems with BeagleBoard-X15 GPIO fan control and lm-sensors

[David Stein]

Robert: I haven't quite solved the problem, but I've made some progress. 
Reporting back both FYI and to help anyone else with this problem.

I downloaded your dtb-rebuilder and spent some time looking at it. I 
anticipated having to write those changes into the patched file, but as it 
happened, I found that they're already included in 
am57xx-beagle-x15-common.dtsi. I checked the more specific file 
(am57xx-beagle-x15-revc.dts) to verify that it didn't have any overriding 
settings.

I built the DTB:

make all
make install

...and verified that /usr/bin/dtb (aliased to /usr/bin/local/dtb) had been 
updated. So far, so good.

I rebooted and found that device behavior hadn't changed. But at least I 
had a lead as to where the behavior was controlled.

I tried tweaking the hystersis values in common.dtsi, making sure that the 
most relevant hysteresis values are reasonably large:

cpu_alert1: cpu_alert1 {

hysteresis = <2000>; /* millicelsius */

};

board_alert0: board_alert {

hysteresis = <5000>; /* millicelsius */

};

board_crit: board_crit {

hysteresis = <1000>; /* millicelsius */

};


I rebuilt, reinstalled, and rebooted... no change in behavior - the fan 
still turned on and off every couple of seconds. Watching the output of 
tmp102 via sensors, I can see that the CPU temperature only fluctuates 
about 0.1-0.2 C between fan cycles. I set them even higher - up to 5000 mC. 
Rebuild, reinstall, reboot... no effect.

I realized that I could tackle the problem in a more crude way - by 
increasing the temperature polling frequency... bordering on stupidly large:

&thermal_zones {

board_thermal: board_thermal {

polling-delay-passive = <3>; /* milliseconds */

polling-delay = <3>; /* milliseconds */

};

};


Rebuild, reinstall, reboot - that seems to have worked. Well, kind of. The 
fan typically cycles in 30-second intervals now. Oddly, it's not 100% of 
the time: sometimes it conducts three or four 30-second on/off cycles and 
then exhibits a few short cycles (like: turning on just long enough to get 
up to speed, turning off just long enough to stop, and then turning on for 
30 seconds again).

Honestly, though, this solves the immediate problem: rapid fan cycling was 
both getting on my nerves, and creating some concerns about wear and tear 
from constantly turning on and off. I suppose I can live with a 30-second 
cycle time.

However, I'm still really puzzled by the inconsistent behavior: why 
hysteresis temperatures didn't work, and why the cycle time doesn't seem to 
be fixed. Curious results that bear further exploration.

Regards,

David Stein

-- 
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/92c25c25-09a4-4edf-ae93-9e1c34cc37e6%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Re: fsck fails to start on writable partition at boot/startup

[mindentropy]

On Saturday, December 9, 2017 at 1:47:29 AM UTC+5:30, Dennis Lee Bieber 
wrote:
>
>
> Prior to a lay-off, my last four years were avionics -- 
> fortunately 
> mostly maintenance work for existing software (since my prior 30 years 
> experience qualified as "mainframe number crunching", so the entire 
> embedded/real-time world was a new experience). 
>
> No experience with use of an OS as Linux in such applications -- 
> from 
> what I could tell, general-purpose OS with real file-systems was only 
> approved for things like monitoring/logging systems wherein the loss of 
> the 
> system would have no effect on the operation of the aircraft itself. 
>
> The rest tended to follow two concepts: 
>
> A) operation out of Flash memory (similar to what one would find on an 
> Arduino, TIVA C, and similar boards). 
>
> B) operation out of RAM with firmware loaded from Flash memory (closer to 
> BBx/R-Pi, except the Flash is not a general file system and is read-only) 
>
> Both likely used some sort of RTOS providing the core of tasking 
> and 
> IPC (and the highest level having fixed time-slice assigned to tasks with 
> watch-dogs for overrun detection). In both, analysts created memory maps 
> defining what code/data is placed where in memory. 
>
> (A) tended to have just one copy of the firmware/data in the layout; 
> (B) tended to have two copies allowing for swap-over if the boot-up checks 
> detected corruption (and reducing the odds of "bricking" when loading 
> updates into one copy) 
>
> In both, CRC checks were run during booting before passing control 
> to 
> the real RTOS/application. Data regions tended to have CRC checks 
> performed 
> periodically during operation (one assignment involved a board with 
> expanded Flash memory -- where the person responsible for the CRC found he 
> had to run it in phases as the new data region was too large to be CRCd in 
> the allowed time-slot). In (B) the CRC was also run before loading the 
> code 
> into RAM. 
>
> A CRC failure would result in the code going into a "halt" state 
> (usually implemented as an endless loop) or an attempt to restart the 
> processor -- while control of the craft went to the second flight 
> computer. 
>
> Power-glitches (ever watch all the lights flicker on a passenger 
> jet 
> while they swap over from ground generator to engine generators?) trigger 
> state save, and later checks of RAM contents (the restart logic would 
> check 
> a timer -- capacitor bleed down -- to determine if it needed to do full 
> reboot or take a fast start path), if reading all the RAM does not trigger 
> a CRC error, control is passed to the application at the position saved. 
> While a glitch was considered ~10 seconds with no power, it seems some 
> boards could keep RAM stable for hours after loss of power. 
> -- 
> Wulfraed Dennis Lee Bieber AF6VN 
> wlf...@ix.netcom.com HTTP://wlfraed.home.netcom.com/ 
>
>
Thanks a lot for the insight. This is very interesting and something which 
I have seen in medical implants too. There were a lot of checks with the 
scheduler and also their queues which I don't seem to recall. Also as you 
have said I too have seen/worked mostly on microcontrollers with some type 
of qualified RTOS for such regulated devices. Also as you have noticed 
usually they relegated the Application processor with Linux for monitoring.


Although I have not explored it, I feel that the design can be made much 
better now with the availability of Cortex M4 in AM57x and the i.MX7 
series. With this you have the Application processor and the 
microcontroller in the same die thereby shrinking the board to a huge 
extent and also making development much more compact and also simplifying 
the implementation of safety to the system.

The safety checks can be implemented during boot-up can be done using the 
POST framework in the boot loader. I have yet to explore this deeply and 
the possibilities are good.

-Gautam.

-- 
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/57004cdb-b52b-464a-85e2-a60c65ae018c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.