Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

iio_attr -a mode fails on PlutoSDR #925

Closed
tfcollins opened this issue Jan 11, 2023 · 10 comments
Closed

iio_attr -a mode fails on PlutoSDR #925

tfcollins opened this issue Jan 11, 2023 · 10 comments

Comments

@tfcollins
Copy link
Contributor

Welcome to:
______ _       _        _________________
| ___ \ |     | |      /  ___|  _  \ ___ \
| |_/ / |_   _| |_ ___ \ `--.| | | | |_/ /
|  __/| | | | | __/ _ \ `--. \ | | |    /
| |   | | |_| | || (_) /\__/ / |/ /| |\ \
\_|   |_|\__,_|\__\___/\____/|___/ \_| \_|

v0.34-3-g401e-dirty
https://wiki.analog.com/university/tools/pluto
# iio_attr -a -d
Scanning for IIO contexts failed: Input/output error (5)

I guess its missing some discovery/scanning packages?

@pcercuei
Copy link
Contributor

It shouldn't need any. Could you try to see where the -EIO error is returned from?

@tfcollins
Copy link
Contributor Author

Ok. Let me get my cross-compiling setup going

@rgetz
Copy link
Contributor

rgetz commented Feb 3, 2023

Pluto doesn't ship with avahi client on it. This failure is expected.

I don't think -a (which does a scan, and attaches to the first device) tries local. That's a feature enhancement.

-Robin

@pcercuei
Copy link
Contributor

pcercuei commented Feb 3, 2023

@rgetz In that case I would expect it to fail, but not with a -EIO code.

@rgetz
Copy link
Contributor

rgetz commented Feb 3, 2023

I was wrong - it should try local...

LIBIIO_SCAN_BACKENDS should have local defined when compiled with WITH_LOCAL_BACKEND

a scan returns the same.

# iio_info -s
Library version: 0.23 (git tag: v0.23)
Compiled with backends: local xml ip usb serial
Scanning for IIO contexts failed: Input/output error (5)

so - scans fail on local for some reason.

from a host:

C:\Users\rgetz>iio_info -s
Library version: 0.24 (git tag: c4498c2)
Compiled with backends: xml ip usb serial
Unable to create Local IIO context : Function not implemented (40)
Available contexts:
        0: 192.168.2.1 (Analog Devices PlutoSDR Rev.B (Z7010-AD9364)), serial=1044735411960002e7ff210031f11e3d48 [ip:pluto.local]
        1: 0456:b673 (Analog Devices Inc. PlutoSDR (ADALM-PLUTO)), serial=1044735411960002e7ff210031f11e3d48 [usb:3.1.5]
C:\Users\rgetz>

I can try on a ARM target later (using Kuiper).

-Robin

@rgetz
Copy link
Contributor

rgetz commented Feb 10, 2023

Works on ARM (Kuiper), and provides local context.

analog@analog:~ $ lsb_release -a
No LSB modules are available.
Distributor ID:	Raspbian
Description:	Kuiper GNU/Linux 10 (buster)
Release:	10
Codename:	buster
analog@analog:~ $ uname -a
Linux analog 4.19.0-g82d2f24 #140 SMP PREEMPT Fri Nov 13 16:21:44 GMT 2020 armv7l GNU/Linux
analog@analog:~ $ iio_info -s
Library version: 0.23 (git tag: 60de6b9)
Compiled with backends: local xml ip usb
Available contexts:
	0: 192.168.1.120 (AD-FMCOMMS2-EBZ on Xilinx Zynq ZED), serial=00100 [ip:analog.local]
	1: 2601:190:400:da:47b3:55ab:3914:bff1 (AD-FMCOMMS2-EBZ on Xilinx Zynq ZED), serial=00100 [ip:analog.local]
	2: (adf4351-udc-tx-pmod, ad9361-phy, cf-ad9361-lpc, adf4351-udc-rx-pmod, xadc, ad7291, cf-ad9361-dds-core-lpc on Xilinx Zynq ZED) [local:]

so this is likely a uClibc issue...
so - updating my pluto source/build to the latest release, and updating Vivado...

@rgetz
Copy link
Contributor

rgetz commented Feb 20, 2023

Ok - not a uClibc issue, just a couple stacked libiio issues...

two issues:

  • continuation of scan failure on one backend causes failures on all #559 - if one backend fails, they all do. This is because of the way error handling is done in scan.c:iio_scan_context_get_info_list() https://github.com/analogdevicesinc/libiio/blob/master/scan.c#L57-L58 if any backend errors, they all error, and return the error code of the one that failed, even if the others worked.
  • On Pluto (or any time that libUSB is complied in, and it's set up as a backend), but not enabled/turned on in the device (ie - when OTG is in device mode), usb.c:usb_context_scan() calls libusb_init(), which returns LIBUSB_ERROR_OTHER; which in turns gets translated to EIO in libusb_to_errno()

So, libUSB is installed, the USB backend is turned on, usb scanning is turned on, but usb scans fail when in device mode.
When in host mode - things work fine. (nothing is found, but it doesn't error, so the first issue with the scan error code issue doesn't get triggered and everything is Ok).

I'm not sure on the "fix":

  • Claim it's a Pluto problem (WITH_USB_BACKEND should be off) and do nothing. (which I don't think helps, since you can plug a PlutoSDR into a different PlutoSDR.)
  • don't return an error code with errors in usb.c:usb_context_scan() calls libusb_init() fails, just zero. This is problematic - since you don't really know why it's failing. (for linux host, check if /dev/bus/usb/ is not there - which is what libusb is doing) see discussion at : libusb_init() fails with Other error [-99] if in chroot and --disable-udev libusb/libusb#595
  • only return error codes from scan.c:iio_scan_context_get_info_list() if all backends fail. This could mask some things, but might make it easier for default users.

-Robin

rgetz added a commit to rgetz/libiio that referenced this issue Feb 20, 2023
libiio scans via libusb when the usb backend is built in. For many
embedded linux targets that support On The Go (OTG) the USB port can be
configured as device or host. Sometimes, end users may want to scan for
local devices when the OTG is configured as a device (and there aren't
any USB hosts).

The issue with this is libusb returns an error when there are not any
hosts. So - on linux - catch that, and override the error handling.

New functionality is when Linux's OTG USB is in device mode, usb scans
can still take place.

This fixes issue analogdevicesinc#925 (iio_attr -a fails on plutoSDR).

Signed-off-by: Robin Getz <[email protected]>
@rgetz
Copy link
Contributor

rgetz commented Feb 20, 2023

The PR does the 2nd (don't return an error code), and leaves the backends alone for now.

@tfcollins - I don't know if you want to verify on your side?, but it fails for me before, and works now:

# iio_attr -a -d
Multiple contexts found. Please select one using --uri:
        0: 192.168.2.1 (Analog Devices PlutoSDR Rev.C (Z7010-AD9361)), serial=10447376de0b000213002900fafa9908ec [ip:pluto.local]
        1: (cf-ad9361-lpc, xadc, cf-ad9361-dds-core-lpc, ad9361-phy on Analog Devices PlutoSDR Rev.C (Z7010/AD9363)) [local:]

rgetz added a commit to rgetz/libiio that referenced this issue Feb 22, 2023
libiio scans via libusb when the usb backend is built in. For many
embedded linux targets that support On The Go (OTG) the USB port can be
configured as device or host. Sometimes, end users may want to scan for
local devices when the OTG is configured as a device (and there aren't
any USB hosts).

The issue with this is libusb returns an error when there are not any
hosts. So - on linux - catch that, and override the error handling.

New functionality is when Linux's OTG USB is in device mode, usb scans
can still take place.

This fixes issue analogdevicesinc#925 (iio_attr -a fails on plutoSDR).

Signed-off-by: Robin Getz <[email protected]>
pcercuei pushed a commit that referenced this issue Feb 22, 2023
libiio scans via libusb when the usb backend is built in. For many
embedded linux targets that support On The Go (OTG) the USB port can be
configured as device or host. Sometimes, end users may want to scan for
local devices when the OTG is configured as a device (and there aren't
any USB hosts).

The issue with this is libusb returns an error when there are not any
hosts. So - on linux - catch that, and override the error handling.

New functionality is when Linux's OTG USB is in device mode, usb scans
can still take place.

This fixes issue #925 (iio_attr -a fails on plutoSDR).

Signed-off-by: Robin Getz <[email protected]>
@rgetz
Copy link
Contributor

rgetz commented Feb 22, 2023

I think this can be closed now.

@pcercuei
Copy link
Contributor

Fixed by #939 I assume?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants