Reboot instead of shutdown

[ithinu]

I want to shutdown the board in order to have the sdcard in a consistent state.

  shutdown -h now

reboots instead. There is a discussion about this https://groups.google.com/d/msg/beagleboard/qw5zlS4F4p4/chu0J3VXKgAJ but I do not get the conclusion.

Is it possible to shutdown the board, if powered externally, without ahardware modification?

[Graham]

shutdown -P now

--- Graham

==

[ithinu]

shutdown -P now does the same as shutdown -h now: reboots the board. So I still do not know a way of shutting it down.

I attach the relevant part of syslog.

[Robert Nelson]

On Tue, Apr 25, 2017 at 5:00 PM, ithinu <artur...@gmail.com> wrote:
> shutdown -P now does the same as shutdown -h now: reboots the board. So I
> still do not know a way of shutting it down.
>
> I attach the relevant part of syslog.

I usually tell everyone to use:

sudo systemctl poweroff

as systemd knows how to tell the external tps65217 to cut power.

looking at the syslog, i don't remember any issues with 4.4.39-ti-r75,
and looking at the git log i don't see any poweroff regressions
mentioned..

Regards,

--
Robert Nelson
https://rcn-ee.com/

[William Hermans]

Every since I've been using systemd variants of Debian( Jessie ) I use the commands halt, and reboot. These work fine for me. Battery connected to the PMIC, or not. However, I have noticed with at least one of our custom capes, one of the USR leds comes back on, after a halt. No blinking pattern to indicate a reboot however.

So what I attribute this to is that the PMIC is powered back on, *maybe*. But with our custom capes, it does not matter, because we've built in external power management. e.g. The input voltage from AC power goes away, for whatever reason, our custom external power management disconnects the battery from the beaglebone, after 30 seconds, until 5vdc is back.

With no battery, this "problem" never manifests. But we feel the external power is still necessary, because of the occasional need for a processor reset. After power has been reapplied.

[Graham Haddock]

What OS/kernel is ithinu running?

"shutdown -P now" works on all my BBB/BBG boards.

But, I run from external +5V, without anything on the battery connections.

--- Graham

==

I usually tell everyone to use:

sudo systemctl poweroff

as systemd knows how to tell the external tps65217 to cut power.

looking at the syslog, i don't remember any issues with 4.4.39-ti-r75,
and looking at the git log i don't see any poweroff regressions
mentioned..

Regards,

--
Robert Nelson
https://rcn-ee.com/

--
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/9VdtZKf3Dz0/unsubscribe.
To unsubscribe from this group and all its topics, send an email to beagleboard+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/CAOCHtYgHtwySLzoGJOdRLwGKm34kPxxwz6GBj5BFwWYUUtbR9g%40mail.gmail.com.

For more options, visit https://groups.google.com/d/optout.

[ithinu]

The board is connected to a 5V power supply, to a USB hub and via Ethernet to a router. It has no capes.

uname -a
Linux beaglebone 4.4.39-ti-r75 #1 SMP Thu Dec 15 22:16:11 UTC 2016 armv7l GNU/Linux

The command

  sudo systemctl poweroff

reboots it just like

  shutdown -P now

However, if the board is disconnected from the USB hub (still connected to the power supply), both of the above commands shut the unit down as expected. I checked this several times: connecting even a running unit to USB makes it unable to shutdown. However, if powered from USB (power supply disconnected) the board shuts down again without a problem.

I tested this several times and it seems, that the only combination where the board can not shut down is when connected to both the power supply and USB at once. Which is ok as of me, as I do not need the USB connection any more.

There is an old thread (the kernel must obviously have been different) where a similar problem is reported by several people: https://groups.google.com/forum/#!msg/beagleboard/qw5zlS4F4p4/chu0J3VXKgAJ

On Wednesday, April 26, 2017 at 4:45:41 AM UTC+2, Graham wrote:

What OS/kernel is ithinu running?

"shutdown -P now" works on all my BBB/BBG boards.

But, I run from external +5V, without anything on the battery connections.

--- Graham

==

I usually tell everyone to use:

sudo systemctl poweroff

as systemd knows how to tell the external tps65217 to cut power.

looking at the syslog, i don't remember any issues with 4.4.39-ti-r75,
and looking at the git log i don't see any poweroff regressions
mentioned..

Regards,

--
Robert Nelson
https://rcn-ee.com/

--
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/9VdtZKf3Dz0/unsubscribe.

To unsubscribe from this group and all its topics, send an email to beagleboard...@googlegroups.com.

[William Hermans]

On Wed, Apr 26, 2017 at 8:31 AM, ithinu <artur...@gmail.com> wrote:

The board is connected to a 5V power supply, to a USB hub and via Ethernet to a router. It has no capes.

uname -a
Linux beaglebone 4.4.39-ti-r75 #1 SMP Thu Dec 15 22:16:11 UTC 2016 armv7l GNU/Linux

The command

  sudo systemctl poweroff

reboots it just like

  shutdown -P now

However, if the board is disconnected from the USB hub (still connected to the power supply), both of the above commands shut the unit down as expected. I checked this several times: connecting even a running unit to USB makes it unable to shutdown. However, if powered from USB (power supply disconnected) the board shuts down again without a problem.

I tested this several times and it seems, that the only combination where the board can not shut down is when connected to both the power supply and USB at once. Which is ok as of me, as I do not need the USB connection any more.

There is an old thread (the kernel must obviously have been different) where a similar problem is reported by several people: https://groups.google.com/forum/#!msg/beagleboard/qw5zlS4F4p4/chu0J3VXKgAJ

Without looking at the post, no it's probably not the same issue. Because if that is the topic I think it is. It would cause the boards to not boot. In either case I think the fix will be the same. You may need to do surgery on your USB hub, and remove the power back into the host aspect of the hub. e.g. it sounds very much like your getting backfeed power over the USB from your hub. On some boards( I've only heard of this with ODROID boards ), this can be caused by HDMI as well.

Short story, you're using a powered hub, and you need to keep that hub from sending power back into the host.

[ithinu]

> Short story, you're using a powered hub, and you need to keep that hub from sending power back into the host.

No, the hub is not powered. Also, as I said, the problem exists only with the combination power supply/usb connection, which I rarely need. But it still can be a problem of someone else.

So, I would guess, it is more of checking the issue by the board constructors before the next rev of BeagleBone. Especially that someone in the other thread reports that the problem is spotty. With an oscilloscope, power supplies of different power, capes or not, USB cables of different length etc., until the cause is apparent. Or just don't care :)

In any case, I can be of help, for example I can check if the problem persists with the board connected directly to a PC.

[William Hermans]

The issue in the post you linked to has to be different. Unless you've gone and reconfigured the USB OTG port, though software, which is possible. So while the problem Harvey was talking about in that post *could* be corrected through hardware changes. Making those changes would be less than ideal. As it would reduce the flexibility of the USB mini connector. There are two or possibly three different modes the USB mini connector could be configured into through software.

[William Hermans]

By the way those changes which I mentioned for the USB OTG port are made through device tree configurations. I think in the main board file, but that problem has been corrected so long ago, I do not remember exactly how.

Here, we do not connect to our boards in this manner, ever.I have one beaglebone black that I do power over that USB port here, but never with a barrel jack, or through the P9 header at the same time. We have a few capes we're working on, with different beaglebone greens. These are all powered through the P9 header, but communication is made through ethernet on those boards. Well actually, all the boards we have in our "lab" are connected via ethernet for communications.

[ithinu]

Perhaps a work-around would be to provide a software possibility of freezing the unit after the kernel is down. Handy for someone who has a power-hungry cape requiring a power supply, no Ethernet and would like to safely replace the sd card. If it were possible to detect, that the unit is going to reboot anyway, the freeze could even be chosen automatically if a shutdown is requested.

[William Hermans]

On Thu, Apr 27, 2017 at 9:53 AM, ithinu <artur...@gmail.com> wrote:

Perhaps a work-around would be to provide a software possibility of freezing the unit after the kernel is down. Handy for someone who has a power-hungry cape requiring a power supply, no Ethernet and would like to safely replace the sd card. If it were possible to detect, that the unit is going to reboot anyway, the freeze could even be chosen automatically if a shutdown is requested.

The source code for this hardware is all open source. As well as the hardware in general. So one can make any changes needed to software, or hardware on their own when they need specific functionality changes. The above is not meant as a smart or condescending remark. It's meant to impress on the point that the hardware was designed with cost in mind, and that the software for this hardware is provided free of charge. I am sure there is someone out in the world that would be happy to make these changes for you, if you're willing to pay their fee.

But I can sympathize, I understand where you're coming from. I've had to make software changes myself for various things I needed built into the system. Granted, I never needed this specific functionality myself, as I said in my previous post, we do not use our own boards in this specific manner. You may have to end up adapting your usage, or the software to conform to your own specific needs. But that's often how the open source world works.

[ithinu]

On Thu, Apr 27, 2017 at 7:26 PM, William Hermans <yyrkoon@gmail.com> wrote:

It's meant to impress on the point that the hardware was designed with cost in mind, and that the software for this hardware is provided free of charge.

I realize that. This is why I suggested a solution which a knowledgeable person might possibly write in few minutes (adding an option to a script?) and not for example a board modification, which would add to effort and cost.

 

I am sure there is someone out in the world that would be happy to make these changes for you, if you're willing to pay their fee.

Very likely, but this is about a third time when I write in this thread that I found a solution for myself (unplug an USB cable). Otherwise, I would add some statement to one of the shutdown script, but given how the Linux startup system is complex today, I doubt the fast fix would be on par with that made by a Linux professional. Or that the additional possibility would become a part of your FAQ etc.
 

But I can sympathize, I understand where you're coming from. I've had to make software changes myself for various things I needed built into the system. Granted, I never needed this specific functionality myself, as I said in my previous post, we do not use our own boards in this specific manner. You may have to end up adapting your usage, or the software to conform to your own specific needs. But that's often how the open source world works.

Sometimes (very often?) users report an issue to help the developers, and not to demand anything from them.

They do this e.g. out of gratitude.

[William Hermans]

It would not be part of "my" FAQ. I have no affiliation with beagleboard.org, at all. I'm just some guy, who has had 4+ years hands on experience with this specific platform, who also just so happens to get paid by a third party who builds systems based on this platform as well. But obviously I do not know everything.

I actually want to fix the way this board powers down when a battery is connected to the beaglebone, myself. Which means when I did into the guts of everything that is involved I could probably look into this problem as well.It's not something that is high priority in my life right now, but *is* something that I've spent money out of my own pocket on having hardware designed for. PCB's, and components, etc. Now, I just need the time to develop the software, which may, or may not happen some time soon.

[William Hermans]

So now I'm in pitbull mode, but I wont be able to do any further research at this time.

https://www.kernel.org/doc/Documentation/devicetree/bindings/usb/am33xx-usb.txt
. . .

USB
~~~
- compatible: ti,musb-am33xx
- reg: offset and length of "USB Controller Registers", and offset and
  length of "USB Core" register space.
- reg-names: control for the ""USB Controller Registers" and "mc" for
  "USB Core" register space
- interrupts: USB interrupt number
- interrupt-names: mc
- dr_mode: Should be one of "host", "peripheral" or "otg".
- mentor,multipoint: Should be "1" indicating the musb controller supports
  multipoint. This is a MUSB configuration-specific setting.
- mentor,num-eps: Specifies the number of endpoints. This is also a
  MUSB configuration-specific setting. Should be set to "16"
- mentor,ram-bits: Specifies the ram address size. Should be set to "12"
- mentor,power: Should be "500". This signifies the controller can supply up to
  500mA when operating in host mode.
- phys: reference to the USB phy
- dmas: specifies the dma channels
- dma-names: specifies the names of the channels. Use "rxN" for receive
  and "txN" for transmit endpoints. N specifies the endpoint number.

The controller should have an "usb" alias numbered properly in the alias
node.
. . .

You can try experimenting with the "mode" I've highlighted above. You'd have to modify this board file 
here: https://github.com/jadonk/cape-firmware/blob/master/arch/arm/boot/dts/am335x-bone-common.dtsi#L204

And recompile all of, or the single board file you use at boot time. Of course then you've have to move the old board file out of the way, and replace it with the one you built yourself.