OpenBIOS

openbios@openbios.org

4297 discussions

21 Dec '98

At 06:23 PM 12/20/98 -0800, you wrote: >There hasn't been much activity on the list lately, so I thought it might >be worth mentioning that the FAQ has been accessed 414 times in the last >week. So somebody cares about what we're doing. :-) I am new to the list and very interested. What is the URL for the FAQ? How about other URL's that would be useful in getting up to speed. TIA, Dave

1 0

414 FAQ accesses
by M Carling 20 Dec '98

20 Dec '98

Gang, There hasn't been much activity on the list lately, so I thought it might be worth mentioning that the FAQ has been accessed 414 times in the last week. So somebody cares about what we're doing. :-) M

1 0

Re: Interrupts needed by LILO
by M Carling 12 Dec '98

12 Dec '98

> > Well, that was a property to OF that I was unaware of. What I like about > > OF is the Forth code, the device tree and that is is a standard. > Agreed. I guess I'm just cranky because I think OpenFirmware is limping > because their mission is limited to "like the PC BIOS, only cleaner and > interpreted". This means they don't provide compelling value to the > hardware vendor who only cares about x86. So it's no wonder the PC market > ignores them and it's the SPARCs and Macintoshes that use OpenFirmware. > If OpenBIOS wants to go the OpenFirmware route, that would actually speed > adoption among some groups, as the NetBSD guys have quite a bit of > experience already using OF drivers to boot their kernel. Good point, Todd. If OpenBIOS is OpenFirmware compliant, no one will shake their head, throw up their arms, or accuse us of being non-standard. If OpenBIOS is not OpenFirmware complaint, we need to have some really compelling reasons. M

1 0

Re: Interrupts needed by LILO
by M Carling 12 Dec '98

12 Dec '98

> 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: OpenBIOS Logo contest voting page ready
by Anton Bossenbroek 03 Dec '98

03 Dec '98

Hello, A money reward for the best logo is not really the best thing you can do I think, first because it cost you money and second it has nothing to do anymore with the GNU ideology. I think it would be nicer to give away something that has to do with this project, like a T-Shirt with the logo on it, signed by the main developers, or giving away a special edition OpenBIOS hardware. ..Anton Bossenbroek Op Thu, 3 Dec 1998, Stefan Reinauer wrote: > Hi.. > > I just finnished the OpenBIOS logo contest scripts. check out the contest > at > > http://www.freiburg.linux.de/OpenBIOS/logo/ > > It's possible to vote for the logos now. There are not all logos online, > yet, I will put them online asap. > > Daniele, can you post this to the information boards? > > We need more logos. For that I thought about setting out a prize for the > best logo. Any ideas what would be best for this? > > As I don't have real sponsors yet and pay this prize mostly alone, it > should not be more expensive than let's say US$200 > > Regards, > Stefan. > > -- > Can you afford *not* to use linux? >

1 0

Logo's/IRC
by Matthew Sullivan 03 Dec '98

03 Dec '98

How long is the logos admission/voting open? and... Did we ever sort out an IRC channel/net to use? If not I'll start one on CMDnet .. servers exist at irc.??.cmdnet.net where ?? is one of the following ... uk se de fi no nl .... its a small quiet net so there is rarely twits/splits Yours Matthew

2 1

OpenBIOS Logo contest voting page ready
by Stefan Reinauer 03 Dec '98

03 Dec '98

Hi.. I just finnished the OpenBIOS logo contest scripts. check out the contest at http://www.freiburg.linux.de/OpenBIOS/logo/ It's possible to vote for the logos now. There are not all logos online, yet, I will put them online asap. Daniele, can you post this to the information boards? We need more logos. For that I thought about setting out a prize for the best logo. Any ideas what would be best for this? As I don't have real sponsors yet and pay this prize mostly alone, it should not be more expensive than let's say US$200 Regards, Stefan. -- Can you afford *not* to use linux?

1 0

Re: Chipset autodetect -- pro and con
by Matthew Sullivan 30 Nov '98

30 Nov '98

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 30 Nov '98

30 Nov '98

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 29 Nov '98

29 Nov '98

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

Jump to page: