# CONFIG_USB_FUNCTIONFS is not set
rgetz opened this issue · comments
in
root@analog:~# cat /etc/rpi-issue
Raspberry Pi reference 2019-08-02
Generated using pi-gen, https://github.com/RPi-Distro/pi-gen, 29d362e5443c4f591885a4de3cbd48d4239efb70, stage6
root@analog:~# uname -a
Linux analog 4.19.86-v7l+ #763 SMP Wed Mar 11 18:21:19 EET 2020 armv7l GNU/Linux
functionfs isn't in the kernel, or a module, so I can't get usb gadget going with IIO.
root@analog:~# grep func /proc/filesystems
root@analog:~#
This should be fixed in the kernel.
Shouldn't this be CONFIG_USB_CONFIGFS_F_FS? Or some other symbol?
configfs is different that functionfs (we need both).
root@analog:~# zgrep USB_CONFIGFS /proc/config.gz
CONFIG_USB_CONFIGFS=m
CONFIG_USB_CONFIGFS_SERIAL=y
CONFIG_USB_CONFIGFS_ACM=y
CONFIG_USB_CONFIGFS_OBEX=y
CONFIG_USB_CONFIGFS_NCM=y
CONFIG_USB_CONFIGFS_ECM=y
CONFIG_USB_CONFIGFS_ECM_SUBSET=y
CONFIG_USB_CONFIGFS_RNDIS=y
CONFIG_USB_CONFIGFS_EEM=y
CONFIG_USB_CONFIGFS_MASS_STORAGE=y
CONFIG_USB_CONFIGFS_F_LB_SS=y
CONFIG_USB_CONFIGFS_F_FS=y
CONFIG_USB_CONFIGFS_F_UAC1=y
# CONFIG_USB_CONFIGFS_F_UAC1_LEGACY is not set
CONFIG_USB_CONFIGFS_F_UAC2=y
CONFIG_USB_CONFIGFS_F_MIDI=y
CONFIG_USB_CONFIGFS_F_HID=y
CONFIG_USB_CONFIGFS_F_UVC=y
CONFIG_USB_CONFIGFS_F_PRINTER=y
root@analog:~# zgrep -i function /proc/config.gz
# Multifunction device drivers
# CONFIG_USB_FUNCTIONFS is not set
CONFIG_HAVE_FUNCTION_TRACER=y
CONFIG_HAVE_FUNCTION_GRAPH_TRACER=y
CONFIG_FUNCTION_TRACER=y
CONFIG_FUNCTION_GRAPH_TRACER=y
CONFIG_FUNCTION_PROFILER=y
root@analog:~# uname -a
Linux analog 4.19.86-v7l+ #763 SMP Wed Mar 11 18:21:19 EET 2020 armv7l GNU/Linux
poking - makes me think it could be either CONFIG_USB_CONFIGFS_F_FS or CONFIG_USB_FUNCTIONFS depending on the system:
CONFIG_USB_CONFIGFS_F_FS from gadget/Kconfig:
https://github.com/torvalds/linux/blob/master/drivers/usb/gadget/Kconfig#L360-L370
or
CONFIG_USB_FUNCTIONFS: from gadget/legacy/Kconfig
https://github.com/torvalds/linux/blob/master/drivers/usb/gadget/legacy/Kconfig#L218-L235
poking - makes me think it could be either
CONFIG_USB_CONFIGFS_F_FSorCONFIG_USB_FUNCTIONFSdepending on the system:
CONFIG_USB_CONFIGFS_F_FSfromgadget/Kconfig:
https://github.com/torvalds/linux/blob/master/drivers/usb/gadget/Kconfig#L360-L370or
CONFIG_USB_FUNCTIONFS: fromgadget/legacy/Kconfig
https://github.com/torvalds/linux/blob/master/drivers/usb/gadget/legacy/Kconfig#L218-L235
that's my sentiment as well;
i actually took the symbols from the Pluto defconfig;
we know that the function_fs is working there;
however i can't say for sure yet that we don't need CONFIG_USB_FUNCTIONFS
needs some testing
I just tried R5 of the release on RPi 4, and it still isn't there...
root@analog:~# cat /etc/rpi-issue
Raspberry Pi reference 2020-11-15
Generated using adi-kuiper-gen, https://github.com/analogdevicesinc/adi-kuiper-gen, be5c92adae2be9bd83e29ffaa863ea63a710be27, stage8
root@analog:~# uname -a
Linux analog 4.19.86-v7l+ #3 SMP Sun Nov 15 18:11:34 UTC 2020 armv7l GNU/Linux
functionfs is still missing, configfs is there.
root@analog:~# cat /proc/filesystems | grep fun
root@analog:~# cat /proc/filesystems | grep con
nodev configfs
root@analog:~# modprobe configs
root@analog:~# zcat /proc/config.gz | grep CONFIG_USB_CONFIGFS_F_FS
CONFIG_USB_CONFIGFS_F_FS=y
root@analog:~# zcat /proc/config.gz | grep CONFIG_USB_FUNCTIONFS
# CONFIG_USB_FUNCTIONFS is not set
same on Zynq 7000 (it's not there)
root@analog:~# grep func /proc/filesystems
root@analog:~# grep con /proc/filesystems
nodev configfs
root@analog:~#
Raspberry Pi reference 2020-11-15
Generated using adi-kuiper-gen, https://github.com/analogdevicesinc/adi-kuiper-gen, be5c92adae2be9bd83e29ffaa863ea63a710be27, stage8
root@analog:~# uname -a
Linux analog 4.19.0-g82d2f24 #140 SMP PREEMPT Fri Nov 13 16:21:44 GMT 2020 armv7l GNU/Linux
root@analog:~# lsb_release -a
No LSB modules are available.
Distributor ID: Raspbian
Description: Kuiper GNU/Linux 10 (buster)
Release: 10
Codename: buster
root@analog:~# zcat /proc/config.gz | grep CONFIG_USB_CONFIGFS_F_FS
CONFIG_USB_CONFIGFS_F_FS=y
root@analog:~# zcat /proc/config.gz | grep CONFIG_USB_FUNCTIONFS
root@analog:~#
ok, but are you sure that CONFIG_USB_FUNCTIONFS is required?
and not just CONFIG_USB_CONFIGFS_F_FS
here's what i get for a ZC706 with the current kernel, and this is :
~ sudo ./tests/iio_info -s
Library version: 0.21 (git tag: 64f2e41)
Compiled with backends: local xml ip usb
Unable to create Local IIO context : No such file or directory
Available contexts:
0: 0456:b671 (Analog Devices Inc. Generic USB IIOD), serial=00000000 [usb:1.50.0]
1: fd8d:fcaf:19e2::bdd (xadc,ad9517-4,axi-ad9265-core-lpc) [ip:analog.local]
2: 192.168.20.168 (xadc,ad9517-4,axi-ad9265-core-lpc) [ip:analog.local]
i can't seem to see any devices via USB cable yet with iio-osciloscope
but iio_info -u usb: shows the details at the end [1];
to get this to work i also had to enable OTG mode in a ZC706 DT:
diff --git a/arch/arm/boot/dts/zynq-zc706-adv7511.dtsi b/arch/arm/boot/dts/zynq-zc706-adv7511.dtsi
index d61b6810bd97..c483ad683dcf 100644
--- a/arch/arm/boot/dts/zynq-zc706-adv7511.dtsi
+++ b/arch/arm/boot/dts/zynq-zc706-adv7511.dtsi
@@ -1,5 +1,11 @@
#include <dt-bindings/interrupt-controller/irq.h>
+&usb0 {
+ xlnx,phy-reset-gpio = <&gpio0 52 0>;
+ dr_mode = "otg";
+ status = "okay";
+};
+
I may need to see if xlnx,phy-reset-gpio is really needed.
also, this USB/OTG context seems to have been mostly used on Pluto and M2k and not much else;
maybe @mhennerich knows why;
if i search in the DTs for Zynq I get:
git grep otg | grep zynq
zynq-adrv9361-z7035-packrf.dts: dr_mode = "otg";
zynq-adrv9364-z7020-packrf.dts: dr_mode = "otg";
zynq-adrv9364-z7020-packrf.dts: otg_ctrl 24 78
zynq-m2k.dtsi: dr_mode = "otg";
zynq-pluto-sdr.dtsi: dr_mode = "otg";
zynq-zc706-adv7511.dtsi: dr_mode = "otg";
zynq-zed-adv7511-m2k-revb.dts: dr_mode = "otg";
zynq-zed-adv7511-m2k-revc.dts: dr_mode = "otg";
so, PackRF seems to have needed this, but I'm not sure when this was last tested, or if this was tested;
so, CONFIG_USB_CONFIGFS_F_FS=y seems to be sufficient;
also, CONFIG_USB_FUNCTIONFS can't be enabled without disabling something else;
it's a choice menuconfig:
in the picture above, Function filesystem (FunctionFS) is selected [already];
the CONFIG_USB_FUNCTIONFS symbol is under USB Gadget precomposed configurations; and looks like this:
i'm not sure if it's worth touching it, since it's under legacy; and is a mess to enable it;
the new FunctionFS seems to be working; maybe some quirks in libiio/iio-oscilloscope need to be resolved;
[1]
sudo ./tests/iio_info -u usb:
Library version: 0.21 (git tag: 64f2e41)
Compiled with backends: local xml ip usb
IIO context created with usb backend.
Backend version: 0.21 (git tag: d2396b0)
Backend description string: Linux analog 4.19.0-13386-gfa10bddfb981-dirty #2 SMP PREEMPT Mon Nov 23 11:48:30 EET 2020 armv7l
IIO context has 10 attributes:
hdl_system_id: [ad9265] [sys rom custom string placeholder] on [fmc] git <2e4ac278eb09c13471e381459b0da790ebad8373> clean [2019-12-05 00:09:09] UTC
local,kernel: 4.19.0-13386-gfa10bddfb981-dirty
uri: usb:1.54.0
usb,idVendor: 0456
usb,idProduct: b671
usb,release: 2.0
usb,vendor: Analog Devices Inc.
usb,product: Generic USB IIOD
usb,serial: 00000000
usb,libusb: 1.0.23.11397
IIO context has 4 devices:
iio:device0: xadc
9 channels found:
voltage5: vccoddr (input)
2 channel-specific attributes found:
attr 0: raw value: 2031
attr 1: scale value: 0.732421875
voltage0: vccint (input)
2 channel-specific attributes found:
attr 0: raw value: 1366
attr 1: scale value: 0.732421875
voltage4: vccpaux (input)
2 channel-specific attributes found:
attr 0: raw value: 2460
attr 1: scale value: 0.732421875
temp0: (input)
3 channel-specific attributes found:
attr 0: offset value: -2219
attr 1: raw value: 2478
attr 2: scale value: 123.040771484
voltage7: vrefn (input)
2 channel-specific attributes found:
attr 0: raw value: -2
attr 1: scale value: 0.732421875
voltage1: vccaux (input)
2 channel-specific attributes found:
attr 0: raw value: 2451
attr 1: scale value: 0.732421875
voltage2: vccbram (input)
2 channel-specific attributes found:
attr 0: raw value: 1363
attr 1: scale value: 0.732421875
voltage3: vccpint (input)
2 channel-specific attributes found:
attr 0: raw value: 1360
attr 1: scale value: 0.732421875
voltage6: vrefp (input)
2 channel-specific attributes found:
attr 0: raw value: 1700
attr 1: scale value: 0.732421875
1 device-specific attributes found:
attr 0: sampling_frequency value: 961538
No trigger on this device
iio:device1: ad9517-4
8 channels found:
altvoltage4: (output)
2 channel-specific attributes found:
attr 0: frequency value: 125000000
attr 1: raw value: 0
altvoltage3: (output)
2 channel-specific attributes found:
attr 0: frequency value: 125000000
attr 1: raw value: 1
altvoltage7: (output)
2 channel-specific attributes found:
attr 0: frequency value: 5208333
attr 1: raw value: 0
altvoltage2: (output)
2 channel-specific attributes found:
attr 0: frequency value: 125000000
attr 1: raw value: 0
altvoltage0: (output)
2 channel-specific attributes found:
attr 0: frequency value: 125000000
attr 1: raw value: 0
altvoltage5: (output)
2 channel-specific attributes found:
attr 0: frequency value: 125000000
attr 1: raw value: 1
altvoltage1: (output)
2 channel-specific attributes found:
attr 0: frequency value: 125000000
attr 1: raw value: 0
altvoltage6: (output)
2 channel-specific attributes found:
attr 0: frequency value: 5208333
attr 1: raw value: 0
1 debug attributes found:
debug attr 0: direct_reg_access value: 0x18
No trigger on this device
iio:device2: axi-ad9265-core-lpc (buffer capable)
1 channels found:
voltage0: (input, index: 0, format: le:S16/16>>0)
5 channel-specific attributes found:
attr 0: sampling_frequency value: 125000000
attr 1: scale value: 0.030517
attr 2: scale_available value: 0.019073 0.022888 0.026702 0.030517
attr 3: test_mode value: off
attr 4: test_mode_available value: off midscale_short pos_fullscale neg_fullscale checkerboard pn_long pn_short one_zero_toggle
3 buffer-specific attributes found:
attr 0: data_available value: 0
attr 1: length_align_bytes value: 8
attr 2: watermark value: 2048
2 debug attributes found:
debug attr 0: pseudorandom_err_check value: CH0 : PN9 : Out of Sync : PN Error
debug attr 1: direct_reg_access value: 0x18
No trigger on this device
iio_sysfs_trigger:
0 channels found:
2 device-specific attributes found:
attr 0: add_trigger ERROR: Permission denied (-13)
attr 1: remove_trigger ERROR: Permission denied (-13)
No trigger on this device
a question after the previous reply is:
- do we want to make the other Zynq/ZynqMP boards work with USB from a host-computer?
- are there reasons why this wasn't done before?
we can do it for the next releases;
i would not force this in 2019_R2 [since it wasn't done so far];
there's enough to fix in this release and it got delayed enough as-is;
we can do it in master and we'll have it in 2020_R1
Ok, there might be a bug with the USB context in iio-oscilloscope and not libiio.
Manually input-ing the USB URI works:
Ok, there might be a bug with the USB context in iio-oscilloscope and not libiio.
seems to be a bug with Ubuntu's libiio-dev;
if i use a locally built libiio it works
aptitude show libiio-dev
Package: libiio-dev
Version: 0.19-1
State: installed
Automatically installed: no
Multi-Arch: same
Priority: optional
Section: universe/libdevel
Maintainer: Ubuntu Developers <ubuntu-devel-discuss@lists.ubuntu.com>
Architecture: amd64
Uncompressed Size: 89,1 k
Depends: libiio0 (= 0.19-1)
Description: libiio development files
Libiio is a library that has been conceived to ease the development of applications interfacing Industrial Input/Output (IIO) devices through the IIO subsystem of the Linux kernel.
This package contains the development files.
Homepage: https://github.com/analogdevicesinc/libiio
-------------------------------------------------------------------------------------
aptitude show libiio0
Package: libiio0
Version: 0.19-1
State: installed
Automatically installed: yes
Multi-Arch: same
Priority: optional
Section: universe/libs
Maintainer: Ubuntu Developers <ubuntu-devel-discuss@lists.ubuntu.com>
Architecture: amd64
Uncompressed Size: 138 k
Depends: libavahi-client3 (>= 0.6.16), libavahi-common3 (>= 0.6.16), libc6 (>= 2.17), libserialport0, libusb-1.0-0 (>= 2:1.0.16), libxml2 (>= 2.7.4)
Suggests: avahi-daemon
Description: Library for interfacing with IIO devices
Libiio is a library that has been conceived to ease the development of applications interfacing Industrial Input/Output (IIO) devices through the IIO subsystem of the Linux kernel.
This package contains the shared library.
we could probably open a bug report; but we'll see;
a question after the previous reply is:
- do we want to make the other Zynq/ZynqMP boards work with USB from a host-computer?
Yes.
- are there reasons why this wasn't done before?
No.
Like you said - it was done for a few platforms, but there was no consistency.
This would improve the end user experience alot (IMHO). (no IP numbers to configure) - we get requests for this.
we could probably open a bug report; but we'll see;
last I checked debian was not installing the udev rule.
Xilinx ships broken USB Micro B to Female USB A Adapters in their kits.
Besides that it requires a few jumpers to move from their default position.
So enabling OTG mode by default for Xilinx carriers is causing lot's of support issues.
HOST mode can fail. So plugging in a keyboard no longer works.
Therefore we have enabled OTG mode only for ADI carriers. Such as SoM, SoM2, PACKRF, etc.
Ok.
So, then to me this sounds like we just let the CONFIG_USB_CONFIGFS_F_FS (not CONFIG_USB_FUNCTIONFS) enabled in the kernel, and enable this ADI boards via DT.
Or?
The new Kconfig.adi files in the kernel should make sure that whenever we select the [CONFIG_]KERNEL_ALL_ADI_DRIVERS symbol in a kernel build, that all symbols required to enable all ADI drivers get enabled.
As well as drivers that we care for ADI products (like these USB symbols).
This issue was about the Kconfig symbol; that seems to have been solved.
If we don't do anything in device-trees, maybe we can close this?
So enabling OTG mode by default for Xilinx carriers is causing lot's of support issues.
Enabling OTG mode - and allowing it to be self selected by the ID pin - I agree will cause issues.
Enabling OTG in the kernel, and providing two device trees (host mode, and device mode) should be easy (in theory)? and better than we have today...
?
michael@mhenneri-D06:~/devel/hdl/github-linux-work/linux/arch/arm/boot/dts$ grep dr_mode zynq*
zynq-adrv9361-z7035-packrf.dts: dr_mode = "otg";
zynq-adrv9364-z7020-packrf.dts: dr_mode = "otg";
zynq-cc108.dts: dr_mode = "host";
zynq-cc108.dts: dr_mode = "host";
zynq-coraz7s.dtsi: dr_mode = "host";
zynq.dtsi: dr_mode = "host"; /* This breaks OTG mode */
zynq-m2k.dtsi: dr_mode = "otg";
zynq-microzed.dts: dr_mode = "host";
zynq-pluto-sdr.dtsi: dr_mode = "otg";
zynq-zc702.dts: dr_mode = "host";
zynq-zc706.dts: dr_mode = "host";
zynq-zc770-xm010.dts: dr_mode = "host";
zynq-zc770-xm011.dts: dr_mode = "host";
zynq-zed-adv7511-m2k-revb.dts: dr_mode = "otg";
zynq-zed-adv7511-m2k-revc.dts: dr_mode = "otg";
zynq-zed.dts: dr_mode = "host";
zynq-zturn.dts: dr_mode = "host";
zynq-zybo.dts: dr_mode = "host";
zynq-zybo-z7.dts: dr_mode = "host";
michael@mhenneri-D06:~/devel/hdl/github-linux-work/linux/arch/arm/boot/dts$ ls zynq*.dts | wc
112 112 3472
This will double the device trees we have today..
This will double the device trees we have today..
Ok - I can pretty quickly make a script that decompiles device tree...
dtc -I dtb -O dts \BOOT\devicetree.dtb -o /tmp/tmp.dts
uses sed to search replace sed 's/dr_mode = "host";/dr_mode = "otg";//'
and recompliles/replaces for the next boot (if that's easier).
That's definitely the preferred option.
We can even turn this into a /usr/bin/enable_otg_mode script.
Mounts the boot partition depending on the target either processes system.dtb (zynqmp) or devicetree.dtb (zynq).
An alternative would be to use u-boot fdt utils to patch the dtb during boot.
This way you could use
#fw_setenv dr_mode otg
an overlay would be interesting;
it might just be a few patches to move over from the RPi branch;
or it might be that the current overlay support in the Linux master branch is sufficient;
it needs some testing;
we might be approaching a point where the Linux master tree could run on RPi as well;
well, at least some RPi boards may already run; maybe not all of them yet;
on a broader topic, overlays would be interesting because we could simplify our DTs;
we'd have some sort of base base DT, then just apply the ADRV7511 overlay [or not], or a DAQ2/3 overlay, or a USB configuration overlay, and so on;
This will double the device trees we have today..
Ok - I can pretty quickly make a script that decompiles device tree...
the only issue i see, is that some new device-tree compilers issue more warnings than older ones;
so, potential EZ questions;
and we typically build the DTs with the DT compiler that is in the kernel repo;
An alternative would be to use u-boot fdt utils to patch the dtb during boot.
This way you could use
#fw_setenv dr_mode otg
a uEnv.txt option, or uEnv_usb_otg.txt file sounds good as well