OpenBIOS August 1999

openbios@openbios.org

20 participants
14 discussions

RE: [OpenBIOS] Proposals for development stages

by Wim Vervoorn

Isn't that available at www.dmtf.org ? Best regards, Wim Vervoorn Development Manager Eltan B.V. Het Schild 13 5275 EB Den Dungen The Netherlands Tel. 073-5944664 Fax. 073-5941187 E-mail. Wvervoorn(a)eltan.com -----Original Message----- From: Ross [SMTP:rossio@hoeftd.reno.nv.us] Sent: Friday, August 13, 1999 11:57 PM To: openbios(a)elvis.informatik.uni-freiburg.de Subject: Re: [OpenBIOS] Proposals for development stages Does, anyone out their know how to get the DMI 2.0 spec. //Ross ---------- > From: James Oakley <jfunk(a)roadrunner.nf.net> > To: openbios(a)elvis.informatik.uni-freiburg.de > Subject: Re: [OpenBIOS] Proposals for development stages > Date: Friday, August 13, 1999 3:29 AM > > "Joseph D. Foley" wrote: > > > The linux kernel guys are sometimes a fussy bunch; such a spec already > > exists, take a look at MultiBoot standard at > > http://www.uruk.org/~erich/grub/boot-proposal.html, but I don't believe > > they've adopted it yet. > > Didn't know it existed. It's interesting reading, but too narrow. > > What we want to know is what BIOS calls the kernel uses and then hash > out new ways of achieving what is needed. APM is one example, there's > also memory reporting, hard disk parameter passing (LILO isn't > infallible on large drives), USB, PCI, etc. > > It won't be an easy task, unfortunately. I think we can come up with > something though. > > James Oakley > - > 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

21 years, 5 months

Re: [OpenBIOS] Intel holding back information

by Timothy J. Massey

On Sun, 8 Aug 1999 20:02:20 -0400, David J. Coffin wrote: >On Sun, Aug 08, 1999 at 05:35:25PM -0230, James Oakley wrote: >> "Timothy J. Massey" wrote: >> >> > Even if your BIOS bears no resemblance to the one you disassembled, because >> > you *did* disassemble it, the makers of the BIOS you disassembled can say to >> > you, "But you saw our code and did it yourself. That's illegal." And >> > they'd be right. > > Reverse engineering is very legal in Sweden, although it >may soon be illegal in the USA. There wouldn't *be* any BIOS >industry today if Phoenix hadn't reverse-engineered IBM's code. > > So Phoenix, which now owns Award, is going to prosecute >some college student in Sweden for doing exactly what they did. >Not likely. No, they would prosecute some college student in Sweden for breaking the law. Phoenix was **VERY** careful in how they reverse-engineered IBM's BIOS. There were two teams. Team one disassembled the IBM code and wrote a detailed english-language description of what IBM did: This function when called this way does this. No code was contained in this description. Team two had **NEVER** (not once, not ever) in any way disassembled any BIOS code ever, had never seen IBM's code ever, etc. They took that english-language description and wrote their own code. Even if there were parts of the code that were exactly identical, it wouldn't have mattered, because they came up with them on their own. That's why it's called "clean room" development. The guys that have never seen the code they're trying to copy are in a clean room: free from suspicion. *That* is perfectly legal. But once having seen copyrighted code, you **cannot** write code that does the same thing without opening the possiblity of lawsuit. I'm not saying that they'd win, but there is the possibility of a lawsuit. And if **any** similarity was found (even if it were coincidental), you would lose. >> This is very true. A couple of years back, some guys who worked for >> Matrox quit and started their own video chipset company. Matrox >> successfully blocked their entry into the market because they saw >> proprietary Matrox engineering information. > > Not the same thing. Those engineers had to sign stacks of >non-disclosure and non-competition agreements before they could >see Matrox's designs. They clearly violated those contracts. Even if they hadn't, they would still have been in the wrong. If I'm an engine designer for Ford and leave to start my own engine-designing company, Ford would have every right to go over my designs with a fine-tooth comb. And if something even coincidentally looked the same, I would be in big trouble. That doesn't mean that I couldn't leave Ford and start my company. Look at Lee Iacocca (sp?), or John DeLorean. But it opens the *possibility* of attacks. > Niklaus would be taking a bigger risk if he signed Intel's >NDA. Right now, he has no legal obligation to protect anyone's >secrets. And once Niklaus signed Intel's NDA, he would be UNABLE to contribute to OpenBIOS. Ever. > If a disgruntled chemist at Coca-Cola gave you their secret >formula, he would be in deep trouble. But no one could stop you >from selling cola drink (you couldn't *call* it "Coca-Cola", of >course), or posting the formula on the web. Yes they could. If I were given the text of a book from a disgruntled publishing employee, and I put it on my website, could I be prosecuted? Not until I was told of the copyright violation. But once I was told, that's it. I am open to prosecution. And, if I were found publishing a manuscript that was given to me, and it was found that the manuscript was not owned by the person who gave it to me (just as if I were given the secret Coke formula by an unauthorized person), I would be in big trouble. Ignorance of the law is no excuse: it's still illegal. So, all of the actions that you describe are quite illegal. Duplication of copyrighted material is a crime. Period. And once you've seen copyrighted material, copying that material (even if it's by rewriting it yourself from your understanding of that material) in any way opens you up to possible prosecution as well. Tim Massey - To unsubscribe: send mail to majordomo(a)freiburg.linux.de with 'unsubscribe openbios' in the body of the message

21 years, 5 months

Re: [OpenBIOS] Proposals for development stages

by Ross

Does, anyone out their know how to get the DMI 2.0 spec. //Ross ---------- > From: James Oakley <jfunk(a)roadrunner.nf.net> > To: openbios(a)elvis.informatik.uni-freiburg.de > Subject: Re: [OpenBIOS] Proposals for development stages > Date: Friday, August 13, 1999 3:29 AM > > "Joseph D. Foley" wrote: > > > The linux kernel guys are sometimes a fussy bunch; such a spec already > > exists, take a look at MultiBoot standard at > > http://www.uruk.org/~erich/grub/boot-proposal.html, but I don't believe > > they've adopted it yet. > > Didn't know it existed. It's interesting reading, but too narrow. > > What we want to know is what BIOS calls the kernel uses and then hash > out new ways of achieving what is needed. APM is one example, there's > also memory reporting, hard disk parameter passing (LILO isn't > infallible on large drives), USB, PCI, etc. > > It won't be an easy task, unfortunately. I think we can come up with > something though. > > James Oakley > - > 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

21 years, 5 months

Re: [OpenBIOS] (was) Intel holding back information: Maybe we should move on...

by Timothy J. Massey

On Mon, 09 Aug 1999 19:17:36 -0230, James Oakley wrote: >Therefore, I agree with Ron. We should build a specification from >scratch with reference to Linux. Then we get the Linux kernel to support >us. Then we can add features such as APM, improved user setup, >comprehensive hardware enumeration, and, of course, loading >DOS/Win/OS/2. As much as I hate to say it, this is probably the best way to go. This will put the OpenBIOS into a totally PC-BIOS-uncompatible track. That makes OpenBIOS just about useless to me personally in the short-term (an OS/2 and WinNT user), but it assures a path that won't get OpenBIOS in trouble with the law... Tim Massey - To unsubscribe: send mail to majordomo(a)freiburg.linux.de with 'unsubscribe openbios' in the body of the message

21 years, 5 months

Re: [OpenBIOS] Intel holding back information

by Timothy J. Massey

On Sun, 8 Aug 1999 12:59:29 +0200 (MET DST), Niklas Ekstr�m wrote: >I have been thinking about doing that, but wouldn't that make me unable to >write the bios after that (legally that is) ? You got it. If you **EVER** in your entire LIFE disassemble a BIOS, you are then unable to program a similar BIOS without being open to a legal challenge. Even if your BIOS bears no resemblance to the one you disassembled, because you *did* disassemble it, the makers of the BIOS you disassembled can say to you, "But you saw our code and did it yourself. That's illegal." And they'd be right. Tim Massey - To unsubscribe: send mail to majordomo(a)freiburg.linux.de with 'unsubscribe openbios' in the body of the message

21 years, 5 months

Re: [OpenBIOS] Intel holding back information

by Timothy J. Massey

On Sun, 08 Aug 1999 22:38:23 -0400, Ed Brinker wrote: <description of clean room techniques snipped> >How might we implement such an approach. It would probably require two >separate mail lists. One for the group to reverse engineer the other BIOS >and a second for the group creating the new BIOS. The could be no >communication between the two groups about the BIOS's other than the >"identified functions." Now here's the catch: how do you prove a negative, that the clean room group did not indeed disassemble a BIOS, did not sneak a look at that other mailing list, etc? If you're going to do a clean room technique, you need that strictly enforced. That means being able to control **EVERY** last action of both the clean and dirty room people. The information generated by the dirty room group and the actions of the clean room group need to be strictly controlled. You need to say that there is **ABSOLUTELY** no way that the clean room people could have gotten information from the dirty room group. That means monitoring all means of communication. In our day and age, on an OpenSource project, that is not going to happen. A single e-mail from the dirty group to the clean group ruins the entire effort. We don't exactly have the resources to sequester the two groups, now do we? Compaq and Phoenix did. >The first group could make no comments about the work in progress of the >second group as that could be intrepreted as providing "guidance." The >second group >could not ask if the function was really necessary as that would be >intrepreted as asking for "guidance." > >If we are to take this route, then perhaps it is best we split soon to >avoid the process of legal "contamination." Again, it just can't happen. There are too many ways for the arrangement to be broken, and even if every member of each team did in no way break the barrier, how could it be **PROVED** that they didn't? Again, proving a negative. You need a *tremendous* amount of evidence to do this... Tim Massey - To unsubscribe: send mail to majordomo(a)freiburg.linux.de with 'unsubscribe openbios' in the body of the message

21 years, 5 months

Re: [OpenBIOS] Intel holding back information

by Timothy J. Massey

On Sun, 8 Aug 1999 21:12:00 -0700, William Meyer wrote: >> And I have a feeling that because of this a project like OpenBIOS is >doomed. >> The best coders are the ones that have "seen too much"... :( > >False again. Phoenix had experienced coders, very experienced coders -- none >of whom had touched a PC. Yes, but that was 1982. In 1999, how many experienced coders haven't touched a PC? Tim Massey - To unsubscribe: send mail to majordomo(a)freiburg.linux.de with 'unsubscribe openbios' in the body of the message

21 years, 5 months

Re: [OpenBIOS] Intel holding back information

by Timothy J. Massey

On Sun, 8 Aug 1999 20:23:36 -0700, William Meyer wrote: >> How might we implement such an approach. It would probably require two >> separate mail lists. One for the group to reverse engineer the other BIOS >> and a second for the group creating the new BIOS. The could be no >> communication between the two groups about the BIOS's other than the >> "identified functions." > >It would require a rigid protocol. E-mail is not likely to be an acceptable >record of communications. Rigorous note keeping using traditionally accepted >methods would be essential. Those participating in coding would have to be >able to swear out affidavits attesting to their complete prior ignorance of >BIOS coding. > >There are paper notebooks which serve well for documenting developments >which are potentially of legal importance. One supplier is the Laboratory >Notebook Company. The notebooks are stitched, the pages are gridded and >numbered, and each page provides space for the author and a witness to sign >and date. I've used these on projects for over 20 years, and they are >generally adopted as a standard in companies where patentability is a >consideration. They should be equally useful in documenting freedom from >infringing practices. We used these exclusively in Chemistry class. With these, pages couldn't be ripped out, moved, changed, etc. The problem is, what prevents me from e-mailing what I remember to the other side? Nothing. In addition to proving what actually happened (the clean room procedures), you need to prove that what didn't happen didn't happen. Without extremely tight control (a level that is impossible for a distributed group like us), it can't be done. >True enough, but the split can't be based merely on people's preferences. >Coders have to be free from any prior knowledge of BIOS source code. Many >won't like this, but there is no other way I am aware of to keep the group >legally untainted. And I have a feeling that because of this a project like OpenBIOS is doomed. The best coders are the ones that have "seen too much"... :( Tim Massey - To unsubscribe: send mail to majordomo(a)freiburg.linux.de with 'unsubscribe openbios' in the body of the message

21 years, 5 months

What OpenBIOS should contain

by s.jacobson＠xtra.co.nz

Hello all, I see it's been busy, even if not on track ;). The basic requirements that I would have from a BIOS are as follows: 1) The ability to chainload to another bootloader ( the most basic function ), after enough hardware setup (a little RAM testing etc). The state of the processor on hand over should be a runtime option (ie protected or real mode). No dabling with V86 mode. There really isn't any need, and it gets ugly quickly. 2) A nice simple (though powerful) built in bootloader. Something like grub mainly 'cause it's got a command line which is REALLY USEFUL when you've got a system you couldn't boot otherwise. 3) The ability to boot from many media (network, cd, floppy, ide etc). Network booting would be nice but the network card support may be a bit cumbersome. 4) Some cool utilities like a nice format for common filesystem types (FAT, VFAT, ext2 etc). I think we should look to Linux for the filesystem drivers. Sam. - To Unsubscribe: send mail to majordomo(a)freiburg.linux.de with "unsubscribe openbios" in the body of the message

21 years, 5 months

Re: [OpenBIOS] Intel holding back information

by Brian Smith

Hi all, Can anybody let me know what compiler to buy that is good for asm and c++. -----Original Message----- From: Ross <rossio(a)hoeftd.reno.nv.us> To: openbios(a)elvis.informatik.uni-freiburg.de <openbios(a)elvis.informatik.uni-freiburg.de> Date: Saturday, August 07, 1999 8:27 AM Subject: Re: [OpenBIOS] Intel holding back information >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 - To unsubscribe: send mail to majordomo(a)freiburg.linux.de with 'unsubscribe openbios' in the body of the message

21 years, 5 months