Possible USB Mass Storage bug on Xilinx's Zynq

[Bruno L. Albrecht]

The EP1/in fails are on drivers/usb/gadget/ci_udc.c @ line 628. They happen
during enumeration (I'm able to check even exactly which package fails
using Wireshark + USB PCAP), but I couldn't find out more. I was hoping
someone had been through that and had an idea of could be happening before
I dive into the wonders of USB drivers.
The CACHE fails are from arch/arm/lib/cache.c @ line 64.



On Tue, 20 Apr 2021 at 06:15, Sean Anderson <seanga2 at gmail.com> wrote:

> 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
> >
> >
>
>

-- 
  Eng. Bruno Landau Albrecht
  e-mail: brunolalb at gmail.com