OSDev.org

Posted: **Sat May 07, 2011 6:46 am**

Hey guys, just starting out writing an os from scratch (that is, bootloader and all). I've got a lot of design ideas but in order to test them I need to finish my bootloader. I'm adapting the code for checking whether the A20 line is open from the wiki to AT&T syntax rather than Intel, and most of it's fine. But for some reason there are some registers (DS and ES, I think) that I'm apparently not allowed to push to stack:

Code: Select all

checka20:
    pushf						# Push flags to stack
    push %ds					# Push important registers to stack
    push %es
    push %di
    push %si

Code: Select all

boot.s:96: Error: operand type mismatch for `push'
boot.s:97: Error: operand type mismatch for `push'

As you can see, the other registers push fine. It's just the DS and ES registers that screw up.

Posted: **Sat May 07, 2011 7:26 am**

Are you using something else than a GCC Cross-Compiler? This works for me:

Code: Select all

combuster@daphnis ~/dev $ cat test.s
.section .text
main:
push %es
push %ds
pop %ds
pop %es
combuster@daphnis ~/dev $ i386-elf-as test.s -o test.o
combuster@daphnis ~/dev $ objdump -S test.o

test.o:     file format elf32-i386


Disassembly of section .text:

00000000 <main>:
   0:	06                   	push   %es
   1:	1e                   	push   %ds
   2:	1f                   	pop    %ds
   3:	07                   	pop    %es
combuster@daphnis ~/dev $

Posted: **Mon May 09, 2011 1:25 am**

alaroldai wrote:As you can see, the other registers push fine. It's just the DS and ES registers that screw up.

Probably you should use "pushw" instead of "push".

Posted: **Mon May 09, 2011 3:10 am**

Hobbes wrote:
alaroldai wrote:As you can see, the other registers push fine. It's just the DS and ES registers that screw up.
Probably you should use "pushw" instead of "push".

pushw will cause 16-bit pushes in 32-bit protected mode. This is probably not what you want

Posted: **Mon May 09, 2011 3:48 am**

Owen wrote:pushw will cause 16-bit pushes in 32-bit protected mode. This is probably not what you want

I understood that the code is from a boot loader so it is 16-bits anyway.

Posted: **Mon May 09, 2011 6:44 pm**

Yeah, at this point it's still in 16-bit real mode. First it checks for the A20 line, then it tries to set it, then it switches to protected mode. I tried using pushw, it gives exactly the same error. I'm compiling on Ubuntu 11.04 (64 bit), without using a cross-compiler. Should I be using a cross-compiler? I can't see how that would make much difference (except maybe the version of gas I've got doesn't let you mess with the segment registers because that's the operating system's job?), but I'll give it a go... do I have to download and build it all myself, or is there an Ubuntu package for binutils, etc? Can I just run "sudo apt-get binutils-something"?

**update: I found the "GCC Cross-Compiler on Debian Linux" page, very helpful. I'll give it a try in a minute.

**update 2: Mostly, worked fine, but I haven't tested it yet. I got one error on apt-get update:

Code: Select all

W: Failed to fetch http://www.pedigree-project.org/debian/dists/stable/main/binary-amd64/Packages  404  Not Found

Posted: **Mon May 09, 2011 8:16 pm**

Still got the same errors:

Code: Select all

checka20:
	pushf						# Push flags to stack
    push %ds					# Push important registers to stack
    push %es
    push %di
    push %si
 
    cli							# Clear interrupts
 
    xor %ax, %ax				# Set ax = 0
    mov %ax, %es
 
    not %ax						# ax = 0xFFFF
    mov %ax, %ds					
 
    mov $0x0500, %di
    mov $0x0510, %si
 
    movl %es:(%di), %al
    push %ax
 
    movl %ds:(%si), %al
    push %ax
 
    movl $0x00, %es:(%di)
    movl $0xFF, %ds:(%si)
 
    cmpl $0xFF, %es:(%di)
 
    pop %ax
    mov %al, %ds:(%si)
 
    pop %ax
    mov %al, %es:(%di)
 
    mov $0, %ax
    je check_a20__exit
 
    mov $1, %ax
 
check_a20__exit:
    pop %si
    pop %di
    pop %es
    pop %ds
    popf
 
    ret

Code: Select all

alaroldai@alaroldai-MacBook:~/projects/ROSE/boot$ x86_64-elf-gcc boot.s -o boot.o
boot.s: Assembler messages:
boot.s:96: Error: suffix or operands invalid for `push'
boot.s:97: Error: suffix or operands invalid for `push'
boot.s:112: Error: `%es:(%di)' is not a valid base/index expression
boot.s:115: Error: `%ds:(%si)' is not a valid base/index expression
boot.s:118: Error: `%es:(%di)' is not a valid base/index expression
boot.s:119: Error: `%ds:(%si)' is not a valid base/index expression
boot.s:121: Error: `%es:(%di)' is not a valid base/index expression
boot.s:124: Error: `%ds:(%si)' is not a valid base/index expression
boot.s:127: Error: `%es:(%di)' is not a valid base/index expression
boot.s:137: Error: suffix or operands invalid for `pop'
boot.s:138: Error: suffix or operands invalid for `pop'

Posted: **Mon May 09, 2011 8:47 pm**

Code: Select all

push %ds

is not a valid instruction in 64 bit mode.

Posted: **Mon May 09, 2011 9:43 pm**

yeah, but I'm not in 64 bit mode yet - this is bootloader code. My computer should still boot into 16-bit real mode, right?

Posted: **Mon May 09, 2011 10:26 pm**

alaroldai wrote:yeah, but I'm not in 64 bit mode yet - this is bootloader code. My computer should still boot into 16-bit real mode, right?

Does your compiler/assembler know that you want to generate 16bit code ?

Posted: **Tue May 10, 2011 1:28 am**

Gaah!

Rookie error.

Forgot to put .code16 at the top of the text section.

Posted: **Sun Jun 05, 2011 9:33 am**

Isn't disabling the A20 line a piece of nonsense the hardware designers should have left behind long ago? It's about twenty years since anybody has had to worry about how addresses above 1mb are interpreted.

Posted: **Sun Jun 05, 2011 10:46 am**

Casm wrote:Isn't disabling the A20 line a piece of nonsense the hardware designers should have left behind long ago? It's about twenty years since anybody has had to worry about how addresses above 1mb are interpreted.

It might matter to someone's old program, so why would they ditch this and not ditch all the other legacy stuff at the same time? It only takes a few bytes of code to enable it anyway, and it looks as if you can just leave it open after that even if you want to use BIOS services - I haven't met a BIOS yet that closes it or that goes wrong on account of it being open. Has anyone had any problems when calling the BIOS with the A20 on?

Posted: **Sun Jun 05, 2011 11:57 am**

DavidCooper wrote:It might matter to someone's old program, so why would they ditch this and not ditch all the other legacy stuff at the same time? It only takes a few bytes of code to enable it anyway, and it looks as if you can just leave it open after that even if you want to use BIOS services - I haven't met a BIOS yet that closes it or that goes wrong on account of it being open. Has anyone had any problems when calling the BIOS with the A20 on?

Just how old would the said program have to be before it relied upon addresses wraping round above 0xFFFFF?

Even the majority of MS-DOS programs didn't need it.

It is a question of where you draw the line. At the moment it would be ridiculous if support for legacy PICs disappeared from motherboards, but twenty years from now it will be a different story.

OSDev.org

Check A20 code

Check A20 code

Re: Check A20 code

Re: Check A20 code

Re: Check A20 code

Re: Check A20 code

Re: Check A20 code

Re: Check A20 code

Re: Check A20 code

Re: Check A20 code

Re: Check A20 code

Re: Check A20 code

Re: Check A20 code

Re: Check A20 code

Re: Check A20 code