Aux-opsy / Stoatworks Labs

Platform index / Digital mixing console

Allen & Heath Qu-5 / Qu-6 / Qu-7

The 2nd-generation Qu is SQ silicon in a Qu suit, and not by analogy — it is the same Zynq part, running a mix bitstream of the same size, with the SQ's boot BSP and the Avantis's FX subsystem.

DocumentedIntroduced 2024Qu 2nd-gen — SQ platform lineageZynq PS + discrete FPGABare metalSQ-derivedFDSP FX V2No signing

Hardware in our hands: none — every finding below came out of a file. · Last updated

The load-bearing finding. The 65 MB Qu-7 update is one unencrypted Xilinx boot image carrying six PL bitstreams, and the one that mixes is for an XC7Z020 — the SQ-5's exact part, at 6,503 configured frames against the SQ's 6,021. "SQ silicon in a Qu suit" started as a read of shared strings; the bitstreams state it outright.

Verdict. The second-generation Qu is not a descendant of the 2014 Qu-16/24/32 — it is the SQ platform in a cheaper suit: the same bare-metal Zynq, the same PS-driver BSP, the same FDSP FX V2 as the Avantis. Anything already learned from the SQ's platform carries straight over; the classic Qu is the genuinely separate, still-undocumented target.

Method

Static analysis of the Qu-7 V1.1.3 (r3931) update .bin and the bundled Qu-5/6/7 update-instructions PDF. No hardware inspected; no bitstream disassembled. The classic Qu-16/24/32 is a separate earlier platform and is not covered.

Artifacts examined

  • Qu-7UPG_1_1_3_r3931.bin — 65 MB, a single Xilinx Zynq boot image (XLNX header, encryption status 0)
  • Qu567_FirmwareUpdateInstructions.pdf — names the generation: Qu-5/5D, Qu-6/6D, Qu-7/7D; update via Qu-MixPad or a FAT32 USB drive in the Qu-A port
  • QUDante16.q16 — the Qu Dante-16 option-card image (Audinate module), 28 MB; not analysed here

No manufacturer firmware, binaries or documentation are redistributed here. Artifacts are referenced by name and version only. See the method and legal statement for the basis on which this analysis was performed and the boundaries it observes.

Hardware architecture

ItemFindingConfidence
SoC / bootA Xilinx Zynq PS (ARM) — boot header AA995566/XLNX with encryption status 0, Xilinx First Stage Boot Loader, PS7 initialization successful, and the Zynq PS-driver BSP (xemacps, xscugic, xdevcfg, xqspips, xiicps, xttcps, xuartps, lwIP 2.0.3 xilinx_modified) — the identical BSP to the SQVerified
Audio / FX fabricBoth the Zynq PL and discrete fabric — this page recorded "no Zynq PL" until 2026-08-14 and that was wrong. Three of the image's bitstreams state their target device outright: the Zynq's own PL is XC7Z020 (0x03727093, at file offset 0x1730, 6,503 configured frames), a second XC7Z010 (0x03722093) is the FX Zynq, and one discrete XC7A15T (0x0362E093) is the remote-I/O device image. The Zynq PL was read as empty because its bitstream is byte-reversed per 32-bit word for the PCAP boot path, so a normal-order search for the sync word cannot see itVerified
FX subsystemA dual-core FDSP FX V2 (FDSPFxV2SystemCore0/1, Both FX Zynqs booted) — the same FX subsystem as the Avantis, down to identical Bitstream CRC: 0x8948 / 0xE489Verified
PS coresAMP across the two PS cores, not SMP (CPU1: clearing flag for CPU0, a START_SYNC shared region, Handoff Address (Core0/1)) — the SQ's AMP modelVerified
StorageQSPI NOR boot (Boot mode is QSPI, xqspips) plus eMMC for scenes and libraries (… EMMC ERROR); USB recording under /AH_QU/USBRecVerified
SurfaceMotor-fader MCUs flashed from the host (Expected Fader Version %u.%u, updating…)Verified

Software architecture

ItemFindingConfidence
Operating systemNone — a bare-metal Xilinx standalone BSP (FSBL + AMP), with no Linux, FreeRTOS or ThreadX strings. The SQ's model, not the Avantis's x86 LinuxVerified
This buildQu-7 firmware V1.1.3 (r3931); the image also carries This Qu is running pre-production firmware and Silicon Version 3.1Verified
Update toolingApplied over the Qu-MixPad app (iOS/Android/Windows/Mac) or a FAT32 USB stick in the Qu-A port, per the bundled Qu-5/6/7 instructionsVerified

Update path & security model

ItemFindingConfidence
Boot imageUnencrypted and analysable — boot-header encryption status 0x00000000; the FSBL knows about eFUSE security (EFUSE_SEC_EN bit is set, Encryption is mandatory) but that bit is not set on this image. The SQ's postureVerified
Update validationCRC/checksum only, no signature: Error, invalid image Checksum, PARTITION_CHECKSUM_FAIL, Partition DataChecksum 0x%0x != 0x%0x, File failed CRC check. No signing primitive in the update path — the AES strings are audio channelsVerified
Add-on entitlementA paid add-on system exists; its mechanism is out of scope and was not analysed — see the methodology pageVerified

These rows describe how a platform validates a firmware image, because that is a structural fact about its architecture. They are not a vulnerability disclosure and no exploit, bypass or circumvention technique is published here. Licensing and entitlement mechanisms are out of scope throughout — seescope boundaries.

What is programmable

  1. 1Interoperability, not rehosting

    The Qu speaks published MIDI/TCP control and the Qu-MixPad protocol, and takes dSNAKE/gigaACE/Dante/Waves I/O. Almost everything that motivates looking at the firmware is better served here.

  2. 2The Zynq ↔ FPGA interface

    As on the SQ, the audio engine sits in fabric behind the Zynq; mapping that boundary turns it into commandable hardware. Because the platform is shared, this is largely the same work as the SQ's undocumented AXI/config interface.

  3. 3The FPGA bitstreams

    Unencrypted 7-series and analysable in principle (Project X-Ray covers Artix-7), but a very large project and downstream of the interface. Not step one.

Traps

Mistakes this analysis actually made, or came close to making. They are recorded because each one produces a plausible-looking wrong answer rather than an obvious failure.

  • The 2nd-gen Qu (Qu-5/6/7) and the classic Qu-16/24/32 share a name and, on this evidence, nothing else — do not carry a finding from this image back to a 2014 Qu.
  • Concluding "no Zynq PL" from the absence of a Zynq IDCODE — this page did exactly that and was wrong for a week. A bitstream destined for the PCAP boot port is stored byte-reversed per 32-bit word, so it carries 66 55 99 AA where the documentation says AA 99 55 66. Searching one byte order finds the discrete Artix image, misses the Zynq one, and hands you a clean, confident, inverted answer: the fabric that was recorded as absent is the one doing the mixing. Search both orders, and treat "the IDCODE is missing" as a claim needing evidence rather than a finding.
  • The AES strings are AES3 audio channels and EFUSE_SEC_EN is an FSBL capability check — neither is evidence of a signed or encrypted image. The boot-header encryption status (0) is the authority.

Open questions

  • The classic Qu-16/24/32/Pac/SB (2014) is a separate, earlier platform — NXP Cortex-M + Blackfin + FPGA, bare-metal, no add-ons — documented in its own entry; the two Qu generations share only the brand.
  • Which of the six bitstreams is which. Three state a device (XC7Z020, XC7Z010, XC7A15T); the remaining three were not attributed to a board, and no bitstream was disassembled — so "the XC7Z020 image is the mixer" rests on its size and on the SQ parallel, not on anything read out of the fabric.
  • The Qu Dante-16 option card (QUDante16.q16, an Audinate module image) was not analysed.

Status of this entry. A written teardown exists and its claims carry evidence citations. Nothing on this page has been verified against physical hardware — no unit of this platform has been opened, connected to or modified.

← Back to the platform index