Clarification needed

[Wallace I. Kroeker]

Hello,

Now that I've been working with the OpenBIOS code for a little while and as
I slowly pull back the skins of this Onion I would like to get some
clarification about the structure.  I will try to explain what I understand
is to be  the structure and maybe someone can correct me if I'm wrong.

boot/
    This contains all the code needed to get the basic BIOS up and
running (excluding the actual specific chipset code).  The final task under
boot32 is to ungzip something and start running it.

drivers/
    This is the specific chipsets that are supported.

firmware/
    Hmmm ... what is this suppose to be ... it looks like the piece of
code that would provide support for our BIOS interrupt handling.
    HOWEVER, there are some things to watch out for with this scenario.

A standard x86 system has low memory usage as:
    	00000-001DF  -  Interrupt Vectors
    	001E0-002FF  -  User Vectors
          00300-003FF  -  Bios stack/user Vectors
          00400-004FF  -  Bios data
          00500-005FF  -  DOS and Basic Use
          00600-9FFFF  - User Ram
          
    The built in payload that comes with OpenBIOS unloads in the low end
and takes up some of the user space.

This has implications for how OpenBIOS might actually load other
OSs.

Linux for example from a zImage disk loads starting at 0x1000
(contrary to the in-line documentation that claims 0x10000!  If you look at
the code the variable is set to 0x1000 which is the second 64K segment on
the x86 machine).  This means (as Ron pointed out a while back) that for
Linux you should use a bzImage.  The Linux kernel has a hack in it for
magically moving the image to 0x10000 and everything is fine.  The orginal
intent was for this to be used with large linux kernels that won't fit in
the low end.

DOS isn't going to work as the OpenBIOS firmware uses up it's space.

FreeDOS ... someone else will have to tell me about that but if it
is following the DOS model then it will have problems too.

Another thing of note is that the regular Linux boot requires the following
Interrupts to be supported:
    	Linux Interrupts expected in linux/arch/i386/bootsect .S:

0x13  - 00  reset the FDC (Floppy Disk Controller)
    	0x13 - 0x02 read the boot sector
    	0x13 - 0x15  read DASD type (check for a harddrive if DL bit
7 is set ... Linux set DL = 0x81) ...
    	           Likely for the flashdisk we will have to return
something

0x10 - print of characters (e.g. new line ) ...  SUPPORTED
by the video BIOS for now ...

0x15  - memory size AH = 0x88 
    	0x15  - Check   AH = 0xC0 system config parameters - Micro
Channel arch.  :  set the Carry flag for this.
    	 
    	0x16 - keyboard repeat rate setting AX=0305  BX = 0 to set
it to the max
    	0x16 - 00   
    	0x16 - 01

0x11 - Get installed capabilities (AX=0)  EAX has equipment
list ... used to determine if the Mouse is active

0x15 -  0x87  Move Block
    	0x1A - 0x02  Read the real time clock time

So to avoid having to implement these you will have to modify the bootsect.S
code and find other ways of feeding Linux the information it wants.

So what I am doing right now is implementing the interrupts via the
firmware/init/irq.c capabilities so that I can get linux to come up.

Is this correct or should I be putting in BIOS IRQ support in another
location (e.g. in the boot/ code)?

This may have impacts on how Ron re-organizes things too.

Any feedback would be appreciated.

Thanks
Wallace
-
To unsubscribe: send mail to [e-mail]
with 'unsubscribe openbios' in the body of the message