identifying USB boot device

[boro...@gmail.com]

Ideally, I'd like to be able to determine which device is the boot
device. For example, if I boot from a USB stick, I want to know how
to map the INT 13h drive number in DL to a USB device ID. Is there
any *universal* way of doing this? Note: im not interested in
proprietary techniques that may or may not work depending on vendor
support/brand, etc

Regards
B

[Alexei A. Frounze]

If you have unique serial numbers in the boot sectors, that'll help
you to determine the correspondence between the two "addresses" - just
see which two lead to the boot sectors with the same serial number.

Alex

[boro...@gmail.com]

On Nov 20, 10:59 pm, "Alexei A. Frounze" <alexfrun...@gmail.com>
wrote:

I suspected that this was the only way to do it. So, in other words,
for each boot sector written to a device, incorporate a unique
identifier, perhaps with the date and time of creation with an
additional random number, similar to how COM uses GUIDs?

How reliable are INT 13h extensions for mapping between the two ID's
for other devices? For example, I notice that you *should* be able to
map physical device to BIOS ID using INT 13h func 48 for ATA/ATAPI
devices, because it provides you with info on the I/O ports for the
device.

Finally, its seems rather primitive to have to have the OS determine
its own boot device with unique numbers in the boot sector. Is this
situation improved in newer 64-bit machines?

Regards,
B

[Alexei A. Frounze]

Never got that far, don't know.

> Finally, its seems rather primitive to have to have the OS determine
> its own boot device with unique numbers in the boot sector. Is this
> situation improved in newer 64-bit machines?

I would expect something in EFI, but that's only my hypothesis.

Alex

[Maxim S. Shatskih]

MBR table has "MBR signature", which is used by Windows to assign the drive
letters to the volumes. It is nearly the unique ID - unique machine-wise.

--
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
ma...@storagecraft.com
http://www.storagecraft.com

<boro...@gmail.com> wrote in message
news:9143b2bd-b6ba-4e6f...@d21g2000prf.googlegroups.com...

[Andreas Grögel]

boro...@gmail.com wrote:
> How reliable are INT 13h extensions for mapping between the two ID's
> for other devices? For example, I notice that you *should* be able to
> map physical device to BIOS ID using INT 13h func 48 for ATA/ATAPI
> devices, because it provides you with info on the I/O ports for the
> device.

Yes, *should*. But I've seen many cases where the Int13Ex BIOS
functions don't tell you that.

--
Grüße,
Andreas

[boro...@gmail.com]

On Nov 21, 5:52 pm, "Alexei A. Frounze" <alexfrun...@gmail.com> wrote:

> I would expect something in EFI, but that's only my hypothesis.
>
> Alex

I had the same hunch, so I have downloaded the spec and will browse
through it. I'll let you know if there is anything interesting in
there pertaining to this issue.

Regards,
B.

[boro...@gmail.com]

It seems that EFI solves this issue. A boot image is called from the
firmware and is passed two parameters, a pointer to the EFI System
Table (general global stuff) and an image handle, which allows the
boot loader to know where it came from (ie, the image handle provides
access to the boot images device path)

While it probably wont be mainstream for a while, I can't wait for the
day that the BIOS (and BIOS services) are dead

Regards,
B.

[Alexei A. Frounze]

:) Will never happen. The EFI isn't that much different from the BIOS
after all. And don't forget about hardware bugs that will need to be
solved by software (OS, BIOS/EFI, SMM code, CPU microcode and so on).

Alex

[boro...@gmail.com]

On Nov 23, 7:43 pm, "Alexei A. Frounze" <alexfrun...@gmail.com> wrote:

> :) Will never happen. The EFI isn't that much different from the BIOS
> after all.

While the EFI will probably be implemented by a BIOS-like hardware/
firmware device, I'm not sure how you can say that they are the same.
The interface is completely different. There is no INT xx services
and no 16-bit code. I welcome anything that fixes this whole boot-
time mess.

Regards,
B.

[Alexei A. Frounze]

What I meant was that some hardware specific code will still be there
(whether BIOS/EFI or not) and you won't get a bare machine. In that
sense, BIOS = EFI and it will live forever. But I agree, all this
ancient BIOS stuff is too primitive and low-level.

Alex

[rob.h...@comcast.net]

It would be nice to finally get a bare machine, especially if one
could go right to long mode. I haven't looked too much at EFI, but
didn't Apple's ppc firmware solution (OpenFirmware?) solve the issue
of having a consistent view of the machine upon startup? IIRC, each
device would load it's own mini-driver during the boot sequence.

I suppose the real answer here is that no one's in a big hurry for EFI
(except Apple), since by and large, this is a solved problem.
Microsoft has their own boot solution, and the open source crowd has
Grub. It's only the people around here that even notice, since we're
constantly trying to reinvent fire.