Question about which tools to use, bugs, the best way to implement a function, etc should go here. Don't forget to see if your question is answered in the wiki first! When in doubt post here.
If I load my code to 0x2000:0x0000 and set cs=ds=es to 0, CS still equals 0x2000. [ORG 0x2000]
Now if I load my code to 0x0000:0x2000 and set cs=ds=es to 0, CS = 0. [ORG 0x0000]
If I try to load it to 0x0000:0x7e00, I get a RIP > CS.limit in Bochs, but if I load it to some other address it will load, but not print anything out unless CS = 0. The first example doesnt print anything, but the second will.
I want also to notice you that 0x2000:0x0000 is different from 0x0000:0x2000 , the first address coresponds to linear address 0x20000 and the second one coresponds to 0x2000.
I want also to notice you that 0x2000:0x0000 is different from 0x0000:0x2000 , the first address coresponds to linear address 0x20000 and the second one coresponds to 0x2000.
After some reasoning on my part, I realized that they were in fact different addresses I was trying to load.
If I try to load it to 0x0000:0x7e00, I get a RIP > CS.limit in Bochs, but if I load it to some other address it will load, but not print anything out unless CS = 0. The first example doesnt print anything, but the second will.
The problem has been fixed. I was clearing interrupts before I initialized CS to 0, so my code was getting loaded at any known address. This caused the CS:IP pair to fault, IP was greater than the code segment limit.
The problem was solved when I removed the cli from the beginning of the code and used cli/sti to setup the stack
When you load code to 0x7c0:000 your org is 0. This is because when addressing to the base of your segment (which is at 0x7c00) you add 0 to get to the real start of your code.
If you load it to 0x0:0x7c00 your org is 0x7c00, because you address compared to the 0-based segment (and thus need a 7c00 addition to all your addresses within the code).
In your case, I'd consider setting the ORG to 0 when CS=0x200, and the ORG to 0x2000 when the CS=0x0. PS: make sure you load your code there too.
I've been re-writing my bootloader and have come across a problem with bochs.
Re:Memory maps ? Reply #8 on: 06-Sep-04, 06:37am ?
Quote from: Federico Tomassetti on 06-Sep-04, 05:21am
...Bochs seems to not support E820...
> From curufir
Then your code is wrong. Bochs has supported this for as long as I can remember.
I am trying to create a memory map using int 15h, E820 and I am using bochs 2.1.1. This is what I get in my bochs_error.txt file
[BIOS ] *** int 15h function AX=E820, BX=0000 not yet supported!
On the bochs webpage:
Version 2.1.1 is a bugfix release :
* fix bug in int15h function 0xe820
* fix vmware3 disk support on big-endian platforms
* fix conditions for NM exception on FWAIT instruction
* fix symbol conflict in rfb and x display libraries
* allow 16 bit writes to ne2k page 0
* notify display libraries on change of bpp
* fix bug in int13h function 0x10
* fix floppy dialog error on win2k
* fix adress check in TSS IO permission bitmap
* fix buffer overflow vulnerability
* updates for MacOS compile
Heres the code I use:
e820_map:
pusha
mov ebx, 0 ; EBX clear
mov ebp, ebx ; EBP clear
mov edi, mem_map+4 ; ES:DI buffer to read info into
.again:
mov eax, 0x0e820 ; EAX service no
mov edx, 0x534d4150 ; EDX with 'SMAP'
mov ecx, 0x14 ; 20 bytes to read
int 15h
jc .end ; If carry then END
cmp eax, 0x534d4150 ; If EAX! = SMAP
jne .end ; Then END
mov dword eax, [di+8] ; Else get the length of segment
add ebp, eax ; Add it to EBP
add edi, 20+4
inc dword [mem_map]
cmp ebx, 0 ; If EBX == 0 then END
jne .again ; Else continue
.end:
; Store the result in the variable
mov dword [MEMORY_SIZE], ebp
popa ; Restore all registers
mov eax, [MEMORY_SIZE]
ret ; Return.
MEMORY_SIZE dd 0
mem_map dd 0
I just dumped your code into my own bootloader and I don't get any error using 2.1.1.
I didn't expect one to be honest, as my own memory routine tries to use e820 by default (And has been successfully doing so for a long time). In fact the only problem I can remember with the BOCHS memory routines was e801 returning bad values for systems with less than 16mb a while back (Bug reported, and fixed).
So as far as I can see there should be no problem here. Try grabbing the latest BOCHS BIOS from their cvs and see if it helps.
So as far as I can see there should be no problem here. Try grabbing the latest BOCHS BIOS from their cvs and see if it helps.
Didnt change a thing. Whats your setup of bochs? Im using bochs 2.1.1 on windows 2000 with latest bios versions of BIOS-bochs-latest and VGABIOS-elpin-2.40.
is this wit the bochs bios or the gpl bios? last time i looked at bochs it shipped with a couple of bioses.
you probably have a misalignment of your gdt loading stuff. Or, you explicitly set the limit to 0, which means you can't load stuff out of it except from the first byte of the first entry.
Quote from: beyondsociety on 20-Oct-04, 02:54pm
Does anybody know what this bochs error means and how to solve it. Code: load_seg_reg: GDT: DS: index(0001) > limit(000000)[
>You probably have a misalignment of your gdt loading stuff. Or, you explicitly set the limit to 0, which means you can't load stuff out of it except from the first byte of the first entry.
pusha
mov ebx, 0 ; EBX clear
mov ebp, ebx ; EBP clear
mov edi, mem_map+4 ; ES:DI buffer to read info into
This piece of code clears the bx register, and sets up a buffer located at 0000:0004h.
My unreal code uses the bx register to load the selector for allowing 32-bit addresses to reside in real-mode. So when I loaded the selector into bx, it was already loaded with 0. So it was pointing to the first entry in the gdt (null selector), when I wanted to use a linear selector (0x08) causing a GPF in bochs.