NEW, experimental NTBOOTDD.SYS for USB booting

User FreddyV down at 911CD is trying to write a USB device driver to be able to USB boot on motherboards that have no or defective USB booting support.

The project is of course at it's beginning, but this is when anyone can help the most.

Please check this:
http://www.911cd.net...showtopic=20450
Specific post:
http://www.911cd.net...o...20450&st=58

And if you have the possibility to test and report, please do so.



jaclaz

Following are my reports:

Content of my bootable diskette:

a:\ntldr

a:\ntdectect.com

a:\ntbootdd.sys

a:\boot.ini

Content of boot.ini

[boot loader]

timeout=-1

default=scsi(1)disk(0)rdisk(0)partition(1)\windows

[operating systems]

scsi(1)disk(0)rdisk(0)partition(1)\windows="ntbootdd.sys scsi 1"

scsi(2)disk(0)rdisk(0)partition(1)\windows="ntbootdd.sys scsi 2"

scsi(3)disk(0)rdisk(0)partition(1)\windows="ntbootdd.sys scsi 3"

To make bootable CD from the diskette image I used UltraISO.

I did some experimentations with VMware and real machine:
- VMware XP with NO USB controller present
vmware_xp_no_usb_ntbootdd.jpg
- VMware XP WITH USB controller present
vmware_xp_with_usb_ntbootdd.jpg
- VMWare Vista WITH USB controller present
vmware_vista_with_usb_ntbootdd.jpg
- Real machine (Phoenix Bios), no USB disabled. This machine is capable of USB booting, and has 4 built-in USB2 ports.
laptop_l1_with_usb_ntbootdd.jpg
- Real machine (Insyde Bios), no USB disabled. This machine is capable of USB booting, and has 5 built-in USB2 ports.
laptop_l2_with_usb_ntbootdd.jpg

Maybe specialists need to look at VMware capability (at least with latest version 6.xx).
It detects on the fly my USB keys/HDD plugged inside the virtual machine.
Using VMware maybe useful for testing function like ntbootdd.sys ?


That's all folks! :-)

Excellent!

Don't have a machine to try out but I might find some "oldies" back at work on monday.

This means we can also use a CD with a floppy image emulation and call back to boot from USB?

This is a promissing work!

The idea FreddyV is implementing is very interesting (though I remember discussing ntbootdd option with jaclaz a while ago).
However, "talk is cheap"
Anyway, I think FreddyV was hoping to make it fast any easy and, actually, combined two different tasks:
- implement universal standalone (i.e. OS independent) USB support
- make ntbootdd that would use it.
If I were him, I would make working USB support in DOS and test it on verious PCs, having laxury of printing and runtime debugging.
Then I would port it to 32bit and make sure it's still working.
Only after that I would make ntbootdd out of it to deal only with specific Win issues.

However, he might be able to overcome it all together. Good luck to him

Alexei

I see it also as a practical multiboot solution.

Right now, USB support is in BIOS (on most USB compatible machines), some need to change boot order in BIOS before booting from a stick, some have a F12 or similar option to change boot order on-the-fly.

In both cases you need to remember enabling the boot option (unless you have set it "by default" in BIOS, not really advisable for security reasons).

By using this driver (when hopefully it will be "mature" ) you shift the boot device selection to the BOOT.INI choices, i.e. at the time when you normally make your decision on a multiboot system, and most probably you might be able to use the "signature" syntax so that only a certain stick will be able to boot from USB, a small but useful precaution for the same security reasons.

jaclaz

I see it also as a practical multiboot solution.

Right now, USB support is in BIOS (on most USB compatible machines), some need to change boot order in BIOS before booting from a stick, some have a F12 or similar option to change boot order on-the-fly.

In both cases you need to remember enabling the boot option (unless you have set it "by default" in BIOS, not really advisable for security reasons).

By using this driver (when hopefully it will be "mature" ) you shift the boot device selection to the BOOT.INI choices, i.e. at the time when you normally make your decision on a multiboot system, and most probably you might be able to use the "signature" syntax so that only a certain stick will be able to boot from USB, a small but useful precaution for the same security reasons.

jaclaz

I don't think it would work this way As I understand, you meant booting from HDD, but using NTBOOTDD from the stick (if you place your NTBOOTDD on HDD it will be used for all bootings). However, you can probably do it by "switching" boot to stick's boot record, same way as booting DOS (or something similar).
However, anyway, it would be a problem with booting speed, without USB 2.0 EHCI it's gonna be terribly slow
I would say, CD+USB boot is much more preferable, especially, if you boot small compressed NTFS ram-disk hard linked to the stick.

BTW, is there any chance to make something like "Compressed NTFS CD hardlinked to the USB stick"???


Alexei

@Alexei
No, AFAIK, NTBOOTDD.SYS is used only if "scsi" or "signature" syntax is used, never for "multi" one.

Reference:
http://support.micro...b;en-us;q102873

Using SCSI() notation indicates that Windows NT will load a boot device driver and use that driver to access the boot partition.

On an x86-based computer, the device driver used is NTBOOTDD.SYS, which can be found in the root of the system drive (generally of drive C) and is a copy of the device driver for the drive controller in use.

http://support.micro...kb/227704/en-us

The signature() syntax is equivalent to the scsi() syntax, but is used instead to support the Plug and Play architecture in Windows. Because Windows is a Plug and Play operating system, the SCSI controller number instance may vary each time you start Windows, especially if you add new SCSI controller hardware after Setup is finished.

Using the signature() syntax instructs Ntldr to locate the drive whose disk signature matches the value in the parentheses, no matter which SCSI controller number the drive is connected to.

jaclaz

@Alexei
No, AFAIK, NTBOOTDD.SYS is used only if "scsi" or "signature" syntax is used, never for "multi" one.

Reference:
http://support.micro...b;en-us;q102873


http://support.micro...kb/227704/en-us


jaclaz

It seems, you're right. BTW, it's latest, November 1, 2006 version of this article.
I studied those issues 2-3 years ago, and as I remember, those details were not present.
BTW, do you know how signature syntax corresponds to signature bytes in the MBR?. An example would be nice

Alexei
PS
Can't "regular" USB driver (usbstor?) be used as NTBOOTDD and why?

It seems, you're right.

You actually doubted it?



Cannot say if the info was already there in the past, but I can guarantee that that info is correct at least dating back to NT 4.00.

BTW, do you know how signature syntax corresponds to signature bytes in the MBR?. An example would be nice

Yep, sure, read here (same info is also used for \DosDevices Registry key):
Posts:
http://www.911cd.net...o...181&st=1891
up to here:
http://www.911cd.net...o...181&st=1896

http://www.911cd.net...o...4181&st=594
up to here:
http://www.911cd.net...o...4181&st=637


Entire threads:
http://www.911cd.net...showtopic=20094
http://www.911cd.net...showtopic=19663

These might interest you as well:
http://www.911cd.net...showtopic=13612
http://www.911cd.net...o...181&st=2045

Can't "regular" USB driver (usbstor?) be used as NTBOOTDD and why?

No, if you read "around" the linked posts in the HUGE XP from USB thread:
http://www.911cd.net...showtopic=14181
you'll see Dietmar's experiences with this approach (unfortunately ended in failure )

Basically, NTBOOTDD.SYS needs to be a "monolithic" driver, whilst the USB driver(s) are several files:
USBSTOR.SYS
and
USBHUB.SYS
and/or
USBHUB20.SYS
and either of:
USBEHCI.SYS
USBOHCI.SYS
USBUHCI.SYS
and maybe some more.

and till today noone has found a way to "combine" them together.

Some related posts (actually pointers inside the HUGE thread):
http://www.911cd.net...o...181&st=1192
http://www.911cd.net...o...181&st=1242





jaclaz