New Code :-)

daniel.engstrom at riksnett.no daniel.engstrom at riksnett.no
Sat Nov 14 20:25:32 CET 1998


On 13 Nov, Stefan Reinauer wrote:
> Dear OpenBIOS readers,
> 
> I had the time to have a closer look at Daniel Engstroems code now and I
> think we should use this as a code base for further developments. (Daniel,
> I hope, you allow this :>)
Ok. :)

About the name, when I thought of the name I very delibraty(sp?) avoided
the use of the word 'BIOS', since we're actually not trying to clone the
BIOS, but doing something rather generic. Not that this is important or
anything... 

> 
> We only have support for 3 chipsets right now.
2, the Ali 1510 support does not work yet...

> which is definitely not
> enough. I will try to write support for the Intel 430HX/TX/VX/.. chipsets,
> as I have an old HX board at home. If anyone is capable of doing this
> (it's not really hard, as you just need the datasheets for your chipset
> and a board containing the chipset itself to test)
I must admit that having the data sheets helps, but the only chipset I
have found data sheets for is the ACC1287. Having a working bios image
on disk is what really helps, ndissasm is your friend. Hint: the bios
enters at 0xffff0 (eg. 'ndissasm -e 0xfff0 -o 0xffff0 rom.bin >
bin.txt' for a 64k bios)

> I thought about building something like an eprom simulator which can be
> plugged into the bios socket of a board and to the parallel port of
> another computer which just holds a file with the bios image. This would
> make defelopment and testing *quite* faster. Has anyone experiences with
> this or does anyone know whether there are ready, cheap solutions for
> this?
I know they exist. A one Mbit version costs about $500 here. They can
be bough from DanBit http://www.danbit.dk (Danish languge pages only) A
friend of mine is thinking of designing one for other reasons, he can
be found at http://www2.e.kth.se/~e92_jre/ .

A port 0x80 decoder is very useful...

> Now, at the moment, we don't have hardware drivers for any bootdevices.
> Should we go the way linux goes and write our own drivers or should we try
> to use other bioses (i.e. scsi bios on host adapter) for that?

I think we need to do at least floppy and IDE ourself. That will keep us
busy for a while... I still haven't given up on the idea of being 100%
OpenFrimware compatible at some point in the future.

> Well.. I wrote this just to start discussion again :-)

Some notes on the current code:

The chipset drives are not finished. I am planning of having a 2nd stage
C part of them that runs shortly after the console is initialized, it
would probe and test the memory above 1MB. (The 16 bit asm version
should enable memory below 1MB with a safe timing.) The last part, also
in C should set the memory timings to a value specified by the user
(saved in the NVRAM, obiusly)

the boot/init32 directory should be moved to the top level firmware
dir.

Only MDA displays are working, the EGA/VGA stuff is some bone headed
attempt to get those working without using their BIOSes, it might work
for some cards some day, the other plan is to steal some 386-emulator to
parse the video BIOS with, like the ppc/alpha people do (calling the
video BIOS directly would just postpone the problem 'til we port this
to a non-386 compatible processor, besides the BIOS is 16bit anyway).

Console in is not done yet. I can read the keyboard, but I don't keep
track of the shift-state, etc. Serial console in is not done yet. (What
terminal emulation should we use? Some very basic I  think.) Serial
console is fixed to com1,9600,8n1

Oh, and the board I have been using are Ampro CM2/3SXi, CM2/4DXi,
LB3/P5i. I also have an old ASUS 486 board with a SIS chipset, that I
plan on doing (I have the chipset manual, but the board have an Eprom 
istead of a flash, and I have no 28pin flashes around)

/Daniel

-- 



More information about the openbios mailing list