OSDev.org

Posted: **Thu Feb 26, 2009 7:24 pm**

Hi,

I compiled the following 16bit code for the APs in the system, that start in real mode.. Well I was trying to debug the code, so went line by line..

Code: Select all

section .text
global AP_startup

;*************************************************
;*            Bootloader Entry Point             *
;*************************************************


AP_startup:

	bits 	16
	xor eax, eax
	mov ds, ax
	mov es, ax
	mov fs, ax
	mov gs, ax
	mov ss, ax
	mov esp, 0x1000

;************************************************
; Incrementing processor count to acknowledge 
; presence. The location of the counter is 0x500
;************************************************
	lock inc byte [COUNTER]
	cli
	hlt

The above is the code that I compiled using NASM... objdump of the obj file is shown below:

Code: Select all

apboot.o:     file format elf32-i386


Disassembly of section .text:

00000000 <AP_startup>:
   0:	66 31 c0             	xor    %ax,%ax
   3:	8e d8                	mov    %eax,%ds
   5:	8e c0                	mov    %eax,%es
   7:	8e e0                	mov    %eax,%fs
   9:	8e e8                	mov    %eax,%gs
   b:	8e d0                	mov    %eax,%ss
   d:	66 bc 00 10          	mov    $0x1000,%sp
  11:	00 00                	add    %al,(%eax)                     **** WAT IS THIS??
  13:	f0 fe 06             	lock incb (%esi)
  16:	00                     	.byte 0x0                                  **** AND THIS?? 
  17:	05                     	.byte 0x5
  18:	fa                      	cli    
  19:	f4                   	        hlt

wat is that stuff in there?? dont think it's supposed to be there, rite?? Am I missing somethin?? Appreciate the help.. thanx..

David.

Posted: **Thu Feb 26, 2009 8:15 pm**

if its 16 bit code you should have a [bits 16] directive, and why did you compile a bootloader into elf?

Posted: **Thu Feb 26, 2009 8:31 pm**

the 16 bits directive is there.. u probably missed it.. I guess the bootloader could be binary too.. but does it really matter? Y do u ask? it actually works fine... until I try n jump to protected mode..

so i decided to do an objdump n figure out wher the prob is, n chk the absolute values of the data and jump offsets... wel.. objdump ws actually giving me better results a few days back.. but then my ubuntu froze, n then I lost the file.. luckily had a backup.. then I do an objdump i get wierd stuff in between.. cant figure out y?? has any1 had this prob... or is it jus me doin somethin wrong??

Posted: **Thu Feb 26, 2009 8:42 pm**

worldsapart wrote:I guess the bootloader could be binary too.. but does it really matter?

If its for a boot sector it does. If it is, and it is built as elf and works, then it might be only working out of luck. (Not to mention possibly breaking possible filesystem compatibility.) Chances are it will break sooner or later. If its not for a boot sector then it does not really matter what you use.

Posted: **Thu Feb 26, 2009 8:47 pm**

It's not a boot sector... it is code to wake up Application processors in an SMP system.. The APs jump to a specified location, on receiving an IPI from the bootstrap processor, where this code is present and starts executing it.. the APs are in a sleep state in the beginning..

Posted: **Thu Feb 26, 2009 8:59 pm**

The wierd dissasembly is most likely because objdump thinks you are dissasembling 32-bit code. Try running it in bochs (or another emulator) and see what happens. And you would probably be safe with setting sp instead of esp until you enter protected or long mode. Also, you will probably want to use a flat binary for startup code because you must base it at XX000h (where XX is the vector you send in the SIPI).

Posted: **Thu Feb 26, 2009 11:16 pm**

ya.. that makes sense.. It works fine wit Qemu.. but i think making it a flat binary is a better idea. thanks johnny..

Posted: **Thu Feb 26, 2009 11:59 pm**

objdump -mi8086 ... solved it.. now it's showing more sensible stuff.. thanks anyways guys..

OSDev.org

objdump

objdump

Re: objdump

Re: objdump

Re: objdump

Re: objdump

Re: objdump

Re: objdump

Re: objdump