booted from logical drive
Benjamin David Lunt
Hi guys,
I was brain storming on this subject last night
and wanted to know what some of you thought about
how you think it should be done and/or how you
have done it.
For instance, I would like to have the current
(logical) disk drive at boot up the same as the
bootable disk.
e.g.: There are two physical disks, each have
three partitions, C:, D:, E:, F:, G:, and H:.
Now let's say that the BIOS is set to boot from
the second physical disk instead of the first.
Also, the second partition on the second disk is
set as the active partition.
So this would mean that logical drive G: would
be the booted from partition. Correct? Yep...
Now, my question is, how do you, as a loader or
kernel, know that this is that logical drive?
For instance, while in rmode, your boot code
is told by the bios that the booted from physical
disk is a value of 00h, 01h, etc. for floppies,
and a value of 80h, 81h, etc. for hard disks.
As the boot code, you have know idea if 80h is
actually the first hard disk or the second hard
disk. Let me rephrase that, you don't know which
controller base (0x170 or 0x1F0) goes with which
DL value (80h or 81h).
So, my question is, how do you "link" the booted
from disk in the boot code (BIOS) with the calculated
logical drive (partition) in your kernel?
Here are a few ways I thought of:
- If there was a BIOS service that you could
call with input as the DL value (80h, etc.)
and it would return the controller base and
drive number (0, 1, 2, or 3). Then all you
would have to do is parse the partition entries
in the MBR (and any extended entries) to
find the active partition entry.
However, as far as I know there are no standard
BIOS services to get the controller and drive
data from a given DL value.
- One could wait until in Pmode, then set up
a valid TSS and an IO permission bitmap. Then
using a V86 task, use the DL value given at
boot time to "verify" a sector (or some other
non fatal BIOS service). Then your V86 Monitor
will catch the IO and you can get the info
from there. This seems like a lot of work just
to get this info.
- Since we know that a DL value with bit 7 clear
is a floppy, and set is a hard disk, we can
set a non fatal IO register to a known value.
Then issue a INT 13h service. Now go check
the IO register values. If the register is
not modified, this base was not used by the DL
value's service.
e.g.: if DL = 00h, set the DOR register in
both floppy controllers to have the drive bits
clear. Then issue a INT 13h service on the
DL = 00h value. Then go check the DOR registers.
One of them should now have a drive bit set.
This would work as long as the BIOS does not
restore the original value when done with the
service.
One more example of what I thought we could do, but
then figured it wouldn't work.
For instance. In your code, where you are parsing
all partitions entries on all disks, just wait until
you find an entry marked active. This is the booted
from partition. However, how do you know that this
was the physical disk that the BIOS started on? For
example, what if you have two physical disks and
each have one partition entry marked active. How
do you know that this found active partition is on
the physical disk that was booted from? What if
you parse the partition entries on one physical disk
first, while the BIOS booted from the other physical
disk.
Anyway, I was just wondering how you guys calculate
the connection between the partition and the actual
booted from physical drive.
Thanks,
Ben
wolfgang kern
Hi Ben,
[about ..]
| Now, my question is, how do you, as a loader or
| kernel, know that this is that logical drive?
How I handle this:
The very first thing is to tell the BIOS from which
physical drive to boot (regardless if master or slave drive).
The BIOS then find by itself the first active partition,
and if the BIOS is able to access the sector (older ones
may be limited to the CHS-range or 28-bit LBA), it will
boot from there.
[logical drive assignment]
| So, my question is, how do you "link" the booted
| from disk in the boot code (BIOS) with the calculated
| logical drive (partition) in your kernel?
Even the BIOS may be able to detect and store 'all'
physical drives it wont check on other present partitions.
So I don't trust the BIOS (as it may be old) and start
first with a hardware check (presence of controllers, HD/CD).
Then I follow the partition chain on each HD and store
all needed data in my 'drive-info blocks'.
Floppies, CDs and RAM-sticks are just recognised to be
present at this time.
It's now on me how to assign 'drive-IDs' to each logical drive.
M$ usually have all first partitions on the drives named consecutive
[C: =1st on 1st HD; D: =1st on 2ns HD] and append extended partitions
after [i.e.: E: F: G: are 2.3.4. on 1st HD; H:I:J: are 2.3.4. on 2nd HD]
For example my KESYS handles this different:
No drive letters, the user just see a sorted list of drive-names (labels),
internal there is an identifier word (DRV-type/mode/HW-class/../number)
which shares layout and order with identifiers for other devices.
[but my FAT-import/export module reports M$-ordered drive-letters]
[about DL as boot drive indicator]
Yes for deterring the drive (if from HD or FD),
but it wont tell you from which partition.
I don't know the value in DL if booted from other sources
like ZIP-, USB-drives, local-net, ROMs or chip-cards.
| - One could wait until in Pmode, then set up
| a valid TSS and an IO permission bitmap. Then
| using a V86 task, ...
This wouldn't tell you if a port exists or not
(sounds awful detouring also),
In my hardware checker I just try 'identify drive' on all the
four known ports (master and slave) and it reports a time-out error
if it not present.
| - Since we know that a DL value with bit 7 clear
| is a floppy, and set is a hard disk, we can
| set a non fatal IO register to a known value.
| Then issue a INT 13h service.
INT 13 service may not be able to handle huge HDs and other sources
but it's fine for floppy.
| Anyway, I was just wondering how you guys calculate
| the connection between the partition and the actual
| booted from physical drive.
If I would need to know from where my OS was booted from,
I could search for "my" OEM-sign in my 'drive info blocks'.
And if none of them holds my sign I can read the first floppy
sector and/or other 'removables' to confirm it was booted from there.
__
wolfgang
Alexei A. Frounze
news:mOhve.167$pg...@news01.roc.ny...
>
> Hi guys,
>
> I was brain storming on this subject last night
> and wanted to know what some of you thought about
> how you think it should be done and/or how you
> have done it.
>
> For instance, I would like to have the current
> (logical) disk drive at boot up the same as the
> bootable disk.
>
> e.g.: There are two physical disks, each have
> three partitions, C:, D:, E:, F:, G:, and H:.
That's the dos/win assignment :)
> Now let's say that the BIOS is set to boot from
> the second physical disk instead of the first.
> Also, the second partition on the second disk is
> set as the active partition.
>
> So this would mean that logical drive G: would
> be the booted from partition. Correct? Yep...
No :) It would still be C :))
Int 13h fxn 48h, table #00278. See the RBIL.
> - One could wait until in Pmode, then set up
> a valid TSS and an IO permission bitmap. Then
> using a V86 task, use the DL value given at
> boot time to "verify" a sector (or some other
> non fatal BIOS service). Then your V86 Monitor
> will catch the IO and you can get the info
> from there. This seems like a lot of work just
> to get this info.
Something like that could work.
> - Since we know that a DL value with bit 7 clear
> is a floppy, and set is a hard disk, we can
> set a non fatal IO register to a known value.
> Then issue a INT 13h service. Now go check
> the IO register values. If the register is
> not modified, this base was not used by the DL
> value's service.
>
> e.g.: if DL = 00h, set the DOR register in
> both floppy controllers to have the drive bits
> clear. Then issue a INT 13h service on the
> DL = 00h value. Then go check the DOR registers.
> One of them should now have a drive bit set.
> This would work as long as the BIOS does not
> restore the original value when done with the
> service.
Maybe.
> One more example of what I thought we could do, but
> then figured it wouldn't work.
>
> For instance. In your code, where you are parsing
> all partitions entries on all disks, just wait until
> you find an entry marked active. This is the booted
> from partition. However, how do you know that this
> was the physical disk that the BIOS started on? For
> example, what if you have two physical disks and
> each have one partition entry marked active. How
> do you know that this found active partition is on
> the physical disk that was booted from? What if
> you parse the partition entries on one physical disk
> first, while the BIOS booted from the other physical
> disk.
>
> Anyway, I was just wondering how you guys calculate
> the connection between the partition and the actual
> booted from physical drive.
I guess nobody cares much about it in the group according to the amount of
replies. :)
I've enjoyed playing with all this stuff on PC recently for I upgraded the
HDD and unfortunately it couldn't be installed in that bay where was the
previous one and thus I was forced to hook it up onto the different IDE
channel, which lead to some mishmash until I finally disconnected the other
HDD :) Booting order was always something different from what I wanted it to
be. That's on windows level, not on the BIOS'.
Alex
Benjamin David Lunt
"wolfgang kern" <now...@nevernet.at> wrote in message
news:d9mvg4$ha2$3...@newsreader1.utanet.at...
>
> Hi Ben,
>
> [about ..]
> | Now, my question is, how do you, as a loader or
> | kernel, know that this is that logical drive?
>
> How I handle this:
> The very first thing is to tell the BIOS from which
> physical drive to boot (regardless if master or slave drive).
>
> The BIOS then find by itself the first active partition,
> and if the BIOS is able to access the sector (older ones
> may be limited to the CHS-range or 28-bit LBA), it will
> boot from there.
[ The BIOS usually does *not* parse the partition
entry, correct? That is up to the MBR. ]
> [logical drive assignment]
>
> | So, my question is, how do you "link" the booted
> | from disk in the boot code (BIOS) with the calculated
> | logical drive (partition) in your kernel?
>
> Even the BIOS may be able to detect and store 'all'
> physical drives it wont check on other present partitions.
[ correct ]
> So I don't trust the BIOS (as it may be old) and start
> first with a hardware check (presence of controllers, HD/CD).
> Then I follow the partition chain on each HD and store
> all needed data in my 'drive-info blocks'.
> Floppies, CDs and RAM-sticks are just recognised to be
> present at this time.
[This I do also. However, you *must* use the BIOS in your
boot sector. A sectors worth of bytes is not enough room
to detect the hardware, load a hardware driver, *and* find
the rest of the kernel. ]
Hi wolfgang,
I have to admit, I did not understand alot of your
reply. Either I am confused about what you are
saying, or you are confused about what I am trying
to accomplish. :-)
I have no problem with any of the boot code, nor
the drive allocation units, or whatever you would like
to call them. i.e.: I have all my logical drives
in "drive info blocks" also. There is no problem
here.
What is the problem, is I am trying to assign one
of these "drive info blocks" as the "booted from
partition".
i.e.: Of all the "drive info blocks" (for simplicity,
I am only worrying about floppies and hard drives for
the moment) which of these blocks (partitions or
actual floppies) had it's boot code executed. Don't
count the MBR on LBA 0. I am talking about which
partition boot sector gained control after the BIOS
POST.
I would like to link one of my "drive info blocks"
to which partition boot sector was booted from.
The problem with parsing the partition tables, after
your kernel has control, looking for a SysId mark in
the table is what if there are two physical drives that
contain the same SysId in one or more of their partition
tables?
Once my kernel gains control, it no longer rely's
on which partition, floppy, ZIP, USB, etc., was booted.
My kernel starts to create "drive info blocks" in order
of what I coded it to do so. If my kernel starts with
the controller at 0x1F0, then it creates a "drive info
block" for all partitions on that controller, which could
be as many as 25 per drive. (Unrealistic, but with
extended partition entries, feasible). USB would be
well on the last part of the list, since the USB stack
must be created first. So what if the machine booted
from the USB ROM stick which had a FAT12 partition
and there was also a FAT12 partition on the second
partition on the second drive of the first hard drive
controller? What if these partitions where of equal
size and type. (I know FAT12? Just for example).
How should my kernel be written to know that the
USB partition was the booted from drive, not the
other FAT12 partition?
Anyway, I appreciate your comments. I am still thinking
of a good way of doing this.
Thanks,
Ben
P.S. All the comments above in []'s where done
after the fact of writing the above reply. :)
Benjamin David Lunt
"Alexei A. Frounze" <ale...@chat.ru> wrote in message
news:3i8gavF...@individual.net...
> "Benjamin David Lunt" <zf...@frontiernet.net> wrote in message
> news:mOhve.167$pg...@news01.roc.ny...
Hi Alex,
>> Hi guys,
>>
>> I was brain storming on this subject last night
>> and wanted to know what some of you thought about
>> how you think it should be done and/or how you
>> have done it.
>>
>> For instance, I would like to have the current
>> (logical) disk drive at boot up the same as the
>> bootable disk.
>>
>> e.g.: There are two physical disks, each have
>> three partitions, C:, D:, E:, F:, G:, and H:.
>
> That's the dos/win assignment :)
Indeed.
>> Now let's say that the BIOS is set to boot from
>> the second physical disk instead of the first.
>> Also, the second partition on the second disk is
>> set as the active partition.
>>
>> So this would mean that logical drive G: would
>> be the booted from partition. Correct? Yep...
>
> No :) It would still be C :))
If it were a DOS/Windows OS :) I was using this
as a general example.
I will go and have a look. Thanks. Although, if
I did know which controller/drive was booted from,
once my kernel gained control, which now is FS
independant, how do I know which partition on that
controller/drive was booted? :) I am still thinking
about it.
Thanks for your comments. I will let you guys
know what I come up with.
Thanks,
Ben
wolfgang kern
| > The BIOS then find by itself the first active partition,
| > and if the BIOS is able to access the sector (older ones
| > may be limited to the CHS-range or 28-bit LBA), it will
| > boot from there.
|
| [ The BIOS usually does *not* parse the partition
| entry, correct? That is up to the MBR. ]
Yes, BIOS reads just the four entries in the MBR and
take the first one which is marked active as the sector
to execute (very old BIOS may only accept the first entry).
| > [logical drive assignment]
[..]
| [This I do also. However, you *must* use the BIOS in your
| boot sector. A sectors worth of bytes is not enough room
| to detect the hardware, load a hardware driver, *and* find
| the rest of the kernel. ]
Sure.
| Hi wolfgang,
| I have to admit, I did not understand alot of your
| reply. Either I am confused about what you are
| saying, or you are confused about what I am trying
| to accomplish. :-)
Probably a bit of both :)
| I have no problem with any of the boot code, nor
| the drive allocation units, or whatever you would like
| to call them. i.e.: I have all my logical drives
| in "drive info blocks" also. There is no problem
| here.
|
| What is the problem, is I am trying to assign one
| of these "drive info blocks" as the "booted from
| partition".
|
| i.e.: Of all the "drive info blocks" (for simplicity,
| I am only worrying about floppies and hard drives for
| the moment) which of these blocks (partitions or
| actual floppies) had it's boot code executed. Don't
| count the MBR on LBA 0. I am talking about which
| partition boot sector gained control after the BIOS
| POST.
If only floppies and HDs are of concern you can use DL.
| I would like to link one of my "drive info blocks"
| to which partition boot sector was booted from.
Yes, my OS got some marks (partition type and OEM-ID)
which also goes to the drive-info block, so I actually
know where the OS was booted from.
| The problem with parsing the partition tables, after
| your kernel has control, looking for a SysId mark in
| the table is what if there are two physical drives that
| contain the same SysId in one or more of their partition
| tables?
I just had to look which one got the a set 'active bit'.
But right, if I would boot from a frame-HD, the exchangeable
media bit wont be set then ... this may cause a problem,
but by fortune I never encountered it.
[about the problem ...]
| How should my kernel be written to know that the
| USB partition was the booted from drive, not the
| other FAT12 partition?
|
| Anyway, I appreciate your comments. I am still thinking
| of a good way of doing this.
If your OS got its own file-sytem (mine got its 'very own'),
then the format-process could add a single info byte in the
boot-sector (not the partition sector yet) which could then
identify itself on which media type it resides.
Similar to the media-descriptor-byte on M$-formatted drives.
There is still the problem of two identical media can
hold identical? (this wont hurt anyway) versions of an OS.
So a version check in addition could make it sure.
| P.S. All the comments above in []'s where done
| after the fact of writing the above reply. :)
:) I thought so.
__
wolfgang
Benjamin David Lunt
> Hi Ben,
Hi wolfgang,
> | > The BIOS then find by itself the first active partition,
> | > and if the BIOS is able to access the sector (older ones
> | > may be limited to the CHS-range or 28-bit LBA), it will
> | > boot from there.
> |
> | [ The BIOS usually does *not* parse the partition
> | entry, correct? That is up to the MBR. ]
>
> Yes, BIOS reads just the four entries in the MBR and
> take the first one which is marked active as the sector
> to execute (very old BIOS may only accept the first entry).
I have to beg to differ. Unless I am completely wrong, I
have never seen a BIOS that parses the MBR and loades the
partition boot sector of the active partition. Please
correct me if I am wrong here.
> | I would like to link one of my "drive info blocks"
> | to which partition boot sector was booted from.
>
> Yes, my OS got some marks (partition type and OEM-ID)
> which also goes to the drive-info block, so I actually
> know where the OS was booted from.
[talking to myself, I said:]
How? What is it you actually mark? If you have an
OEM-ID, while in the boot code, do you save this partition
type and OEM-ID number somewhere in memory? Then when
your kernel creates the "disk info blocks", it could
compare these two values. Hhmm.... This would work.
I will have to look into this. Thanks.
Since all partition boot sectors are file system specific,
I could pass a block of information to the kernel with
one of the members of the block being the filesystem
type. Then fill this info block with info from the boot
sector:
e.g.: for a FAT FS, the serial number, secs_per_clust, etc.
A different FS would have different known items in this
info block.
Then when I create each "disk info block", simply check
the boot_info_block's FS type. If this type matches the
"disk info block" partitions FS, then do the compare on
the remaining items.
This should work as long as I make the information block
detailed enough that no two similar partitions of same
FS type on the same physical disk could be considered
the same partition.
Thanks, wolfgang, for your comments. This should give
me enough to create what I am looking for.
Thanks,
Ben
Alex, thanks for your comments too. I haven't looked
at the INT 13h/48h service you mentioned yet, but if it
returns the data I want, it will be great to know.
wolfgang kern
Hi Ben,
| > Yes, BIOS reads just the four entries in the MBR and
| > take the first one which is marked active as the sector
| > to execute (very old BIOS may only accept the first entry).
| I have to beg to differ. Unless I am completely wrong, I
| have never seen a BIOS that parses the MBR and loades the
| partition boot sector of the active partition. Please
| correct me if I am wrong here.
While I read your doubt, I'm not sure anymore for the
master boot record structure is standard on all x86 PCs.
But I have an Award-styled BIOS on one of my motherbords
which can optionally boot from extended partitions.
Doesn't FAT, NT and Linux use the same format of MBR ?
And when I look at the list of possible partition-types ...?
| > | I would like to link one of my "drive info blocks"
| > | to which partition boot sector was booted from.
| > Yes, my OS got some marks ...
| [talking to myself, I said:]
| How? What is it you actually mark? If you have an
| OEM-ID, while in the boot code, do you save this partition
| type and OEM-ID number somewhere in memory?
Yes, in the drive info block.
| Then when your kernel creates the "disk info blocks", it could
| compare these two values. Hhmm.... This would work.
| I will have to look into this. Thanks.
I forgot to mention that my FS got only one start sector
per partition, with the boot-header on top and partition
entries at the end, so I have all needed info on the fly
at 0:7c00 loaded by BIOS.
| Since all partition boot sectors are file system specific,
| I could pass a block of information to the kernel with
| one of the members of the block being the filesystem type.
The partition type byte in the MBR is already a good indicator.
| Then fill this info block with info from the boot
| sector:
| e.g.: for a FAT FS, the serial number, secs_per_clust, etc.
| A different FS would have different known items in this
| info block.
Oh yes, my boot record got a complete different layout:
no clustering nor FAT-sectors, no CHS-info,
no 'hidden' nor 'wasted/reserved' sectors
only LBA-start sectors of system- and user-directory,
last valid sector and a few more data which I copy
1:1 direct to the drive-info block.
| Then when I create each "disk info block", simply check
| the boot_info_block's FS type. If this type matches the
| "disk info block" partitions FS, then do the compare on
| the remaining items.
| This should work as long as I make the information block
| detailed enough that no two similar partitions of same
| FS type on the same physical disk could be considered
| the same partition.
|
| Thanks, wolfgang, for your comments. This should give
| me enough to create what I am looking for.
You're welcome, good luck
__
wolfgang
Maxim S. Shatskih
> take the first one which is marked active as the sector
> to execute (very old BIOS may only accept the first entry).
BIOS just read the sector 0 from the active physical disk and jumps to it.
Nothing more. It is agnostic on MBR structure.
--
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
ma...@storagecraft.com
http://www.storagecraft.com
Maxim S. Shatskih
Bad indicator. There is no standard body to assign it, so lots of different
filesystems can have "FAT" or "NTFS" type byte. More so, NTFS reuses the HPFS's
type byte.
wolfgang kern
Hi Maxim,
| > Yes, BIOS reads just the four entries in the MBR and
| > take the first one which is marked active as the sector
| > to execute (very old BIOS may only accept the first entry).
|
| BIOS just read the sector 0 from the active physical disk and jumps to it.
| Nothing more. It is agnostic on MBR structure.
I got at least one BIOS ('Gentronic', looks like a MSI/Award clone)
which let me boot from extended partitions, it either is very smart or
just dedicated to a certain MBR format.
So what is my list of partition types worth then ?
__
wolfgang
wolfgang kern
Hi Maxim,
| > The partition type byte in the MBR is already a good indicator.
| Bad indicator. There is no standard body to assign it,
? I only know one MBR format on x86's,
the four 16 byte entries at offset 01be ...
+00 b7 = active bit;
+01 CHS boot sector (almost obsolete)
+04 main partition type
+05 CHS last sector (almost obsolete)
+08 boot sector
+0c total sectors
Can you please give me link where I can find other forms ?
| so lots of different filesystems can have "FAT" or "NTFS" type byte.
| More so, NTFS reuses the HPFS's type byte.
Yes my list shows even more:
07 Advanced Unix
07 OS/2 HPFS
07 HPFS
07 QNX
07 Windows NT NTFS
__
wolfgang
Maxim S. Shatskih
EFI-only and thus Itanuim-only.
What I was speaking about is the Type byte. Its values are not
standartized, though 7 is (according to modern MS's headers) - PARTITION_IFS,
so, any custom FS type can safely reuse 7. NTFS also does this.
--
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
ma...@storagecraft.com
http://www.storagecraft.com
"wolfgang kern" <now...@nevernet.at> wrote in message
news:d9pr3c$66n$1...@newsreader1.utanet.at...
wolfgang kern
Thanks Maxim,
| I know of no other MBR formats on x86. There is also GPT, but it is
| EFI-only and thus Itanuim-only.
| What I was speaking about is the Type byte. Its values are not
| standartized, though 7 is (according to modern MS's headers) -
| PARTITION_IFS,
| so, any custom FS type can safely reuse 7. NTFS also does this.
I wasn't quite sure about the MBR x86 standard ;)
| > | > The partition type byte in the MBR is already a good indicator.
So I rephrase:
The partition type byte in the MBR may be a good indicator to
detect your own FS if the value isn't already used from others.
I use 4Bh 'K' here, which matches the first character in the OEM-string,
and together with other things it keeps M$ away from my partitions.
But for my FAT-import/export I first check for valid partition-types.
__
wolfgang