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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox