ChanServ changed the topic of #rust-embedded to: Welcome to the Rust Embedded IRC channel! Bridged to #rust-embedded:matrix.org and logged at https://libera.irclog.whitequark.org/rust-embedded, code of conduct at https://www.rust-lang.org/conduct.html
IlPalazzo-ojiisa has quit [Quit: Leaving.]
zxrom has left #rust-embedded [Leaving]
bpye has quit [Ping timeout: 240 seconds]
bpye has joined #rust-embedded
dc740 has joined #rust-embedded
emerent has quit [Ping timeout: 240 seconds]
emerent has joined #rust-embedded
dc740 has quit [Remote host closed the connection]
dc740 has joined #rust-embedded
cr1901 has quit [Remote host closed the connection]
cr1901 has joined #rust-embedded
cr1901 has quit [Remote host closed the connection]
cr1901 has joined #rust-embedded
dc740 has quit [Remote host closed the connection]
IlPalazzo-ojiisa has joined #rust-embedded
<re_irc> <@arnoldanderson:matrix.org> Hello there! Guys, can you help me, please, with the udev rule to give group of users the ownership on the device and all the permissions for all other users?
<re_irc> I tried to create the udev rule for Micro:bit V1 controller to code for it, but rule doesn't work, I checked it out on two different machines, the same result on both (Gentoo machine and the second is Fedora)
<re_irc> Logs are empty, no errors at all. Checked logs with the following command: "sudo journalctl -u systemd-udevd --since "5 minutes ago""
<re_irc> There is some info about what is going on on my machine now:
<re_irc> [anderson@rpi4]~% ls -l /dev/hidraw*
<re_irc> Prove that there is no permissions over the device:
<re_irc> crw-------. 1 root root 234, 0 Jun 3 10:23 /dev/hidraw0
<re_irc> Udev rule that I tried
<re_irc> [anderson@rpi4]~% cat /etc/udev/rules.d/99-microbit.rules
<re_irc> # CMSIS-DAP for microbit
<re_irc> SUBSYSTEM=="usb", ATTR{idVendor}=="0d28", ATTR{idProduct}=="0204", GROUP="plugdev", MODE="666"
<re_irc> Yes, I'm in group plugdev
<re_irc> [anderson@rpi4]~% groups
<re_irc> anderson wheel video docker plugdev
<re_irc> Yes, there is no permissions on exactly that device:
<re_irc> [anderson@rpi4]~% lsusb | grep -i "NXP ARM mbed"
<re_irc> Bus 001 Device 004: ID 0d28:0204 NXP ARM mbed
<re_irc> [anderson@rpi4]~% udevadm info /dev/hidraw0
<re_irc> P: /devices/platform/scb/fd500000.pcie/pci0000:00/0000:00:00.0/0000:01:00.0/usb1/1-1/1-1.1/1-1.1:1.3/0003:0D28:0204.0002/hidraw/hidraw0
<re_irc> Yes, user from the group has permissions to read that rule
<re_irc> [anderson@rpi4]~% ls -l /etc/udev/rules.d/99-microbit.rules
<re_irc> -rw-r--r--. 1 anderson root 120 Jun 3 10:20 /etc/udev/rules.d/99-microbit.rules
<re_irc> Yes, I've reloaded udev rules, at least twice, and even rebooted the machine
<re_irc> There is guide for rust that I'm partially following to https://docs.rust-embedded.org/discovery/microbit/03-setup/linux.html
<re_irc> There is no help in linux chats, so I decided to go in Rust chat, sorry for kind of offtop
<re_irc> <@TimSmall:matrix.org> If you're using a systemd based distro, then you could "systemctl edit systemd-udevd.service" and change "ExecStart=" to add the debug ("-D") flag to udev.
<re_irc> <@TimSmall:matrix.org> (or rather add it to the commandline args for "systemd-udevd").
<re_irc> <@TimSmall:matrix.org> 4nd3rs0n: ^
<re_irc> <@TimSmall:matrix.org> BTW, the rules file shouldn't need to have any special ownership or perms - root ownership is fine.
<re_irc> <@arnoldanderson:matrix.org> Thank you a lot!
<re_irc> <@arnoldanderson:matrix.org> Useful information
<re_irc> <@tiwalun:matrix.org> 4nd3rs0n: Maybe the subsystem is wrong? The rule specifies usb, but it seems to be in the hidraw subsystem.
<re_irc> <@adamgreig:matrix.org> Have you unplugged and replugged the device after reloading the udev rules?
<re_irc> <@adamgreig:matrix.org> Also for hid devices I didn't think you needed permissions set, it goes through the kernel hid stuff
<re_irc> <@adamgreig:matrix.org> Could you run probe-rs with trace logs and upload them somewhere?
dc740 has joined #rust-embedded
dc740 has quit [Remote host closed the connection]
<re_irc> <@sparky:matrix.possumlodge.me> when flashing an esp32c3, does this app/part size % indicate how full the onboard flash is?
<re_irc> Finished release [optimized] target(s) in 0.56s
<re_irc> Crystal frequency: 40MHz
<re_irc> Flash size: 4MB
<re_irc> Chip type: ESP32-C3 (revision 4)
<re_irc> Features: WiFi
<re_irc> MAC address: 64:e8:33:db:e7:60
<re_irc> App/part. size: 846080/1048576 bytes, 80.69%
<re_irc> [00:00:00] ######################################## 12/12 segment 0x0 [00:00:00] ######################################## 1/1 segment 0x8000 [00:00:08]...
<re_irc> ... ######################################## 487/487 segment 0x10000
<re_irc> cause 80% full with 4MB just for using wifi to setup a ping is pretty intense imo...
<re_irc> <@9names:matrix.org> i think mine is being caught by jlink's udev rules, which look like this:
<re_irc> KERNEL=="hidraw*", ATTRS{idProduct}=="0204", ATTRS{idVendor}=="0d28", MODE="666"
<re_irc> <@9names:matrix.org> ^ @4nd3rs0n
<re_irc> <@9names:matrix.org> * 4nd3rs0n
<re_irc> <@9names:matrix.org> looks like mine is also being handled by openocd and probe.rs blanket rules file, since iProduct contains the string "CMSIS-DAP".
<re_irc> if you don't have openocd installed, try adding the probe-rs' udev rules (https://probe.rs/docs/getting-started/probe-setup/)