29 replies to this topic

[kolk]

Hello!

How to make booting from USB 2.0 faster if BIOS only supports 1.1?

For Linux it's keeping initrd slim.
For DOS it is loading big ramdisk after USB 2.0 drivers.
For EWF XP it's OK

But how to do it for XP RAM (SDI or IMA) booting?
You can make copies of all pre-big-switch files outside of the image and boot same way as to EWF mode.
But how to load image after the big-switch?

Or may the solution be loading a bootable SDI from DOS?

I am trying to kexec SDI (I added SDI format support), but for now it just reboots.
SysLinux (I applied the patch to 2.13) loads the same SDI OK.

Thank you!

[Brito]

How would an SDI boot straight from DOS and keep memory of the image when the kernel is initiated?

----

As far I see things, the best chance for getting this to work is using the FREELDR from the ReactOS code to provide the SDI boot capability and also add support for USB 2.0 drivers.

http://en.wikipedia....startup_process
http://www.reactos.o...er_37.html#sec3

[Galapo]

Yes, hopefully we'll soon be able to ditch 2k3 'setupldr.bin' for 'FREELDR'! We'll also need a replacement for 'ramdisk.sys'.

Regards,
Galapo.

[was_jaclaz]

Yes, hopefully we'll soon be able to ditch 2k3 'setupldr.bin' for 'FREELDR'! We'll also need a replacement for 'ramdisk.sys'.

Regards,
Galapo.

Most probably we don't , there is a report by Bilou Gateux somewhere on the board that he uses successfully a XP version insted of the 2003 one.

Olof also thinks that IMDISK with small changes could be used as well, check this thread:
http://www.911cd.net...showtopic=19960

jaclaz

[kolk]

How would an SDI boot straight from DOS and keep memory of the image when the kernel is initiated?

Which of kernels?
DOS kernel was loaded before SDI.
Then SDI is loaded with grub4dos (with map command, if it is able to use filesystem or disk drivers provided by DOS instead of BIOS ones) or in LoadLIN way. When control is transferred to SDI (or ntldr inside IMA), we can forget about DOS.
Following then this is known good process
SDI RAM boot

[was_jaclaz]

Please, no, not again.

Please do read this:
http://www.boot-land...?...=2692&st=26


Now, the good news is that we may have a new way for USB booting using native (read USB 2.0) XP drivers, using a "Kansas City Shuffle":
http://www.911cd.net...o...c=21242&hl=



jaclaz

[kolk]

IMHO, NT Ramdisk can be booted with any OS-independent filedisk drivers:
1. OS-independent filedisk provides int 13
2. ntldr loads /rdpath=*.ima inside that filedisk into RAM and serves it
3. after the big-switch, "internal" .ima is served by Ramdisk.sys
4. IMHO, OS-independent memdisk can be used too, but after step 3 we will have two in-memory copies of the image. Maybe first copy is gone after step 3.

[kolk]

Now, the good news is that we may have a new way for USB booting using native (read USB 2.0) XP drivers, using a "Kansas City Shuffle":
http://www.911cd.net...o...c=21242&hl=



jaclaz

This hack is placing pre-big-switch files into ramdisk, I'm asking for opposite

[was_jaclaz]

Well, no, you need anyway a NT driver, which is the missing step .

Maybe deeply modifying memdisk to be used as RAMDISK.SYS may work, but cannot say, the modifications will make it become a NT kernel driver, and so we are back to square one, that originated the search for a filedisk/ramdisk driver.....
http://www.boot-land...vers-t1507.html

Besides the already linked to thread on IMDISK, there is also this one:
http://www.boot-land...?...ic=1441&hl=
which was the one I was referring to earlier where the finding by bilou gateux is referenced and this one:
http://www.boot-land...?showtopic=3142
(just fixed the links corrupted by the "stupid" board update)

However, the "fast USB 2.0" boot is now solved using s4e's/Dietmar's method referenced above, it is still very experimental, but it does work, I know you are asking for something different, but AFAIK the solution you want, the way you want, does not exist (yet ) so I am just giving you what is available.

jaclaz

[kolk]

IMHO, the solution is simpler.

Lets assume that we will use Ramdisk.sys as NT driver.
And that ramdisk is just flat memory region containing a file system.

All we have to do is to pass it's start address to ntldr.
(I think to real-mode portion).

There is one documented way: use 3-BLOB SDI.
I think other ways exist (0x41 is not the only flag checked by Startrom.com at very beginning,
and may be it could point not only to '$SDI0001').

But even 3-BLOB SDI is enough, we can hack, say, LoadLIN, to support it's format or just convert SDI to bzImage format:
1. Put Microsoft's sample loader in front of SDI to make it linux System-like.
2. Remove unneeded code from Setup.
3. Run through remaining steps of make bzImage (System->zSystem->bzImage).
Or hack Anvin's memdisk to not contain the int 13 handler but instead pass control to an SDI BOOT BLOB.

[was_jaclaz]

Yep, everything is possible, and the approach you describe is simpler, or to be more exact, it will be simpler when you'll have found a way to make it work, as a "general" solution.

Using Ramdisk.sys is actually pointless, as I see it, as it is limited anyway to 512 Mbytes and however there will be memory (RAM) requirements that will make a RAM based solution unusable on older machines, which quite coincidentally are those that have only USB 1.1 support.

The "right" way as I see it is using a "filedisk" driver that has not such limits, but in this particular context, (using USB 2.0 drive speed on motherboards that only have BIOS support for 1.1) BOTH approaches are pointless , what you need is to find a way to load USB 2.0 speed enabled drivers to access the USB device, i.e. find a way to speed READING independently from where the data will be written to.

jaclaz

[ktp]

Thanks to this thread I discover the problem of slow USB 1.1 booting with some BIOS.
I use BartPE/VistaPE image (.ima) booting method (200 MB). On one machine (6-year old, 512MB RAM) it boots very fast, on the
other (newer, 2 GB RAM, 2007) it takes really long !

But booting Knoppix is OK (fast) on both machines.
Booting XP is a little slow at the beginning on the newer machine (the blank progression bar at about 1/10), then afterwards it progresses quickly. XP booting is real fast on older machine.

From the information in this thread, I understand that probably Knoppix loads USB 2.0 driver at the very beginning, and so probably XP does.
BartPE/WinPE probably loads USB 2.0 drivers at the end, so the 200 MB ima file has to be read entirely first.

Is this correct ?

[kolk]

Yes, you are right!

For Knoppix the USB 2.0 (EHCI) driver is in small initrd image.
For XP there is relatively short list of files loaded before switching to 2.0 drivers:
http://www.911cd.net...o...c=21242&hl=

But for loading .iso or .ima or .sdi we depend on BIOS.
At that point the only loaded file is ntldr which contains no block device drivers.

[was_jaclaz]

Is this correct ?

Partly.

If you use " .ima" file, it means you use RAMDISK.SYS.
Thus the image is first copied to RAM and then booted.
The copying is done by the SETUPLDR.BIN/NTLDR (i.e. during the "text-mode" or "real mode" part of booting) thus the BIOS routines are used.

If the BIOS routines support USB 2.0 speed the copying will be fast, if they use USB 1.1 speed. it will be slow.

jaclaz

[kolk]

Finally I found this post:
http://www.911cd.net...=40#entry138466
which explains how to build 3-media solution:

Step 1. You insert USB filesystem and DOS floppy. DOS copies filesystem to ramdisk, served by DOS driver.
Step 2. You exchange floppy and type "boot". Then ntbootdd.sys serves preloaded ramdisk.

[ktp]

@kolk

Do you mean that now there is a solution to the slow USB 1.x boot by BIOS ?
If yes, could you put more details on how to do it ?

[kolk]

@kolk

Do you mean that now there is a solution to the slow USB 1.x boot by BIOS ?
If yes, could you put more details on how to do it ?

In referred topic it was also noted that DOS->ntldr switch is possible
with debug script (I suppose simple load of whole binary to 0:7c00 and then
jumping here).

IMHO, switching from BIOS to loadable DOS driver is already solved DOS problem

[kolk]

IMHO, switching from BIOS to loadable DOS driver is already solved DOS problem

Really, we have to load DOS FAT ramdisk before copying of NT filesystem to it.
So we can load it just before loading the DOS drivers, copy DOS stuff to it
(command.com, devload (sorry, I don't remember Microsoft's one) and the drivers). In the next step we load drivers and copy NT, ntldr and debug to ramdisk.
Then we should be able to boot NT.

[kolk]

In the next step we load drivers and copy NT, ntldr and debug to ramdisk.

I'm sorry, there is no need to copy ntldr and debug
Also we can delete the drivers and command.com from ramdisk after loading.
We can use them residing on source media.

[windrv]

The best way is to buy a machine with fast USB 2.0 support.

Save the time to earn more money for that!

Computer hardware is really cheap these days.

Time is rather precious on the other hand!

[kolk]

The best way is to buy a machine with fast USB 2.0 support.

That's not such simple.
I must boot a machine from USB before buying.
And if I buy a motherboard alone for assembling myself, I don't know how to check

Could you point us to table which shows presence of EHCI BIOS for different models & manufacturers?
Because some manufacturers can stay long with UHCI-only BIOS...
Or may be even with UHCI drivers over SMM-emulated UHCI over EHCI-only hardware.

[was_jaclaz]

Time is rather precious on the other hand!

A very good reason NOT to waste some of yours posting advice on what other people should do with theirs.

Most of the time spent here on projects is "fun" time, even if it's not commercially or economically a smart idea, it is something most people do as a hobby, to learn and experiment something.

Sometimes it is not important where you arrive, but how you got there.

jaclaz

[windrv]

That's not such simple.
I must boot a machine from USB before buying.
And if I buy a motherboard alone for assembling myself, I don't know how to check

Could you point us to table which shows presence of EHCI BIOS for different models & manufacturers?
Because some manufacturers can stay long with UHCI-only BIOS...
Or may be even with UHCI drivers over SMM-emulated UHCI over EHCI-only hardware.

May be The Finder could help you in this respect.

[windrv]

A very good reason NOT to waste some of yours posting advice on what other people should do with theirs.

Most of the time spent here on projects is "fun" time, even if it's not commercially or economically a smart idea, it is something most people do as a hobby, to learn and experiment something.

Sometimes it is not important where you arrive, but how you got there.

jaclaz

Yes! That is good for amusement and education purpose and as a hobby.

Spending a little of my time on advising lots of people not wasting their precious time is an act out of my good motive! may be you could construe it otherwise.

[ktp]

I'm sorry, there is no need to copy ntldr and debug
Also we can delete the drivers and command.com from ramdisk after loading.
We can use them residing on source media.

So to summarize, finally is there a solution to boot BartPE from USB key with USB 2.0 speed while the BIOS boots only with USB 1.0/1.1 speed ?