OSDev.org

The Place to Start for Operating System Developers
It is currently Fri Sep 22, 2017 6:17 pm

All times are UTC - 6 hours




Post new topic Reply to topic  [ 9 posts ] 
Author Message
 Post subject: General Master Boot Record
PostPosted: Sat Sep 09, 2017 11:53 am 
Offline
Member
Member

Joined: Thu Jul 05, 2012 5:12 am
Posts: 841
Location: Finland
This is probably my first actual release of OSDev code. I have written a lot of code but never put it under public review. This is also like a test to see what happens if I try to do that. For me this whole publishing process is more important than the actual thing published at this time. This is important thing to mention because I do not think a release like this is worth an announcement in general but I play my "first release" card. I start with a small test that is called General Master Boot Record.

  • 8086 compatible code.
  • CHS and LBA disk access routines.
  • Designed for real hard drives and USB sticks.
  • USB emulated floppy or hard drive both work.
  • Defensive programming taken very seriously.
  • General code "alignment" for size-constrained area.

There is nothing special in the design itself and it is all about the implementation. If you think this license is still too restrictive (shoult not be) I can try to make it even more free. The license and my moral approval make it possible to use in proprietary software.

General Master Boot Record

Comments?


Attachments:
MBR.png
MBR.png [ 36.52 KiB | Viewed 886 times ]

_________________
Undefined behavior since 2012
Top
 Profile  
 
 Post subject: Re: General Master Boot Record
PostPosted: Sun Sep 10, 2017 9:23 am 
Offline
Member
Member

Joined: Mon Mar 25, 2013 7:01 pm
Posts: 1127
Antti wrote:
Comments?

Is there any particular reason you're overriding the assembler's optimizations? Most of your overrides have no effect at all, and a few of them make your code larger.

There are a few other space-wasters in your code, such as a far jump when CS is already a known value, and a CS segment override when the default segment has the same value as CS, an instruction that operates on AX when it could get the same result operating on AL, and an "add" that could be an "inc".

Your code for LBA to CHS conversion doesn't handle more than 256 cylinders. A setup where this matters would be rare, but it's a potential issue.


Top
 Profile  
 
 Post subject: Re: General Master Boot Record
PostPosted: Sun Sep 10, 2017 10:30 am 
Offline
Member
Member

Joined: Thu Jul 05, 2012 5:12 am
Posts: 841
Location: Finland
Octocontrabass wrote:
Is there any particular reason you're overriding the assembler's optimizations? Most of your overrides have no effect at all, and a few of them make your code larger.


This is a very valid question. Every instruction is thought-out when it comes to length and all those longer instructions are used just because their longer lengths. If you look at the binary code, you will see a few patterns that make it like thoroughly signed by me. This is just how it is.

Octocontrabass wrote:
a few other space-wasters in your code, such as a far jump when CS is already a known value, and a CS segment override when the default segment has the same value as CS.


That CS override is a bit unelegant but please note that the next instructions are very space inefficient too. There is a lot of room to make some small changes (and possible bug fixes that are usually just a very few bytes) without collapsing the overall binary structure of this sector.

Octocontrabass wrote:
Your code for LBA to CHS conversion doesn't handle more than 256 cylinders.


This was a design choice and should probably be mentioned on the feature list. Please note that it does handle it: an error message with very defined behavior.

Thank you very much for your comments. Any bugs? :D

_________________
Undefined behavior since 2012


Top
 Profile  
 
 Post subject: Re: General Master Boot Record
PostPosted: Mon Sep 11, 2017 9:46 am 
Offline
Member
Member

Joined: Thu Jul 05, 2012 5:12 am
Posts: 841
Location: Finland
My previous reply could be interpreted so that there is a tone of underestimation but I really try to avoid giving that impression. I take all the feedback seriously, listen to users (it does not matter whether there actually are users or not) and support all the software I release unless specifically announced otherwise.

The stylistic notes were very valid but I am not sure there existed an answer that rationalized the way things were implemented in a way that makes controversy disappear altogether. May I give an example? After releasing the first version, I started to think about tiny improvements for the next "merge window" if there were bugs that make it necassary to release the next version in the first place.

For the next version there will be two things on my list:

  • Clear the boot partition signature area in the buffer before making the read calls.
  • Clear register cx before getting the drive geometry. This will catch the error if the call does not modify it.

Both of these changes fit well in the code and take advantage of these so called "reserved" bytes, i.e. space inefficient instructions.

However, let's imagine a situation that someone actually started using the first release I made. Do I release an updated version every day and make it very confusing, e.g. was the first version useless and do I have to update my installer that embedded the code in it?

The current version has the exact same bytes than the first released version. It has no bugs as far as I know (and I asked for checking if someone else finds ones) and I think there should be a threshold so new versions are not released without good reasons. Of course, I will implement the things listed above but it would be good to have those changes in the same "merge window" so that there will be only a few different versions in use.

Please note that all this is just theoretical thinking but small things may scale to bigger things as far attitude is concerned.


EDIT: Of course this was not marked as "stable" but that is just because I am just learning this process... :D

_________________
Undefined behavior since 2012


Top
 Profile  
 
 Post subject: Re: General Master Boot Record
PostPosted: Tue Sep 12, 2017 12:57 pm 
Offline
Member
Member
User avatar

Joined: Thu Nov 03, 2011 9:30 am
Posts: 141
Antti,

I find your approach interesting (in a very good way) and inspiring. Keep doing what you do. I personally hope to get some ideas from your code and, again, your approach.

Good luck with your endeavor.

_________________
https://sandras-simanauskas.github.io/


Top
 Profile  
 
 Post subject: Re: General Master Boot Record
PostPosted: Tue Sep 12, 2017 1:09 pm 
Offline
Member
Member

Joined: Tue Mar 04, 2014 5:27 am
Posts: 803
Antti wrote:
Comments?


It would be nice to have a description of what this is and what it does.


Top
 Profile  
 
 Post subject: Re: General Master Boot Record
PostPosted: Tue Sep 12, 2017 1:55 pm 
Offline
Member
Member

Joined: Thu Jul 05, 2012 5:12 am
Posts: 841
Location: Finland
sandras wrote:
Good luck with your endeavor.


Thank you very much. I don't think my OSDev path has been very optimal so far. Perhaps I made the beginner mistake and "wrote a boot loader" without a good reason and have spent a way too much time on it. I have a somewhat feature-complete boot loader (about 32 KiB and I can guarantee that is quite a lot of assembly even with some data) that prepares the system for the next firmware-independent stages. I have to carefully think about how to release it (a binary blob or open source). A way too much attention could be paid to source code and perhaps my work of trying to ensure it could be a usable and stable product is overlooked.

Features like the next ones listed have teached quite a lot things in general:

  • Having little "process-like" stages in the boot loader.
  • Unicode support (partial), fonts, etc.
  • VESA video modes, buffering, color formats, etc.
  • Memory map sorting and handling in general. Gapless...
  • Basic "boilerplate", A20 gate, etc.
  • Serial ports, keyboard for interactive features.
  • Long mode, protected mode, and real mode. Back and forth.
  • Boot loader API for the next firmware-independent stages (that still depend on firmware but details are abstracted).
  • Defensive programming. Checksums, CRC-32 etc.

It is just a "reinvention of wheel" and it is better never claim anything else. With this released MBR I paved the way so it is not so big a step to release something more. Perhaps I am not ready to take the critique for the whole work yet.

_________________
Undefined behavior since 2012


Top
 Profile  
 
 Post subject: Re: General Master Boot Record
PostPosted: Tue Sep 12, 2017 2:09 pm 
Offline
Member
Member

Joined: Thu Jul 05, 2012 5:12 am
Posts: 841
Location: Finland
alexfru wrote:
It would be nice to have a description of what this is and what it does.


You are right. I try to work on that and write some kind of formal description. As an informal description, I would say that it does "what a volume boot record should depend on" and this is mostly a de facto standard. This is not part of any OS.

_________________
Undefined behavior since 2012


Top
 Profile  
 
 Post subject: Re: General Master Boot Record
PostPosted: Wed Sep 13, 2017 1:16 pm 
Offline
Member
Member

Joined: Thu Jul 05, 2012 5:12 am
Posts: 841
Location: Finland
I just released the next version which is (I hope so) the final version. Those who were interested in checking the first version, I recommend checking this latest revision. There are verbose comments that should explain the latest modifications.

_________________
Undefined behavior since 2012


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 9 posts ] 

All times are UTC - 6 hours


Who is online

Users browsing this forum: No registered users and 3 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group