News:

Attention: For security reasons,please choose a user name *different* from your login name.
Also make sure to choose a secure password and change it regularly.

Main Menu

TE0720 + TE0703 Gadget Serial

Started by En1kay, August 14, 2023, 04:12:54 PM

Previous topic - Next topic

En1kay

Hello everybody,

Iam trying to get the Gadget Serial to run with the above mentioned board. Steps taken so far:


  • I created a new vivado project with _create_win_setup.cmd
  • I exported the hardware .xsa
  • I started a new petalinux project by copying the "os/petalinux" files to my build-server
  • than I ran "petalinux-config --get-hw-description [name].xsa"

All fine up to this step. I started configuring for peripheral mode with the Gadget Serial driver


  • I edited the system-user.dtsi in project-spec/meta-user/recipes-bsp/device-tree/files to be in dr_mode="peripheral";
  • Then i ran "petalinux-configure -c u-boot" to check my changes for errors. There were no errors so I saved and exited
  • In the kernel configuration I edited the following:

Device Driver
     <*>    USB support
          <*>    USB Gadget Support
        [*]     Abstract Control Model (CDC ACM)
            USB Gadget precomposed configurations
                <*> Serial Gadget (with CDC ACM and CDC OBEX support)

Then I just build my image "petalinux-build" and packed the binary for boot "petalinux-package --boot --u-boot --fpga images/linux/system.bit".

If I run "dmesg | grep ci_hdrc" I get the following messages:

[    2.036131] ci_hdrc ci_hdrc.0: unable to init phy: -110
[    2.040083] ci_hdrc: probe of ci_hdrc.0 failed with error -110


and /sys/class/udc is empty.

I still ran "modprobe g_serial.ko" just to give it a try but i get:


udc-core: couldn't find an available UDC - added [g_serial] to list of pending drivers


as expected.

I also tried the exported binaried for the TE0720-03-1CFA (my board variant) but it is configured as "dr_mode="host";" therefore it is not usable for my project.

Any help would be appreciated as I'am definetly stuck now.

En1kay

Update:

Out of curiosity I changed the phy settings in the "system-user.dtsi" to include "compatible = "usb-nop-xceiv";" instead of "compatible = "ulpi-phy";" now it works.

I did not find any suggestions in the Trenz documentation to this setting. Could you maybe link me to the right place in order for me not to make the same mistake again?

M Kirberg

Hi,

normally we do not do peripherals often.

But I do have a USB gadget 2022.2 Project where there are no adaptions needed to devicetree, except for setting dr_mode to "peripheral".

Which version are you on

En1kay

Iam currently running:

  • Vivado 2022.2 on Windows 10 Pro 64 Bit (19045.3324)
  • Petalinux-Tools 2022.2 on Ubuntu 18.04.6 LTS (Bionic Beaver)

As described if I leave the "compatible = "ulpi-phy";" setting I get the ci_hdrc errors. However If I comment in the "compatible = "usb-nop-xceiv";"  setting which is already there and comment out "compatible = "ulpi-phy";" the ci_hdrc errors are gone and I see the "ci_hdrc.0" under "/sys/class/udc".

For initialization of the Gadget Serial I use the following "init.sh":


# load libcomposite module
modprobe libcomposite

# create a gadget
mkdir /sys/kernel/config/usb_gadget/g1
# cd to its configfs node
cd /sys/kernel/config/usb_gadget/g1

# configure it (vid/pid for Netchip Technology, Inc. Linux-USB Serial Gadget (CDC ACM mode))
echo 0x0525 > idVendor
echo 0xa4a7 > idProduct

# configure its serial/mfg/product
mkdir strings/0x409
echo myserial > strings/0x409/serialnumber
echo mymfg > strings/0x409/manufacturer
echo myproduct > strings/0x409/product

# create a config
mkdir configs/c.1
# configure it with attributes if needed
echo 120 > configs/c.1/MaxPower

# ensure acm function is loaded
modprobe usb_f_acm

# enable gadget by binding it to a UDC from /sys/class/udc
modprobe g_serial


The Gadget loads fine with the following message:


g_serial gadget: Gadget Serial v2.4
g_serial gadget: g_serial ready


However the connection is a bit flaky. No matter if I connect the USB-cable before or after boot it sometimes gets recognized as a COM-port and sometimes I get "unknown usb device (port reset failed)".

As a debugging step I started to lighten the kernel and available modules by changing the following configurations:


Device Drivers --->
    < > Multimedia support  ----

    < > Sound card support  ----

    HID support  --->
        < >   Generic HID driver
        USB HID support  --->
            < > USB HID transport layer
        < > HID bus support

    [*] USB support  --->
        < >   Support for Host-side USB
        <*>   USB Gadget Support  --->
            [*]     Abstract Control Model (CDC ACM)
            [ ]     Mass storage
            USB Gadget precomposed configurations  --->
            <M> Serial Gadget (with CDC ACM and CDC OBEX support)


However this seems to have no effect compared to the initial settings from the "TE0720 Test Board - Reference Design" os/petalinux template files for the kernel.

I would like to have this up and running stable (with USB plugged in before or after boot) in order to verify the USB peripheral mode with a simple example. Depending on data-rate constraints which are still discussed i am then planning on implementing a raw endpoint driver with Gadget FS or use the Gadget Serial with a high Baud Rate.

M Kirberg

Hi,

I see now, I am talking myself about ZynqMP without Modifications, Zynq is a little bit different.

The modifications you do sound to me like OTG detection could be shaky?
Did you try to fix dr_mode to "peripheral"?

I have seen shaky USB Enumeration on Petalinux < 2022.2, there are some Xilinx ARs to that, but as you are already using 2022.2 this is unlikely...

Swiss222

Hi,
Having the same issue with petalinux 2022 and TE0715 (so zynq 7000). I lost so much time before trying out
"compatible = "usb-nop-xceiv";

I am implementing USB RNDIS and I'm now facing new problems, but I can't be certain they aren't related to this compatibility issue with ulpi-phy . I couldn't find any other mention of this except in this thread, really wish this was documented somewhere.