Re: kexec and frame buffer

[Eric W. Biederman]

Luca Falavigna <dktrkranz@xxxxxxxxx> writes:

> 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.
Hmm. very odd.  Sounds very much like an implementation problem.

> 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.
That is the default address, it can actually move quite a bit.

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

That is why we have sys_kexec_load().
With a working ioctl (or other way to query the information) we
just need to populate screen_info from x86-linux-setup.c in /sbin/kexec.

Eric
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/