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
 ...
[ message continues ]

On Thu, 4 Oct 2007 15:05:13 +0200


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 ;)
-

[ message continues ]

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
-

[ message continues ]

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
-

[ message continues ]

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
-

[ message continues ]

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

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
-

[ message continues ]

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
-

[ message continues ]

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)
-

[ message continues ]

Hi,

the videomode is standard 80x25 VGA.

The kernel commandline is 


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

Thanks,

-- 
Jiri Kosina
-

[ message continues ]

Any "before" image as well?

	-hpa
-

[ message continues ]

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

	-hpa
-

[ message continues ]

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

Thanks,

-- 
Jiri Kosina
-

[ message continues ]

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

	-hpa
-

[ message continues ]