d/freebsd-dev
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity
7c9dcdde00
freebsd-dev/sys/i386/bios/apm_init/apm_init.inc

62 lines
3.1 KiB
PHP
Raw Normal View History

Laptop Advanced Power Management support by HOSOKAWA Tatsumi. Submitted by: HOSOKAWA Tatsumi
1994-10-01 02:56:21 +00:00
/* This file is automatically generated by bin2asm */
/* Original file is 'apm_init' */
On my GW2K Handbook486 this code would reset when called from locore.s I think I have narrowed this down to the stack being overflown. I have taken the push/pop of %fs out, it shouldn't be needed anyway, but the real & correct solution might to save the registers on the stack in locore.s before calling this stuff.
1994-10-01 21:29:50 +00:00
.byte 0xfa, 0x55, 0x66, 0x8c, 0xd8, 0x66, 0x8e, 0xe0
.byte 0x66, 0xb8, 0xf0, 0x00, 0x66, 0x8e, 0xd8, 0x66
This is the latest version of the APM stuff from HOSOKAWA, I have looked briefly over it, and see some serious architectural issues in this stuff. On the other hand, I doubt that we will have any solution to these issues before 2.1, so we might as well leave this in. Most of the stuff is bracketed by #ifdef's so it shouldn't matter too much in the normal case. Reviewed by: phk Submitted by: HOSOKAWA, Tatsumi <hosokawa@mt.cs.keio.ac.jp>
1995-02-17 02:22:57 +00:00
.byte 0x8e, 0xc0, 0x66, 0x8e, 0xd0, 0x89, 0x25, 0x94
On my GW2K Handbook486 this code would reset when called from locore.s I think I have narrowed this down to the stack being overflown. I have taken the push/pop of %fs out, it shouldn't be needed anyway, but the real & correct solution might to save the registers on the stack in locore.s before calling this stuff.
1994-10-01 21:29:50 +00:00
.byte 0x01, 0x00, 0x00, 0xbc, 0x00, 0x00, 0x01, 0x00
This is the latest version of the APM stuff from HOSOKAWA, I have looked briefly over it, and see some serious architectural issues in this stuff. On the other hand, I doubt that we will have any solution to these issues before 2.1, so we might as well leave this in. Most of the stuff is bracketed by #ifdef's so it shouldn't matter too much in the normal case. Reviewed by: phk Submitted by: HOSOKAWA, Tatsumi <hosokawa@mt.cs.keio.ac.jp>
1995-02-17 02:22:57 +00:00
.byte 0x0f, 0x01, 0x0d, 0xb0, 0x01, 0x00, 0x00, 0xe8
.byte 0x24, 0x01, 0x00, 0x00, 0xb4, 0x53, 0xb0, 0x00
Laptop Advanced Power Management support by HOSOKAWA Tatsumi. Submitted by: HOSOKAWA Tatsumi
1994-10-01 02:56:21 +00:00
.byte 0x66, 0xbb, 0x00, 0x00, 0x00, 0x00, 0xfb, 0xcd
This is the latest version of the APM stuff from HOSOKAWA, I have looked briefly over it, and see some serious architectural issues in this stuff. On the other hand, I doubt that we will have any solution to these issues before 2.1, so we might as well leave this in. Most of the stuff is bracketed by #ifdef's so it shouldn't matter too much in the normal case. Reviewed by: phk Submitted by: HOSOKAWA, Tatsumi <hosokawa@mt.cs.keio.ac.jp>
1995-02-17 02:22:57 +00:00
.byte 0x15, 0xfa, 0x73, 0x15, 0x66, 0xe8, 0xde, 0x00
.byte 0x00, 0x00, 0xc7, 0x05, 0x98, 0x01, 0x00, 0x00
.byte 0xff, 0xff, 0xff, 0xff, 0xe9, 0x92, 0x00, 0x00
.byte 0x00, 0x89, 0xc2, 0x66, 0xe8, 0xc7, 0x00, 0x00
On my GW2K Handbook486 this code would reset when called from locore.s I think I have narrowed this down to the stack being overflown. I have taken the push/pop of %fs out, it shouldn't be needed anyway, but the real & correct solution might to save the registers on the stack in locore.s before calling this stuff.
1994-10-01 21:29:50 +00:00
.byte 0x00, 0x80, 0xff, 0x50, 0x75, 0x05, 0x80, 0xfb
This is the latest version of the APM stuff from HOSOKAWA, I have looked briefly over it, and see some serious architectural issues in this stuff. On the other hand, I doubt that we will have any solution to these issues before 2.1, so we might as well leave this in. Most of the stuff is bracketed by #ifdef's so it shouldn't matter too much in the normal case. Reviewed by: phk Submitted by: HOSOKAWA, Tatsumi <hosokawa@mt.cs.keio.ac.jp>
1995-02-17 02:22:57 +00:00
.byte 0x4d, 0x74, 0x0c, 0xc7, 0x05, 0x98, 0x01, 0x00
.byte 0x00, 0xff, 0xff, 0xff, 0xff, 0xeb, 0x74, 0xf7
On my GW2K Handbook486 this code would reset when called from locore.s I think I have narrowed this down to the stack being overflown. I have taken the push/pop of %fs out, it shouldn't be needed anyway, but the real & correct solution might to save the registers on the stack in locore.s before calling this stuff.
1994-10-01 21:29:50 +00:00
.byte 0xc1, 0x02, 0x00, 0x00, 0x00, 0x75, 0x0c, 0xc7
This is the latest version of the APM stuff from HOSOKAWA, I have looked briefly over it, and see some serious architectural issues in this stuff. On the other hand, I doubt that we will have any solution to these issues before 2.1, so we might as well leave this in. Most of the stuff is bracketed by #ifdef's so it shouldn't matter too much in the normal case. Reviewed by: phk Submitted by: HOSOKAWA, Tatsumi <hosokawa@mt.cs.keio.ac.jp>
1995-02-17 02:22:57 +00:00
.byte 0x05, 0x98, 0x01, 0x00, 0x00, 0xfe, 0xff, 0xff
.byte 0xff, 0xeb, 0x60, 0x81, 0xe2, 0xff, 0xff, 0x00
.byte 0x00, 0x89, 0x15, 0x98, 0x01, 0x00, 0x00, 0x81
.byte 0xe1, 0xff, 0xff, 0x00, 0x00, 0x89, 0x0d, 0x9c
.byte 0x01, 0x00, 0x00, 0xe8, 0xb0, 0x00, 0x00, 0x00
.byte 0xb4, 0x53, 0xb0, 0x03, 0x66, 0xbb, 0x00, 0x00
.byte 0x00, 0x00, 0xfb, 0xcd, 0x15, 0xfa, 0x73, 0x12
.byte 0x66, 0xe8, 0x6a, 0x00, 0x00, 0x00, 0xc7, 0x05
.byte 0x98, 0x01, 0x00, 0x00, 0xfd, 0xff, 0xff, 0xff
.byte 0xeb, 0x21, 0x89, 0xc5, 0x66, 0xe8, 0x56, 0x00
.byte 0x00, 0x00, 0xb8, 0xff, 0xff, 0x00, 0x00, 0x21
.byte 0xc5, 0x21, 0xc1, 0x21, 0xc2, 0x21, 0xc6, 0x21
.byte 0xc7, 0xc1, 0xe5, 0x10, 0x09, 0xe9, 0xc1, 0xe7
.byte 0x10, 0x09, 0xfe, 0xfa, 0x0f, 0x01, 0x1d, 0xb0
.byte 0x01, 0x00, 0x00, 0x8b, 0x25, 0x94, 0x01, 0x00
.byte 0x00, 0x8b, 0x2d, 0x98, 0x01, 0x00, 0x00, 0x8b
.byte 0x3d, 0x9c, 0x01, 0x00, 0x00, 0x66, 0x8c, 0xe0
.byte 0x66, 0x8e, 0xd0, 0x66, 0x8e, 0xc0, 0x66, 0x8e
.byte 0xd8, 0x31, 0xc0, 0x66, 0x8e, 0xe0, 0x89, 0xe8
.byte 0x5d, 0xcb, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00
On my GW2K Handbook486 this code would reset when called from locore.s I think I have narrowed this down to the stack being overflown. I have taken the push/pop of %fs out, it shouldn't be needed anyway, but the real & correct solution might to save the registers on the stack in locore.s before calling this stuff.
1994-10-01 21:29:50 +00:00
.byte 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00
Laptop Advanced Power Management support by HOSOKAWA Tatsumi. Submitted by: HOSOKAWA Tatsumi
1994-10-01 02:56:21 +00:00
.byte 0xfa, 0x0f, 0x20, 0xc0, 0x66, 0x83, 0xc8, 0x01
This is the latest version of the APM stuff from HOSOKAWA, I have looked briefly over it, and see some serious architectural issues in this stuff. On the other hand, I doubt that we will have any solution to these issues before 2.1, so we might as well leave this in. Most of the stuff is bracketed by #ifdef's so it shouldn't matter too much in the normal case. Reviewed by: phk Submitted by: HOSOKAWA, Tatsumi <hosokawa@mt.cs.keio.ac.jp>
1995-02-17 02:22:57 +00:00
.byte 0x0f, 0x22, 0xc0, 0x66, 0xea, 0x33, 0x01, 0x00
Laptop Advanced Power Management support by HOSOKAWA Tatsumi. Submitted by: HOSOKAWA Tatsumi
1994-10-01 02:56:21 +00:00
.byte 0x00, 0xe8, 0x00, 0xb8, 0xf0, 0x00, 0x00, 0x00
.byte 0x66, 0x8e, 0xd8, 0x66, 0x8e, 0xd0, 0x66, 0x8e
This is the latest version of the APM stuff from HOSOKAWA, I have looked briefly over it, and see some serious architectural issues in this stuff. On the other hand, I doubt that we will have any solution to these issues before 2.1, so we might as well leave this in. Most of the stuff is bracketed by #ifdef's so it shouldn't matter too much in the normal case. Reviewed by: phk Submitted by: HOSOKAWA, Tatsumi <hosokawa@mt.cs.keio.ac.jp>
1995-02-17 02:22:57 +00:00
.byte 0xc0, 0x0f, 0x01, 0x1d, 0xb0, 0x01, 0x00, 0x00
Laptop Advanced Power Management support by HOSOKAWA Tatsumi. Submitted by: HOSOKAWA Tatsumi
1994-10-01 02:56:21 +00:00
.byte 0xc3, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00
This is the latest version of the APM stuff from HOSOKAWA, I have looked briefly over it, and see some serious architectural issues in this stuff. On the other hand, I doubt that we will have any solution to these issues before 2.1, so we might as well leave this in. Most of the stuff is bracketed by #ifdef's so it shouldn't matter too much in the normal case. Reviewed by: phk Submitted by: HOSOKAWA, Tatsumi <hosokawa@mt.cs.keio.ac.jp>
1995-02-17 02:22:57 +00:00
.byte 0xa1, 0x90, 0x01, 0x00, 0x00, 0xc1, 0xf8, 0x04
.byte 0x66, 0x50, 0x66, 0xb8, 0x72, 0x01, 0x66, 0x50
.byte 0xea, 0x67, 0x01, 0x00, 0x00, 0xf8, 0x00, 0x0f
Laptop Advanced Power Management support by HOSOKAWA Tatsumi. Submitted by: HOSOKAWA Tatsumi
1994-10-01 02:56:21 +00:00
.byte 0x20, 0xc0, 0x66, 0x83, 0xe0, 0xfe, 0x0f, 0x22
.byte 0xc0, 0xcb, 0x66, 0x8c, 0xc8, 0x66, 0x8e, 0xd8
.byte 0x66, 0x8e, 0xd0, 0x66, 0x8e, 0xc0, 0x67, 0x66
This is the latest version of the APM stuff from HOSOKAWA, I have looked briefly over it, and see some serious architectural issues in this stuff. On the other hand, I doubt that we will have any solution to these issues before 2.1, so we might as well leave this in. Most of the stuff is bracketed by #ifdef's so it shouldn't matter too much in the normal case. Reviewed by: phk Submitted by: HOSOKAWA, Tatsumi <hosokawa@mt.cs.keio.ac.jp>
1995-02-17 02:22:57 +00:00
.byte 0x0f, 0x01, 0x1d, 0xb6, 0x01, 0x00, 0x00, 0x66
Laptop Advanced Power Management support by HOSOKAWA Tatsumi. Submitted by: HOSOKAWA Tatsumi
1994-10-01 02:56:21 +00:00
.byte 0xc3, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00
.byte 0x00, 0x00, 0x08, 0x00, 0x00, 0x00, 0x00, 0x00
.byte 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00
.byte 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00
.byte 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00
.byte 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0xff, 0x03
.byte 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00
This is the latest version of the APM stuff from HOSOKAWA, I have looked briefly over it, and see some serious architectural issues in this stuff. On the other hand, I doubt that we will have any solution to these issues before 2.1, so we might as well leave this in. Most of the stuff is bracketed by #ifdef's so it shouldn't matter too much in the normal case. Reviewed by: phk Submitted by: HOSOKAWA, Tatsumi <hosokawa@mt.cs.keio.ac.jp>
1995-02-17 02:22:57 +00:00
/* Total size = 0x01c0 */
Reference in New Issue Copy Permalink