Problem on real hardware

[DavidCooper]

If CS is still 16 bit, you haven't done a far jump into protected mode.

[Edit: I misread that - it was SS, not CS.]

Have you tried Guyfawkes's suggestion? It may need a [BITS 32] in the code before the part you're jumping to.

[romfox]

Sorry it was a mistake of me ^^ It says CS is 16 bits =/

And I am talking about Guyfawkes's solution

[DavidCooper]

Can you print your first bit of code again - the loading part, not the kernel. I want to see what you've done with the gdt code, because it clearly isn't working now.

[romfox]

Here it is :

Code: Select all

%define BASE    0x100  ; 0x0100:0x0 = 0x1000
%define KSIZE   50     ; nombre de secteurs a charger

[BITS 16]
[ORG 0x0]

jmp start
%include "fn_boot.inc"
start:

; initialisation des segments en 0x07C0
    mov ax, 0x07C0
    mov ds, ax
    mov es, ax
    mov ax, 0x8000    ; stack en 0xFFFF
    mov ss, ax
    mov sp, 0xf000

; recuparation de l'unite de boot
    mov [bootdrv], dl    

; affiche un msg
    mov si, msgDebut
    call print16

; charger le noyau
    xor ax, ax
    int 0x13

    push es
initialise_disque: ; Initialise le lecteur de disque
    xor ax, ax
    int 0x13
    jc initialise_disque ; En cas d'erreur on recommence (sinon, de toute façon, on ne peut rien faire)
lire:
    mov ax, BASE ; ES:BX = BASE:0000
    mov es, ax
    xor bx, bx
    mov ah, 2           ; Fonction 0x02 : chargement mémoire
    mov al, KSIZE       ; On lit KSIZE secteurs
    xor ch, ch          ; Premier cylindre (n° 0)
    mov cl, 2           ; Premier secteur (porte le n° 2, le n° 1, on est dedans, et le n° 0 n'existe pas)
    xor dh, dh          ; Tête de lecture n° 0
    mov dl, [bootdrv]   ; Toujours pas d'identifiant de disque, c'est toujours le même.
    int 0x13            ; Lit !
    jc lire             ; En cas d'erreur, on recommence
    pop es

    xor eax, eax      ; calcule l'adresse lineaire de GDT
    xor ebx, ebx
    mov ax, ds
    mov ecx, eax
    shl ecx, 4
    mov bx, gdt
    add ecx, ebx
    mov dword [gdtptr+2], ecx

; passage en modep
    cli
    lgdt [gdtptr]    ; charge la gdt
    mov eax, cr0
    or  ax, 1
    mov cr0, eax        ; PE mis a 1 (CR0)

    jmp 0x8:next

[BITS 32]

next:
    mov ax, 0x10        ; segment de donne
    mov ds, ax
    mov fs, ax
    mov gs, ax
    mov es, ax
    mov ss, ax
    mov esp, 0x9F000    

    jmp 0x8:0x1000    ; reinitialise le segment de code

;--------------------------------------------------------------------
bootdrv:  db 0
msgDebut: db "Chargement du kernel", 13, 10, 0
;--------------------------------------------------------------------
gdt:
    db 0, 0, 0, 0, 0, 0, 0, 0
gdt_cs:
    db 0xFF, 0xFF, 0x0, 0x0, 0x0, 10011011b, 11001111b, 0x0
gdt_ds:
    db 0xFF, 0xFF, 0x0, 0x0, 0x0, 10010011b, 11001111b, 0x0
gdtend:
;--------------------------------------------------------------------
gdtptr:
    dw gdtend - gdt -1
    dd 0  ; base
;--------------------------------------------------------------------

;; NOP jusqu'a 510
times 510-($-$$) db 144
dw 0xAA55

Debuger is also saying that : "read_RMW_virtual_dword_32() : segment violation

And then it breaks at 0x8:next =/

[DavidCooper]

I'm not getting anywhere with this. The gdt looks fine. Could the dw gdtend - gdt -1 be doing the second subtraction before the first one?

[DavidCooper]

You might also want to check the hex for the jump - it should be a prefixed far jump instruction, so that's a 66 EA followed by a 4-byte address and a 2-byte segment value (8 0).

[romfox]

I try with :

Code: Select all

jmp 0x8:0x1000

And then init the segments, AND then writting directly to Video RAM, but it works in VM but still not on real hardware : I see the message of the bootloader, but nothing about what I've written in raw to the ram :s. After spawning the boot message it doesn't reboot, just freez =/

Edit : Yes it is the EA opcode...

[DavidCooper]

The vital question is whether the EA has a 66 byte in front of it?

We need to know why the thing crashed when you loaded ds and why cs was reported as being in 16-bit mode at the time.

[romfox]

No =/

Edit : Using "jmp dword" I got a far jump, but now it still work in VM, but reboot my computer on real test =/

[DavidCooper]

Without the 66h prefix it will think it's jumping into a 16-bit segment rather than 32. Try coding the instruction with a direct 66h machine code instruction before the jump.

[DavidCooper]

Wait a minute, it may work without the prefix if the address is only 2-bytes long - check that to see. The 8 0 would have to follow after just two bytes of address, with the EA before them. I expect that's the case, in which case the jump ought to work fine.

[romfox]

This is "jmp next" => E90000
It seems to don't work cause after that if I init segments an write to Video RAM directly it doesn't work

[DavidCooper]

Have you checked to see if ds is still what you think it is after using the BIOS to load the kernel in? If it's been corrupted by the BIOS (and it may well have been), you won't be calculating the right address for the lgdt-related code.

Set it again from scratch (or push and pop it round the code that uses the BIOS).

Never assume that the BIOS will preserve any registers.

[romfox]

Done and it doesn't work =/

[DavidCooper]

Well, I'm to tired to think straight now. I'll probably just waste your time if I try to suggest anything else at the moment. I'll be back tomorrow to find out who's solved it for you - I'm sure someone will. It'll probably be something really obvious - such things are often hard to find. I don't think it can be the lack of A20 related code, but you might want to add that anyway (to be able to access memory above the 1MB point).