PnP BIOS

gaf · **Posted:** Sun Sep 12, 2004 2:07 pm

Hi,
I'm having some problems calling the PnP BIOS. My code is a bit lenghty so I'll try to post the most important parts of it only. Please take some time and read through it, I've now been working on this for 2 weeks and I just can't find the error.

Descriptors involved in the BIOS call:

Code:

; 0x20 descriptor - PnP call segment
;   base : (set at runtime)  limit: 0x10 (64 KB)
;   DPL  : 0                             32 bit
dd 0x00000010    dd 0x00c09A00

; 0x28 descriptor - PnP BIOS data segment
;   base : (set at runtime)  limit: 0xFFFF (64 KB)
;   DPL  : 0                              16 bit
dd 0x0000FFFF    dd 0x00009200

; 0x30 descriptor - PnP BIOS code segment
;   base : (set at runtime)   limit: 0xFFFF (64 KB)
;   DPL  : 0                              16 bit
dd 0x0000FFFF    dd 0x00009A00

; 0x38 descriptor - PnP BIOS stack segment
;   base : (set at runtime)   limit: 0x1000 (4 KB)
;   DPL  : 0                              16 bit
dd 0x00001000    dd 0x00009200

; 0x40 descriptor - PnP transfer segment (1)
;   base : (set at runtime)  limit: 0xFFFF (64 KB)
;   DPL  : 0                             16 bit
dd 0x0000FFFF    dd 0x00009200

; 0x48 descriptor - PnP transfer segment (2)
;   base : (set at runtime)   limit: 0xFFFF (64 KB)
;   DPL  : 0                              16 bit
dd 0x0000FFFF    dd 0x00009200

The descriptors' base addresses are set at run-time because the BIOS runs in 16bit pmode and therefore can't access anything in a segment beyond 64k. I set them up as follows:

Code:

SetDescriptorBase(GDT_BIOS_CODE, (u32)pnp_block.P16_code_segment);
SetDescriptorBase(GDT_BIOS_DATA, (u32)pnp_block.P16_data_segment);
SetDescriptorBase(GDT_BIOS_STACK, 0);

// CallBIOS2 is the asm procedure that calls the BIOS, see below
u32 call_bios2 = (u32) pager().LinearToPhysical((void*)((u32)CallBIOS2 &0xfffff000));
call_bios2    += (u32) CallBIOS2 &0xfff;
SetDescriptorBase(GDT_CALL, call_bios2);

BIOS_Selector = GDT_BIOS_CODE;
BIOS_Offset   = pnp_block.P16_code_offset;

'BIOS_Selector' and 'BIOS_Offset' are defined in the asm part of my code and will be used for the final jump.

The asm-code (sorry this is somewhat long...):

Code:

CallBIOS:
; We're about to disable paging for the BIOS call
; This will make all selectors invalide which
; means that we have to save the parameters by
; putting them into the CPU's registers
push esi
push edi
push ebp
mov  ebp, esp

; Don't worry about the way I've stacked the args - I've checked that
mov  eax, [ss:ebp+20]
shl  eax, 16
or   eax, [ss:ebp+16]
mov  ebx, [ss:ebp+28]
shl  ebx, 16
or   ebx, [ss:ebp+24]
mov  ecx, [ss:ebp+36]
shl  ecx, 16
or   ecx, [ss:ebp+32]
mov  edx, [ss:ebp+44]
shl  edx, 16
or   edx, [ss:ebp+40]

; Switch to the BIOS stack
mov  bp, 0x38
mov  ss, bp
mov  [Vstack], esp
mov  esp, 0x400

; Disable paging
mov  ebp, cr0
xor  ebp, 0x80000000
mov  cr0, ebp

push ds
push es
push fs
push gs
pushf

call 0x20:0    ; Far call to GDT_CALL:CallBIOS2

popf
pop  gs
pop  fs
pop  es
pop  ds

; Re-enable paging
mov  ebx, cr0
or   ebx, 0x80000000
mov  cr0, ebx

; Restore the stack
mov  bx, 0x18
mov  ss, bx
mov  esp, [Vstack]

pop  ebp
pop  edi
pop  esi
ret

Vstack dd 0


CallBIOS2:
; Push the parameters on a 16bit stack
push edx
push ecx
push ebx
push eax

; Call the entrypoint
call far word [BIOS_ENTRYPOINT]
add  esp, 16
retf

BIOS_ENTRYPOINT:
BIOS_Offset    dw  0
BIOS_Selector  dw  0

Thanks you,
gaf

tom1000000 · **Posted:** Mon Sep 13, 2004 5:52 am

Hi,

I could be completely wrong however......

You should try outputting to the ports directly, instead of using the BIOS.

IIRC Linux doesn't use the bios, but does a whole bunch of inb() and outb() etc.

Using the BIOS is probably more complicated than bypassing it.

gaf · **Posted:** Mon Sep 13, 2004 6:12 am

Hi tom,
from what I know the PnP BIOS is the only way to get configration informations about the mainboard devices (PIT, DMA, COM ports...) because they aren't connected to the PCI /ISA bus. Linux uses the BIOS too and I already had a look at the code, but it didn't help me finding the problem.

regards,
gaf

bubach · **Posted:** Mon Sep 13, 2004 11:16 am

gaf wrote:

because they aren't connected to the PCI /ISA bus.

so how do u think that BIOS get in toutch with them? ;D

/ Christoffer

gaf · **Posted:** Tue Sep 14, 2004 7:09 am

bubach wrote:

so how do u think that BIOS get in toutch with them? ;D

http://my.execpc.com/~geezer/osd/pnp/index.htm
"The 'legacy' devices, such as the 8253 timer chip and 8259 interrupt controller chip, do not have the logic to support direct probing, and can only be detected via the PnP BIOS."

I don't know how exactly the BIOS communicates with these devices, but I wouldn't be too surprised if it was done on a very low level and in a different way from mainboard to mainboard.

VMware says that the kernel crashed due to a stack fault in kernel space. I'm quite sure that ss and esp are set up correctly but not about ebp. Do I have to assign a special value to it before doing the call ?

regards,
gaf

Candy · **Posted:** Tue Sep 14, 2004 9:46 am

VMWare uses the OS type to skip some parts of the emulation so it can speed up the OS. In short, this means that if you use a different OS setting, you'll get different errors. Result (even with other/other!) is that vmware isn't reliable imo.

Try bochs, and see what it tells you.

Brendan · **Posted:** Tue Sep 14, 2004 10:20 am

Hi,

gaf wrote:

bubach wrote:

so how do u think that BIOS get in toutch with them? ;D

http://my.execpc.com/~geezer/osd/pnp/index.htm
"The 'legacy' devices, such as the 8253 timer chip and 8259 interrupt controller chip, do not have the logic to support direct probing, and can only be detected via the PnP BIOS."

I don't know how exactly the BIOS communicates with these devices, but I wouldn't be too surprised if it was done on a very low level and in a different way from mainboard to mainboard.

"bubach" is right - there is a standard method for BIOSs & software to access plug & play through IO ports. According to the "Plug and Play ISA Specification" there are 3 seperate IO ports:

ADDRESS PORT: 0x0279, Write only
WRITE_DATA PORT: 0x0A79, Write only
READ_DATA PORT: Read only (Relocatable from 0x0203 to 0x03FF)

From what I gather you can skip the BIOS completely and go straight to the IO ports, which IMHO isn't a bad idea when the BIOS expects you to push 16 bit parameters on a 32 bit stack... Using the IO ports doesn't look too easy though (the initialization looks a bit messy).

Also the statement "The 'legacy' devices, such as the 8253 timer chip and 8259 interrupt controller chip, do not have the logic to support direct probing, and can only be detected via the PnP BIOS." came out of the southern end of a north bound horse. The PIT, RTC/CMOS, PIC and DMA chips all use fixed resources that comply with convention, and haven't changed for 20 years (and therefore never need to be detected). How long would you expect a manufacturer of "PC compatibles" to remain in business if they decided to make these devices use different IO ports or something? Anything that isn't compatible isn't a "PC compatible" if you see what I mean...

gaf wrote:

VMware says that the kernel crashed due to a stack fault in kernel space. I'm quite sure that ss and esp are set up correctly but not about ebp. Do I have to assign a special value to it before doing the call ?

The "Plug and Play BIOS Specification" has assembly examples which don't do anything with EBP, and it explicitly states that "The Plug and Play BIOS functions will preserve all FLAGS and registers except for the AX register, which will contain the return code.".

Candy wrote:

Try bochs, and see what it tells you.

I'd be very surprised if Bochs supported "plug & pray" at all...

Cheers,

Brendan

gaf · **Posted:** Wed Sep 15, 2004 8:32 am

Hi Brendan,
from what I know the "Plug and Play ISA Specification" only applies to ISA PnP cards. Since legacy devices where developed before the invention of PnP I'm not sure if they support it today. Using PIT and PIC as examples for legacy devices probably wasn't a very good idea but I could hardly change the quotation. What about the serial and parallel ports ? They can use different addresses..

Quote:

I'd be very surprised if Bochs supported "plug & pray" at all...

It doesn't - this is the reason I switched to VMware.

regards,
gaf

Brendan · **Posted:** Wed Sep 15, 2004 10:17 am

Hi,

gaf wrote:

Hi Brendan,
from what I know the "Plug and Play ISA Specification" only applies to ISA PnP cards. Since legacy devices where developed before the invention of PnP I'm not sure if they support it today.

Any ISA devices that don't support plug & play won't be supported by the BIOS plug & play functions (apart from the basic motherboard devices, PIC, PIT, etc that have fixed IO ports). The only way to find out the resources for these devices is direct probing.

gaf wrote:

Using PIT and PIC as examples for legacy devices probably wasn't a very good idea but I could hardly change the quotation. What about the serial and parallel ports ? They can use different addresses..

Sure, the serial ports can use the base IO ports 0x03F8, 0x2F8, 0x3E8 or 0x2E8 and it's easy to check each of these IO port groups to determine if a serial port is there. Once you've done that put it into loopback mode and make it generate an IRQ, and see which IRQ was received (or just assume it's IRQ 3 and IRQ 4). You can do the same for parallel ports...

It is possible that someone has an "IO card" that is set to strange settings, but it's also extremely unlikely that this card will work with plug & play. In this case the user will have to configure it regardless of what you try.

BTW have you looked at ACPI?

Cheers,

Brendan

gaf · **Posted:** Fri Sep 17, 2004 9:43 am

Hi,
I didn't yet have a look at ACPI but I will do so as soon as I have finished the ISA and PCI stuff.

Since bochs doesn't support the PnP BIOS I had the idea to set up a small dummy myself. It access the parameters on the stack aswell as the (16bit) datasegment just like the BIOS would do without any problems. I'm now quite sure that my code was actually correct, but that I must have overwrittten the BIOS image with my kernel...

regards,
gaf

OSDev.org

PnP BIOS

Who is online