video resume stuff

video resume stuff

[Pavel Machek]

Hi!

I'm thinking about how to clean up video resume/how to get it to work
for non-VESA video modes (jikos' case).

I guess the cleanest solution would be to just call set_mode from
wakeup.S.... but that is not as easy as I imagined, because bootup
code seems to be compiled separately.

Is there some easy way to retain bootup code in memory, so that wakeup
can use it? Or is there some easy solution I'm missing?

I came up with this, unfortunately it does not even link :-(.
									Pavel
diff --git a/arch/i386/kernel/acpi/Makefile b/arch/i386/kernel/acpi/Makefile
index 7f7be01..f6a0885 100644
--- a/arch/i386/kernel/acpi/Makefile
+++ b/arch/i386/kernel/acpi/Makefile
@@ -2,7 +2,10 @@ obj-$(CONFIG_ACPI)		+= boot.o
 ifneq ($(CONFIG_PCI),)
 obj-$(CONFIG_X86_IO_APIC)	+= earlyquirk.o
 endif
-obj-$(CONFIG_ACPI_SLEEP)	+= sleep.o wakeup.o
+obj-$(CONFIG_ACPI_SLEEP)	+= sleep.o wakeup.o ../../boot/a20.o       ../../boot/edd.o     ../../boot/pmjump.o      ../../boot/video-vesa.o ../../boot/apm.o  ../../boot/printf.o      ../../boot/video-vga.o ../../boot/cmdline.o    ../../boot/string.o      ../../boot/video.o ../../boot/copy.o      ../../boot/mca.o     ../../boot/tty.o         ../../boot/voyager.o ../../boot/cpu.o       ../../boot/memory.o  ../../boot/version.o ../../boot/cpucheck.o  ../../boot/pm.o      ../../boot/video-bios.o
+
+#   ../../boot/main.o
+
 
 ifneq ($(CONFIG_ACPI_PROCESSOR),)
 obj-y				+= cstate.o processor.o
diff --git a/arch/i386/kernel/acpi/wakeup.S b/arch/i386/kernel/acpi/wakeup.S
index f1c7484..3fd5cf6 100644
--- a/arch/i386/kernel/acpi/wakeup.S
+++ b/arch/i386/kernel/acpi/wakeup.S
@@ -2,6 +2,9 @@
 #include <linux/linkage.h>
 #include <asm/segment.h>
 #include <asm/page.h>
+#include <asm/boot.h>
+#include "../../boot/boot.h"
+
 
 #
 # wakeup_code runs in real mode, and at unknown address (determined at run-time).
@@ -28,6 +31,9 @@ #define BEEP \
 	movb	$15, %al; 	\
 	outb	%al, $66;
 
+	.globl	set_video
+	.type	set_video, @function
+	
 ALIGN
 	.align	4096
 ENTRY(wakeup_start)
@@ -71,7 +77,8 @@ #	BEEP
 	testl	$2, realmode_flags - wakeup_code
 	jz	1f
 	mov	video_mode - wakeup_code, %ax
-	call	mode_set
+	calll	set_video
+#	call	mode_set
 1:
 
 	# set up page table




-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Re: video resume stuff

[Arjan van de Ven]

On Thu, 4 Oct 2007 15:05:13 +0200
Pavel Machek <pavel@ucw.cz> wrote:

> Hi!
> 
> I'm thinking about how to clean up video resume/how to get it to work
> for non-VESA video modes (jikos' case).


I suspect in the medium run, the video mode setting stuff that's moving
into the kernel is the real answer to this problem... maybe it's more
efficient to move that in in a hurry ;)

Re: video resume stuff

[Pavel Machek]

> On Thu, 4 Oct 2007 15:05:13 +0200
> Pavel Machek <pavel@ucw.cz> wrote:
> 
> > Hi!
> > 
> > I'm thinking about how to clean up video resume/how to get it to work
> > for non-VESA video modes (jikos' case).
> 
> 
> I suspect in the medium run, the video mode setting stuff that's moving
> into the kernel is the real answer to this problem... maybe it's more
> efficient to move that in in a hurry ;)

Violently agreed... but we still want fallback for vesafb ;-).
									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Re: video resume stuff

[H. Peter Anvin]

Pavel Machek wrote:
> Hi!
> 
> I'm thinking about how to clean up video resume/how to get it to work
> for non-VESA video modes (jikos' case).
> 
> I guess the cleanest solution would be to just call set_mode from
> wakeup.S.... but that is not as easy as I imagined, because bootup
> code seems to be compiled separately.
> 
> Is there some easy way to retain bootup code in memory, so that wakeup
> can use it? Or is there some easy solution I'm missing?

No, not really.  The setup code is not even part of the kernel binary 
proper, and may not even have been run under certain circumstances.

The "easy" solution is to link it in again, which seems to be what 
you're doing.  Now, currently the boot code is compiled after vmlinux is 
complete, so some of the build ordering would have to be changed and/or 
some of the code rearranged.

I suggest we tackle this *after* the x86 merge.

	-hpa

Re: video resume stuff

[H. Peter Anvin]

Pavel Machek wrote:
>> On Thu, 4 Oct 2007 15:05:13 +0200
>> Pavel Machek <pavel@ucw.cz> wrote:
>>
>>> Hi!
>>>
>>> I'm thinking about how to clean up video resume/how to get it to work
>>> for non-VESA video modes (jikos' case).
>>
>> I suspect in the medium run, the video mode setting stuff that's moving
>> into the kernel is the real answer to this problem... maybe it's more
>> efficient to move that in in a hurry ;)
> 
> Violently agreed... but we still want fallback for vesafb ;-).

It should also be pointed out that the first mode setting might very 
well be different from an already-in-operation modeset, if the procedure 
that we have access to doesn't initialize everything necessary.

	-hpa

Re: video resume stuff

[Pavel Machek]

Hi!

> >I'm thinking about how to clean up video resume/how to get it to work
> >for non-VESA video modes (jikos' case).
> >
> >I guess the cleanest solution would be to just call set_mode from
> >wakeup.S.... but that is not as easy as I imagined, because bootup
> >code seems to be compiled separately.
> >
> >Is there some easy way to retain bootup code in memory, so that wakeup
> >can use it? Or is there some easy solution I'm missing?
> 
> No, not really.  The setup code is not even part of the kernel binary 
> proper, and may not even have been run under certain circumstances.
> 
> The "easy" solution is to link it in again, which seems to be what 
> you're doing.  Now, currently the boot code is compiled after vmlinux is 
> complete, so some of the build ordering would have to be changed and/or 
> some of the code rearranged.

I guess major change is to rename conflicting symbols, so that it is
possible to link it twice. That would mean boot_memset() instead of
memset() etc... Is that acceptable?

> I suggest we tackle this *after* the x86 merge.

Well, we still have the regression on jikos' strange system, and I
would like to understand what is going on there.
									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Re: video resume stuff

[Jiri Kosina]

On Fri, 5 Oct 2007, Pavel Machek wrote:

> > I suggest we tackle this *after* the x86 merge.
> Well, we still have the regression on jikos' strange system, and I would 
> like to understand what is going on there.

Sorry for this taking too long. Finally I had the time to play with this 
again, so here goes the current summary. I have a system here, that:

- with 1d67953f2bda8876045c24ae58841f27d9bb7572 (just before the setup 
  code rewrite), resumes nicely in VGA console 
  (acpi_sleep=s3_bios,s3_mode kernel parameter is needed), everything 
  works

- with c39736823232bc3ca113c8228fa852c09fba300e (just after the setup code 
  rewrite), VGA text console is garbled after resume - looks like the 
  video RAM contains some strange data (patterns from BIOS post can be 
  recognized, there are some various-colored stripes across the screen, 
  etc). The machine also seems to be frozen (no keyboard LEDs working, 
  etc).

- with 2.6.23-rc9, the video doesn't come up at all, I can't even see the 
  garbled picture any more - the display stays blank, the LED diod is 
  yellow (i.e. looks like completely no signal from VGA card). On the 
  other hand, the machine seems to work otherwise

-- 
Jiri Kosina

Re: video resume stuff

[H. Peter Anvin]

Pavel Machek wrote:
> 
> I guess major change is to rename conflicting symbols, so that it is
> possible to link it twice. That would mean boot_memset() instead of
> memset() etc... Is that acceptable?
> 

Messy, but I guess we can deal with it.  One can always do it with 
#define lest it gets too ugly.

	-hpa

Re: video resume stuff

[H. Peter Anvin]

Jiri Kosina wrote:
> On Fri, 5 Oct 2007, Pavel Machek wrote:
> 
>>> I suggest we tackle this *after* the x86 merge.
>> Well, we still have the regression on jikos' strange system, and I would 
>> like to understand what is going on there.
> 
> Sorry for this taking too long. Finally I had the time to play with this 
> again, so here goes the current summary. I have a system here, that:
> 
> - with 1d67953f2bda8876045c24ae58841f27d9bb7572 (just before the setup 
>   code rewrite), resumes nicely in VGA console 
>   (acpi_sleep=s3_bios,s3_mode kernel parameter is needed), everything 
>   works
> 
> - with c39736823232bc3ca113c8228fa852c09fba300e (just after the setup code 
>   rewrite), VGA text console is garbled after resume - looks like the 
>   video RAM contains some strange data (patterns from BIOS post can be 
>   recognized, there are some various-colored stripes across the screen, 
>   etc). The machine also seems to be frozen (no keyboard LEDs working, 
>   etc).
> 
> - with 2.6.23-rc9, the video doesn't come up at all, I can't even see the 
>   garbled picture any more - the display stays blank, the LED diod is 
>   yellow (i.e. looks like completely no signal from VGA card). On the 
>   other hand, the machine seems to work otherwise
> 

Jiri, what particular video mode are you running in?  In other words, 
what is your vga= parameter set to?  In fact, what does your entire 
kernel command line look like?

Also, if you could extract the information requested in:

http://marc.info/?i=46FD802D.2030804@zytor.com

... that would really help.

	-hpa

(who notices we really need to export boot_params to userspace for sanity)

Re: video resume stuff

[Jiri Kosina]

On Fri, 5 Oct 2007, H. Peter Anvin wrote:

> Jiri, what particular video mode are you running in?  In other words, 
> what is your vga= parameter set to?  In fact, what does your entire 
> kernel command line look like?

Hi,

the videomode is standard 80x25 VGA.

The kernel commandline is 

	root=/dev/sda2 vga=normal 3 acpi_sleep=s3_bios,s3_mode

> Also, if you could extract the information requested in:
> http://marc.info/?i=46FD802D.2030804@zytor.com
> ... that would really help.

bootparams.bin can be found at 
http://www.jikos.cz/jikos/junk/bootparams.bin

Thanks,

-- 
Jiri Kosina

Re: video resume stuff

[H. Peter Anvin]

Jiri Kosina wrote:
> On Fri, 5 Oct 2007, H. Peter Anvin wrote:
> 
>> Jiri, what particular video mode are you running in?  In other words, 
>> what is your vga= parameter set to?  In fact, what does your entire 
>> kernel command line look like?
> 
> Hi,
> 
> the videomode is standard 80x25 VGA.
> 
> The kernel commandline is 
> 
> 	root=/dev/sda2 vga=normal 3 acpi_sleep=s3_bios,s3_mode
> 
>> Also, if you could extract the information requested in:
>> http://marc.info/?i=46FD802D.2030804@zytor.com
>> ... that would really help.
> 
> bootparams.bin can be found at 
> http://www.jikos.cz/jikos/junk/bootparams.bin
> 

Any "before" image as well?

	-hpa

Re: video resume stuff

[H. Peter Anvin]

Jiri Kosina wrote:
> On Fri, 5 Oct 2007, H. Peter Anvin wrote:
> 
>> Jiri, what particular video mode are you running in?  In other words, 
>> what is your vga= parameter set to?  In fact, what does your entire 
>> kernel command line look like?
> 
> Hi,
> 
> the videomode is standard 80x25 VGA.
> 
> The kernel commandline is 
> 
> 	root=/dev/sda2 vga=normal 3 acpi_sleep=s3_bios,s3_mode
> 
>> Also, if you could extract the information requested in:
>> http://marc.info/?i=46FD802D.2030804@zytor.com
>> ... that would really help.
> 
> bootparams.bin can be found at 
> http://www.jikos.cz/jikos/junk/bootparams.bin
> 

Looks like this bootparams image was obtained without removing 
__initdata, so it's unusable.  Sorry.

	-hpa

Re: video resume stuff

[Jiri Kosina]

On Fri, 5 Oct 2007, H. Peter Anvin wrote:

> > bootparams.bin can be found at http://www.jikos.cz/jikos/junk/bootparams.bin
> Looks like this bootparams image was obtained without removing __initdata, so
> it's unusable.  Sorry.

Oops, sorry. I have just put the new dump 
http://www.jikos.cz/jikos/junk/bootparams.bin

Thanks,

-- 
Jiri Kosina