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
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 serial_usb0
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
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 included in the final release. It
solves serious bug.
Check
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,
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 hope
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
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
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
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 star...@volny.cz wrote:
... Did you change something else than misc.c?
No, please see attached diff.
Thanks
###
#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, Javier Vasquez napsal(a):
On 11/17/13, Aleš Nesrsta star
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 see loading of OHCI module
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: OHCI module
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:
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
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 (Ownership of EHCI controller
# 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
gregg.drw...@gmail.com
This signature fought the Time Wars, time and again.
On Tue, Sep 17, 2013 at 5:10 PM, Aleš Nesrsta star...@volny.cz 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.
If you
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 at
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
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]
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
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.
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
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.
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
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
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 needs
, I didn't
test it again yet.
BR,
Ales
Regards,
C
-Original Message-
From: grub-devel-bounces+christian.melki=saabgroup@gnu.org
[mailto:grub-devel-bounces+christian.melki=saabgroup@gnu.org] On
Behalf Of Aleš Nesrsta
Sent: den 10 augusti 2013 00:25
To: The development of GNU
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 ehciuhci 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 include insmod
...
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
...
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
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
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
...
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),
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
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
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
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
/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 has only EHCI+RMH
so root port isn't
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
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 star...@volny.cz
mailto:star...@volny.cz wrote:
Javier Vasquez píše v Po 29. 10. 2012 v 17:03 -0600
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.0
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
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 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 GRUB from USB device. I expect it is probably
(very
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
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 yes - and it possibly
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
device when GRUB opens USB disk, e.g. when ls command is entered first
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 :-)
But:
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
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 that I also
Javier Vasquez wrote:
On Sun, Oct 28, 2012 at 11:19 AM, Vladimir 'φ-coder/phcoder'
Serbinenko phco...@gmail.com wrote:
...
Is there a hub or is keyboard connected directly?
--
Regards
Vladimir 'φ-coder/phcoder' Serbinenko
The keyboard is connected directly...
According to
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
Rock some time ago.
Try this patch, please
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
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 to do some experiments but QHs in AL remained
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
Hi Vladimir and Chris:
Chris:
Thank You for the research, correction of my mistakes (classical
copy-paste mistake... :-) ) and the patch.
As I see, Vladimir is currently discussing Your patch to be accepted, so
I am writing only some notes below mainly for Vladimir.
Vladimir:
1.
interrupt
Christer Weinigel píše v Út 29. 05. 2012 v 11:07 +0200:
Hi list,
the EHCI driver in GRUB has some known problems with low-speed transfers
and split transactions [1]. On older machines this is not a big problem
since it's possible to connect low speed devices such a USB keyboard
directly to
On Sat, May 12, 2012 at 06:48:29PM -0700, walt wrote:
Hi! I have an amd64 machine with an add-on usb3 adapter which
works well with the linux xhci driver, but the machine's BIOS
doesn't see any disks in the usb3 docking station I use.
My (elderly) grub-1.99-rc1 also doesn't see the outboard
@gnu.org] On Behalf
Of Aleš Nesrsta
Sent: den 4 november 2011 22:21
To: The development of GNU GRUB
Subject: Re: Stall due to babble when reading card ATR from CCID device using
UHCI
Hi,
AFAIK, the babble is fatal bus error which should not normally occur, so if
You get it regularly
Ales
Philipp Hahn píše v Čt 03. 11. 2011 v 10:25 +0100:
Hello,
I had a look at your EHCI driver, while investigating why grub-1.99
needs 2 minutes to load my 58 MB InitRd.
On Sat, Aug 27, 2011 at 06:42:18PM +0200, Aleš Nesrsta wrote:
Changes in other files are still the same (more
Vladimir 'φ-coder/phcoder' Serbinenko píše v Pá 30. 09. 2011 v 17:37
+0200:
That must be a too long interval of writing e-mail. I started it a month
ago, then interrupted and now finishing it
No problem, I have often very, very long response time too...
(sometimes infinite...) :-)
According to
to find some
workaround.
But first try to test EHCI yourself on Your machine(s) and then we will
see...
Best regards
Ales
Aleš Nesrsta píše v So 01. 10. 2011 v 10:15 +0200:
Vladimir 'φ-coder/phcoder' Serbinenko píše v Pá 30. 09. 2011 v 17:37
+0200:
That must be a too long interval of writing e
Hi Vladimir,
@Rock changes merged into trunk.
I did not find any author(s) information in file headers (in any USB related
source file), so I put this information in ChangeLog file in this way:
2011-10-01 Ales Nesrsta star...@volny.cz
* grub-core/bus/usb/uhci.c: Changes made by Rock Cui -
Hi Vladimir,
see below...
Currently I have only note to discussed packed attribute problem:
...
2. AFAIK (but maybe it is not true, maybe it was never true...?)
compilers are using default alignment of variables usually according to
native length of CPU word. So, as we have 64-bit machines now,
Hi,
I think it is not GRUB related problem, more probably there is some HW
problem on Your serial port. Try to check idle voltage on RxD pin of
serial port (best with oscilloscope... :-) ). Or You can have some
unwanted leakage between pins of connector or wires in cable (check
resistance between
...
I very shortly tested this patch, it seems to be working OK.
Best regards,
Ales
Vladimir 'φ-coder/phcoder' Serbinenko píše v Ne 21. 08. 2011 v 18:10
+0200:
On 20.08.2011 23:45, Aleš Nesrsta wrote:
Hi everybody,
could anybody test changes from Cui Lei (see below) in uhci.c
to needed change of UHCI
controller ownership and should be included into uhci.c code.
Regards,
Ales
Přeposlaná zpráva
Od: Cui Lei neverforget_2...@163.com
Komu: Aleš Nesrsta star...@volny.cz
Kopie: The development of GNU GRUB grub-devel@gnu.org
Předmět: [Resolved] Grub2 can
Hi,
To Szymon ( Vladimir too...):
...
In such case EHCI should handover port to a companion 1.1 controller.
(see section 4.2 of EHCI specification)
Yes, driver does it in such way - but I tested it first alone, without
any other USB driver, and in such case companion controllers of course
did
Vladimir 'φ-coder/phcoder' Serbinenko wrote:
Hi,
there is corrected patch (with sizeof and -p) for review before going to
trunk.
Regards
Ales
Go ahead
Done, revision 2873.
___
Grub-devel mailing list
Grub-devel@gnu.org
Vladimir 'φ-coder/phcoder' Serbinenko wrote:
I found small bug in old problem solution of SCSI cache ID in trunk -
see attached patch which should solve it.
Go ahead
Done, revision 2874.
___
Grub-devel mailing list
Grub-devel@gnu.org
Hi,
I have problem with multi-lun devices in some cases.
I found small bug in old problem solution of SCSI cache ID in trunk -
see attached patch which should solve it.
Regards
Ales
--- ./grub/include/grub/scsi.h 2010-09-30 22:17:31.0 +0200
+++ ./grub_patched/include/grub/scsi.h
Vladimir 'φ-coder/phcoder' Serbinenko wrote:
On 09/23/2010 10:27 PM, Aleš Nesrsta wrote:
code works on on 64 bits architectures. */
- u-td = (grub_uhci_td_t) grub_memalign (4096, 4096*2);
+ u-td = (grub_uhci_td_t) grub_memalign (4096, 32*N_TD);
if (! u-td)
goto fail
Vladimir 'φ-coder/phcoder' Serbinenko wrote:
On 09/26/2010 10:11 PM, Aleš Nesrsta wrote:
+ grub_uint8_t cbicb[GRUB_USBMS_CBI_CMD_SIZE] =
+{ 0x1d, 0x04, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff,
+ 0xff, 0xff
+};
Could you deblob this?
Other that this it can
Hi,
I don't know who is developer/maintainer of USB serial drivers - I
expect it is Vladimir, so this e-mail is addressed mainly to him.
As I wrote in my older e-mail (Question: USB serial - device driver
debugging), there is some problem with PL2303. Not with driver but with
device itself
Vladimir 'φ-coder/phcoder' Serbinenko wrote:
Unfortunately, I cannot simply debug this problem, because when I set
for example all into debug variable, problem does not happen and boot
is processed normally... :-(
It's a typical syndrom of memory corruption. I fixed few memory
- it is not in
grub.cfg
Regards
Ales
Aleš Nesrsta wrote:
Hi,
there is some bug in trunk last versions:
I am not able to boot with normal configuration stored in grub.cfg - if
I select any item from menu (or wait for timeout for default item),
booting is aborted with messages
Hi,
there is the patch which adds support for USB Mass Storage type CBI
(Control/Bulk/Interrupt).
I know, currently is probably not the best time to add some new features
but it happened... :-)
I don't know how it will be useful because CBI devices should be
(according to specification) full
Hi,
I discovered problem which happens if bulk EP has shorter wMaxPacketSize
value than control (zero) EP.
There was bug in usbtrans.c, see patch.
Another problem happens when bulk EP has wMaxPacketSize = 16 - in this
case transfer error happens because it is not possible to allocate
sufficient
Hi,
there is some bug in trunk last versions:
I am not able to boot with normal configuration stored in grub.cfg - if
I select any item from menu (or wait for timeout for default item),
booting is aborted with messages:
Booting 'xyz...'
unaligned pointer 0x...
Aborted. Press any key to exit.
Vladimir 'φ-coder/phcoder' Serbinenko wrote:
On 09/15/2010 07:58 AM, Aleš Nesrsta wrote:
Hi,
I did not find configuration of USB serial device, so I made this small
patch.
Go ahead for trunk
Done (trunk revision 2843).
(I had to do it two times - unfortunately there was some
Hi,
it seems there are some problems in USB serial driver PL2303 and I want
to debug it.
I need to send and receive some data to see what happened, i.e. I need
to enable remote debug via classic serial interface by e.g.
serial;terminal_output console serial;debug=xxx and then do something
like
Hi,
I did not find configuration of USB serial device, so I made this small
patch.
Regards
Ales
diff -urB ./kbdlayouts/grub-core/bus/usb/serial/common.c ./kbdlayouts_changed/grub-core/bus/usb/serial/common.c
--- ./kbdlayouts/grub-core/bus/usb/serial/common.c 2010-09-03 22:13:28.0 +0200
Hi,
there is little bit modified patch, it should work better...
For details see description in original e-mail included below.
Regards
Ales
Aleš Nesrsta wrote:
Hi,
today I discovered some small problem related to my last patch described
in e-mail below, point 7. The problem
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 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
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 interrupt
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 to
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 allocate enough EDs
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 they
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/2010 11:21 AM, Aleš Nesrsta wrote:
Hi,
included patch should make
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/phcoder' Serbinenko wrote:
On 06/20/2010 11:23 AM, Aleš Nesrsta wrote
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
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 support, i.e. USB hub
and device must be connected
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,
I found some mistake in uhci.c in grub_uhci_portstatus when enable=0.
There is proposal
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 uhci
module).
- USB 2.0 devices (USB disks etc.) are mostly backwards compatible, i.e.
they are working also when connected to OHCI/UHCI controllers.
Regards
Ales
On Mon, Jul 5, 2010 at 8:14 PM, Aleš Nesrsta star...@volny.cz wrote:
On 07/02/2010 12:30 PM, jonatan perry wrote
1 - 100 of 120 matches
Mail list logo
