I know Martin ordered one too, which means I can't be banned for discussing a competing product - https://www.electro-smith.com/daisy
My kickstarter shipment has finally arrived and I've started digging into details of their hardware. My main interest is porting OpenWare to it, but I'm not sure how realistic would that goal be. Daisy board is using an MCU from STM32H7 family and it would take lots of effort to port current firmware. This was expected, but I haven't initially checked specific H750IB MCU datasheet, which creates more difficulties.
While it should perform about 4 times faster (at least according to ST marketing presentations), it belongs to value line of H7 family. So it only has 128k flash on MCU itself. Daisy also has 8MB QSPI flash chip, but we won't be able to write it from firmware like we do for normal flash. We could probably move patch writing code to a version of midi bootloader that it would use, then switch to bootloader for writing patches. Something like this would probably work in linker script:
FLASH (rx) : ORIGIN = 0x8000000, LENGTH = 64K /* Bootloader on flash*/
SETTINGS (rx) : ORIGIN = 0x8010000, LENGTH = 64K /* Writable flash part - should be used for storing settings from firmware */
APPLICATION (rx) : ORIGIN = 0x90000000, LENGTH = 512K /* QSPI flash - firmware part */
STORAGE (rx) : ORIGIN = 0x90080000, LENGTH = 7680K /* QSPI flash - patch storage part. That's one hell of a lot of patches */
So we'll have a bootloader and writable flash section (i.e. for storing settings), plus memory mapped QSPI chip for firmware and patches. Midiboot would be writing firmware (or patches) in indirect write mode to chip, then switching to memory mapped mode and jumping to firmware.
I will spend some time trying to port midiboot here, we'll see if this would lead to something.
The good thing is there's a proper library for hardware access that looks quite usable. Also there's cubeMX project that I'll use as a starting point.