0
rytm-fw-re
Reverse engineering the Elektron Analog Rytm MKII OS update (OS 1.74) and building a from-source replacement firmware that compiles into a flashable .syx.
- Custom firmware
- Alpha
- Medium brick risk
This project hasn't been claimed by its maintainer yet, so its details come from the community. Is it yours? Claim it
Before you start
- How hard is it?
- HardUses the command line or developer tools.
- What you need
- A USB or MIDI cable
- A computer
- Can it break my device?
- Small chance of trouble, with a way to recover.
- Can I undo it?
- The project doesn't say. Assume you can't.
Get itOpens github.com
Did it work for you?
Did rytm-fw-re work on your Elektron Analog Rytm MKII?
No reports yet.
One-tap reports from owners. Bricked reports are checked before they count.
Compatibility
Devices: Elektron Analog Rytm MKII.
No compatibility information yet.
Getting started
From the project's README ("Flash + upgrade path"):
- The whole upgrade path lives in the bootstrap section (42 KB, runs from SRAM): receive over the MIDI UART, parse the container, verify, write flash, reboot.
- Flash is SPI NOR on the DSPI controller 0xfc05c000 (polled, no DMA), multi-vendor JEDEC: an RDID probe picks page/erase sizes per manufacturer. Erase is 256 KB blocks, program is 512 B units, staged in DDR at 0x3FF80008.
- Flash layout: bootstrap + FPGA at 0x0-0x7FFFF (never written), MAIN OS at 0x80000+ — so writing only above 0x80000 keeps the FUNC+power recovery path intact by construction.
- The opcode-level erase/program helpers are called through absolute pointers whose targets are not those instructions in the file (they resolve into startup-menu code): the real driver is loaded or patched at runtime, most likely from +Drive. A replacement OS does not need it — standard JEDEC commands (WREN/RDSR/RDID/PP/0xD8) are enough.
- Writeup: docs/flash-driver.md; the plan to make the custom OS own USB and retire the DIN dependency: docs/usb-reflash.md.
Risk and recovery
- Brick risk
- Medium
- Requires opening the device
- No
From the project's README ("Boot contract"):
- Bootstrap decompresses MAIN OS to 0x40000400, sets VBR=0x40000000, then jsr to the function pointer stored in image word[0] (C-style, one stack arg). It is NOT a reset SP/PC header.
- Startup menu ([FUNC] at power-on) lives entirely in the bootstrap section: key/encoder/pot/pad tests, empty reset, factory reset, OS upgrade receiver. An OS-only update can never touch it; a bad OS is always recoverable.
- Bootstrap version-checks upgrades and refuses to install an older version.