[FIXED] Speed Editor won't update (after 18.0.2) but still works

[fat-tire]

18.0.2 told me there was a version update. I tried to update via:

sudo ./opt/resolve/DaVinci\ Control\ Panels\ Setup/DaVinci\ Control\ Panels\ Setup

It started to work..

But then didn't:

The log said:

DFU Upgrade: Getting device info.
DFU Upgrade: Waiting for initial arrival.
DFU Upgrade: Current boot mode  0
DFU Upgrade: Detaching....
DFU Upgrade: Update started.
DFU Upgrade: Payload download complete, waiting for OS arrival.
DFU Upgrade: Current boot mode  0
DFU Upgrade: Current boot mode  255
DFU Upgrade failure:  Failed to get DFU interface after download

Now when I run it and try to update I get the "Failed" dialog and this:

DFU Upgrade: Getting device info.
DFU Upgrade: Waiting for initial arrival.
DFU Upgrade: Current boot mode  255
DFU Upgrade failure:  Failed to get DFU interface before detach

The speed editor appears to still work, and I no longer get notices that there is an update. So did it update? I have no idea, but if anyone does, let me know.

(I don't have an other OS like Mac/Windows to see if there is an error w/them..)

[cowmix]

I had this problem with similar debug output a few months ago when trying to get Resolve working within Docker on Pop_OS 22.04. In my specific case, Resolve would not let me use the device until the upgrade was completed so I eventually gave up on getting the update to work via the container. Instead I updated the firmware via two methods (I have two Speed Editors):

a) Under MacOS
b) I installed Resolve using the dpkg creator script.

After I updated the firmware, the Speed Editor functioned perfectly through the container.

[fat-tire]

I should be clear that the keyboard IS working even though it gets that weird error when updating.

From watching a few teardown videos, it seems that the SE is built around a Silicon Labs BGM113 (spec sheet) that apparently uses Device Firmware Update mode (hence DFU), see page 38 here for details:

1. Boot device to DFU mode with DFU reset command
2. Wait for DFU boot event
3. Send command Flash Set Address to start the firmware update
4. Upload the firmware with Flash Upload commands until all data is uploaded
5. Send when all data is uploaded
6. Finalize DFU firmware update with Reset command.
DFU mode is using UART baudrate from hardware configuration of firmware. Default baudrate 115200 is used if firmware is missing or firmware content does not match the CRC checksum.

UART = the serial protocol used (via USB in linux), and the sequence described above seems to match the process from that mini-log, but perhaps for whatever reason it's unable to boot into DFU mode? Or maybe it DID work, but it got stuck on step 6, the reset command... not sure.

Error codes are listed in section 2.16, but aside from "failed to get DFU interface after download" and "current boot mode 255" (instead of 0, which usually means the correct result), not sure what the probelm is.

If as you say it works under linux w/o the container, it's probably SOME missing permission required for doing this type of firmware update.. but what is it I wonder...

[fat-tire]

I think I may have found the fix.

I wanted to use strace to see if I can figure out exactly where it's failing and what it's trying to do. strace wasn't working off the bat, so I added --privileged to the resolve.sh script in the run section at the bottom. But strace still didn't work.

Then I read you should try adding --cap-add=SYS_PTRACE instead, which can't be used at the same time as --privileged, so i swapped 'em.

After adding --cap-add=SYS_PTRACE, now I could do:

./resolve.sh /bin/bash
[bunch of stuff]
sudo dnf install strace -y
[bunch of stuff]
strace ./opt/resolve/DaVinci\ Control\ Panels\ Setup/DaVinci\ Control\ Panels\ Setup
[stuff scrolls past]

And I noticed that THIS time-- it doesn't even ask to update the keyboard!

Instead I saw this:

What?!! No error? Clicking the version number brings up more build info: Version 1.4.2, Build 612a7747

Cool! So I try it again, this time WITHOUT strace:

 $ ./opt/resolve/DaVinci\ Control\ Panels\ Setup/DaVinci\ Control\ Panels\ Setup

And.. it comes up fine! I didn't try doing a factory reset of the keyboard, but at least everything seems to be correct now (?)

Could someone confirm that adding --cap-add=SYS_PTRACE fixes this issue? And if so, is this something we want to add in?

(I should add this is on the 8.0.3 release that came out an hour or so ago, not that I think it matters)

[fat-tire]

A few updates:

Once the issue was "fixed", I could remove --cap-add=SYS_PTRACE and still don't get the error. So I don't know if it fixes something on the speed editor or what, but now everything works even without it.

I can't figure out what's so special about ptrace that would fix something like this, so I had a look at this discussion. I'm using podman, but I was interested in this:

The upshot seems to be that --cap-add doesn’t do exactly what it says it does in the man page, it’s more like --cap-add-and-also-whitelist-some-extra-system-calls-if-required. Which makes sense! If you have a capability like CAP_SYS_PTRACE which is supposed to let you use the process_vm_readv system call but that system call is blocked by a seccomp profile, that’s not going to help you much!

So allowing the process_vm_readv and ptrace system calls when you give the container CAP_SYS_PTRACE seems like a reasonable choice.

Specifically, CAP_SYS_PTRACE on docker enables these syscalls:

• "kcmp",
• "process_vm_readv",
• "process_vm_writev",
• "ptrace"

On podman, it seems to work slightly differently, enabling:

• "kcmp",
• "process_madvise",

Both of these have to do with accessing info about another process. Note the ptrace syscall itself isn't included in podman's implementation, nor is process_vm_readv/writev. Maybe it's not needed in a rootless container..?

So what does this all tell us about why CAP_SYS_PTRACE seems to fix this issue? Not much. I'm inclined to leave this issue open and hope someone who has the speed editor firmware update issue might chine in on whether CAP_SYS_PTRACE fixed it for them as well (on either docker or podman). It is fully updated and working on my set up, so I can't really play with it until the next time there's a firmware update.

Incidentally, I just tried a "factory reset" operation from the Control Panel without CAP_SYS_PTRACE included and it seems to have worked without incident.

[fat-tire]

Update:

So, with DaVinci Resolve 18.1.2--- It seemed to do the update, slowly flashed the SE, but then got the "Update Failed!" even with --cap-add=SYS_PTRACE on.

bash-5.1$ ./DaVinci\ Control\ Panels\ Setup 
QStandardPaths: wrong ownership on runtime directory /run/user/1000, 0 instead of 1000
*** WARNING *** The program 'DaVinci Control Panels Setup' uses the Apple Bonjour compatibility layer of Avahi.
*** WARNING *** Please fix your application to use the native API of Avahi!
*** WARNING *** For more information see <http://0pointer.de/avahi-compat?s=libdns_sd&e=DaVinci Control Panels Setup>
DFU Upgrade: Getting device info.
DFU Upgrade: Waiting for initial arrival.
DFU Upgrade: Current boot mode  0
DFU Upgrade: Detaching....
DFU Upgrade: Update started.
DFU Upgrade: Payload download complete, waiting for OS arrival.
DFU Upgrade: Current boot mode  0
DFU Upgrade: Current boot mode  255
DFU Upgrade failure:  Failed to get DFU interface after download

Kept offering to re-do the update, but when I quit and restarted the container and ran /opt/resolve/DaVinci\ Control\ Panel\ Setup/DaVinci\ Control\ Panel\ Setup, it seems to have updated to software version 1.4.4 successfully. 🤷

[fat-tire]

This appears to be fixed (?), at least for me, and nothing new since Dec last year, so closing. Re-open if updating the SE again becomes an issue.

[fat-tire]

Update for DVR Release 19, beta 1--

With --cap-add=SYS_PTRACE in resolve.sh it appeared to update fine... but then gave an update failed error. However, after removing this line and restarting, the Control Panel Setup, I see that firmware is indeed set to "Version 1.5" and the speed editor works, so it appears to have updated successfully. 🤷