From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with archive (Exim 4.43) id 1P1hEK-0006Xm-Fp for mharc-grub-devel@gnu.org; Fri, 01 Oct 2010 11:09:00 -0400 Received: from [140.186.70.92] (port=47591 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1P1hEE-0006PP-DH for grub-devel@gnu.org; Fri, 01 Oct 2010 11:08:59 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1P1hC4-0007AI-6x for grub-devel@gnu.org; Fri, 01 Oct 2010 11:06:41 -0400 Received: from smtp-out3.iol.cz ([194.228.2.91]:43675) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1P1hC3-0007A7-Ri for grub-devel@gnu.org; Fri, 01 Oct 2010 11:06:40 -0400 Received: from antivir5.iol.cz (unknown [192.168.30.212]) by smtp-out3.iol.cz (Postfix) with ESMTP id A57AABC8D63 for ; Fri, 1 Oct 2010 15:06:37 +0000 (UTC) Received: from localhost (antivir5.iol.cz [127.0.0.1]) by antivir5.iol.cz (Postfix) with ESMTP id 9321D1E8031 for ; Fri, 1 Oct 2010 17:06:37 +0200 (CEST) X-Virus-Scanned: amavisd-new at iol.cz Received: from antivir5.iol.cz ([127.0.0.1]) by localhost (antivir5.iol.cz [127.0.0.1]) (amavisd-new, port 10224) with LMTP id mFrESQaljtqL for ; Fri, 1 Oct 2010 17:06:37 +0200 (CEST) Received: from port7.iol.cz (unknown [192.168.30.97]) by antivir5.iol.cz (Postfix) with ESMTP id 780BD1E802F for ; Fri, 1 Oct 2010 17:06:37 +0200 (CEST) X-SBRS: None X-SBRS-none: None X-RECVLIST: MTA-OUT-IOL X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiILAD6VpUxVRnXk/2dsb2JhbAAHgxeBAdNbkiSBIoMudASJTw Received: from 228.117.broadband3.iol.cz (HELO [192.168.6.160]) ([85.70.117.228]) by port7.iol.cz with ESMTP; 01 Oct 2010 17:06:37 +0200 From: =?UTF-8?Q?Ale=C5=A1?= Nesrsta To: The development of GNU GRUB In-Reply-To: <4CA4FC38.8000308@gmail.com> References: <1285531907.4545.9.camel@pracovna> <4CA4FC38.8000308@gmail.com> Content-Type: text/plain; charset=utf-8 Date: Fri, 01 Oct 2010 17:06:35 +0200 Message-Id: <1285945596.6460.14.camel@pracovna> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 Content-Transfer-Encoding: quoted-printable X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6, seldom 2.4 (older, 4) Subject: Re: [PATCH] USB Mass Storage CBI support 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: Fri, 01 Oct 2010 15:08:59 -0000 Vladimir '=CF=86-coder/phcoder' Serbinenko wrote:=20 > On 09/26/2010 10:11 PM, Ale=C5=A1 Nesrsta wrote: > > + grub_uint8_t cbicb[GRUB_USBMS_CBI_CMD_SIZE] =3D > > + { 0x1d, 0x04, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, 0xff, > > + 0xff, 0xff > > + }; > > =20 > Could you deblob this? > Other that this it can be merged into experimental. Be sure to push > branches/cbi and then merge branches/cbi into experimental Hi, I am sorry, but I don't know what is "deblob", my English language knowledge is unfortunately little bit limited (as you probably noticed before...)... (My dictionary says: "blob" is "small amount of a thick liquid"...) I guess you probably want to explain what the code means and add related comment (?) It is CBI specific command "Command Block Reset" which should be used to reset CBI protocol in "phase error" or similar fatal cases, i.e. it is something like "Bulk Only Reset" control command. There is difference between BO and CBI style of device communication reset: "Bulk Only Reset" is class-specific request for Bulk Only Mass Storage devices. CBI "Command Block Reset" is sent to device as a command block, i.e. as DATA of CBI class-specific "universal" request ADSC. (In both cases should be additionally cleared HALT feature on all EPs - except control EP 0.) In "USB Mass Storage Class Control/Bulk/Interrupt (CBI) Transport" specification (http://www.usb.org/developers/devclass_docs/usb_msc_cbi_1.1.pdf) you can find "Command Block Reset" in chapter 2.2 Command Block Reset Protocol, there is part of specification (citation): "... To issue a Command Block Reset, the host shall use the Non-Data Command Protocol to transport the command block: 1Dh 04h FFh FFh FFh FFh ... The device may use the trailing FFh bytes to distinguish the Command Block Reset from the legacy op 1Dh SEND DIAGNOSTIC command block. ..." Regards Ales=20 >=20 > _______________________________________________ > Grub-devel mailing list > Grub-devel@gnu.org > http://lists.gnu.org/mailman/listinfo/grub-devel