[HOW TO]Bios development: resources and information to share

[ignus]

Can I say that (in protected mode and unreal mode, the last one should be the default mode at the startup) a segment like CS points to a selector inside the GDT?

EDIT1: There's nothing wrong if I ember my GDT table inside the ROM firmware, right? I waste only a few bytes, then I can copy them in the RAM, if I need it.

[Brendan]

Hi,

EDIT1: There's nothing wrong if I ember my GDT table inside the ROM firmware, right? I waste only a few bytes, then I can copy them in the RAM, if I need it.

There's no reason you can't have a GDT stored in ROM - just make sure that you set the "accessed" flag in each descriptor (otherwise every time the CPU loads the descriptor the "accessed" flag will be clear and the CPU will try to set it, generating pointless writes to ROM).


Cheers,

Brendan

[ignus]

Oh yeah, something's going to work as it's expected to be.
Even if Bochs drives me crazy (why I'm the only person in the world that cannot make work peter-bochs?) I am able to load the GDT

Code: Select all

; at startup:
;	- unreal mode
;	- CS: 	0xF000
;	- EIP:	0x0000 FFF0
[BITS 16]

; ================= GDT ======================
GDT:
	dq 0x0000000000000000 ; null desriptor
	dq 0x00CF92000000FFFF ; code descriptor
	dq 0x00CFFA000000FFFF ; data descriptor
	dq 0x00CFF2000000FFFF ; TSS (is not userful)
	; size: 8B*4 = 32B
GDTR:
	dw 0 ; limit to load
	dd 0 ; base addr
loadGDT:
	cli
	mov word [GDTR], 32-1 ; size
	mov dword [GDTR+2], GDT ; address
	lgdt [GDTR]
	sti
loadSegment: ; load all segment to point the area of memory fro bit 0 to 4GB-1
	jmp 0x08:.loadMain ; 0x08 point to code segment (CRASH HERE! point to undefined memory)
.loadMain:
	mov ax, 0x08 ; 8 = offset from GDT (skips null descriptor)
	mov cs, ax
	mov ax, 0x10 ; 16 = offset from GDT (skips null descriptor and code descriptor)
	mov ds, ax
	mov es, ax
	mov fs, ax
	mov gs, ax
	mov ss, ax
switchToProtectedMode:
	cli
	mov eax, cr0
	or  eax, 1
	mov cr0, eax
	sti
	jmp $

CopyToMemory:
	; todo

JUMPtoMAIN:
	jmp loadGDT
	; size total = 16B
	; code byte = ($ - JUMPtoMAIN)
	times (16-($-JUMPtoMAIN)) db 0

The problem is: now I load the CS correctly, but points to the memory that is empty (undefined?)
First I have to copy some code to the destination's address, then I can jump there. How can I copy some code there? Well, I don't know
But the main problem is to find a way, after jumped (modified CS) from ROM to RAM, to get back to ROM (wip)
However, does it sound good?

PS: That code is magic

Code: Select all

JUMPtoMAIN:
	jmp loadGDT
	times (16-($-JUMPtoMAIN)) db 0

[Nable]

to ignus:
I think that you have to put some ORG directives in your code (and padding before the final jump), without them translator cannot generate right offsets (and without padding it's hard to put your code in right place).

[ignus]

to ignus:
I think that you have to put some ORG directives in your code (and padding before the final jump), without them translator cannot generate right offsets (and without padding it's hard to put your code in right place).

Previously I used [ORG 0xF000], but even if I delete it, it seems to work I really don't know why (what a witchcraft)
Or, at least, [GDTR], [GDRT+2] seems to be loaded correctly (when I type in bochs info sreg recognize 4 segment...)
EDIT1: I wrote something really stupid. In fact, GDT loads wrong (base: 0x0000 0000), I'm trying to fix it. However, ORG is absolutely necessary.

However I decided to set my GDT as this:
0x00 null descriptor
0x08 code segment (from 0x0 to 4GB-1) [cs]
0x10 data segment (from 0x0 to 4GB-1) [ds, fs, gs, ss]
0x18 rom segment (from start rom to 4GB-1) [es]
Is it a good idea? So I can move data from [es:index_a] to [cs:index_b]

EDIT2: It seems that loading GDT would be more difficoult than I thought
Limit is loaded correctly, base address not. If someone is interested...

Code: Select all

[ORG 0xF000]
[BITS 16]

START:

; ============= GDT =============
GDT:
	dq 0x0000000000000000 ; NULL desriptor
	dq 0x00CF92000000FFFF ; RAM CODE descriptor
	dq 0x00CFFA000000FFFF ; RAM DATA descriptor
	dq 0xFFCF9AFF0000FFFF ; ROM CODE descriptor (latest 64k)
	dq 0xFFCFFAFF0000FFFF ; ROM DATA descriptor (latest 64k)
	; size: 8B*4 = 32B SBAGLIATA
GDTR:
	dw 0 ; limit to load
	dd 0 ; base addr

; ============= CODE =============
MAIN:
	cli
	; load GDT
	mov ax, 32-1 ; ONLY 4 ENTRY (forget about the 5th)
	mov word [GDTR], ax
	mov eax, GDT
	mov dword [GDTR+2], eax
	lgdt [GDTR]
	; goto protected mode
	mov eax, cr0
	or  eax, 1
	mov cr0, eax
	sti

	mov ax, 0x20 ; latest descriptor
	mov fs, ax 	 ; CRASH HERE

JUMP: ; FFFF FFF0
	jmp MAIN
	times (16-($-JUMP)) db 0	
END:

From Bochs:


EDIT3: There's something wrong if I first load GDT into the RAM (with some code) and then I jump there to load it?

[Octocontrabass]

0x18 rom segment (from start rom to 4GB-1) [es]
Is it a good idea? So I can move data from [es:index_a] to [cs:index_b]

I don't think that's a good idea. You can already access the ROM using your 0x8 and 0x10 segments, and using the same base address for all segments means you don't need to worry about which segment an instruction is using.

If someone is interested...

Your intentions are pretty clear, but it looks like you don't understand segmentation well enough to write the correct code.

Code: Select all

[ORG 0xF000]

Since you're going to switch to protected mode so early in execution, I would choose to set this to the linear address where your ROM is located. That way, it will be correct for the code in protected mode.

Code: Select all

GDTR:
	dw 0 ; limit to load
	dd 0 ; base addr

Let the assembler generate these values for you, because...

Code: Select all

	mov word [GDTR], ax

...you can't write to ROM. However, this instruction is actually using DS, not CS, so you're writing somewhere in the first 64kB of RAM.

Code: Select all

	lgdt [GDTR]

You will need to add an "o32" prefix. In 16-bit mode, lgdt only loads 24 bits for the GDT base address, but you need it to load 32 bits in order to have a GDT inside the ROM. You also need a CS segment override, since the GDTR is way outside the current DS limit. Since you'll be using CS, you'll also have to subtract the CS base (0xFFFF0000) so that the assembler generates the correct offset.

Code: Select all

	mov cr0, eax
	sti

Don't enable interrupts before you've written an interrupt handler. Also, why not jump to protected mode here? There is no reason to stay in 16-bit mode now that you have a GDT.

[ignus]

Well thanks man you destroy my code and my self-respect (actually I'm crying), but it was userful

The system address map in figure 1.6 shows that the BIOS chip is mapped to two different address ranges, i.e., 4GB_minus_BIOS_chip_size to 4 GB and E_0000h to F_FFFFh. The former BIOS flash-ROM address range varies from chipset to chipset, depending on the maximum BIOS chip size supported by the chipset. This holds true for every chipset and must be taken into account when I delve into the BIOS code in later chapters. The latter address range mapping is supported in most contemporary chipsets.
This 128-KB range (E_0000h–F_FFFFh) is an alias to the topmost 128-KB address range in the BIOS chip.

I've got another question: on a book I'm reading (BIOS Disassembly Ninjutsu Uncovered, one of the most interesting I've ever read) there's written that the latest 128kb of ROM are mirrored at address 0xE0000 to 0xF0000. Is it true? Now I'll try to access that part of memory because, if it's possible, I'll try to posticipate my "baptism of fire" in 32 bit and code for now only in real mode

If someone is interested...

I was trying not to be heavy-going, you all are quite kind and my question isn't a request but a humble aid to a newbie developer. Sorry if I have seemed a bit assh...

[Octocontrabass]

there's written that the latest 128kb of ROM are mirrored at address 0xE0000 to 0xF0000. Is it true?

It depends on the chipset.

Back in the nineties, all BIOSes had an option to "shadow" the BIOS ROM. When it was disabled, the BIOS would configure the chipset to mirror the last 128kB of ROM at 0xE0000 to 0xFFFFF. When it was enabled, the BIOS would configure the chipset to put RAM instead of ROM at 0xE0000 to 0xFFFFF, then the BIOS would copy itself to that RAM.

Modern BIOSes don't have options like that anymore, so you'd have to read the chipset manuals to tell for sure, but I wouldn't be surprised if BIOSes still operate on the assumption that 0xE0000 to 0xFFFFF will be the same as 0xFFFE0000 to 0xFFFFFFFF once the chipset initialization is complete.

You don't need to worry about the hardware, though - just Bochs. A quick look at rombios.c tells me that Bochs probably mirrors the BIOS.

if it's possible, I'll try to posticipate my "baptism of fire" in 32 bit and code for now only in real mode

Trust me, 32-bit mode (without segmentation) is way easier to deal with.

I was trying not to be heavy-going, you all are quite kind and my question isn't a request but a humble aid to a newbie developer. Sorry if I have seemed a bit assh...

Don't worry about it. You're just trying to learn, right? I enjoy sharing my obscure (outside of OSdev) knowledge, and I hope you find it helpful.

[ignus]

Trust me, 32-bit mode (without segmentation) is way easier to deal with.

Well, surely I'll try both of them

However, you were right about shadowing (any doubt?)
It was easier than I though, to set up RAM enviroment. Now I'm lower than 1MB and also data segment seems to work (even if I needed to set my RAM size to a fixed size - decided 4k for now -)
Next: make keyboard work (argh!)

Code: Select all

[ORG 0xF000]
[BITS 16]

times (4096-(END-START)) db 0 ; remember the org 0xf000
START:
; 0xF 0000 to FFFF ROM CODE
; 0xE FFFF to 0000 STACK and VARIABLES


; ============= CODE =============
MAIN:
	jmp 0xF000:SETUP ; change cs
	nop ; add it to not execute LOCK command
SETUP:
	; SETUP segments
	mov ax, 0xF000
	mov ds, ax
	mov es, ax
	mov ax, 0xE000
	mov ss, ax
	mov sp, 0xFFFE ; sp = 0xE FFFF
	mov bp, 0xFFFE

.charApplication:
	xor ax, ax
	mov bx, DATA

	.loop:
		mov al, [bx]
		push word ax
		inc bx
		cmp al, 0
		jne .loop

	.read:
		pop ax
		dec bx
		cmp ax, 'C'
		jne .read

	jmp $

DATA:
	db "Ciao", 0
JUMP: ; FFFF FFF0
	jmp MAIN
	times (16-($-JUMP)) db 0	
END:

Edit1: first thing to do is initialize stack, then I'll work on PS/2 keyboard support (this wouldn't be easy, right?)
Maybe before PS/2 I'll try with serial (seems much easier)
Edit2: it seems more difficoult than I thought to initialize the stack
If ax contain the value to push, ss is 0xE000, sp is 0xFFFC (and also bp), why after push word ax the stack increased but without moving the variable in ax?
Edit3: It doesn't work even if in this way:

Code: Select all

sub sp, 2
	mov bx, sp
	mov [ss:bx], ax

It's because I can't write in ROM? But technically that's not rom...
Edit4: It's scandalous! I can't write from 0xE_0000 to 0xF_FFFF! If I set ss = 0x9000 it works. Yuppie
Edit5: I think that in the following days the SuperIO will be my biggest enemy. To be honest, I never heard of that before...

[Octocontrabass]

It's because I can't write in ROM? But technically that's not rom...

But it is ROM. "Mirroring" is just a shorter name for connecting the address lines in a way that a single device responds to reads/writes at two or more addresses. (The A20 gate is another example of mirroring: it makes the first megabyte of RAM respond to the addresses normally used for the second megabyte of RAM.)

By the way, you should probably detect RAM before you try to use it.

[Brendan]

Hi,

Edit4: It's scandalous! I can't write from 0xE_0000 to 0xF_FFFF! If I set ss = 0x9000 it works. Yuppie
Edit5: I think that in the following days the SuperIO will be my biggest enemy. To be honest, I never heard of that before...

Bochs emulates the PAM registers of the "Intel 440FX" chipset. The area from 0x000C0000 to 0x000FFFFF is split up into 13 different sub-areas, and each of those sub-areas has 2 bits in the PAM registers that control whether reads and writes in that sub-area will go to RAM or get sent to PCI. Note: "get sent to PCI" typically means "get ignored", because nothing on the PCI bus is mapped in that area.

I don't know what the default setup is for these PAM registers (for Bochs) at power on. You may want to set all of them to "reads and writes go to RAM" initially; then copy data into RAM in those areas; then change the PAM to "reads go to RAM, writes go to PCI" (where appropriate) later on (after your POST) to make the areas look like ROM.

You can (and will probably need to) download the datasheet from Intel's web site. You'd be looking for "3.2.18. PAMPROGRAMMABLE ATTRIBUTE MAP REGISTERS (PAM[6:0])" on page 30 of this datasheet. Also note that Bochs does not emulate everything in the chipset 100% correctly; and various things (e.g. the RAM chip sizing and configuration registers) are not emulated by Bochs (if I remember right, you have to determine RAM size from values left in CMOS instead).


Cheers,

Brendan

[ignus]

You can (and will probably need to) download the datasheet from Intel's web site. You'd be looking for "3.2.18. PAMPROGRAMMABLE ATTRIBUTE MAP REGISTERS (PAM[6:0])" on page 30 of this datasheet. Also note that Bochs does not emulate everything in the chipset 100% correctly; and various things (e.g. the RAM chip sizing and configuration registers) are not emulated by Bochs (if I remember right, you have to determine RAM size from values left in CMOS instead).

There aren't enough word to say how much I admire you. How can you always have the answer for everything? (What are the number of tomorrow's lottery?)
I don't want to misuse your knowledge, but maybe you have something to link me about SuperIO and company. I have already found some docs, but I'll need all the help I can

But it is ROM. "Mirroring" is just a shorter name for connecting the address lines in a way that a single device responds to reads/writes at two or more addresses. (The A20 gate is another example of mirroring: it makes the first megabyte of RAM respond to the addresses normally used for the second megabyte of RAM.)

Now I know it too ahah After three hours Now let's try to make serial works correctly (I don't have a serial port on my computer, I really don't know how to test it ahah -well, emulated with something obviously-)

EDIT1: My hope is to finish my work. If my thesis is in June, I'll have 4 months to design and other 6 to conclude it. I think I have enough time.
I'll surely make some documentation (I mean TONS of documentation, about everything I met during this project) and maybe, if you all want, I can post them on osDev

[ignus]

It's me again
I was a little afraid to write here again but well, I try

I was trying to display something in bochs (with vgabios-lgpl, not cirrus), so I started looking here.
It seems that, like with ROM, I can't write from A000:0000 to B000:FFFF (well, I can't write yet) + I can't use BIOS (obviously)
Then I read this:

Writing specific drivers

The alternative approach is to not use the BIOS at all. In this case, you must write your own drivers to interact with the hardware.
The simplest way to get graphics modes without using BIOS would be to develop or reuse an existing VGA driver. This gives you all low resolution modes on practically all hardware, and is easier to do than setting up a virtual machine of any sort.
However, if you want to support high resolutions, you must write a driver for each graphics card that you want your OS to support. Only recommended if you have more than one life to waste. Note that there is no official documentation available for a lot of video cards, and that you need to resort to second-hand information (which tends to be incomplete) and existing driver implementations. If you want hardware acceleration, this is the only way to go.

Seems familiar?

Following IBM specs, VGA mode 0x13 should be perfect. Graphics mode (= you don't have to deal with fonts yet), decent resolution (320x200), small color range (byte sized)

Perfect, let's do it! I supposed I need to setup something. So I was quite happy when I found someone that did that work for me. However, I miss some parts (font bitmap, I can find it on google, and a mysterious text.inc). Since that part aren't fundamental, I can delete that parts, call amazing function set_mode_0x13 and after only 20900 steps, it starts to loop without any sense.

This is a good sign: you need to do-it-yourself completely.
I tried to port modes.c from osdev files, only 13h mode. This is the code (it seems to assembly correctly)

vga.inc

Code: Select all

%define	VGA_AC_INDEX		0x3C0
%define	VGA_AC_WRITE		0x3C0
%define	VGA_MISC_WRITE		0x3C2
%define VGA_SEQ_INDEX		0x3C4
%define VGA_SEQ_DATA		0x3C5
%define VGA_GC_INDEX 		0x3CE
%define VGA_GC_DATA 		0x3CF
;							COLOR emulation		MONO emulation 
%define VGA_CRTC_INDEX		0x3D4				; 0x3B4 
%define VGA_CRTC_DATA		0x3D5				; 0x3B5 
%define	VGA_INSTAT_READ		0x3DA

%define VGA_NUM_MISC_REG	1
%define	VGA_NUM_SEQ_REGS	5
%define	VGA_NUM_CRTC_REGS	25
%define	VGA_NUM_GC_REGS		9
%define	VGA_NUM_AC_REGS		21
%define	VGA_NUM_REGS		(VGA_NUM_MISC_REG+VGA_NUM_SEQ_REGS+VGA_NUM_CRTC_REGS+VGA_NUM_GC_REGS+VGA_NUM_AC_REGS)

%macro outb 2
	mov dx, %1
	mov al, %2
	out dx, al
%endmacro

%macro outw 2
	mov dx, %1
	mov ax, %2
	out dx, ax
%endmacro

%macro inb 1
	mov dx, %1
	in  al, dx
%endmacro

%macro inw 1
	mov dx, %1
	in  ax, dx
%endmacro

vgamode_13h_reg:
	db 0x63	; MISC
	db 0x03, 0x01, 0x0F, 0x00, 0x0E	; SEQ
	db 0x5F, 0x4F, 0x50, 0x82, 0x54, 0x80, 0xBF, 0x1F,			; CRTS
	db 0x00, 0x41, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,			; CRTS
	db 0x9C, 0x0E, 0x8F, 0x28, 0x40, 0x96, 0xB9, 0xA3,	0xFF	; CRTS
	db 0x00, 0x00, 0x00, 0x00, 0x00, 0x40, 0x05, 0x0F, 0xFF 	; GC
	db 0x00, 0x01, 0x02, 0x03, 0x04, 0x05, 0x06, 0x07,			; AC
	db 0x08, 0x09, 0x0A, 0x0B, 0x0C, 0x0D, 0x0E, 0x0F,			; AC
	db 0x41, 0x00, 0x0F, 0x00, 0x00								; AC

set_mode_13h:
	; set misc
	outb VGA_MISC_WRITE, [vgamode_13h_reg]

	;set sequencer
	mov bx, 0 ; xor bl, 0
	%define INDEX (VGA_NUM_MISC_REG)
	.sequencerLoop:
		outb VGA_SEQ_INDEX, bl
		outb VGA_SEQ_DATA, [vgamode_13h_reg+INDEX+bx]
		inc bl
		cmp bl, VGA_NUM_SEQ_REGS
		jl  .sequencerLoop

	; unlock CRTR
	outb VGA_CRTC_INDEX, 0x03
	inb VGA_CRTC_DATA
	or	al, 0x80
	outb VGA_CRTC_DATA, al

	outb VGA_CRTC_INDEX, 0x03
	inb VGA_CRTC_DATA
	and al, 0x7F; ~0x80
	outb VGA_CRTC_DATA, al

	; write CRTC reg 
	mov bx, 0
	%define INDEX (VGA_NUM_MISC_REG+VGA_NUM_SEQ_REGS)
	.crtrLoop:
		outb VGA_CRTC_INDEX, bl
		outb VGA_CRTC_DATA, [vgamode_13h_reg+INDEX+bx]
		inc bl
		cmp bl, VGA_NUM_CRTC_REGS
		jl  .crtrLoop

	; write gc regs
	mov bx, 0
	%define INDEX (VGA_NUM_MISC_REG+VGA_NUM_SEQ_REGS+VGA_NUM_CRTC_REGS)
	.GCLoop:
		outb VGA_GC_INDEX, bl
		outb VGA_GC_DATA, [vgamode_13h_reg+INDEX+bx]
		inc bl
		cmp bl, VGA_NUM_GC_REGS
		jl  .GCLoop

	; write ATTRIBUTE CONTROLLER regs
	mov bx, 0
	%define INDEX (VGA_NUM_MISC_REG+VGA_NUM_SEQ_REGS+VGA_NUM_CRTC_REGS+VGA_NUM_GC_REGS)
	.ACLoop:
		inb VGA_INSTAT_READ
		outb VGA_AC_INDEX, bl
		outb VGA_AC_WRITE, [vgamode_13h_reg+INDEX+bx]
		inc bl
		cmp bl, VGA_NUM_AC_REGS
		jl  .ACLoop

	; lock 16-color palette and unblank display (WHAT?)
	inb VGA_INSTAT_READ
	mov bl, 0x20
	outb VGA_AC_INDEX, bl

	;end
	ret

fill_screen:
	; sync
	nop
	nop
	nop

	; es = video segment 0xA000
	; this time, I should load it
	mov ax, 0xA000
	mov es, ax

	; random color, similar to red-pink in default IBM palette
	mov al, 0x50 

	; fill everything
	mov bx, 0
	.drawLoop:
		mov [es:bx], al

		inc bx
		cmp bx, 320*200-1
		jmp .drawLoop

	; done
	ret

main.asm

Code: Select all

[ORG 0xF000]
[BITS 16]

times (4096-(END-START)) db 0 ; remember the org 0xf000
START:
; 0xF 0000 to FFFF ROM CODE
; 0x9 FFFE to 0000 STACK and VARIABLES
%include "vga.inc"

; ============= CODE =============
MAIN:
	jmp 0xF000:SETUP ; change cs
	nop ; add it to not execute LOCK command
SETUP:
	; SETUP segments
	mov ax, 0xF000
	mov ds, ax
	mov ax, 0xA000
	mov es, ax ; vga segment
	mov ax, 0x9000
	mov ss, ax
	mov sp, 0xFFFE ; sp = 0xE FFFF
	mov bp, 0xFFFE

	call set_mode_13h
	call fill_screen


	jmp $

DATA:
	db "Ciao", 0
JUMP: ; FFFF FFF0
	jmp MAIN
	times (16-($-JUMP)) db 0	
END:

It doesn't crash. After only 625 step in bochs dbg, it calls fill_screen, which should fill from es:0000 to es:ffff (es = A000).
Screen remains black.

So I asked myself: do I need to inizialize something before setting up VGA? I don't think so, because (I'm about to say something silly) I read somewhere that VGA isn't related to PCI, so I don't need to init PCI before VGA. They lied?

Any ideas?

[ignus]

I started writing a bit of docs. Probably it isn't completely correct yet, and it's just the beginning.
I can't upload .pdf, so I post a link. It really doesn't have a licence yet, so use the way you want..

Any advice is appreciated

[Octocontrabass]

So I asked myself: do I need to inizialize something before setting up VGA? I don't think so, because (I'm about to say something silly) I read somewhere that VGA isn't related to PCI, so I don't need to init PCI before VGA. They lied?

A typical (hardware) implementation requires you to initialize PCI at least to the point that you can identify video cards that claim to provide VGA compatibility, configure the chipset to forward VGA accesses to that video card, load the appropriate ROM from the video card, and run the ROM to initialize the video card.

Bochs is not hardware, so you may be able to take shortcuts that wouldn't work on real hardware.


You will need to keep in mind that almost every piece of example code you find assumes that the BIOS has already initialized the hardware.