From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with archive (Exim 4.43) id 1PWcf2-0002HM-NZ for mharc-grub-devel@gnu.org; Sat, 25 Dec 2010 17:32:24 -0500 Received: from [140.186.70.92] (port=58687 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PWcf0-0002Gq-LF for grub-devel@gnu.org; Sat, 25 Dec 2010 17:32:23 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1PWcez-0007qA-3V for grub-devel@gnu.org; Sat, 25 Dec 2010 17:32:22 -0500 Received: from mail-ww0-f41.google.com ([74.125.82.41]:49867) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1PWcey-0007ps-Ki for grub-devel@gnu.org; Sat, 25 Dec 2010 17:32:21 -0500 Received: by wwi18 with SMTP id 18so8083534wwi.0 for ; Sat, 25 Dec 2010 14:32:19 -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 :content-type:content-transfer-encoding; bh=UGXeLKEHLl7+xKmAHXCNQC2I6OB2+Fw48xw8gWLs7sc=; b=DzWIsFAjGW55emdeMDKRUjbEXPZFuiuJ648cIUJA5CR3A+q+xBJwpVKLxLOz3onvJl Ytd4aN+ILW3zDzi29BlYI8+vKee6kHzEDyjhv3DeGQV2CEL8wXLTaKwif3ltRXyvxmPj brSHvHwAduZzp37JOu9ynr4Lp9UhCPT0WhjHA= 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:content-type:content-transfer-encoding; b=VvYtTmI8HK39fX320I6JsxpRQeHeDXSXZsOwTQq1LvvLgWN4b/wmkjQgY5PK6n/c1N 5OXEoG0Cv4djI9VoRrbc0sVrTq5YkWHZzyKOKlb04BobWrZjrajJUgnaylj/kmhhRroI g1cFZ8dDPE3OW+77MkUetY+RWLZljLlHjIpZk= Received: by 10.227.129.83 with SMTP id n19mr6416348wbs.99.1293316339567; Sat, 25 Dec 2010 14:32:19 -0800 (PST) Received: from [192.168.1.13] (AReims-156-1-48-106.w86-192.abo.wanadoo.fr [86.192.223.106]) by mx.google.com with ESMTPS id 11sm7207159wbi.6.2010.12.25.14.32.18 (version=SSLv3 cipher=RC4-MD5); Sat, 25 Dec 2010 14:32:18 -0800 (PST) Message-ID: <4D1670F1.7080701@gmail.com> Date: Sat, 25 Dec 2010 23:32:17 +0100 From: =?UTF-8?B?Tmljb2xhcyBkZSBQZXNsb8O8YW4=?= User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.15) Gecko/20101030 Icedove/3.0.10 MIME-Version: 1.0 To: =?UTF-8?B?VmxhZGltaXIgJ8+GLWNvZGVyL3BoY29kZXInIFNlcmJpbmVua28=?= References: <4D0FB8A2.5060407@gmail.com> <4D15E5C9.8000501@gmail.com> <4D164CC5.1090105@gmail.com> <4D16505E.3050209@gmail.com> In-Reply-To: <4D16505E.3050209@gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit 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 22:32:23 -0000 On 12/25/2010 09:13 PM, Vladimir 'φ-coder/phcoder' Serbinenko wrote: >> Whould you support adding such command? >> >> usb_bulk_write >> > usb bus/address is assigned on runtime and depends on enumeration order > so no way to know it in advance for sure. If usbid = vendor/device id > then it's posssible although doesn't seem optimal. Which interface does > usb-modeswitch use? Yes, usbid is vendor/device id. usb-modeswitch uses vendor/device id to detect switchable devices. 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. >> Yes, you are right. I didn't plan to try and use a fixed USB address. >> But, it sounds reasonable to assume that, for a given user, the device >> is always the same (usb id). So, the usb id of the device, the >> endpoint number and the string to send to the endpoint could be >> selected at grub-mkconfig time and given as arguments to the grub >> command I plan to create. >> > 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. >> The kind of device I know provides two different modes: >> >> - default mode, where the device is seen as a CD reader and gives >> access to a virtual CD that hold the Windows drivers for the device. >> (Mostly useless, from a non Windows point of view). >> - switched mode, where the device is seen as a 3G modem plus a >> micro-SD card reader. I plan to boot from this micro-SD card. >> >> From a grub point of view, deciding to switch or to stay to the >> default mode depends on whether the "kernel" one plan to boot is >> located on a normal device or one a device that need to be switched >> prior to be usable. >> >> So the switch command should only be incorporated into the menu entry >> that is designed to boot on the switchable device that hold the >> micro-SD card. > 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"? >> And by the way, it is possible to virtually "burn" an ISO image into >> the device, so it is possible to use the virtual CD reader to hold >> grub. But that is another story. >> > I've vaguely heard that this way you can actually change the device > firmware so I wouldn't exepriment with this unless I can allow myself > brick the device in question (I actually have one such device) The device I own (made by Option) support two totally different update parts and corresponding update softwares: - 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 again. 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, located on the micro-SD. This would require far less frequent updates of the ISO image. This would also allow for normal operation for everything on the micro-SD, including a fresh version of grub if necessary. 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. 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.