OSDev.org

tables.o: In function `init_gdt':
tables.c:(.text+0x10b): undefined reference to `gdt_flush'

extern void gdt_flush(unsigned int);

[GLOBAL gdt_flush]
gdt_flush:
	mov eax, [esp+4]
	lgdt [eax]
	
	mov ax, 0x10
	mov ds, ax
	mov es, ax
	mov fs, ax
	mov gs, ax
	mov ss, ax
	jmp 0x08:.flush
.flush:
	ret

ld -o kernel_l.bin -Ttext 0x7e00 kernel_l.o console.o tables.o -m elf_i386 --oformat binary

ld

Combuster wrote:

ld

Posting Checklist

Apart from using a dodgy linker and a dodgy reference, which file that you pass contains the implementation of gdt_flush?

which file that you pass (...)

Combuster wrote:

which file that you pass (...)

boot.bin: file not recognized: File format not recognized

nasm boot.asm -f elf -o boot.elf

boot.asm:1: error: unrecognised directive [ORG]

-Ttext 0x7e00

So the solution is to rewrite boot.asm, so it would compile to elf format? Or there is any other solutions?

Bender wrote:Also, you would have to use a linker script instead of an ORG, to define your start address.

[org 0x7c00]
[bits 16]

Start:
	mov al, 'A'
	mov ah, 0eh
	int 10h
	
	jmp $
	
times 510 - ($ - $$) db 0
dw 0xAA55

nasm boot.asm -f bin -o boot.bin
qemu boot.bin

ENTRY(Start)
INPUT(boot.o)
OUTPUT_FORMAT(elf32-i386)
OUTPUT(boot.bin)
SECTIONS
{
	. = 0x7c00;
	.text : { *(.text) }
}

section .text
	[global Start]
[bits 16]

Start:
	mov al, 'A'
	mov ah, 0eh
	int 10h
	
	jmp $
	
times 510 - ($ - $$) db 0
dw 0xAA55

Modestas wrote:

Bender wrote:Also, you would have to use a linker script instead of an ORG, to define your start address.

How the hell I can do this? I've tried few hours to do it, tried to google some info, but still nothing.

I have this assembly code:

Code: Select all

[org 0x7c00]
[bits 16]

Start:
	mov al, 'A'
	mov ah, 0eh
	int 10h
	
	jmp $
	
times 510 - ($ - $$) db 0
dw 0xAA55

If I do:

Code: Select all

nasm boot.asm -f bin -o boot.bin
qemu boot.bin

It prints 'A' character. But how to do it with linker script?
I've tried this:

Code: Select all

ENTRY(Start)
INPUT(boot.o)
OUTPUT_FORMAT(elf32-i386)
OUTPUT(boot.bin)
SECTIONS
{
	. = 0x7c00;
	.text : { *(.text) }
}

Assembly code:

Code: Select all

section .text
	[global Start]
[bits 16]

Start:
	mov al, 'A'
	mov ah, 0eh
	int 10h
	
	jmp $
	
times 510 - ($ - $$) db 0
dw 0xAA55

But nothing happens, qemu won't find bootable floppy drive.

And with linker script boot.bin is not 512 bytes as it should be, it's greater than 3kb.

seuti wrote:

Modestas wrote:

Bender wrote:Also, you would have to use a linker script instead of an ORG, to define your start address.

How the hell I can do this? I've tried few hours to do it, tried to google some info, but still nothing.

I have this assembly code:

Code: Select all

[org 0x7c00]
[bits 16]

Start:
	mov al, 'A'
	mov ah, 0eh
	int 10h
	
	jmp $
	
times 510 - ($ - $$) db 0
dw 0xAA55

If I do:

Code: Select all

nasm boot.asm -f bin -o boot.bin
qemu boot.bin

It prints 'A' character. But how to do it with linker script?
I've tried this:

Code: Select all

ENTRY(Start)
INPUT(boot.o)
OUTPUT_FORMAT(elf32-i386)
OUTPUT(boot.bin)
SECTIONS
{
	. = 0x7c00;
	.text : { *(.text) }
}

Assembly code:

Code: Select all

section .text
	[global Start]
[bits 16]

Start:
	mov al, 'A'
	mov ah, 0eh
	int 10h
	
	jmp $
	
times 510 - ($ - $$) db 0
dw 0xAA55

But nothing happens, qemu won't find bootable floppy drive.

And with linker script boot.bin is not 512 bytes as it should be, it's greater than 3kb.

Maybe it is because you are telling the linker you want the elf format and I think the MBR has to be a flat binary.

• for floppy (unpartitioned, with BPB, with old "int 0x13")
• for BIOS MBR partitioned hard disk (MBR partitioned, without BPB, with "int 0x13 extensions")
• for BIOS GPT/hybrid hard disk (GPT partitioned, without BPB, with "int 0x13 extensions")
• for BIOS network boot/PXE (completely different, no disk IO at all)
• for BIOS "no emulation El Torito" CDs
• for 32-bit UEFI
• for 64-bit UEFI

• what the physical and/or virtual address space will look like when the kernel is started
• which data (memory map, video buffer details, etc) is passed to the kernel and how
• what can the kernel assume about the CPU's state - which mode will the CPU be in, what will registers contain, can the kernel assume FPU has been initialised, is there a GDT or IDT, will caches be enabled, will MTRRs be configured, will IRQs be enabled, etc.
• the state/s of all other hardware - e.g. is A20 guaranteed to be enabled, what state are other CPUs in, are PCI devices guaranteed to be correctly preconfigured (and how) or in an undefined state, what about PIC/IO APIC (and local APIC), etc.
• if the boot loader has to provide some sort of interface/API, then that has to be included too. What CPU mode is used for the interface/API and which calling conventions. For each function the interface/API provides; what do they do, what are the input and output parameters, what are the limitations.

Brendan wrote:The boot loader and the kernel need to be completely separate;