The Axoloti patcher was built by users for Raspberry Pi before, with underwhelming performance. That was RPi 2 and 3 though, I tried it on a 4 today.
Building the patcher and even compiling firmware surprisingly works after I’ve scrapped the whole build script and apt-installed recent and currently maintained versions of java, arm-none-eabi and other required packages.
Firmware does not really compile well but that’s an issue of gcc version mismatch. I copied over the current firmware .hex and .bin from the standalone build.
This is the image file for Raspberry Pi 4 (Model B) with Raspberry Pi OS and the Ksoloti Patcher installed.
I guarantee nothing, use at your own risk.
I am going to leave this here in case anyone wants to experiment.
With the development of usb audio I’m wondering if a ksoloti/pi tandem could be turned into a mega instrument. You get send audio back and forth for cpu intensive reverb on the pi. And then also have the pi running the patcher.
Hi, trying to built this on a non RPi Arm Linux. It should be more powerful than RPi5 so, high hopes for getting something usable.
Can you share what you mean by “scrapped the whole build script”
Do you start from the old axoloti git repo? Or directly from ksoloti?
awaiting my first Big Genes DIY, but I have some ols axo’s I want to make use of meanwhile.
It’s been a while,I simply ignored the build script but used the info inside the script to manually install required packages, java ant and the arm version of gcc-arm-none-eabi.
I started with the ksoloti/ksoloti repo.
But maybe set the repo to the tag 1.0.12-8 before you try anything, that’s the current release version.
I cloned the repo and checked out the tag using git checkout tags/1.0.12-8 after doing a git fetch --all --tags
building the firmware also needs chibios, I have no idea what version i should put there.
After making the .sh files in ksoloti/firmware_axoloti_legacy executable, the firware build stops at missing chibios.
for now I’ll be skipping that part.
so I went for /ksoloti/platform_linux and ran the ./build.sh
I also ran the addudevrules and other scripts from that directory. The process was pretty smooth. My ubuntu-on-rockchip did complain about libbz2:i386 not being found or something,
I had to install the regular (non headless version) of openjdk otherwise it complains about no DISPLAY found
Upon running I need to install some extra libs, like libusb4java after seeing this exception. org.usb4java.LoaderException: Native library not found in classpath: /org/usb4java/linux-aarch64/libusb4java.so
apt install libusb-1.0-0-dev
was not enough, I had to install the native JAVA usb lib
git clone git://github.com/usb4java/libusb4java.git
cd libusb4java
mkdir build
cd build
cmake .. -DCMAKE_INSTALL_PREFIX=""
make install/strip DESTDIR=/tmp
It compiled fine. I then installed it to the directory from the error and changed the permissions. Sadly java still cannot find it at /org/usb4java/linux-aarch64/libusb4java.so (even though it is at the correct location) the error is unchanged
After trying to set the javaclasspath in various ways and linkingthe lib to places in the classpath I’ve seen from java -XshowSettings:properties I have toadmit I don’t know what else to try… Ksoloti cannot find the libusb4java.so
Soo… the gui is up, but I’m missing a basic part, libusb4java… any ideas? I tried this page and followed all the steps successfully, but it did not help.
in the 1.0.12-8 tag, linux-aarch64 is not included in the distribution (libusb4java 1.2.0) in the master branch it is (version 1.3.0)
I tried copying the 1.3.0 file, symlinking it to 1.2.0 but that did not help…
I added the jar directly to the $CLASSPATH as well as the native library. I tried using the -cp in the java command as well as the -Djava.class.path=
the error remains org.usb4java.LoaderException: Native library not found in classpath: /org/usb4java/linux-aarch64/libusb4java.so
I even linked libusb4java.so in my $JAVA_HOME native libs directory /usr/lib/jvm/java-1.21.0-openjdk-arm64/lib
Did you open the raspberry pi 4 image and have a look what is inside the ksoloti folder /home/ksoloti? There is no aarch64 version of libusb4java there, only linux_arm.
Maybe try to extract the ksoloti folder from the img and diff it, or run it directly on your system haha
Anyway, I seem to remember that there is no point in getting aarch64 versions of java libraries if not all of them are available as aarch64. There is probably going to be something that only has a 32 bit version, which will make the whole app only run as 32 bit.
I extracted ksoloti from the image. I get (besides some error about a prefs file that seems to be no big deal) the same error. I think ksoloti compiles fine, but there is a host system problem. the 32bit problem could be something. but I don’t have good experience running mixed 32bit/64bit
I copied over the whole folder and ran it straight from my harddrive, not from the image. and I still have the error.
I’m pretty sure my native libusb4java is compiled fine as well… ksoloti just cannot find it…
thnaks for all the input, but I’m (still) out of ideas
I’m afraid I can’t help you with it either … All I know is I never had to install any native libusb4java, I don’t even know what exactly that is to be honest. the libusb4java 1.30 files in the lib folder (and references inside build.xml and nbproject/) should be enough … what exactly are you running to do the build? IIRC the build.sh script does not make any sense for Raspberry Pi or similar, so I would run “ant” in the command line and that would be that.
You then also need chibios and gcc-arm-none-eabi for the firmware and patch compilation mechanism, the exact links you can find in the build.sh.
Also I use Zulu java 21.30.15 something something, again the exact link is in the build script. Hope this gives you some ideas!
I added the aarch64 jar from the github master to the lib directory and in the build.xml file. It builds fine and now the usb error is gone.
so for clarity:
I edited build.xml
and added <zipfileset excludes="META-INF/*.SF" src="lib/usb4java-1.2.0/lib/libusb4java-1.3.0-linux-aarch64.jar"/>
I did put it in the 1.2.o directory but that does not matter, the lib is found now. Also building using ant as suggested
It does say SEVERE: No matching USB devices found. but that is probably because I d not have the ksoloti for now, I just have an old axoloti. Ksoloti says INFO: Link to firmware CRC F95CB123 old axo said: Link to firmware CRC E95BAC96
when I reboot ksoloti in legacy mode it asks to reflash the firmware… not sure if I should proceed.
Firmware version 1.0.0.1 | CRC 0xE95BAC96
Firmware CRC mismatch! Please flash the firmware first!
Hardware CRC E95BAC96 <-> Software CRC Please compile the firmware first
when trying to run the compile_firmware_linux.sh in the firmware_axoloti_legacy directory, it fails with
/tmp/ccqushTk.s:1300: Error: leb128 operand is an undefined symbol: .LVU37
make: *** [../chibios/os/ports/GCC/ARMCMx/rules.mk:181: build/obj/flash.o] Error 1
Yes, this is a slightly updated firmware compared to the old Axoloti 1.0.12-2, you should be fine.
leb128 operand is an undefined symbol
This sounds like a compiler version mismatch, which version arm-none-eabi did you install? For 1.0.12 you should probably stick with 4.9 or whatever is in the build script, you can’t just get the newest .deb or so, it will completely go off because they changed so many things
should be build/runtime/tmp/axoloti_runtime/platform_linux/lib/gcc/arm-none-eabi/4.9.3/armv7-m
according to build.xml, I can however not find campatible binaries, not online, and not in the RPi4 image. Looking here: /rootfs/home/pi/ksoloti/platform_linux/bin
trying that binary just gives ./arm-none-eabi-gcc: cannot execute binary file: Exec format error
Not going smooth…
architecture is not recognized
in order to keep the build minimal use the options
first build the prerequisites, ./build-prerequisites.sh --skip_steps=mingw32
after that ./build-toolchain.sh --skip_steps=mingw32
it succeeds at a lot of tasks, but fails at some tasks checking build system type... Invalid configuration aarch64-linux-gnu’: machine aarch64' not recognized
I had to add the line | aarch64 \ after the line containing | arm \ sometimes in config.sub, sometimes in configfsf.sub
eg.:
gcc-arm-none-eabi-4_9-2015q3-20150921/src/gmp-4.3.2/configfsf.sub
followed by a wild guess in gcc-arm-none-eabi-4_9-2015q3-20150921/src/gmp-4.3.2/config.sub
the failing files are shown in the output, so easy to adapt
error is like: configure: error: /bin/bash /home/kaos/toolchain/gcc-arm-none-eabi-4_9-2015q3-20150921/src/mpc-0.8.1/config.sub aarch64-linux-gnu failed
edit the file and run the command to check if it returns something other than unknown.
just trying stuff here, not really understanding it…
I also removed “make clean” from the build script, otherwise the building has to start over everytime
after some time both the first build succeeded
sometimes I needed to install some extra packages like sudo apt install texlive-font-utils because some pdf convertionstep fails
Finally I get an error… error: use of an operand of type 'bool' in 'operator++' is forbidden in C++17 meaning my gcc is too new too build this old version…if I googled that right.
I also googled the fix (not all steps were found)
vi gcc/reload1.c //open the reload1.c file and //search for “spill_indirect_levels++” and replace “spill_indirect_levels++” AS “spill_indirect_levels = 1”
sed -i -e ‘s/attribute///attribute/g’ gcc/cp/cfns.h
sed -i ‘/#include <pthread.h>/a #include <signal.h>’ libsanitizer/asan/asan_linux.cc
vi libsanitizer/tsan/tsan_platform_linux.cc //open the tsan_platform_linux.cc file //and search for “statp” and replace the below line: “__res_state statp = ( __res_state)state;” AS “struct __res_state statp = (struct __res_state)state;”
But even after I did all that after several hours of compiling, the builttools step still fails… Unless the arm buildtools pop up somewhere, I’m not diving deeper
Done generating code.
Compiling patch...
cc1plus: warning: /home/kaos/ksoloti/build/xpatch.h.gch: had text segment at different address
x /home/kaos/ksoloti/build/xpatch.h.gch
cc1plus: error: one or more PCH files were found, but they were invalid
cc1plus: fatal error: /home/kaos/ksoloti/build/xpatch.h: No such file or directory
compilation terminated.
make: *** [Makefile.patch:59: /home/kaos/ksoloti/build/xpatch.bin] Error 1
Shell task failed, exit value: 2
Patch compilation failed: /home/kaos/ksoloti/1.0.12/axoloti-factory/patches/tutorials/20_karplus_strong.axp
Hmm, even when emptying the whole build directory, I get this error. The files are regenerated on compile. Could it be I build the toolchain with the wrong compileroptions or something? The xpatch.h file is missing, but also not visible in my working axoloti and ksoloti installations.
xpatch.h is in the firmware folder and shouldn’t be the problem. Ksoloti is using the arm none eabi inside platform_linux/bin, did you place your build (recreate the folder structure?) inside there?
There are some other helper files like “make” in there, maybe try out some older version (IIRC Axoloti and Ksoloti 1.0.12 use make 3.82)
Not a priority but dfu-util (for rescue flash) might not work either, it required a patched libusb version in 1.0.12 (the patch is somewhere in platform_linux called like libusb.stdfu or so)
