November 1998 - OpenBIOS - mail.coreboot.org

Chipset autodetect -- pro and con
by M Carling Jan. 12, 1999

Jan. 12, 1999

There seems to be some disagreement over the issue of whether or not OpenBIOS should provide for possibility to compile into a single binary support for multiple chipset types to be autodetected at run-time. For OpenBIOS to be successful, it needs to become more attractive to the MB manufacturers than the alternatives. I don't know whether such a feature would be attractive to the MB manufacturers or not. I suggest will begin by compiling a list of the advantages and disadvantages of this feature. Having done that (so that we understand it ourselves as best we can) we should then ask the manufacturers. (This will be a good step toward getting free hardware from them for development.) When we ask them, we should also ask any other questions about their needs. In effect, we need to do some market research. Here are the advantages and disadvantages that I can think of. There are probably others. Pro: It's cool. It would allow manufacturers to have one BIOS ROM that supports all their MB products. The autodetect code might also be useful for diagnostics. Con: Extra complexity--something else to go wrong. Bug free code is *really* important in the BIOS. Extra complexity--more difficult to test. What other questions would we like the MB manufacturers to answer for us? M

7 7

Re: Interrupts needed by LILO
by M Carling Dec. 12, 1998

Dec. 12, 1998

> I thought, a main topic for OpenBIOS development is full access to the > hard drives so there is no trouble with large disks, large partitions and > kernels laying somewhere on them. Perhaps I'm confused. Shouldn't OpenBIOS be able implement the functionality of LILO? I thought that LILO existed because BIOS16 are incapable of loading anything that isn't DOS-like. Doesn't LILO look to the BIOS like DOS? In other words, when a BIOS is loading LILO, doesn't it "think" it's loading DOS? > I thought, a main topic for OpenBIOS development is full access to the > hard drives so there is no trouble with large disks, large partitions and > kernels laying somewhere on them. That sounds right. So why have a new LILO? Why not just not need LILO anymore? M

3 4

Re: Chipset autodetect -- pro and con
by Matthew Sullivan Nov. 30, 1998

Nov. 30, 1998

Hiya all My two pennies worth...<G> Asbjoernsen(a)atntr.telemax.no wrote: > > Too Big. Each chipset got it's own data and specs (don't forget we're > > talking about 386, 486, LX, BX, VX, FX chipset and they got lots of > > differences) - combining them all together will give a binary file that > > will probably won't fit into the flash (not mentioning other features we > > want to have). > We aren't talking about compiling in support for all and every supported > chipsets, just making it configurable, so one could add support for more > chipsets in one binary, of course limited by size. This would for instance be > nice for admins having a large pool of computers with two different > motherboards. Compile time config on chipset support will be the answer.. I have an FX so i need just to compile FX support... I have FX & HX boards so I'll compile both separatly --> or compile HX & FX into the same binary.... that has to be decided i think... > > I think this is the answer to many discussions we will probably see: > - Do we want a boot logo? Yes i think so, even if optional... > > - Should it support loading the kernel directly? Only if the kernel is placed in a _standardised_ place, like the MBR currently.... If people want kernel ROMs surely it will be better, _and_ SAFER to just compile a linux kernel boot ROM and pop it onto their nearest Net/VGA/SCSI card.... cause most are capable of holding custom boot ROMs, and executing them. > > - Should we support 16bit functions for compatibility Again compile time ... remember you get your _generic_ Linux kernel, you then compile it to do _exactly_ what _you_ want then you install it. The generic BIOS is of course the current MB BIOS's, if they take on OpenBIOS, then implementing the current Flash failsafe (which IMHO is not very well implemented), similar to the 3Com Router BIOS/Firmware(which is implemented beautifully <G>), should be made the default. 3Com router Firmware has 3 parts: Boot Loader - initialises hardware can checks for valid checksum on flash. Provides a method of re-writing boot/main code, or erasing flash - Does nothing hardware dependant, works across platform. Main Code - Takes into account Version/Revision/Chipset can do all functions of Bootloader, but provides user stuff - the real BIOS as it were..... Data Code - Settings/config - user deturmined. > > - ... > Make it configurable (tm) :) > tu chez! yours Matthew (aka Mickey)

2 1

Re: Chipset autodetect -- pro and con
by John Foster Nov. 30, 1998

Nov. 30, 1998

A couple of ideas to consider - single all inclusive chipset support vs. modularized chipset specific builds: 1. The bios core is relatively stable 2. Chipsets keep changing 3. CPU platforms change over time - 386, 486, ........ 4. There are usually 2 or 3 places in the code where chipset initialization is called - usually very early in the code 5. Encountered these problems in the 16 bit bios over many iterations, finally arrived at a basic structure that included a chipset module. The chipset modules required some ASM and some C and some H code. Rather than create 3 files for a chipset, I created one file to keep the chipset info in a convenient place and then extracted the ASM,C, and H info into 3 temporary files when doing the build. 6. Did this about ten years ago using MS C and MASM - primitive but it works 7. MS H2INC utility is very nice - lets one use one H definition file for both C and MASM structures so they are always in sync with each other 8. A bios build was based on a configuration file (xxx.job) that defined variables for the build for a particular configuration 9. Separating the chipsets from the core code made it easier to debug developing new chipset code and to update core code - by allowing testing to verify core code on existing platforms 10. It also made creating new chipset code easier because it is all defined in one separate file. BTW - the openbios.org domain has a temporary link to M's new pages - a bit of kludge so far - but we will work on getting this prettified and organized :-) John -----Original Message----- From: M Carling <m(a)midgard.net> To: openbios(a)elvis.informatik.uni-freiburg.de <openbios(a)elvis.informatik.uni-freiburg.de> Date: Sunday, November 29, 1998 9:13 PM Subject: Chipset autodetect -- pro and con > > >There seems to be some disagreement over the issue of whether or not >OpenBIOS should provide for possibility to compile into a single binary >support for multiple chipset types to be autodetected at run-time. > >For OpenBIOS to be successful, it needs to become more attractive to >the MB manufacturers than the alternatives. I don't know whether such >a feature would be attractive to the MB manufacturers or not. I suggest >will begin by compiling a list of the advantages and disadvantages of >this feature. Having done that (so that we understand it ourselves as >best we can) we should then ask the manufacturers. (This will be a good >step toward getting free hardware from them for development.) > >When we ask them, we should also ask any other questions about their >needs. In effect, we need to do some market research. > >Here are the advantages and disadvantages that I can think of. There are >probably others. > >Pro: > >It's cool. > >It would allow manufacturers to have one BIOS ROM that supports all >their MB products. > >The autodetect code might also be useful for diagnostics. > >Con: > >Extra complexity--something else to go wrong. Bug free code is *really* >important in the BIOS. > >Extra complexity--more difficult to test. > >What other questions would we like the MB manufacturers to answer for us? > >M

1 0

memory allocator
by daniel.engstrom＠riksnett.no Nov. 29, 1998

Nov. 29, 1998

Hello, all. It seems that it will be time soon for med to add a memory allocator to my tree. I know nothing about the implementation of those, anyone who wants to try to make something up? /Daniel --

2 1

Try xpdf today!
by daniel.engstrom＠riksnett.no Nov. 28, 1998

Nov. 28, 1998

Hello, Just figured I should share this: If you think that Adobes Acrobat Reader renders PDF files too slow, give xpdf a shot. It renders faster, but uglier than Acrobat Reader. It can be had from: http://www.foolabs.com/xpdf/ /Daniel --

1 0

GPLed Digital Circuit Simulator
by citibunni＠usa.net Nov. 28, 1998

Nov. 28, 1998

Dear all, I am forwarding the following message from the seul-edu maillist. The GPLed digital circuit simulator may benefits the subscribers of this list. I am _NOT_ the author of the digital circuit simulator. Thi <ttn(a)mingle.glug.org> is. Any corresponding should be with Thi, and not me. Thank you. - ---------------------- Forwarded message begins - ---------------------- From: thi <ttn(a)mingle.glug.org> X-Mailing-list: seul-edu(a)seul.org [...] ObCode: Anyone interested in adapting the (GPLed) digital circuit simulator I'm working on for teaching purposes, please look at the code and let me know how I can help. ftp://ftp.netcom.com/pub/tt/ttn/thud/thud-0.13.README ftp://ftp.netcom.com/pub/tt/ttn/thud/thud-0.13.tar.gz In writing this code, I am also a student, and welcome critique. If THUD is not useful for teaching purposes, how can it be made so? - -------------------- Forwarded message ends - --------------------

1 0

Re: call for datasheets
by Ray Jones Nov. 27, 1998

Nov. 27, 1998

Check http://www.winbond.com.tw/ (taiwan) I see various permutations of the 83C787 digits (e.g 83C877), but I do not see that part. Are you sure that your part is 83C787? You can download Winbond datasheets from that web site.. Is C787 an old ('486 days) part? My recommondation is to focus on recent chipsets first because data is more easily available and the results are most useful. -Ray

2 2

Code release 0.0.2pre1
by Stefan Reinauer Nov. 27, 1998

Nov. 27, 1998

-----BEGIN PGP SIGNED MESSAGE----- Hi... I've put out some new code again, today and it's based on Daniel's work. This is not a final 0.0.2 release as there's a lot of work to do left. I am sorry to say that I am away (working) until sunday evening, so I won't be able to release anything new until the mid of next week. I've put John's work from OpenBIOS.org to the web directory as well as some other stuff.. look at it, comment on it, hack it!!! I expect to have at least a thousand openbios mails in my mbox when I return on Sunday evening ;-)) Philipp Rumpf <prumpf(a)jcsbs.lanobis.de> has looked at the linux kernel startup and the lilo code and determined which software interrupts are needed to boot up a system at the moment.... It's the following 1000 o SET VIDEO MODE 100E o TELETYPE OUTPUT 100F o GET CURRENT VIDEO MODE 1014 o LOAD FONT 11 ? GET EQUIPMENT LIST 12 ? GET MEMORY SIZE 13?? ! DISK ACCESS 140000 ! INITIALIZE SERIAL PORT 1587 COPY EXTENDED MEMORY 1588 GET EXTENDED MEMORY SIZE 15C0 GET CONFIGURATION 15E801 GET MEMORY SIZE > 64M 1600 ! GET KEYSTROKE 1601 ! CHECK FOR KEYSTROKE 1602 ! GET SHIFT FLAGS with the following meaning o obsolete (not really needed) ? don't know don't know, too. ! IMPORTANT. Thanks, Philipp.. I will try to join work again on Sunday evening or on Monday Happy hacking guys.... BTW, I'd like to set out a prize on the best OpenBIOS logo... Any ideas what would be sufficient for this? Maybe we could even find a little company as sponsor for this.. ? :-) Best wishes, Stefan (tired now) - -- Reincarnation: Life sucks, then you die. Then life sucks again. -----BEGIN PGP SIGNATURE----- Version: 2.6.3i Charset: noconv iQEVAwUBNl3svyu+zKndEmP5AQHsMgf/edfqPFPy7g95Mn2Xx0NQBgMsKvIiEfAg 3DYvLBdGwk3uCxJsJ/ltDNPIQRJCBptv+PiKOyLgCfU6nPoOIodptISyarUYEBJU BZg/zzyWHMVscJrV3rMYndwo0LU3wBhKZSyMQuzugpmrO9ePqWRGlUg74N+Le/Gx ufH9SREFleBz8hdUJQClUrduf6yyr49LsWcIz3tca4yy+oYPo1SGTsJRTKf1YroD 1pvFlBzs/1NQM3uhNPqn6vuofvZEqUh0JsaNWfw3nwlcpeTrTlpvyuElJbw4R/EW RU/Y7+nxcx0R/c9KDiS3P+lMxX3i2MV2UvS2OKtRQPbvCuLfAkeS1A== =fF84 -----END PGP SIGNATURE-----

2 1

URL of the new code :-9
by Stefan Reinauer Nov. 27, 1998

Nov. 27, 1998

-----BEGIN PGP SIGNED MESSAGE----- Hi again... Am I getting old? I forgot the URL of the new code... get it at http://www.freiburg.linux.de/OpenBIOS/bin/ g'night OpenBIOS hackers :) Stefan - -- Reincarnation: Life sucks, then you die. Then life sucks again. -----BEGIN PGP SIGNATURE----- Version: 2.6.3i Charset: noconv iQEVAwUBNl3t8iu+zKndEmP5AQGWDgf7BKU/VmfJGYGKlxGNzmyhtPB3aPqoQs9i LJgc6R2AGiN7uYsEBuEedcnzWns4p//tGWq1b4taTSo2lDEGG848tgb04fwuIoP/ lBUTOWRoqlhs3M7mlucpuuNnRhVu7xPBRV4l3qhZOoRxPnYSujw3fdALR5OQjyDF DEUthBtGMbRckkUkexM6gD7PfF2P4QdkZsx5EsTjsp4uS+lUMqpoIo0vMwIKqKRr lk1k/YvTTgdDpiTspmnEwfNkCWN4MhuqIvX2ByVdmPZZO+wk8RyZ94Dh2leHSBqg zuh3sxpKWIS0PFPHwITuCPAcdpQ44s6lwoSBGY9KDmDuyAeE6q4tDg== =7X0A -----END PGP SIGNATURE-----

1 0