OpenBIOS August 1999

openbios@openbios.org

20 participants
14 discussions

Re: [OpenBIOS] Intel holding back information
by Brian Smith 09 Aug '99

09 Aug '99

Hi all, I am new at bios programming. I have written several asm programs that use int 13 and other bios and dos functions. I am really interested in writting my own bios. I was wondering if anybody had any documentation or instructions on how to get all the code from your bios. I know about the cmos chip, but can you get all the information from cmos or do you have to get it from somewhere else. I know a little about low level functions and port i/o but i need some help. Thanks Brian Smith -----Original Message----- From: David J. Coffin <dcoffin(a)shore.net> To: Niklas Ekström <t97nek(a)student.tdb.uu.se> Cc: openbios(a)elvis.informatik.uni-freiburg.de <openbios(a)elvis.informatik.uni-freiburg.de> Date: Saturday, August 07, 1999 5:06 PM Subject: Re: [OpenBIOS] Intel holding back information >Niklas, > > You cannot get a DRAM-sizing algorithm from Intel with- >out signing an NDA, and the NDA forbids you to share your >source code without Intel's written permission. > > This is necessary to protect Intel's "competitive ad- >vantage", even for a chipset that was discontinued two years >ago. > > VIA Technologies publishes their DRAM-sizing algorithms >without restriction. The VIA 580VP chipset matches the Intel >430FX almost bit-for-bit, so this is a good place to start. > > For an example of actual code, disassemble an Award, >AMI, or Phoenix BIOS. Don't read the BIOS from shadow RAM; >copy it off the chip or find it on the web. The DRAM- and >cache-sizing code are easy to find, because most everything >else is compressed to resemble random noise. > > There is no way for the BIOS writer to conceal Intel's >secrets. DRAM-sizing code must run directly off the flash >chip, so it can never be compressed or encrypted. > > Dave Coffin 8/7/99 > >On Fri, Aug 06, 1999 at 01:16:27AM +0200, Niklas Ekström wrote: >> I have been in contact with Intel about obtaining the BIOS specifications >> for various chipsets (in particular the 430FX which is the chipset of my >> testing environment), but they seem very reluctant to give them away. I >> guess it might depend on that a) you normally have to sign a >> Non-Disclosure Agreement to obtain them (which doesn't go well with the >> fact that I will make the source for the BIOS publicly available) and >> possibly b) that I'm a private person and not a well recogized BIOS >> manufacturing company. >> >> Does anyone have a good suggestion as how to solve this issue? I think >> this is quite a major issue. Even though I think I have a clue on how to >> do most things (detecting memory size and type (FPM/EDO)), I also believe >> there are some things that you would actually need the BIOS specification >> for (atleast so I don't have to _guess_ how to do some things). >> >> I believe some of you here (professional BIOS programmers) have read these >> specifications. Can you give any hint to how much information these >> specifications contain and how vital that information is? Also, is it >> possible to obtain that information for any other source? >> >> / Niklas >> >> - >> To unsubscribe: send mail to majordomo(a)freiburg.linux.de >> with 'unsubscribe openbios' in the body of the message >- >To unsubscribe: send mail to majordomo(a)freiburg.linux.de >with 'unsubscribe openbios' in the body of the message - To unsubscribe: send mail to majordomo(a)freiburg.linux.de with 'unsubscribe openbios' in the body of the message

1 0

Invitation to sign the Petition (by Matthew Sullivan)
by Petition Politik-Digital 06 Aug '99

06 Aug '99

Hello Matthew Sullivan (matthews(a)netscape.com) invites you to sign the petition against SPAM: Please support the anti-spam cause. This is in the interest of you and the net. Please resend the invitation to your friends via the web link. Please visit http://www.politik-digital.de for more information on this issue. You may sign the petition by visiting http://www.politik-digital.de/spam/en/petition/eintrag-2.php3?email=openbio… Vote against SPAM is an initiative of c't Magazin (http://www.heise.de/ct) and politik-digital (http://www.politik-digital.de) - To unsubscribe: send mail to majordomo(a)freiburg.linux.de with 'unsubscribe openbios' in the body of the message

1 0

Re: [OpenBIOS] Intel holding back information
by Ross 06 Aug '99

06 Aug '99

Niklas Ekström: I'm running windows 95 (the latest version), and a C++ 4.5 C compiler and I could not get the source code for the OpenBios off of the Internet. Can you or anyone on this list help obtain the source code? in plain text. Sorry about your troubles with intel I found the best way to get data from is to say that you are going in the future be purchasing 20k of the 430xx chipset and they normally give you what you want. //Ross (HANWE) ---------- : From: Niklas Ekström <t97nek(a)student.tdb.uu.se> : To: openbios(a)elvis.informatik.uni-freiburg.de : Subject: Re: [OpenBIOS] Intel holding back information : Date: Saturday, August 07, 1999 5:06 AM : : On Fri, 6 Aug 1999, Ron Tsur wrote: : > I would not be subscribing to this mailing list if I would not share : > your interest in open source and free OpenBIOS. I don't think that you : > are stupid, but your attitude sucks, because you attack the very people : > that are trying to help you. : : Yes you're right. I've gotten really frustrated talking to braindead : Intel reps (most of them atleast), who just points me in some other : direction. So the last thing I needed to hear was "have you tried : developer.intel.com?". Anyway, I'm sorry about that, it wasn't you I was : barking at. (However, I do ask that people read through the question : before answering it, so they don't answer the wrong question...) : : > If you read my letter carefully, you will see that I offered you some real : > help. I can probably get the documents you need at any time. However, I : > cannot distribute them legally without the owners (Intel) consent. : : Yesterday I got a mail from a guy at my local Intel distributor, where he : explains why Intel didn't give away the specs (atleast what he thinks). He : said that the reason is probably that if Intel gives out the specs, they : also have to give support and because of that they don't want to give it : out to just anyone. But he also said that if I could prove that Intel : would sell more chips (probably >5k/year, the guy said), they would almost : certainly give out the specs. However, I'd says it's highly unlikely that : people (atleast that many) would buy an Intel machine just to run this : BIOS on it... : : Maybe if I can convince them that I, or anyone I give the specs to, will : not require support for it? : : > Now, comes my question. Why do you need Intel's BIOS specs. If you are : > working on a truly OPEN software product, isn't it better to take the : > "cleanroom" approach? : : Ofcourse that is an alternative, but then I would have to get the : information that is available in the BIOS specs from some other place (or : possible reverse engineer or just guess etc) and I feel that it would be : unnessecary difficult, compared to just having all information in one : specification. Ofcourse I wouldn't change my BIOS design because of : something that I read in the BIOS spec. : : > Thanks for listening, : : Thank you for helping! :) : : / Niklas : : - : To unsubscribe: send mail to majordomo(a)freiburg.linux.de : with 'unsubscribe openbios' in the body of the message - To unsubscribe: send mail to majordomo(a)freiburg.linux.de with 'unsubscribe openbios' in the body of the message

1 0

Re: Use of BIOS calls in modern code (Was: Re: [OpenBIOS] Why protected mode?)
by Ed Brinker 02 Aug '99

02 Aug '99

I agree. I do very much agree. A bios built of a minimal ROM based loader and loadable modules would allow the OpenBIOS to support almost any imaginable configuration (even Wintel if you wanted). At 08:05 PM 7/21/99 +0100, you wrote: >On Sat, 17 Jul 1999, Edward Brotsman Dreger wrote: > >> Back to an earlier thread: What development model are we following? >> >> IMHO, I think that the "BIOS" proper should be the bare minimum. All >> other functionality, even some "standard" BIOS functions such as ACPI, >> could be implemented as modules -- even as option ROMs. Since we'll need >> option ROM loader code, anyway, why not reuse it for the "roll-your-own" >> modules? > >If I may delurk to support this view (and repeat some stuff that I put on >the wishlist). > >My interest in openbios is that Sychron is working on cluster software to >make cabinets full of commodity motherboards into clusters (think in terms >of an SP2 or SGI Origin at 10% of the cost). Buying commodity hardware is >easy; OS software exists - make up a Beowulf from the Extreme Linux CD, or >(better yet) buy the stuff we're working on. BUT the available commercial >BIOSes thwart easy installation and management (and hence scaling up). >Until a proper minimal bios is available we have to equip each one with >a graphics card, have a console switch, etc. > >Beowulfs, and the kind of cluster we have planned will use 100 or 1000s of >bios chips per system - so serious production quantities for ROM blowing >are very achieveable (Intel themselves are talking about filling buildings >with Ks of motherboards for the ASP market). I know very little about >BIOSs, processors and motherboards, so much of the list traffic is chinese >to me, but I've been used to the monitor ROMs of e.g. Digital and Sun >systems over the past 10 years. Though they weren't exactly perfect, and >started to bloat, I feel that I've lost the degree of control over my >hardware that I had back then, so I am very encouraged by opinions >expressed here that a minimal bios chip with *optional* extras is the way >to go - if this means that we can... > >- Eliminate the bulky and unneccesary stuff e.g. GUIs >- Control motherboards and monitor status at the BIOS level via e.g. > serial line or USB, so a command line is essential, not merely useful. >- Configure hardware to do *exactly* what we need. >- Easily add our own bios functionality, if that seems useful, without > needing to touch the rest of the BIOS, just like a Linux kernel module. >- Do the above on 1024 nodes en masse. :-) > >The less functions that are blown into ROM, the happier I am, cos that >means they can be pulled from the net (or USB or whatever device seems >appropriate) as required. > >openbios can really make a mark in the compute / server cluster market - >Phoenix / AMI and friends have the desktops sewn up, so I really would >urge the openbios development model towards minimalism in the first >instance and cluster support in the second. I don't wish to deprive anyone >of GUIs or other bells and whistles, I just require them to be optional. >There may be bells and whistle that we'd like, such as APM support for our >UPS of choice, or a heartbeat between systems to provide fast non OS >reliant notification of hardware failure, which are irrelevant for desktop >PCs, and I have no wish to impose them on anyone. I don't want to watch >advertisements as my desktop PC boots, and certainly not when restarting >a cluster node. > >If anyone else is interested in issues relating to BIOSs for servers, >especially for large clusters, please get in touch, on or off this list. > >Peter Lister P.Lister(a)sychron.com PGP (RSA): 0xE4D85541 >Sychron Ltd http://www.sychron.com PGP (DSS): 0xBC1D7258 >1 Cambridge Terrace Voice: +44 1865 200211 >Oxford OX1 1UR UK FAX: +44 1865 249666 > >- >To Unsubscribe: send mail to majordomo(a)freiburg.linux.de >with "unsubscribe openbios" in the body of the message > - To unsubscribe: send mail to majordomo(a)freiburg.linux.de with 'unsubscribe openbios' in the body of the message

1 0