Does avrdude *have to* run as root in Linux for `-c xplainedmini_updi` (jtag3)?
Closed this issue · 3 comments
The micoUPDI programmer poses as -c xplainedmini_updi programmer. On my Linux I get permission errors when using it, see below. I assume this is the same problem for all programmers derived from jtag3.c : ATMEL ICE, snap, xplained boards etc. I also assume the problem originates in the USB HID mode that jtag3.c uses.
$ avrdude -p atmega4808 -c xplainedmini_updi -t
avrdude error: cannot read serial number: error sending control message: Operation not permitted
avrdude error: cannot read product name: error sending control message: Operation not permitted
avrdude warning: unable to set configuration 1: could not set config 1: Operation not permitted
avrdude error: unable to claim interface 0: could not claim interface 0: Operation not permitted
avrdude error: unable to claim interface 1: could not claim interface 1: Operation not permitted
avrdude error: unable to claim interface 2: could not claim interface 2: Operation not permitted
avrdude warning: no usable interface found
avrdude error: no device found matching VID 0x03eb and PID list: 0x2145
avrdude error: unable to open port usb for programmer xplainedmini_updi
avrdude done. Thank you.
When running avrdude as root things work like a charm:
$ sudo avrdude -p atmega4808 -c xplainedmini_updi -t
avrdude: AVR device initialized and ready to accept instructions
avrdude: device signature = 1E 96 50 (ATmega4808)
avrdude>
I suspect the problem is with the Linux drivers, but no matter which udev rule I enter in my /etc/udev/rules.d/13-xplainedmini I can only use that connection when I make myself root. Here the current contents of that file:
SUBSYSTEM=="usb", ATTRS{idVendor}=="03eb", ATTRS{idProduct}=="2145", MODE="0660", GROUP="plugdev", TAG+="uaccess"
# SUBSYSTEM=="hidraw", ATTRS{idVendor}=="03eb", ATTRS{idProduct}=="2145", MODE="0660", GROUP="plugdev", TAG+="uaccess"
# KERNEL=="hidraw*", ATTRS{idVendor}=="03eb", ATTRS{idProduct}=="2145", MODE="0660", GROUP="plugdev", TAG+="uaccess"
Now I realise this may or may not be an AVRDUDE problem (likely not) but it is not great practice to run avrdude as root and having to change all root ownership of file that avrdude created.
Does anyone have a solution for this?
Ideally, we could take the information from the config file which lists all programmers with their respective USB (VendorID, ProductID) tuple or similar information, and create long udev rules files with one rule each, probably with one TAGS+=uaccess action.
The Debian package has a relatively long list of udev rules which I have adapted for the Fedora package by removing the blanket write access the Debian udev rules file gives to all USB serial and USB ACM devices (https://src.fedoraproject.org/rpms/avrdude/blob/rawhide/f/avrdude.udev with https://src.fedoraproject.org/rpms/avrdude/blob/rawhide/f/avrdude-udev-no-blanket-access.patch)
Maintaining such a rules file manually is possible, but error prone and a lot of work, so it should be autogenerated from the authoritative source.
I once tried my hand at writing a C program to iterate through the list of programmers and their properties using libavrdude, but the iteration code got so weird so quickly that I could see it would take me longer to finish than I had time to spend on it back then.
I also tried writing my own parser for avrdudd.conf in IIRC Python, but that became very complex very quickly as well.
Then other things happened and I forgot.
That would probably be the most comprehensive udev rules file which avrdude could create.
For programmers which present as USB TTYs or USB ACMs, more specific rules with USB VendorId/ProductID tuples or even USB serial numbers are required. And the latter at least are definitively outside of the scope of the avrdude project, or of an avrdude distro package.
I do not know whether avrdude.conf contains USB VendorID/ProductID information at least for programmers which are built together with USB TTY or USB ACM chips and which use a VID/PID tuple specific to that programmer.
Oh, and there might still be special USB operations which an unprivileged (i.e. non-root) user is not allowed to do.
Claiming the interface is certainly one USB operation which rw access to the device allows unprivileged users to do.
Found the solution for the right udev rules. I put the following in /etc/udev/rules.d/80-xplainedmini.rules, then reloaded the rules (on my system that's sudo udevadm control --reload-rules && sudo udevadm trigger), then unplugged the programmer and plugged it in again. Voila!
SUBSYSTEM=="usb", ATTRS{idVendor}=="03eb", ATTRS{idProduct}=="2145", GROUP="plugdev", MODE="0660", TAG+="uaccess"
KERNEL=="hidraw*", SUBSYSTEM=="hidraw", ATTRS{idVendor}=="03eb", ATTRS{idProduct}=="2145", GROUP="plugdev", MODE="0660", TAG+="uaccess"
Ideally, we could take the information from the config file which lists all programmers with their respective USB [...] tuple
@ndim This is such a brilliant idea! Very tempted to take this on board. Avrdude has developer options, so I could imagine that avrdude -c xplainedmini/u outputs the udev rules for this one programmer or avrdude -c \*/u the list of udev rules for all known USB programmers. One difficulty is that AVRDUDE more often than not uses hardcoded vid/pid pairs 😮. These need to be entered into avrdude.conf first.