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 anything because ports are polled only when enumerating usbdevices. We need a more reliable way to detect new devices. Perhaps we should try to assign addresses to any device without address and see if it responds to configuration request. If noone responds assume that no devices were newly connected. On Yeeloong 'usb' command lists hotplugged devices correctly but bulk transfer fails with donehead=0. > 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.). > > It's mostly your work ;). > But better will be if somebody else also tests more devices on both > controllers. > > Now when it's merge to mainline and will be propagated, it should recevie some light. > Some additional informations: > > 1. > I found multi-LUN relatedproblem: I have one multi-LUN device - card > reader - and I tried plug into it more than one card. In this case "ls" > command reports bad number of filesystems (and also bad type of listed > partition filesystem) on another than first LUN. > > It looks like that (not true copy of console): > (usb0a) (usb0,msdos1) (usb0b,msdos1) > It is bad because LUN usb0b has four partitions with ext2 filesystem. > > When I try for example "ls (usb0b,4)/", grub returns for the first try > "error: unknown filesystem.", for second try grub does normal file list. > (the same for another partitions, i.e. (usb0b,1), (usb0b,2), (usb0b,3)) > > Perhaps there are strill problems with toggle bit. Problem is that if it gets out of sync it can only hard get in-sync again. Hence strange problems. But it would appear on single-LUN devices too. > The same configuration works fine under Linux and Windows. > > 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 CBW are LUN bits on another place > than in SCSI CDB, both should be set correctly. */ > > Perhaps (scsi->lun << GRUB_SCSI_LUN_SHIFT) | scsi->lun ? > 2. > I found some other devices to test, now I have 13 USB MS bulk-only > devices, each is from another manufacturer and there are approx. five > different kinds of devices - flash disk, hard disk, card reader, camera, > mobile phone. > What is known but maybe interesting, three devices are not working at > all on UHCI - but are working on OHCI (and under Linux / Windows they > are also working) - as we discussed previously, it can be some problem > with power or EHCI influence because it looks like device is not > properly powered. > UHCI-problematic devices are: Transcend SDHC card reader I have a cardreader and it may be Transcend. > and two flash > disks - EMTEC "lollipop" and PRETEC Bullet-Proof. > One curiosity - cheap EMTEC "lollipop" USB flash disk has USB ID > 0000:0000... (but it works on OHCI). > > > 3. > In Linux USB mass storage source is interesting link about problems with > USB mass storage devices: > http://www.one-eyed-alien.net/~mdharm/linux-usb (and inside > http://www2.one-eyed-alien.net/~mdharm/linux-usb/target_offenses.txt ) > > In Linux source You can find also one interesting information - from > some Intel chipset version there are new bits in UHCI hub port registers > related to overcurrent (bits 10 & 11). But we currently don't care about > overcurrent at all. > > > 4. > One really stupid question related to your older e-mail: > > What does mean "For this you can add a new field in "o"." ? > > It is something related to Bazaar branch ? Or to something in source > code configuration etc. ? > (I am totally unexperienced with bazaar and similar tools, the same with > autogen and similar..., sorry.) > > I meant this: struct grub_ohci *o = (struct grub_ohci *) dev->data;
> That's all for now, there will be probably silent from me for some > days... > That's of course no problem. > Best regards > Ales > > > > > _______________________________________________ > Grub-devel mailing list > Grub-devel@gnu.org > http://lists.gnu.org/mailman/listinfo/grub-devel > > -- Regards Vladimir 'φ-coder/phcoder' Serbinenko
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
