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?
shutdown -P now
— Graham
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.
syslog (74.6 KB)
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,
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.
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
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.
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.
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.
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.
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.
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.
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.
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.
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