public inbox for devel@edk2.groups.io
 help / color / mirror / Atom feed
From: "Tian, Feng" <feng.tian@intel.com>
To: Heyi Guo <heyi.guo@linaro.org>,
	"edk2-devel@lists.01.org" <edk2-devel@lists.01.org>
Cc: "Zeng, Star" <star.zeng@intel.com>, "Tian, Feng" <feng.tian@intel.com>
Subject: Re: Why is USB_BOOT_IO_BLOCKS set to 128?
Date: Thu, 19 Jan 2017 01:00:13 +0000	[thread overview]
Message-ID: <7F1BAD85ADEA444D97065A60D2E97EE5699AA9E1@SHSMSX101.ccr.corp.intel.com> (raw)
In-Reply-To: <76e11520-b4ba-7c78-cd55-d3d5502a4967@linaro.org>

Hi, Heyi

Just I said before, it's just an experience value. 

The transfer length limitation only comes from real h/w and the largest transfer length shipped by SCSI Read10/Write10 cmd.

A SCSI Read10/Write10 cmd supports max 0xFFFF blocks. But according to our experience, some h/w devices don't have such big internal buffer to support read/write 0xFFFF blocks once. That's why we introduced a back-off algorithm in ScsiDiskDxe to handle such case. 

As for Usb cdrom/bot devices, we just directly use such a macro to specify the max transfer length. If you met real problem, please tell me the device model/serial no, then we can modify this value accordingly.

Thanks
Feng

-----Original Message-----
From: edk2-devel [mailto:edk2-devel-bounces@lists.01.org] On Behalf Of Heyi Guo
Sent: Wednesday, January 18, 2017 2:41 PM
To: Tian, Feng <feng.tian@intel.com>; edk2-devel@lists.01.org
Cc: Zeng, Star <star.zeng@intel.com>
Subject: Re: [edk2] Why is USB_BOOT_IO_BLOCKS set to 128?

Hi Feng,

Digging in the code history, I found the original value of USB_BOOT_IO_BLOCKS was 64, but it was changed to be 128 by the commit 41e8ff2. So could you help to explain my questions as below?

1. What was the exact reason to change this value?

2. And for the comment in the code, it says "Max carried size is 512B *
128 = 64KB", but we see that some USB CDROM has block size of 2KB. So do we mean something for 64KB max size?

3. From USB specification perspective, is there any limit for transfer length, or the device should be able to transfer arbitrary length?

commit 41e8ff2781f3ca14f73ef5f39e781ccba8cb373d
Author: yshang1 <yshang1@6f19259b-4bc3-4df7-8a09-765794883524>
Date:   Mon Oct 8 06:14:13 2007 +0000

     Fixed unexpected timeout in Usb MassStorage Driver.
     Fixed unexpected timeout in Uhci/Ehci driver.

     git-svn-id: 
https://edk2.svn.sourceforge.net/svnroot/edk2/trunk/edk2@4038
6f19259b-4bc3-4df7-8a09-765794883524

Thanks and regards,

Heyi


在 10/19/2016 10:10 AM, Tian, Feng 写道:
> It's just an experience value and has been here about 10 years...
>
> Which usb brand/model name do you have problem on?
>
> Thanks
> Feng
>
> -----Original Message-----
> From: Heyi Guo [mailto:heyi.guo@linaro.org]
> Sent: Wednesday, October 19, 2016 9:57 AM
> To: edk2-devel@lists.01.org
> Cc: Tian, Feng <feng.tian@intel.com>; Zeng, Star <star.zeng@intel.com>
> Subject: [edk2] Why is USB_BOOT_IO_BLOCKS set to 128?
>
> Dear experts,
>
> Could anyone help to explain why USB_BOOT_IO_BLOCKS in MdeModulePkg/Bus/Usb/UsbMassStorageDxe/UsbMassBoot.h is set to 128?
>
> We found on some platforms this value may cause USB boot failure and
> *64* blocks will make them work. Though we have not got the final root cause, it will be really helpful if you can tell the reason of setting it to 128 and possible root cause for such issue.
>
> Thanks and regards,
>
> Heyi
>

_______________________________________________
edk2-devel mailing list
edk2-devel@lists.01.org
https://lists.01.org/mailman/listinfo/edk2-devel

  reply	other threads:[~2017-01-19  1:00 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-10-19  1:57 Why is USB_BOOT_IO_BLOCKS set to 128? Heyi Guo
2016-10-19  2:10 ` Tian, Feng
2016-10-20  1:35   ` Heyi Guo
2017-01-18  6:41   ` Heyi Guo
2017-01-19  1:00     ` Tian, Feng [this message]
2017-01-19  7:41       ` Heyi Guo

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-list from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=7F1BAD85ADEA444D97065A60D2E97EE5699AA9E1@SHSMSX101.ccr.corp.intel.com \
    --to=devel@edk2.groups.io \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox