grub-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Missing USB devices.


From: Aleš Nesrsta
Subject: Re: Missing USB devices.
Date: Sat, 31 Aug 2013 00:07:40 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130806 Thunderbird/17.0.8

Hi guys,
sorry for the delay - I was too busy on business trip...


Vladimir:
...
I am waiting mainly for Vladimir's "Go on!" :-)
I don't see any messages in mymailbox from you tagged as pending
patches. Can you tell me the date and subject?
Oh, sorry, maybe I missed something. (Exists/Are somewhere written some exact rules how to ask for patch commit?)

I sent the patch for testing at 18.7.2013 18:10 CET in ML thread named "[PATCH] Re: [grub-devel] loongson-2f mini-pc (fuloong) elf image generation.". And I wrote some comments related to it at 23.7.2013 23:05 CET in the same thread.
But, you are right, nowhere is some exact asking for patch commit.


Christian:
I'm thinking of the EHCI hand-over. In the case of EHCI handover beeing 
successful within the timeout, you never clear the USBLEGCTLSTS register 
(SMI's). You do that in the other cases however. Why? I can not think of any 
case of a successful handover with SMI's still enabled. To what purpose? A 
buggy BIOS would maybe act upon such stuff? Maybe thats a case for lost devices 
etc?
Yes, it could be the bug.

But it is the question:

1) I expect BIOS disables all related SMI during handover procedure of EHCI (or OHCI, it has similar procedure). AFAIK, EHCI (and possibly also OHCI) specification doesn't say anything about resetting of SMI bits by OS after handover procedure - but maybe it is common thing which it is not worth mentioning.

2) According to the specification, default state of SMI bits should be 0 -> i.e., after EHCI reset (which is done immediately after ownership handover) I expect these bits should be 0. But maybe I am wrong. - ?

Did you try this change? You are probably experienced programmer, so I expect such change should be not problem to you... :-) What result did you get?


Also, I've been toying with the black magic EHCI hand-back. I've gotten it to 
work for some machines. The problem with GRUB and USB is that if you enable USB 
you have no more control over USB in case a OS needs input before loading it's 
own USB stack. Do you have any experience with this? Could we make such code 
execution optional on environment etc (because hand back is even more buggy 
than everything else.. :)) Maybe users can use it in corner cases when they 
need USB-input with usb-support in GRUB... if it'll work on their hardware that 
is.
I don't understand this part - What do you mean by (black magic) EHCI hand-back? Do you mean procedure which returns EHCI ownership back to the BIOS (SMM) ? Oh, maybe I understand in this case - You are probably pointing to the situation when some OS boots and it wants some input from keyboard to select something in boot process - is it correct? Hmm, maybe it can happen, but I didn't see such situation yet - but I am not expert nor OS experimenter/developer etc. :-) AFAIK, USB drivers are loaded very early or they are (at least can be) integral part of any nowadays kernel. I.e., I think such situation can happen only in some very very special cases, so it is the question, if we should spent our time to try to solve it - or?


BR,
Ales



reply via email to

[Prev in Thread] Current Thread [Next in Thread]