Page 4 of 8
Re: Problem on real hardware
Posted: Tue Dec 06, 2011 4:41 pm
by guyfawkes
If you are in PM you can debug by using code like this
Code: Select all
mov byte [fs:0xB809E], "1" ;print 1
NoKey1:
xor eax,eax
in al,60h ; get key press
cmp al,0x1c ; check if enter
jne NoKey1 ; if not loop
; SOME TEST CODE HERE
mov byte [fs:0xB809E], "2"
NoKey2:
xor eax,eax
in al,60h
cmp al,0x1c
jne NoKey2
; SOME TEST CODE HERE
mov byte [fs:0xB809E], "3"
NoKey3:
xor eax,eax
in al,60h
cmp al,0x1c
jne NoKey3
; SOME TEST CODE HERE
For real PC.
It waits for enter to be pressed and prints 1, then 2 and so on.
Remember the last number before it reboots.
NOTE: Its fasm code, so may need modding for nasm.
My understanding of assembler is rather limited. Where does "jmp $" jump to? What code is it running that lets you know it has worked?
jmp $ is the same as
stop:
jmp stop
Re: Problem on real hardware
Posted: Tue Dec 06, 2011 5:06 pm
by DavidCooper
guyfawkes wrote:jmp $ is the same as
stop:
jmp stop
As there's no routine called "stop", I'm guessing that means it's jumping to itself. If that's the case, when Romfox says he "can see all works", he must mean it doesn't crash because it gets stuck in an infinite loop instead, which won't give him a lot to look at.
I'd like to see some proper debugging done here. After the far jump immediately following the switch to protected mode, I want to see some code that sends a letter and colour to the top left corner of the screen, followed by a delay loop - that's all it takes to see if it's really working or not. If it isn't, look further back for the fault.
The same thing can be done just before the switch to protected mode, putting b800 into ES and 0 into DI before sending ax to the screen (with al=65 and ah=12), and then that code can be modified to try to read the ptrgdt bytes to check that they are correct.
Re: Problem on real hardware
Posted: Tue Dec 06, 2011 5:12 pm
by romfox
Thanks but I have already tried with some 'debug' kernels and the kernel never goes launched on my computer. (And all works in all VMs) =(
Yes that is what I meant. All works in bootsector cause I can see it has not crashed with an infinite loop, but it doesn't jump to any kernel.
Re: Problem on real hardware
Posted: Tue Dec 06, 2011 5:17 pm
by DavidCooper
The other possibility then is that the kernel hasn't loaded. Have you tried testing that? The way to do this is to start the kernel with some bytes that can be recognised easily, then try to read them from the bootloader code and print them to the screen.
E.g. 235, 2, 65, 66 (all decimals) - that's a short jump instruction followed by a jump distance of 2 to get past the 65 and 66 which are two ASCII chars to be read by the boot code (at any point after the attempt to load the kernel) and printed to the screen.
Re: Problem on real hardware
Posted: Tue Dec 06, 2011 10:59 pm
by Muneer
A quick read through the code revealed
Code: Select all
xor eax, eax ; calcule l'adresse lineaire de GDT -- EAX IS 0 NOW
xor ebx, ebx
mov ax, ds ; WHY DO YOU WANT THE VALUE OF DS
mov ecx, eax
shl ecx, 4
mov bx, gdt ; THE LABEL gdt IS 32 BITS IN SIZE. ONLY MUST DO MOV EBX,gdt
add ecx, ebx ; ADDING THE WRONG VALUE
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) ; DS MUST BE ZERO BEFORE JUMPING TO PROTECTED MODE
jmp 0x8:next
Also
Code: Select all
; YOU HAVENT CHANGED YOUR CS SO IT IS GARBAGE AT BOOT TIME. EITHER THAT OR ORG 7C00
[ORG 0x0]
Read those comments by me in caps
EDIT: Triple fault on enabling protected mode means either addressing is wrong like ds is garbage or gdt is not setup in the correct way
EDIT: It would be more easy if your comments were in english
Re: Problem on real hardware
Posted: Wed Dec 07, 2011 4:32 am
by romfox
Thank you I corrected my gdt adress and add a "jmp 0x7c0:start" at the start so CS is now 0x7c0 but this doesnt work (but seems better than before^^).
But trying to set DS to 0x0 when I load gdt and jump it breaks even on VMs...
I keep trying
Re: Problem on real hardware
Posted: Wed Dec 07, 2011 5:30 am
by Muneer
I told to set ds 0 because I was taking that you would put your org as 0x7C00. Since you have your org as 0, then you should set ds as 0x07C0, that I see you already have done
Re: Problem on real hardware
Posted: Wed Dec 07, 2011 6:29 am
by Muneer
Hi , I tested your code. There are some things you have overlooked.
For eg: when you have
Code: Select all
[BITS 16]
mov ax , Label1 ; Here Label1 is a 16 bit address
Label1:
.....some-code.....
Code: Select all
[BITS 32]
mov ax , Label1 ; Here Label1 is a 32 bit address
Label1:
.....some-code.....
Code: Select all
[BITS 16]
mov ax , Label1 ; Here Label1 is a 32 bit address. SO THIS WILL RESULT IN THE LOWER 16 BITS OF THE
; ADDESS OF LABEL1 being entered into ax
mov eax, Label1 ; Here you get what is expected
[BITS 32]
Label1:
.....some-code.....
Code: Select all
[BITS 32]
mov ax , Label1 ; Here Label1 is a 16 bit address. SO THIS WILL RESULT IN THE LOWER 16 BITS OF THE
; ADDESS OF LABEL1 being entered into ax. THIS IS AS EXPECTED
mov eax, Label1 ; Here you get what is NOT expected. The higher EAX is now garbage
[BITS 16]
Label1:
.....some-code.....
Jmp dword 8:next ; This is a special opcode that takes 8 as Cs and the 32 bit address of next because next
; next comes under the section [BITS 32]
[BITS 32]
next:
Now What you have done in your code is that you tried filling the values of the gdtptr at wrong addresses like
Code: Select all
mov dword [gdtptr+2], ecx ; which gets the 16 bit address of gdtptr and adds 2 which is not what you want
Also it seems that your gdt table is also wrong ... I didnt check it but when I inserted my GDT it worked.
So a clean version would be i.e only taking into account getting into protected mode would be
Code: Select all
[BITS 16]
[ORG 0x7C00]
jmp 0:start
start:
cli
mov ax , 0
mov ds , ax ;################ SET DS TO 0
lgdt [GDTR] ; charge la gdt
mov eax, cr0
or ax, 1
mov cr0, eax ; PE mis a 1 (CR0)
jmp dword 8:protected
[BITS 32]
protected:
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 $ ; if I do that I see my boot message
jmp 0x8:0x1000 ; It restart my real computer & works in VMs
GDTR :
dw GDT_End - GDT - 1 ; 16 Bit Size Limit Of GDT
dd GDT ; 32 Bit Linear Address Of GDT
GDT :
dd 0x00000000 , 0x00000000 ; Null
dd 0x0000FFFF , 0x00CF9A00 ; Kernel Code
dd 0x0000FFFF , 0x00CF9200 ; Kernel Data
dd 0x0000FFFF , 0x00CFFA00 ; User Code
dd 0x0000FFFF , 0x00CFF200 ; User Data
GDT_End :
times 510-($-$$) db 144
dw 0xAA55
Re: Problem on real hardware
Posted: Wed Dec 07, 2011 6:51 am
by romfox
I have tried with org 0x7c00 setting DS to 0.
On my computer it breaks when jumping to my kernel cause
"mov cr0, eax
Jmp 0x8:next
[BITS 32]
next:
Jmp $"
Doesnt break. But adding jmp 0x8:0x1000 it breaks.
Re: Problem on real hardware
Posted: Wed Dec 07, 2011 6:59 am
by Muneer
Just out of curiosity, why do you want to jmp 8:0x1000 , when you already have your Cs set to 8 in jmp 8:next.
wouldnt a normal jmp 0x1000, do the job
Re: Problem on real hardware
Posted: Wed Dec 07, 2011 7:11 am
by romfox
Cause a simple jump doesnt work. It seems my kernel is not here. Because I can write to 0xb8000 in color after enabling protected mode so it works but I can't jump to my kernel it reboots my computer.
Edit : It doesnt reboot my computer but doesnt jump to my kernel anymore :
Code: Select all
Mov cr0, eax
jmp 8:next
[BITS 32]
next:
; some code which init segments
mov byte [0xb8a00], 'H'
mov byte [0xb8a01], 0x57
jmp 0x1000
I can see my colored 'H' but no kernel =(
Edit : using the HardCoder's GDT and ORG 0x7c00 followed by jmp 0:start and setting DS to 0 too. I got the same result. It looks BIOS doesnt read my sectors.
Re: Problem on real hardware
Posted: Wed Dec 07, 2011 10:30 am
by romfox
Yes after each int 0x13 I jump If carry but it seems it works. But as like you I think this is an int 0x13 problem cause it doesn't put my kernel to RAM. But don't know what is the problem.
Edit : created a 16 bits register printer function to print my segments or registers but it looks normal (but doesn't work).
And on Bochs I can't debug cause all works.
Re: Problem on real hardware
Posted: Wed Dec 07, 2011 11:12 am
by guyfawkes
Bos ver 1 uses the same method and nasm, download ver 1 and check for any big differences.
See here:
http://bos.asmhackers.net/downloads.php
Re: Problem on real hardware
Posted: Wed Dec 07, 2011 11:52 am
by Combuster
HardCoder wrote:Code: Select all
[BITS 16]
mov ax , Label1 ; Here Label1 is a 32 bit address. SO THIS WILL RESULT IN THE LOWER 16 BITS OF THE
; ADDESS OF LABEL1 being entered into ax
mov eax, Label1 ; Here you get what is expected
[BITS 32]
Label1:
.....some-code.....
What epic nonsense. The address is a completely independent type. Only the ORG directive for binary or the linker for ordered formats determine if the address will actually fit within 16 bits or not.
Re: Problem on real hardware
Posted: Wed Dec 07, 2011 11:59 am
by romfox
Yeah I forgot to read some simples OS codes. But in BOS, regardless I don't have any BPB, and that he reads sector by sector (I read 50 sectors, can it be a problem ?) I don't see any big differences =S