summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorRicardo Wurmus <rekado@elephly.net>2023-09-24 23:37:07 +0200
committerRicardo Wurmus <rekado@elephly.net>2023-09-24 23:37:07 +0200
commit48206123874223b4c4166542b1be38f64c1d9bd3 (patch)
tree681a8c791395ce0bc11398fe6f4b86b2c7a76a82
parentdfdb70ca28be64f2899932cbd360532f1f520d2f (diff)
Publish polybrute article.
-rw-r--r--posts/2023-09-24-polybrute-fw-update.md106
1 files changed, 106 insertions, 0 deletions
diff --git a/posts/2023-09-24-polybrute-fw-update.md b/posts/2023-09-24-polybrute-fw-update.md
new file mode 100644
index 0000000..abea07d
--- /dev/null
+++ b/posts/2023-09-24-polybrute-fw-update.md
@@ -0,0 +1,106 @@
+title: Upgrading the PolyBrute firmware
+date: 2023-09-24 23:30
+tags: audio, linux, gnu, polybrute, synth, music
+---
+
+The Arturia PolyBrute is a lovely analogue synthesizer. A few days ago Arturia released version 3.0.0 of the firmware, which adds a few more effects, fixes bugs, adds more configuration options, such as duophonic pitch bend, and many more.
+
+The proprietary firmware can only be installed through proprietary
+software, PolyBrute Connect, which only runs on proprietary operating
+systems. Bummer. While I see a way towards a free implementation of PolyBrute Connect for changing synth parameters through software (more on that in the future) I haven't figured out whether there is a way to use only free software to switch the synth to firmware update mode and push the proprietary firmware update. I *do* know a way, however, to do this without having to install a proprietary operating system on hardware.
+
+The idea is very dumb but effective: download a gratis copy of a virtual machine with Windows, convert it to use it with Qemu, and launch it with arguments to pass the host system's USB host bus to Windows. This lets PolyBrute Connect see the device, switch device modes, and push the firmware update.
+
+# Preparing Windows
+
+Create a disk. We'll install Windows to this disk.
+
+```shell
+qemu-img create -f qcow2 WindowsVM.img 25G
+```
+
+[Fetch the installation
+ISO](https://www.microsoft.com/en-gb/software-download/windows10) and
+the [virtio driver
+disk]((https://fedorapeople.org/groups/virt/virtio-win/direct-downloads/archive-virtio/virtio-win-0.1.240-1/))
+`virtio-win.iso` for paravirtualization.
+
+Then boot the VM from the installation ISO, adding the virtio ISO as
+an extra drive, and using the disk image as the target file system.
+
+```shell
+qemu-system-x86_64 -enable-kvm \
+ -cpu host \
+ -drive file=WindowsVM.img,if=virtio \
+ -net nic -net user,hostname=windowsvm \
+ -monitor stdio -name "Windows" \
+ -m 2048 \
+ -cdrom ~/Downloads/Win10_22H2_EnglishInternational_x64.iso \
+ -drive file=./virtio-win.iso,media=cdrom \
+```
+
+Once Windows has been installed take a shower to satisfy the urge to wash off that stench of proprietary software. Just note that you cannot scrub off the rot, the feeling that you've been made to do something that you didn't want and that you don't approve of. Remember this feeling, pour a bit of it into a bottle, and add it to your diet every once in a while to remind yourself to join the efforts towards freedom-respecting software.
+
+You can now install PolyBrute Connect and activate it --- that's
+necessary because for some reason you are not permitted to use the
+software on more than five different machines at the same time. Silly
+proprietary software. You will not be able to see a connected PolyBrute synthesizer, though. For that you'll need to pass through the USB device or better: the whole bus.
+
+# Launch Windows and pass through USB
+
+This is the Qemu command I use to launch the Windows VM with 4GB of RAM, a virtual USB controller (xhci), and passing through bus 3, port 3 to the VM:
+
+```shell
+qemu-system-x86_64 -enable-kvm \
+ -cpu host,hv-vpindex,hv_stimer,hv_synic,hv_time,hv_relaxed \
+ -machine q35,usb=on,accel=kvm \
+ -device qemu-xhci,id=xhci \
+ -device usb-host,bus=xhci.0,hostbus=3,hostport=3,guest-reset=true,guest-resets-all=true \
+ -drive file=WindowsVM.img,cache=writeback,if=virtio \
+ -net nic -net user,hostname=windowsvm \
+ -monitor stdio \
+ -name "Windows" \
+ -m 4096 -smp 4 \
+ -drive file=~/Downloads/Win10_22H2_EnglishInternational_x64.iso,media=cdrom \
+ -device usb-tablet \
+ -vnc :1
+```
+
+I use `-vnc :1` so that I can connect to `:1` with a VNC viewer like [Remmina](https://remmina.org/). The option `-device usb-tablet` is needed to ensure that the virtual mouse pointer actually lines up with my actual mouse pointer.
+
+`-monitor stdio` exposes the Qemu command line to the terminal, making it convenient to attach or detach devices with commands. The `-cpu` line looks complicated and it's just an attempt to speed the Windows guest up somewhat. The same goes for the `-machine` line.
+
+The important bits are the USB configuration. `-device
+qemu-xhci,id=xhci` adds a capable USB controller in the guest and
+names it `xhci`. The line starting with `-device usb-host` references
+it with the `bus=xhci.0` option. Here I opted for exposing USB bus 3
+and port 3 to the guest. Which bus/port you pass through depends on thee bus/port on which the PolyBrute synthesizer is connected. You can check this with `lsusb` on your GNU+Linux host. I also granted permissions to the guest to reset any device on that
+bus/port combination as often as it wants.
+
+These settings enable the Windows guest and thus the PolyBrute Connect
+software to see the PolyBrute synthesizer, switch its mode to firmware
+upgrade mode, see the new USB firmware upgrade device that appears in
+place of the PolyBrute USBMIDI device, and reset the device after the firmware upgrade. You should be able to upgrade the PolyBrute firmware to 3.0.0 with these settings.
+
+For my reverse engineering experiments I use a different command. It is sufficient to expose just the PolyBrute USBMIDI device to the virtual machine. To do that I replace the `-device usb-host,...` option above with this option:
+
+```shell
+-device usb-host,bus=xhci.0,vendorid=0x1c75,productid=0x0406,id=synth
+```
+
+The vendor id is that of Arturia, and the product id is reserved for the PolyBrute.
+
+
+# Meh.
+
+Yeah, it's not great. I haven't looked into it yet, but there's probably a native way to push the firmware file to the USB device. I'll post an update if ever I feel the urge to risk bricking my expensive synthesizer.
+
+Replacing PolyBrute Connect for managing patches and editing sounds, on the other hand, is not as difficult. It's pretty obvious how to do it, because all communication is just MIDI (and MIDI sysex) over USB. I wasted a lot of time analyzing the USB traffic with wireshark before I realized that it's all run of the mill MIDI over USB. The PolyBrute sends and receives so-called [NRPN](https://en.wikipedia.org/wiki/NRPN) messages. NRPN stands for non-registered parameter numbers and it's pretty much custom CC messages.
+
+I wasted even more time trying to record all of these NRPNs and value
+ranges before I realized that PolyBrute Connect installs XML files
+describing all parameters, their ranges, their NRPNs, and their mappings. You'll find these files in `C:\ProgramData\Arturia\PolyBrute Connect\resources\`.
+
+If Arturia could grant permission to these XML files (and perhaps even
+the GUI assets) under a free license I'd be happy to build a free
+implementation of PolyBrute Connect for GNU+Linux users.