Re: arch/i386/boot rewrite, and all the hard-coded video cards
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...
-
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 the FAQ at http://www.tux.org/lkml/
Re: arch/i386/boot rewrite, and all the hard-coded video cards
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...
-
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 the FAQ at http://www.tux.org/lkml/
Re: arch/i386/boot rewrite, and all the hard-coded video cards
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 - 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 the FAQ at http://www.tux.org/lkml/
Re: arch/i386/boot rewrite, and all the hard-coded video cards
* 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. - 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 the FAQ at http://www.tux.org/lkml/
Re: arch/i386/boot rewrite, and all the hard-coded video cards
* 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. - 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 the FAQ at http://www.tux.org/lkml/
Re: arch/i386/boot rewrite, and all the hard-coded video cards
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 - 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 the FAQ at http://www.tux.org/lkml/
Re: arch/i386/boot rewrite, and all the hard-coded video cards
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 - 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 the FAQ at http://www.tux.org/lkml/
Re: arch/i386/boot rewrite, and all the hard-coded video cards
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 the FAQ at http://www.tux.org/lkml/
Re: arch/i386/boot rewrite, and all the hard-coded video cards
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.
-
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 the FAQ at http://www.tux.org/lkml/
Re: arch/i386/boot rewrite, and all the hard-coded video cards
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 - 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 the FAQ at http://www.tux.org/lkml/
Re: arch/i386/boot rewrite, and all the hard-coded video cards
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. - 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 the FAQ at http://www.tux.org/lkml/
Re: arch/i386/boot rewrite, and all the hard-coded video cards
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 - 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 the FAQ at http://www.tux.org/lkml/
Re: arch/i386/boot rewrite, and all the hard-coded video cards
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. - 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 the FAQ at http://www.tux.org/lkml/
Re: arch/i386/boot rewrite, and all the hard-coded video cards
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 - 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 the FAQ at http://www.tux.org/lkml/
Re: arch/i386/boot rewrite, and all the hard-coded video cards
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. - 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 the FAQ at http://www.tux.org/lkml/
Re: arch/i386/boot rewrite, and all the hard-coded video cards
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 - 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 the FAQ at http://www.tux.org/lkml/
Re: arch/i386/boot rewrite, and all the hard-coded video cards
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. - 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 the FAQ at http://www.tux.org/lkml/
Re: arch/i386/boot rewrite, and all the hard-coded video cards
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 - 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 the FAQ at http://www.tux.org/lkml/
Re: arch/i386/boot rewrite, and all the hard-coded video cards
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 - 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 the FAQ at http://www.tux.org/lkml/
Re: arch/i386/boot rewrite, and all the hard-coded video cards
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 - 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 the FAQ at http://www.tux.org/lkml/
Re: arch/i386/boot rewrite, and all the hard-coded video cards
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 -- - 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 the FAQ at http://www.tux.org/lkml/
Re: arch/i386/boot rewrite, and all the hard-coded video cards
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 -- - 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 the FAQ at http://www.tux.org/lkml/
Re: arch/i386/boot rewrite, and all the hard-coded video cards
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 - 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 the FAQ at http://www.tux.org/lkml/
Re: arch/i386/boot rewrite, and all the hard-coded video cards
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 PROTECTED]> 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! - 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 the FAQ at http://www.tux.org/lkml/
Re: arch/i386/boot rewrite, and all the hard-coded video cards
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 PROTECTED] 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! - 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 the FAQ at http://www.tux.org/lkml/
Re: arch/i386/boot rewrite, and all the hard-coded video cards
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 - 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 the FAQ at http://www.tux.org/lkml/
Re: arch/i386/boot rewrite, and all the hard-coded video cards
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 -- - 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 the FAQ at http://www.tux.org/lkml/
Re: arch/i386/boot rewrite, and all the hard-coded video cards
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 -- - 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 the FAQ at http://www.tux.org/lkml/
Re: arch/i386/boot rewrite, and all the hard-coded video cards
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 - 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 the FAQ at http://www.tux.org/lkml/
Re: arch/i386/boot rewrite, and all the hard-coded video cards
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 - 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 the FAQ at http://www.tux.org/lkml/
Re: arch/i386/boot rewrite, and all the hard-coded video cards
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 - 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 the FAQ at http://www.tux.org/lkml/
Re: arch/i386/boot rewrite, and all the hard-coded video cards
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. - 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 the FAQ at http://www.tux.org/lkml/
Re: arch/i386/boot rewrite, and all the hard-coded video cards
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 - 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 the FAQ at http://www.tux.org/lkml/
Re: arch/i386/boot rewrite, and all the hard-coded video cards
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. - 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 the FAQ at http://www.tux.org/lkml/
Re: arch/i386/boot rewrite, and all the hard-coded video cards
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 - 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 the FAQ at http://www.tux.org/lkml/
Re: arch/i386/boot rewrite, and all the hard-coded video cards
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. - 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 the FAQ at http://www.tux.org/lkml/
Re: arch/i386/boot rewrite, and all the hard-coded video cards
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 - 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 the FAQ at http://www.tux.org/lkml/
Re: arch/i386/boot rewrite, and all the hard-coded video cards
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. - 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 the FAQ at http://www.tux.org/lkml/
Re: arch/i386/boot rewrite, and all the hard-coded video cards
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 - 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 the FAQ at http://www.tux.org/lkml/
Re: arch/i386/boot rewrite, and all the hard-coded video cards
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.
-
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 the FAQ at http://www.tux.org/lkml/
Re: arch/i386/boot rewrite, and all the hard-coded video cards
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 the FAQ at http://www.tux.org/lkml/
Re: arch/i386/boot rewrite, and all the hard-coded video cards
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 - 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 the FAQ at http://www.tux.org/lkml/
Re: arch/i386/boot rewrite, and all the hard-coded video cards
--- 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 > >> 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 - 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 the FAQ at http://www.tux.org/lkml/
Re: arch/i386/boot rewrite, and all the hard-coded video cards
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. - 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 the FAQ at http://www.tux.org/lkml/
Re: arch/i386/boot rewrite, and all the hard-coded video cards
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 - 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 the FAQ at http://www.tux.org/lkml/
Re: arch/i386/boot rewrite, and all the hard-coded video cards
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. - 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 the FAQ at http://www.tux.org/lkml/
Re: arch/i386/boot rewrite, and all the hard-coded video cards
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 - 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 the FAQ at http://www.tux.org/lkml/
Re: arch/i386/boot rewrite, and all the hard-coded video cards
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 - 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 the FAQ at http://www.tux.org/lkml/
Re: arch/i386/boot rewrite, and all the hard-coded video cards
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 - 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 the FAQ at http://www.tux.org/lkml/
Re: arch/i386/boot rewrite, and all the hard-coded video cards
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. - 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 the FAQ at http://www.tux.org/lkml/
Re: arch/i386/boot rewrite, and all the hard-coded video cards
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. - 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 the FAQ at http://www.tux.org/lkml/
Re: arch/i386/boot rewrite, and all the hard-coded video cards
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. - 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 the FAQ at http://www.tux.org/lkml/
Re: arch/i386/boot rewrite, and all the hard-coded video cards
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. - 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 the FAQ at http://www.tux.org/lkml/
Re: arch/i386/boot rewrite, and all the hard-coded video cards
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 - 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 the FAQ at http://www.tux.org/lkml/
Re: arch/i386/boot rewrite, and all the hard-coded video cards
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 - 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 the FAQ at http://www.tux.org/lkml/
Re: arch/i386/boot rewrite, and all the hard-coded video cards
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 - 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 the FAQ at http://www.tux.org/lkml/
Re: arch/i386/boot rewrite, and all the hard-coded video cards
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. - 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 the FAQ at http://www.tux.org/lkml/
Re: arch/i386/boot rewrite, and all the hard-coded video cards
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 - 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 the FAQ at http://www.tux.org/lkml/
Re: arch/i386/boot rewrite, and all the hard-coded video cards
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. - 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 the FAQ at http://www.tux.org/lkml/
Re: arch/i386/boot rewrite, and all the hard-coded video cards
--- 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 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 - 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 the FAQ at http://www.tux.org/lkml/
Re: arch/i386/boot rewrite, and all the hard-coded video cards
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. ;) - 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 the FAQ at http://www.tux.org/lkml/
Re: arch/i386/boot rewrite, and all the hard-coded video cards
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 body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: arch/i386/boot rewrite, and all the hard-coded video cards
"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 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 - 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 the FAQ at http://www.tux.org/lkml/
Re: arch/i386/boot rewrite, and all the hard-coded video cards
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 - 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 the FAQ at http://www.tux.org/lkml/
Re: arch/i386/boot rewrite, and all the hard-coded video cards
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 - 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 the FAQ at http://www.tux.org/lkml/
Re: arch/i386/boot rewrite, and all the hard-coded video cards
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 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 - 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 the FAQ at http://www.tux.org/lkml/
Re: arch/i386/boot rewrite, and all the hard-coded video cards
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 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 - 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 the FAQ at http://www.tux.org/lkml/
Re: arch/i386/boot rewrite, and all the hard-coded video cards
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 - 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 the FAQ at http://www.tux.org/lkml/
Re: arch/i386/boot rewrite, and all the hard-coded video cards
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 - 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 the FAQ at http://www.tux.org/lkml/
Re: arch/i386/boot rewrite, and all the hard-coded video cards
> 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 message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: arch/i386/boot rewrite, and all the hard-coded video cards
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 - 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 the FAQ at http://www.tux.org/lkml/
Re: arch/i386/boot rewrite, and all the hard-coded video cards
"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, 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 - 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 the FAQ at http://www.tux.org/lkml/
Re: arch/i386/boot rewrite, and all the hard-coded video cards
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 - 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 the FAQ at http://www.tux.org/lkml/
Re: arch/i386/boot rewrite, and all the hard-coded video cards
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 - 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 the FAQ at http://www.tux.org/lkml/
Re: arch/i386/boot rewrite, and all the hard-coded video cards
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 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 the FAQ at http://www.tux.org/lkml/
Re: arch/i386/boot rewrite, and all the hard-coded video cards
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 - 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 the FAQ at http://www.tux.org/lkml/
Re: arch/i386/boot rewrite, and all the hard-coded video cards
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 - 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 the FAQ at http://www.tux.org/lkml/
Re: arch/i386/boot rewrite, and all the hard-coded video cards
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 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 the FAQ at http://www.tux.org/lkml/
Re: arch/i386/boot rewrite, and all the hard-coded video cards
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 - 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 the FAQ at http://www.tux.org/lkml/
Re: arch/i386/boot rewrite, and all the hard-coded video cards
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 - 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 the FAQ at http://www.tux.org/lkml/
Re: arch/i386/boot rewrite, and all the hard-coded video cards
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, 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 - 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 the FAQ at http://www.tux.org/lkml/
Re: arch/i386/boot rewrite, and all the hard-coded video cards
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 - 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 the FAQ at http://www.tux.org/lkml/
Re: arch/i386/boot rewrite, and all the hard-coded video cards
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 message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: arch/i386/boot rewrite, and all the hard-coded video cards
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 - 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 the FAQ at http://www.tux.org/lkml/
Re: arch/i386/boot rewrite, and all the hard-coded video cards
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 - 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 the FAQ at http://www.tux.org/lkml/
Re: arch/i386/boot rewrite, and all the hard-coded video cards
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 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 - 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 the FAQ at http://www.tux.org/lkml/
Re: arch/i386/boot rewrite, and all the hard-coded video cards
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 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 - 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 the FAQ at http://www.tux.org/lkml/
Re: arch/i386/boot rewrite, and all the hard-coded video cards
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 - 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 the FAQ at http://www.tux.org/lkml/
Re: arch/i386/boot rewrite, and all the hard-coded video cards
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 - 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 the FAQ at http://www.tux.org/lkml/
Re: arch/i386/boot rewrite, and all the hard-coded video cards
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 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 - 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 the FAQ at http://www.tux.org/lkml/
Re: arch/i386/boot rewrite, and all the hard-coded video cards
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 body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: arch/i386/boot rewrite, and all the hard-coded video cards
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. ;) - 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 the FAQ at http://www.tux.org/lkml/
