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 majordomo@freiburg.linux.de with 'unsubscribe openbios' in the body of the message