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
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
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,
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
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-lun; /* In USB MS
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
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
disconnect a device and plug a new one at its place this routine won't
notice
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. Compile
On 06/01/2010 11:14 PM, Aleš Nesrsta wrote:
On both HCs was not working device which has max. packet length for
control endpoint lower than 64. As I remember that this patch was
relative simple, I shortly looked into usb.c and usbtrans.c and there is
mistake:
--- usbtrans.c
+++
On 06/02/2010 02:27 AM, Vladimir 'φ-coder/phcoder' Serbinenko wrote:
very slow on this controller. Unfortunately I currently have no time to
discover why - I am expecting some mistake probably in toggling and
related code in ohci.c.
There is probably some new problem in OHCI because
Vladimir 'φ-coder/phcoder' Serbinenko wrote:
Aleš Nesrsta 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.
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 send
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
USB devices are notoriously difficult to get right. During development of
USB device support (mainly mass-storage devices), we discovered numerous
devices, usually super-cheap devices, that were not spec compliant or that
didn't implement this-or-that command, etc. It's truly amazing that
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 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
Aleš Nesrsta wrote:
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
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 probably cannot help You as I don't have GEODE or
Yeeloong... I can hope only that my corrections
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 probably cannot help You as I don't have GEODE or
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
universally for
Vladimir 'φ-coder/phcoder' Serbinenko 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 probably cannot help You as I don't have GEODE or
Yeeloong... I can hope
=20
Ale=C5=A1 Nesrsta wrote:
=20
I will look into yeeloongfw branch, I got Bazaar working yesterday
evening only... I agree with You, first should be solved known proble=
ms
on simple base.
Unfortunately, I probably cannot help You as I don't have GEODE or
Yeeloong... I can hope only
On May 23, 2010, at 12:35 PM, Vladimir 'φ-coder/phcoder' Serbinenko phco...@gmail.co
m wrote:
Vladimir '=CF=86-coder/phcoder' Serbinenko wrote:
=20
Ale=C5=A1 Nesrsta wrote:
=20
I will look into yeeloongfw branch, I got Bazaar working yesterday
evening only... I agree with You,
On Sat, May 22, 2010 at 01:46:57AM +0200, Aleš Nesrsta wrote:
I cannot get actual bzr code because of this error:
$ bzr get http://bzr.savannah.gnu.org/r/grub
bzr: ERROR: Not a branch:
http://bzr.savannah.gnu.org/r/grub/.bzr/branch/;.
bzr get http://bzr.savannah.gnu.org/r/grub/trunk/grub
Aleš Nesrsta wrote:
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
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
On 05/22/2010 01:46 AM, Aleš Nesrsta wrote:
I cannot get actual bzr code because of this error:
$ bzr get http://bzr.savannah.gnu.org/r/grub
bzr: ERROR: Not a branch:
http://bzr.savannah.gnu.org/r/grub/.bzr/branch/;.
For trunk, use:
bzr branch http://bzr.savannah.gnu.org/r/grub/trunk/grub
Aleš Nesrsta wrote:
Additionally, specification says that bit 31 (FIT) should be set to one
if any change of FRAME_INTERVAL occurs - but I think it is necessary
only if OHCI is in operational state - which is not in our case.
It can be done. Thanks.
As I wrote, it is most probably not our
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
Aleš Nesrsta wrote:
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
Aleš Nesrsta wrote:
I will test the usb.diff soon and than I try to more study EHCI
specification. On my PC is OHCI detected properly but I have very old
machine Toshiba Satellite 2140CDS (i586 at 450MHz) with one OHCI only
interface. I.e. it looks like problem appears only on combined
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 meantime new
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 is removed from patch
because Vladimir Serbinenko wrotes
Aleš Nesrsta wrote:
+ * So we should:
+ * - allow WritebackDoneHead interrupt (WDH) by proper setting of last TD
+ * token - it is done above in transaction settings
+ * - detect setting of WDH bit in HcInterruptStatus register
+ * - compare HccaDoneHead value with address
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 is removed from patch
because Vladimir Serbinenko wrotes that it will be corrected.
First of all big
35 matches
Mail list logo
