Question about which tools to use, bugs, the best way to implement a function, etc should go here. Don't forget to see if your question is answered in the wiki first! When in doubt post here.
I finished coding the bootstrap for my Hard Disk Drive's MBR and I thought of releasing it as an open-source bootstrap(Coded in NASM). Below are the details of this bootstrap code:
; | SSFS 00.01 BootStrap 0.1's tasks: | ;
; | • Relocates the HDD's MBR into memory at 0x0000:0x0600. | ;
; | • Searches in the Partition Table of the HDD to find | ;
; | an active partition (Flag = 0x80). | ;
; | • If an active partition is not found, it will display a | ;
; | relevant error message. | ;
; | • If an active partition is found, it will check its | ;
; | Starting C/H/S value to see if it is valid. | ;
; | • If the Starting C/H/S value is valid, it will load the | ;
; | Boot Sector of that drive into memory at 0x0000:0x7C00 using | ;
; | INT 0x13 (Disk Operations). | ;
; | • If the Starting C/H/S value is not valid, it will | ;
; | use IDE ports to load the Boot Sector of that partition | ;
; | using its LBA28/32 address to the memory location at | ;
; | 0x0000:0x7C000. | ;
; | • After the Boot Sector of the active partition is loaded | ;
; | in 0x0000:0x7C00, it will check for the Boot Sector's | ;
; | Boot Signature (0xAA55). | ;
; | • If the Boot Signature of the active partition's Boot Sector | ;
; | is valid, it will jump to the Boot Sector and give the | ;
; | control to it. | ;
; | • If the Boot Signature of the active partition's Boot Sector | ;
; | is not valid, it will display an error message. | ;
; | | ;
; | | ;
; | SSFS 00.01 BootStrap 0.1's code details: | ;
; | • Compiled code's size in bytes = 446. | ;
; | • Used bytes = 340. | ;
; | • Free bytes filled with null = 106 (Free to program) | ;
; | • Instruction set used = x86. | ;
; | • Original code location = 0x0000:0x7C00. | ;
; | • Relocated code location = 0x0000:0x0600. | ;
; | • Loads the boot sector at = 0x0000:0x7C00. | ;
; | • Uses stack at = 0x0000:0xFFFF. | ;
; | • CS/DS/ES/FS at = 0x0000. | ;
I am going to be using it for my own file system SSFS (Schematically Structured File System). Let me know what you guys think of this.
ATTN: To download the bootstrap code, scroll down the page for the newer version.
Last edited by XCHG on Sun Jul 08, 2007 12:26 am, edited 1 time in total.
On the field with sword and shield amidst the din of dying of men's wails. War is waged and the battle will rage until only the righteous prevails.
Good code, nice comments. Only one thing did you pass a pointer to the partition table entry for the boot sector you are loading in si? The boot sector needs that pointer to know which partition it is on and how big of an offset to add to all disk accesses.
Wow; no, I did not know that I had to pass the pointer to the active partition's descriptor in SI! I will sure look into it and fix this problem. Thank you frank for considering looking at the code. Appreciations.
On the field with sword and shield amidst the din of dying of men's wails. War is waged and the battle will rage until only the righteous prevails.
; <CODE BLOCK>
; Purpose = Set the segment registers as soon as the program is executed
MOV AX , CS ; Read CS in AX
MOV DS , AX ; DS = CS
MOV ES , AX ; ES = DS = CS
MOV SS , AX ; SS = ES = DS = CS
MOV SP , 0xFFFF ; SS:SP = 0x7C00:0xFFFF at the physical address of 0x0008BFFF = ~559th KB
; </CODE BLOCK>
Some issues I see here:
* Your last comment line is wrong; SS should never be 0x7C00 after executing this code when first booting. Lose the last 0; this will also change the physical address corresponding to SS:SP to 0x17BFF.
* You seem to assume CS is set to 0x7C0 when this is executed. This is not always the case. Some BIOSes jump to 0x7C0:0x0000 when booting, some jump to 0x0000:0x7C00. I don't remember which ones are buggy, but anyway it's best not to depend on the initial value of CS and just set AX explicitly in the first line (i.e. "MOV AX, 0x7C0").
* Your stack is misaligned. If you want the first address after the stack to be 0x0x17C00 (as it would be after your code if CS was 0x7C0 initially) you should set SP to 0. It will be decremented before use when you push something onto it.
urxae wrote:
* Your stack is misaligned. If you want the first address after the stack to be 0x0x17C00 (as it would be after your code if CS was 0x7C0 initially) you should set SP to 0. It will be decremented before use when you push something onto it.
The stack should be set to 0xFFFC instead of 0 or 0xFFFF since 0xFFFC is aligned on DWORD and it doesn't change the current stack direction (which you would imply by saying it should be set to 0).
bughunter wrote:
The stack should be set to 0xFFFC instead of 0 or 0xFFFF since 0xFFFC is aligned on DWORD and it doesn't change the current stack direction (which you would imply by saying it should be set to 0).
no, setting it to 0 is just fine (and is definitely what i would do) and doesnt imply changing the stack direction (which im not sure is even possible in RMode -- though i dont know why it wouldnt be)
if you set SP=0, then on the first 'push', the CPU will decrement it and place the data at FFFF/FFFE
Alrighty. I uploaded the new version here. The list of updates is available in the source and the txt files.
ATTN: I had accidentally (for testing purposes) put a RETF instruction just before the long jump in the code which was causing problems right when the code was being relocated. I just uploaded the correct source code here.
