M+ computer internals + info

Do you know that NI uses files with the .deb extension to install? For example - (ni-raum_Installer.deb).
I managed to catch a few on the SD card. When unpacking there
ni-raum_Installer.deb\data.tar.\usr\lib\vst\raum .so

Interesting indeed. It seems as if some updates, I'm guessing baseline revisions are released as .nu files which are encrypted and signed, but also like you mentioned, dpkg seems to be used as well to install standard and NI specific updates.

I have those .nu files. the EFI, recovery and rootfs. They are easy to obtain by simply selecting firmware update from your Maschine+ and then removing SD card before rebooting. At least that is how it behaved last year. It's possible NI has changed this process since then.

The NU files appear to be encrypted and signed though, at least according to what I've seen from the eMMC dump. However there is another step that happens during this process that I have yet to find and understand.

this. thread is so useful. ive been able to maintain & repair my M+ because of it

am I still gagged? Anyway, this just so cool to read. I feel like I’m in a movie where hackers have to save the world!! I understand nothing but feel everything!! Haha

I have nothing to ask, I just think it’s exciting what you do and what you can report haha

Well I'm glad people are interested, I was hoping to inspire more people to look into the internals but it's honestly hard to tell.

Of course I've mounted the emmc image in a vm and looked over it, but I think what you're trying to get at is using the emmc image as a disk image to boot a virtual machine from?

Assuming that's the case, it's not a very easy task to perform. Embedded devices have a number of built-in peripherals, not unlike a desktop PC. They may have devices connected via SPI, I2C, I2S or other chip-to-chip busses. All of these devices need to be emulated in some form for the original code to run. It's definitely something that can be done…. If you look into emulating WiFi routers, you'll find that this has been done for a number of popular routers. It's a matter of determining what can be safely ignored and what the system actually needs to interact with.

Long story longer, using the emmc image to emulate an M+ is a pretty substantial task.

A few people have asked for, and I'd love to share the emmc image, but there's a lot of personal data mixed in across the entire image, so I've no plans to ever distribute the entire emmc image. I just don't know enough about the image to feel confident that I would be able to erase any personal info.

I've got a lot going on currently so I really haven't done much since dumping the emmc, and honestly I'm not sure if I will pick this up again. I also made a huge mistake when desoldering the emmc and a few smt capacitors were removed during the process, so my M+ is currently not working.

Glad people are still interested, happy to answer any questions if I can.

Hi!

Of course I've mounted the emmc image in a vm and looked over it, but I think what you're trying to get at is using the emmc image as a disk image to boot a virtual machine from?

exactly, since it's an ext4 with boot manager running on some x86 architecture it could be rather easy to boot from. usually the disk paths (either UUID based or logically named) need to be adjusted (the VM won't mount an "/dev/mmcblk0p1" but rather an "/dev/sda" or "/dev/nvmXYZ", depending on the driver).

Embedded devices have a number of built-in peripherals, not unlike a desktop PC. They may have devices connected via SPI, I2C, I2S or other chip-to-chip busses.

Sure, could be, but we know that it's a "Conga-QA5 Intel Atom x5-E3940" module, seeming like an off-the-shelf x86 SBC. I'd expect that internal communication to the Maschine Controller goes via USB b/c it's already that way for the M3 line which simplifies implementation & maintenance (Rough guess of peripheral usage w/o looking into anything: standard SM-Bus for internal things, I²C bus: too cumbersome for the usually low datarate, UART low datarate, PCI too cumbersome to implement).

A few people have asked for, and I'd love to share the emmc image, but there's a lot of personal data mixed in across the entire image, so I've no plans to ever distribute the entire emmc image. I just don't know enough about the image to feel confident that I would be able to erase any personal info.

Sure, I'd also be not inclined to share the maybe included serial number.

I've got a lot going on currently so I really haven't done much since dumping the emmc

sound like tough times, good luck!

and honestly I'm not sure if I will pick this up again. I also made a huge mistake when desoldering the emmc and a few smt capacitors were removed during the process, so my M+ is currently not working.

oh my, sad to hear! tbh i would not have had the guts to unsolder the emmc, reball & resolder it. pretty brave! did it hit only the capacitors on the congatec SBC? (so the project of cloning the emmc & migrating it to another board could still make a lot of sense?) Also you now can only use it as Maschine (minus plus), right?

For the ultra-geeks out there….

Emulating Arm router firmware:  https://azeria-labs.com/emulating-arm-firmware/

Good that this one is a x86, i already had my fair share of arm qemu with other projects.

Firmadyne:  https://github.com/firmadyne/firmadyne

Fun stuff.

Also comparing to other things, the Ableton Push designers went with the Intel NUC Compute Element -series, which actually could have been a pretty clever design idea (until Intel announced to discontinue the NUC, ASUS finally took it over but afaik the future for compute element modules are still an open/untouched/ending topic).

Two more things:

1: What's the goal for the development right now?

My thoughts: the only useful direction I see is upgrading the M+ performance with a stronger CPU. That makes a lot of sense, increases TDP which needs more energy & cooling. Also opening up & installing custom VSTs could be nice but how many interesting linux vsts are there which could be controlled without a screen. Building a standalone music box with more horsepower supporting more instruments could need a bit of a different direction b/c of future-proof upgradability, energy supply and cooling.

2: Ideas/steps to try running it in a VM:

1. check disk image, i think you already did that showing the 8 partitions (4 + 4 recovery). fdisk -l emmc_dump.bin / parted emmc_dump.bin print
2. check for BIOS or EFI, e.g. using hexdump, iirc it was EFI → let's go with qemu & ovmf
3. mount the disk in qemu including everything, best as SD card, then we may not require any changes. therefore let's go with the sd-card driver. checking this back with the /etc/fstab on the device could make sense.

the qemu command could roughly look like (untested)

qemu-system-x86_64 \

  -m 2048 \

  -enable-kvm \

  -cpu host \

  -smp 2 \

  -bios /usr/share/OVMF/OVMF_CODE.fd \

  -device sdhci-pci \

  -device sd-card,drive=emmc \

  -drive if=none,file=emmc_dump.bin,format=raw,id=emmc \

  -serial mon:stdio

Cheers