41 replies to this topic

[steve6375]

@Steve

I will try retyping it slowly:

It seems to me that "a working USB 2.0 driver" means a driver "working" and "working at USB 2.0 speed".

In my perverted mind, if the BIOS USB 2.0 driver is working at 1.1 speed, then it is not working, but the number of such motherboards (having USB 2.0 capable chips BUT having a BIOS USB 1.1 speed driver are not that much common anymore).

 

 

 

Well my Asus EeePC 904HA BIOS can access files 100 times in a loop in 5 seconds, but with the grub4dos usb driver it does it in under 2 seconds.

100 loop  ls /file test (BIOS times)

Asus EeePC = 5sec
Acer Aspire 7741G = 2sec

 

The EeePC also can boot from a USB HDD or Flash drive, but it cannot access sectors past 137GB (which is a very common bug with many BIOSes it seems). e.g. AWARD V6.00PG BIOS

In both cases the USB boot section of the EeePC BIOS could be described as 'working' as it does boot at a reasonable speed and does work - but it has bugs and is not particularly fast.

The very slow system that I mentioned was a reasonably modern system as it had USB 3 ports but seemed to have a problem with a particular make of USB Flash drive (which the grub4dos driver did not).

 

See posts by Jon and Neil on the E2B forum - http://www.easy2boot.com/forum/

 

Plop! is a read-only driver - it is not compatible with E2B or any grub4dos command that writes to the USB drive like default or dd or partnew.

[Wonko the Sane]

Which still means in plain enough English, besides in my perverted mind, that that particular machine BIOS does NOT provide "a working USB 2.0 driver", but most probably "a working USB 1.1 driver", or "a working driver BUT limited to USB 1.1 speed, i.e. NOT working at USB 2.0 speed".
 
The Asus Eeepc 904HA is - unless I am mistaken - a 5 year old or so machine, I claim that "not much common anymore" implies an event horizon smaller than 5 years .

I further claim that:

If you have issues with grub4dos internal driver, do try (as Steve mentioned ) PLoP, it is relatively easily chaiinloadable from grub4dos and while somewhat "reducing the range of possible booting methods" should work fine in your setup.

represents a "short version" of:

Plop! is a read-only driver - it is not compatible with E2B or any grub4dos command that writes to the USB drive like default or dd or partnew.

 

 

I tested with 0.4.6a-2014-11-19 version and the problem is gone
In fact with this driver all menu.lst entries seem to work fine.
With Plop more than half of them don't work.

And, yes, I have tested and all the USB ports behave the same way.

Very good.
 

Wonko

[Wonko the Sane]

@DavidB

 

Back to topic, cannot say how much this is connected with the "red" device , but maybe the issue is with your port(s):

http://www.techpower...on-chip.203659/

 

Plug into a usb3.0 port.. this is critical. YOU MUST USE USB3

 

 

Wonko

[DavidB]

It may be the solution, but for now I can't test because I don't have a USB 3 port on my mainboard...

[DavidB]

Now, to be offtopic again:   

I use this way to load the usb 2 driver:

menu.lst:

if not "%MAINRAN%"=="1" set USB2DRV=False > nul
if not "%MAINRAN%"=="1" set MAINRAN=1


title Enable USB 2.0 internal driver
configfile /usb2load.lst

usb2load.lst:

clear
if "%USB2DRV%"=="True" echo USB 2.0 internal driver already started...
if "%USB2DRV%"=="False" usb --init && set USB2DRV=True > nul && echo -e
pause --wait=5
configfile /menu.lst

title
root

2 questions:

1. Is there a way to detect if "usb --init" failed or not? Because in my code it sets USB2DRV to True in both situations.
I mean other than searching keywords with "cat" into the text outputed by the function...
2. Is there a fast and sure way to detect that Grub4DOS is started on a different mainboard?

[steve6375]

The message output by --init is dependent on the debug level (1 = message is output).

 

What do you mean by 'different mainboard'? Different make/model/chipset?

You still can't tell if they are connected to USB 2 or USB 3 port.

 

You can look at bytes in the BIOS to get the BIOS date, or search for certain strings or you could check the PCI ID of the USB controller.

[DavidB]

The message output by --init is dependent on the debug level (1 = message is output).

 

I haven't set the debug level, so it's the default.

 

What do you mean by 'different mainboard'? Different make/model/chipset?

You still can't tell if they are connected to USB 2 or USB 3 port.

 

You can look at bytes in the BIOS to get the BIOS date, or search for certain strings or you could check the PCI ID of the USB controller.

 

 

I boot with the flash drive many times on the same computer. So it make sens to set it to automatically load the driver (if it's working fine on that computer) instead of manually loading it every time.
But, if the code detects another computer, it should not automatically load it. Until I set it again.

[steve6375]

The usb --init driver code should (??) work on any system that has the same USB controller in it's chipset.
So you could check for the same USB controller and run usb --init if it is a match (or matches a list).
The grub4dos chkpci will list all PCI devices, and the PCI Class Code will contain the part-string &CC_0C03
See http://wiki.osdev.org/PCI for the class codes

e.g.
/utils/chkpci > (md)0x220+1
cat --locate=VEN_xxxx&DEV_yyyy (md)0x220+1 && usb --init

however, I have seen problems if executing usb --init more than once and behaviour can change if it is not a fresh (hard) reboot (rather than a warm (soft) reboot), so I would keep the USB2DRV variable.

[Wonko the Sane]

Random thought, but maybe the output of usb --init when the usb --init has already been run is not a "failure".

 

What about using iftitle in the "main" menu.lst?

 

*like*:

 

iftitle [if not exist USB2DRV] Enable USB 2.0 internal driver

usb --init

set USB2DRV=True

configfile /menu.lst

 

this should allow only one usb --init per boot.

 

Wonko

[DavidB]

steve6375, on 24 Nov 2014 - 8:00 PM, said:

The usb --init driver code should (??) work on any system that has the same USB controller in it's chipset.
So you could check for the same USB controller and run usb --init if it is a match (or matches a list).
The grub4dos chkpci will list all PCI devices, and the PCI Class Code will contain the part-string &CC_0C03
See http://wiki.osdev.org/PCI for the class codes

e.g.
/utils/chkpci > (md)0x220+1
cat --locate=VEN_xxxx&DEV_yyyy (md)0x220+1 && usb --init

however, I have seen problems if executing usb --init more than once and behaviour can change if it is not a fresh (hard) reboot (rather than a warm (soft) reboot), so I would keep the USB2DRV variable.

Thank you for the idea

Wonko the Sane, on 24 Nov 2014 - 9:06 PM, said:

Random thought, but maybe the output of usb --init when the usb --init has already been run is not a "failure".

What about using iftitle in the "main" menu.lst?

*like*:

iftitle [if not exist USB2DRV] Enable USB 2.0 internal driver
usb --init
set USB2DRV=True
configfile /menu.lst

this should allow only one usb --init per boot.


Wonko

I usually avoid using iftitle's because they are slow, especialy when USB speed is low.
Are you sure it will not access the drive searching for a file called "USB2DRV"...?

LE: I checked and it's loading the menu slower; during this the LED is blinking. So it seems it is accessing the drive searching for the file...

[Wonko the Sane]

The actual operation performed is the "if exist", which should be able to distinguish between a file or a variable.

 

But you can use:

iftitle [if not "%USB2DRV%"=="True"] Enable USB 2.0 internal driver

...

 

If you don't like the iftitle you can still have something *like*:

 

"main" menu.lst:

 

title Enable USB 2.0 internal driver

configfile /usb2load.lst

 

usb2load.lst:

title Load USB 2.0 driver

echo loading ...

if "%USB2DRV%"=="True" echo You dumbass, it has been already attempted to load! &; pause --wait=5 &; configfile /menu.lst  (or if exist USB2DRV .... )

set USB2DRV=True

configfile /menu.lst

 

 

The operators  ";;": "&;" "|;"

http://reboot.pro/to...space-operator/

 

Wonko

[steve6375]

LE: I checked and it's loading the menu slower; during this the LED is blinking. So it seems it is accessing the drive searching for the file...

AFAIK if exist fred should not cause a file access

if exist fred

executes almost instantaneously (in a loop of 10,000 passes = 3 seconds - LED does not flash)

if exist /fred

takes 2 seconds for 100 loops under VBox on my notebook.

I have tested this in a grub4dos batch file. iftitle should be the same???  The menu.lst file may be loaded twice though, just by using  iftitle (unsure?).

[DavidB]

The actual operation performed is the "if exist", which should be able to distinguish between a file or a variable.

But you can use:
iftitle [if not "%USB2DRV%"=="True"] Enable USB 2.0 internal driver
...

 

Hmm, that could work...
 

AFAIK if exist fred should not cause a file access

if exist fred

executes almost instantaneously (in a loop of 10,000 passes = 3 seconds - LED does not flash)

if exist /fred

takes 2 seconds for 100 loops under VBox on my notebook.
I have tested this in a grub4dos batch file. iftitle should be the same??? The menu.lst file may be loaded twice though, just by using iftitle (unsure?).

 

It will search the file into the current folder.
I tested: I added 7 iftitle's to the menu. The menu loading time was increased by more then 10 sec. At 1.1 speed is normal. At 2.0 and in VBox may not be so noticeable...
Also, my impression is iftitle is not using the "readings" from the drive in the next search (buffer/cache).

[steve6375]

well

if exist menu.lst echo 1

does not echo 1

if exist /menu.lst echo 1

does echo 1

set menu.lst=x
if exist menu.lst echo 1

does echo 1

 

so it should only be checking for the variable.

 

It might be that just using iftitle is causing the .lst file to be read more often? grub4dos looks for all iftitle's first and after executing each one in turn, I think it then loads the whole .lst file again and executes the initial lines and displays the menu entries.

 

I put in loads (50) of iftitle [if exist ccc] entries and it did not access the USB drive during executing these - however it does seem to take an age to process the iftitle statements (25 seconds under QEMU). The LED did flash once the preprocessing had finished (reloading the menu.lst?)

I then replaced the if exist cccc with nothing, i.e.

iftitle [] xxx

The result was very similar (25 seconds under QEMU), 2-3 seconds under VBox.

replacing iftitle []  with just title  resulted in the 25 second delay reduced to just 1 to 2 seconds before the menu appeared using QEMU  (and v quick using VBox).

So for some reason, using iftitle seems to be executing a large amount of code for each iftitle entry.

[DavidB]

That reminds about something I said more than a year ago:

 

http://reboot.pro/to...e-2#entry172126

[Wonko the Sane]

That reminds about something I said more than a year ago:

 

http://reboot.pro/to...e-2#entry172126

Which allows me to bring this even more OT.

 

JFYI Chenall re-engineered/rewrote PassPass 1.2 removing the need for WENV:

http://reboot.pro/to...sword/?p=188197

including some mods to the included findverdll snippet which may further speed up things.

 

Wonko

[DavidB]

@DavidB

 

Back to topic, cannot say how much this is connected with the "red" device , but maybe the issue is with your port(s):

http://www.techpower...on-chip.203659/

 

 

Wonko

 

 

 

Well, I just tried again on a laptop with a USB 3.0 port (blue).
FixedDisk_v1003 still shows Fail after I click on the 2 buttons with "Fixed", Phison_MPALL_V3.63_PS2251-67 still show that red issue...

So the problem is not from using a USB 2.0 port...