OpenBIOS February 1998

openbios@openbios.org

33 participants
63 discussions

Re: [OpenBIOS] User-extentions (was Re: More comments and a proposal...)

by Ben Pfaff

> Why not? Award BIOS does this, Windows 95 does this. As we participate at > "The right thing to do[tm]" we should be allowed to do so, too. Microsoft does a lot of things the wrong way :) Microsoft flashes the BIOS? Then won't our BIOS, or part of it, get blown away, if we're not careful? I belive someone mentioned that there limits to how many times you can flash most chips. If so, then we definitly don't want to do it every bootup, especially if we are supporting DOS/Windows :) I don't believe that we were going to flash it every bootup, just every time that the user decides to changes his boot settings or whatnot. That should be fewer than 100,000 times, I think, normally. --- OpenBIOS -- http://www.linkscape.net/openbios/ openbios-request(a)linkscape.net Body: un/subscribe Problems? dcinege(a)psychosis.com

23 years, 7 months

Re: [OpenBIOS] User-extentions (was Re: More comments and a proposal...)

by Chris Arguin

On Tue, 24 Feb 1998, Stefan Reinauer wrote: > On Fri, 20 Feb 1998, Chris Arguin wrote: > > > All things considered, you really don't want to flash the BIOS too often, > > and especially not behind the users back, so to speak. As pointed out > > before, we could always reserve a parition on the disk, which would allow > > for extra code and data. This just strikes me as kinda kludgy... > > Why not? Award BIOS does this, Windows 95 does this. As we participate at > "The right thing to do[tm]" we should be allowed to do so, too. Microsoft does a lot of things the wrong way :) > This allows having no disk at all. It could be possible, too, to receive > BIOS settings over the net (or from disk). Maybe this should be made > dependent on whether you have a disk or networking card or not. I think everyone has agreed that this will be modular enough that if you don't like a feature, don't use it. I belive someone mentioned that there limits to how many times you can flash most chips. If so, then we definitly don't want to do it every bootup, especially if we are supporting DOS/Windows :) -- Chris Arguin | "Multiple exclamation marks are a sure sign of a Chris.Arguin(a)unh.edu | diseased mind." - Eric, Terry Pratchett --- OpenBIOS -- http://www.linkscape.net/openbios/ openbios-request(a)linkscape.net Body: un/subscribe Problems? dcinege(a)psychosis.com

23 years, 7 months

Re: [OpenBIOS] Licensing of the code.

by Pavel Machek

Hi! > > > Or did you mean the actual microcode update, as opposed to the code which > > > loads it into the CPU? > > > > I mean the actual microcode update. > > So what is at issue? The only problem I can forsee is getting Intel to > give us the Microcode update, since they are not usually publically > available. Intel has had a Microcode fix to the F00F bug for awhile, but > is only releasing it to specific vendors, many of whom aren't even > bothering to use it. Wouldn't you like to be able to take that F00F kludge > out of Linux? Wrong. F00F workaround is not based on microcode update. And linux already does it :-). Pavel -- I'm really pavel(a)atrey.karlin.mff.cuni.cz. Pavel Look at http://atrey.karlin.mff.cuni.cz/~pavel/ ;-). --- OpenBIOS -- http://www.linkscape.net/openbios/ openbios-request(a)linkscape.net Body: un/subscribe Problems? dcinege(a)psychosis.com

23 years, 7 months

RE: [OpenBIOS] User-extentions

by William A. Arbaugh

On Saturday, February 21, 1998 2:37 PM, Benjamin Scott [SMTP:hawk@ttlc.net] wrote: > >>> Remember that the CMOS settings are stored in the NVRAM, not the > >>> flash. Now the question is how big is the NVRAM? I don't think we > >>> have room for this. > >> > >> Why do these have to be stored in the NVRAM? Can't we reserve 1K or > >> so of flash for this sort of thing? Or can't you erase and replace > >> just a little bit of flash at a time? > > > > All things considered, you really don't want to flash the BIOS too > > often,and especially not behind the users back, so to speak > NVRAM varies from machine to machine some of the chips now have several K available since a number of BIOS' store the ESCD (needed for PnP) info in NVRAM rather than flash. Most of the flash ROMs support up to 100,000 reprogramming cycles. > Flashing the BIOS often would be a Bad Thing. There is a limit to how > often you can write flash ROM. It would take awhile to hit it, but it > is a real limit. Plus, I think you need to erase flash ROM in banks of > a certain size. At least, I've seen plenty of stuff that worked that > way and that way only. > You do need to flash in blocks. The size of the block depends on the chip with the modern chips now having small blocks for storing configuration information, e.g. the Intel 28F001BX-T (128K)has two 4KByte parameter blocks plush a 8KB boot block. The boot block has extra HW protection to prevent accidental reprogramming. This is how the Intel boards prevent you from completely trashing your bios by mistake and ruining the motherboard (since the flash chips are not removable on Intel boards). > If we're going to store boot configuration info on disk, we might as > well just go back to using LILO. I want something that can boot your > selected OS without the need of loading from the disk. > So do Microsoft and Intel. This is why they've put together the NetPC spec, and why there is etherboot and netboot now available for Linux. You can burn/flash a ROM today that you can put in your ethernet card's ROM socket and do a net boot with out every touching your hard disk. Take a look at http://www.slug.au/etherboot. Bill --- OpenBIOS -- http://www.linkscape.net/openbios/ openbios-request(a)linkscape.net Body: un/subscribe Problems? dcinege(a)psychosis.com

23 years, 7 months

Re: [OpenBIOS] BIOS extensions are pointless (was: More comments...)

by Alexander Viro

On Sun, 22 Feb 1998, Benjamin Scott wrote: > Pascal Dornier wrote: > > 1. DOS translates logical block address into Cylinder / Head / Sector > > based on BIOS parameters. This is constrained by the 10 bit limit > > on cylinder and 6 bit on sector number (and sector numbers start > > at 1, which further mucks things up). > > I never really thought about it, but yeah, I guess DOS's sector > numbers are a form of LBA, aren't they? Is the LBA DOS uses the same as > the LBA used by IDE? How could it be, given that DOS does start sector > numbers at 1. Does the BIOS provide an INT13 extension/alternative that > supports LBA directly? I've never looked at this stuff this closely > before. Pointers to info are also welcome. :) No, they aren't. DOS sectors are linear within the partition. And that's it. It uses damned amount of layers: linear in the partition -[int25/26]->3D-[BIOS Int13]-->3D----[IDE,EIDE] \->linear[EIDE,SCSI] For Linux: linear -[driver]-->3D----[IDE] \->linear[EIDE,SCSI] Moreover, BIOS in LBA mode means the following: translate DOS 3D into linear and use another set of hardware commands. Interface DOS/BIOS remains the same. > > > 2. The BIOS translates this either into another CHS > > What I don't understand is: If DOS and Linux coexisting on the same > system, and you have BIOS geometry translation on to support DOS, Linux > still works. But Linux doesn't use the BIOS. So how does that work? It uses either linear addresses or native drive CHS. All point of BIOS translation is to map CHS addresses provided by DOS into the real addresses. > Does Linux do the remapping instead of the BIOS? There must be a What should it remap? Who will feed CHS addresses to Linux driver? For Linux the disk is a 1-dimensional array of sectors. For DOS it's 3-dimensional one. Both are _ordered_. And there is a real disk geometry. It's also an ordered sequence of sectors. These orderings should be the same. Everything else is irrelevant. Driver (or BIOS, in DOS case) should get a position in array (1D for Linux, 3D for DOS) and transform it into the disk's one. And vice versa. All (E)IDE disks can be addressed as 3D arrays _and_ there is a command that makes disk to say you its dimensions. New disks can be addressed as 1D arrays. Now, for DOS we need to choose some dimensions suitable for DOS (Cyl<=1024, i.e.) and make a correspondence between DOS 3D coordinates and disk 3D or 1D. The only tricky part is choosing the dimensions for DOS, for correspondence should preserve the order and disk dimensions are known. That's the work of BIOS translation. For Linux we have to make either correspondence between 1D and 1D [preserving the order!], or correspondence between 1D and 3D with known dimensions [preserving the order, again]. If we know that the order is the same for DOS and Linux we can forget (in Linux) about DOS internal pecularities. And thus forget about BIOS translation. > standard method of geometry translation if that is the case (there > prolly is, I just never dug that far). > > > The only right thing to do is put up with this nonsense during boot, then use LBA mode. > > Or possibly, one of the things we can do in this project is implement > a new interface for the disk I/O, for use with advanced OSes and/or > bootloaders, which supports LBA directly, cleaning things up > considerably. Oh, sure, it would break some things horribly, but that's > why it would be an option. Hmm. Then you can take Linux IDE driver and put it into BIOS. Yep, it will break some things. DOS, for example. And Virus95, for it is loaded by BIOS drivers. And LILO (well, _that_ is not a problem for we have the source, but DOS & Virus...). NT will survive, for it uses its own loader. And consider the fact that BIOS access is _slow_. So Linux will still use its own driver (in regular RAM) for speed reasons. The only thing that will gain something would be LILO (rewritten, i.e.). > > We might even be able to implement a better partition table format > (like the BSD format). The MS partition table format is absolutely > horrid at times. Not a BIOS problem. For BIOS partitions don't exist. They are just linear chunks of disk. It's determined by OS. Even in case of DOS it is so (in MSDOS.SYS, as far as I remember). Oh, and boot loader have some reduced knowledge of these matters. Then it's a question of master boot loader. Al > > I know, I know, why reinvent the wheel. Because we can, dang it, > that's why! :-) > > -- Ben <hawk(a)ttlc.net> > > > --- > OpenBIOS -- http://www.linkscape.net/openbios/ > openbios-request(a)linkscape.net Body: un/subscribe > Problems? dcinege(a)psychosis.com > > --- OpenBIOS -- http://www.linkscape.net/openbios/ openbios-request(a)linkscape.net Body: un/subscribe Problems? dcinege(a)psychosis.com

23 years, 7 months

Re: [OpenBIOS] BIOS extensions are pointless (was: More comments...)

by Pascal Dornier

From: Benjamin Scott <hawk(a)ttlc.net> To: openbios(a)linkscape.net <openbios(a)linkscape.net> Date: Sunday, February 22, 1998 6:03 Subject: Re: [OpenBIOS] BIOS extensions are pointless (was: More comments...) > I think it might be better to say that re-implementing things like >INT13 in protected-mode would be pointless. The few things that modern >OSes actually do *use* the BIOS for are definate canidates for >improvement and possible protected-mode reimplementation. However, >"BIOS32" implies it may be protected-mode already. Anyone know more >about this? Yes, 32 bit protected mode. See the PCI BIOS spec. > While I do agree in theory, memory space limitations may force us to >link the BIOS together before programming the flash. Which isn't really >a big deal. If you own all the sources, you can save yourself the complexity of linking. I don't even use a object linker, my assembler is fast enough to assemble the whole BIOS in about 60 ms. > Actually, to the list in general: Does anyone know exactly *where and >how* geometry translation occurs? I've been thinking it must occur in >the motherboard BIOS for onboard EIDE controllers. But we already know >many OSes bypass the BIOS. I was assuming they were still talking to >the EIDE controller through the BIOS, just via a different route. Is >that correct? Or is geometry translation implemented in the EIDE >controller chipset itself? Or something else? There are multiple levels of geometry translation. It's a classic example of Winchester Mystery House software design. Read it and weep. 1. DOS translates logical block address into Cylinder / Head / Sector based on BIOS parameters. This is constrained by the 10 bit limit on cylinder and 6 bit on sector number (and sector numbers start at 1, which further mucks things up). 2. The BIOS translates this either into another CHS (the drive can only handle 4 bits for the head number, but 16 bits for the cylinder number, and 8 bits for the sector). Alternatively, the CHS value is converted into a logical block address. 3. The drive translates the CHS into a logical block number, then converts that into the real CHS values (which is not a straight division as the number of sectors per track varies). The only right thing to do is put up with this nonsense during boot, then use LBA mode. -------------------------------------------------------------------- Pascal Dornier pdornier(a)pcengines.com http://www.pcengines.com Your Spec + PC Engines = Custom Embedded PC Hardware -------------------------------------------------------------------- --- OpenBIOS -- http://www.linkscape.net/openbios/ openbios-request(a)linkscape.net Body: un/subscribe Problems? dcinege(a)psychosis.com

23 years, 7 months

Re: [OpenBIOS] BIOS extensions are pointless (was: More comments...)

by Benjamin Scott

WA = William A. Arbaugh <waa(a)dsl.cis.upenn.edu> WA> Not true actually, Linux does use some bios32 functions for PCI WA> support. My guess is that they'll still need some BIOS level support WA> for PnP, Power management, and not to mention DPMI etc. You're right of course. I had forgotten about the PnP stuff entirely. I'm not sure how DPMI works, but it's a fair bet it needs BIOS support, too. I think it might be better to say that re-implementing things like INT13 in protected-mode would be pointless. The few things that modern OSes actually do *use* the BIOS for are definate canidates for improvement and possible protected-mode reimplementation. However, "BIOS32" implies it may be protected-mode already. Anyone know more about this? DW = David Woodhouse <Dave(a)imladris.demon.co.uk> CA = Chris Arguin <Chris.Arguin(a)unh.edu> DW> Regarding the module support: DW> We can either link them at flash time, or have the BIOS search through DW> the available modules when it boots. I prefer the latter, While I do agree in theory, memory space limitations may force us to link the BIOS together before programming the flash. Which isn't really a big deal. DW>> Other than that, I don't see any point in extra protected-mode DW>> functionality - as you rightly say, anything running in protected mode DW>> is going to have its own drivers already. CA> Not to be too purest... but is that the "Right Way"? The BIOS is CA> *supposed* to abstract that away. It doesn't. Maybe it should... Originally, yes, the IBM-PC BIOS was a hardware abstraction layer. Rather then, say, having disk device drivers, you called INT13 and got support that way. Now, the original IBM-PC platform has been extended so much about the only thing *left* is the original BIOS service code, like INT13. One might argue we should "fix" that, that we should put all that hardware abstraction back in. Other platforms (the Mac comes to mind) accomplish this very well. A standard hardware abstraction API has obvious advantages. However, it is typcially accomplished by providing a low-level API in firmware to which devices talk to. Each device implements the support for this API. Due to the open nature of the IBM-PC platform, this is obviously not going to happen. The only other way to do it would be to write device drivers for each and every device on the system, incorporate them into firmware, and let the OS call our new hardware abstraction API. Besides the fact that this would be totally redundent, I don't know that we have the flash ROM space to accomplish this. Even more important, I don't think it *would* be the Right Thing to do. The IBM-PC mindset has become such that device abstraction occurs at the OS level. This allows greater flexability and faster development, something that has kept the IBM-PC line going where others have failed. Software is easier to change then firmware. I don't really think that we should try to go back to the "old way" of doing things, despite the advantages. If you really want hardware abstraction in firmware, buy a Mac. <grin> CA> On a related note, I just bought a 8 Gig SCSI disk. CA> Due to limitations of my SCSI controller, [snip] CA> I now have an 8GB Linux Disk. That is not a bad thing, but it wasn't CA> what I was intending. So there is another bug for us to fix :) I don't know that we can. Geometry translation for SCSI would be handled by your SCSI controller and its BIOS, not the motherboard BIOS (which would only control EIDE gemometry translation). Actually, to the list in general: Does anyone know exactly *where and how* geometry translation occurs? I've been thinking it must occur in the motherboard BIOS for onboard EIDE controllers. But we already know many OSes bypass the BIOS. I was assuming they were still talking to the EIDE controller through the BIOS, just via a different route. Is that correct? Or is geometry translation implemented in the EIDE controller chipset itself? Or something else? -- Ben <hawk(a)ttlc.net> --- OpenBIOS -- http://www.linkscape.net/openbios/ openbios-request(a)linkscape.net Body: un/subscribe Problems? dcinege(a)psychosis.com

23 years, 7 months

Re: [OpenBIOS] BIOS extensions are pointless (was: More comments...)

by David Woodhouse

hawk(a)ttlc.net said: > > Could someone please tell me where protected-mode code will be > useful in the BIOS firmware? Initial memory and other hardware checks, and then some of the INT 15h functions for copying memory around above 1Mb. Oh, and of course the BIOS function to switch into protected-mode :) Also PCI and APM BIOS32 functions. Other than that, I don't see any point in extra protected-mode functionality - as you rightly say, anything running in protected mode is going to have its own drivers already. > I believe the single most important goal of this effort should be > modular design. If we make the design modular, most everyone can be > happy. Agreed. Most of the things we've been talking about recently have been proposed extensions which would be separate modules, so those who don't see the point don't have to use them. We have very little dispute about the core of the project, other than the fact that we're not entirely happy about LPGL but it seems to be the best option so far suggested. Regarding the module support: We can either link them at flash time, or have the BIOS search through the available modules when it boots. I prefer the latter, because it doesn't involve any intelligence on the part of the linker, and the extra headers required won't take up a significant amount of space Each module object needs a header, much like the existing BIOS extensions have. In it we need to store: length, checksum, entry point. We could also do with a flag indicating the invokation order, and whether it needs to remain in memory when it's done (for when we've uncompressed into RAM). For example, a chipset optimisation module would be loaded early, and not remain in memory. An IDE disk driver providing INT 13h functions could be loaded later, and will remain in memory. A boot loader will be loaded last. The power-up vector will point to a routine which does an inventory of the available modules, and invokes them in the correct order, uncompressing them from flash into RAM as required. This boot loader will provide certain basic functions for reading data from the CMOS and other things that a number of other modules will require. ---- ---- ---- David Woodhouse, Robinson College, CB3 9AN, England. (+44) 0976 658355 Dave(a)imladris.demon.co.uk http://dwmw2.robinson.cam.ac.uk finger pgp(a)dwmw2.robinson.cam.ac.uk for PGP key. --- OpenBIOS -- http://www.linkscape.net/openbios/ openbios-request(a)linkscape.net Body: un/subscribe Problems? dcinege(a)psychosis.com

23 years, 7 months

Re: [OpenBIOS] More comments and a proposal for priorities

by John Labovitz

Markus Kaufmann <kaufmann(a)pks-software.de> said: > A BIOS isn't something that you change daily like the newest > developer kernel. Once you have a perfect BIOS, you should never > change it. to interject a philosophical point here: this is why we're doing an *open* BIOS project -- to rid ourselves of the accepted myth that Thou Shalt Never Change The BIOS (unless the manufacturer tells you to, via an upgrade). yes, we should make it clear that BIOS changes are dangerous and could result in a nonbooting system, but that doesn't mean that someone who got some fancy new file system, device, etc., shouldn't be able to boot directly off it once the BIOS extension is available and installed. however, i do agree with the general point of not cluttering up the new BIOS (and our time devoted to this project) with too many features; things like grub-in-bios should definitely be considered options that are worked on in parallel or sequential to the core code, and compiled/linked in optionally by the user or distribution. john --- OpenBIOS -- http://www.linkscape.net/openbios/ openbios-request(a)linkscape.net Body: un/subscribe Problems? dcinege(a)psychosis.com

23 years, 7 months

Re: [OpenBIOS] More comments and a proposal for priorities

by Markus Kaufmann

Hi, At 17:05 20.02.98 +0530, Arjun Roychowdhury wrote: >I feel that while writing a BIOS, we must provide a small set >of very poweful operations instead of bloatingt the BIOS to include >one & all. I am strongly for adding prot-mode code, but only when >necessary. wheras prot. mode code will add extra bytes in size, >the advantages are obvious. However, IMHO, one should not just >rewrite the entire BIOS using prot. mode. Real mode code does >have its advantages, esp. in areas where mem. consumption is >not so critical. The real mode vs. prot. mode: If you want to support DOS, you have to rewrite the normal BIOS in real mode. Any protected mode extensions can't use these functions and have to reimplement them. If you wan't to boot from protected mode, you need your own SCSI-drivers, small VGA-Drivers and so on. Bye Markus Kaufmann --- OpenBIOS -- http://www.linkscape.net/openbios/ openbios-request(a)linkscape.net Body: un/subscribe Problems? dcinege(a)psychosis.com

23 years, 7 months