An attempt in writing an OS.
Aharon Lavie
Finally, I decided to make an attempt to write an operating system. As
my first step, I decided to write an MBR that would let me switch
between the development platform and the operating system under
development. It works. Upon booting, a panel on the screen offers the
choice between booting either operating systems. At present, the one I
am developing just displays a panel indicating the that OS is not yet
operational, and returns to the MBR after a key is pressed. So far it
contains only a few control data structures which I have already
designed and implemented.
Here is my question. The code in the MBR is tightly crowded in the 512
bytes available in the first sector. There is not enough room to carry
all the tests I would like to perform in there. Is there any reason
why I should not use for MBR extension some of the sectors following
the MBR sector in the first cylinder? Why not make use of this wasted
space?
Benjamin David Lunt
"Aharon Lavie" <sdc...@gmail.com> wrote in message
news:1ee6a5a0-e050-4ac6...@o33g2000vbu.googlegroups.com...
Hi Aharon,
The advantage of creating your own MBR is that you can reserve
as much space as you would like. For example, traditionally,
the MBR would have each partition start on a cylinder boundary.
This leaves 62 sectors reserved after the MBR. If 62 sectors
are not enough for you, you can simply jump to the next cylinder.
There is nothing wrong with doing this. Each operating system
installed should be partition independent. i.e.: it should
not matter where on the disk, physically, it starts.
On another note, you may want to take into consideration that
in the (near) future, disk manufacturers will start to have
disk drives with larger sectors. For example, the 512 byte
sector will be a thing of the past. Therefore, you may
want to make sure that your MBR starts each partition on
a 4k boundary.
He is a reference
http://support.microsoft.com/kb/923332
Ben
P.S. Most modern disks now already have larger disk sectors.
However, they internally take care of the calculation and
only show to the system, 512-byte sectors. The disk manufacturers
are going to rid this calculation from their firmware for
faster and easier disk I/O.
--
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Forever Young Software
http://www.frontiernet.net/~fys/index.htm
http://www.frontiernet.net/~fys/collections.htm
To reply by email, please remove the zzzzzz's
Batteries not included, some assembly required.
BGB / cr88192
"Aharon Lavie" <sdc...@gmail.com> wrote in message
news:1ee6a5a0-e050-4ac6...@o33g2000vbu.googlegroups.com...
>
AFAIK this is what is often done by multiboot loaders, such as LILO or GRUB.
under usual partitioning one has all of the first cylinder available, which
allows for around 8MB.
personally though, I will state that I have some personal uncertainty as to
whether it is actually a good idea to put ones' OS bootloader in the MBR,
for the primary reason that this conflicts with other OS's (it is bad enough
that LILO and GRUB do this). more so, doing so would risk creating lots of
trouble for, say, someone who wanted Linux and 'this other OS' on the same
system.
my personal recommendation is then, either:
use GRUB as the bootloader (secondary, actually);
make use of a bootloader which goes in the first sector of the partition
(this could itself optionally be a multiboot loader if needed).
just in case you are not aware, something like QEMU or Bochs could be fairly
useful for OS-dev work. it could be less effort than the "endlessly
rebooting a spare PC" route (well, and makes it a little easier to quickly
get ones' files into the OS image, vs my case where I had been mostly using
3.5's for the bootloader and kernel...).
BGB / cr88192
"Benjamin David Lunt" <zf...@frontiernet.net> wrote in message
news:FqQSm.2766$ha3...@newsfe19.iad...
>
> "Aharon Lavie" <sdc...@gmail.com> wrote in message
> news:1ee6a5a0-e050-4ac6...@o33g2000vbu.googlegroups.com...
>>
>> Finally, I decided to make an attempt to write an operating system. As
>> my first step, I decided to write an MBR that would let me switch
>> between the development platform and the operating system under
>> development. It works. Upon booting, a panel on the screen offers the
>> choice between booting either operating systems. At present, the one I
>> am developing just displays a panel indicating the that OS is not yet
>> operational, and returns to the MBR after a key is pressed. So far it
>> contains only a few control data structures which I have already
>> designed and implemented.
>>
>> Here is my question. The code in the MBR is tightly crowded in the 512
>> bytes available in the first sector. There is not enough room to carry
>> all the tests I would like to perform in there. Is there any reason
>> why I should not use for MBR extension some of the sectors following
>> the MBR sector in the first cylinder? Why not make use of this wasted
>> space?
>
> Hi Aharon,
>
> The advantage of creating your own MBR is that you can reserve
> as much space as you would like. For example, traditionally,
> the MBR would have each partition start on a cylinder boundary.
>
> This leaves 62 sectors reserved after the MBR. If 62 sectors
> are not enough for you, you can simply jump to the next cylinder.
>
agreed, however, if we note that the typical (simulated) disk geometry is:
CHS: *x255x63
this leaves 255*63-1 sectors, which is right around 8MB...
there should not be any real need to have to start the first partition
anywhere but cylinder 1, unless of course one wants to try to cram a whole
OS in the MBR or something...
granted...
all this assumes that one is not using EFI, since EFI may put their own
partition table/... here.
> There is nothing wrong with doing this. Each operating system
> installed should be partition independent. i.e.: it should
> not matter where on the disk, physically, it starts.
>
granted, it does mean that one would have to partition a drive for said OS,
which may not be all that realistic for the most part (such as installing it
on a drive which already has another OS installed, ...).
> On another note, you may want to take into consideration that
> in the (near) future, disk manufacturers will start to have
> disk drives with larger sectors. For example, the 512 byte
> sector will be a thing of the past. Therefore, you may
> want to make sure that your MBR starts each partition on
> a 4k boundary.
>
> He is a reference
> http://support.microsoft.com/kb/923332
>
yep, another nail in the coffin for MS-DOS compatibility...
then it is left to the BIOS to also fake 512 byte sectors if anyone should
dare try to use DOS.
> Ben
>
> P.S. Most modern disks now already have larger disk sectors.
> However, they internally take care of the calculation and
> only show to the system, 512-byte sectors. The disk manufacturers
> are going to rid this calculation from their firmware for
> faster and easier disk I/O.
>
granted...
and maybe we can also get rid of this damn old MS-DOS style partition table
in the process?...
like, say, finally move to EFI partitioning?...
well, I know at least XP did not support EFI partitioning (Linux did, last I
tried using it).
dunno, I have not seen if it would work with newer Windows...
I sure hope though that we don't end up with some sort of inter-OS
partition-table incompatibility war (of a similar nature to the current
filesystem wars...).
hell, back when I wrote my OS, I used FAT-32, and it worked fairly well...
(I had on-off considered building another layer of filesystem machinery on
top of FAT-32, but had not done so...).
hmm:
it would be amussing if there were a "FAT32+", which could address a few of
FAT32's limitations via hackishly adding some extended metadata, while still
being (mostly) compatible (sort of like how LFN's were added so long
ago...).
(the main uncertainty is for very large drives, where there is a risk of
either needing to fudge with the basic means of managing clusters, or
breaking compatibility...).
I guess there is another possible (unexplored) hack:
the possibility of "filesystem chaining", where the limit is expanded via a
hack involving putting multiple FAT32-like images end-to-end, and so a
normal FS driver would only see the first image, but not the later images.
for example, if the drive were broken into a sequence of 128GB or 1TB or
such pseudo images, with the "actual" filesystem being spread between
them... (if a huge drive is used, a normal FS driver in an unaware OS may
then fail to see much of the drives' contents).
or such...
Rod Pemberton
news:1ee6a5a0-e050-4ac6...@o33g2000vbu.googlegroups.com...
>
> bytes available in the first sector.
Yup.
> There is not enough room to carry
> all the tests I would like to perform in there.
Like what? Well, I don't really need to know. I'm just interested in how
much stuff you're trying to put in there. If you're using a Multi-boot
loader as a reference, you need to load the OS, call some BIOS calls to get
the memory or video mode etc., setup minimal PM, and call your OS.
Technically, your OS can do the memory or video mode stuff too, as well as a
more complete PM setup. I.e., load the OS, minimal PM switch, call the OS.
Why? So that you can avoid writing a bootloader so that you can code your
OS... (I'm not sure if even a minimal startup like that will fit in 512b.
You'd probably need to ask Ben or Alex etc... It might be a good Hugi
compo.)
Rod Pemberton
BGB / cr88192
"Rod Pemberton" <do_no...@nohavenot.cmm> wrote in message
news:hfhdsg$ia1$1...@aioe.org...
I have seen it done before (getting the kernel both loaded and doing the PM
switch in 512 bytes).
back when I wrote an OS though, I didn't do this, and instead loaded 2
files:
the kernel and a 'setup' file, the latter of which served to both set up PM,
and also to serve as a mechanism for mode-hopping (mostly used to access
VESA).
>
> Rod Pemberton
>
>
Aharon Lavie
wrote:
> "Aharon Lavie" <sdcs...@gmail.com> wrote in message
> To reply by email, please remove the zzzzzz's
>
>
> - Show quoted text -
Hi Ben,
Thank you very much for answering my question. I know about all those
unused sectors which follow the MBR, but I was not sure whether or not
there is any reason not to use them. I vaguely remember reading
somewhere long time ago a warning against using this storage and I was
wandering why.
I do not need all these sectors. I believe that one additional sector
would suffice. Maybe two, but very unlikely. Available space may be
used recklessly, of course, but I prefer to be conservative.
Thank you very much for alerting me to the new hard drives with sector
size other than 512 bytes. This is a serious concern for existing
operating systems which use hardcoded 512 sector size, but for me it
is only a timely warning. Since the development of my operating system
is in a very early stage, it is easy to test the sector size by means
of INT 13H with 48H in AH, and assign buffers according to the
reported sector size. By the way, such a test is an example for one
possible answer to Ron Pemberton's question ("Like what?").
Thanks again.
Aharon Lavie
> "Aharon Lavie" <sdcs...@gmail.com> wrote in message
>
> - Show quoted text -
Thank you very much for answering my question, and for your extensive
comments.
Aharon Lavie
> "Aharon Lavie" <sdcs...@gmail.com> wrote in message
Ron,
I appreciate your posting. I would have appreciate it even more had
you simply answered my question whether there a reason why I should
not use the sectors following the MBR. Instead you ponder
unnecessarily about what I am doing in the MBR.
You say you do not really need to know. You are right. For a
straightforward answer to my question there is no need for you to know
what I am doing there. Yet, strangely enough, you make wrong
assumptions about exactly what you yourself say you do not need to
know, then you blast me for your own false fantasies. Isn't that
weird?
I read many of your postings elsewhere and I like most of them. Too
bad I cannot say the same about this one which you address to me. I
have high regards for your demonstrated ability as a software
developer. I hope and wish that future communication between us will
be friendlier and more constructive.
Alexei A. Frounze
> > To reply by email, please remove the zzzzzz's
>
> > Batteries not included, some assembly required.- Hide quoted text -
>
> > - Show quoted text -
>
> Hi Ben,
>
> Thank you very much for answering my question. I know about all those
> unused sectors which follow the MBR, but I was not sure whether or not
> there is any reason not to use them. I vaguely remember reading
> somewhere long time ago a warning against using this storage and I was
> wandering why.
>
> I do not need all these sectors. I believe that one additional sector
> would suffice. Maybe two, but very unlikely. Available space may be
> used recklessly, of course, but I prefer to be conservative.
>
> Thank you very much for alerting me to the new hard drives with sector
> size other than 512 bytes. This is a serious concern for existing
> operating systems which use hardcoded 512 sector size, but for me it
> is only a timely warning. Since the development of my operating system
> is in a very early stage, it is easy to test the sector size by means
> of INT 13H with 48H in AH, and assign buffers according to the
> reported sector size. By the way, such a test is an example for one
> possible answer to Ron Pemberton's question ("Like what?").
>
> Thanks again.
I once did fit a FAT32 file loader into 512 bytes of the boot sector
(not the MBR itself, but the sector the MBR loads). Pretty tough, but
not impossible.
Alex
Rod Pemberton
> I would have appreciate it even more had
> you simply answered my question whether there a reason why I should
> not use the sectors following the MBR.
Sure... As I see it, you can format or structure the blank tracks on the
disk anyway you like. Is it worthwhile to design and implement your own
filesystem? Well, that's debatable. It'll be more work if you chose to
design your own, obviously. So, is there a problem using the sectors
following the MBR, only if your use of them clashes with the existing design
use of them in the filesystem you're using. Do I know which filesystems
would cause a problem if this is done? No. Do I know which filesystem
you're using? No. So, I had no answer for you.
> You say you do not really need to know. You are right. For a
> straightforward answer to my question there is no need for you to know
> what I am doing there.
Sorry, I didn't believe I had any real input on the original question.
Threads often spark interest into more interesting questions. I wouldn't
take offense. I didn't mean to sidetrack your discussion. There are enough
people around who have experience or an answer on your question, who
could've posted. Some of them did. And, the amount of discussion has
dropped off lately. I wanted something of interest to me to discuss.
> Yet, strangely enough, you make wrong
> assumptions about exactly what you yourself say you do not need to
> know,
You asked why you shouldn't use the sectors following the MBR, but you
didn't provide ample scope as to why you _need_ to use the sectors following
the MBR. I don't really see the two issues as entirely independent. From
which, my statements arose.
> then you blast me for your own false fantasies.
My point was: Where do you want to spend the time you have? Do you want to
spend it coding your OS, or spend it coding a bootloader? IMO, people may
use your OS if they like it, but few will use your bootloader. If on your
OS, then there is no point in coding a larger, more complicated bootloader.
It seems you took my comments rather personally, instead of constructively.
Rereading my comments, I don't see me "blasting you" due to "fantasy"
anywhere. I did make assumptions based on my knowledge and experience,
since you shared none of your own.
Rod Pemberton
Benjamin David Lunt
>>>>>>>>>>>>>>>>>>>>>>>
Hi Ben,
Thank you very much for answering my question. I know about all those
unused sectors which follow the MBR, but I was not sure whether or not
there is any reason not to use them. I vaguely remember reading
somewhere long time ago a warning against using this storage and I was
wandering why.
I do not need all these sectors. I believe that one additional sector
would suffice. Maybe two, but very unlikely. Available space may be
used recklessly, of course, but I prefer to be conservative.
Thank you very much for alerting me to the new hard drives with sector
size other than 512 bytes. This is a serious concern for existing
operating systems which use hardcoded 512 sector size, but for me it
is only a timely warning. Since the development of my operating system
is in a very early stage, it is easy to test the sector size by means
of INT 13H with 48H in AH, and assign buffers according to the
reported sector size. By the way, such a test is an example for one
possible answer to Ron Pemberton's question ("Like what?").
Thanks again.
<<<<<<<<<<<<<<<<<<<<<<<
Long ago, when the BIOS had the 512meg limit with CHS addressing,
Micro House came out with a product called EZ-Drive which hooked
into the INT 13h vector and caught all disk access (larger than
512meg) [1] and used LBA addressing. By doing so, it created a
MBR with a single entry pointing to LBA 1 (the second sector of
the disk) which had an "EZ-Drive MBR" which pointed to 1 or more
partitions.
If you had EZ-Drive installed, then yes, your MBR could not use
the second sector of the disk. However, since about 1999 (?)
BIOS' have had extended services to read larger disks.
As stated before, usually the only code you should have in
the MBR is code to find the active partition and load its
boot sector. Nothing more.
Then, in the partition's boot sector, you can start your
setup code. If your code needs more than one sector, then
the first part of your code would load the remaining sector(s).
One thing to remember, and it is very important, make sure
your read_sector() function is in the first sector already
loaded by the MBR code. If your read_sector() function is
past the 512 byte point and you call it to read in the next
sector(s), you won't get the results you expected.
As Alex stated, he has made a FAT32 boot sector in 512 bytes.
It is difficult, but can be done. My FAT32 boot takes just
more than 2 sectors, but I do a bit of error checking and
print progress messages. However, since it is more than
1 sector, I must load the remaining 2 sectors as stated
above.
Rod (not Ron) mentioned that you may want to forget about
the boot code and go directly to the kernel, letting a boot
loader such as Grub do the boot for you. He has a good point.
Where do you want to put your efforts? However, and this
is only my opinion, others have different opinions include
Rod, I learned quite a bit and enjoyed writing boot sectors
for many filesystems.
I suggest this:
- Write a MBR that *only* finds the active partition and
loads the first sector of that partition to 0x07C00.
There is plenty of space to do this and print an error
message if no active partition is found.
*be sure* to move this code from 0x07C00 to another location
before you load the partition sector, or your MBR's read_sector()
function may not return to where you expected it to.
- Write a partition boot sector. This can then load
numerous other sectors. Have this partition boot sector
load enough sectors (2 or 3 more) to have enough code
to load a "setup" file from the filesystem. Meaning,
this partition boot sector would need enough space to
have a minimal filesystem driver and print errors
if any found. The minimal filesystem driver would only
need to be read-only.
- Then write a "setup" program that could reside anywhere
within the volume of the partition. This file can be
of any size and do anything you like.
The FYSOS boot process is as such:
- MBR: Any mbr as long as one of the entries point to
the FYSOS partition and is active.
- Partition boot: 1 to 3 sectors depending on the filesystem.
The only thing it does is load "LOADER.SYS" from the volume,
using a read-only filesystem driver, and printing errors
if any found. I have multiple filesystem boot loaders.
Unlike the loader.sys file below, you do not need to have
your partition sector multi-filesystem dependant. The
boot sector will be dependant of the filesystem installed.
The loader.sys file may not be.
- LOADER.SYS:
- A complete read-only filesystem driver for the following
filesystems: FAT12, FAT16, FAT32, LEANFS, Ext2, FYSFS, and
one other that I can't quite remember. This is so that I
can have any (supported) filesystem installed and only have
one loader.sys file to build.
- Contains a list of files to load, where each file contains
a header stating where to load and if compressed/encrypted.
- moves to unreal mode
- Loads each file (using the bios large disk extensions)
- if compressed, contains a complete BZ2 decompressor to
decompress to physical memory.
- A few other items such as:
- get date and time from cmos
- get memory map from BIOS
- get other misc BIOS/CMOS info before moving to pmode
- setup a flat address space
- Move to Protected mode
- jump to kernel.sys
Others may have other ideas and may not be wrong, but in my opinion
this is a traditional setup. Your loader.sys file doesn't have
to have multiple filesystem drivers. You can place #define's in
the code and simply change a #define and rebuild for each filesystem.
Also, my partition boot sector passes information to loader.sys
such as base lba of partition and filesystem installed.
Hope this helps,
Ben
[1] I wonder. I never checked. Did EZ-Drive catch all disk
access, or did it let any access less than the 512meg limit
just fall through to the BIOS?
BGB / cr88192
"Benjamin David Lunt" <zf...@frontiernet.net> wrote in message
news:SEaTm.35707$kY2....@newsfe01.iad...
in my case, I usually end up using deflate for most everything.
if I were doing a loader, I might consider either plain LZ77, or LZ77 with a
simplified PAQ-style arithmetic coder, mostly as these can be done in less
bytes if needed (LZ77 takes fairly little code if using linear-buffer
decompression, and PAQ-style arithmetic coding also uses a fairly small
amount of code, and a variant I had used had also used fairly little memory
as well).
I guess the main downside with plain LZ77 is that the ratio is not very good
(but the decompressor is very simple, and very fast). LZSS was an example of
this variety.
my PAQ variant lost out in my case, because I could not get it to be as fast
as I could get static huffman (which at the time was fairly important to
me).
similarly, at the time I had also messed with BWT, but speed was rather weak
vs LZ77, and personally I was not seeing enough of an improvement in ratios
to be worth the speed loss.
so, eventually I settled on using Deflate for most things (LZ77 + static
huffman), although for some of my own stuff I use a deflate variant known as
Deflate64 (basically, deflate with a 64kB window).
but then I have noticed recently that there is a bug somewhere in my
deflater, and I have not been able to track it down (not that I have tried
agressively, mostly as it has been popping up when producing PNG's, and so
it is a matter of spotting the occasional fouled-up PNG and fixing it
manually...), where every so often it will apparently make a false match and
generate fouled-up results... (and does not seem to manifest much with
higher-density data, mostly just large very-compressible PNG's...).
> Others may have other ideas and may not be wrong, but in my opinion
> this is a traditional setup. Your loader.sys file doesn't have
> to have multiple filesystem drivers. You can place #define's in
> the code and simply change a #define and rebuild for each filesystem.
>
> Also, my partition boot sector passes information to loader.sys
> such as base lba of partition and filesystem installed.
>
> Hope this helps,
> Ben
>
>
> [1] I wonder. I never checked. Did EZ-Drive catch all disk
> access, or did it let any access less than the 512meg limit
> just fall through to the BIOS?
>
I am pretty sure it caught all accesses, as it was the originator of the CHS
1024x255x63 geometry.
the BIOS'es of the time typically only did a 1024x16x63 (hence the 512 MB
limit).
the new geometry essentially increased the limit to 8.4 GB.
now, why it would probably have to catch all accesses:
do you expect the plain BIOS to know what to do with requests with 255
heads, when it itself claims there are only 16?...
so, presumably, it caught all of them.
I think ATA itself had a limit of 16384x16x63 with CHS geometry, so it was
mostly redistibuting bits I think. that, or, by using LBA, which allowed
2^28 sectors, or 128GB, where this limit was in turn broken by "double
pumping" the drive (sending multiple requests at a time with different parts
of the block address in the requests).
I don't know much about how SATA does things, as I have been "out of the
game" for a while.
however, a quick calculation shows the limit of the double-pump strategy to
be around 32M TB, or around 32EB.
or such...
>
Maxim S. Shatskih
> tried using it).
> dunno, I have not seen if it would work with newer Windows...
GPT is the mainstream future, EFI is exotic.
Nevertheless, most modern disks are by default MBR, and GPT is rarely used.
--
Maxim S. Shatskih
Windows DDK MVP
ma...@storagecraft.com
http://www.storagecraft.com
Maxim S. Shatskih
>there is any reason not to use them.
Imagine there are 2 products which use them.
s_dub...@yahoo.com
[snip]
> Here is my question. The code in the MBR is tightly crowded in the 512
> bytes available in the first sector. There is not enough room to carry
> all the tests I would like to perform in there. Is there any reason
> why I should not use for MBR extension some of the sectors following
> the MBR sector in the first cylinder?
Yes, I have examples of MBR partitions where there is no such space.
>Why not make use of this wasted
> space?
For you, for your HD, go ahead. As a matter of convention, no.
In addition to what Maxim says..
http://en.wikipedia.org/wiki/GUID_Partition_Table
I fully agree with what Ben has said about the purpose of the MBR.
You can credit IBM for the MBR convention, they also set the
convention for the original floppy drives as well. You can also
credit them with 'menu boot selection' as a matter of policy, with the
introduction of OS/2.
Sometimes, that 'extra' space is used by partition manager software,
as Ben has said. OnTrack, was another company which did this not only
to overcome limitations of the RomBios but also limitations in the
OS. Overwrite this area
and you'll lose all access to the data on the drive.
The MBR is not the boot sector of your OS. The first sector of your
OS's partition should be the bootsector of your OS.
Also, keep in mind that the HD may be moved to other hardware, I have
done this often, so keep assumptions generic and few. Let your boot
sector load secondary boot code, either in additional sectors or in a
file, and let the SBC detect the specifics you are after for your OS's
runtime. jmho.
Steve
Benjamin David Lunt
"BGB / cr88192" <cr8...@hotmail.com> wrote in message
news:hfjj83$bi3$1...@news.albasani.net...
>
> in my case, I usually end up using deflate for most everything.
> if I were doing a loader, I might consider either plain LZ77, or LZ77 with
> a simplified PAQ-style arithmetic coder, mostly as these can be done in
> less bytes if needed (LZ77 takes fairly little code if using linear-buffer
> decompression, and PAQ-style arithmetic coding also uses a fairly small
> amount of code, and a variant I had used had also used fairly little
> memory as well).
>
> I guess the main downside with plain LZ77 is that the ratio is not very
> good (but the decompressor is very simple, and very fast). LZSS was an
> example of this variety.
>
> my PAQ variant lost out in my case, because I could not get it to be as
> fast as I could get static huffman (which at the time was fairly important
> to me).
>
> similarly, at the time I had also messed with BWT, but speed was rather
> weak vs LZ77, and personally I was not seeing enough of an improvement in
> ratios to be worth the speed loss.
>
> so, eventually I settled on using Deflate for most things (LZ77 + static
> huffman), although for some of my own stuff I use a deflate variant known
> as Deflate64 (basically, deflate with a 64kB window).
I used bz2 at the time, since I was interested in how it worked.
I haven't spent much time on another form yet, though I may.
Isn't LZ77 and variants patented in some way or another? I think
this is why a stayed away from them.
>> [1] I wonder. I never checked. Did EZ-Drive catch all disk
>> access, or did it let any access less than the 512meg limit
>> just fall through to the BIOS?
>>
>
> I am pretty sure it caught all accesses, as it was the originator of the
> CHS 1024x255x63 geometry.
> the BIOS'es of the time typically only did a 1024x16x63 (hence the 512 MB
> limit).
> the new geometry essentially increased the limit to 8.4 GB.
>
> now, why it would probably have to catch all accesses:
> do you expect the plain BIOS to know what to do with requests with 255
> heads, when it itself claims there are only 16?...
(smile) No, I meant if the CHS passed via the INT 13h call was within
1023x15x63, would it just pass it along? No need to really I guess.
> so, presumably, it caught all of them.
>
> I think ATA itself had a limit of 16384x16x63 with CHS geometry, so it was
> mostly redistibuting bits I think. that, or, by using LBA, which allowed
> 2^28 sectors, or 128GB, where this limit was in turn broken by "double
> pumping" the drive (sending multiple requests at a time with different
> parts of the block address in the requests).
>
> I don't know much about how SATA does things, as I have been "out of the
> game" for a while.
>
> however, a quick calculation shows the limit of the double-pump strategy
> to be around 32M TB, or around 32EB.
>
> or such...
I haven't done much with the SATA either. The specs say that it is
ATA-x compatible until you "enable" it. I got as far as "ATA_RECAL"
and the SATA drive froze. I haven't looked into why yet. Sometime
I will get back to it.
Thanks,
Ben
BGB / cr88192
"Maxim S. Shatskih" <ma...@storagecraft.com.no.spam> wrote in message
news:hfjmmr$12kg$1...@news.mtu.ru...
> well, I know at least XP did not support EFI partitioning (Linux did, last
> I
> tried using it).
> dunno, I have not seen if it would work with newer Windows...
<--
GPT is the mainstream future, EFI is exotic.
Nevertheless, most modern disks are by default MBR, and GPT is rarely used.
-->
GPT was part of EFI, and was essentially what was meant by "EFI
partitioning"...
either way, WinXP didn't support it last I tried using it, but more modern
Windows may have added supprt...
anyways, EFI is not that rare, as a while back I got a laptop which
apparently uses an EFI BIOS (oddly enough, it was a Netbook...).
or such...
BGB / cr88192
>
> "BGB / cr88192" <cr8...@hotmail.com> wrote in message
> news:hfjj83$bi3$1...@news.albasani.net...
>>
>> in my case, I usually end up using deflate for most everything.
>> if I were doing a loader, I might consider either plain LZ77, or LZ77
>> with a simplified PAQ-style arithmetic coder, mostly as these can be done
>> in less bytes if needed (LZ77 takes fairly little code if using
>> linear-buffer decompression, and PAQ-style arithmetic coding also uses a
>> fairly small amount of code, and a variant I had used had also used
>> fairly little memory as well).
>>
>> I guess the main downside with plain LZ77 is that the ratio is not very
>> good (but the decompressor is very simple, and very fast). LZSS was an
>> example of this variety.
>>
>> my PAQ variant lost out in my case, because I could not get it to be as
>> fast as I could get static huffman (which at the time was fairly
>> important to me).
>>
>> similarly, at the time I had also messed with BWT, but speed was rather
>> weak vs LZ77, and personally I was not seeing enough of an improvement in
>> ratios to be worth the speed loss.
>>
>> so, eventually I settled on using Deflate for most things (LZ77 + static
>> huffman), although for some of my own stuff I use a deflate variant known
>> as Deflate64 (basically, deflate with a 64kB window).
>
> I used bz2 at the time, since I was interested in how it worked.
> I haven't spent much time on another form yet, though I may.
>
fair enough (just for my uses, it was slower than deflate is all, and my
concern at the time had been doing compression/decompression in a soft
real-time setting, where a slower decompressor would lead to possible
delays...).
another factor was that deflate is much more commonly used, for example, it
was needed for things like ZIP and PNG, which I also use a lot, so this was
also a deciding factor...
> Isn't LZ77 and variants patented in some way or another? I think
> this is why a stayed away from them.
>
LZW was patented, but the patent has since expired (some-odd years back).
LZ77 is not under patent, and has been free for a fairly long time.
Deflate is the most common form in which it is used, and is used in things
such as:
ZIP, GZIP, PNG, ...
>>> [1] I wonder. I never checked. Did EZ-Drive catch all disk
>>> access, or did it let any access less than the 512meg limit
>>> just fall through to the BIOS?
>>>
>>
>> I am pretty sure it caught all accesses, as it was the originator of the
>> CHS 1024x255x63 geometry.
>> the BIOS'es of the time typically only did a 1024x16x63 (hence the 512 MB
>> limit).
>> the new geometry essentially increased the limit to 8.4 GB.
>>
>> now, why it would probably have to catch all accesses:
>> do you expect the plain BIOS to know what to do with requests with 255
>> heads, when it itself claims there are only 16?...
>
> (smile) No, I meant if the CHS passed via the INT 13h call was within
> 1023x15x63, would it just pass it along? No need to really I guess.
>
probably not, since this would have lead to the situation in LBA terms where
data was spread out all over the disk, whereas the design preserved a linear
relationship between CHS and LBA sectors.
(C*255+H)*63+S != (C*16+H)*63+S
CHS: 1x0x1 would be a different LBA addr in the 2 modes:
16066 != 1009
>> so, presumably, it caught all of them.
>>
>> I think ATA itself had a limit of 16384x16x63 with CHS geometry, so it
>> was mostly redistibuting bits I think. that, or, by using LBA, which
>> allowed 2^28 sectors, or 128GB, where this limit was in turn broken by
>> "double pumping" the drive (sending multiple requests at a time with
>> different parts of the block address in the requests).
>>
>> I don't know much about how SATA does things, as I have been "out of the
>> game" for a while.
>>
>> however, a quick calculation shows the limit of the double-pump strategy
>> to be around 32M TB, or around 32EB.
>>
>> or such...
>
> I haven't done much with the SATA either. The specs say that it is
> ATA-x compatible until you "enable" it. I got as far as "ATA_RECAL"
> and the SATA drive froze. I haven't looked into why yet. Sometime
> I will get back to it.
>
yeah...
I once had an experience with trying to install XP on a SATA drive and
"Windows Setup" wiped the partition table (I was like: "WTF are there no
partitions here?..."), after rebooting, the partition table was still
gone...
hence, for a while, I did not trust the Windows installer, but this has not
happened again...
> Thanks,
> Ben
>
>
Benjamin David Lunt
>
>
> LZW was patented, but the patent has since expired (some-odd years back).
>
> LZ77 is not under patent, and has been free for a fairly long time.
>
> Deflate is the most common form in which it is used, and is used in things
> such as:
> ZIP, GZIP, PNG, ...
Good to know, thanks.
Thanks again,
Ben
Alexei A. Frounze
...
LZ77
> but then I have noticed recently that there is a bug somewhere in my
> deflater, and I have not been able to track it down (not that I have tried
> agressively, mostly as it has been popping up when producing PNG's, and so
> it is a matter of spotting the occasional fouled-up PNG and fixing it
> manually...), where every so often it will apparently make a false match and
> generate fouled-up results... (and does not seem to manifest much with
> higher-density data, mostly just large very-compressible PNG's...).
Most likely you're hitting some edge condition.
You could write a test app that would generate such repeatable/well
compressable patterns and compare the result from the compression
+decompression sequence with the original.
Alex
wolfgang kern
Aharon Lavie posted:
It may depend on the primary partition types found in the MBR.
If there is an M$-aware partition, then you better don't touch this
wasted first track, because windoze may store something in there
(IIRC a copy of the MBR/BR and more), can't tell about Linux yet.
> Why not make use of this wasted space?
My OS uses only one sector to hold BR and MBR info and it wont waste
a single sector, so system code/data reside already on the first track
of the partition and are stored in fixed contiguous order which eases
the systems protection and allow standardised relative LBA-addressing
for system modules/tables/images/...(no FS nor names required here).
I'd say: just use it!
BUT (from bad experience): make sure no other OS can spoil it.
a solution to hide your partition from others is an unknown or hidden
partition type. But it will not work as long you need the tools from
the unwanted to create yours. So before I could use my own disk format,
I first had to make all the required tools to become independent from
PQmagic, DISKEDIT, DEBUG and friends.
__
wolfgang
Maxim S. Shatskih
> Windows may have added supprt...
2003 supports it for sure.
Maxim S. Shatskih
> (IIRC a copy of the MBR/BR and more), can't tell about Linux yet.
Windoze will never do this by itself, but some OEM installations on laptops really use this way.
BGB / cr88192
"Maxim S. Shatskih" <ma...@storagecraft.com.no.spam> wrote in message
> either way, WinXP didn't support it last I tried using it, but more modern
> Windows may have added supprt...
<--
2003 supports it for sure.
-->
yeah.
it seems 32-bit XP was the last OS not to support it though...
oddly, for whatever reason Windows can't boot from it according to
Wikipedia, but I am not sure the reason.
Maxim S. Shatskih
> Wikipedia
This is supported in Itanium version of Windows only.
BGB / cr88192
"Alexei A. Frounze" <alexf...@gmail.com> wrote in message
news:a6a12777-ee72-4c10...@o9g2000prg.googlegroups.com...
> but then I have noticed recently that there is a bug somewhere in my
> deflater, and I have not been able to track it down (not that I have tried
> agressively, mostly as it has been popping up when producing PNG's, and so
> it is a matter of spotting the occasional fouled-up PNG and fixing it
> manually...), where every so often it will apparently make a false match
> and
> generate fouled-up results... (and does not seem to manifest much with
> higher-density data, mostly just large very-compressible PNG's...).
<--
Most likely you're hitting some edge condition.
You could write a test app that would generate such repeatable/well
compressable patterns and compare the result from the compression
+decompression sequence with the original.
-->
I thought of this, but apart from notable instrumentation (would be a pain
to do...), this would not particularly help me find and fix the bug...
I already have a fairly good idea of around where it is, but for some reason
have not been able to identify the bug itself... (granted, if it is an edge
convention, it is possibly something very subtle...).
I did notice though that apparently the code is using a very old style of
hashing (lots of shifting and xor's) that I have since stopped using, but
likely this has little to do with the bug itself...
or such...
BGB / cr88192
"Maxim S. Shatskih" <ma...@storagecraft.com.no.spam> wrote in message
> oddly, for whatever reason Windows can't boot from it according to
> Wikipedia
<--
This is supported in Itanium version of Windows only.
-->
yeah, but it does seem a little silly though...
I guess for a "generic" bootloader, there would need to be either some way
to indicate the boot partition, or something along the lines of a multiboot
loader...
wouldn't seem like it would be too hard to pull off...
Maxim S. Shatskih
> -->
>
> yeah, but it does seem a little silly though...
I think this is because EFI BIOS is by far more complex then the usual one, and can contain half of the boot loader in it, not only int 13h path.
So, EFI bootloader can be absolutely other from the usual one. And, if MS forgot to include the GPT code in the usual boot loader, then sorry - only EFI (i.e. Itanium) machine can boot off GPT.
James Harris
> "Aharon Lavie" <sdcs...@gmail.com> wrote in message
That's a great description of how to get an OS booted from hard disk.
What about a machine with multiple hard disks? Although they should
boot the same hard disk each time (as set in the BIOS) IME they don't
always.
Any recommendations on how to reliably boot a machine with multiple
drives?
James
Alexei A. Frounze
wrote:
...
> That's a great description of how to get an OS booted from hard disk.
>
> What about a machine with multiple hard disks? Although they should
> boot the same hard disk each time (as set in the BIOS) IME they don't
> always.
What do you mean they don't always? It all depends on the boot order
and active partitions if we're talking about conventional systems (w/o
GPT/EFI).
> Any recommendations on how to reliably boot a machine with multiple
> drives?
Define reliably.
Alex
James Harris
> On Dec 9, 12:18 am, James Harris <james.harri...@googlemail.com>
> wrote:
> ...
>
> > That's a great description of how to get an OS booted from hard disk.
>
> > What about a machine with multiple hard disks? Although they should
> > boot the same hard disk each time (as set in the BIOS) IME they don't
> > always.
>
> What do you mean they don't always? It all depends on the boot order
> and active partitions if we're talking about conventional systems (w/o
> GPT/EFI).
Yes, conventional systems that have been around for decades.
>
> > Any recommendations on how to reliably boot a machine with multiple
> > drives?
>
> Define reliably.
Exhibiting to the user the same response each time.
James
Rod Pemberton
news:5a9e78e9-a76c-4cff...@m3g2000yqf.googlegroups.com...
>
> What about a machine with multiple hard disks? Although they should
> boot the same hard disk each time (as set in the BIOS) IME they don't
> always.
Except for this machine, I've never experienced that. AFAIR, they always
follow either historical Int 19h/18h BIOS order (floppy, harddisk, network,
etc.) or BIOS selected boot-order.
Unfortunately, it seems that this machine has some auto-detect feature in
the BIOS. So, if one drive doesn't recognize fast enough or drives are
switched or removed, it automatically choses some other bootable device.
The problem is that it'll chose a bootable device, even if I've got it
*disabled* in the BIOS settings. But, it won't auto-select certain devices,
even when bootable.
> Any recommendations on how to reliably boot a machine with multiple
> drives?
I'm not sure what you mean by "reliably"... Is this a flaky BIOS issue, or
MBR/bootloader issue? Your code can only take control when the BIOS has
executed it - from whatever device it selected...
If the BIOS isn't _consistently_ (not reliably?) selecting the same device
to boot, what can you do other than get a new BIOS?
Are you trying to override the BIOS first device selection? E.g., force
harddisk boot instead of floppy? E.g., force harddisk on second interface?
Is only _one_ of the devices bootable? That could be a solution...
Manually deactivate bootability on all devices. Alternately, when the
"proper" bootloader executes, it automatically disables all other found
bootable devices by overwriting their bootable code. This is *not*
something I'd recommend for normal use, but it's something that might be
done for a _secured_ system. I.e., only one way in. It'd royally mess with
bootable floppies and USB devices. Yuck. This won't fix devices not
detected at the time (unplugged or uninserted) if they are higher up in the
BIOS boot order. E.g., if a device, say floppy or USB, is bootable and your
boot sequence boots it first, you still have a problem.
Another solution might be to determine if a certain device is always
selected if bootable, e.g., floppy or USB. Or, determine if a device acts
as a fall-back bootable device, e.g., floppy or USB, when the main device
doesn't boot. You could then epoxy in a USB or floppy with your backup
bootsector. I.e., you're attempting to control the non-reliable boot order
via an alternate device.
What if you write the information for the device to boot into the first
piece of non-BIOS code to executed, i.e., the bootsector on the first
device? Is that early enough in the boot sequence to fix your problem? I
don't think so, but if it is, you could patch or block int 19h and int 18h
in your bootloader. Use lidt in real-mode to setup a IVT elsewhere. Change
the vectors in your new IVT. I.e., it's effectively locked since most real
mode code won't know the IVT is not where it's supposed to be. Such code
will attempt to modify the old table directly.
If you're looking to harden a bootloader, there is lots of stuff you can do.
IVT lockout (above), disable interrupts and NMI, disable keyboard, clear low
memory, clear memory with 0xCC (Int 03h) - to catch "into the weeds" code,
A20 off/on, etc.
Rod Pemberton
Rod Pemberton
news:hfnplu$9bq$1...@aioe.org...
> [...]
> Another solution might be to determine if a certain device is always
> selected if bootable, e.g., floppy or USB. Or, determine if a device acts
> as a fall-back bootable device, e.g., floppy or USB, when the main device
> doesn't boot. You could then epoxy in a USB or floppy with your backup
> bootsector. I.e., you're attempting to control the non-reliable boot
order
> via an alternate device.
>
Continuing with that thought, another option would be to determine if
another bootable device, e.g., floppy or USB or network, will reliably boot.
Use that as the primary boot device. USB would be preferable, especially if
pin headers are available on the motherboard. You could then mount the USB
drive and pin header cable internally. It be cheap too. A two outlet USB
port connector runs $4. Unscrew USB pin header cable from slot plate. 2GB
USB runs $7.
Rod Pemberton
wolfgang kern
Maxim S. Shatskih wrote:
...
>> wasted first track, because windoze may store something in there
>> (IIRC a copy of the MBR/BR and more), can't tell about Linux yet.
>Windoze will never do this by itself, but some OEM installations on
>laptops really use this way.
my current desktop winXP(original M$) fills at least the first 15
sectors after the MBR with several things ...
and the install prompts with 'hardware error, need format/reboot'
if there is more than one visible primary partition present.
if my memory serves me well, I think to remember an M$-paper where
sectors 4,5,6,.. are used for backup/repair/defect-mgmt/freesize/...
__
wolfgang
Maxim S. Shatskih
> sectors 4,5,6,.. are used for backup/repair/defect-mgmt/freesize/...
If you have a VM guest with Windows - try overwriting them with zeroes in the .vhd file and booting.
The disk image backup programs often do not restore these sectors in the restore path. This is optional, and everything usually works without it.
Benjamin David Lunt
"James Harris" <james.h...@googlemail.com> wrote in message
news:5a9e78e9-a76c-4cff...@m3g2000yqf.googlegroups.com...
>>>>>>>>>
That's a great description of how to get an OS booted from hard disk.
What about a machine with multiple hard disks? Although they should
boot the same hard disk each time (as set in the BIOS) IME they don't
always.
Any recommendations on how to reliably boot a machine with multiple
drives?
James
<<<<<<<<<
Hi James, and thanks.
Multiple drives could be the BIOS' concern. It will load the first
given drive's MBR. If no active partition is found, it will
move to the next drive, until an active partition is found.
However, this only works if the BIOS is programmed to do so.
I have never looked into it, so the following is only a guess,
but I think that the BIOS reads in the MBR and searches for an
active partition before loading the MBR and jumping to it.
If the BIOS doesn't find an active partition (or a valid boot
device) it moves to the next item in the list.
Again, I haven't looked in to what really happens, all I do
know is that you don't have to worry about multiple disks
if you don't want to. Let the (modern) BIOS do it.
However, you can write a Boot Manager that always has one
active partition and is always the first disk to boot. Then
you can boot what ever device/drive you wish due to stored
information or user intervention.
Therefore, let the BIOS do all the work, or make sure
that the specified device/drive is *always* the first
device to check, then write your own MBR with one active
partition which points to your boot manager.
This is probably what a good GPT/EFI system does. Makes
sure to boot the same device each time, then allowing the
GPT/EFI's boot manager to take control of which device/drive
is booted.
Anyway, I haven't looked into it much, so don't take that
as fact. It is just my idea of what may happen.
I am sure there are others that know more about it. Max?
Ben
BGB / cr88192
"Maxim S. Shatskih" <ma...@storagecraft.com.no.spam> wrote in message
> This is supported in Itanium version of Windows only.
> -->
>
> yeah, but it does seem a little silly though...
<--
I think this is because EFI BIOS is by far more complex then the usual one,
and can contain half of the boot loader in it, not only int 13h path.
So, EFI bootloader can be absolutely other from the usual one. And, if MS
forgot to include the GPT code in the usual boot loader, then sorry - only
EFI (i.e. Itanium) machine can boot off GPT.
-->
presumably there would have just been an alternate bootloader stuffed into
the MBR, which would handle GPT partitions rather than DOS-style partitions.
granted though, this would require a flag or similar to be used to identify
the active partition, that or, worse yet, a boot manager would be a standard
feature (this could require reserving a little space after the partition
table).
say, for example, if 64 sectors (or 32k) were reserved, and the MBR reads in
the partition table and boot manager code somewhere, then jumps to this.
partitions are then marked "potentially bootable", and the manager gives a
menu to choose from.
OTOH, presumably one could also just use GRUB, but I am uncertain if Windows
can boot from EFI via GRUB (probably as one of their well advised sanity
features, they will refuse to install it there, much as how Win7 will say
that it doesn't install to USB drives...).
granted, then there is Linux on USB, which will sort of work, but apparently
as soon as one tries to plug it into a different computer (or maybe if other
USB drives are added/removed), then it can no longer mount the root (I think
because it confuses the '/dev/sd*' assignment...).
(hmm, but if people knew how to use it, GPT could help reduce this issue,
since then one could look for the partition via GUID rather than by '/dev'
location or some other metric...). hmm...
in fstab:
{F00BA599-CAFE-BAAD-F00D-50F10150F101} / ext4 ...
{8EF99A76-7D5D-4F2E-8F35-C3DB5B990B39} swap swap ...
or such...
BGB / cr88192
On 9 Dec, 08:23, "Alexei A. Frounze" <alexfrun...@gmail.com> wrote:
> On Dec 9, 12:18 am, James Harris <james.harri...@googlemail.com>
> wrote:
> ...
>
> > That's a great description of how to get an OS booted from hard disk.
>
> > What about a machine with multiple hard disks? Although they should
> > boot the same hard disk each time (as set in the BIOS) IME they don't
> > always.
>
> What do you mean they don't always? It all depends on the boot order
> and active partitions if we're talking about conventional systems (w/o
> GPT/EFI).
<--
Yes, conventional systems that have been around for decades.
-->
>
> > Any recommendations on how to reliably boot a machine with multiple
> > drives?
>
> Define reliably.
<--
Exhibiting to the user the same response each time.
-->
the BIOS is stupid, and doesn't exactly 'think' a whole lot...
the simple rule of thumb:
with PATA: have your bootable drive as the primary master;
with SATA: have your bootable drive as the lowest numbered.
and make sure the BIOS isn't told to do something weird.
take note that many newer BIOS'es will try to boot USB / thumb-drives before
internal drives (sort of like with CD's and floppies), so this may make
issue if there is a USB drive with a bootable MBR plugged in at boot time.
so, if your boot drive is a slave drive, on a secondary bus, ... then there
is a possibility for wonky behavior in edge cases.
I am leaving out tertiary/... PATA busses (such as on MOBO's with "onboard
RAID", ...), as personally I have not seen a BIOS which would attempt to
boot them...
or such...
Maxim S. Shatskih
> active partition before loading the MBR and jumping to it.
This is not BIOS, this is MBR's code itself.
The BIOS can only read sector 0 of the physical disk and transfer control there.
Benjamin David Lunt
"Maxim S. Shatskih" <ma...@storagecraft.com.no.spam> wrote in message
>> but I think that the BIOS reads in the MBR and searches for an
>> active partition before loading the MBR and jumping to it.
>
>This is not BIOS, this is MBR's code itself.
>
>The BIOS can only read sector 0 of the physical disk and transfer control
> >there.
Hi Max,
If this is the case, how does a MBR code, after finding no active
partitions, either primary or extended, find and read in the MBR
of the next disk/device all in 512-(4*16)-2 bytes? I have never
seen a MBR code return to the BIOS.
Therefore, if the primary disk has no active partitions, does the
secondary disk ever get checked?
What if the primary disk doesn't have an active partition, but
the secondary disk is in the boot sequence list after the primary,
then how does the BIOS know to move to the secondary when the
primary isn't active?
Or does the MBR on the primary just quite with a message stating
that no active partitions found, halting? (Most likely this is
the case)
If this is the case, then James has a valid question.
"How does one boot from the secondary disk when there are no
active partitions on the primary disk?"
I guess this would be up to the MBR code on the primary. Should
it use more than one sector to be able to find an active partition
on another disk on the same controller, or another controller.
If it does do this, then it defeats the purpose of a MBR and
now turns into a boot manager.
This is something to think about. I have never tried it
so I don't know what happens exactly. Maybe it is worth
getting out some old drives, writing a few MBR's and testing
on various BIOS'.
Interesting.
Thanks,
Ben
Maxim S. Shatskih
> of the next disk/device all in 512-(4*16)-2 bytes?
Increment the disk number and call int 13h once more.
> Or does the MBR on the primary just quite with a message stating
> that no active partitions found, halting? (Most likely this is
> the case)
"Error loading operating system" as it was for me. The MBR code has some error messages in it.
Benjamin David Lunt
"Maxim S. Shatskih" <ma...@storagecraft.com.no.spam> wrote in message
>> partitions, either primary or extended, find and read in the MBR
>> of the next disk/device all in 512-(4*16)-2 bytes?
>
>Increment the disk number and call int 13h once more.
I was thinking of a little more work than that :-)
>> Or does the MBR on the primary just quite with a message stating
>> that no active partitions found, halting? (Most likely this is
>> the case)
>
>"Error loading operating system" as it was for me. The MBR code has
> some error messages in it.
Thanks,
Ben
Aharon Lavie
> "Aharon Lavie" <sdcs...@gmail.com> wrote in message
>
>
> > I would have appreciate it even more had
> > you simply answered my question whether there a reason why I should
> > not use the sectors following the MBR.
>
> Sure... As I see it, you can format or structure the blank tracks on the
> disk anyway you like. Is it worthwhile to design and implement your own
> filesystem? Well, that's debatable. It'll be more work if you chose to
> design your own, obviously. So, is there a problem using the sectors
> following the MBR, only if your use of them clashes with the existing design
> use of them in the filesystem you're using. Do I know which filesystems
> would cause a problem if this is done? No. Do I know which filesystem
> you're using? No. So, I had no answer for you.
>
> > You say you do not really need to know. You are right. For a
> > straightforward answer to my question there is no need for you to know
> > what I am doing there.
>
> Sorry, I didn't believe I had any real input on the original question.
> Threads often spark interest into more interesting questions. I wouldn't
> take offense. I didn't mean to sidetrack your discussion. There are enough
> people around who have experience or an answer on your question, who
> could've posted. Some of them did. And, the amount of discussion has
> dropped off lately. I wanted something of interest to me to discuss.
>
> > Yet, strangely enough, you make wrong
> > assumptions about exactly what you yourself say you do not need to
> > know,
>
> You asked why you shouldn't use the sectors following the MBR, but you
> didn't provide ample scope as to why you _need_ to use the sectors following
> the MBR. I don't really see the two issues as entirely independent. From
> which, my statements arose.
>
> > then you blast me for your own false fantasies.
>
> My point was: Where do you want to spend the time you have? Do you want to
> spend it coding your OS, or spend it coding a bootloader? IMO, people may
> use your OS if they like it, but few will use your bootloader. If on your
> OS, then there is no point in coding a larger, more complicated bootloader.
>
> It seems you took my comments rather personally, instead of constructively.
> Rereading my comments, I don't see me "blasting you" due to "fantasy"
> anywhere. I did make assumptions based on my knowledge and experience,
> since you shared none of your own.
>
> Rod Pemberton
Rod,
Even though we disagree about the interpretation of what you wrote, I
accept the simple fact that you meant it according to your
interpretation. Obviously we have different mind sets. Therefore, I
have no hard feelings whatsoever about it.
Aharon Lavie
answers, as I see the situation, indicate that since other software
packages are using this storage, and since such usage is not regulated
in any way, shape, or form, there is a danger of conflict in case a
user of such software ends up also using mine. Since, in various
responses here a number of software packages are claimed to be using
this storage, I wonder if such conflict has already been encountered
and, if so, how has the conflict been resolved.
Apparently some confusion took place here because I did not see the
need to explain my purpose for my attempt to develop my operating
system. Well, I am doing this as a learning exercise. I am in no rush
whatsoever to produce a final product. I may eventually have one, but
it is not inconceivable that none will be produced. It is important
for me to make sure that I understand what I am doing. I want to learn
form any mistake, misjudgement, or wrong decision in the process. If,
by good luck, a useful product will result from this exercise, I will
be happy to share the good news with you.
The MBR was the first lesson of this exercise. It works the way I want
it to. It is restricted to the 512 bytes in the very first sector of
the drive (LBA=0). For the time being I intend to leave it as is
within this standard single sector.
Some of you mentioned that the only responsibility of the MBR is to
load the boot sector of the operating system and pass control to it.
In my case I needed to add two more activities. One, to select the
operating system I want to boot. The other has to do with my decision
to use LBA rather than CHS for locating sectors (I used the latter in
my earlier exercises using floppies) requiring the 13H function calls
for the BIOS enhanced disk drive services (EDD). Therefore, the code
in the MBR calls INT 13H with 41H in AH to test for the availability
of the enhanced functions in the BIOS. Maybe this precaution is
excessive, but I feel that it is better to play it safe.
I like the advice given here to set in the MBR a single partition and
use it to manage the selection of the operating system to boot. I did
not think of this idea when I started the project. Should I face a
need to extend the MBR beyond the 512 bytes, I would prefer to use
this method over the use of the cylinder zero wasted space.
Next, I started developing the operating system itself by designing,
constructing and implementing its basic control data structures. This
process is in its early stages. The rest remains to be seen.
Thank again for taking your time to respond.
wolfgang kern
Benjamin David Lunt posted:
...
> Multiple drives could be the BIOS' concern. It will load the first
> given drive's MBR. If no active partition is found, it will
> move to the next drive, until an active partition is found.
I think standard BIOS doesn't check on partitions and may not even
look if 55AA is present.
BIOS only load/execute the first 512 bytes of a media (if readable),
so a boot of an all zero MBR usually ends in the wild.
It's the code in the MBR which searches for the active partition,
and it should invoke INT19h or INT13h boot_next if none is found,
even many will just tell 'missing operating system, press ...'.
I haven't checked on my latest BIOS yet, but the offered boot-options
include everthing (FD,CD,USB) regardless if bootable or not.
Yes, there are a few issues with the boot-order on some BIOS, because
not all devices may respond in time.
A workaround could be to disable boot-options except the desired one.
__
wolfgang
wolfgang kern
"Maxim S. Shatskih" wrote:
> If you have a VM guest with Windows - try overwriting them with zeroes in
> the .vhd file and booting.
> The disk image backup programs often do not restore these sectors in the
> restore path. This is optional, and everything usually works without it.
Thanks Max, I'll try it.
My problem once were just that a new XP-installation overwrote my
bootloader-extensions which were located right after the MBR.
__
wolfgang
Benjamin David Lunt
"wolfgang kern" <now...@never.at> wrote in message
news:hfqnte$bvo$1...@newsreader2.utanet.at...
>
> Benjamin David Lunt posted:
> ...
>> Multiple drives could be the BIOS' concern. It will load the first
>> given drive's MBR. If no active partition is found, it will
>> move to the next drive, until an active partition is found.
> ...
>
> I think standard BIOS doesn't check on partitions and may not even
> look if 55AA is present.
> BIOS only load/execute the first 512 bytes of a media (if readable),
> so a boot of an all zero MBR usually ends in the wild.
>
> It's the code in the MBR which searches for the active partition,
> and it should invoke INT19h or INT13h boot_next if none is found,
> even many will just tell 'missing operating system, press ...'.
After thinking about it, with your's and Max's comments, this would
be the ideal thing to do. If no active partition found, load
from the next disk and jump to it.
A few notes:
- Make sure that the disk is present. Don't just assume
that 80h + 1 is present. Yes, the BIOS will return a
carry, but it may be better to check first.
- Make sure to pass the newly updated drive in DL. Definitely
don't want to boot from 81h and have it still read from 80h.
- Also, just incrementing the drive doesn't get all of the disks.
I have seen notes were a disk will have a DL value of A0h.
Don't remember where I read that, but it may or may not be
valid. [1]
- Make sure that current_DL + 1 is the same disk type.
Example, don't try to boot a CDROM from a hard drive partition.
I guess we would have to find some way to make sure that
81h was a hard drive and not a CDROM, which could be the
next item in the boot sequence list.
- Same goes for USB flash drives.
On a different note, if you remember, I mentioned that future
drives may have larger sectors. The BIOS will need to support
larger sector sizes. I took a quick look to see if the BIOS would
return sector size for current disk. Service 48h/Int 13h will
return sector size. Most modern BIOS' should support this
service on hard drives. However, how many MBR's and boot
code hard code 512 into their boot process. i.e.: How many
support and use extended read service 42h/Int 13h and still
assume 512 byte sectors? Mine does currently. I never
thought of it until this thread. I have made a note to make
sure I modify my code. If the code uses the extended services,
it should read the sector size also. Correct?
Anyway, this is what I meant by more code than simply
incrementing DL and reading again. :-) But I am sure
you know that to Max.
Thanks guys for your comments. I will make a few notes
and have to modify my code when I get back to that portion.
Thanks,
Ben
P.S. A few more comments:
- The BIOS' I have seen, will return "not installed" when
you check for the BIOS disk extension with a DL value < 80h.
i.e.: Serve 41h will return a carry for floppy drives.
even though it is supported by the BIOS.
- MBR's only need to support 512 byte sectors. It doesn't
matter if the sector size is larger than 512, the partition
table is at 0x01BE any way. However, if the filesystem
supports larger sector sizes, and any good filesystem should,
your partition boot code should support it too. Therefore,
use service 42h/Int 13h.
Thanks guys.
[1] Went and looked. RBIL: service 48h/Int 13h:
BUGS: Several different Compaq BIOSes incorrectly report high-numbered
drives (such as 90h, B0h, D0h, and F0h) as present, giving them the same
geometry as drive 80h; as a workaround, scan through disk numbers, stopping
as soon as the number of valid drives encountered equals the value in
0040h:0075h. Dell machines using PhoenixBIOS 4.0 Release 6.0 fail to
correctly handle this function if the flag word at DS:[SI+2] is not 0000h on
entry
--
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Forever Young Software
http://www.frontiernet.net/~fys/index.htm
http://www.frontiernet.net/~fys/collections.htm
To reply by email, please remove the zzzzzz's
Batteries not included, some assembly required.
James Harris
...
> Or does the MBR on the primary just quite with a message stating
> that no active partitions found, halting? (Most likely this is
> the case)
>
> If this is the case, then James has a valid question.
Always. :-)
> "How does one boot from the secondary disk when there are no
> active partitions on the primary disk?"
But maybe not the same question. Given that machines may have multiple
disk drives I'm thinking more along the lines of, "What should an MBR
do?" If the BIOS starts the wrong MBR maybe it's better not to boot at
all than just to boot any active parition.
> I guess this would be up to the MBR code on the primary. Should
> it use more than one sector to be able to find an active partition
> on another disk on the same controller, or another controller.
>
> If it does do this, then it defeats the purpose of a MBR and
> now turns into a boot manager.
These alternatives sum it up.
James
James Harris
> "wolfgang kern" <nowh...@never.at> wrote in message
>
> news:hfqnte$bvo$1...@newsreader2.utanet.at...
>
>
>
>
>
> > Benjamin David Lunt posted:
> > ...
> >> Multiple drives could be the BIOS' concern. It will load the first
> >> given drive's MBR. If no active partition is found, it will
> >> move to the next drive, until an active partition is found.
> > ...
>
> > I think standard BIOS doesn't check on partitions and may not even
> > look if 55AA is present.
> > BIOS only load/execute the first 512 bytes of a media (if readable),
> > so a boot of an all zero MBR usually ends in the wild.
>
> > It's the code in the MBR which searches for the active partition,
> > and it should invoke INT19h or INT13h boot_next if none is found,
> > even many will just tell 'missing operating system, press ...'.
>
> After thinking about it, with your's and Max's comments, this would
> be the ideal thing to do. If no active partition found, load
> from the next disk and jump to it.
I'm not so sure this is a good idea. You might end up booting a
partition that is not wanted. Rather, I can only think of two serious
options:
1. Stop with a short message in English saying cannot boot and giving
the disk id if possible.
2. Make a pan-machine decision on which partition to boot, asking the
user if necessary. What to do if the selected partition is not
present?
In other words, I can only think that we should either rely on the
BIOS to have picked the correct boot disk or to explicitly deal with
any inconsistency. Perhaps the latter implies a boot manager. It would
be good if it could be fit within a sector but that might not be
possible.
James
James Harris
> "Rod Pemberton" <do_not_h...@nohavenot.cmm> wrote in message
It's a good idea but I should be clear that my question was from the
point of view of what an OS writer (or MBR-writer) should do. I wasn't
trying to solve a problem on one machine. Any code we write for an MBR
should be appropriate for all machines. Users shouldn't have to buy
extra hardware.
James
James Harris
> Benjamin David Lunt posted:
> ...> Multiple drives could be the BIOS' concern. It will load the first
> > given drive's MBR. If no active partition is found, it will
> > move to the next drive, until an active partition is found.
>
> ...
>
> I think standard BIOS doesn't check on partitions and may not even
> look if 55AA is present.
I recall a Usenet discussion where it was asserted that the 0x55, 0xaa
signature is not generally checked by the BIOS for a floppy but that
it is for a hard disk. I can't verify that this is a standard either
way so it's mentioned only as heresay.
> BIOS only load/execute the first 512 bytes of a media (if readable),
> so a boot of an all zero MBR usually ends in the wild.
>
> It's the code in the MBR which searches for the active partition,
> and it should invoke INT19h or INT13h boot_next if none is found,
> even many will just tell 'missing operating system, press ...'.
Do you know the AH number for int 0x13 boot_next?
James
Rod Pemberton
> Any code we write for an MBR
> should be appropriate for all machines.
Do as little as is required...
Do nothing non-standard...
Use a DOS compatible BPB...
e.g., short jmp with nop
e.g., with PS/2 OEM name, e.g., "MSWIN 3y" instead of "MSWIN4.1".
Don't modify any memory or settings (e.g., PIC or IVT or CMOS or low ram)
that the BIOS touched...
Use the BIOS heavily, especially "long forgotten" functions:
e.g., use Int 15h, ax = 2401h to enable A20...
e.g., use Int 15h, ah = 89h to switch to PM...
e.g., use Int 15h, ah = 87h to copy memory high...
e.g., use 286 compatible CMOS flag and 40:67 vector to exit RM...
(I definately didn't follow this suggestion in my numerous partially written
bootloaders... It's a control issue.)
Don't use "recent" (post '89 or post PS/2) BIOS API extensions...
e.g., extended int 13h calls, int 15h, EBDA, extended int 19/18h BBS, or
USB or VESA or ACPI or SMBIOS BIOS calls, etc.
(I'm not sure if that's really feasible. Int 13h has been extended by at
least three specifications...)
If BIOS is broken, it's the PC owners problem... (e.g., int 19h jmp 7c0:0h
BIOS bug)
:-) With a grin, was that more along the lines of your question?
It's really hard to provide useful answers when no one will tell me what
they're doing.
Rod Pemberton
Rod Pemberton
> On 10 Dec, 20:05, "Benjamin David Lunt" <zf...@frontiernet.net> wrote:
> > If no active partition found, load
> > from the next disk and jump to it.
>
> I'm not so sure this is a good idea.
If I didn't mark it active, I don't want it booted. If it's not marked
active, 70% of the time there won't be valid boot code on that partition
anyway since I never put one there. What happens if the first disk had
active DOS partitions that've been disabled, and the second disk has a Linux
swap as it's first partition? Are you going to boot a swap partition?
Rod Pemberton
Benjamin David Lunt
"Rod Pemberton" <do_no...@nohavenot.cmm> wrote in message
Nope. What I meant was, if no active partition found, load
the MBR from the next disk and jump to it.
To add to me notes of what should be done, one should probably
check that 0x1FE = 0xAA55 or 0x55AA before attempting to boot
it.
Thanks,
Ben
James Harris
> "James Harris" <james.harri...@googlemail.com> wrote in message
Sort of (except that I don't think there's a BPB in the MBR).
>
> It's really hard to provide useful answers when no one will tell me what
> they're doing.
Just discussing what an MBR should or could do.
Thanks for the suggestions.
James
Rod Pemberton
> Sort of (except that I don't think there's a BPB in the MBR).
>
Sorry, been a while... After looking at my code, I probably never fully
separated them (MBR/PBS) mentally. But, that brings up a good design
question. Let's say you only use bootloader code in an MBR to boot
partitions (only one partition on a disk should be marked bootable anyway) -
more like a floppy except you've also got partition entries too - so, there
is no partition boot code in a partition boot sector at the start of each
partition. Do you 1) use a BPB with your OS (it's optional), and 2) if so,
do you put it in the MBR? You've got almost the same amount of code space
available in the MBR as in the PBS.
Rod Pemberton
Rod Pemberton
> I think standard BIOS doesn't check on partitions and may not even
> look if 55AA is present.
AIUI, the PC BIOS checks for 0xAA55 signature on all bootable devices except
the floppy and BIOS. "Devices" is defined as harddisks, option ROM's -
network cards, Video BIOS, BASIC, etc... E.g., 0xAA55 will be on a 2k
boundary for option ROM's.
> I recall a Usenet discussion where it was asserted that the 0x55, 0xaa
> signature is not generally checked by the BIOS for a floppy
The 0xAA55 signature is not supposed to be checked for the floppy, ever.
CP/M uses last byte of 512 to indicate floppy type. I.e., if the BIOS
checks, it won't boot a CP/M floppy. However, I found out that this
machine's BIOS does check the floppy for 0xAA55. It's the only one I'm
aware of that does so. If there was a recent standard which obsoleted this,
I haven't found it yet.
> but that
> it is for a hard disk.
Yes.
> I can't verify that this is a standard either
> way so it's mentioned only as heresay.
Heresy? Hearsay?
"IBM Personal System/2 and Personal Computer BIOS Interface Technical
Reference", September 1991, pg. 2-IN19-1 and 2-IN19-2
"Interrupt 19H--Boostrap Loader
Devices that are supported by Interrupt 13H read the boot record from
cylinder 0, head 0, sector 1. Devices that are supported by Interrupt
4BH read the boot record from logical block address 1. The boot
record is then read into system memory at address hex 0000:7C00.
The power-on self-test (POST) checks for the following characteristics
to validate a boot record:
* For a device with removable media, such as a diskette, the boot
record must contain valid code. For example, the value of the
first byte of the boot record must be greater than 6.
* For a device with nonremovable media, such as a fixed disk,
there must be a signature of hex 55AA at the end of the boot
record."
Further on, it states:
"The following information is passed to the boot record:
(CS) = 0000H
(IP) = 7C00H
(DX) - Boot device identifier or device key
When (DX) is a boot device identifier, (DH) and (DL) are
defined as follows:
(DH) - Device identifier
Bit 7 - Removable-media indicator
= 0 - Nonremovable media
= 1 - Removable media
Bit 6 - Reserved
Bit 5 - Access mode
= 0 - Device is supported by Interrupt 13H
= 1 - Device is supported by Interrupt 4BH
Bits 4 to 0 - Peripheral-device type
(DL) - Device instance
= 00H - First diskette drive (if the access-mode bit)
is set to 0)
- First CD-ROM drive (if the access-mode bit
is set to 1)
= 80H - First fixed disk drive (if the access-mode bit
is set to 0)
"
If BIOS cloners had this info, they wouldn't have had the CS=07C0H, IP=0,
jump problem. Of course, without the signature, other methods need to be
used to detect a bootable versus a blank floppy. Elsewhere, I read that
some BIOSes checked for repeated identical byte values to determine
blankness.
As for 0xAA55 signature on 2k boundaries required for ROM's, network
devices, PnP, etc., there numerous specifications that require that:
"Microsoft Extensible Firmware Initiative FAT32 File System Specification",
Microsoft Corporation, V1.03, Dec. 6, 2000
"BIOS Boot Specification", Compaq Comp. Co., Phoenix Technologies Ltd.,
Intel Corp., Jan 11, 1996 V1.01
"Plug and Play BIOS Specification", Compaq Comp. Co., Phoenix Technologies
Ltd., Intel Corp. May 5, 1994, V1.0A
"PhoenixBIOS 4.0 Revision 6", Phoenix Technologies Ltd., June 22, 2000
"Novell Boot Rom Developer's Guide for DOS Workstations", July 9, 1992, V.
1.0
Some of these also make changes to Int 19h and Int 18h boot order.
Unfortunately, except for original IBM manuals and RBIL, I've found no
specifications stating what's required for floppies and harddisks.
Rod Pemberton
James Harris
> "James Harris" <james.harri...@googlemail.com> wrote in message
According to Wikipedia the master boot record and what it calls the
volume boot record are different. They certainly have different
requirements and a BPB would be appropriate only for a volume boot
record and env then only if it is of a type for which a BPB is
relevant such as FAT. See
http://en.wikipedia.org/wiki/Master_boot_record
http://en.wikipedia.org/wiki/Volume_Boot_Record
http://en.wikipedia.org/wiki/Disk_partitioning
http://en.wikipedia.org/wiki/Extended_boot_record
The first two links are directly relevant but the last two are also
useful. For example they seem to show that for a conventional
partitioning scheme an MBR may need to skip through an EBR chain
looking for the partition that is to be booted.
James
James Harris
> "James Harris" <james.harri...@googlemail.com> wrote in message
>
> news:e43b4aa2-91b1-4ced...@j24g2000yqa.googlegroups.com...
>
> > I think standard BIOS doesn't check on partitions and may not even
> > look if 55AA is present.
I think you've attributed Wolfgang's comment to me there.
>
> AIUI, the PC BIOS checks for 0xAA55 signature on all bootable devices except
> the floppy and BIOS. "Devices" is defined as harddisks, option ROM's -
> network cards, Video BIOS, BASIC, etc... E.g., 0xAA55 will be on a 2k
> boundary for option ROM's.
>
> > I recall a Usenet discussion where it was asserted that the 0x55, 0xaa
> > signature is not generally checked by the BIOS for a floppy
>
> The 0xAA55 signature is not supposed to be checked for the floppy, ever.
> CP/M uses last byte of 512 to indicate floppy type. I.e., if the BIOS
> checks, it won't boot a CP/M floppy. However, I found out that this
> machine's BIOS does check the floppy for 0xAA55. It's the only one I'm
> aware of that does so. If there was a recent standard which obsoleted this,
> I haven't found it yet.
>
> > but that
> > it is for a hard disk.
>
> Yes.
>
> > I can't verify that this is a standard either
> > way so it's mentioned only as heresay.
>
> Heresy? Hearsay?
Ah, probably a bit of both!
>
> "IBM Personal System/2 and Personal Computer BIOS Interface Technical
> Reference", September 1991, pg. 2-IN19-1 and 2-IN19-2
>
> "Interrupt 19H--Boostrap Loader
>
> Devices that are supported by Interrupt 13H read the boot record from
> cylinder 0, head 0, sector 1. Devices that are supported by Interrupt
> 4BH read the boot record from logical block address 1. The boot
> record is then read into system memory at address hex 0000:7C00.
>
> The power-on self-test (POST) checks for the following characteristics
> to validate a boot record:
>
> * For a device with removable media, such as a diskette, the boot
> record must contain valid code. For example, the value of the
> first byte of the boot record must be greater than 6.
>
> * For a device with nonremovable media, such as a fixed disk,
> there must be a signature of hex 55AA at the end of the boot
> record."
OK that's very clear. So at least in principle
removable --> 0x55, 0xaa NOT required
nonremovable --> 0x55, 0xaa REQUIRED
As you point out below some BIOSes are not written to spec but at
least the above shows what was designed.
I included 0x55, 0xaa in my own floppy boot sector
http://codewiki.wikispaces.com/fatbootsect.nasm
I guess it's not (officially) needed.
True. Interesting point about DH. I only knew of the DL part.
wolfgang kern
James Harris wrote:
...
>>> Multiple drives could be the BIOS' concern. It will load the first
>>> given drive's MBR. If no active partition is found, it will
>>> move to the next drive, until an active partition is found.
>> ...
>> I think standard BIOS doesn't check on partitions and may not even
>> look if 55AA is present.
> I recall a Usenet discussion where it was asserted that the 0x55, 0xaa
> signature is not generally checked by the BIOS for a floppy but that
> it is for a hard disk. I can't verify that this is a standard either
> way so it's mentioned only as heresay.
Yeah, BIOS should check for 55AA on HD.
But I remember one older BIOS (Compaq or Packard ?) which didn't.
>> BIOS only load/execute the first 512 bytes of a media (if readable),
>> so a boot of an all zero MBR usually ends in the wild.
>> It's the code in the MBR which searches for the active partition,
>> and it should invoke INT19h or INT13h boot_next if none is found,
>> even many will just tell 'missing operating system, press ...'.
Do you know the AH number for int 0x13 boot_next?
I'd use AH=02 to simulate a bootload, even this could result in
drive-letter issues. As Ben already said, this should be part of
a boot manager.
Better still is to say 'error...reboot' on a wrong BIOS-setup.
__
wolfgang
s_dub...@yahoo.com
> "James Harris" <james.harri...@googlemail.com> wrote in message
>
> news:e43b4aa2-91b1-4ced...@j24g2000yqa.googlegroups.com...
>
> > I think standard BIOS doesn't check on partitions and may not even
> > look if 55AA is present.
>
> AIUI, the PC BIOS checks for 0xAA55 signature on all bootable devices except
> the floppy and BIOS. "Devices" is defined as harddisks, option ROM's -
> network cards, Video BIOS, BASIC, etc... E.g., 0xAA55 will be on a 2k
> boundary for option ROM's.
>
> > I recall a Usenet discussion where it was asserted that the 0x55, 0xaa
> > signature is not generally checked by the BIOS for a floppy
>
> The 0xAA55 signature is not supposed to be checked for the floppy, ever.
> CP/M uses last byte of 512 to indicate floppy type. I.e., if the BIOS
Actually, this was an IBM standard, set on the original 8" floppy
diskettes; if the last byte of the boot sector was 00h, then the
diskette media was taken as single sided, if 01h then the diskette
media was double sided. This was because early 8" drives came in
single and double (2) recording head models.
This carried over into the 5 1/4 media the same way because the early
IBM & Tandon full height 5 1/4 floppy drives came in single head and
double head versions, (most commonly single head, early on).
CP/M-86 v1.0 (IBM's version for the PC), CP/M-86 v1.1 (offered
directly by DRI) and 86-DOS (8" originally), used this convention.
I first ran across the 0xAA55 signature restriction, in a Seagate
ST-01 scsi HD controller, in which its option rom revectored int 13h
thru its own int 40h handler. So with the controller installed, it
wouldn't boot CP/M-86 at all, it would just continue to try to reboot,
tsk, tsk, without error notification. This behavior was a fluke at
the time. Now, most MBR code self-verifies by looking for this
signature, in addition to looking for the bootable partition.
I've also seen two strategies for selecting the boot partition by the
MBR code; 1) boot first bootable regardless of whether there was more
than one marked as bootable, and 2) verify a single partition is
marked bootable, and boot that, else error if more than one is marked
bootable at a time. AFAIK, IBM OS/2 MBR was the first to have a menu
to boot select as part of the MBR code. Boot selection (of device)
has moved to the Bios in later PnP bios's. Some of these later bios's
have to be told to recognize (enable) a hardware device thru the Power-
On Setup function. And to this was added device 'Boot Selection'
ordering as another function to the Power-On Setup.
btw, the format filler byte was 0E5h up to the 3 1/2 floppy drives
where it was changed to 0F6h, to place in 'empty' sectors.
Steve
> checks, it won't boot a CP/M floppy. However, I found out that this
> machine's BIOS does check the floppy for 0xAA55. It's the only one I'm
> aware of that does so. If there was a recent standard which obsoleted this,
> I haven't found it yet.
>
[snipped]
>
> Rod Pemberton
Rod Pemberton
> On 11 Dec, 03:49, "Rod Pemberton" <do_not_h...@nohavenot.cmm> wrote:
> > "James Harris" <james.harri...@googlemail.com> wrote in message
> >
news:e43b4aa2-91b1-4ced...@j24g2000yqa.googlegroups.com...
> >
> > > I think standard BIOS doesn't check on partitions and may not even
> > > look if 55AA is present.
>
> I think you've attributed Wolfgang's comment to me there.
Ah... Yes, sorry. Occasionally, I have to manually correct the
auto-indentation with this newsreader. That was probably what happened.
RP
Rod Pemberton
> removable --> 0x55, 0xaa NOT required
> nonremovable --> 0x55, 0xaa REQUIRED
>
> As you point out below some BIOSes are not written to spec but at
> least the above shows what was designed.
>
> I included 0x55, 0xaa in my own floppy boot sector
>
> http://codewiki.wikispaces.com/fatbootsect.nasm
>
> I guess it's not (officially) needed.
That was the official position twenty years ago. I'm not sure whether it's
officially _not_ required anymore for floppies.
I put 0xAA55 mine too. Unfortunately, I wanted my floppy bootsector to work
without it.
Since this machine requires the 0xAA55 signature to boot my bootable
floppies, I suspect not having 0xAA55 on floppies may have been obsoleted
sometime. But, I haven't been able to confirm. This machine has USB
booting of floppy and harddisk images. Perhaps, it might be in an (offline)
standard related to that.
> > [PS/2 spec. Int 19h]
>
> Interesting point about DH. I only knew of the DL part.
There was some more info. about the 4Bh functionality, but I didn't post
that. I suspect the other returns may have been PS/2 or obsoleted since
RBIL doesn't have this info. RBIL contributors cited the tech. ref, so they
should've had that info. Someone could test Int 19h to see if it seemed the
other info is returned. Even so, I'm not about to use DL either, unless I
have too. Once my 0x7C00 (MBR/VBR) code starts, I don't want potentially
"bad input".
Rod Pemberton
Rod Pemberton
>
> According to Wikipedia the master boot record and what it calls the
> volume boot record are different.
VBR? Ok... new term. First, I'll criticize their terminology, then I'll
go on using their terminology...
It's unfortunate that the partition boot record (PBR) is what Wikipedia is
calling the volume boot record (VBR). A floppy is a volume. A harddisk is
a volume. But, a partion is _not_ a volume. So, how can a volume boot
record pertain to a partition?
Wikipedia's term volume boot record (VBR) is what I (currently) understand
to be the partition boot record (PBR) for harddisk partitions, and the
master boot record (MBR) for floppies. A master boot record (MBR) to me,
is the first sector of a volume (floppy or harddisk, etc.) which has
executable code. That's why it's the _master_. It's first. "master" and
"slave" (unfortunately) are the historical electrical engineering (EE) terms
for "primary" and "secondary". So, "my MBR", using Wikipedia's (current)
terminology, would be 1) MBR for harddisks or 2) VBR for floppies. So, from
their perspective, I'm confusing things...
> They certainly have different
> requirements
What requirements? None of this is required. It has historical
significance.
Once your code from the bootsector is executing, you can do what you want.
AFAIK, the BPB was an IBM and MS invention in order to recognize media of
different sizes and densities, like the many different types of 5 1/4"
floppies. If you choose compatibility with DOS or Windows, you might want
them. Or, you might want them to ease implementation of your bootloader.
> and a BPB would be appropriate only for a volume boot
> record
This is purely hypothetical, but if one is using a MBR and VBR setup (e.g.,
FAT), does one need a VBR under all circumstances? Let's take a harddisk
with an MBR and a couple of partitions with VBRs. Now, we delete all
partions. Next, we create a single partition. It'll have a VBR... But, do
we need a VBR if we only have a single partition? Couldn't we use only an
MBR in this situation? If yes, and we were also using BPBs in the VBRs,
don't we need to relocate the BPB somewhere? E.g., in MBR?
Rod Pemberton
wolfgang kern
Rod Pemberton wrote:
>> According to Wikipedia the master boot record and what it calls the
>> volume boot record are different.
> VBR? Ok... new term. First, I'll criticize their terminology, then I'll
> go on using their terminology...
Oh yeah, terms and abbreviations ...
for myself I named the first sector of a partition:
'the partition-sector' aka MBR
and the format-info usually found in one track (theory anyway) distance:
'the boot sector' aka BR
> It's unfortunate that the partition boot record (PBR) is what Wikipedia is
> calling the volume boot record (VBR). A floppy is a volume. A harddisk
> is
> a volume. But, a partion is _not_ a volume. So, how can a volume boot
> record pertain to a partition?
I treat partitions as apart 'volumes', because
they may use different formatted filesystems (format-info is in the vBR),
got a literal Volume-Label and a drive-letter or -number.
> Wikipedia's term volume boot record (VBR) is what I (currently) understand
> to be the partition boot record (PBR) for harddisk partitions, and the
> master boot record (MBR) for floppies. A master boot record (MBR) to me,
> is the first sector of a volume (floppy or harddisk, etc.) which has
> executable code. That's why it's the _master_. It's first. "master" and
> "slave" (unfortunately) are the historical electrical engineering (EE)
> terms
> for "primary" and "secondary". So, "my MBR", using Wikipedia's (current)
> terminology, would be 1) MBR for harddisks or 2) VBR for floppies. So,
> from
> their perspective, I'm confusing things...
I think Master/Slave once came from a free pin on FD-connectors which
allowed
two devices to share one controller. IDE-HDs followed this cheap solution.
So it would be less confusing if we'd all use equal terms ie:
1. drive DRV;a single piece of hardware
2. volume VOL;a single part of a drive, aka partition
3. directory DIR;aka folder
4. file
>> They certainly have different requirements
> What requirements? None of this is required. It has historical
> significance.
> Once your code from the bootsector is executing, you can do what you want.
> AFAIK, the BPB was an IBM and MS invention in order to recognize media of
> different sizes and densities, like the many different types of 5 1/4"
> floppies. If you choose compatibility with DOS or Windows, you might want
> them. Or, you might want them to ease implementation of your bootloader.
>> and a BPB would be appropriate only for a volume boot record
> This is purely hypothetical, but if one is using a MBR and VBR setup
> (e.g.,
> FAT), does one need a VBR under all circumstances? Let's take a harddisk
> with an MBR and a couple of partitions with VBRs. Now, we delete all
> partions. Next, we create a single partition. It'll have a VBR... But,
> do
> we need a VBR if we only have a single partition? Couldn't we use only an
> MBR in this situation? If yes, and we were also using BPBs in the VBRs,
> don't we need to relocate the BPB somewhere? E.g., in MBR?
It could look like my (KESYS) single sector boot-structure:
000 jmp 050
003 "DISK LABEL"
010 8 qw format info ;includes one bit which indicate partitions present*.
050 ... code
1BE ... (optional*) partition table
1FE AA55
Sure, this need its own formatting tool but helps for security
if no other partitions are present.
For less secure (multi OS-boot) installations the partition table
is mandatory and this sector can be the first of any partition in
the partition-tree/chain, even not recognised from Linux/windoze
because of the 'unknown' partition type.
A problem with single partitions might be the limited size-field
in the partition entries, chaining partitions is already limited.
Beside the LBA-48 border, 4G -1 sectors * 512 byte = 2TB -512.
But SATA drives may come with increased sector-size anyway.
btw: I quietly ignore all CHS-infos in partition entries and use
only LBA start and size.
__
wolfgang
James Harris
> "James Harris" <james.harri...@googlemail.com> wrote in message
> news:3d713f5f-274b-42a7...@g26g2000yqe.googlegroups.com...
> > According to Wikipedia the master boot record and what it calls the
> > volume boot record are different.
>
> VBR? Ok... new term. First, I'll criticize their terminology, then I'll
> go on using their terminology...
>
> It's unfortunate that the partition boot record (PBR) is what Wikipedia is
> calling the volume boot record (VBR). A floppy is a volume. A harddisk is
> a volume. But, a partion is _not_ a volume. So, how can a volume boot
> record pertain to a partition?
Doesn't really matter too much. In the context it's just semantics
though I would accept a partition as a volume (of storage).
...
> > They certainly have different
> > requirements
>
> What requirements? None of this is required. It has historical
> significance.
Using their term the VBR has to provide code to read a file. (This is
true both for a hard disk partition and for a floppy disk. They have
other similarities. For example, each has a boot sector and holds a
file system.) By contrast the MBR doesn't need to know anything about
files. It documents how a hard disk has been partitioned and only has
to load one sector.
...
James
James Harris
> "Rod Pemberton" <do_not_h...@nohavenot.cmm> wrote in message
...
> > Are you going to boot a swap partition?
>
> Nope. What I meant was, if no active partition found, load
> the MBR from the next disk and jump to it.
Bad idea, IMHO. As a general approach this is too non-deterministic
and could lead to a lot of confusion.
James
Benjamin David Lunt
On 11 Dec, 01:44, "Benjamin David Lunt" <zf...@frontiernet.net> wrote:
> "Rod Pemberton" <do_not_h...@nohavenot.cmm> wrote in message
...
> > Are you going to boot a swap partition?
>
> Nope. What I meant was, if no active partition found, load
> the MBR from the next disk and jump to it.
James wrote:
>Bad idea, IMHO. As a general approach this is too non-deterministic
>and could lead to a lot of confusion.
Without a boot manager, how else would you boot a secondary
disk drive?
Isn't this the question that started most of this thread? :-)
Ben
Rod Pemberton
>
> "IBM Personal System/2 and Personal Computer BIOS Interface Technical
> Reference", September 1991, pg. 2-IN19-1 and 2-IN19-2
>
> "Interrupt 19H--Boostrap Loader
>
> Devices that are supported by Interrupt 13H read the boot record from
> cylinder 0, head 0, sector 1. Devices that are supported by Interrupt
> 4BH read the boot record from logical block address 1. The boot
> record is then read into system memory at address hex 0000:7C00.
>
> The power-on self-test (POST) checks for the following characteristics
> to validate a boot record:
>
> * For a device with removable media, such as a diskette, the boot
> record must contain valid code. For example, the value of the
> first byte of the boot record must be greater than 6.
>
> * For a device with nonremovable media, such as a fixed disk,
> there must be a signature of hex 55AA at the end of the boot
> record."
>
> Further on, it states:
This is what is between in case someone was interested what 4Bh does:
"
Parameters that identify the device from which the boot record was
obtained are passed to the boot record. Passing of these parameters
enables the boot record to continue the system boot operation.
In systems that do not support Interrupt 15H, Return Boot Device and
Key function ((AH)=D6H), the following information is passed to the
boot record:
(CS) = 0000H
(IP) = 7C00H
(DL) - Drive from which the boot record was read
In systems that support Interrupt 15H, Return Boot Device and Key
function ((AH)=D6H), information is passed also to the DX register. If
the access-mode bit (bit 5) is set to 0, the DX register is defined as the
"boot device identifier"; if the access-mode bit is set to 1, the DX
register is defined as the "device key." The device key is a 16-bit
value that is returned by Interrupt 4BH, Allocate Device function
((AH)=80H,(AL)=02H), (AX)=8002H. (The device key is available
also from Interrupt 15H, Return Boot Device ID and Key function
((AH)=D6H).)
"
>
> "The following information is passed to the boot record:
>
> (CS) = 0000H
> (IP) = 7C00H
> (DX) - Boot device identifier or device key
>
> When (DX) is a boot device identifier, (DH) and (DL) are
> defined as follows:
>
> (DH) - Device identifier
> Bit 7 - Removable-media indicator
> = 0 - Nonremovable media
> = 1 - Removable media
> Bit 6 - Reserved
> Bit 5 - Access mode
> = 0 - Device is supported by Interrupt 13H
> = 1 - Device is supported by Interrupt 4BH
> Bits 4 to 0 - Peripheral-device type
> (DL) - Device instance
> = 00H - First diskette drive (if the access-mode bit)
> is set to 0)
> - First CD-ROM drive (if the access-mode bit
> is set to 1)
> = 80H - First fixed disk drive (if the access-mode bit
> is set to 0)
> "
>
HTH,
Rod Pemberton
James Harris
> "James Harris" <james.harri...@googlemail.com> wrote in message
>
> news:1359205e-9754-4d07...@j4g2000yqe.googlegroups.com...
> On 11 Dec, 01:44, "Benjamin David Lunt" <zf...@frontiernet.net> wrote:
>
> > "Rod Pemberton" <do_not_h...@nohavenot.cmm> wrote in message
>
> ...
>
> > > Are you going to boot a swap partition?
>
> > Nope. What I meant was, if no active partition found, load
> > the MBR from the next disk and jump to it.
> James wrote:
> >Bad idea, IMHO. As a general approach this is too non-deterministic
> >and could lead to a lot of confusion.
>
> Without a boot manager, how else would you boot a secondary
> disk drive?
Is this a PATA issue where the BIOS won't allow boot from the
secondary drive to be specified?
The counter point is that I have seen a SATA array where drives don't
always come up in the same order. They do mostly. It's just some times
that the order will change.
Maybe a boot manager would be better (more appropriate) in such cases.
> Isn't this the question that started most of this thread? :-)
An unresolved query. :-)
James
Aharon Lavie
[...snip...]
> ... Let your boot
> sector load secondary boot code, either in additional sectors or in a
> file, and let the SBC detect the specifics you are after for your OS's
> runtime. jmho.
>
> Steve
While I like this idea, I wonder: won't this method interfere with an
operating system which examines the MBR?
Aharon Lavie
> "James Harris" <james.harri...@googlemail.com> wrote in message
>
>
> Use a DOS compatible BPB...
[...snip...]
>
> Rod Pemberton
DOS compatible BPB contains a field named BPB_HiddSec which provides
the number of sectors preceding the partition. If I am not mistaken,
the purpose of this field is to facilitate the conversion from
partition relative CHS or LBA to the absolute one for the drive.
How does the operating system obtain this value? Is there a standard
way of providing it?
Benjamin David Lunt
This is something that has bothered me for some time.
How do you know where the base address is of the partition?
If you rely on someone else's MBR, how do you know where
your partition boot sector is?
My MBR's pass the base address in four 16-bit register with
a signature in a fifth. If the partition boot code finds this
signature, it takes the 64-bit base address and stores it for
future reference. If it does not, it assumes it is at LBA 0.
However, this isn't always the case. If the MBR doesn't pass
the base address, you are pretty much SOL if you don't have
a BPB_HiddSec field that is initialized at format time.
This is where a good boot manager comes into play. The GPT,
EFI, etc. I wrote a little manager one time and may or may
not get back to it.
http://www.frontiernet.net/~fys/fysos_embr.htm
I have notes to skip it and just use strictly GPT, though I haven't
done it yet.
Ben
"Aharon Lavie" <sdc...@gmail.com> wrote in message
news:87f3afd1-aaf4-4abc...@g23g2000vbr.googlegroups.com...
Maxim S. Shatskih
>the number of sectors preceding the partition.
From the PT describing it (can be MBR at sector 0 or the extended PT) to the start of partition.
--
Maxim S. Shatskih
Windows DDK MVP
ma...@storagecraft.com
http://www.storagecraft.com
Aharon Lavie
When different operating systems reside on the same hard drive, all
listed in the MBR PT entries, how can any of them recognize its own
PTE?
Benjamin David Lunt
"Benjamin David Lunt" <zf...@frontiernet.net> wrote in message
news:QniVm.68188$de6....@newsfe21.iad...
> This is where a good boot manager comes into play. The GPT,
> EFI, etc. I wrote a little manager one time and may or may
> not get back to it.
> http://www.frontiernet.net/~fys/fysos_embr.htm
>
> I have notes to skip it and just use strictly GPT, though I haven't
> done it yet.
Just for curiosity's sake, I have updated the embr page above.
Again, I don't intend it to be the next big thing, just posted
for your curiosity's sake.
Ben