RE: [Linux-fbdev-devel] Re: Generic VESA framebuffer driver and Video card BOOT?

RE: [Linux-fbdev-devel] Re: Generic VESA framebuffer driver and Video card BOOT?

[Pallipadi, Venkatesh]

 

>-----Original Message-----
>From: linux-kernel-owner@vger.kernel.org 
>>         pushl   $0                                           
>   # Kill any dangerous flags
>>         popfl
>> 
>>         movl    real_magic - wakeup_code, %eax
>>         cmpl    $0x12345678, %eax
>>         jne     bogus_real_magic
>> 
>>         testl   $1, video_flags - wakeup_code
>>         jz      1f
>>         lcall   $0xc000,$3
>
>The call to 0xC000:0x0003 is the entry point to POST the card. However 
>for PCI cards you need to make sure that AX is loaded with the 
>bus, slot 
>and function for the card that is being POST'ed. It will pass 
>this value 
>to the PCI BIOS Int 0x1A functions in order to find itself, so 
>if this is 
>not set many BIOS'es will not work.
>
>The rest of the code you have above seems superfluous to me as we have 
>never needed to do that. Then again we boot the card using the BIOS 
>emulator, which is different because it runs within a 
>protected machine 
>state.
>
>Have you taken a look at the X.org code? They have code in 
>there to POST 
>the video card also (either using vm86() or the BIOS emulator).
>

I have done some experiments with this video post stuff.
I think this should be done using x86 emulator rather than doing 
in real mode. The reason being, with an userlevel emulator we can call
it at different times during resume. The current real mode videopost
does 
it before the driver has restored the PCI config space. Some systems 
(mostly the ones with Radeon card) requires this to be done after 
PCI config space is restored. With a userspace emulator, we can 
call it at various places during the driver restore.

I have seen the SciTech's x86 emulator in X.org. I could seperate it out

from X into a stand alone application that does x86 emulation. I use it
to get 
the video back on my laptop (which has radeon card), by calling this
user level 
emulator using usermodehelper call. I hope we will have x86 emulator
sitting in 
a standard place in userspace. That way we can use it in driver restore
and 
solve the S3 video restore problem in a more generic way.

Thanks,
Venki

Re: [Linux-fbdev-devel] Re: Generic VESA framebuffer driver and Video card BOOT?

[Pavel Machek]

Hi!

> >The rest of the code you have above seems superfluous to me as we have 
> >never needed to do that. Then again we boot the card using the BIOS 
> >emulator, which is different because it runs within a 
> >protected machine 
> >state.
> >
> >Have you taken a look at the X.org code? They have code in 
> >there to POST 
> >the video card also (either using vm86() or the BIOS emulator).
> >
> 
> I have done some experiments with this video post stuff.
> I think this should be done using x86 emulator rather than doing 
> in real mode. The reason being, with an userlevel emulator we can call
> it at different times during resume. The current real mode videopost
> does 

Actually Ole Rohne has patch that allows you to call real mode any
time you want.
								Pavel
-- 
People were complaining that M$ turns users into beta-testers...
...jr ghea gurz vagb qrirybcref, naq gurl frrz gb yvxr vg gung jnl!

RE: Re: Generic VESA framebuffer driver and Video card BOOT?

[Kendall Bennett]

"Pallipadi, Venkatesh" <venkatesh.pallipadi@intel.com> wrote:

> I have done some experiments with this video post stuff. I think
> this should be done using x86 emulator rather than doing in real
> mode. The reason being, with an userlevel emulator we can call it
> at different times during resume. The current real mode videopost
> does it before the driver has restored the PCI config space. Some
> systems (mostly the ones with Radeon card) requires this to be
> done after PCI config space is restored. With a userspace
> emulator, we can call it at various places during the driver
> restore. 
> 
> I have seen the SciTech's x86 emulator in X.org. I could seperate
> it out from X into a stand alone application that does x86
> emulation. I use it to get the video back on my laptop (which has
> radeon card), by calling this user level emulator using
> usermodehelper call. I hope we will have x86 emulator sitting in a
> standard place in userspace. That way we can use it in driver
> restore and solve the S3 video restore problem in a more generic
> way. 

We already have all this code completely separate from X and would 
release this as part of the Video Boot package for Linux. The kernel 
module is one part of it, but the code can be compiled as a stand alone 
user land program as well (SNAPBoot we call it right now). 

Regards,

---
Kendall Bennett
Chief Executive Officer
SciTech Software, Inc.
Phone: (530) 894 8400
http://www.scitechsoft.com

~ SciTech SNAP - The future of device driver technology! ~




-------------------------------------------------------
This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
Use IT products in your business? Tell us what you think of them. Give us
Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more
http://productguide.itmanagersjournal.com/guidepromo.tmpl

RE: Re: Generic VESA framebuffer driver and Video card BOOT?

[Pallipadi, Venkatesh]

 

>-----Original Message-----
>From: Kendall Bennett [mailto:KendallB@scitechsoft.com] 
>Sent: Friday, October 22, 2004 10:11 AM
>To: Pallipadi, Venkatesh
>Cc: linux-kernel@vger.kernel.org; 
>linux-fbdev-devel@lists.sourceforge.net
>Subject: RE: [Linux-fbdev-devel] Re: Generic VESA framebuffer 
>driver and Video card BOOT?
>
>"Pallipadi, Venkatesh" <venkatesh.pallipadi@intel.com> wrote:
>
>> I have done some experiments with this video post stuff. I think
>> this should be done using x86 emulator rather than doing in real
>> mode. The reason being, with an userlevel emulator we can call it
>> at different times during resume. The current real mode videopost
>> does it before the driver has restored the PCI config space. Some
>> systems (mostly the ones with Radeon card) requires this to be
>> done after PCI config space is restored. With a userspace
>> emulator, we can call it at various places during the driver
>> restore. 
>> 
>> I have seen the SciTech's x86 emulator in X.org. I could seperate
>> it out from X into a stand alone application that does x86
>> emulation. I use it to get the video back on my laptop (which has
>> radeon card), by calling this user level emulator using
>> usermodehelper call. I hope we will have x86 emulator sitting in a
>> standard place in userspace. That way we can use it in driver
>> restore and solve the S3 video restore problem in a more generic
>> way. 
>
>We already have all this code completely separate from X and would 
>release this as part of the Video Boot package for Linux. The kernel 
>module is one part of it, but the code can be compiled as a 
>stand alone 
>user land program as well (SNAPBoot we call it right now). 
>

That is really nice to know. That will make "video on S3 resume" problem
go away on quite a few laptops. Will look forward to release of such a
code.

Thanks,
Venki


-------------------------------------------------------
This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
Use IT products in your business? Tell us what you think of them. Give us
Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more
http://productguide.itmanagersjournal.com/guidepromo.tmpl

Generic VESA framebuffer driver and Video card BOOT?

[Kendall Bennett]

Hello All,

I am writing this email to guage the interest in having code contributed 
to the main stream Linux kernel that would support the user of a generic, 
full featured VESA framebuffer driver that works on any CPU architecture 
along with a generic Video card BOOT or POST mechanism.

We have been working on a project under contract to ATI that involves 
porting a version of our SNAPBoot BIOS emulator solution to the PowerPC 
Linux kernel. The SNAPBoot code supports initialising a graphics card 
using an x86 BIOS image on any platform (currently tesed on x86, x86-64 
and PowerPC). Initially SNAPBoot was developed to work across multiple 
operating systems and CPU architectures from user space, but the desire 
to use it to initialise the graphics card on embedded PowerPC kernels 
prompted us to port a version of it for use within the Linux kernel. The 
version we have ported for use in the kernel can be used to initialise 
the graphics card for use with any accelerated framebuffer console 
driver, such as the radeonfb driver which we are currently using it with.

Note that the SNAPBoot code uses the x86emu BIOS emulator project as the 
core CPU emulation technology, and project we have been actively involved 
with for many years since the licensing on the project was changed to 
MIT/BSD style licensing and incorporated into the XFree86 project. We 
have built code on top of x86emu to provide generic support for 
initialising graphics cards on multiple platforms as well as supporting 
initialisation of modern NonVGA graphics cards (like the ATI Radeon 
family) without needing access to real VGA resources such as VGA I/O 
ports and physical memory at 0xA0000-0xBFFFF.

More importantly we have used SNAPBoot to port our generic VESA SNAP 
display driver to work on multiple operating systems and platforms, 
including both x86-64 and PowerPC platforms. Using this driver you can 
use any graphics card in the machine and it will support all the features 
provided by the graphics cards VESA BIOS, including support for refresh 
rate control on cards that support VBE 3.0 services. We have been 
actively testing both the SNAPBoot capability and the BIOS emulator on 
many platforms and graphics cards, and the latest version work flawlessly 
on just about every graphics card we have tested.

What this means is that it should be possible to build a new version of 
the VESA framebuffer console driver for the Linux kernel that will have 
these important features:

1. Be able to switch display modes on the fly, supporting all modes 
enumerated by the Video BIOS.

2. Be able to support refresh rate control on graphics cards that support 
the VBE 3.0 services.

3. Be able to support 8-bit and 32-bit display modes on any graphics card 
on big endian machines (16-bit is not possible unless software rendering 
code is written to enable endian swapping in software, which may be 
possible).

So what we would like to find out is how much interest there might be in 
both an updated VESA framebuffer console driver as well as the code for 
the Video card BOOT process being contributed to the maintstream kernel. 
If there is interest, we would start out by first contributing the core 
emulator and Video BOOT code, and then work on building a better VESA 
framebuffer console driver. 

So what do you guys think? 

Regards,

---
Kendall Bennett
Chief Executive Officer
SciTech Software, Inc.
Phone: (530) 894 8400
http://www.scitechsoft.com

~ SciTech SNAP - The future of device driver technology! ~

Re: Generic VESA framebuffer driver and Video card BOOT?

[Jon Smirl]

> What this means is that it should be possible to build a new version of
> the VESA framebuffer console driver for the Linux kernel that will have
> these important features:
> 
> 1. Be able to switch display modes on the fly, supporting all modes
> enumerated by the Video BIOS.
> 
> 2. Be able to support refresh rate control on graphics cards that support
> the VBE 3.0 services.

How is this going to work if there are multiple graphics cards
installed? Each card will want to install it's own VBE extension
interrupt.

-- 
Jon Smirl
jonsmirl@gmail.com


-------------------------------------------------------
This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
Use IT products in your business? Tell us what you think of them. Give us
Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more
http://productguide.itmanagersjournal.com/guidepromo.tmpl

Re: Re: Generic VESA framebuffer driver and Video card BOOT?

[Kendall Bennett]

Jon Smirl <jonsmirl@gmail.com> wrote:

> > What this means is that it should be possible to build a new version of
> > the VESA framebuffer console driver for the Linux kernel that will have
> > these important features:
> > 
> > 1. Be able to switch display modes on the fly, supporting all modes
> > enumerated by the Video BIOS.
> > 
> > 2. Be able to support refresh rate control on graphics cards that support
> > the VBE 3.0 services.
> 
> How is this going to work if there are multiple graphics cards
> installed? Each card will want to install it's own VBE extension
> interrupt. 

Yep. The code I have ported to the Linux kernel right now does not 
support multiple consoles because porting that code would be a lot more 
work (I would prefer to keep it in userland if possible since it already 
works there).

Anyway the way the system works for multiple controllers is that there is 
a separate BIOS image and separate machine state maintained for each 
graphics card. So you can run the VBE driver on the primary, secondary 
and ternary drivers if you want. We do it all the time with SNAP just for 
fun and giggles ;-)

Regards,

---
Kendall Bennett
Chief Executive Officer
SciTech Software, Inc.
Phone: (530) 894 8400
http://www.scitechsoft.com

~ SciTech SNAP - The future of device driver technology! ~




-------------------------------------------------------
This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
Use IT products in your business? Tell us what you think of them. Give us
Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more
http://productguide.itmanagersjournal.com/guidepromo.tmpl

Re: Generic VESA framebuffer driver and Video card BOOT?

[Pavel Machek]

Hi!

> I am writing this email to guage the interest in having code contributed 
> to the main stream Linux kernel that would support the user of a generic, 
> full featured VESA framebuffer driver that works on any CPU architecture 
> along with a generic Video card BOOT or POST mechanism.

BTW, does this look like right way to POST VGA BIOS from real mode? It
is what we currently use... and it works on some machines...

        movw    $0xb800, %ax
        movw    %ax,%fs
        movw    $0x0e00 + 'L', %fs:(0x10)

        cli
        cld

        # setup data segment
        movw    %cs, %ax
        movw    %ax, %ds                                        # Make ds:0 point to wakeup_start
        movw    %ax, %ss
        mov     $(wakeup_stack - wakeup_code), %sp              # Private stack is needed for ASUS board
        movw    $0x0e00 + 'S', %fs:(0x12)

        pushl   $0                                              # Kill any dangerous flags
        popfl

        movl    real_magic - wakeup_code, %eax
        cmpl    $0x12345678, %eax
        jne     bogus_real_magic

        testl   $1, video_flags - wakeup_code
        jz      1f
        lcall   $0xc000,$3
        movw    %cs, %ax
        movw    %ax, %ds                                        # Bios might have played with that
        movw    %ax, %ss
1:

								Pavel
-- 
People were complaining that M$ turns users into beta-testers...
...jr ghea gurz vagb qrirybcref, naq gurl frrz gb yvxr vg gung jnl!

Re: Re: Generic VESA framebuffer driver and Video card BOOT?

[Kendall Bennett]

Pavel Machek <pavel@ucw.cz> wrote:

> BTW, does this look like right way to POST VGA BIOS from real
> mode? It is what we currently use... and it works on some
> machines... 
> 
>         movw    $0xb800, %ax
>         movw    %ax,%fs
>         movw    $0x0e00 + 'L', %fs:(0x10)

What is this for?

>         cli
>         cld
> 
>         # setup data segment
>         movw    %cs, %ax
>         movw    %ax, %ds                                        # Make ds:0 point to wakeup_start
>         movw    %ax, %ss
>         mov     $(wakeup_stack - wakeup_code), %sp              # Private stack is needed for ASUS board
>         movw    $0x0e00 + 'S', %fs:(0x12)

We have never needed to set up a private stack. What ASUS board was it 
that you had problems with and needed to do this for?

>         pushl   $0                                              # Kill any dangerous flags
>         popfl
> 
>         movl    real_magic - wakeup_code, %eax
>         cmpl    $0x12345678, %eax
>         jne     bogus_real_magic
> 
>         testl   $1, video_flags - wakeup_code
>         jz      1f
>         lcall   $0xc000,$3

The call to 0xC000:0x0003 is the entry point to POST the card. However 
for PCI cards you need to make sure that AX is loaded with the bus, slot 
and function for the card that is being POST'ed. It will pass this value 
to the PCI BIOS Int 0x1A functions in order to find itself, so if this is 
not set many BIOS'es will not work.

The rest of the code you have above seems superfluous to me as we have 
never needed to do that. Then again we boot the card using the BIOS 
emulator, which is different because it runs within a protected machine 
state.

Have you taken a look at the X.org code? They have code in there to POST 
the video card also (either using vm86() or the BIOS emulator).

Regards,

---
Kendall Bennett
Chief Executive Officer
SciTech Software, Inc.
Phone: (530) 894 8400
http://www.scitechsoft.com

~ SciTech SNAP - The future of device driver technology! ~




-------------------------------------------------------
This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
Use IT products in your business? Tell us what you think of them. Give us
Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more
http://productguide.itmanagersjournal.com/guidepromo.tmpl

Re: [Linux-fbdev-devel] Re: Generic VESA framebuffer driver and Video card BOOT?

[Pavel Machek]

Hi!

> > BTW, does this look like right way to POST VGA BIOS from real
> > mode? It is what we currently use... and it works on some
> > machines... 
> > 
> >         movw    $0xb800, %ax
> >         movw    %ax,%fs
> >         movw    $0x0e00 + 'L', %fs:(0x10)
> 
> What is this for?

Debugging.

> >         cli
> >         cld
> > 
> >         # setup data segment
> >         movw    %cs, %ax
> >         movw    %ax, %ds                                        # Make ds:0 point to wakeup_start
> >         movw    %ax, %ss
> >         mov     $(wakeup_stack - wakeup_code), %sp              # Private stack is needed for ASUS board
> >         movw    $0x0e00 + 'S', %fs:(0x12)
> 
> We have never needed to set up a private stack. What ASUS board was it 
> that you had problems with and needed to do this for?

This is running at system resume, so it is not normal boot. Some ASUS
Athlon 900MHz machine needed this; I'm no longer using this one.

> >         pushl   $0                                              # Kill any dangerous flags
> >         popfl
> > 
> >         movl    real_magic - wakeup_code, %eax
> >         cmpl    $0x12345678, %eax
> >         jne     bogus_real_magic
> > 
> >         testl   $1, video_flags - wakeup_code
> >         jz      1f
> >         lcall   $0xc000,$3
> 
> The call to 0xC000:0x0003 is the entry point to POST the card. However 
> for PCI cards you need to make sure that AX is loaded with the bus, slot 
> and function for the card that is being POST'ed. It will pass this value 
> to the PCI BIOS Int 0x1A functions in order to find itself, so if this is 
> not set many BIOS'es will not work.

Ok, this one is bad... ... In case of just one vga adapter, we should
be able to store its parameters in some well-known place. For more
than one adapter, we'll definitely need to run BIOS in emulator.

								Pavel
-- 
People were complaining that M$ turns users into beta-testers...
...jr ghea gurz vagb qrirybcref, naq gurl frrz gb yvxr vg gung jnl!

Re: Re: Generic VESA framebuffer driver and Video card BOOT?

[Kendall Bennett]

Pavel Machek <pavel@ucw.cz> wrote:

> > > BTW, does this look like right way to POST VGA BIOS from real
> > > mode? It is what we currently use... and it works on some
> > > machines... 
> > > 
> > >         movw    $0xb800, %ax
> > >         movw    %ax,%fs
> > >         movw    $0x0e00 + 'L', %fs:(0x10)
> > 
> > What is this for?
> 
> Debugging.

Ok ;-)

> > >         cli
> > >         cld
> > > 
> > >         # setup data segment
> > >         movw    %cs, %ax
> > >         movw    %ax, %ds                                        # Make ds:0 point to wakeup_start
> > >         movw    %ax, %ss
> > >         mov     $(wakeup_stack - wakeup_code), %sp              # Private stack is needed for ASUS board
> > >         movw    $0x0e00 + 'S', %fs:(0x12)
> > 
> > We have never needed to set up a private stack. What ASUS board was it 
> > that you had problems with and needed to do this for?
> 
> This is running at system resume, so it is not normal boot. Some
> ASUS Athlon 900MHz machine needed this; I'm no longer using this
> one. 

Ok. For the BIOS emulator the code always has it's own local stack anyway 
so I assume the problme you had may have been that the BIOS on the board 
was using too much stack space, so setting up a local stack that is big 
enough is probably a good idea.

> > >         pushl   $0                                              # Kill any dangerous flags
> > >         popfl
> > > 
> > >         movl    real_magic - wakeup_code, %eax
> > >         cmpl    $0x12345678, %eax
> > >         jne     bogus_real_magic
> > > 
> > >         testl   $1, video_flags - wakeup_code
> > >         jz      1f
> > >         lcall   $0xc000,$3
> > 
> > The call to 0xC000:0x0003 is the entry point to POST the card. However 
> > for PCI cards you need to make sure that AX is loaded with the bus, slot 
> > and function for the card that is being POST'ed. It will pass this value 
> > to the PCI BIOS Int 0x1A functions in order to find itself, so if this is 
> > not set many BIOS'es will not work.
> 
> Ok, this one is bad... ... In case of just one vga adapter, we
> should be able to store its parameters in some well-known place.
> For more than one adapter, we'll definitely need to run BIOS in
> emulator. 

Yes. If you are running this in real mode you don't have any option but 
to use the BIOS emulator. If you are running in protected mode and using 
vm86() style service, the 0xC0000 memory is just memory and can be re-
written. For instance on Linux you can map 0xC0000 into your process 
address space as copy on write, which then allows you to re-write the 
BIOS image for a secondary controller and then restore it when you are 
done.

But you will also need to make sure you can hook the Int 0x1A interrupt 
to hide any other graphics cards on the bus as some BIOS'es are pretty 
stupid and will find the first card on the bus that matches their 
Vendor/Device ID's. So if you have two of the same card, it will find th 
wrong one ;-)

Regards,

---
Kendall Bennett
Chief Executive Officer
SciTech Software, Inc.
Phone: (530) 894 8400
http://www.scitechsoft.com

~ SciTech SNAP - The future of device driver technology! ~




-------------------------------------------------------
This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
Use IT products in your business? Tell us what you think of them. Give us
Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more
http://productguide.itmanagersjournal.com/guidepromo.tmpl

Re: [Linux-fbdev-devel] Re: Generic VESA framebuffer driver and Video card BOOT?

[Pavel Machek]

Hi!

> > > >         pushl   $0                                              # Kill any dangerous flags
> > > >         popfl
> > > > 
> > > >         movl    real_magic - wakeup_code, %eax
> > > >         cmpl    $0x12345678, %eax
> > > >         jne     bogus_real_magic
> > > > 
> > > >         testl   $1, video_flags - wakeup_code
> > > >         jz      1f
> > > >         lcall   $0xc000,$3
> > > 
> > > The call to 0xC000:0x0003 is the entry point to POST the card. However 
> > > for PCI cards you need to make sure that AX is loaded with the bus, slot 
> > > and function for the card that is being POST'ed. It will pass this value 
> > > to the PCI BIOS Int 0x1A functions in order to find itself, so if this is 
> > > not set many BIOS'es will not work.
> > 
> > Ok, this one is bad... ... In case of just one vga adapter, we
> > should be able to store its parameters in some well-known place.
> > For more than one adapter, we'll definitely need to run BIOS in
> > emulator. 
> 
> Yes. If you are running this in real mode you don't have any option but 
> to use the BIOS emulator. If you are running in protected mode and using 
> vm86() style service, the 0xC0000 memory is just memory and can be re-
> written. For instance on Linux you can map 0xC0000 into your process 
> address space as copy on write, which then allows you to re-write the 
> BIOS image for a secondary controller and then restore it when you are 
> done.

One more question: Does 0xc0000 POST method work even on notebooks? On
regular machines, PCI card must have normal bios and stuff is easy. On
notebooks there was talk about "integrated bios" where it really has
no video bios at all and system bios POSTs the card. Have you seen
that?
								Pavel
-- 
People were complaining that M$ turns users into beta-testers...
...jr ghea gurz vagb qrirybcref, naq gurl frrz gb yvxr vg gung jnl!

Re: Re: Generic VESA framebuffer driver and Video card BOOT?

[Kendall Bennett]

Pavel Machek <pavel@ucw.cz> wrote:

> One more question: Does 0xc0000 POST method work even on
> notebooks? On regular machines, PCI card must have normal bios and
> stuff is easy. On notebooks there was talk about "integrated bios"
> where it really has no video bios at all and system bios POSTs the
> card. Have you seen that? 

We have never had a need to POST a notebook Video BIOS so I don't know 
what would happen. It is an interesting question, and if this is to be 
used for resume operations something that should be investigated.

Regards,

---
Kendall Bennett
Chief Executive Officer
SciTech Software, Inc.
Phone: (530) 894 8400
http://www.scitechsoft.com

~ SciTech SNAP - The future of device driver technology! ~




-------------------------------------------------------
This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
Use IT products in your business? Tell us what you think of them. Give us
Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more
http://productguide.itmanagersjournal.com/guidepromo.tmpl