Installing custom OS on Duo X

Hi there,

Is it possible to install a custom OS on the Duo X? I notice in the BOM for the bottom board that there’s

SERIAL_DEBUG

Connector_PinHeader_2.54mm:PinHeader_1x03_P2.54mm_Vertical

DO NOT PLACE

so I assume that one can solder a header onto the board and get access to the UART for the RK3399? I also see that it’s possible to get into Maskrom mode. Has anyone attempted to install a custom OS on a Duo X? Or a Duo or Duo Dwarf, for that matter?

Also, I see mention of “MOD OS” in various places and a bunch of git repositories on GitHub. Is it possible to build a MOD OS version locally or are there missing/proprietary components?

More generally, how open are MOD to users hacking their own operating systems? From what I can see of the schematics, they seem very incomplete and doesn’t look like there’s enough information to program the peripherals on the device. Would MOD be open to answering questions about, for example how the DAC/ADC or LCD display are connected, so that they can be used in a custom OS? Or any of the other hardware in the device?

Thanks,

Bob Ham

And as a postscript, I tried to find the .dts for the Duo X presuming it would be in one of the linux-* repositories but all I can see is a patch to rk3399.dtsi. Is the .dts available? Assuming so, can I ask where it is? Thanks.

Yes. I’ve done that for the Dwarf. For the DuoX this is the repository you’ll need:

You find all instructions you need to build and install the firmware in the repository.
I’ve done that for the dwarf in order to get a more accurate Tuner display.
Happy hacking.

2 Likes

Hi, thanks for the response but this doesn’t look like source code for MOD OS, the OS running on the main SoC. This looks like firmware for the HMI part, just the user interface. It appears to be FreeRTOS rather than Linux. Also, the instructions say:

# Restart mod-ui service
ssh root@192.168.51.1 "systemctl stop mod-ui"

after installing the updated firmware. If one were updating the OS, one would expect to find a “reboot” command or something similar, not just restarting a systemd service. Also, they say

You can deploy HMI firmware with the hmi-update command included inside the MOD OS.

which refers to the HMI firmware and MOD OS as separate concepts, not the same thing.

Thanks,

Bob

1 Like

Ah, yes, sure. This is only the firmware, not the OS.

@rah

We are ok with people hacking the OS.

The last image that we released are already non encrypted, so that you can customize it to your needs.

The tool for building the full OS is not open.

@falkTX might be able to give you more details on the technicalities :slight_smile:

1 Like

I’m curious about that Dwarf mod! Have you documented your process?

No, I just read the source, modify it to my needs and follow the instructions given in the repository.

1 Like

@falkTX is the .dts available?

publishing kernel related files was a 2nd stage of the “open-sourcing as much as possible from MOD side” that got pending and not finished.

it should go into mod-plugin-builder eventually (even though I know it sounds weird to be there, it is mostly for reusing the toolchain so we can more easily allow custom kernel builds).

for now I put the duox dts file in https://paste.debian.net/plain/1386232

related to customizing the OS, start with Open Images - MOD Wiki for creating a custom installable image.
if something goes wrong you can always use the maskrom mode to reflash the unit from scratch.

finally for the display, that one runs its own OS and code. it is connected to the linux system by 3 serials

  1. uart debug serial - logging in and running commands, like pausing the bootloader to enter restore. this serial is the linux debug console
  2. HMI protocol communication with mod-ui, specified in GitHub - mod-audio/mod-controller-proto: Protocol definitions for the MOD Devices controllers. mod-ui connects to this
  3. “HMI Widgets” and system related communication (was meant to replace serial 1 in time, but never happened). mod-system-control connects to this
5 Likes

It’s great to hear that the intention is there but sadly I wonder how likely it is that this will ever happen :slight_smile: Clearly refraining from publishing all the source code is not limiting making a profit and presumably it’s more of an afterthought for the engineers involved rather than being integral to the business. Which IMHO is a great pity; the value of the MOD pedals would be exponentially greater if the source code for every part of the system was available. Proprietary software isn’t sustainable; when MOD goes out of business or changes focus, the pedals’ OS and the “MOD Platform” will become frozen in time, never updated and forever bit rotting, the pedals continuously decreasing in value over time, the ecosystem dying and all the energy put into them lost. If the source code for the whole system was available, nothing would ever be lost, the ecosystem would be sustainable and MOD’s work could live on. Alas.

Nice one, thanks.

You realize that falkTX is the engineer involved?
There are limited resources at MOD at the moment and preparing all of these parts just takes a lot of time and care.
(and it’s not like there is nothing else on the todo list)

At least right now the possibilities of a customized OS are opened up and it can only get better from here.

2 Likes

Yes.

You’re making my point for me: it’s not integral to the business.

This completely misconstrues what I said. It has nothing to do with “integral” or “business”.
There is no time to work on anything let alone this (which yes: it’s on the todo, but low priority).

Your framing of the situation is not conducive to any future progress.

2 Likes

I think we’re talking about two different things: (1) releasing kernel source code and (2) releasing the source code for the whole of the system.

@falkTX said:

And here there’s the caveat “as much as possible”, meaning there are parts of the system, beyond the kernel, whose source code release is explicitly not “on the todo”. There are parts of the system which are proprietary, for example:

This is what I was lamenting.

I’m not really sure what you want to do with cloud infrastructure code.

I’m not sure why you’re talking about cloud infrastructure code and I’m not really interested in having a debate about the principles of free software with you.

MOD OS is proprietary. MOD will not grant us the right to build it. An owner of a MOD pedal cannot build their own copy of MOD OS. This is because of MOD’s policies, not because of lack of time. This is bad.

Because that’s what the build tools are.

That doesn’t make sense to me. We’re not communicating.

This is going to be impossible specially now because Darkglass owns the tools to create the OS, it is no longer property of MOD Audio.

What @dreamer was implying is that the build tools are all online, as in, builds are (or used to) be all automated.

Anyhow even if everything+everything was open I realistically do not expect it to gather any special attention. Over the course of my many years doing open-source projects, I have clearly seen that just because something is open does not mean it will get any contributions at all.
The idea that “just open it and people will come” is false and biased, because we tend to only remember the best projects that were able to succeed in creating a nice working community around them. Not saying it is what you imply, just clarifying a common misconception I see online.
Problem with community management is that is a full-time job, we tend to expect things to “just happen” but there are a lot of things that need to happen behind the scenes to make this all possible - documentation, mentoring and guidance, on-boarding of new people, moderating discussions and participating on them too, probably something related to incentives to community as well.

That said, I hope to put up the kernel bits on the mod-plugin-builder somewhat soon. The Dwarf stuff is already there, as a test, just not documented yet. But just a matter of:

# build kernel
./bootstrap.sh moddwarf-new kernel
./build moddwarf-new kernel
# copy into dwarf unit over usb
./publish moddwarf-new kernel

Files are in mod-plugin-builder/kernel at master · mod-audio/mod-plugin-builder · GitHub

Anyhow, even when MOD was operating at a faster pace, there were still several infrastructure issues. For example, mod-ui still relies on tornado4 which has been deprecated for around 5 years and is not compatible with latest python. But updating and modernizing it means taking time from other tasks, plus needing actual extra time to test everything after the update is complete…
MOD employees working on things full-time didn’t really help here at all, even me couldn’t justify spending time on such maintenance updates when “everything just works” (the OS is self-contained, so it doesn’t matter if python is old).

Best we can hope for is for future work for Darkglass to trickle-down to MOD units, one of the big things being USB Audio feature which is now complete from Darkglass side and because it is open-source it can be imported into e.g. MOD Dwarf. There were other improvements in mod-host too, one of them being useful to import for faster pedalboard snapshot changes.

9 Likes