OSDev.org

ignus wrote:The main problem is that, differently from OS development, doesn't exist any forum.biosdev.org, and much less documentation is available (and much less clear, can i make an example?: Intel CPUs should load bios at fixed address 000F FFF0 (or F000:FFF0, if you like it more), but that part of memory should be already taken)

ignus wrote:But still I don't know where to start

Of course it's much simpler (and faster) to forget about the BIOS and write a special bootloader for your OS, so that the OS can be installed in ROM and will boot from ROM with no BIOS (and no disk IO, etc) at all.

For emulators (Bochs, Qemu) it's much much easier, as (unlike real hardware) RAM (and a bunch of other things that the firmware is supposed to initialise) are setup/working before the firmware is started.

CPU starts - the code at 0xFFFFFFF0 (or "0xFFFFF000:0xFFF0")

If you follow the normal real-mode addressing scheme, the physical address should be CS.Selector*16+IP, or, with the values substituted, 0xFFFF0. However, the CPU actually calculates the address using CS.Base+(E)IP (in the real and 16/32-bit protected mode, but not in virtual 8086 or 64-bit protected mode), hence the first address that the CPU requests from the memory is going to be 0xFFFFFFF0. Your inability to use far jumps to code within the ROM at that high address may be due to the fact that loading into CS will reset CS.Base to 16 * the new value of CS.Selector. So, jumping to, say, 0xF000:0xFFF0 will transfer control to 0xFFFF0 instead of 0xFFFFFFF0 and unless the ROM is also mapped at that low location in the memory and the code in it is suited for running with CS(.Selector)=0xF000, it's not going to run.

The reset vector for the 80386 and later x86 processors is physical linear address FFFFFFF0h. The value of the selector portion of the CS register at reset is F000h, the value of the base portion of the CS register is FFFF0000h, and the value of the IP register at reset is FFF0h to form the segmented address FFFFF000h:FFF0h in real mode.

The best place to start

[ORG 0xFFF0]
[BITS 16]

	mov ax, 0xF000 ; I don't need these two lines, right?
	mov cs, ax	

	; go to protected mode
	; optional: initialize ram
	; setup devices
		; DMA
		; PIC
		; PS/2 controller
		; VGA (argh!)

	; code interrupt vector table
	; LOAD your os HERE

The value of 0xfffffff0 is slightly less then 4Gb, so unless the machine has 4Gb physical memory, it cannot point to a valid memory address. The computer's hardware translates this address so that it points to a BIOS memory block.
BIOS stands for Basic Input Output System, and it is a chip on the motherboard that has a relatively small amount of read-only memory (ROM). This memory contains various low-level routines that are specific to the hardware supplied with the motherboard. So, the processor will first jump to the address 0xfffffff0, which really resides in the BIOS's memory. Usually this address contains a jump instruction to the BIOS's POST routines.

ignus wrote:

CPU starts - the code at 0xFFFFFFF0 (or "0xFFFFF000:0xFFF0")

It's it just 16 bytes below 4GB limit?

ignus wrote:What happens if my system doesn't have so much memory (my QEMU is configurated to use just 32 MB of memory, how can it access to 0xFFFFFFF0? )

ignus wrote:From StackOverflow i found this:

If you follow the normal real-mode addressing scheme, the physical address should be CS.Selector*16+IP, or, with the values substituted, 0xFFFF0. However, the CPU actually calculates the address using CS.Base+(E)IP (in the real and 16/32-bit protected mode, but not in virtual 8086 or 64-bit protected mode), hence the first address that the CPU requests from the memory is going to be 0xFFFFFFF0. Your inability to use far jumps to code within the ROM at that high address may be due to the fact that loading into CS will reset CS.Base to 16 * the new value of CS.Selector. So, jumping to, say, 0xF000:0xFFF0 will transfer control to 0xFFFF0 instead of 0xFFFFFFF0 and unless the ROM is also mapped at that low location in the memory and the code in it is suited for running with CS(.Selector)=0xF000, it's not going to run.

And this from wikipedia

The reset vector for the 80386 and later x86 processors is physical linear address FFFFFFF0h. The value of the selector portion of the CS register at reset is F000h, the value of the base portion of the CS register is FFFF0000h, and the value of the IP register at reset is FFF0h to form the segmented address FFFFF000h:FFF0h in real mode.

ignus wrote:So the firmware inside the rom is loaded twice, just before 4GB limit and at address 0xF000:0xFFF0?

ignus wrote:Should my code be similar to this?

Code: Select all

[ORG 0xFFF0]
[BITS 16]

	mov ax, 0xF000 ; I don't need these two lines, right?
	mov cs, ax	

	; go to protected mode
	; optional: initialize ram
	; setup devices
		; DMA
		; PIC
		; PS/2 controller
		; VGA (argh!)

	; code interrupt vector table
	; LOAD your os HERE

your ROM is mapped by the chipset into the 1 MiB area from 0xFFF00000 to 0xFFFFFFFF

Execution begins with the instruction addressed by the initial contents of the CS and IP registers. To allow the initialization software to be placed in a ROM at the top of the address space, the high 12 bits of addresses issued for the code segment are set, until the first instruction which loads the CS register, such as a far jump or call. As a result, instruction fetching begins from address OFFFFFFFOH. Because the size of the ROM is unknown, the first instruction is intended to be a jump to the beginning of the initialization software. Only near jumps may be performed within the ROM-based software. After a far jump is executed, addresses issued for the code segment are clear in their high 12 bits.

From cs.stackexchange wrote:32-bit CPUs start up in what is colloquially known as unreal mode.

Brendan wrote:The best place to start would be the same place the CPU starts - the code at 0xFFFFFFF0 (or "0xFFFFF000:0xFFF0"). This mostly has to be a JMP instruction to some code that should switch to protected mode (without using any RAM), followed by code to detect and initialise RAM chips (which can be a "do nothing" stub for Qemu or Bochs), followed by code to setup other parts of the chipset (if/where necessary for the specific chipset), followed by code to decompress/copy the "run-time" part into the legacy BIOS area.

However, the CPU actually calculates the address using CS.Base+(E)IP

Combuster wrote:Are you sure you read everything?

However, the CPU actually calculates the address using CS.Base+(E)IP

Combuster wrote:Are you sure you read everything?

Combuster wrote:Obviously not, because this is answered where that quote came from.

ignus wrote:

Combuster wrote:Obviously not, because this is answered where that quote came from.

Obviously I didn't understand it well, because I usually read other's people advices before trying to understand 80386 manual.
Maybe you can add something if you've time to waste

ignus wrote:

Combuster wrote:Are you sure you read everything?

However, the CPU actually calculates the address using CS.Base+(E)IP

But if CS is 16bit + IP 16bit (EIP at startup is 0x0000 FFF0, so points to a 16 bit area), how can it point to 0xFFFF FFF0?
EDIT: is CS.Base something different of CS (16bit code segment)?

• The visible value that you can see (e.g. the value that would be loaded into AX by an "mov ax, cs" instruction)
• A hidden "base address"
• A hidden "limit"
• A hidden set of attributes (CPL, read, write, execute, etc)

bluemoon wrote:I suggest the opposite, read the manual and know it well before you start something serious

Note that "a modern CPU (80486 or later)" does not include older CPUs (e.g. 80386) and therefore Intel's 80386 Programmer's Reference Manual will not include this information. More recent Intel manuals do describe this oddity appropriately in the relevant section of the "Processor Management and Initialisation" chapter.

Brendan wrote:Note that "a modern CPU (80486 or later)" does not include older CPUs (e.g. 80386) and therefore Intel's 80386 Programmer's Reference Manual will not include this information.

After RESET, address lines A{31-20} are automatically asserted for instruction fetches. This fact, together with the initial values of CS:IP, causes instruction execution to begin at physical address FFFFFFF0H. Near (intrasegment) forms of control transfer instructions may be used to pass control to other addresses in the upper 64K bytes of the address space. The first far (intersegment) JMP or CALL instruction causes A{31-20} to drop low, and the 80386 continues executing instructions in the lower one megabyte of physical memory. This automatic assertion of address lines A{31-20} allows systems designers to use a ROM at the high end of the address space to initialize the system.