Linker script wiht custom memory location

[Octocontrabass]

But aren't BIOSes supposed to continue executing code even if there is no BPB ?

Sure: if the disk is correctly partitioned, the BIOS will boot it without a BPB. The BIOS authors don't want to boot a disk that isn't bootable.

I guess this sould now be better, but why should we disable interrupts and re-enable them after setting up the stack ?

Interrupts use the stack. If an interrupt happens in the middle of setting up your stack, you don't know where the stack will be and it could overwrite your code.

I'm still not able to hit my code after loading it memory adress 0x9000.

Code: Select all

    mov bx, 0x8000
    [...]
    ljmp 0x0000:0x8000

Perhaps it's because 0x8000 is not 0x9000.

Code: Select all

    ljmp 0x0000:_init

This instruction is five bytes, but there are only three bytes available before the start of the BPB.

Code: Select all

.value 0

Is there any particular reason you're using ".value" instead of ".byte"?

[liwinux]

Interrupts use the stack. If an interrupt happens in the middle of setting up your stack, you don't know where the stack will be and it could overwrite your code.

That’s something I didn’t know about, guess I haven’t paid to much attention to the wiki !

Perhaps it's because 0x8000 is not 0x9000

I’m sorry it’s my fault, in the mean time I have modify the adresses and know I load everything at 0x8000. I know it can confuse but anyway, my linker script seems to work great but I’m still unable to use my print function after loading things at 0x8000 anymore. And I’m unsure why then

This instruction is five bytes, but there are only three bytes available before the start of the BPB.

I’m not sure what do you mean by that. I’m just faking it so for the moment it doesn’t really matter as I’m focusing on continuing to execute my code after loading it

Is there any particular reason you're using ".value" instead of ".byte"?

I don’t really know m, I say this ok another bootloader and I thought is was to store an int. The real problem is that I want to write the bootloader using GAS but I truly can’t find any good resources online. Do you have any good ones to recommend me ? I think I should first have to correctly learn how to write good assembly code but at the same time writing a bootloader would be a great exercices

[Octocontrabass]

I’m still unable to use my print function after loading things at 0x8000 anymore.

I don't see anything else wrong with the code you've posted. Perhaps you should use a debugger to examine what's going on.

I don’t really know m, I say this ok another bootloader and I thought is was to store an int.

The .value directive is equivalent to the .short directive. It's two bytes, but you only need one byte.

The real problem is that I want to write the bootloader using GAS but I truly can’t find any good resources online. Do you have any good ones to recommend me ?

I started with NASM, so I don't have any resources for where to begin using GAS. This manual may be helpful, though.

[liwinux]

Perhaps you should use a debugger to examine what's going on.

I always work with a debugger when I'm stuck but debugging the bootloader is quite challenging. I'm gonna bother you again but what's the bets way to debug this thing ? Any tutorial ?

I started with NASM

I also wanted to start with NASM, but I compare to python, it's way easier than GAS and I want to challenge myself and always work the hard way if you know what I mean. But many thanks for the resource on GAS, that will definitely help me out !

[Octocontrabass]

I'm gonna bother you again but what's the bets way to debug this thing ? Any tutorial ?

I've found the Bochs debugger with its magic breakpoint is very useful for 16-bit code. It's also possible to use GDB with QEMU, although that can get confusing since GDB doesn't understand segmentation.

I also wanted to start with NASM, but I compare to python, it's way easier than GAS and I want to challenge myself and always work the hard way if you know what I mean.

The challenge in writing a bootloader is writing code that reliably works. The differences between assemblers are pretty small by comparison.

[liwinux]

I finally found where the problem was thanks to Bochs ! So apparently, when I load my code at let's 0x8000, between 0x8000 and 07e00 they are 512 byte with 0's. So actually, when I ask to load my code at address 0x8000, in reality it is placed at (0x8000+512) 0x8200...


Here is a dump of my bootloader in Hexadecimal :

Code: Select all

000001f0: 0000 0000 0000 0000 0000 0000 0000 55aa  ..............U.
00000200: 0000 0000 0000 0000 0000 0000 0000 0000  ................
00000210: 0000 0000 0000 0000 0000 0000 0000 0000  ................
...
00000400: b008 e8a6 fc48 656c 6c6f 2057 6f72 6c64  .....Hello World

So, there might be a problem with my linker script then, is it supposed to do that (filling from 0x7e00 to 0x8000 with zero's)?

[Octocontrabass]

So, there might be a problem with my linker script then, is it supposed to do that (filling from 0x7e00 to 0x8000 with zero's)?

It shouldn't do that if you're still using the linker script you posted earlier. I'm not sure how it could be a problem with the linker script unless you've got a typo or something.

[liwinux]

So, there might be a problem with my linker script then, is it supposed to do that (filling from 0x7e00 to 0x8000 with zero's)?

It shouldn't do that if you're still using the linker script you posted earlier. I'm not sure how it could be a problem with the linker script unless you've got a typo or something.

Well here is my linker script :

Code: Select all

ENTRY(_start)

SECTIONS
{
    . = 0x7c00;


    .sector1 : {
        KEEP(*(.sector1))
    }
    . = 0x8000;

    .sector2 : {
        KEEP(*(.sector2))
    }
}

I compile my code with :

Code: Select all

as --32 -o boot.o boot.s

and link it with :

Code: Select all

ld -melf_i386 -o boot.bin --oformat binary -T linker.ld boot.o

I'm not sure either why it does that...

[liwinux]

Well, my bad, I used another linker script. But what are the differences between them ?
Adds useless padding :

Code: Select all

ENTRY(_start)

SECTIONS
{
    . = 0x7c00;


    .sector1 : {
        *(.sector1)
    }
    . = 0x8000;

    .sector2 : {
        *(.sector2)
    }
}

Doesn't add padding :

Code: Select all

SECTIONS
{
   .sector1 0x7c00 : AT(0) {
      *(.sector1)
   }
   .sector2 0x8000 : AT(0x200) {
      *(.sector2)
   }
}

What does the

Code: Select all

AT(0)

and

Code: Select all

AT(200)

do ?

[Octocontrabass]

The AT keyword tells the linker that the layout of your binary file needs to be different from the layout in memory.

Without the AT keyword, the linker assumes you're going to load the entire binary at once starting at 0x7C00. If you were doing that, the padding would be necessary.

[kzinti]

Why did you change your linker script to something you don't understand?

[liwinux]

The AT keyword tells the linker that the layout of your binary file needs to be different from the layout in memory.

Without the AT keyword, the linker assumes you're going to load the entire binary at once starting at 0x7C00. If you were doing that, the padding would be necessary.

Get it, new thing learned today. I'm finally able to do what I wanted and I actually load my code correctly now ! Many thanks !

[liwinux]

Why did you change your linker script to something you don't understand?

Actually because I talked to someone and he told me the take the linker script that he gave me but in the mean time, I forgot that I changed it and here I'm feeling stupid x)
I always try to understand what I write but man this linker script made me mad because of the man pages being not friendly at all ! So I just took whatever I found and test if it would work or not...