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
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
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
* 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
* 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
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
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
Rene Herman wrote:
>
> It also provides them as VESA modes yes.
OK, so no work needed.
-hpa
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please
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
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
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
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
>>>
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.
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
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
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
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,
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
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
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
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
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
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
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 <[EMAIL
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 [EMAIL
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
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
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
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
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
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
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,
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
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
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
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.
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
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
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
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
Rene Herman wrote:
It also provides them as VESA modes yes.
OK, so no work needed.
-hpa
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read
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
--- Rene Herman <[EMAIL PROTECTED]> 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
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
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,
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
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
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
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:
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
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
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
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
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
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
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
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
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
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
--- Rene Herman [EMAIL PROTECTED] 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
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
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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
"H. Peter Anvin" <[EMAIL PROTECTED]> writes:
> Eric W. Biederman wrote:
>> Andi Kleen <[EMAIL PROTECTED]> 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
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
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
Eric W. Biederman wrote:
> Andi Kleen <[EMAIL PROTECTED]> 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
Andi Kleen <[EMAIL PROTECTED]> 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
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
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
> 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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a
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
"H. Peter Anvin" <[EMAIL PROTECTED]> 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
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
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
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
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
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
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
-
To
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
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
H. Peter Anvin [EMAIL PROTECTED] 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,
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
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
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a
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
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
Andi Kleen [EMAIL PROTECTED] 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
Eric W. Biederman wrote:
Andi Kleen [EMAIL PROTECTED] 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
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
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,
H. Peter Anvin [EMAIL PROTECTED] writes:
Eric W. Biederman wrote:
Andi Kleen [EMAIL PROTECTED] 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
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
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the
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
92 matches
Mail list logo
