NASM and ORG directive after short jmp

[mihe]

Hello cloud of wisdom!

Novice level OS dev here.

I am struggling to find a solution to a conceptual question I am having. I hope you guys could help with it.

I am rolling my own bootloader and so far I am doing good progress (slow pace but learning a lot).

This is the situation I have right now, which works perfectly:

• - Windows environment with Bochs
  - Bin file created using NASM with 2 sectors of 512 bytes each. (No file system, just a binary blob)
  - First sector does some standard stuff and:
  • • - Copies the second sector to memory, right after the boot sector, starting at 0x0:0x7E00
      - Does a short jump to that address
  - Second sector:
  • - Some other standard stuff and a couple of functions and some string data.

* NASM file begins with [ORG 0x7C00] so the offsets when referencing positions such as strings in data section are correct.
* References to data strings work correct as well, because the second sector is copied immediately after the first one, so it is contiguous in the machine code file and in memory.

What I cannot make it work is if I decide to load in memory the second sector somewhere else, either before or after the boot sector.

Things I have tried:

- Tried to use a second [ORG] directive in the middle of the file. NASM does not assemble it.
- Load the second sector a bit further (0x8000), then pad the file using TIMES directive, SECTION directive and manual NOP. Even though I thought this was going to work, it did not (or I did it wrong).
- In case I want to load it in, let's say 0x1000, I am blank coming with any solution for this.

Does anyone know a solution for this? Maybe having another file with different [ORG] and using linker afterwards? Maybe using a fixed offset in every op required in the second stage?

Thanks in advance!!

[Octocontrabass]

- Load the second sector a bit further (0x8000), then pad the file using TIMES directive, SECTION directive and manual NOP. Even though I thought this was going to work, it did not (or I did it wrong).

You did it wrong. NASM allows you to specify how sections are arranged both in the flat binary and in memory.

You probably want to use something like this:

Code: Select all

section first vstart=0x7c00
section second vstart=0x1000 align=512

You may need additional parameters depending on how you choose to set up your code.

[mihe]

Thanks for your answer Octocontrabass.

I was not aware of vstart and align. I guess I have a research line to follow now, although so far I could not find good documentation for those parameters. I was using "start=" at this moment for padding the first sector up to the boot signature.

Does vstart and align combined provide the same service than ORG?

Anyway I am going to start a sandbox file to play around with all this new info.

By the way, this will indeed solve the scenario when it is loaded after the boot sector (with a gap), but, what about if for instance we want to load it at 0x1000? Can we make NASM work with negative values?

Thanks again!!!

[Octocontrabass]

Does vstart and align combined provide the same service than ORG?

Vstart completely replaces ORG. Align is just to keep the section neatly aligned to sector boundaries - you can remove it if you don't need it.

By the way, this will indeed solve the scenario when it is loaded after the boot sector (with a gap), but, what about if for instance we want to load it at 0x1000? Can we make NASM work with negative values?

You can set the vstart to wherever you want. You can even make two sections overlap, though I can't think of any reason why you would want to do that in a bootloader.

[mihe]

Thanks Octocontrabass,

I have been playing with it today and I finally understand how it works, and, in the process I have learned about the MAP directive in NASM

In the end I have used a combination of ORG at 0x7C00 for the whole program and then setting the second sector with a new SECTION with the particular VSTART I required. Something like this:

[ORG 0x7C00]
.
.
.
[SECTION stage2 vstart=0x1000]
.
.
.

Thanks again !