diff --git a/tests/gadget-zero/70-libopencm3.rules b/tests/gadget-zero/70-libopencm3.rules
new file mode 100644
index 00000000..964971c5
--- /dev/null
+++ b/tests/gadget-zero/70-libopencm3.rules
@@ -0,0 +1,6 @@
+# Put this in /etc/udev/rules.d/70-libopencm3.rules
+# then do "sudo udevadm control --reload" and unplug/replug the usb device.
+# This grants user accesss to the "cafe" USB Vendor ID used/hijacked/squatted by the test gadget
+
+# libopencm hacking
+SUBSYSTEMS=="usb", ATTRS{idVendor}=="cafe", TAG+="uaccess"
diff --git a/tests/gadget-zero/README.md b/tests/gadget-zero/README.md
index de30b242..564056e3 100644
--- a/tests/gadget-zero/README.md
+++ b/tests/gadget-zero/README.md
@@ -8,23 +8,42 @@ should be built for multiple devices.
 
 ## Requirements:
  * [pyusb](https://walac.github.io/pyusb/) for running the tests. 
- * [openocd](http://openocd.org/) >= 0.9 for automated flashing of specific boards
+ * [OpenOCD](http://openocd.org/) >= 0.9 for automated flashing of specific boards
  * python3 for running the tests at the command line.
+
+### Building the device firmware
+There are Makefile.xxxxx files for all the currently tested targets.
+```
+make -f Makefile.stm32f4disco clean all V=1
+```
+The ```V=1``` is optional, and turns on verbose mode, which can be useful if
+things don't work. This will give you a .elf file you can program using your
+own toolchain, but if you have a functional OpenOCD installed, then...
+```
+make -f Makefile.stm32f4disco clean all flash
+```
+Will handle flashing as well.
  
-### Example using virtual environments
+### Setting up the test runner (using python virtual environments)
 ```
 pyvenv .env  # ensures a python3 virtual env
 . .env/bin/activate
 pip install pyusb
 ```
 
-You _will_ need to modify the openocd config files, as they contain specific
-serial numbers of programming hardware. You should set these up for the set of
-available boards at your disposal.
+If you have multiple test boards connected, have a look at opencd.common.cfg
+for some tips on selectively matching the right board.  For people with just
+a single matching board, you don't need to do anything.
 
 Tests marked as @unittest.skip are either for functionality that is known to be
 broken, and are awaiting code fixes, or are long running performance tests
 
+### Access rights
+On some systems (most linux systems) you probably won't have access to the
+usb vendor id being used/hijacked by the test cases.  See 70-libopencm3.rules
+for installation instructions, or, if you have your own system, grant yourself
+access to the usb vid: 0xcafe
+
 ## Running the tests
 Below is an example of running the full suite of tests from the command line.
 The argument specifies the serial number to look for in the usb gadget, if