Hello,
any idea what's required for system power on via usb device?
On said system power-on via ps/2 keyboard already works.
I immagine that even if the original bios does not support it, it merely means that the 1st hard power-on won't work. However, I think that 2nd and subsequent soft power off/on cycles would work if the system would be put in stand-by mode in the right way.
* Shaddam Corrino IV shaddamcorrinoiv@gmail.com [061221 16:21]:
I immagine that even if the original bios does not support it, it merely means that the 1st hard power-on won't work.
USB power on must be supported by the mainboard and chipset as well. Only if the hardware is designed to do it, the bios has a chance.
However, I think that 2nd and subsequent soft power off/on cycles would work if the system would be put in stand-by mode in the right way.
What do you mean by that?
USB power on must be supported by the mainboard and chipset as well.
However, I think that 2nd and subsequent
soft power off/on cycles would work if the system would be put in
stand-by mode
in the right way.
What do you mean by that?
That I do not think I need original PC bios support for usb wake up if I myself program the chipset from linux before putting PC into suspend state.
Either way, I made partial progress, but then I got stuck.
chipset/datasheet : i440BX - iPIIX4-i82371AB-29056201.pdf
chapter 7.2 - pg 137 - Power Management IO Space Registers chapter 7.2.3 - pg 138 - Base + 04h = Set Power On Suspend chapter 7.2.6 - pg 140 - Base + 0Eh = USB_EN
# lspci -s 00:07.3 00:07.3 Bridge: Intel Corporation 82371AB/EB/MB PIIX4 ACPI (rev 02)
# setpci -D -v -s 00:07.3 40.L
00:07.3:40 = 00004001
# cat /proc/ioports | grep 00:07.3
4000-403f : 0000:00:07.3 5000-500f : 0000:00:07.3
So this means that at offset 0x4000 at IO space should be the PM stuff that I could modify, but when I read space, I get all 0xFF's so that's not working :-(
# dd bs=1 skip=13500 if=/dev/port count=60 | od -t x1 -v
0000000 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff 0000020 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff 0000040 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff 0000060 ff ff ff ff ff ff ff ff ff ff ff
/dev/port itself works at least for low numbers.
"X" = 0x58 ASCII # printf "\x58" | dd bs=1 seek=128 of=/dev/port # dd bs=1 skip=128 if=/dev/port count=1 above correctly shows "X" on screen.
but no idea so far why I can't read the PM space.
So this means that at offset 0x4000 at IO space should be the PM stuff that I could modify, but when I read space, I get all 0xFF's so that's not working :-(
# dd bs=1 skip=13500 if=/dev/port count=60 | od -t x1 -v
13500 isn't anywhere near 0x4000. Try writing skip=$((0x4000)) if you have problems with hexadecimal arithmetic -- computers can do it fine ;-)
Segher
On 12/22/06, Segher Boessenkool segher@kernel.crashing.org wrote:
So this means that at offset 0x4000 at IO space should be the PM stuff that I could modify, but when I read space, I get all 0xFF's so that's not working :-(
# dd bs=1 skip=13500 if=/dev/port count=60 | od -t x1 -v
13500 isn't anywhere near 0x4000. Try writing skip=$((0x4000)) if you have problems with hexadecimal arithmetic -- computers can do it fine ;-)
Thanks a lot!
The problem was that I did
# echo "ibase=F;4000" | bc -lq instead of # echo "ibase=16;5000" | bc -lq bc can be nasty about this since format for ibase depends on what base you set before.
either way your trick is far better, and now I get meaningfull data:
# dd bs=1 skip=$((0x4000)) if=/dev/port count=60 | od -t x1 -v 60+0 przeczytanych recordów 60+0 zapisanych recordów skopiowane 60 bajtów (60 B), 0,00331573 sekund, 18,1 kB/s 0000000 11 00 20 04 01 00 00 00 03 fb 54 00 00 00 00 00 0000020 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0000040 40 00 10 40 00 00 00 00 81 00 50 00 15 00 00 58 0000060 ff 03 00 00 1e 00 00 00 01 00 00 00 0000074
Once again thanks :-)
# dd bs=1 skip=$((0x4000)) if=/dev/port count=60 | od -t x1 -v
60+0 przeczytanych recordów
60+0 zapisanych recordów skopiowane 60 bajtów (60 B), 0,00331573 sekund, 18,1 kB/s 0000000 11 00 20 04 01 00 00 00 03 fb 54 00 00 00 00 00 0000020 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0000040 40 00 10 40 00 00 00 00 81 00 50 00 15 00 00 58 0000060 ff 03 00 00 1e 00 00 00 01 00 00 00 0000074
ugh, slight correction. The above data is for a different machine (forgot to login into 440bx). Trying the above on the 440bx will hang it hard.
FWIW, it is the partial (probably sufficent) read for 440bx # dd bs=1 skip=$((0x4000)) if=/dev/port count=15 | od -t x1 -v 15+0 records in 15+0 records out 15 bytes (15 B) copied, 0.000205221 seconds, 73.1 kB/s 0000000 11 00 00 01 00 14 00 00 2e 19 97 00 01 08 00 0000017
base+4 = suspend type base+E = usb_en
FWIW, partial success
# sleep 1 ; printf "\x20" | dd bs=1 seek=$((0x4000+4+1)) of=/dev/port count=1 >& /dev/null sytem power off. # sleep 1 ; printf "\x24" | dd bs=1 seek=$((0x4000+4+1)) of=/dev/port count=1 >& /dev/null stops playing video, system hangs # sleep 1 ; printf "\x28" | dd bs=1 seek=$((0x4000+4+1)) of=/dev/port count=1 >& /dev/null system reboot # sleep 1 ; printf "\x2C" | dd bs=1 seek=$((0x4000+4+1)) of=/dev/port count=1 >& /dev/null stops playing video, screen is lit, resumes on usb event # sleep 1 ; printf "\x30" | dd bs=1 seek=$((0x4000+4+1)) of=/dev/port count=1 >& /dev/null stops playing video, screen is lit, resumes on usb event
however, I still haven't gotten to the point where either * "suspend -s 00:01" wakes up on usb event. or * "suspend -S 00:01" does not wake up on eth event.
or some other method for "power on suspend"+USB to work.
On Thu, Dec 21, 2006 at 04:21:18PM +0100, Shaddam Corrino IV wrote:
However, I think that 2nd and subsequent soft power off/on cycles would work if the system would be put in stand-by mode in the right way.
If the system is suspended it is not power on, but resume or wakeup.
Wake-on-USB could be done just as Wake-on-LAN but it would trigger pretty often since USB host controllers are very thin devices, as opposed to a network controller.
//Peter
On 12/22/06, Peter Stuge stuge-linuxbios@cdy.org wrote:
On Thu, Dec 21, 2006 at 04:21:18PM +0100, Shaddam Corrino IV wrote:
However, I think that 2nd and subsequent soft power off/on cycles would work if the system would be put in stand-by mode in the right way.
If the system is suspended it is not power on, but resume or wakeup.
Wake-on-USB could be done just as Wake-on-LAN but it would trigger pretty often since USB host controllers are very thin devices, as opposed to a network controller.
I found out that the "apmsleep -s 00:01" (with little 's') does not wake up on either network or usb. However, "apmsleep -S 00:01" does almost what I want. The apmsleep with big S does not seem to shut down hdd, but I can do that using hdparm.
I have problem since the "apmsleep" with big S does not only wake up (correctly) on USB, but also on broadcast network packets! Disabling "wake up on network" in BIOS won't help, nor ethtool
# ethtool -s eth0 wol g Cannot get current wake-on-lan settings: Operation not supported not setting wol # dmesg | grep eth eth0: Lite-On 82c168 PNIC rev 32 at ca812000, 00:A0:CC:62:2B:2A, IRQ 10.
Argh!
-
Peter Stuge -
Segher Boessenkool -
Shaddam Corrino IV -
Stefan Reinauer