From: Luca Falavigna <dktrkranz@gmail.com>
To: "Eric W. Biederman" <ebiederm@xmission.com>
Cc: rddunlap@osdl.org, fastboot@osdl.org,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: kexec and frame buffer
Date: Fri, 12 Aug 2005 18:53:03 +0000 [thread overview]
Message-ID: <42FCF00F.2040709@gmail.com> (raw)
In-Reply-To: <42F6266B.8000704@gmail.com>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Luca Falavigna ha scritto:
> Eric W. Biederman ha scritto:
>
>>>Anyway I believe you also want to look at include/linux/tty.h
>>>at the screen_info structure. I believe that is where
>>>all of that information is passed.
>
> I noticed. Maybe if we fill struct x86_linux_param_header with some values
> obtained from struct screen_info, we should be able to "score that mid-court
> prayer" ;)
>
I tried to implement a new ioctl command in fb_ioctl() in order to retrieve and
store screen_info variables into struct x86_linux_param_header, but I got the
same result: no messages shown in console, as I supposed.
After that I looked at video.S, especially an interesting label called "video":
# This is the main entry point called by setup.S
# %ds *must* be pointing to the bootsector
video: pushw %ds # We use different segments
pushw %ds # FS contains original DS
popw %fs
[...]
#ifdef CONFIG_VIDEO_SELECT
movw %fs:(0x01fa), %ax # User selected video mode
cmpw $ASK_VGA, %ax # Bring up the menu
jz vid2
[...]
Video mode is stored (by bootloader, actually) at offset 0x01fa from a given
boot sector, which should be located at physical address DEF_SETUPSEG (0x9020).
Feel free to correct me if I'm wrong.
If we could store current video mode before executing reboot_code_buffer,
probably setup() function would take care of anything else. So we could
implement a function (or an assembly stub) in machine_kexec which does this job.
I think this is the best (and safest) solution.
Regards,
- --
Luca
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iQEVAwUBQvzwDczkDT3RfMB6AQJlQAf+INkCMjhmm18RPCMHXij7WmOL/4TCKTc8
fZCf+IzhsSUxwkfYmUbTfXtJ/xCxIyRh5gBGirB9n/s9NzOiYwmcQWMrn7DbWpWu
YBVkTdz3W3Y0dA08baIYQ8u51gJvnVMuGJEFqsLxPx+gzHJOETEGkzhuyUuPk+J+
N4OkSyTGYt5zXZmyVzV7KZ8XLrfX3XvRLV3m2aey0Hz4jcf8sIozANokDRdG3MpN
7F0Z4yL1EnMI4oijHSDLeqbycAg8iYa49P45EO6+jzuRH2i2bnq8hOvBHa0+B01Q
Gr0Ljd+DJ2jNVO4ecqbWC9oFxBFXsRN+ThAxsYEbWDGIrJdAa32mfA==
=BztK
-----END PGP SIGNATURE-----
next prev parent reply other threads:[~2005-08-12 16:53 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-08-04 13:35 kexec and frame buffer Luca Falavigna
2005-08-04 18:43 ` Eric W. Biederman
2005-08-06 14:19 ` Luca Falavigna
2005-08-06 16:50 ` Eric W. Biederman
2005-08-07 15:19 ` Luca Falavigna
2005-08-12 18:53 ` Luca Falavigna [this message]
2005-08-12 17:10 ` Eric W. Biederman
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=42FCF00F.2040709@gmail.com \
--to=dktrkranz@gmail.com \
--cc=ebiederm@xmission.com \
--cc=fastboot@osdl.org \
--cc=linux-kernel@vger.kernel.org \
--cc=rddunlap@osdl.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.