020110348 wrote:I too am wondering, if i could use the same button to apply "Sudo Halt" and use the Wake Function?
Say i have a "Power" button, if the RPi is "halted" it wakes it, if the RPi is on it issues a "Sudo Halt" command. now how can i issue a sudo halt command and be sure it is entered?
e.x running an application like "startx" or an emulator, than want to shutdown, how can that happen?
I was wondering how low the power usage is when RaspberryPi is halted. Connecting my multimeter, it seems that my model B takes about 110mA, which is 0.55W. It is almost 1/4 of the power consumption when turned on (and idle) but still quite high - it's almost the same as model's A power usage when turned on. Did anybody do similar experiments (especially on model A)?dom wrote:The Pi goes into a lower powered state.
I would like to know what parts you used and how you connected them all together. Couldn't find this on your homepage.Dweeber wrote:Holidays were a blur... Finally got a chance to upgrade my test unit which is on a Adafruit Pi plate to a current kernel that has the new Halt code in it. I already had switches setup to test this with the pre-release before the code made it into the mainstream kernel.
Works like a champ.
Now using two switches (red and green) a couple resistors and a green LED, I am about to solder up some kits to allow me to upgrade my other units so that they have a Request Stop (Red) button, Restart Button (Green) and Green LED to show status of the OS (if OS is running) that I can then mount on the top of the cases I have for the other RPi.
I have a script which runs to watch for the Request Stop button, which when it sees it, tells the OS to do a shutdown.
All of my RPi are headless (no keyboard) so this will allow me to do a safe shutdown, see if it is already running and restart it if needed.
use a model A ;-pkadamski wrote:Yes I was aware of where the power goes, that's why I was interested in the same measurement on model A. And I found it in the tread you linked to - 0.2W, not that bad. Now if only the LAN chip could be put in some deeper power safe mode..
Thanks for the link.
"Just connect pin 1 to a momentary open switch, and the switch to a 1K and a 10K resistor. Then connect the 10K resistor to the ground on pin 9 and the 1K to pin 17."
Quoted from: http://www.3cc.org/blog/2013/01/raspber ... ff-the-pi/
dom wrote:This scheme avoids reloading bootcode.bin, but otherwise the two schemes are pretty much identical (as long you have a rev2 board).KenT wrote:Is there any practical difference between this and the Reset pin P6 introduced on the Rev. 2 board.
"sudo halt" by itself actually starts "shutdown -h now" for you.mcgyver83 wrote:So any suggestion? I usually use shutdown -h now, is the same as sudo halt?
So I can add the wake/reset switch (reset pin or gpio way) and everything should be fine?
B+ wake from halt OK with RUN, anything else to try?dom wrote:Can anyone test this file:
https://dl.dropboxusercontent.com/u/366 ... otcode.bin
Replace the one on boot partition.
I'd like to know any of the following:
Does B+ still wake from halt?
Does B+ spuriously wake from halt when prodded with fingers?
Does a rev2 model A/B still behave as before?
Does a rev1 model A/B still behave as before?
Yes. This was fixed prior to the B+ launch in rpi-update firmware, but not the apt-get firmware.jojopi wrote:Incidentally, this suggests that bootcode.bin is revision-aware. It had been reported that it used the wrong GPIO for ACT LED, or otherwise configures GPIO16 as an output on a B+ (and perhaps on CM). Is that fixed too?
Ah yes. LAN_RUN used to be an output with a pull-down. With the gpioman commit the pull-down has gone. I'll fix that...jojopi wrote:I have noticed another halt state anomaly (not new with this bootcode, but I think it may be recent). On some Model Bs the Ethernet PHY and LEDs can remain fully powered while the SoC is halted. (Depending on distro, this may need "halt -fp" so that the kernel does not explicitly down eth0 before returning to GPU.)
Attempting to probe pin12 on the 9512 immediately stops the PHY. I suspect GPIO6 (LAN_RUN) is floating during halt when in old firmware it used to be pulled down.
(I have never really understood why firmware floats any GPIOs, rather than keeping them in pull states. Especially since the CM documentation appears to recommend against floating.)
Can you add this file to boot partition of sdcard:jojopi wrote:I have noticed another halt state anomaly (not new with this bootcode, but I think it may be recent). On some Model Bs the Ethernet PHY and LEDs can remain fully powered while the SoC is halted. (Depending on distro, this may need "halt -fp" so that the kernel does not explicitly down eth0 before returning to GPU.)
It's a compiled device tree file. When the .dtc version is made available, it will be very easy to modify.jojopi wrote:Yes, that fixes it.
(Intriguing file format is fun to modify!)
But it is the job of people with such degrees to make it simple for those not so fortunate.gsh wrote:I'm just in the process of adding the clock management to the dt-blob.bin to allow people to also define the clock configuration themselves, unfortunately you'll need a degree in hard stuff to understand how the clock management works in the first place!