Hi,
just note:
There was done some work mainly by Bjørn Forsman - but, AFAIK, it is probably
unfinished, see e.g. here:
https://lists.gnu.org/archive/html/grub-devel/2017-03/msg9.html
From my point of view, the main problem is how to adapt advanced
properties/functions of XHCI controller t
Hi,
I reproduced this problem on VMware workstation (v. 7.1.5).
But I am totally confused - it looks like EHCI doesn't execute
Asynchronous List (AL) even it is active according to EHCI status.
I tried to do some experiments but QHs in AL remained "untouched" by
EHCI - EHCI ignored any settings/c
e (without interrupt)...
BR,
Ales
Aleš Nesrsta wrote:
> Hi,
>
> I reproduced this problem on VMware workstation (v. 7.1.5).
>
> But I am totally confused - it looks like EHCI doesn't execute
> Asynchronous List (AL) even it is active according to EHCI status.
> I tried
Hi Frank,
You are probably right - it might be the problem with PCI bus master
settings! The same problem was solved in UHCI driver for coreboot by
Rock some time ago.
Try this patch, please:
@@ -533,6 +533,11 @@ grub_ehci_pci_iter (grub_pci_device_t de
"EHCI grub_ehci_pc
Vladimir 'φ-coder/phcoder' Serbinenko wrote:
> On 18.07.2012 17:32, Aleš Nesrsta wrote:
>
> > Hi Frank,
> >
> > You are probably right - it might be the problem with PCI bus master
> > settings! The same problem was solved in UHCI driver for coreboot by
&
Javier Vasquez wrote:
> On Sun, Oct 28, 2012 at 11:19 AM, Vladimir 'φ-coder/phcoder'
> Serbinenko wrote:
> >
> >> ...
> >
> > Is there a hub or is keyboard connected directly?
> >
> > --
> > Regards
> > Vladimir 'φ-coder/phcoder' Serbinenko
>
>
> The keyboard is connected directly...
>
Accordin
Javier Vasquez píše v Po 29. 10. 2012 v 17:03 -0600:
> > According to USB keyboard: Maybe it sounds funny, but try this, please:
> > Unplug and plug again keyboard when GRUB is loaded.
> > Does it help?
> >
> > BR
> > Ales
>
>
> Thanks, I tried, and it didn't work, :-(
>
> BTW, forgot to menion
Javier Vasquez wrote:
> Are somewhere available more detailed information
> about Your loongson-2f
> Mini-PC HW?
>
> I'm attaching more information about the mini-pc...
OK, OHCI is present as companion controller, i.e. directly conn
Hi,
I found some USB problem:
Some part of GRUB wants read "long" data block from USB mass storage
device when GRUB opens USB disk, e.g. when "ls" command is entered first
time after EHCI/UHCI/OHCI module is loaded.
"Long" means data block of 0x8000 bytes length - it is not too much
nowadays :-)
Vladimir 'φ-coder/phcoder' Serbinenko píše v Po 10. 12. 2012 v 11:57
+0100:
> On 01.12.2012 23:46, Aleš Nesrsta wrote:
>
> > Hi,
> > I found some USB problem:
> >
> > Some part of GRUB wants read "long" data block from USB mass storage
> >
Vladimir 'φ-coder/phcoder' Serbinenko píše v Po 10. 12. 2012 v 21:33
+0100:
> On 10.12.2012 18:49, Aleš Nesrsta wrote:
...
> So it would be that maximum transfer size would be part of structure.
> Another 2 questions are:
> 1) Is this multi-schedule transfer reliable?
I think
Hi,
I found something not really bad but probably also not good, related to
booting of GRUB from USB device.
I expect it is probably (very) low priority thing.
Sorry if it was discussed before, I didn't notice it.
Consider this situation:
- You have ordinary PC which (BIOS) supports boot from USB
Phillip Susi píše v Út 18. 12. 2012 v 15:35 -0500:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On 12/16/2012 11:54 AM, Aleš Nesrsta wrote:
> > Hi,
> >
> > I found something not really bad but probably also not good,
> > related to booting of
> On 12/18/2012 5:09 PM, Aleš Nesrsta wrote:
> > Probably the only one possibility is to load all necessary USB
> > GRUB modules manually before issuing "insmod ehci" as You
> > recommend. I will try if it is working in this way, it could be
> > usable.
>
Hi Vladimir,
in some e-mail in this thread You wrote:
> Can this be computed from the device info rather than hardwired to 2K?
So, there is "draft" of patch which makes maybe little bit more
sophisticated limiting of bulk transfer length.
How it works:
I added new variable "max_bulk_tds" into US
Hi Bob,
it is probably not GRUB bug according to Your description - it looks to
be BIOS problem.
1.
Currently I have no idea about Your HW, but it looks like Your xHCI (USB
3.0 controller) is not "native" part of the PC handled by BIOS, i.e.
BIOS cannot boot from any device connected to USB 3.0 p
Hi Vladimir,
do you mean something like that ?
Or do you want also to change "int endpoint" to "struct
grub_usb_desc_endp *endpoint" - like in Your patch ?
Additionally some (unrelated) note:
There is also waiting important USB patch in bug
https://savannah.gnu.org/bugs/?36740
(related to USB 2
;antivirus"
software blocked my message with GRUB binary. Also thers is grub.elf
(from 2.00~rc1) in downloads section.
On 03.11.2012 22:34, Javier Vasquez wrote:
On Tue, Oct 30, 2012 at 2:14 PM, Aleš Nesrsta mailto:star...@volny.cz>> wrote:
Javier Vasquez píše v Po 29. 10. 2012 v 17:03 -
mir 'φ-coder/phcoder' Serbinenko napsal(a):
On 12.07.2013 18:25, Aleš Nesrsta wrote:
Hi Vladimir,
- what was the reason of the OHCI problem on Loongson?
(I don't see any details of solution below nor the patch... ?)
It was bad handling of root ports. My standard system h
You have to use nativedisk command which reloads disk drivers all at
once as BIOS disk services are disables when *hci or pata is loaded.
Thanks, it works - it looks like I missed some important change in GRUB...
BR,
Ales
___
Grub-devel mailing list
I fixed the usb keyboard bug on fuloong. Looks like some "antivirus"
software blocked my message with GRUB binary. Also thers is grub.elf
(from 2.00~rc1) in downloads section.
Hi Vladimir,
I made some tests with the last changes of USB and there are results:
1.
Some of my USBMS devices have pro
Hi Vladimir,
I have some additional information - results of some today's experiments.
The main important thing related to USB keyboard:
USB keyboard doesn't work if it is connected as first device to the same
non-root hub port, where was connected USBMS device previously!
If the keyboard is di
I forgot one more thing - if You want to try repeat USBMS/USB keyboard
problem described below, You need to access the connected USB disk (e.g.
by "ls" command) before removing it.
Hi Vladimir,
I have some additional information - results of some today's experiments.
The main important thing
Hi,
after some debugging I have found bug(s) in handling of QHs related to
EHCI low speed split interrupt transfers.
Attached patch seems to solve problem described below (non-working USB
keyboard attached to the same port where was USB disk previously).
Please try it - maybe it solves also
...
Attached patch seems to solve problem described below (non-working USB
keyboard attached to the same port where was USB disk previously).
Please try it - maybe it solves also reported keyboard problem on
fuloong/loongson.
...
I applied the patch, on the version of the repo I had (5071), wit
Hm, it's pity. So, there is at least one additional bug somewhere... :-(
...
Could You test if Your keyboard will work on fuloong when You use only
OHCI module (don't include/load EHCI module in GRUB)?
(EHCI module is not needed for USB keyboard in the case when keyboard is
connected to root po
Hi Javier,
probably last chance to find the reason of Your GRUB USB keyboard
trouble is the debugging.
I don't know how much debugging experience do You have, so there is
short "manual" what You need to have/to do:
1.
You'll need to have some another computer with serial port (or working
U
...
Hmm, I can access one laptop with 9 pins RS-232 port. The mini-pc is
a 3 pins serial port. I don't currently have a way to connect them.
I'll have to buy a some cable/converter...
Cable is shipped with fuloong. It's straight passive cable to RS-232.
Thanks for that... I just found it
...
Hmm, I can access one laptop with 9 pins RS-232 port. The mini-pc is
a 3 pins serial port. I don't currently have a way to connect them.
I'll have to buy a some cable/converter...
Cable is shipped with fuloong. It's straight passive cable to RS-232.
Thanks for that... I just foun
Hi,
please send output of
lspci -vvv
lsusb -vvv
Run it as root or via sudo.
Some general advices:
1.
Do not include "insmod usb_keyboard" - this module should be loaded
automatically from usb module.
2.
If Your keyboard is connected to USB controller via hub (it can be
internal, integrated
Hi,
I forgot one important thing - try to use "nativedisk" command instead
of separate loading ehci&uhci modules.
BR,
Ales
Dne 9.8.2013 20:27, Aleš Nesrsta napsal(a):
Hi,
please send output of
lspci -vvv
lsusb -vvv
Run it as root or via sudo.
Some general advices:
1.
Do not i
ree connected disks
in nativedisk mode (as I remember, it found only SATA disks, not PATA
disk - or something like that) - but maybe it is solved now, I didn't
test it again yet.
BR,
Ales
Regards,
C
-Original Message-
From: grub-devel-bounces+christian.melki=saabgroup@gnu.or
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 somew
Hi,
what do you mean exactly by "GRUB does not detect this device"?
1) Do you mean it is not listed by "usb" command?
2) Or do you mean it is not listed by "ls" command as disk?
In the case 2) it is most probably caused by this: Such device is not
mass storage class device. I.e., it probably nee
Hi again,
probably did you mean SD card reader instead of smart card reader?
In this case:
1) SD card reader is PCI device, not USB device:
lspci
...
03:01.2 SD Host controller: Ricoh Co Ltd R5C822 SD/SDIO/MMC/MS/MSPro
Host Adapter (rev 21) (prog-if 01)
...
AFAIK, it needs SDHCI PCI driver.
28.8.2013 08:59, Melki Christian (consultant) wrote:
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 success
Sorry, I missed the patch... :-)
There it is.
28.8.2013 08:59, Melki Christian (consultant) wrote:
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. Wh
Hmmm, today is not a good day - I sent wrong patch with mistake,
sorry... :-(
I hope attached patch is finally OK...
BR,
Ales
Sorry, I missed the patch... :-)
There it is.
28.8.2013 08:59, Melki Christian (consultant) wrote:
I'm thinking of the EHCI hand-over. In the case of EHCI handover
Vladimir:
Please, when you will very important review/commit Christian patch,
consider also my two previous latest USB patches - please review them (I
can commit them myself, no problem) or commit.
I mean these two patches:
- simple patch related to reset SMI (sent in ML in thread [PATCH] Re
2.9.2013 10:49, Melki Christian (consultant) wrote:
Sorry Ales,
Here is a lsusb -vvv dump of the E6430 machine.
I meant to include it the first time.
According to this file, it looks like Smart card reader is connected in
port 8 at internal USB2 hub Bus 002 Device 002: ID 8087:0024.
Did you
2.9.2013 09:01, Melki Christian (consultant) wrote:
Exactly.
The EHCI handback is provided by the EHCI spec handover state machine. Problem
is, most BIOS:es don't implement it, or just screw it up trying.
The scenario is like this:
Load grub2 with EHCI usb.
Grub2 loads windows 7 or something.
Wi
Hi,
I have stupid question related to organization of committing of patches
- I am currently little bit confused.
Vladimir wrote to me in some latest e-mail :
"I don't see any messages in my mailbox from you tagged as pending
patches."
And, additionally, I see only Vladimir's commits in trunk
# stty -F /dev/ttyUSB0 9600 -echo
# cat /dev/ttyUSB0 > ttyUSB0.txt
It was 9600 usually, but probably it should be 112500 now, as Vladimir
wrote.
If you want, you can ensure some speed on GRUB side by parameter -s ,e.g.:
serial -s 112500
serial
terminal_output console serial
debug=all
insmod
evine gregg.drw...@gmail.com
"This signature fought the Time Wars, time and again."
On Tue, Sep 17, 2013 at 5:10 PM, Aleš Nesrsta wrote:
# stty -F /dev/ttyUSB0 9600 -echo
# cat /dev/ttyUSB0 > ttyUSB0.txt
It was 9600 usually, but probably it should be 112500 now, as Vladimir
wrote
Hi Christian,
sorry for delay, I am too busy in last time.
> Hi,
>
> I discovered that on some PC's the USB stack would produce an invalid
> descriptor upon query without an error.
> I don't know why this is the case, maybe broken hardware but I
> seriously doubt it.
> GRUB doesn't handle TT's
OK, committed.
I simply removed the line you mentioned...
BR, Ales
Dne 23.9.2013 14:47, Vladimir 'φ-coder/phcoder' Serbinenko napsal(a):
On 31.08.2013 23:12, Aleš Nesrsta wrote:
- grub_boot_time ("Ownership of EHCI port taken");
+ grub_boot_time ("Own
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 cas
Dne 27.10.2013 19:33, Javier Vasquez napsal(a):
> OK, I'll re-dump removing such call, :-)
Hi Javier,
maybe it is not necessary - at least with your current configuration.
Why:
1.
This:
"...
bus/usb/ehci.c:1772: detect_dev: EHCI STATUS: c004
bus/usb/ehci.c:1774: detect_dev: iobase=0xb4073
Dne 27.10.2013 21:19, Javier Vasquez napsal(a):
On the other hand, I believe as part of prior experiments I've already
tried loading ohci after ehci, and that didn't make any difference...
OK, as I wrote, order is not critical.
But it looks like your PC never loaded OHCI module at all.
Can yo
Only short note below...
Dne 27.10.2013 23:43, Vladimir 'φ-coder/phcoder' Serbinenko napsal(a):
On 27.10.2013 21:03, Aleš Nesrsta wrote:
2.
I don't see loading of OHCI module in debug output !
Do you really have this module included in your image?
I have to second this:
Dne 29.10.2013 19:46, Vladimir 'φ-coder/phcoder' Serbinenko napsal(a):
On 29.10.2013 19:35, Aleš Nesrsta wrote:
Only short note below...
Dne 27.10.2013 23:43, Vladimir 'φ-coder/phcoder' Serbinenko napsal(a):
On 27.10.2013 21:03, Aleš Nesrsta wrote:
2.
I don't s
Hi,
something went wrong with debug.
It looks like serial output stopped work...
But it worked before, in output you sent 27.10.2013... Did you change
something else than misc.c?
We need somebody's help - Vladimir?
Or somebody else who knows deep details about GRUB debugging via serial
line on
put in this case?
BR,
Ales
P.S.
Sorry if this e-mail will appear twice in ML - I had some problem with
e-mail client...
Dne 17.11.2013 19:31, Javier Vasquez napsal(a):
> On 11/17/13, Aleš Nesrsta wrote:
>> ... Did you change something else
g in this way:
...
### BEGIN /etc/grub.d/00_header ###
#serial
#terminal_output console serial
debug=all
insmod ehci
insmod ohci
insmod usb_keyboard
ls
...
i.e. disable the GRUB serial driver and console redirection.
What will be serial debug output in this case?
BR,
Ales
Dne 17.11.2013 19:31, Jav
> Premise: me and phcoder think its a bad/slow USB drive.
Of course, the USB device could be "bad" - I met some devices which have
not good implementation of USB mass storage class (or SCSI) specification.
What is surprising, most of these devices were able to work correctly in
Linux or Windows (at
I found serious mistake in grub_ehci_check_transfer which probably
causes bad behavior explained in ML thread "flash drive timing out,
can't boot vmlinuz/initrd (coreboot payload)".
The problem is:
If we cannot use interrupts, we can detect finish of EHCI transfer only
by polling of QH's TD overl
Hi,
I probably found the reason of this bad behavior.
Try patch included in ML thread "[PATCH] EHCI/USBMS corrections".
BR,
Ales
signature.asc
Description: OpenPGP digital signature
___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/m
Dne 16.12.2013 15:42, Melki Christian (consultant) napsal(a):
> I think there was more than that.
> Several lines was more than 80 chars long with diff additions. Cutting and
> pasting them that was wrapped by some client leads to errors.
Yes, you are right.
You can find patch in attachment - I ho
Hi Vladimir,
it would be fine if the bugfix, posted by me in ML thread "EHCI/USBMS
corrections" (12/16/2013), will be included in the final release. It
solves serious bug.
I tested it on four different PCs - it is working fine, I saw no
negative results, and it helps on PCs where the problem, des
Dne 19.12.2013 12:33, Melki Christian (consultant) napsal(a):
>...
> I'm not an USB expert. :)
In this case we are two... :)
According to your patch:
Even if this patch looks good for me, I am afraid it is not good way to
handle xHCI from EHCI module.
From my point of view it is maybe little bit
Dne 20.12.2013 13:16, Vladimir 'φ-coder/phcoder' Serbinenko napsal(a):
> On 19.12.2013 20:59, Aleš Nesrsta wrote:
>> Hi Vladimir,
>>
>> it would be fine if the bugfix, posted by me in ML thread "EHCI/USBMS
>> corrections" (12/16/2013), will be incl
Hi Christian,
I think - generally, if OS is able to work with this Intel chipset, then
it should handle change of XUSB2PR and USB3_PSSEN registers state during
reboot (or sleep/resume).
In opposite case, when OS is not able to work with this chipset, then OS
will not touch these registers - and ro
Hi Juan,
I fully agree with Gregg Levine remarks.
But, for the first look, I maybe see your mistake in GRUB "serial"
command, so there is my first aid:
> but when I write "serial --speed=115200 --word=8 --parity=no --stop=1 usb0"
> this print it:
>
> "serial port 'usb0' is not found"
Try "seri
Hello,
according to e-mail from Vladimir Serbinenko I am sending patch related
to (mostly) OHCI problem (bug #26237).
Workaround related to grub_memalign problem is removed from patch
because Vladimir Serbinenko wrotes that it will be corrected.
Patch was done by:
diff -urB grub2-1.98~experimen
Vladimir 'φ-coder/phcoder' Serbinenko wrote:
> Aleš Nesrsta wrote:
> > Hello,
> >
> > according to e-mail from Vladimir Serbinenko I am sending patch related
> > to (mostly) OHCI problem (bug #26237).
> > Workaround related to grub_memalign problem
Vladimir 'φ-coder/phcoder' Serbinenko wrote:
> > I am not so far oriented in such kind of development, so I am asking:
> > Will You correct my patch yourself (as maintainer of code) or should I
> > prepare new corrected code and related patch? And against which version
> > - I noted that in meantim
Vladimir 'φ-coder/phcoder' Serbinenko wrote:
...
> I discovered something. It looks like on Yeeloong the problem is caused
> by the skipped step of initialising of timings and power management.
> Quick and dirty fix:
...
Hello,
first of all sorry about delay - I am little bit busy now.
1.
I ful
Vladimir 'φ-coder/phcoder' Serbinenko wrote:
Problem is that if firmware didn't set this register correctly we'll
have problems with it. Additionaly the advantage of always using the
same values is to avoid having different behaviour on different chipsets
which is a plus from debugging perspectiv
Hi Vladimir,
I have some news - I made extensive testing and researching and I
discovered some things related to OHCI and generally to USB MS or USB
itself.
I tried to fix them and it looks like I was probably successful in some
cases:
- multiple LUNs related bug (meaning of value from device &
Hi Vladimir and others,
first of all thanks for immediate advice about Bazaar.
Attached is the usb patch related to OHCI and USB MS (SCSI).
(There is also very small patch for uhci.c - it signals in debug print
failed transaction even if it finished correctly.)
Patch is done against Bazaar source
Vladimir 'φ-coder/phcoder' Serbinenko wrote:
> Aleš Nesrsta wrote:
> > I will look into yeeloongfw branch, I got Bazaar working yesterday
> > evening only... I agree with You, first should be solved known problems
> > on simple base.
> > Unfortunately, I pro
Vladimir 'φ-coder/phcoder' wrote:
> > It could make troubles on SCSI subclass
> > devices but I tried all my devices with SCSI subclass with
> > ATAPI-compatible length of command and all devices are working normally
> > - so I think it should be safe to use ATAPI format of commands
> > universal
Hi,
I discovered something when I was looking for some hangs (timeouts):
1.
There is problem in used toggling system on bulk transfers - in case of
some errors (underrun, overrun etc.) it missed synchronization with
device, because it expects that all TDs will be processed - and in error
case it
Hi,
there is some new patch which includes:
- OHCI power and configuration counter check patch sent by Vladimir in
the meantime
- simple handling of unrecoverable OHCI error (not tested yet - I cannot
set OHCI into unrec. error state...)
- (I hope) proper toggle bit handling also in error state
Vladimir 'φ-coder/phcoder' Serbinenko wrote:
> > Hello, Aleš. I've seen that your assignment was completed. I added you
> > to grub contributors. Feel free to create a branch in branches/usb.
> > Right now I'm busy but next week I should be able to assist. Perhaps
> > even this week. Right now I se
Hi Vladimir,
even I am too busy to do any development or "research", I tried at least
to shortly test the usb branch code, as you wrote here:
Vladimir 'φ-coder/phcoder' Serbinenko wrote:
> I've merged your latest patch into usb branch too, fixing some
> problems
> it would have on yeeloong. Compi
Hi Vladimir,
Vladimir 'φ-coder/phcoder' Serbinenko wrote:
> There were few special cases. (Hopefully) fixed and ccomitted into "usb".
You are successful, great work, all devices are working (with some known
exceptions on UHCI - see below in point 2.).
But better will be if somebody else also te
Hello Vladimir,
only shortly:
> > Oh, I find probably the mistake right now - there is missing my older
> > small patch in usbms.c - there is fast "hand made" "patch", I have no
> > more time, sorry:
> > usbms.c, line 240:
> > - cbw.lun = scsi->lun << GRUB_SCSI_LUN_SHIFT;
> > + cbw.lun = scsi
Hi,
I am sorry, there is small mistake inside ohci.c - I forgot delete
testing code in lines 442-443 in ohci.c, code
442 /* Test - remove it !!! */
443 o->bad_OHCI = 1;
should be removed !
(Code is functional also with this mistake but in "emergency" mode,
o->bad_OHCI == TRUE enables workarounds
Hi Vladimir,
one more idea:
Vladimir 'φ-coder/phcoder' Serbinenko wrote:
> Hello, Aleš. Today I merged usb branch into mainline. Now I've started
> some work towards hotplugging and module autoloading. Currently it just
> checks portsstatus to see newly connected devices. Touble is that if you
>
Hi,
included patch should make USB hubs operational.
It works in the same simple way as whole GRUB2 USB support, i.e. USB hub
and device must be connected to computer BEFORE uhci/ohci module is
loaded.
Note (mainly for Vladimir):
Via hub are normally working also devices which I reported to be n
Hi,
I found some mistake in uhci.c in grub_uhci_portstatus when enable=0.
There is proposal of correction.
Without correction portstatus reported false timeout when enable=0
because it is waiting for reset to be done but none is performed...
Best regards
Ales
diff -urB ./usb/bus/usb/uhci.c ./usb
richardvo...@gmail.com wrote:
> On Sun, Jun 20, 2010 at 4:21 AM, Aleš Nesrsta wrote:
> > Hi,
> >
> > included patch should make USB hubs operational.
> >
> > It works in the same simple way as whole GRUB2 USB support, i.e. USB hub
> > and device must be
Hi Vladimir,
now I have working SSH, so I committed my last work into usb branch
(commented as "Faster OHCI, USB hub support, UHCI portstatus corr.",
revision 2427).
(Sorry if it is not the right way how to cooperate - should I make
another, my own branch? Or wait first for your agreement about n
Vladimir 'φ-coder/phcoder' Serbinenko wrote:
> On 06/20/2010 11:23 AM, Aleš Nesrsta wrote:
> > Hi,
> >
> > I found some mistake in uhci.c in grub_uhci_portstatus when enable=0.
> > There is proposal of correction.
> >
> > Without correctio
Vladimir 'φ-coder/phcoder' Serbinenko píše v Po 28. 06. 2010 v 18:44
+0200:
> On 06/20/2010 11:21 AM, Aleš Nesrsta wrote:
> > Hi,
> >
> > included patch should make USB hubs operational.
> >
> > It works in the same simple way as whole GRUB2 USB s
Vladimir 'φ-coder/phcoder' Serbinenko wrote:
> On 06/26/2010 12:03 AM, Aleš Nesrsta wrote:
> > Vladimir 'φ-coder/phcoder' Serbinenko wrote:
> >
> >> On 06/20/2010 11:23 AM, Aleš Nesrsta wrote:
> >>
> >>> Hi,
> >>&g
> On 07/02/2010 12:30 PM, jonatan perry wrote:
> > Hi all,
> > I am using grub2 uhci.c usb driver for testing new hardware, on some
> > occuisions the UHCI signature test fails (can be found on the PCI
> > iteration routine), the driver thest if the controller founded by PCI
> > has a signature as
ices, i.e., You cannot "switch" EHCI to UHCI (or OHCI) via
"legacy support". The only one possible way is to add EHCI support into
GRUB2 (new driver module).
- USB 2.0 devices (USB disks etc.) are mostly backwards compatible, i.e.
they are working also when connected to OHCI/UHC
Vladimir 'φ-coder/phcoder' Serbinenko píše v Út 06. 07. 2010 v 01:59
+0200:
> On 07/05/2010 07:11 PM, Aleš Nesrsta wrote:
> > Vladimir 'φ-coder/phcoder' Serbinenko píše v Po 28. 06. 2010 v 18:44
> > +0200:
> >
> >> On 06/20/201
Vladimir 'φ-coder/phcoder' Serbinenko :
> On 07/05/2010 07:12 PM, Aleš Nesrsta wrote:
> > Vladimir 'φ-coder/phcoder' Serbinenko wrote:
> >
> >> On 06/26/2010 12:03 AM, Aleš Nesrsta wrote:
> >>
> >>> Vladimir 'φ-coder/ph
Hi,
I little bit changed "hot-plugging" support added into "usb" branch by
Vladimir - see included patch. For the first look it maybe works on
UHCI, I did not test it on OHCI yet...
Basic info to this patch:
1.
This patch is made against current usb branch code (rev. 2427).
This patch is not com
Hi,
attached new patch includes improved hot-plug support.
It is also committed into usb branch (rev. 2428).
It should work now on UHCI, OHCI and also on non-root hubs.
Could somebody test it ?
(New plugged device should be accessible after "ls" command.
Disconnected devices remain listed but the
Hi, I am sorry to be late with answer, unfortunately, I have few time
during our school holidays...
To Your questions, chronologically:
> how would i surely know that grub usb driver would not work on this
> platform?
None of current USB drivers will work if Your PC is EHCI-only PC. One
way how t
Hi Vladimir,
Vladimir 'φ-coder/phcoder' Serbinenko wrote:
> > ...
> "statically" allocated EDs:
> > -- number of EDs could be increased in ohci.c
> > -- de-allocation of EDs should be added in ohci.c
> >
> >
> You can have at most 255 devices on one controller. The easiest way is
> to alloc
Vladimir 'φ-coder/phcoder' Serbinenko wrote:
> On 08/27/2010 01:05 AM, Carles Pina i Estany wrote:
> > > 3) Keyboard layouts and related USB improvements
> >
> > Maybe I've missed something. When I did it some months ago was working
> > fine, but we had some design issue (I think that Vladimir w
Vladimir 'φ-coder/phcoder' Serbinenko wrote:
> > The issue was that we were using getStatus every time we polled for new
> > devices which suposedly (I fixed few other bugs in the code I used at
> > the time so, I'm not sure) drove hub in my USB keyboard crazy. The
> > correct way is to poll interr
Hi Vladimir,
in fact nothing important changed from my previous e-mail, I have only
few information what I did.
I still have no progress with low-speed keyboard problem as I wrote in
last e-mail. Control transfers are working fine but interrupt transfer
fails even if I tried to send Clear Halt on
Hi Vladimir (and, of course, possibly others...),
there is patch which (perhaps) solves some bugs I found in kbdlayouts
branch.
It includes:
0. Previously sent patch for UHCI low speed problem.
1. UHCI transfer error evaluation
2. OHCI cdata de-allocation
3. OHCI proper previous TD unchaining
4.
Hi,
I found two problems in usb_keyboard, included patch should solve them
(I hope...):
1.
Configuration of USB device was misssing.
(Additionally, for low speed devices on UHCI should be applied patch
which I sent at Sat, 04 Sep 2010 00:02:28, subject: "Re: Plans on 1.99
release - USB issues").
1 - 100 of 132 matches
Mail list logo
