summaryrefslogtreecommitdiff
path: root/posts/2023-09-24-polybrute-fw-update.md
blob: abea07d7de8c1770c4790ff9afabce3d98cf2de9 (about) (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
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.