grub-devel
[Top][All Lists]
Advanced

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

RE: EHCI handoff & AMI BIOS EHCI Handoff support.


From: Melki Christian (consultant)
Subject: RE: EHCI handoff & AMI BIOS EHCI Handoff support.
Date: Tue, 15 Oct 2013 08:31:09 +0000

Ales,

This is a little bit exotic yes. :)
I have recommended the feature be turned off for machines that have this option 
in BIOS. Running GRUB (with EHCI module loaded), which is capable of proper 
handover, this feature should not be turned on. I think regardless of OS GRUB 
is booting. Since we leave the controller in OS_OWNED when booting, it should 
be safe for any OS to start using it. GRUB does not try to do handback, even 
though I'd like such a feature. :) I have changed the code flow a bit and while 
it seems to help, I cannot guarantee that all BIOS code behaves the same. Im 
trying to get more information on the code from AMI. But you are right, 
changing this code without more information is likely to break more things than 
fixing it. Linux does not care about this case. The handover is quite identical 
as it stands now.

Regards,
Christian

> Hi Christian,
> 
> yes, I have seen such BIOS feature somewhere some time ago.
> I think the best workaround is to disable this feature... :-) Of course, if 
> you
> have installed some OS without proper support of EHCI handoff, you cannot
> do this - but, from the opposite side, do you need GRUB in this case?
> You are doing something little bit exotic, doesn't? :-) (OK, it may happen 
> e.g.
> in the case when you do some emergency/rescue boot from CD-ROM or USB
> on machine with some older OS.)
> 
> 
> More seriously (if I good understood your e-mail...):
> 
> I am not sure that proposed change(s) will help. Did you try it?
> BIOS probably will not expect that the OS will "touch"/use the USBLEGSUP
> register in this case.
> There is also the question, if the USBLEGSUP ownership is really set to OS at
> the BIOS usage time when EHCI handoff feature is enabled.
>  From the opposite side - proposed EHCI code change(s) will probably don't
> cause any harm on other "normal" machines - but, to be sure, I recommend
> to test first it on some different machines.
> 
> 
>  From my point of view - my guess:
> If this feature is enabled, BIOS have to detect the moment when "somebody
> else" accessed EHCI - to "unlink" BIOS from EHCI. So, I think we should first
> have to know the answer of the question: how the BIOS detects that OS
> wants to use EHCI - ?
> And, additionally - does it all BIOSes in the same way?
> 
> Could be the OS access detection done e.g. by BIOS SMI - ? If yes, then we
> probably should to do some access to EHCI register(s) first with SMI enabled
> and wait if happens some BIOS-itself handoff - ???
> But such code may be possibly dangerous and should be used only in related
> cases - can we reliably detect such case?
> 
> I am afraid we cannot do anything useful if we don't have more detailed
> information about this BIOS feature. (Maybe we can try to look inside Linux
> EHCI driver if there is solved such case - ? There is lot of "quirks" - but I 
> didn't
> mentioned something like "BIOS handoff support"
> there in past...)
> 
> BR,
> Ales
> 
> On 10/14/13 09:58, Melki Christian (consultant) wrote:
> > Hi.
> >
> > Im having trouble on one machine which has an AMI-BIOS with a function
> called "EHCI Handoff support". Sometimes the machine hangs in usb
> controller init.
> > Technically I think the function is meant to support OS without proper
> handoff support (windows xp pre sp2 or something). The problem is that I
> dont know how they do it.
> > USB Legacy support is meant to be disabled once OS gets EHCI control
> otherwise all hell will break loose with two drivers managing one EHCI
> controller.
> > This function (I think) makes BIOS set OS_OWNED bit and release the
> control once it thinks someone is trying to manage the controller besides
> BIOS.
> > The problem (again, I think) is that GRUB does not do anything if the
> OS_OWNED flag is set thereby sending no signal at all, relying on BIOS getting
> it right to stop playing with the controller.
> > A solution would be in EHCI initialization instead of doing:
> >
> > if (usblegsup & GRUB_EHCI_BIOS_OWNED)
> >
> > it should be:
> >
> > if (usblegsup & (GRUB_EHCI_BIOS_OWNED || GRUB_EHCI_OS_OWNED))
> >
> > because technically, GRUB is running and nothing really should matter.
> > We could even do:
> >
> > if (usblegsup) { ...}
> >
> > Because all cases are the same. We need to send a signal, no matter the
> state of the current settings.
> > The relevant part is to test the settings once the signal has been sent, it
> should contain GRUB_EHCI_OS_OWNED only.
> > But I think we cannot ignore to write the register even if it's already set
> because of the above specified function.
> >
> > regards,
> > Christian
> >
> > _______________________________________________
> > Grub-devel mailing list
> > address@hidden
> > https://lists.gnu.org/mailman/listinfo/grub-devel
> >
> 
> _______________________________________________
> Grub-devel mailing list
> address@hidden
> https://lists.gnu.org/mailman/listinfo/grub-devel



reply via email to

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