OpenBIOS

openbios@openbios.org

4297 discussions

BOUNCE openbios@freiburg.linux.de: Admin request: /^subject:\s*help\b/i
by owner-openbios＠elvis.informatik.uni-freiburg.de 11 Sep '99

11 Sep '99

>From stepan(a)wesley.informatik.uni-freiburg.de Sat Sep 11 11:11:47 1999 Received: from avalon.informatik.uni-freiburg.de (root(a)avalon.informatik.uni-freiburg.de [132.230.150.1]) by wesley.informatik.uni-freiburg.de (8.8.8/8.8.8) with ESMTP id LAA30414 for <openbios(a)elvis.informatik.uni-freiburg.de>; Sat, 11 Sep 1999 11:11:46 +0200 Received: from mailgateway1.uni-freiburg.de (mailgateway1.uni-freiburg.de [132.230.1.6]) by avalon.informatik.uni-freiburg.de (8.9.0/8.9.0) with SMTP id KAA13059 for <openbios(a)elvis.informatik.uni-freiburg.de>; Sat, 11 Sep 1999 10:53:24 +0200 (MET DST) Received: from dns.ele.uva.es [157.88.111.190] (root) by mailgateway1.uni-freiburg.de with esmtp (Exim 1.82 #3) id 11PiuR-00066k-00; Sat, 11 Sep 1999 10:53:23 +0200 Received: from wopr (jesus(a)wopr.ele.uva.es [157.88.111.53]) by dns.ele.uva.es (8.9.3/8.8.8) with SMTP id KAA20250 for <openbios(a)freiburg.linux.de>; Sat, 11 Sep 1999 10:53:02 +0200 From: Jesus Arias <jesus(a)ele.uva.es> Reply-To: jesus(a)ele.uva.es To: openbios(a)elvis.informatik.uni-freiburg.de Subject: Help finding chipset info Date: Sat, 11 Sep 1999 08:33:28 +0000 X-Mailer: KMail [version 0.7.9] Content-Type: text/plain MIME-Version: 1.0 Message-Id: <99091108522700.00362@wopr> X-MIME-Autoconverted: from 8bit to quoted-printable by dns.ele.uva.es id KAA20250 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by wesley.informatik.uni-freiburg.de id LAA30415 Hi, I've got an old 386 board that i think is well suited for some embedded apps. But the BIOS don't boot without keyboard or video card. Anyway, the 64 Kb of the BIOS are better intended for other use, so i'm planning to replace the BIOS chip to other with my application inside. The problem is the initialitation of the chipset. The only unknown chip is marked as "M1217", and it's the main chipset of the beast, so i'm searching some info about it, like Manufacturer, Datasheet, etc. Other motherboard chips are: (for ease of identification) CPU: AMD 386SX (33 MHz) NPU: IIT 387 Keyboard Controller: Intel/AMI CMOS: M5818 (same Manufacturer? 146818 clone?) BIOS: 27c512 (64Kb) AMI BIOS RAM: four 1Mb 30 pin SIMMs a few TTL/CMOS standart IC's. Any help is wellcome. Best regards ------------------------------------------------------------------------------ Jesús Arias Alvarez Dpto. de Electricidad y Electrónica. Univ. Valladolid. SPAIN E-mail: jesus(a)ele.uva.es Please don't send me Microsoft Virus^H^H^H^H^HWord documents ------------------------------------------------------------------------------

1 0

RE: [OpenBIOS] Proposals for development stages
by Wim Vervoorn 16 Aug '99

16 Aug '99

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

1 0

Re: [OpenBIOS] Intel holding back information
by Timothy J. Massey 13 Aug '99

13 Aug '99

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

6 6

Re: [OpenBIOS] Proposals for development stages
by Ross 13 Aug '99

13 Aug '99

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

1 0

Re: [OpenBIOS] (was) Intel holding back information: Maybe we should move on...
by Timothy J. Massey 09 Aug '99

09 Aug '99

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

1 0

Re: [OpenBIOS] Intel holding back information
by Timothy J. Massey 09 Aug '99

09 Aug '99

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

11 12

Re: [OpenBIOS] Intel holding back information
by Timothy J. Massey 09 Aug '99

09 Aug '99

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

3 2

Re: [OpenBIOS] Intel holding back information
by Timothy J. Massey 09 Aug '99

09 Aug '99

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

1 0

Re: [OpenBIOS] Intel holding back information
by Timothy J. Massey 08 Aug '99

08 Aug '99

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

3 2

What OpenBIOS should contain
by s.jacobson＠xtra.co.nz 08 Aug '99

08 Aug '99

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

10 17

Jump to page: