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?

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

[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: [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: [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

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

[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