[U-Boot] USB mass storage gadget patch

Lukasz Majewski
2012-11-02T13:19:09Z

Hi victor,

> Lukasz,
>
> I am looking at the usb mass storage gadget patch from you at:

USB mass storage gadget reference:
[*]
http://patchwork.ozlabs.org/patch/104516/
>
> I am trying to use this patch in the u-boot. Some questions:
> 1) Is this patch in U-boot git release?

Unfortunately not. It has been posted, but so far wasn't accepted to
mainline u-boot.

The reason is that in meantime I've added composite gadget support for
the u-boot USB stack. DFU "function" uses this composite gadget
framework.

UMS (ver. [*]) shall also be modified to work with the composite
gadget framework. Posted patch [*] works as a standalone USB
gadget.

> 2) Now I can use the patch and process till SCSI MODE_SELECT_6
> command, and then problem is encountered. Basically the SCSI
> MODE_SELECT_6 is sent to EP1 Out, then data is sent to EP1 out, and
> the fsg_main_thread only sees the data. I change the code to force
> the CSW.

Can you explain further problems which you encounter?

I'm using this UMS version internally (the version which you pointed
out with the link) for debugging our targets.

I'm using Debian Linux as a host with standard tools like dd and
parted/fdisk. I don't have any problems with it (even with debug
messages enabled).

[*] implementation of UMS has one (bit) flaw:
It doesn't provide "caching" for read/write operations. Therefore
sending bigger files is very time consuming.

This and support for composite gadget infrastructure shall be developed
for v3 of UMS patch set.

>
> The changes are:
> 1) fix the buf pointer in scsi inquiry
> 2) fix the buf pointer in scsi read format capacities
> 3) fix the buf pointer in CSW sending
> 4) fix attention condition checking in scsi command check
> 5) fix the context pointer before queue a request to read bulk only
> CBW 6) change bulk out endpoint from endpoint 2 to endpoint 1 to
> accommodate gen2 usb hardware limitation
> 7) in pad_with_zeros(), comment out the bh->inreq->length = nsend
> 8) in received_cbw(), force to send CSW if CBW is invalid. Otherwise,
> the IRQ routine keeps on reading the same data.
>
> I attach the file for your reference. Please kindly advise me. Thanks.

Thanks for your fixes, but as I said previously, could you put some more
shed on the problem?

--
Best regards,

Lukasz Majewski

Samsung Poland R&D Center | Linux Platform Group