Page 1 of 1

Calling the PCI Bios

Posted: Sat Apr 10, 2004 9:04 pm
by starscream15
Sorry if this is an old topic, but I didn't find anything answering my particular questions.

I'm trying to access the PCI Bios from pmode, but I get a GPF when I do the far call. I've written the code on my own, based on the PCI bios spec, and I've now switched to borrowing the code from the FAQ, with no luck. My code segment maps all of memory, so I'm pretty sure the page I want is in the segment. It all looks right to me, but I'm betting that my problem has to do with my code segment.

I think I'm in a similar predicament to the author of this thread:
http://www.mega-tokyo.com/forum/index.php?board=1;action=display;threadid=5346
but I've done everything they did & no luck.

My questions are:
1) is there anything else I could be doing wrong?
2) why, in the FAQ, is cs pushed on the stack before making the far call? In the other thread, this made it work; I don't understand.
3) why is there no information anywhere on the LCALL instruction?

Any answers to any of these will be most appreciated.

Re:Calling the PCI Bios

Posted: Sun Apr 11, 2004 12:31 am
by virusx
hi,
Can you provide more source to test.

Can you also post the gdt entries and also how page is mapped.
you dont need to use lcall because it is used to jump to another selector(gdt entry). call is ok.

The reason for page fault may be due to present bit in the page/directory table entry pointing to tha frame containing that address. So, create the virtual to physical mapping of the page containing that address.

regards virusX

Re:Calling the PCI Bios

Posted: Sun Apr 11, 2004 3:28 am
by Pype.Clicker
there's no information about lcall because it's a AT&T name for 'call far' ...

A far call must be used when a RETF ends the procedure. RETF picks the eip value on top of the stack and the segment register just after. CALL FAR places the current EIP and CS on the stack that very way ...

For some unknown reason (unknown due to my imperfect knowledge of AT&T syntax), the code on the FAQ does not issue a FAR call, but instead it performs a near call after pushing the CS value on the stack (so that RETF at the end of the BIOS code can still retrieve the calling segment).

If you ommit the PUSH CS, RETF will get garbage instead, hence the GPF.