0
felucca-bsp
A base for custom firmware on M-VAVE synthesizers built around JieLi chips.
- Custom firmware
- Beta
- Low 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?
- EasyWith Slipway.
- What you need
- A computer
- Can it break my device?
- Very unlikely to break anything.
- Can I undo it?
- The project doesn't say. Assume you can't.
Did it work for you?
Did felucca-bsp work on your M-VAVE FM-1?
No reports yet.
One-tap reports from owners. Bricked reports are checked before they count.
Compatibility
Devices: M-VAVE FM-1.
No compatibility information yet.
Getting started
From the project's README ("Layout"):
Path What chip/ Registers, drivers and boot entry shared by the chip family; libc.c (the few routines a freestanding build needs); ota.c (the update session, which takes its hooks from the application); fm1perf.h (cycle and stall counters) and fm1debug.h (register access for development builds) chip/usbhost.c, chip/usbhostdesc.h Opt-in USB MIDI host: direct or one powered hub, MIDI input/output; API and limits chip/usb.c The USB device: MIDI, serial and audio classes (audio in, and with FELUCCAUACOUT audio out) with the EP0 and poll code chip/fm1sys.h, chip/fm1guard.h Supply rails (VDC14 and SYSVDD at M-VAVE's levels), reboot and core reset; hardware guards (stack, write and fetch limits that end in the fault report), the stack floor, whether code runs in an interrupt loader/ The update loader (builds as a RAM image; it includes chip/usb.c, chip/ota.c and chip/libc.c) boards/fm1/ FM-1 wiring and drivers: LCD pins, key scan (with velocity and pressure from the keys, off by default: fm1input.h), ADC channels, audio codec lines docs/EXPERIMENTAL.md Second core, expanded flash, USB host, clock: what is established and what is not docs/CPU.md What the CPU has been seen to do: 64-bit multiplies among 16-bit loads leave a register a bit off; keep them out of line tools/ Package builder (fm1pkg.py), USB-MIDI installer (fm1install.py), fm1rescue and getsdk.sh (JieLi's SDK, fetched and checked by hash) …
Risk and recovery
- Brick risk
- Low
- Requires opening the device
- No
From the project's README ("Layout"):
Path What chip/ Registers, drivers and boot entry shared by the chip family; libc.c (the few routines a freestanding build needs); ota.c (the update session, which takes its hooks from the application); fm1perf.h (cycle and stall counters) and fm1debug.h (register access for development builds) chip/usbhost.c, chip/usbhostdesc.h Opt-in USB MIDI host: direct or one powered hub, MIDI input/output; API and limits chip/usb.c The USB device: MIDI, serial and audio classes (audio in, and with FELUCCAUACOUT audio out) with the EP0 and poll code chip/fm1sys.h, chip/fm1guard.h Supply rails (VDC14 and SYSVDD at M-VAVE's levels), reboot and core reset; hardware guards (stack, write and fetch limits that end in the fault report), the stack floor, whether code runs in an interrupt loader/ The update loader (builds as a RAM image; it includes chip/usb.c, chip/ota.c and chip/libc.c) boards/fm1/ FM-1 wiring and drivers: LCD pins, key scan (with velocity and pressure from the keys, off by default: fm1input.h), ADC channels, audio codec lines docs/EXPERIMENTAL.md Second core, expanded flash, USB host, clock: what is established and what is not docs/CPU.md What the CPU has been seen to do: 64-bit multiplies among 16-bit loads leave a register a bit off; keep them out of line tools/ Package builder (fm1pkg.py), USB-MIDI installer (fm1install.py), fm1rescue and getsdk.sh (JieLi's SDK, fetched and checked by hash) …
Credits, license and support
- License
- MPL-2.0