arch/i386/boot rewrite, and all the hard-coded video cards

arch/i386/boot rewrite, and all the hard-coded video cards

[H. Peter Anvin]

Hi all,

I'm rewriting the i386 setup code in C, instead of assembly, and before
I spend a very large amount of time translating all the various
card-specific probes, I want to ask the following question...

Does *anyone* care about these anymore?

All of these are specific to cards from a very long time ago.  I am
currently planning to retain the VESA-related code, and the standard
video modes, but I'd like to avoid the card-specific stuff, especially
since I have absolutely zero ability to test any of testing them (with
the possible sole exception of the cirrus5 code, which is emulated by qemu.)

Please holler if you care...

	-hpa

Re: arch/i386/boot rewrite, and all the hard-coded video cards

[Jeff Garzik]

H. Peter Anvin wrote:
> Hi all,
> 
> I'm rewriting the i386 setup code in C, instead of assembly, and before
> I spend a very large amount of time translating all the various
> card-specific probes, I want to ask the following question...
> 
> Does *anyone* care about these anymore?
> 
> All of these are specific to cards from a very long time ago.  I am
> currently planning to retain the VESA-related code, and the standard
> video modes, but I'd like to avoid the card-specific stuff, especially
> since I have absolutely zero ability to test any of testing them (with
> the possible sole exception of the cirrus5 code, which is emulated by qemu.)

Do you mean the SVGA chip-specific code, or additionally you are ripping 
out CGA and EGA support?

Out of curiosity what C compiler will you use?

	Jeff

Re: arch/i386/boot rewrite, and all the hard-coded video cards

[H. Peter Anvin]

Jeff Garzik wrote:
> 
> Do you mean the SVGA chip-specific code, or additionally you are ripping
> out CGA and EGA support?
> 

I mean the SVGA chip-specific code.

> Out of curiosity what C compiler will you use?

gcc, using the ".code16gcc" feature of any non-prehistoric binutils.

	-hpa

Re: arch/i386/boot rewrite, and all the hard-coded video cards

[Dave Jones]

On Mon, Apr 30, 2007 at 06:33:09PM -0700, H. Peter Anvin wrote:
 > Hi all,
 > 
 > I'm rewriting the i386 setup code in C, instead of assembly, and before
 > I spend a very large amount of time translating all the various
 > card-specific probes, I want to ask the following question...
 > 
 > Does *anyone* care about these anymore?
 > 
 > All of these are specific to cards from a very long time ago.  I am
 > currently planning to retain the VESA-related code, and the standard
 > video modes, but I'd like to avoid the card-specific stuff, especially
 > since I have absolutely zero ability to test any of testing them (with
 > the possible sole exception of the cirrus5 code, which is emulated by qemu.)
 > 
 > Please holler if you care...

I don't really care, but I wonder what the point is of rewriting something
that hardly ever gets notably changed, and is rarely (if ever?) a source
of bugs.  It might be crufty old assembly, but it's worked well for years.

	Dave

-- 
http://www.codemonkey.org.uk

Re: arch/i386/boot rewrite, and all the hard-coded video cards

[H. Peter Anvin]

Dave Jones wrote:
> 
> I don't really care, but I wonder what the point is of rewriting something
> that hardly ever gets notably changed, and is rarely (if ever?) a source
> of bugs.  It might be crufty old assembly, but it's worked well for years.
> 

Well, it hardly gets notably changed because it is a nightmare to get it
right, and when it is changed, it is likely to be a bug magnet.  The
sheer number of bugs I have found in the process of figuring out what
the current code is doing is pretty much evidence of that.  I'm
surprised fewer bugs are actually manifest, but I guess that shows how
little of the code is actually used.

The "solution" that people have been employing has been to require the
use of special bootloaders for different environments, which enter at
code32_start instead.  Hardly an improvement.

	-hpa

Re: arch/i386/boot rewrite, and all the hard-coded video cards

[Eric W. Biederman]

"H. Peter Anvin" <hpa@zytor.com> writes:

> Dave Jones wrote:
>> 
>> I don't really care, but I wonder what the point is of rewriting something
>> that hardly ever gets notably changed, and is rarely (if ever?) a source
>> of bugs.  It might be crufty old assembly, but it's worked well for years.
>> 
>
> Well, it hardly gets notably changed because it is a nightmare to get it
> right, and when it is changed, it is likely to be a bug magnet.  The
> sheer number of bugs I have found in the process of figuring out what
> the current code is doing is pretty much evidence of that.  I'm
> surprised fewer bugs are actually manifest, but I guess that shows how
> little of the code is actually used.

This sounds plausible.  Although I don't recall seeing that many bugs.
Even if we don't merge your changes the knowledge of the code gained
should be invaluable for future maintenance purposes.  I reserve judgement
on the sanity of the rewrite until I see the patches.

> The "solution" that people have been employing has been to require the
> use of special bootloaders for different environments, which enter at
> code32_start instead.  Hardly an improvement.

This part is incorrect.  Every example I have seen of entering in at
a different entry point is because the environment does not support
16bit BIOS calls.  So the easiest way to skip the kernels BIOS calls
is to skip setup.S.

Not that the x86 BIOS is bad.  It is nearly a marvel in it's simplicity
and ubiquitousness, but it isn't everywhere, and it doesn't make
sense for it to be everywhere.

Eric

Re: arch/i386/boot rewrite, and all the hard-coded video cards

[Linus Torvalds]

On Mon, 30 Apr 2007, H. Peter Anvin wrote:
> 
> Does *anyone* care about these anymore?

Doubtful. The Tseng ET4000 cards may have been the gold standard in 1991, 
but I don't think most people even _remember_ them. And if they have them 
in their machines, they probably tend to run a Linux-1.2 kernel, or at 
least not care a lot about graphics (ie they may have an old card in the 
machine just because they need VGA to boot, rather than because they care 
about Tseng).

And compared to Tseng and S3, most of the other cards there are just 
obscure.

			Linus

Re: arch/i386/boot rewrite, and all the hard-coded video cards

[H. Peter Anvin]

Andi Kleen wrote:
>> Not that the x86 BIOS is bad.  It is nearly a marvel in it's simplicity
>> and ubiquitousness, 
> 
> Simplicity? That must be why x86 motherbords are shipping with (compressed) 
> 8MB BIOS flash chips now.

Very little of that is the actual BIOS, though.  Most of it is generally
QuickPlay, which tends to be a Linux system...

	-hpa

Re: arch/i386/boot rewrite, and all the hard-coded video cards

[Dave Jones]

On Mon, Apr 30, 2007 at 07:43:54PM -0700, Linus Torvalds wrote:

 > Doubtful. The Tseng ET4000 cards may have been the gold standard in 1991, 
 > but I don't think most people even _remember_ them.

heh. it was only recently I gave away a _dual head_ pci et4000.
One of our X guys grabbed it because it was so... obscure.

With any luck he'll never plug it in.

	Dave

-- 
http://www.codemonkey.org.uk

Re: arch/i386/boot rewrite, and all the hard-coded video cards

[Eric W. Biederman]

Andi Kleen <ak@suse.de> writes:

>> Not that the x86 BIOS is bad.  It is nearly a marvel in it's simplicity
>> and ubiquitousness, 
>
> Simplicity? That must be why x86 motherbords are shipping with (compressed) 
> 8MB BIOS flash chips now.

Those would be 8 megabit chips, and those would be server motherboards
you are looking.  Most likely the ones that are starting to think ahead
to EFI support.

There are thread jobs the firmware on a PC does.
- Configure the hardware to look like a PC.
  What with memory controller setup and the like that is the hard
  part and the bulk of the work.

  Since this is written quickly and in assembler it has likely descended
  into spaghetti by now.

- Whatever ACPI does. suspend/resume and etc.

- Provide a subroutine library for boot loaders.
  That subroutine library is what gets exposed.

Now if you compare what it takes to implement the PC BIOS interface
the "subroutine library for bootloaders"  with EFI, or open firmware
or a real OS you will quickly see how very small and simple it is.  It
isn't a beautiful interface but it is short and to the point.

Eric

Re: arch/i386/boot rewrite, and all the hard-coded video cards

[H. Peter Anvin]

Eric W. Biederman wrote:
> Andi Kleen <ak@suse.de> writes:
> 
>>> Not that the x86 BIOS is bad.  It is nearly a marvel in it's simplicity
>>> and ubiquitousness, 
>> Simplicity? That must be why x86 motherbords are shipping with (compressed) 
>> 8MB BIOS flash chips now.
> 
> Those would be 8 megabit chips, and those would be server motherboards
> you are looking.  Most likely the ones that are starting to think ahead
> to EFI support.
> 

No, 4-8 MB chips are starting to be deployed, but the bulk is for
OS-less applications.

	-hpa

Re: arch/i386/boot rewrite, and all the hard-coded video cards

[H. Peter Anvin]

Andi Kleen wrote:
> 
> At least my Asus board with 8Mb flash doesn't have anything called that.
> There is also no special preboot environment
> 
> iirc Asus ships dual BIOS though, but even half that compressed is a lot.
> 

8 Mb or 8 MB?  Big difference...

So you have 512K worth of compressed code, most of which is running the
configuration menus and code to do initialization and setup of the
runtime environment (build tables, and so on.)  That's not really BIOS,
per se, in the sense of an interface; any firmware has to do that stuff
no matter what.

	-hpa

Re: arch/i386/boot rewrite, and all the hard-coded video cards

[Eric W. Biederman]

"H. Peter Anvin" <hpa@zytor.com> writes:

> Eric W. Biederman wrote:
>> Andi Kleen <ak@suse.de> writes:
>> 
>>>> Not that the x86 BIOS is bad.  It is nearly a marvel in it's simplicity
>>>> and ubiquitousness, 
>>> Simplicity? That must be why x86 motherbords are shipping with (compressed) 
>>> 8MB BIOS flash chips now.
>> 
>> Those would be 8 megabit chips, and those would be server motherboards
>> you are looking.  Most likely the ones that are starting to think ahead
>> to EFI support.
>> 
>
> No, 4-8 MB chips are starting to be deployed, but the bulk is for
> OS-less applications.

I don't doubt that there are some rare systems with very large
capacity flash chips.  However the size of all BIOS chips are measured
in bits.  Anyone talking about the capacity of BIOS chips in bytes
and not bits always raises a red flag with me because that is a very
common mistake.

I would be very surprised if the high volume commodity boards have
exceeded 8 megabits.

Eric

Re: arch/i386/boot rewrite, and all the hard-coded video cards

[H. Peter Anvin]

Eric W. Biederman wrote:
> 
> I would be very surprised if the high volume commodity boards have
> exceeded 8 megabits.
> 

Most of the high-capacity chips are used on laptops, not conventional
motherboards.

	-hpa

Re: arch/i386/boot rewrite, and all the hard-coded video cards

[Andi Kleen]

> Not that the x86 BIOS is bad.  It is nearly a marvel in it's simplicity
> and ubiquitousness, 

Simplicity? That must be why x86 motherbords are shipping with (compressed) 
8MB BIOS flash chips now.

-Andi

Re: arch/i386/boot rewrite, and all the hard-coded video cards

[WANG Cong]

On Mon, Apr 30, 2007 at 06:33:09PM -0700, H. Peter Anvin wrote:
>Hi all,
>
>I'm rewriting the i386 setup code in C, instead of assembly, and before
>I spend a very large amount of time translating all the various
>card-specific probes, I want to ask the following question...
>
>Does *anyone* care about these anymore?

I think this is a good work, but it is not easy.
Hope you can do that well. ;)

Re: arch/i386/boot rewrite, and all the hard-coded video cards

[Andi Kleen]

On Mon, Apr 30, 2007 at 07:54:27PM -0700, H. Peter Anvin wrote:
> Andi Kleen wrote:
> >> Not that the x86 BIOS is bad.  It is nearly a marvel in it's simplicity
> >> and ubiquitousness, 
> > 
> > Simplicity? That must be why x86 motherbords are shipping with (compressed) 
> > 8MB BIOS flash chips now.
> 
> Very little of that is the actual BIOS, though.  Most of it is generally
> QuickPlay, which tends to be a Linux system...

At least my Asus board with 8Mb flash doesn't have anything called that.
There is also no special preboot environment

iirc Asus ships dual BIOS though, but even half that compressed is a lot.

-Andi

Re: arch/i386/boot rewrite, and all the hard-coded video cards

[Rene Herman]

On 05/01/2007 04:43 AM, Linus Torvalds wrote:

> Doubtful. The Tseng ET4000 cards may have been the gold standard in 1991, 
> but I don't think most people even _remember_ them. And if they have them 
> in their machines, they probably tend to run a Linux-1.2 kernel, or at 
> least not care a lot about graphics (ie they may have an old card in the 
> machine just because they need VGA to boot, rather than because they care 
> about Tseng).

My 386 has an ET4000. An ET4000AX/W32 even. And you bet it's because it's 
nifty! Okay, I'll admit the thing doesn't currently run a 2.6 kernel...

The answer will probably be "no", but would this be a good point to ask if 
this would be a good time to not bother with the mode switching code at all 
anymore? I'm generally rather appreciative of old gunk but I haven't cared 
for that specific feature for ages now. I personally don't use framebuffer, 
but I would if I wanted more than the plain VGA my BIOS sets up.

I'd consider keeping anything but VESA 1.2 (which that ET4000 and most all 
other Super VGA cards of the era also do!) nonsensical and as far as I'm 
concerned this includes all the VGA modes with the strange number of lines; 
a 43/60-line VGA screen is too horrible to look at anyway...

Rene.

Re: arch/i386/boot rewrite, and all the hard-coded video cards

[Rene Herman]

On 05/01/2007 10:32 PM, Rene Herman wrote:

> On 05/01/2007 04:43 AM, Linus Torvalds wrote:
> 
>> Doubtful. The Tseng ET4000 cards may have been the gold standard in 
>> 1991, but I don't think most people even _remember_ them. And if they 
>> have them in their machines, they probably tend to run a Linux-1.2 
>> kernel, or at least not care a lot about graphics (ie they may have an 
>> old card in the machine just because they need VGA to boot, rather 
>> than because they care about Tseng).
> 
> My 386 has an ET4000. An ET4000AX/W32 even. And you bet it's because 
> it's nifty! Okay, I'll admit the thing doesn't currently run a 2.6 
> kernel...
> 
> The answer will probably be "no", but would this be a good point to ask 
> if this would be a good time to not bother with the mode switching code 
> at all anymore? I'm generally rather appreciative of old gunk but I 
> haven't cared for that specific feature for ages now. I personally don't 
> use framebuffer, but I would if I wanted more than the plain VGA my BIOS 
> sets up.

Confusingly put; please consider a "If the switching code in itself is still 
considered relevant, " to be present here. But rip it all out, I'd say...

> I'd consider keeping anything but VESA 1.2 (which that ET4000 and most 
> all other Super VGA cards of the era also do!) nonsensical and as far as 
> I'm concerned this includes all the VGA modes with the strange number of 
> lines; a 43/60-line VGA screen is too horrible to look at anyway...

Rene.

Re: arch/i386/boot rewrite, and all the hard-coded video cards

[Linus Torvalds]

On Tue, 1 May 2007, Rene Herman wrote:
> 
> The answer will probably be "no", but would this be a good point to ask if
> this would be a good time to not bother with the mode switching code at all
> anymore?

The standard extended modes are actually really useful, if for a very 
simply reason: they give you bigger more lines on screen when a bug 
happens.

So I _still_ occasionally use "vga=extended" just for that reason. The  
default 80x25 thing scrolls most oops away.

> I'd consider keeping anything but VESA 1.2 (which that ET4000 and most all
> other Super VGA cards of the era also do!) nonsensical and as far as I'm
> concerned this includes all the VGA modes with the strange number of lines; a
> 43/60-line VGA screen is too horrible to look at anyway...

80x50 is useful for the above reason. Yeah, it's ugly, but it's useful for 
the "It's too much work to try to do anything but just take a digital 
photo of the screen". And that 50-line mode will actually be 43 in EGA 
mode, I think.

The 132x50 mode is probably a bit prettier, and is fairly common too, and 
useful for the same reason.

And once you support those, you might as well support all the VESA text 
modes.

And yes, I'm literally talking about the *text* modes. Not all of us want 
to have fbcon built in - I prefer my text-mode lean and mean and fast as 
hell, and if I want a frame buffer, I'll take X11, thank you very much.

		Linus

Re: arch/i386/boot rewrite, and all the hard-coded video cards

[H. Peter Anvin]

Linus Torvalds wrote:
> 
> And yes, I'm literally talking about the *text* modes. Not all of us want 
> to have fbcon built in - I prefer my text-mode lean and mean and fast as 
> hell, and if I want a frame buffer, I'll take X11, thank you very much.
> 

I use framebuffer console pretty much for one purpose -- it sucks less
memory bandwidth when you're stuck with a UMA configuration.  Text modes
require random access to the font buffer, which means it hogs the DRAM
pretty badly, unless the chipset designer decided to burn an 8K SRAM,
which is still a pretty pricey hunk of chip real estate.

	-hpa

Re: arch/i386/boot rewrite, and all the hard-coded video cards

[Rene Herman]

On 05/01/2007 11:41 PM, Linus Torvalds wrote:

> The standard extended modes are actually really useful, if for a very 
> simply reason: they give you bigger more lines on screen when a bug 
> happens.
> 
> So I _still_ occasionally use "vga=extended" just for that reason. The  
> default 80x25 thing scrolls most oops away.

Not the right time, but I've wanted to ask for ages... why can't we keep 
hardware scrolling through the VGA text buffer on a OOPS available from 
Shift-PageUp/Down? With hardware scrolling it's really minimal code IIRC.

>> I'd consider keeping anything but VESA 1.2 (which that ET4000 and most all
>> other Super VGA cards of the era also do!) nonsensical and as far as I'm
>> concerned this includes all the VGA modes with the strange number of lines; a
>> 43/60-line VGA screen is too horrible to look at anyway...
> 
> 80x50 is useful for the above reason. Yeah, it's ugly, but it's useful for 
> the "It's too much work to try to do anything but just take a digital 
> photo of the screen". And that 50-line mode will actually be 43 in EGA 
> mode, I think.
> 
> The 132x50 mode is probably a bit prettier, and is fairly common too, and 
> useful for the same reason.
> 
> And once you support those, you might as well support all the VESA text 
> modes.

Yes, keeping VESA is sensible if you keep anything but note that many of the 
extended text modes video.S can set are not VESA modes but modes available 
on any standard VGA through tweaking VGA registers. The standard VGA text 
modes are:

Mode 0/1:	40x25 (monochrome/colour)
Mode 2/3:	80x25 (monochrome/colour)
Mode 7:		80x25 (monochrome, MDA/Hercules)

VESA 1.2 adds text modes:

Mode 0x108:	80x60
Mode 0x109:	132x25
Mode 0x10a:	132x43
Mode 0x10b:	132x50
Mode 0x10c:	132x60

That 80x43 mode is one of the "specially tweaked VGA modes" (by using a 8x8 
character cell instead of the normal 8x14 on the 640x350 screen; it turns 
into 80x50 on 640x400).

Well, yes, for symetry with the 132x VESA fonts I guess that 80x43/50 may be 
kept; they're sort of "standard" in the sense that they've been widely used 
  and VESA probably only didn't include them since that was the case already 
anyway. And you can set them through standard BIOS calls to replace the font.

But note there are also tweaked "80x28", "80x30", "80x34", and "80x60" modes 
there that I feel do not serve any purpose whatsoever and do make for rather 
involved code that I expect HPA wouldn't so much mind killing. Having:

1) the standard CGA/MDA/HGA/EGA/VGA modes on an adapter that can do them
2) 80x43/80x50 on the EGA/VGA
3) the VESA 1.2 alphanumeric modes if we have VESA.

should really be enough I feel (and 2 only since it's simple and well-known)

> And yes, I'm literally talking about the *text* modes. Not all of us want 
> to have fbcon built in - I prefer my text-mode lean and mean and fast as 
> hell, and if I want a frame buffer, I'll take X11, thank you very much.

I agree and don't use fbcon myself. This is (slowly, very slowly) becoming a 
bit of an obsolete standpoint even on a PC though; doing away with VGA may 
not be all that bad on new machines. And with the absolutely horrible 
interpolation TFTS do on anything but their native resolutions, looking at a 
640x350/400 screen is sometimes almost too painful even for short purposes 
when you have one of those.

Rene.

Re: arch/i386/boot rewrite, and all the hard-coded video cards

[Antonino A. Daplas]

On Tue, 2007-05-01 at 14:41 -0700, Linus Torvalds wrote:
> 
> On Tue, 1 May 2007, Rene Herman wrote:
> > 

> And yes, I'm literally talking about the *text* modes. Not all of us want 
> to have fbcon built in - I prefer my text-mode lean and mean and fast as 
> hell, and if I want a frame buffer, I'll take X11, thank you very much.
> 

I would agree with the lean and mean, but faster, that's another
question.  Even vesafb at 640x480-8 with ypan and mtrr is 30% faster
than vgacon (And for those of you with vesafb that cannot ypan, try
vgacon with the 'no-scroll' option for a more apple-to-apple
comparison).  And with chipset-specific drivers, it can be as much as 3x
faster than vgacon.

Anyway, my default console is still text mode, even though I'm the
framebuffer maintainer :-)

Tony

Re: arch/i386/boot rewrite, and all the hard-coded video cards

[Martin Mares]

Hi!

> I mean the SVGA chip-specific code.

Feel free to kill it, anybody using these cards is very unlikely to run
a 2.6.x kernel.

However, the BIOS mode switching is still useful.

				Have a nice fortnight
-- 
Martin `MJ' Mares                          <mj@ucw.cz>   http://mj.ucw.cz/
Faculty of Math and Physics, Charles University, Prague, Czech Rep., Earth
Hi! I'm a .signature virus! Copy me into your ~/.signature to help me spread!

Re: arch/i386/boot rewrite, and all the hard-coded video cards

[Andi Kleen]

On Wednesday 02 May 2007 09:46:07 Martin Mares wrote:
> Hi!
> 
> > I mean the SVGA chip-specific code.
> 
> Feel free to kill it, anybody using these cards is very unlikely to run
> a 2.6.x kernel.

I agree; that code can all go.

What also seems to miss are the early CPUID checks I recently added
and which x86-64 has for some time.

Also if you ever add x86-64 support it does an additional BIOS
call to tell the BIOS it is 64bit.

-Andi

Re: arch/i386/boot rewrite, and all the hard-coded video cards

[Jan Engelhardt]

On May 1 2007 14:41, Linus Torvalds wrote:
>On Tue, 1 May 2007, Rene Herman wrote:
>> 
>> The answer will probably be "no", but would this be a good point to ask if
>> this would be a good time to not bother with the mode switching code at all
>> anymore?
>
>The standard extended modes are actually really useful, if for a very 
>simply reason: they give you bigger more lines on screen when a bug 
>happens.
>
>So I _still_ occasionally use "vga=extended" just for that reason. The  
>default 80x25 thing scrolls most oops away.
>[...]
>80x50 is useful for the above reason. Yeah, it's ugly, but it's useful for 
>the "It's too much work to try to do anything but just take a digital 
>photo of the screen". And that 50-line mode will actually be 43 in EGA 
>mode, I think.
>
>The 132x50 mode is probably a bit prettier, and is fairly common too, and 
>useful for the same reason.

Seconded. 80x50, and where platforms support it, *80x60 and 132x60*,
is kinda handy (despite the font getting smaller and smaller, heh),
esp. when you don't run it in VMware and not have some capturing
device (serial con/netconsole.. takes time to set up)

>And yes, I'm literally talking about the *text* modes. Not all of us want 
>to have fbcon built in - I prefer my text-mode lean and mean and fast as 
>hell, and if I want a frame buffer, I'll take X11, thank you very much.

You speak for me :)



Jan
-- 

Re: arch/i386/boot rewrite, and all the hard-coded video cards

[Lennart Sorensen]

On Wed, May 02, 2007 at 09:46:07AM +0200, Martin Mares wrote:
> > I mean the SVGA chip-specific code.
> 
> Feel free to kill it, anybody using these cards is very unlikely to run
> a 2.6.x kernel.
> 
> However, the BIOS mode switching is still useful.

I have a 486 with a Mach64 in it running 2.6.18, so well, it just might
happen you know.  I do tend to run it plain 80x25 at the moment, but
that is mainly because it is just doing firewall duties.  I never was
very impressed by the mach64 fb driver when I played with it years ago,
and vesa isn't an option on that card (needed a DOS TSR to do that).

Not sure if that card is covered by any of the chip specific code.

So what is wrong with a 15 year old machine when it has 48MB ram and
18GB disk space?

--
Len Sorensen

Re: arch/i386/boot rewrite, and all the hard-coded video cards

[H. Peter Anvin]

Andi Kleen wrote:
> 
> I agree; that code can all go.
> 
> What also seems to miss are the early CPUID checks I recently added
> and which x86-64 has for some time.
> 
> Also if you ever add x86-64 support it does an additional BIOS
> call to tell the BIOS it is 64bit.
> 

Will do.  I'd like to make this code unified between i386 and x86-64.

	-hpa

Re: arch/i386/boot rewrite, and all the hard-coded video cards

[H. Peter Anvin]

Jan Engelhardt wrote:
>> [...]
>> 80x50 is useful for the above reason. Yeah, it's ugly, but it's useful for 
>> the "It's too much work to try to do anything but just take a digital 
>> photo of the screen". And that 50-line mode will actually be 43 in EGA 
>> mode, I think.
>>
>> The 132x50 mode is probably a bit prettier, and is fairly common too, and 
>> useful for the same reason.
> 
> Seconded. 80x50, and where platforms support it, *80x60 and 132x60*,
> is kinda handy (despite the font getting smaller and smaller, heh),
> esp. when you don't run it in VMware and not have some capturing
> device (serial con/netconsole.. takes time to set up)
> 

This is what I've decided on doing:

I'm having a framework for multiple drivers (probe and set methods,
basically); the stock distro will have VGA and VESA drivers only.
Dropping new drivers in is trivial if someone wants to.  I was going to
leave in the CL54xx and ATI drivers since I actually have specimens of
those, except it appears that on current specimens of those cards, the
probe succeeds but the mode-setting fails, so I dropped those as well.

If someone happens to have algorithms for setting 132-character mode on
especially the CL54xx series with raw register writes I'd actually be
interested, since that's what Bochs and Qemu emulate, and on those it
would be really nice to have a larger text mode.

	-hpa

Re: arch/i386/boot rewrite, and all the hard-coded video cards

[Rene Herman]

On 05/02/2007 10:59 PM, H. Peter Anvin wrote:

> I'm having a framework for multiple drivers (probe and set methods,
> basically); the stock distro will have VGA and VESA drivers only.
> Dropping new drivers in is trivial if someone wants to.

It sounds like going overboard a bit; 80x25 standard VGA, 80x43/50 line VGA 
(settable through simple BIOS calls) and VESA (80x60, 132x25/43/50/60) is 
all that anyone wants. If Bochs and Qemu emulata a CL54xx, they'll provide a 
VESA BIOS for it as well, I suppose?

Rene.

Re: arch/i386/boot rewrite, and all the hard-coded video cards

[H. Peter Anvin]

Rene Herman wrote:
> On 05/02/2007 10:59 PM, H. Peter Anvin wrote:
> 
>> I'm having a framework for multiple drivers (probe and set methods,
>> basically); the stock distro will have VGA and VESA drivers only.
>> Dropping new drivers in is trivial if someone wants to.
> 
> It sounds like going overboard a bit; 80x25 standard VGA, 80x43/50 line
> VGA (settable through simple BIOS calls) and VESA (80x60,
> 132x25/43/50/60) is all that anyone wants. If Bochs and Qemu emulata a
> CL54xx, they'll provide a VESA BIOS for it as well, I suppose?

Yes, but like most other VESA BIOSen they don't have any support for
extended text modes in their BIOS (they could add it, presumably.)

However, the pluggable framework is quite trivial and makes the code
look really clean, so I'm keeping it regardless.

	-hpa

Re: arch/i386/boot rewrite, and all the hard-coded video cards

[Rene Herman]

On 05/02/2007 11:15 PM, H. Peter Anvin wrote:

> However, the pluggable framework is quite trivial and makes the code
> look really clean, so I'm keeping it regardless.

Sheesh. Anyways, I know you asked about register writes but in case it's 
still useful info: the CL54xx adapters have 132x43 and 132x25 as BIOS modes 
0x54 and 0x55 (ie, just int 0x10 modes) respectively. No idea how complete 
the Bochs/Qemu video BIOS is.

Rene.

Re: arch/i386/boot rewrite, and all the hard-coded video cards

[H. Peter Anvin]

Rene Herman wrote:
> On 05/02/2007 11:15 PM, H. Peter Anvin wrote:
> 
>> However, the pluggable framework is quite trivial and makes the code
>> look really clean, so I'm keeping it regardless.
> 
> Sheesh. Anyways, I know you asked about register writes but in case it's
> still useful info: the CL54xx adapters have 132x43 and 132x25 as BIOS
> modes 0x54 and 0x55 (ie, just int 0x10 modes) respectively. No idea how
> complete the Bochs/Qemu video BIOS is.

No, they don't.  I've found enough Cirrus docs to learn that that was
pulled out of their BIOS when they ran out of space.

The Bochs/Qemu biosen don't have it.

	-hpa

Re: arch/i386/boot rewrite, and all the hard-coded video cards

[Rene Herman]

On 05/02/2007 11:25 PM, H. Peter Anvin wrote:

>> Anyways, I know you asked about register writes but in case it's
>> still useful info: the CL54xx adapters have 132x43 and 132x25 as BIOS
>> modes 0x54 and 0x55 (ie, just int 0x10 modes) respectively. No idea how
>> complete the Bochs/Qemu video BIOS is.
> 
> No, they don't.  I've found enough Cirrus docs to learn that that was
> pulled out of their BIOS when they ran out of space.

Mine has them.

Rene.

Re: arch/i386/boot rewrite, and all the hard-coded video cards

[H. Peter Anvin]

Rene Herman wrote:
> On 05/02/2007 11:25 PM, H. Peter Anvin wrote:
> 
>>> Anyways, I know you asked about register writes but in case it's
>>> still useful info: the CL54xx adapters have 132x43 and 132x25 as BIOS
>>> modes 0x54 and 0x55 (ie, just int 0x10 modes) respectively. No idea how
>>> complete the Bochs/Qemu video BIOS is.
>>
>> No, they don't.  I've found enough Cirrus docs to learn that that was
>> pulled out of their BIOS when they ran out of space.
> 
> Mine has them.
> 

The problem is to detect the ones that have it from the ones that don't.

	-hpa

Re: arch/i386/boot rewrite, and all the hard-coded video cards

[Rene Herman]

On 05/03/2007 12:11 AM, H. Peter Anvin wrote:

> The problem is to detect the ones that have it from the ones that don't.

Checking here, and mine also has 132x25 as BIOS mode 0x14 in addition to 
0x55. Probably also not universal, and 0x54 (132x43) doesn't seem to be 
repeated. Unfortunate that Qemu/Bocks don't have the VESA text modes.

Rene.

Re: arch/i386/boot rewrite, and all the hard-coded video cards

[H. Peter Anvin]

Rene Herman wrote:
> On 05/03/2007 12:11 AM, H. Peter Anvin wrote:
> 
>> The problem is to detect the ones that have it from the ones that don't.
> 
> Checking here, and mine also has 132x25 as BIOS mode 0x14 in addition to
> 0x55. Probably also not universal, and 0x54 (132x43) doesn't seem to be
> repeated. Unfortunate that Qemu/Bocks don't have the VESA text modes.
> 

Does it export these modes though the VESA interface, or do you have to
"select them blind?"

	-hpa

Re: arch/i386/boot rewrite, and all the hard-coded video cards

[Rene Herman]

On 05/03/2007 12:59 AM, H. Peter Anvin wrote:

> Rene Herman wrote:

>> Checking here, and mine also has 132x25 as BIOS mode 0x14 in addition to
>> 0x55. Probably also not universal, and 0x54 (132x43) doesn't seem to be
>> repeated. Unfortunate that Qemu/Bocks don't have the VESA text modes.
> 
> Does it export these modes though the VESA interface, or do you have to
> "select them blind?"

It also provides them as VESA modes yes. On further inspection, 0x14 is 
actually a bit different:

BIOS 0x14 =              132x25, 8x16 char cell on 1056x400
BIOS 0x54 = VESA 0x10A = 132x43, 8x8  char cell on 1056x350
BIOS 0x55 = VESA 0x109 = 132x25, 8x14 char cell on 1056x350

Booting 2.6.20.1 on the machine with vga=ask finds BIOS 0x14 as 0214 and 
VESA 0x10A as 030A but allows me to select 0254, 0255 and 0309 as well.
('scan' finds BIOS 0x14 as 0114 and BIOS 0x54 as 0154)

Rene.

Re: arch/i386/boot rewrite, and all the hard-coded video cards

[H. Peter Anvin]

Rene Herman wrote:
> 
> It also provides them as VESA modes yes.

OK, so no work needed.

	-hpa

Re: arch/i386/boot rewrite, and all the hard-coded video cards

[H. Peter Anvin]

Andi Kleen wrote:
> 
> I agree; that code can all go.
> 
> What also seems to miss are the early CPUID checks I recently added
> and which x86-64 has for some time.
> 

I probably need to rebase against your tree.  It makes more sense, anyway.

Either way, I just added a pretty decent framework for testing the CPU
features and barfing if they're missing.

> Also if you ever add x86-64 support it does an additional BIOS
> call to tell the BIOS it is 64bit.

Added.

	-hpa

Re: arch/i386/boot rewrite, and all the hard-coded video cards

[Oleg Verych]

* From: "H. Peter Anvin"
* Date: Tue, 01 May 2007 14:52:53 -0700
>
> Linus Torvalds wrote:
>> 
>> And yes, I'm literally talking about the *text* modes. Not all of us want 
>> to have fbcon built in - I prefer my text-mode lean and mean and fast as 
>> hell, and if I want a frame buffer, I'll take X11, thank you very much.
>> 
>
> I use framebuffer console pretty much for one purpose -- it sucks less
> memory bandwidth when you're stuck with a UMA configuration.  Text modes
> require random access to the font buffer, which means it hogs the DRAM
> pretty badly, unless the chipset designer decided to burn an 8K SRAM,
> which is still a pretty pricey hunk of chip real estate.

When i first booted new Intel dualcore PC with

04:00.0 VGA compatible controller: ATI Technologies Inc RV370 [Sapphire X550 Silent]

back in November i discovered, that graphic/BIOS and normal text mode
aren't working right from power-on. I.e. it is with snow and random
switch on/off behavior, unless you do some reset button pushing.

Even after that is OK, shiny new 19" LCD from Sony with black screen and
glass in front of it in 80x25 mode shows contents in kind of unfocused
form. Yes it's because discrete pixels are not matching this legacy
resolution; standard graphic mode is so clear-cut, that i even can't
focus on it myself ;).

Thus, text mode on modern hardware isn't useable that much, only with
Terminus font it is kind of normal (kudos to Dimitar Toshkov Jekov).
But it's only option to unfortunately sucking X11, even with memory
bandwidth, you are talking about.
____

Re: arch/i386/boot rewrite, and all the hard-coded video cards

[H. Peter Anvin]

Oleg Verych wrote:
> Thus, text mode on modern hardware isn't useable that much, only with
> Terminus font it is kind of normal (kudos to Dimitar Toshkov Jekov).
> But it's only option to unfortunately sucking X11, even with memory
> bandwidth, you are talking about.

That's another reason to use the framebuffer console on laptops.

	-hpa

Re: arch/i386/boot rewrite, and all the hard-coded video cards

[Oleg Verych]

On Wed, Jun 13, 2007 at 10:11:12PM -0700, H. Peter Anvin wrote:
> Oleg Verych wrote:
> > Thus, text mode on modern hardware isn't useable that much, only with
> > Terminus font it is kind of normal (kudos to Dimitar Toshkov Jekov).
> > But it's only option to unfortunately sucking X11, even with memory
> > bandwidth, you are talking about.
> 
> That's another reason to use the framebuffer console on laptops.

Last time i tried, it wasn't so much fun either. Mainly due to wild
cursor, that in normal text mode is well-behaved thing. Visually fb looks
much heavier. What's the benefit, if you see how windows in emacs are
painted? I don't know how giga-hertz/mem in cpu/sys-ram,
mega-hertz/ram in gpu are doing better job WRT to anything in visual
domain.

Also i don't know what to do in case of bugs/oops and "officially" closed
hardware specs on ATI chips{ref}.

About laptop. First and last time i ran new X11 (X.org) there, it drove
VGA fan really crazy. Don't know how it changed now, it was certainly due
to blindly switching 3D on. I don't want to remove *standard* drivers
because of that stupidness [see ref].

And after whole year being with Debian Sarge only, new application update
led me to just drop all that X stuff and run windoze (silently sold to me
with that laptop) if i need a stupid web browser with all that WEB 2.0
and Java crap...
____

Re: arch/i386/boot rewrite, and all the hard-coded video cards

[Jan Engelhardt]

On May 1 2007 15:41, Vlad wrote:
>H. Peter Anvin wrote:
>> I'm rewriting the i386 setup code in C, instead of assembly,
>> and before I spend a very large amount of time translating
>> all the various card-specific probes, I want to ask the
>> following question...
>>
>> Does *anyone* care about these anymore?
>
>Yes, booting Linux on old i386/i486 hardware is still very useful for
>forensic purposes and recovering important data.

Not only that, but there's tons of fun involved. I mean, when was the
last time you ran a *recent* kernel from the 2006/2007 era on an
original i386 from 1990 with 3 bogomips? :) (Though I guess these
boxes don't have any 'modern' video besides 640x480x16 or 320x200x256
anyway.)

Jan
-- 

Re: arch/i386/boot rewrite, and all the hard-coded video cards

[Vlad]

--- Rene Herman <rene.herman@gmail.com> wrote:
> On 05/02/2007 12:41 AM, Vlad wrote:
> 
> > H. Peter Anvin wrote:
> 
> >> I'm rewriting the i386 setup code in C, instead of assembly,
> >> and before I spend a very large amount of time translating
> >> all the various card-specific probes, I want to ask the
> >> following question...
> >>
> >> Does *anyone* care about these anymore?
> > 
> > Yes, booting Linux on old i386/i486 hardware is still very useful
> for
> > forensic purposes and recovering important data. I've personally
> had
> > to do this many times, and I'm sure others have as well.
> > 
> > Booting is such a critical process that a user would be completely
> > lost as to why it fails, especially if they can't see any output
> on
> > the screen. I think it would be a shame to prevent Linux from
> running
> > on these machines.
> 
> He wasn't asking about doing away with all video output on 386/486s,
> but 
> with special Super VGA adapter specific modes. You'd have normal VGA
> 
> available as always, and VESA if the videocard supports it (which
> all cards 
> that _can_ do more than 80x25 do).

Oh, OK. Thanks for clarifying this for me.

Vlad

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

Re: arch/i386/boot rewrite, and all the hard-coded video cards

[Rene Herman]

On 05/02/2007 12:41 AM, Vlad wrote:

> H. Peter Anvin wrote:

>> I'm rewriting the i386 setup code in C, instead of assembly,
>> and before I spend a very large amount of time translating
>> all the various card-specific probes, I want to ask the
>> following question...
>>
>> Does *anyone* care about these anymore?
> 
> Yes, booting Linux on old i386/i486 hardware is still very useful for
> forensic purposes and recovering important data. I've personally had
> to do this many times, and I'm sure others have as well.
> 
> Booting is such a critical process that a user would be completely
> lost as to why it fails, especially if they can't see any output on
> the screen. I think it would be a shame to prevent Linux from running
> on these machines.

He wasn't asking about doing away with all video output on 386/486s, but 
with special Super VGA adapter specific modes. You'd have normal VGA 
available as always, and VESA if the videocard supports it (which all cards 
that _can_ do more than 80x25 do).

Rene.

Re: arch/i386/boot rewrite, and all the hard-coded video cards

[Vlad]

H. Peter Anvin wrote:
> I'm rewriting the i386 setup code in C, instead of assembly,
> and before I spend a very large amount of time translating
> all the various card-specific probes, I want to ask the
> following question...
>
> Does *anyone* care about these anymore?

Yes, booting Linux on old i386/i486 hardware is still very useful for
forensic purposes and recovering important data. I've personally had
to do this many times, and I'm sure others have as well.

Booting is such a critical process that a user would be completely
lost as to why it fails, especially if they can't see any output on
the screen. I think it would be a shame to prevent Linux from running
on these machines.

Vlad

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com