From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with archive (Exim 4.43) id 1PWdV4-0004zE-Jh for mharc-grub-devel@gnu.org; Sat, 25 Dec 2010 18:26:10 -0500 Received: from [140.186.70.92] (port=50470 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PWdV2-0004z9-Rt for grub-devel@gnu.org; Sat, 25 Dec 2010 18:26:09 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1PWdV1-0006on-JM for grub-devel@gnu.org; Sat, 25 Dec 2010 18:26:08 -0500 Received: from mail-ww0-f49.google.com ([74.125.82.49]:36131) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1PWdV1-0006oj-8u for grub-devel@gnu.org; Sat, 25 Dec 2010 18:26:07 -0500 Received: by wwb17 with SMTP id 17so7938973wwb.30 for ; Sat, 25 Dec 2010 15:26:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :x-enigmail-version:content-type; bh=WwAVXDbup75AIuZwiIJjIIT72S4PWoXdxcgjI2n1fv0=; b=HhcJw8h8HvJTeSVcF6wTE7XnAWt5wHW+V7YIm81tiDIMc5WUz4OHKP5ZaQQwW4mCZK DnubiPwP2ysfHKaXHErkqySi8mSNYLVZ++2INdy48UH4c/OKP8KIBDQq1qD0Hze0Zzr5 YpsDlR9E95ViTUm2KG8ZmgBijJt+1Au4BYUPY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:content-type; b=ql5MRL3aPIMlH3heq3kRVd6gQ5aqzqU1HoUMMqC8oUfpcK2AOup25x53Xq0smQJWEf 2QKSktErKq2kS7KyTVYna1nwUXiW6mGNemJEETlwBUoj0GaUY+PA5Wo+aZShOzHGfed+ KiG0ECM0PnzYCfyWvOBxeN12lgBk5rNBznrGE= Received: by 10.216.48.70 with SMTP id u48mr11948433web.25.1293319566356; Sat, 25 Dec 2010 15:26:06 -0800 (PST) Received: from debian.bg45.phnet (12-131.62-81.cust.bluewin.ch [81.62.131.12]) by mx.google.com with ESMTPS id e12sm5092245wer.36.2010.12.25.15.26.02 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sat, 25 Dec 2010 15:26:05 -0800 (PST) Message-ID: <4D167D77.3000303@gmail.com> Date: Sun, 26 Dec 2010 00:25:43 +0100 From: =?UTF-8?B?VmxhZGltaXIgJ8+GLWNvZGVyL3BoY29kZXInIFNlcmJpbmVua28=?= User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.16) Gecko/20101211 Icedove/3.0.11 MIME-Version: 1.0 To: =?UTF-8?B?Tmljb2xhcyBkZSBQZXNsb8O8YW4=?= References: <4D0FB8A2.5060407@gmail.com> <4D15E5C9.8000501@gmail.com> <4D164CC5.1090105@gmail.com> <4D16505E.3050209@gmail.com> <4D1670F1.7080701@gmail.com> In-Reply-To: <4D1670F1.7080701@gmail.com> X-Enigmail-Version: 1.0.1 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="------------enigBAFC5DC72282C095431CFC1A" X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 2) Cc: The development of GNU GRUB Subject: Re: USB bulk transfert from GRUB ? X-BeenThere: grub-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: The development of GNU GRUB List-Id: The development of GNU GRUB List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 25 Dec 2010 23:26:10 -0000 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enigBAFC5DC72282C095431CFC1A Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 12/25/2010 11:32 PM, Nicolas de Peslo=C3=BCan wrote: > > usb-modeswitch uses vendor/device id to detect switchable devices. > I understand how it works, I meant how do you control it? > Depending on the device, the way to switch might change. Some devices > simply require an SCSI eject command to switch. Most require a bulk > transfer of a given string. Some require extra stuff. > usbms can send arbitrary SCSI command. >> I still don't a clear grasp of target usecases and hence of the >> appropriate ways to autoconfig. > > I propose to try on a "non-autoconfig" way, then decide later if we > can find a good way to autoconfig things. > It's ok to do thing partially or non-autoconf but it should be done in a way to avoid of being stuck with inconvenient interface because once a command added it can't e removed.Interesting possibility. Perhaps such devices could be scanned on >> runtime and we look at present files. > > By "look at present files", do you mean "look at the files in the ISO > image"? > Yes. Perhaps even: look for disk with UUID=3DmyUUID if failed switch device, look again. How much overhead is switching? > The device I own (made by Option) support two totally different update > parts and corresponding update softwares: > Wouldn't it be a HSPA modem? Swisscom by any chance? I had one of those but itbroke when I've put my laptop into the bag with the modem still in USB port. > - One is the firmware, and I don't plan to update it, even if the > software to do so is easily available. > - One is the ISO image for the virtual CD reader. The software to > update the ISO image is apparently no more available, but I have a > copy of it. The software is designed to update the Windows drivers > provided by the device. > > I successfully "burn" a new ISO image, in eltorito format, that have > GRUB and /boot inside. /boot contains the kernel and an enhanced > initrd image to be able to switch the device, before accessing / from > the micro-SD. All this work. The only problem is that every time I > upgrade the kernel (/boot), I need to build and burn the ISO image agai= n. > > In would prefer to only have a reasonably stable version of grub in > the ISO image, that only switch the device, then chainload to another > grub,=20 Even if you make the USB device switch BIOS still won't see the new device (very few BIOSes support hotplug). Moreover it's a bad idea to revert to BIOS routines once you started sending direct USB/ATA/AHCI messages. While some form of chainloading (using multiboot) is still possible in this config I recommend against it. Just make GRUB on ISO boot linux on microSD. Current GRUB should be compatible with future linu= xes > Of course, if someone want to do some reverse engineering on the > "burning" software, then it might become far more convenient to "burn" > the ISO image, removing the need for grub to be able to switch. > It's outside of GRUB scope. > But a more general framework to initiate a bulk transfer would allow > for more devices to be supported, including those which lack the > ability to update the ISO image. > > Nicolas. > --=20 Regards Vladimir '=CF=86-coder/phcoder' Serbinenko --------------enigBAFC5DC72282C095431CFC1A Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iF4EAREKAAYFAk0WfXgACgkQNak7dOguQgklJAEAvmTHGC2khrICAWiIPEXDk7LW lgYDjyWJBW0xiymc544A/1OfWPYMigrAugLW+vY/EGLZjnQLDAT1pI0b8Ol2JWK8 =jIpW -----END PGP SIGNATURE----- --------------enigBAFC5DC72282C095431CFC1A--