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
On Thu, 4 Oct 2007 15:05:13 +0200
Pavel Machek <[email protected]> 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 ;)
> On Thu, 4 Oct 2007 15:05:13 +0200
> Pavel Machek <[email protected]> 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
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
Pavel Machek wrote:
>> On Thu, 4 Oct 2007 15:05:13 +0200
>> Pavel Machek <[email protected]> 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
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
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
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
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/[email protected]
... that would really help.
-hpa
(who notices we really need to export boot_params to userspace for sanity)
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/[email protected]
> ... that would really help.
bootparams.bin can be found at
http://www.jikos.cz/jikos/junk/bootparams.bin
Thanks,
--
Jiri Kosina
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/[email protected]
>> ... that would really help.
>
> bootparams.bin can be found at
> http://www.jikos.cz/jikos/junk/bootparams.bin
>
Any "before" image as well?
-hpa
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/[email protected]
>> ... 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
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