OSDev.org

The Place to Start for Operating System Developers
It is currently Mon Nov 20, 2017 11:15 am

All times are UTC - 6 hours




Post new topic Reply to topic  [ 24 posts ]  Go to page Previous  1, 2
Author Message
 Post subject: Re: Question about libx86emu
PostPosted: Fri Mar 03, 2017 3:52 pm 
Offline
Member
Member
User avatar

Joined: Sun Nov 20, 2016 7:26 am
Posts: 155
Location: Somewhere
Oh, even after resetting and restoring PICs, functions needs IRQs doesn't work.

Simple read test with int 0x13 resulted:
Image
Looks like it reads a byte, skipping one, reads the next, skipping one, and going on. So it has 256 bytes instead of 512.

I set the master and slave PICs with their default values, 0x08 and 0x70, as I taken these values from http://wiki.osdev.org/8259_PIC#Real_Mode

Thanks in advance

_________________
Keyboard not found!

Press F1 to run setup.
Press F2 to continue.


Top
 Profile  
 
 Post subject: Re: Question about libx86emu
PostPosted: Fri Mar 03, 2017 4:00 pm 
Offline
Member
Member

Joined: Thu May 17, 2007 1:27 pm
Posts: 373
That does not look like a lost IRQ issue. Do your port I/O routines (in particular the inw case) work correctly?

Aside from that its unwise to reset the PIC as that will interfere with interrupts that are accepted by your protected mode drivers. It would be much better to keep the PIC state, emulate the PIC and inject all occurring interrupts into the emulation.


Top
 Profile  
 
 Post subject: Re: Question about libx86emu
PostPosted: Fri Mar 03, 2017 4:15 pm 
Offline
Member
Member
User avatar

Joined: Sun Nov 20, 2016 7:26 am
Posts: 155
Location: Somewhere
Korona wrote:
That does not look like a lost IRQ issue. Do your port I/O routines (in particular the inw case) work correctly?

Aside from that its unwise to reset the PIC as that will interfere with interrupts that are accepted by your protected mode drivers. It would be much better to keep the PIC state, emulate the PIC and inject all occurring interrupts into the emulation.


Yep, they are working.

Actually another BIOS functions that doesn't use IRQs like 10h and 12h functions are working.
I'm having that problem in only int 13h, that made me suspect IRQs.

In Bochs, it only reads 1/4 of sectors instead of 1/2. Strange :?
Bochs debugger doesn't work well as code is running in x86emu.

I will enable logging in x86emu and look at its logs, however.

It looks best solution is emulating PICs, as I don't want to lost protected mode IRQs while the BIOS interrupt.

Thanks

_________________
Keyboard not found!

Press F1 to run setup.
Press F2 to continue.


Top
 Profile  
 
 Post subject: Re: Question about libx86emu
PostPosted: Sat Mar 04, 2017 1:28 am 
Offline
Member
Member
User avatar

Joined: Sat Jan 15, 2005 12:00 am
Posts: 8148
Location: At his keyboard!
Hi,

Agola wrote:
Yes, I was marked thread as 'Solved', but I had a new question and I didn't want to open a new thread for it.

Does libx86emu has PIC emulation? If not, as I remapped PICs, interrupts uses PICs will be confused.
I couldn't find anything about PIC in source.

Can I reset the PIC before the interrupt, and restore its state after interrupt? But then it's going to be a hacky code, and it is going to look like "Napalm's Protected Mode BIOS Functionality" which I didn't want to use before because that also resets PICs.


Assume you have an Ethernet card hammering away with a few thousand IRQs per second; but this NIC shares the same PCI IRQ as the hard disk controller. Tell me how you plan to keep the Ethernet card driver working correctly while you're reprogramming the PIC and while you're sending that shared IRQ to the BIOS inside the emulated machine.

It's impossible for it to work properly.

What you need to do is have protected/long mode IRQ handling that is capable of triggering a "fake BIOS IRQ" within the emulated machine if and only if necessary (e.g. if no native driver is using that IRQ, or if all native drivers that are sharing the IRQ say "my device didn't cause the IRQ").

Note that for UEFI none of this can work anyway; every single BIOS function that exists is a crippled/worthless joke; and all the time you spend trying to get it to work reliably for "BIOS only" (including avoiding all potential problems) is time that wasn't spent avoiding the need to use BIOS.


Cheers,

Brendan

_________________
For all things; perfection is, and will always remain, impossible to achieve in practice. However; by striving for perfection we create things that are as perfect as practically possible. Let the pursuit of perfection be our guide.


Top
 Profile  
 
 Post subject: Re: Question about libx86emu
PostPosted: Sat Mar 04, 2017 10:34 am 
Online
Member
Member

Joined: Mon Mar 25, 2013 7:01 pm
Posts: 1179
Agola wrote:
It looks best solution is emulating PICs, as I don't want to lost protected mode IRQs while the BIOS interrupt.

The best solution is writing native storage drivers. Unlike video cards, storage devices are very well documented, so you won't have any trouble finding the information you need to write a real driver.


Top
 Profile  
 
 Post subject: Re: Question about libx86emu
PostPosted: Sat Mar 04, 2017 10:38 am 
Offline
Member
Member
User avatar

Joined: Sun Nov 20, 2016 7:26 am
Posts: 155
Location: Somewhere
Octocontrabass wrote:
Agola wrote:
It looks best solution is emulating PICs, as I don't want to lost protected mode IRQs while the BIOS interrupt.

The best solution is writing native storage drivers. Unlike video cards, storage devices are very well documented, so you won't have any trouble finding the information you need to write a real driver.


Actually I have storage drivers already. It supports ATA and ATAPI devices, DMA and PIO read / writes. I'm going to use it for only int 0x10.
The reason I tested it with int 0x13 is its easy to understand whats going on.

Then if some BIOSes have IRQ codes in their int 0x10 handler, my code will fail, thats the reason I asked for PICs, actually.

Thanks.

_________________
Keyboard not found!

Press F1 to run setup.
Press F2 to continue.


Top
 Profile  
 
 Post subject: Re: Question about libx86emu
PostPosted: Sat Mar 04, 2017 11:04 am 
Online
Member
Member

Joined: Mon Mar 25, 2013 7:01 pm
Posts: 1179
VGA didn't (and often couldn't) use IRQs, so you probably won't find any video cards that need IRQs for their option ROM code.

You might want to block it from accessing non-video-card ports anyway. Most video card ROMs are well-behaved, but not all of them.


Top
 Profile  
 
 Post subject: Re: Question about libx86emu
PostPosted: Sun Mar 05, 2017 2:04 pm 
Offline
Member
Member

Joined: Thu May 17, 2007 1:27 pm
Posts: 373
Octocontrabass wrote:
VGA didn't (and often couldn't) use IRQs, so you probably won't find any video cards that need IRQs for their option ROM code.

You might want to block it from accessing non-video-card ports anyway. Most video card ROMs are well-behaved, but not all of them.

Intel's modern graphics cards (and other manufacturers might be similar) need a vsync to switch high-resolution (e.g. VBE) modes. I don't know if their BIOSes wait for vsync via interrupts or via polling though (but polling seems more likely). I would not neglect the possibility of graphics hardware generating interrupts during mode switch tough.


Top
 Profile  
 
 Post subject: Re: Question about libx86emu
PostPosted: Mon Mar 06, 2017 11:04 am 
Offline
Member
Member

Joined: Tue May 13, 2014 3:02 am
Posts: 213
Location: Private, UK
Korona wrote:
I would not neglect the possibility of graphics hardware generating interrupts during mode switch tough.


Personally, I don't think that's likely. This approach (emulation) to running the video BIOS code isn't new; it's been used by plenty of OSs (including Linux and Windows), especially on non-x86 platforms. The emulator we're using was originally written by SciTech (of UniVBE fame) and was used in their SNAP Graphics products, so was absolutely designed for running video BIOS code.

As far as I can tell, none of the open-source users of this library have any handling of hardware interrupts. The original SciTech code didn't even have the x86emu_intr_raise function that could be used for this purpose (the equivalent "X86EMU_prepareForInt" can only be used for software interrupts).

I've also looked at VBE code that used V86 mode, including VBEMP (or at least ReactOS's version of it) and it also has no IRQ handling. I've looked at code that's intended for non-x86 platforms (where PCI video cards designed for PCs may be used) and found no PIC emulation, which would be required to support IRQs on such platforms without a real PIC.

That strongly indicates to me that video hardware that generates and requires handling of IRQs in response to VBE requests is extremely rare, if not non-existent.

_________________
Image


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 24 posts ]  Go to page Previous  1, 2

All times are UTC - 6 hours


Who is online

Users browsing this forum: Bing [Bot], Google [Bot], Octocontrabass, Yahoo [Bot] and 19 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group