Hi all,
My name is Mircea Ciocan, presently I'm struggling as a sysadmin
at a
small ISP and data carrier in Romania, but my "love of the heart" was
allways low level asm programming and hardware hacking.
< rant mode on - you may skip that >
So few days ago I was thinking how can I become as rich as
BillG. or as
famous as Linus ;), remembering that some time ago there was still a
need for people who can do asm and wrote their own device drivers. But
I'm not so smart to make a better Linux and I hate any kind of
spreadsheet so billgatising is not an issue. But what can do an old low
level programmer and hardware guy do to reward somehow the community
that gived him Linux and all those beautifull tools that allow him a
(reletively) quiet and fruitfull job ???
Browsing deadly bored on the FSF site I see that on their task
list the
project of an open BIOS and I rememberd that I see on /. that a new
project was started and after a little search I find you guys :).
By some kind of miracle on the same time few other things
happend:
On /. was announced the smallest PC that can run Linux, making
me
deathly gelous that I wasn't the first to do that ;) and remembering
that with a lot of time ago I haved the smallest ZX Spectrum compatible
in Romania :).
I found the nicest and affordable board that a hacker can find
as a
Mini Internet Gateway build along in a nice case with power supply, 2
serial ports, one Realtek 8019 Ethernet controller with dual interface,
twisted and coax cable, 1MB of RAM and 512KB of FlashROM, "powerd by the
ferocious" ALI 6117C processor ( something like 386SX/40) all on a board
of 100x110mm cased in a nice little plastic case[1]. The beast was used
for connecting a network of max 256 station on 1 or 2
dial-up/leased/ISDN, it has a DHCP server for those windoze machines ;),
it can be administrated remotely by telnet and WEB interface, it has
built-in IP masquerading, traffic shaper, firewalling and it was a dream
to work with. It saved me and my company a LOT of problems (and money)
by zapping expensive routers, expensive windozian proxyes and wingates
:) and yes, even Linux boxes and all that under 200$ !!!!.
So I felt in love instantly, but with the hackerish devil in me
just
awaken, I mistreated a poor box to "see what's inside", beeing firmly
convinced that is some proprietary chip design and I can never make it
to mount network drivers and serve custom web pages for example, not to
mention some other nice usages.
To my great surprise the little thing has the above
configuration and I
said "You're mine baby, you'll run Linux in 2 weeks from now and you'll
be everything that I want to do with you like a wereable(?) computer,
network driven EPROM programmer and many other automation thingies
;)))".
The joy was quickly shadowed by the fact that that the
manufacturer of
the chips "Acer Labs Int'l" (ALI)[2] IS THE MOST ANAL RETENTIVE AND
IDIOTIC CHIP MANUFACTURER IN THE WORLD !!! Now I feel better that I said
it ;).
Protected by password datasheets, no email address, a Taiwan BBS
number
that don't work and nothing more than some description, it was a real
shock me that almost make me hack their american Solaris web host, but I
think: what the hell, I just need a embedded BIOS with serial
redirection and screw ALI.
After another day browsing the Internet for a BIOS and seeing it
at
prices between 200-2000$ I give up closed source and see the light:
"... the world needs an OpenBIOS, and mostly an embedded one ;)))"
On the same time frame a customer with a lot of measurement
points that
spits their measured values on modems ask us if he can use our microwave
MAN for colecting data, given that Breezecom[3] adapters we use have a
phone voice channell simulating a PSTN. Unfortunately the modems did not
work well on voice channel ( it wasn't intended for that) so I came with
the ideea of simulating a modem by network and to use this little
beasts, so now I have more time and resources to work on the BIOS
project.
So, all in all I'm here, all yours, eager to help, code and be
if not a
Linus to BIOSes but maybe a little Alan Cox or Dave Miller. And now
let's get to real ( even protected mode) things ;)
< /rant mode off, thank you for your patience.. >
Questions (not in relevant order):
1) It is considered in this project an embedded BIOS for small
appliance, industrial PCs or PC104 ?
2) Is the list archived somewere?
3) Have you guys established the guide lines of this project and
freezed
the specifications?
4) Does the above specifications contain something about embedded
BIOSEs
and if yes, who is the sub-project leader?
5) What is the organisation of this project, who are the leaders
and how
many of you are here ( I'll be glad to receive personal mail from you to
meet you all) ?
6) [IMPORTANT] Does anybody has specifications of those beasts:
ALI 6117C
ALI M5113-A2
ALI M5232-A1 and if so can he/she share it with me?
7) Is anybody working at some related boards like the above one?
8) What kind of develpment tools you standardised (
assembler,debugger
and so..)? OK, this I'll figure soon when I'll try to see what's in
the
code tar ball.
In the end of this long and boring post thank you for your
patience and
I hope that I can be part of your team for a real free BIOS embedded or
not ;).
Mircea C.
P.S. For the pacient of you who made it here some pointers:
[1]
http://www.surecom.com.tw/ - SURECOM - the maker of Internet Gateway/Hub
on that beautifull board.
[2]
http://www.ali.com.tw/ - Acer Labs - and their most idiotic overseas
site:
http://www.acerlabs.com/
[3]
http://www.breezecom.com/ - BREEZECOM - manufacturers of microwave WAN
adapters, in essance small calculators that are even cuter than Surecom
> >The objective is not to write OpenBIOS such that (in practice) a single
> >compiled image can boot any chipset. Rather, the autodetect objective is
> >that a set of chipsets may be chosen at compile time from which the image
> >is about to boot. Thus, for example, a MB manufacturer could compile a
> >BIOS such that one image would work for all the MBs that they manufacture.
> If this (compile time selection) is the objective, why call it autodetect? I
> would have thought from the name that one image fits all. Then, at run time
> it is autodetected, requiring all of the tables at once.
If someone chooses a set of chipsets at compile time, and then compiles
an image which can automatically detect which of those chipsets it on the
MB on which it finds itself running, why not call that autodetect? Do you
have a better name in mind for such functionality?
Note that the software architecture would not impose any particular limit
on the size of the set of chipsets for which support could be compiled in.
Rather the size of the image is the only constraining factor. I cannot think
of an application that would require a BIOS image that supports more than
a handfull of chipsets. MB manufacturers wouldn't need more than a handful,
home users wouldn't need more than a handful, and embedded systems builders
probably wouldn't need more than one. Who needs a BIOS compiled to run on
every machine?
M
Erin R. Kern wrote:
> The tables for all of the chipsets that you want to support would fill
> any BIOS EEPROM on the market and you haven't even written one line of
> code yet.
The objective is not to write OpenBIOS such that (in practice) a single
compiled image can boot any chipset. Rather, the autodetect objective is
that a set of chipsets may be chosen at compile time from which the image
is about to boot. Thus, for example, a MB manufacturer could compile a
BIOS such that one image would work for all the MBs that they manufacture.
Do you think this has any merit, Eric?
M
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
Eric R. Kern wrote:
> Is the objective of OpenBIOS to provide source code to motherboard
> manufacturers that they can modify and customize for their boards
> or is it to provide a BIOS that will run on an individuals PC?
One objective is that MB manufacturers should have a better, more
reliable BIOS such that license fees don't exist and thus are not
passed on to the consumer.
Another objective is that end users should be able to customize and
compile thier own BIOS.
Of course, since it is Open Source[tm], others may want to do other
things with it. I expect OpenBIOS to become widely used in embedded
systems, for example.
I suspect that providing code that will compile without any pre-
configuration and run on any PeeCee is probably too ambitious. Some
decisions will need to be made at compile time, I think.
M
>The objective is not to write OpenBIOS such that (in practice) a single
>compiled image can boot any chipset. Rather, the autodetect objective is
>that a set of chipsets may be chosen at compile time from which the image
>is about to boot. Thus, for example, a MB manufacturer could compile a
>BIOS such that one image would work for all the MBs that they manufacture.
If this (compile time selection) is the objective, why call it autodetect? I
would have thought from the name that one image fits all. Then, at run time
it is autodetected, requiring all of the tables at once.
-Ray
> After alot of thinking about this I've come to the conclusion that I
agree
> that there should be autodetection of chipsets. I have been reading
some
> pciset documents from Intel, and as Andrew says there is really only
> smaller differences (between the PCI chipsets that is). But all this
> depends on one things; if it is possible to, with 100% accuracy,
determine
> what chipset the BIOS is running on. If this is possible, is see no
reason
> not to include autodetection. A wild guess is that the code for the
> various chipsets (all together) is not more then a couple of kB.
I'll give you a little help with sizing the chipset code since I have
had some experience with this (I am a BIOS programmer for IBM's
Commercial Desktop Division). Upon bootup of a system, there are many
PCI configuration registers that need to be set to a certain value in
order for the system to boot DOS (let alone a sophisticated operating
system like Linux, Windows NT or Windows 98). These registers are
generally set through a table early on in POST (Power On Self Test).
The autodetecting BIOS would need to keep a table for every chipset that
it detects. The tables for all of the chipsets that you want to support
would fill any BIOS EEPROM on the market and you haven't even written
one line of code yet.
I think I have a better design. There are generally three ways of
modifying the BIOS on a computer. The first way is to pull the EEPROM
off the mother board and "burn" an image using an EEPROM burner. The
second way is to enable boot block recovery mode, put the desired flash
image in the floppy drive (or whatever media that was preselected) and
turn the computer on. (Boot block recovery mode is usually a jumper
setting that runs a "bare bones" portion of BIOS in order to load the
desired image.) The third way is through a flash utility.
The flash utility should run from DOS (or maybe Linux for you Linux fans
out there). DOS is used since this utility is run at manufacturing time
before an operating system has been loaded onto the harddrive and DOS
fits nicely onto a floppy. My proposed design would have the system
boot to a CDROM (more space and everyone has one) which boots DOS. The
autodetection would be built into the flash utility. The chipset and
other hardware detected by the flash utility would load the appropriate
modules. These modules would then be put together to form a BIOS image
and a table of pointers to each module would be created at a specified
location in the image.
+------------------------+ FFFFh
| Jmp Vector |
+------------------------+
| Table of Pointers |
+------------------------+
| North Bridge Config. |
+------------------------+
| South Bridge Config. |
+------------------------+
| Cache Configuration |
+------------------------+
| Memory Configuration |
+------------------------+
| ISA Configuration |
+------------------------+
| PCI Configuration |
+------------------------+
| Keyboard Controller |
+------------------------+
| BIOS Functions (int 15)|
+------------------------+
| Planar Hardware |
+------------------------+
| Etc. |
+------------------------+ E000h
Just a thought. Good luck.
Eric R. Kern
