Problem on real hardware

[DavidCooper]

; charger le noyau
xor ax, ax
int 0x13

push es

That's another segment register which could have been corrupted by a BIOS call.

[romfox]

So, when I do a short jmp followed by segment initialisation, and by a far jump to my kernel it reboot my computer but works in VMs.
And when I do directly a far jump to my kernel, and then do segments init and printing to Video RAM it freeze my computer after printing the boot message (I can see it but no the kernel message), and still works on VMs

[DavidCooper]

; affiche un msg
mov si, msgDebut
call print16

Where's the code that this is calling?

[romfox]

Here it is :

Code: Select all

print16:
push ax
push bx

.debut:
lodsb
or al, al
jz .end
mov ah, 0x0e
mov bl, 0xff
int 0x10
jmp .debut

.end:
pop bx
pop ax
ret

[DavidCooper]

How does that code get into the boot sector? Is this done by the %include "fn_boot.inc" part?

I suppose it must be. That's another thing that can corrupt your segment registers. Have you tried putting the right values directly into the segment registers after you've finished using the BIOS, just to be sure you're getting them right?

[romfox]

Yes, it is the only one function in 'fn_boot.inc'. I have to go, hope someone will answer me

[DavidCooper]

Read the bit I added to my previous post. And goodnight!

[Combuster]

Enabling interrupts with only IRQ0 and IRQ1 in the IDT is bound to give trouble. You only need a chipset that complains about all the interrupts not being handled and you're a goner.

Start with making sure you can print when interrupts are disabled, then implement at least a GPF handler before enabling interrupts again. Having dummy handlers for all IRQs is a good thing as well.

[romfox]

Hi all,
Yes I include my functions whith %include and I remember all was working nice before. (Still on a real computer) and after when I implemented new functions my kernel doesn't work anymore.
@Combuster: I Will try when I can, but even if I mask all others interrupts ? (0xfc).
Can it really be an %include problem ?

[sentientnz]

I just dug back through some old boot sector code I had written in NASM to see what looked different. In my code, it seems it wasn't possible to get the far jump to a selector working in code so it's been hand written. You might like to give it a try.

EndLoad:
MOV ECX, CR0
OR CX, 1
MOV CR0, ECX ; Enable Protected Mode

JMP $+2
NOP

DB 0x67
DB 0x66
DB 0xEA
DD 0x00100000
DW 0008 ; Switch To Sel#1:0x00100000

I don't remember what the short jump in the middle was for - I suspect it has to doing with clearing prefetch or something. Been a while since I bothered with bootsectors.

The GDT (just for completeness):

ALIGN 4
GDTR:
DW 3*8-1 ; GDT = 3 Entries
DD BIG_GDT ; Pointer to First Descriptor
ALIGN 4
BIG_GDT:
DD 0x00000000 ; NULL
DD 0x00000000

DD 0x0000FFFF ; Code
DD 0x00CF9A00

DD 0x0000FFFF ; Data
DD 0x00CF9200

[DavidCooper]

I'm finding it hard to keep track of which version is working or freezing or crashing with which setup. Sometimes you're using a version which tries to load segment registers in protected mode before the jump to the kernel, and sometimes afterwards, and sometimes you're doing it using VM or VMs - does that mean both Virtual Machine (which I've never used) and Bochs? It would be helpful if you'd give a full list each time, such as VM - works, Bochs - crash, real PC - freeze, along with any info from Bochs about what went wrong.

It sounds as if it usually works in VM, in which case the jump should be coded correctly - you've already looked carefully at the hex for it, so you should have confirmed that (it's either 66, EA followed by a four-byte address followed by 8, 0, or it's just EA followed by a two-byte address followed by 8, 0). If everything is working in VM, it suggests that it's working by luck and may be failing on a real PC (and in Bochs?) because segment registers aren't being preserved when you call the BIOS - that's the most likely reason for the problem, so it's the first one you need to try to eliminate. I suspect things are going wrong when you run the lgdt instruction because the 4-byte pointer to the gdt has been incorrectly formed or located.

[romfox]

When I say VMs I mean Bochs and Virtual PC. All my tries are working on my VMs. I Will try when I Will go back home.

[DavidCooper]

When I say VMs I mean Bochs and Virtual PC. All my tries are working on my VMs. I Will try when I Will go back home.

You were getting reports at one point from Bochs that it was failing:-

It breaks at "mov ax, 0x10" :s I note that using that I got by Bochs debugger : "Interrupt() : gate descriptor is not a valid sys seg
AND :

CPU protected mode:
CS.mode = 32 bit
SS.mode = 16 bit (?)"

How did you cause that and how did you cure it?

Edit: I misread that last night - I thought it said CS.mode was 16-bit, but it was the stack that was wrong. I also see now that it was an interrupt that caused it, so I'm guessing that must be happening later in the kernel, in which case it's working beyond the jump. So you probably didn't cure it and don't need to yet - that can be fixed later.

[romfox]

This is the result of :
"jmp 0x8:next
[BITS 32]
next:
mov ax, 0x10"

It brokes at "mov ax, 0x10".
I fixed it doing a jump to 0x8:0x1000 or doing a short jump (the 2 cases I explained about the jumps).
ALL works on my 2 differents VMs (Bochs & Virtualbox). And on real tries on my computer I can't debug it, but : with a jmp $ at the end I can see all works but not with a short or far jump.

[DavidCooper]

Okay, I think I've followed that this time (though I don't understand the bit about the interrupt in the Bochs report).

And on real tries on my computer I can't debug it, but : with a jmp $ at the end I can see all works but not with a short or far jump.

My understanding of assembler is rather limited. Where does "jmp $" jump to? What code is it running that lets you know it has worked?