real machine vs bochs

[lama]

Hi,
my little system does not work on real machine (and qemu as well) . On bochs runs everything fine.
Can anyone please tell me how bochs actually differs from real machine and what can i do to fix it?
i dont want to have emulator-only system..
thanks

[zity]

To answer why your system doesn't work on a real machine, you need to supply much more information about your system, how it works and so on (bootloader, programming language, what you have coded so far, etc.).

Just like emulators doesn't work the same way, real machines differs in hardware too. My personal experience tells me that if something isn't working in either qemu or bochs, there is a bug in the code and there is a good change it won't work on real hardware too. If your code works in both qemu and bochs there's a much better change it will work on real hardware to, but you cannot be sure!

If you have written your code well, according to specifications it should be working. If it doesn't you most likely did something wrong

[Combuster]

Due to the utter lack of information, a bunch of statistics:

- Bug On Real Hardware #1: assuming zeroed memory.
- Bug On Real Hardware #2: assuming a floppy read succeeds the first time

Try testing in Virtual PC - it has a tendency of exposing bugs that would normally show up on real hardware, without the weird quirks of real hardware, plus you have a much shorter development cycle. But since qemu breaks, something's even more broken than the ones mentioned above.

In other words:
You too, must debug your code rather than expecting some miracles from our crystal balls. At least try to point out what piece of code is causing troubles.

If you have written your code well, according to specifications it should be working.

What if the OP wrote against Bochs' specifications?

[bewing]

I happen to have been recently doing lots of work on qemu/bochs vs. real hardware when it comes to the floppy drive. There are significant differences between the emulators and "reality" in their floppy model (which the emulators share).

I previously also researched similar problems with the ATA bus. Bochs does not model timing much at all. I would say that most coding issues between bochs and real hardware are timing issues. Bochs also did not model the "cache flush" issue that some ATA drives have.

As combuster said, accidentally accessing unitialized memory is a common cause. He also mentioned floppy retries.

I happen to know there is a bug in the bochs unreal mode emulation.

Bochs sets all the registers and segments to 0 before starting your bootloader, but various models of real hardware do not do this.

[lama]

jj i know about timing issues. but that's not my case. my system fails with gpf when call instruction is executed. (just before paging is initialized). i dont see any way, why is this happening. and the other thing that i cant understand - i have never (ok, for looong time) touched this code (it is just a small init code), the only thing that changed was, ofcourse, filesize..
and i think i dont have to care if memory (or registers) gets zeroized when power resets; or should i ? (i dont see anything in my code, that relies on clean memory)
i dont know what to do next...i suppose i can post that init code...but it is really..dirrty
eh, and sorry for my eng, it must be very annoying to read after me..

[lama]

..post init code and show the instrunction where cpu is failing...

[Combuster]

..post init code and show the instrunction where cpu is failing...

*fetches crystal ball and looks for the missing information between the letters*


If you really want help, this is not really the way...

[lama]

so hello again..
i finally discovered the very first thing that fails in qemu - pic remaping.

Code: Select all

cli
push ax
mov al, 0x11
out 0x20, al
out 0xA0, al
mov al, 0x20
out 0x21, al
mov al, 0x28
out 0xA1, al
mov al, 0x4
out 0x21, al
mov al, 0x2
out 0xA1, al
mov al, 0x1
out 0x21, al
out 0xA1, al
pop ax
sti

qemu crashes with page fault when interrupt flag is set ; i really dont know why cpu wants to access some insanly high memory (781ab80h, the exact value is also in accumulator). idt surely works.
and i rather dont want to know what OP means...

[neon]

Hm, remove the STI and test if it still fails. You shouldnt have much other code after so it shouldnt cause additional issues. If I was to guess, it worked in Bochs out of luck (some older versions of bochs had timing issues.)

[lama]

remove sti? if i'll do that, the hole remapping is useless..and yes - it is working in bochs.
so what i'm doing wrong thistime?

[neon]

When STI is executed, there is a time frame until IRQ0 fires do to the PIT. If its not installed or the handler is erroneous, it may lead to a crash some time after STI is initiated.

I assume that you have already set up the PIT and installed IRQ0 to INT 33 in your IDT?

And I still recommend testing - remove STI and test on all emulators to see if it crashes or not. This will verify if the above is a possible cause of the problem or not. If it works without the STI, it might be the cause. If it still crashes, something else might be at fault.

[lama]

thanks man, i forgot about pit. i guessed that 18hz would be just fine...
but do not lock this topic please more things to come ...

[bewing]

And OP means Original Poster (ie. the user who starts each thread).