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: Pavel Machek [mailto:pavel@ucw.cz] 
>Sent: Thursday, October 21, 2004 4:00 PM
>To: Pallipadi, Venkatesh
>Cc: Kendall Bennett; 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?
>
>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

Yes. I tried Ole's patch. That helped on one of my laptops. But, on 
the other one it doesn't work. It goes into real mode but never returns.
Both systems had Radeom 9000M cards, but one with older version of the 
firmware (didn't work) and one with newer version.

IIRC, even Stefan had similar problems with Ole's patch.

Thanks,
Venki

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

[Pavel Machek]

Hi!

> >> 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.
> 
> Yes. I tried Ole's patch. That helped on one of my laptops. But, on 
> the other one it doesn't work. It goes into real mode but never returns.
> Both systems had Radeom 9000M cards, but one with older version of the 
> firmware (didn't work) and one with newer version.
> 
> IIRC, even Stefan had similar problems with Ole's patch.

It did not work for me, either, but I verified that it works as
expected if I comment out actuall call of BIOS. So the problem is not
with Ole's patch but with bios, and it may be the same if you emulate
it...

[Of course, it will not crash whole system when emulated, but system
without video is not too good, either].
								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: [Linux-fbdev-devel] Re: Generic VESA framebuffer driver and Video card BOOT?

[Pallipadi, Venkatesh]

>-----Original Message-----
>From: linux-kernel-owner@vger.kernel.org 
>[mailto:linux-kernel-owner@vger.kernel.org] On Behalf Of Pavel Machek
>Sent: Thursday, October 21, 2004 4:23 PM
>To: Pallipadi, Venkatesh
>Cc: Kendall Bennett; linux-kernel@vger.kernel.org; 
>linux-fbdev-devel@lists.sourceforge.net; stefandoesinger@gmx.at
>Subject: Re: [Linux-fbdev-devel] Re: Generic VESA framebuffer 
>driver and Video card BOOT?
>
>Hi!
>
>> >> 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.
>> 
>> Yes. I tried Ole's patch. That helped on one of my laptops. But, on 
>> the other one it doesn't work. It goes into real mode but 
>never returns.
>> Both systems had Radeom 9000M cards, but one with older 
>version of the 
>> firmware (didn't work) and one with newer version.
>> 
>> IIRC, even Stefan had similar problems with Ole's patch.
>
>It did not work for me, either, but I verified that it works as
>expected if I comment out actuall call of BIOS. So the problem is not
>with Ole's patch but with bios, and it may be the same if you emulate
>it...
>
>[Of course, it will not crash whole system when emulated, but system
>without video is not too good, either].

Even I thought so. But, with the emulator it doesn't hang. It brings 
back my video. I double checked this using another vm86 emulator too. 
No hang even there. I couldn't figure out why Ole's patch won't work 
though. Right now I am using call_usermodehelper() to call the 
emulator during resume and the video comes back just fine on this 
system where Ole's patch didn't work.

Thanks,
Venki

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

[Stefan Dösinger]

> Right now I am using call_usermodehelper() to call the
> emulator during resume and the video comes back just fine on this
> system where Ole's patch didn't work.
Can you explain me how you do this? call_usermodehelper() doesn't work for me 
at resume time.

BTW, I had a look at the radeon card's resume code at 0xc000:3 and attempted 
to implement it in a kernel module. The code is pretty simple, but it's quite 
long. My module isn't finished, it only turns off the display and resets the 
memory. I had to stop because I've a lot of things to do for school now.

Ole Rohne meant that the code is potentially dangerous because it pokes around 
with undocumented PLL registers, so I will not send it to the list: I will 
send it only to those who explicitly ask for it.

Stefan Dösinger

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!

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?

[Kendall Bennett]

Helge Hafting <helgehaf@aitel.hist.no> wrote:

> On 14-10-2004 21:02:36, Kendall Bennett wrote:
> > Hello All,
> [...]
> > 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.
> 
> The BOOT stuff is very interesting.  Currently, both my videocards
> (in the same pc) have nice hw-specific framebuffer drivers, but
> they require that the card is initialized by the bios first and
> this only ever happens to one of the cards.  Xfree _can_ do the
> job, but way too late for setting up the framebuffer device. 

Exactly.

> > 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.
> 
> Having video BOOT would be great, and please make it independent of
> the framebuffer drivers.  

Right now it is independent but I added a single line of code to the 
Radeon driver to init the card prior to initing the rest of the driver. 
It can be done earlier than that inside fbmem.c, but I wasn't sure how to 
set up the code so it would only POST each card as it is needed as I 
don't want to bring up secondary controllers unless the user actually 
wants this.

How does the framebuffer console system handle secondary controllers 
right now? It seems from my look at the code that it only brings up the 
primary and not the secondary?

> I might want to try your vesa driver, but I might also want to use
> the hw-accelerated chip specific driver that happens to need an
> initialized video card. 

Yep, you could use either. In fact you could even use the VGA text 
console driver on PowerPC and MIPS platforms provided the kernel 
correctly sets up the proper VGA resource mappings (which many embedded 
kernels do not do).

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: [Linux-fbdev-devel] Re: Generic VESA framebuffer driver and Video card BOOT?

[Antonino A. Daplas]

On Saturday 16 October 2004 02:36, Kendall Bennett wrote:
> Helge Hafting <helgehaf@aitel.hist.no> wrote:
> > On 14-10-2004 21:02:36, Kendall Bennett wrote:
>
> How does the framebuffer console system handle secondary controllers
> right now? It seems from my look at the code that it only brings up the
> primary and not the secondary?

By default, the first driver to initialize is used by the fb console.   If
there are more than 1 fb driver, one can either use:

- con2fbmap
- the "fbcon=map:abcd" kernel boot option

Of course, the secondary card must be POSTed.

Tony

Re: Generic VESA framebuffer driver and Video card BOOT?

[Kendall Bennett]

Helge Hafting <helgehaf@aitel.hist.no> wrote:

> On Fri, Oct 15, 2004 at 11:36:04AM -0700, Kendall Bennett wrote:
> > Helge Hafting <helgehaf@aitel.hist.no> wrote:
> > 
> [...]
> > > Having video BOOT would be great, and please make it independent of
> > > the framebuffer drivers.  
> > 
> > Right now it is independent but I added a single line of code to the 
> > Radeon driver to init the card prior to initing the rest of the driver. 
> 
> That's fine.  What I meant, was please make it independent of the
> VESA framebuffer driver, because one might want to use an
> acellerated driver when one is available. 

Oh, it already is. The VESA driver is not actually done yet so the only 
drivers using VideoBoot right now are the accelerated ones ;-)

> > It can be done earlier than that inside fbmem.c, but I wasn't sure how to 
> > set up the code so it would only POST each card as it is needed as I 
> > don't want to bring up secondary controllers unless the user actually 
> > wants this.
> 
> Selecting which cards to "boot" can probably be done with a kernel
> parameter?  The default could be to bring up all cards except the
> one the bios brought up already.  Wanting to _not_ bring up some
> cards seems to be the unusual case to me. 

Not really. In many cases there may be a secondary controller on the 
system that is not wanted, such as when the user has an i915G or other 
chipset with integrated video but has plugged a different video card into 
the system. The integrated video can still be active so trying to bring 
it up may be problematic unless it is really wanted.

> > How does the framebuffer console system handle secondary controllers 
> > right now? It seems from my look at the code that it only brings up the 
> > primary and not the secondary?
> 
> The stock 2.6.x fbcon only use one framebuffer console.  I use the
> ruby patch which supports multiple consoles.  The ruby patch for
> 2.6.7 support multiple fbcons so you can have several keyboards
> attached to separate framebuffers thus supporting several users.
> (VT1-VT16 is the first kbd on the first fbcon, VT17-VT32 is the
> second kbd on the second fbcon, and so on.) 
> 
> The ruby patch for 2.6.8.1 is somewhat broken, and doesn't work
> with fbcon. It still support multiple keyboards and multiple
> framebuffers, so I can support several users with separate xservers
> but currently not gettys on separate fbcons. 

Cool. So this stuff is not yet in the official kernel trees. Is that 
going to happen or is the project to move the video out of the kernel 
going to happen first?

> Note that soft-booting the "extra" video card in order to support a
> framebuffer driver is nice even if it doesn't attach to the
> console, because there is other software that can utilize a
> framebuffer.  X is the most well-known of them. 

Yes, but if you don't need a framebuffer console on the card then X or 
whatever can bring up the secondary controller from user space once the 
kernel has booted.

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: [Linux-fbdev-devel] Re: Generic VESA framebuffer driver and Video card BOOT?

[Antonino A. Daplas]

On Saturday 16 October 2004 06:12, Kendall Bennett wrote:
> Helge Hafting <helgehaf@aitel.hist.no> wrote:
> > On Fri, Oct 15, 2004 at 11:36:04AM -0700, Kendall Bennett wrote:
> > > Helge Hafting <helgehaf@aitel.hist.no> wrote:
> > That's fine.  What I meant, was please make it independent of the
> > VESA framebuffer driver, because one might want to use an
> > acellerated driver when one is available.
>
> Oh, it already is. The VESA driver is not actually done yet so the only
> drivers using VideoBoot right now are the accelerated ones ;-)
>

If these get in (emulator with/without the video boot), I'm willing to
modify the vesafb driver.

Tony

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

[Paulo Marques]

Antonino A. Daplas wrote:
> On Saturday 16 October 2004 06:12, Kendall Bennett wrote:
> 
>>Helge Hafting <helgehaf@aitel.hist.no> wrote:
>>
>>>On Fri, Oct 15, 2004 at 11:36:04AM -0700, Kendall Bennett wrote:
>>>
>>>>Helge Hafting <helgehaf@aitel.hist.no> wrote:
>>>
>>>That's fine.  What I meant, was please make it independent of the
>>>VESA framebuffer driver, because one might want to use an
>>>acellerated driver when one is available.
>>
>>Oh, it already is. The VESA driver is not actually done yet so the only
>>drivers using VideoBoot right now are the accelerated ones ;-)
>>
> 
> 
> If these get in (emulator with/without the video boot), I'm willing to
> modify the vesafb driver.

Well, I played with the emulator last night to see if I could reduce the 
code size, so that it would be easier to make it to the official kernel.

I only took ops.c and did some transformations, like using a single 
function to make several operations based on the opcode, instead of a 
separate function for each opcode, etc.[1]

This is the result. Before:

Size of stripped libx86emu.a: ~74kb
ops.c source code lines: 11682
ops.o .text size: 36136
ops.o .data: 1312

After:

Size of stripped libx86emu.a: ~57kb
ops.c source code lines: 5908
ops.o .text size: 19320
ops.o .data: 1280

If the same treatment is applied to ops2.c and prim_ops.c, I believe it 
would be possible to have a functional emulator for about 32kb of kernel 
code size, which seems pretty reasonable to me and could solve a lot of 
problems.

The decrease in source code size also helps maintenance, since there is 
not so much repeated code has it was before.

Of course, these changes are optimizing the emulator for code size, and 
not execution speed. I haven't done any benchmarks to see if there is a 
noticeable difference in speed.






[1] The worst offenders were actually constructions like:

FETCH_DECODE_MODRM(mod, rh, rl);
switch (mod) {
   case 0:
       ...<some code>
       addr = decode_rm00_address(rl);
       ...<some more code>
       break;
   case 1:
       ...<exactly the same code as above>
       addr = decode_rm01_address(rl);
       ...<exactly the same code as above>
       break;
   case 2:
       ...<exactly the same code as above>
       addr = decode_rm10_address(rl);
       ...<exactly the same code as above>
       break;
    case 3:
       <diferent code to handle register-register ops>
       break;
   }

This could be easily changed to:

FETCH_DECODE_MODRM(mod, rh, rl);
if (mod < 3) {
       ...<some code>
       addr = decode_rmXX_address(mod, rl);
       ...<some more code>
   } else {
       <diferent code to handle register-register ops>
   }

simply by making a new decode_rmXX_address function that handles the mod 
parameter. There were more than 20 of these, and some of them were 
pretty big.

-- 
Paulo Marques - www.grupopie.com

All that is necessary for the triumph of evil is that good men do nothing.
Edmund Burke (1729 - 1797)




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

[Kendall Bennett]

Paulo Marques <pmarques@grupopie.com> wrote:

> Well, I played with the emulator last night to see if I could
> reduce the code size, so that it would be easier to make it to the
> official kernel. 
> 
> I only took ops.c and did some transformations, like using a
> single function to make several operations based on the opcode,
> instead of a separate function for each opcode, etc.[1] 
> 
> This is the result. Before:
> 
> Size of stripped libx86emu.a: ~74kb
> ops.c source code lines: 11682
> ops.o .text size: 36136
> ops.o .data: 1312
> 
> After:
> 
> Size of stripped libx86emu.a: ~57kb
> ops.c source code lines: 5908
> ops.o .text size: 19320
> ops.o .data: 1280
> 
> If the same treatment is applied to ops2.c and prim_ops.c, I
> believe it would be possible to have a functional emulator for
> about 32kb of kernel code size, which seems pretty reasonable to
> me and could solve a lot of problems. 

Wow, that is great!

> The decrease in source code size also helps maintenance, since
> there is not so much repeated code has it was before. 
> 
> Of course, these changes are optimizing the emulator for code
> size, and not execution speed. I haven't done any benchmarks to
> see if there is a noticeable difference in speed. 

Did you get the latest code? I have been sick with the flu and I think I 
forgot to send you the latest code to play with. We should get you set up 
so you can merge your changes into our tree and then we can update the 
one in the X.org tree as well (Egbert Eich usually does that from our 
tree).

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: [Linux-fbdev-devel] Re: Generic VESA framebuffer driver and Video card BOOT?

[Paulo Marques]

Kendall Bennett wrote:
> Paulo Marques <pmarques@grupopie.com> wrote:
> .....
>>If the same treatment is applied to ops2.c and prim_ops.c, I
>>believe it would be possible to have a functional emulator for
>>about 32kb of kernel code size, which seems pretty reasonable to
>>me and could solve a lot of problems. 
> 
> 
> Wow, that is great!

Thanks :)

> 
>>The decrease in source code size also helps maintenance, since
>>there is not so much repeated code has it was before. 
>>
>>Of course, these changes are optimizing the emulator for code
>>size, and not execution speed. I haven't done any benchmarks to
>>see if there is a noticeable difference in speed. 
> 
> 
> Did you get the latest code? I have been sick with the flu and I think I 
> forgot to send you the latest code to play with. We should get you set up 
> so you can merge your changes into our tree and then we can update the 
> one in the X.org tree as well (Egbert Eich usually does that from our 
> tree).

No, I didn't get the latest source (you did disapear for a while :) ).

I started to work on the old source because:

  A - I really wanted to know if this could be done and what kind of 
improvements could be expected, even if the actual changes were thrown 
away in the end

  B - you said that only small bug fixes were made since this version, 
so I probably could diff the source I started from against the latest 
and do the same fixes to my latest source.

One other thing, is there a simple way to test the emulator? I've been 
careful with the changes I did not to change the resulting behaviour of 
the emulator, but I can not _absolutely_ sure that I didn't break 
anything. It would be very good to try the emulator in a controlled 
environment.

Anyway, I think I'll have some more time tonight, so probably tomorrow 
I'll have more information about the final code size.

-- 
Paulo Marques - www.grupopie.com

All that is necessary for the triumph of evil is that good men do nothing.
Edmund Burke (1729 - 1797)

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

[Kendall Bennett]

Paulo Marques <pmarques@grupopie.com> wrote:

> One other thing, is there a simple way to test the emulator? I've
> been careful with the changes I did not to change the resulting
> behaviour of the emulator, but I can not _absolutely_ sure that I
> didn't break anything. It would be very good to try the emulator
> in a controlled environment. 

Unfortunately the test code I wrote years ago is only for Open Watcom and 
uses inline assembler. It hasn't been used for some time and I am not 
sure if it works properly or not (I don't think it does right now). Plus 
we recently found out that it doesn't test everything, just the 
implementation of prim_ops.c.

The only real way to test the emulator is to use it to emulate some code. 
We don't have any code we use on a regular basis to test it, but perhaps 
we should think about building a test suite for it. Usually we test it on 
Video BIOS ROM's, but that is painful because you have to switch video 
cards all the time.

XFree86 and X.org do use the same code so it could be tested there, but 
once again it is only used for Video BIOS ROM stuff. 

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:
Sybase ASE Linux Express Edition - download now for FREE
LinuxWorld Reader's Choice Award Winner for best database on Linux.
http://ads.osdn.com/?ad_id=5588&alloc_id=12065&op=click

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

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

[Richard Smith]

Kendall Bennett 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? 

With all the video chips I've worked with the mfg gives me a binary 
formatted up as an option ROM and I'm responsible for getting it called.

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

What I've seen is that they simply place a copy of the video bios at the 
shadowed legacy vbios range usually 0xc0000 but it can be anywhere in 
the 0xc0000-0x0e0000 range.  Or physically locate the vbios in the 
onboard ROM such that it will show up in that range.

Then when the system bios goes through its scan of the legacy ranges 
looking for option roms it hits the video bios and runs it.

-- 
Richard A. Smith