Possible USB Mass Storage bug on Xilinx's Zynq

[Sean Anderson]

On 4/19/21 9:05 AM, Bruno L. Albrecht wrote:
> Hello people,
> it's my first post here, so forgive me if I do something wrong. I'll try to
> be short and clear.
> 
> I'm developing on an Avnet PicoZed (based on a Xilinx Zynq SoC) and my
> objective is to expose the eMMC as a Mass Storage Device over an USB
> Connection.
> 
> I used the following config flag on defconfig file (
> https://github.com/Xilinx/u-boot-xlnx/blob/master/configs/xilinx_zynq_virt_defconfig
> ):
> 
> CONFIG_CMD_USB_MASS_STORAGE=y
> 
> 
> To the Device Tree (
> https://github.com/Xilinx/u-boot-xlnx/blob/master/arch/arm/dts/zynq-picozed.dts)
> I added the usb configuration:
> 
> aliases {
>>          <...>
>>          usb0 = &usb0;
>> };
>> &usb0 {
>>          u-boot,dm-pre-reloc;
>>          status = "okay";
>>          dr_mode = "peripheral";
>> };
> 
> 
> Compilation goes fine and U-Boot boots fine. The eMMC is correctly
> recognized.
> Then I use the following command to initiate the USB Mass Storage:
> 
> ums 0 mmc 0
> 
> 
> When on *Windows*, the command is successful for a brief moment and then
> the board resets with the following error:
> 
> Zynq> ums 0 mmc 0
>> UMS: LUN 0, dev 0, hwpart 0, sector 0x0, count 0xe30000
>> \EP1/in FAIL info=40000080 pg0=3eb393c0
>> EP1/in FAIL info=40008080 pg0=3eb3d3c0
>> EP1/in FAIL info=d8080 pg0=3eaebdc0
>> CACHE: Misaligned operation at range [00000001, 00000041]
>> CACHE: Misaligned operation at range [00000001, 00000041]
>> data abort
>> pc : [<3ff67dec>]          lr : [<3ff67dec>]
>> reloc pc : [<0405cdec>]    lr : [<0405cdec>]

I don't know anything about this platform, but I'd start with figuring
out what function/line these are from. You can find out by grepping
through objdump -S.

--Sean

>> sp : 3eae81f0  ip : 00000031     fp : 3ffd957c
>> r10: 00000001  r9 : 3eaeaed0     r8 : 00000001
>> r7 : 3ffd9524  r6 : 00000001     r5 : 3ffd94ec  r4 : 3ffd95a4
>> r3 : e0001000  r2 : 00000001     r1 : 00000041  r0 : 00000001
>> Flags: nZCv  IRQs off  FIQs off  Mode SVC_32
>> Code: eaffff7e e2861040 e1a00006 ebfe91a6 (e5963004)
>> Resetting CPU ...
>>
> 
> Since I'm working on a Windows machine, I have a Ubuntu running on a
> Virtual Machine (VirtualBox). So I made a rule to bypass the USB device
> that would be created on Windows directly to the Virtual Machine (virtually
> connected the USB device to my Ubuntu).
> 
> When I do this, the command works. I can access the eMMC and format it and
> do whatever I want. If I remove the filter and let Windows enumerate the
> device, the board resets again.
> 
> I took a look at the dmesg messages on Ubuntu and found the following (the
> only unusual messages are in bold):
> 
> [101436.784042] usb 1-2: new full-speed USB device number 25 using ohci-pci
>>
>> *[101437.232208] usb 1-2: config 1 interface 0 altsetting 0 endpoint 0x81
>> has invalid maxpacket 512, setting to 64[101437.232210] usb 1-2: config 1
>> interface 0 altsetting 0 endpoint 0x2 has invalid maxpacket 512, setting to
>> 64*
>> [101437.477816] usb 1-2: New USB device found, idVendor=<custom>,
>> idProduct=<custom>, bcdDevice= 2.21
>> [101437.477818] usb 1-2: New USB device strings: Mfr=1, Product=2,
>> SerialNumber=0
>> [101437.477820] usb 1-2: Product: my product name
>> [101437.477821] usb 1-2: Manufacturer: my manufacturer
>> [101437.702297] usb-storage 1-2:1.0: USB Mass Storage device detected
>> [101437.713954] scsi host3: usb-storage 1-2:1.0
>> [101438.976664] scsi 3:0:0:0: Direct-Access     Linux    UMS disk 0
>> ffff PQ: 0 ANSI: 2
>> [101438.979158] sd 3:0:0:0: Attached scsi generic sg2 type 0
>> [101439.284100] sd 3:0:0:0: [sdb] 14876672 512-byte logical blocks: (7.62
>> GB/7.09 GiB)
>> [101439.468523] sd 3:0:0:0: [sdb] Write Protect is off
>> [101439.468526] sd 3:0:0:0: [sdb] Mode Sense: 0f 00 00 00
>> [101439.653020] sd 3:0:0:0: [sdb] Write cache: enabled, read cache:
>> enabled, doesn't support DPO or FUA
>> [101440.759756]  sdb: sdb1
>> [101441.559083] sd 3:0:0:0: [sdb] Attached SCSI removable disk
>>
> 
> Not that it sounds like it would interfere, but the USB from the SoC is
> connected to an USB Hub (USB2514B), to which other devices are connected
> and work correctly on both Windows and Linux.
> 
> Any ideas of what might be happening?
> 
> 
> Cheers
> Bruno
> 
>