Actions
Forum Thread Details
  • State Verified Answer
  • Replies 10 replies
  • Answers 1 answer
  • Subscribers 343 subscribers
  • Views 3310 views
  • Users 0 members are here
Related

Microzed USB configuration for petalinux 2018

maldata

Hi all,

 

I can see many discussions in the forums about getting USB host-mode working on a Microzed (Zynq 7020). In particular, here's a selection of links that I've already read:

 

 

I've spent a lot of time googling, but have so far not been successful. I'm using Petalinux 2018 and the Zedboard metadata layers to build the image. I added a device tree layer similar to what is presented here: https://xilinx-wiki.atlassian.net/wiki/spaces/A/pages/18842272/Zynq+Linux+USB+Device+Driver

 

By itself, that doesn't work. No USB bus is available. However, I changed the bus's "compatible" property and moved "drv-vbus" from the phy to the bus itself, so now I have

 

/ {

    usb_phy0: phy0 {

        compatible = "usb-nop-xceiv";

        #phy-cells = <0>;

        reg = <0xe0002000 0x1000>;

        view-port = <0x170>;

    };

};

 

&usb0 {

    dr_mode = "host";

    usb-phy = <&usb_phy0>;

    drv-vbus;

};

 

When I use this device tree, the USB bus appears to be available:

 

# lsusb

Bus 001 Device 001: ID 1d6b:0002

# dmesg | grep -i usb

usbcore: registered new interface driver usbfs

usbcore: registered new interface driver hub

usbcore: registered new device driver usb

usb_phy_generic e0002000.phy0: e0002000.phy0 supply vcc not found, using dummy regulator

ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver

usbcore: registered new interface driver usb-storage

chipidea-usb2 e0002000.usb: e0002000.usb supply vbus not found, using dummy regulator

ci_hdrc ci_hdrc.0: new USB bus registered, assigned bus number 1

ci_hdrc ci_hdrc.0: USB 2.0 started, EHCI 1.00

hub 1-0:1.0: USB hub found

usbcore: registered new interface driver usbhid

usbhid: USB HID core driver

 

However, the board still does not recognize any USB devices plugged into it. If I plug in a USB flash drive, for example, the LED on the drive does light up, but nothing new is available in lsusb, no new messages appear in dmesg, and no new block device appears in /dev.

 

I've tried everything in the links above, I've tried different USB devices, I've tried a powered USB hub, and all I can figure is that there's still some device between the OS and the port that isn't configured correctly. In particular, I'd like to know more about the following:

 

  • Is there a requirement to toggle the reset on the USB3320 chip after power comes up? I have seen some mention of this in similar posts.
    • Sometimes this is handled by the first-stage bootloader. Can AVnet confirm?
    • If not the first-stage bootloader, does this need to be done some other way?
  • Does USB need to be enabled by setting a GPIO? If so, which GPIO?
  • In older versions of the linux kernel/device tree, a USB PHY configuration was not needed. Now, a PHY element must be added to the device tree in order for the system to recognize the USB root hub. This is not done in the stock Zynq-7000 metadata.
    • Can you confirm that usb-nop-xceiv is appropriate for this PHY?
    • Does the PHY require configuration of clocks or regulators in order to function correctly?
  • When USB devices are inserted, the kernel does not fire uevents. Is there any configuration beyond default that is needed to enable this, or is there a hardware/device tree configuration issue blocking this?
    • In the current configuration, the EHCI is correctly detected
    • Is there any kernel configuration required to ensure that hub IRQs are handled correctly?
    • Is there any kernel configuration required to ensure that hub events are handled correctly?

 

Has anyone managed to get this working on a Microzed, and if so, can you share your method?

 

Thanks!

  • 0

    Hi Mark,

     

    I see you have a lot of rather complex questions you are asking about USB which is something that appears to have not yet been demonstrated to work on your end with your MicroZed  Let's try to simplify this a bit and start from something that is known to work and then perhaps you can spiral out from there changing one variable at a time to see what works and what step breaks things.  At a minimum, this approach should at least tell us that you have good hardware you are working with.

     

    On my desk I have a MicroZed 7020 plugged into an FMC Carrier and powered off a 6-pin 12V power supply.  I am booting from bootable files that come from the pre-built PetaLinux image found withing the 2018.2 BSP from the MicroZed resource page here:

     

    MicroZed

     

    On that page, there is a section labeled PetaLinux Board Support Packages where I found this file:

     

    mz7020_fmccc_2018_2_0.zip

     

    You can unpack the archive and use this PetaLinux BSP according to Xilinx UG1144 to create new PetaLinux projects that are already targeted to MicroZed hardware:

     

    https://www.xilinx.com/support/documentation/sw_manuals/xilinx2018_2/ug1144-petalinux-tools-reference-guide.pdf

     

    Without needing to build a new PetaLinux 2018.2 project, you can simply use the pre-built files found in the /pre-built/linux/images/ folder and copy them to an SD card and boot MicroZed using SD card boot mode.

     

    When I tried this on my end, I was able to enumerate a USB thumb drive that was formatted with FAT32, mount the drive, write to a test file, unmount the drive, remount the drive, and read the contents of the test file back as seen here:

     

    3302.contentimage_192676.png

    My suggestion is to try to replicate this on your end and rule out any bad hardware.  Keep in mind that if you do not have MicroZed plugged into a carrier board and it is only being powered off the USB-UART port, then there may not be sufficient power supplied to the USB Host port (from your PC) and this can cause strange behaviors like the LED blinking on an attached USB thumb drive but the drive is not enumerated.

     

    Once you get the USB working, you can look through the BSP settings and see what sort of device tree entries are being used for our MicroZed targets for PetaLinux 2018.2 tools.

     

    I have a few follow-up questions for you.  It sounds like you are working on a new design, are you working with a local Avnet FAE on your new design?

     

    Best Regards,

     

    -Kevin

  • 0 in reply to zedhed

    Hi Kevin,

     

    Thanks for getting in touch! Here's some more info for you:

     

    1. I can confirm that the hardware is fine. I tried the prebuilt image, and I can mount a USB drive just as you described.
    2. There are some differences between the device tree that I built and the device tree in the BSP, but the USB and PHY sections are identical except for the phandle used to refer to the PHY. Would any of the other sections of the device tree somehow conflict with the USB device?
    3. This is not a new design. This is simply an upgrade from an older version of petalinux / older BSP / etc. to the current versions. The old image still works (including USB) on the exact same board, which is a big part of our confusion.

     

    Please let me know if you have any further insight. Thanks!

    -Mark

  • 0 in reply to zedhed

    Hi Kevin,

     

    I spent some time today comparing the sample device tree that works and the one I'm using. I did make some changes, but none had any effect on the USB situation. My current device tree is now practically identical to the one in the BSP I downloaded earlier. The only exceptions:

    1. My kernel bootargs are set to boot from the SD card
    2. A few properties of the flash node are different
    3. The ethernet PHY node (note, NOT the USB PHY... ethernet has always worked fine) is defined at the root level, rather than under the ethernet node itself

     

    On my device, I still get the root hub listed, but no USB devices are recognized when attached.

     

    None of these differences in the device tree should have any effect on the USB device. Is that correct? If so, where should we turn our attention? The kernel configuration?

     

    Thanks,

    -Mark

  • 0 in reply to zedhed

    Actually, the kernel configuration is also virtually identical to the sample. Still nothing. Root hub exists, but devices are not detected when attached.

  • 0 in reply to maldata

    Hi Mark,

     

    Is there an issue with starting from the known good working BSP we provide and adding in what you need for your end application?

     

    -Josh

  • 0

    Here's an update. What I found is that I can start with the vendor BSP, and instead of booting from the ramdisk, I can boot from the rootfs from our PetaLinux project, and the USB port works fine. That rules out the rootfs. Also, the kernel configuration and device tree are pretty much identical to what we produce, so it seems like those are also fine.

     

    The only remaining thing from the BSP then is the BOOT.BIN file. As far as I know, the only things in there are the u-boot executable and the FPGA bitstream, so:

    1. Is there anything at all that may cause u-boot to improperly initialize a device or something?
    2. Is it possible that the FPGA program could somehow cause the USB port to fail?
    3. Is there anything else in BOOT.BIN that I'm not aware of?

     

    I'm still working with the team to determine if there have been any changes to the FPGA since the older, working version.

     

    Thanks,

    -Mark

  • 0 in reply to maldata

    Hi Mark,

     

    This is some pretty good troubleshooting steps that you have taken so far, it certainly helps narrow down the source of the issue.

     

    Have you done any modifications to the hardware platform in Vivado?

     

    I went back and looked at some old notes and I see this note in the hardware user guide:

     

    6064.contentimage_192677.png

     

    5276-MicroZed-HW-UG-v1-7-V1.pdf

     

    Have you checked the state of the PS_MIO7 signal to make sure that your FSBL within the BOOT.BIN file is not keeping the USB PHY in reset?

     

    Best Regards,

     

    -Kevin

  • 0 in reply to maldata

    Hi Mark,

     

    I am not sure which pieces you are modifying, but you can use BootGen to recreate the FSBL by using the pre-built fsbl.elf, download.bit, and u-boot.elf files to recreate the BOOT.BIN that is provided as part of the BSP and then use process of elimination to insert your components one at a time into your own custom BOOT.BIN until you see which one breaks.  If the fsbl.elf is the culprit, then I would recommend to check your Viviado design for the correct settings.

     

    I have some further notes here on the HW configuration used by the PetaLinux BSP.

     

    These are the settings we are using for the PS7 block in the Vivado block diagram:

     

    CONFIG.PCW_EN_USB0 {1}

    CONFIG.PCW_USB0_PERIPHERAL_ENABLE {1}

    CONFIG.PCW_USB0_RESET_ENABLE {1}

    CONFIG.PCW_USB0_RESET_IO {MIO 7}

    CONFIG.PCW_USB0_USB0_IO {MIO 28 .. 39}

    CONFIG.PCW_USB_RESET_ENABLE {1}

    CONFIG.PCW_USB_RESET_POLARITY {Active Low}

    CONFIG.PCW_USB_RESET_SELECT {Share reset pin}

     

    If you are modifying the hardware at all using Vivado or making your own hardware platform and then exporting to PetaLinux, please check that your settings match the above settings.

     

    Best Regards,

     

    -Kevin

  • 0

    Closing the loop here: It looks like the FPGA was not correctly configured. The USB reset configuration that Kevin posted here didn't match the FPGA configuration, so the bitstream embedded in the BOOT.BIN file was the culprit.

     

    Thanks everyone for helping us get to the solution!