M+ computer internals + info

D-One · 2024-01-08T20:31:36+00:00

There was an error rendering this rich post.

There was a thread in the old forum with some pics but not here so I am making one. This is probably of no interest to most users, it's just for curious nerdy ones I guess. Obviously, I do not advise anyone to go opening their 1200$ device, if you do and screw it up it's on you! I lost a screw in the process as I always do 😜

HW: Congatec Conga-QA5 with an Intel Atom x5-E3940 CPU.

The forum shrinks pics so I'll upload them to Dropbox in case someone wants to view them in higher resolution: Link.

Internally it's almost the same as the MK3 but with a tiny computer attached in the top-right corner:

It's kind of cool how tiny the computer is (SD and flash drive for scale)

The back

Angled heat sink to make contact with the aluminum back plate, no fins, no fans, all passive cooling.

I was expecting paste but it has a thermal pad for heat transfer:

CPU:

Where the computer connects to:

All screws on the back are the same length except 3, 2 that hold the heat sink against the backplate (for better contact I assume), and another that is connected to a blunt stand-off, the standoff one doesn't need to be unscrewed for the backplate to come off.

Interestingly if I remove the computer from the M+ still works fine as an MK3 / Controller and Audio interface, it connects to Maschine SW on the desktop/laptop. Shout out to @reffahcs for discovering this. So if the internal computer ever dies it can just live on as an MK3 😁

Find more posts tagged with

Comments

Alexios

https://community.native-instruments.com/discussion/comment/211531#Comment_211531

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

reffahcs

https://community.native-instruments.com/discussion/comment/211539#Comment_211539

Very interesting, no I didn't know that. I'll definitely have to look for that. Thanks for the tip!

reffahcs

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.

Alexios

https://community.native-instruments.com/discussion/comment/212000#Comment_212000

Do you have a firmware file? There is an archive with the extension (nisup) and in it (EFI.nu, recovery.nu, rootfs.nu).

reffahcs

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.

reffahcs

Binwalk confirms a very high entropy, which could still mean compression vs encryption. But everything else is pointing to encryption.

Vic Angelo

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

reffahcs

https://community.native-instruments.com/discussion/comment/212049#Comment_212049

That's awesome! Hope you are able to share, but understand we're kind of in a grey area here.

I'm trying to share as much as I can while also not revealing information that can be used to get free software or rip off NI.

djadidai

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

reffahcs

https://community.native-instruments.com/discussion/comment/212188#Comment_212188

Well definitely ask questions, that's how we all learn.

A lot of people get annoyed and feel like you're talking down to them when you overexplain things they already know, so it's always a struggle to understand the audience.

djadidai

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

anwesender

Hi,

I've been following this thread for a while now, you did great progress recently!

Regarding the disk images you have: Why not take the emmc disk dump and mount that in a VM (depending on setup mount points need patching, but shouldn't be too wild)? And/or inspect whats happening after boot, ie fstab, systemd(v,initfs) services.

Nice Job, tbh I didn't expect that resurrection after the stillstand last year!

reffahcs

https://community.native-instruments.com/discussion/comment/222619#Comment_222619

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.

reffahcs

For the ultra-geeks out there….

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

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

anwesender

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:

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
check for BIOS or EFI, e.g. using hexdump, iirc it was EFI → let's go with qemu & ovmf
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

Quick links

Unanswered questions