I think you’ll find Dreamer is at work integrating your changes already!
I need to update this work. OWL stuff has been merged into HVCC last year, but I didn’t get around to continue the PR.
@JoshuaACNewman this was done over a year ago already 
plugdata integration should be fairly straightforward, since we already have the necessary compiler and other stuff in the toolchain. We just need to add the OWL firmware part and some hooks to the UI with any necessary choices.
Will try to get back to OWL testing and updating the PR soon-ish.
@Befaco I have a Lich already on which I’m doing all my tests.
Hi all, just wondered if there is any news on this? I’d love to be able to use PlugData with my Owl.
No there is no news. I’ve looked at what would be the minimum requirements to get the OWL toolchain working, but I haven’t pieced together anything tangible that works with the plugdata workflow yet.
Work on this is happening on github: https://github.com/plugdata-team/plugdata-heavy-toolchain/issues/13
I’ve started some work to try and bash together a minimal prototype for adding OwlProgram to the plugdata toolchain and into the plugdata compile dialog.
So far I’ve managed to successfully build and flash the test-patch: https://github.com/RebelTechnology/OwlProgram/blob/develop/TestPatches/HeavyTest/HeavyTest.pd
However using this patch from the Patch Library I am getting linker errors regarding the patch size: https://www.rebeltech.org/patch-library/patch/_Lich_Windrone#Source
/home/dreamer/Sources/_projects/_wasted/_hvcc/plugdata-heavy-toolchain-wstd/Heavy/bin/../lib/gcc/arm-none-eabi/10.2.1/../../../../arm-none-eabi/bin/ld: ..//patch.elf section `.text' will not fit in region `PATCHRAM'
/home/dreamer/Sources/_projects/_wasted/_hvcc/plugdata-heavy-toolchain-wstd/Heavy/bin/../lib/gcc/arm-none-eabi/10.2.1/../../../../arm-none-eabi/bin/ld: region `PATCHRAM' overflowed by 632400 bytes
collect2: error: ld returned 1 exit status
make[1]: *** [compile.mk:179: ..//patch.elf] Error 1
make: *** [Makefile:110: patch] Error 2
The patch size seems to be extremely large somehow, any insight into what’s going on would be helpful.
However I’m not using the regular make HEAVY=patch method of building, because we first export the OWL code directly using our PyInstaller version of HVCC in the plugdata toolchain.
We first export the hvcc code to a temporary directory <temp_path>/Source and then copy OwlProgram next to it in <temp_path>/OwlProgram.
Then from the OwlProgram directory we execute the following:
<path_to_our_toolchain/bin/>make -j4 TOOLROOT=<path_to_our_toolchain/bin/> BUILD=../ PATCHNAME=<patch_name> PATCHCLASS=HeavyPatch PATCHFILE=HeavyOWL_owl.hpp load
Hey @dreamer, good to hear that there’s some progress here! I guess you can take a look at what’s in readelf -a patch.elf output and compare it to what you get from OWL’s HVCC version.
I hope it’s not doing something funny like JSON parsing at runtime
There is no patch.elf created by the linker as it fails exactly at this stage.
Versions shouldn’t really differ that much. And as I said the HeavyTest.pd builds just fine.
Btw if I manually build/run with OwlProgram (same version, namely my fork: https://github.com/Wasted-Audio/OwlProgram ) it does work.
Could it have something to do with gcc versions? That’s the only thing I can definitely point to that is different between my local build and the one in the plugdata toolchain.
In the toolchain we are using arm-gcc v10.2 (this is pinned because of libDaisy) and locally I have v12.2
hmm, not sure what I did now, but my board just gives the infamous E. is unresponsive and gets super hot -_-
Ah right, sorry about that pointless suggestion If you just want to link a larger patch executable without being able to run it on hardware, you can edit Source/flash.ld and change the line PATCHRAM (rwx) : ORIGIN = 0x2000c000, LENGTH = 144K /* total RAM is 192kb */ to specify LENGTH = 1M or something like that.
Also, we have an option to build patches up to 512kb in size, but they would run only on OWL3 (or Xibeca) boards. This is done by passing PLATFORM=OWL3 when running make commands. It’s not enough to solve this issue (and compiler output is obviously not correct here either way).
Regressions due to toolchain change are certainly possible, I guess you could test the patch generated by OWL’s HVCC with 10.2 GCC to see if it’s also has this issue. Don’t forget to run make realclean; make libs when changing toolchain.
There is really almost no difference in HVCC or Heavylib of the OWL branch or the Wasted Audio branch.
And as said: when I manually build+load it does work (although right now my Lich seems to be completely dead somehow …)
Here’s the readelf outputs for arm-gcc 10 and 12. First one built for OWL3:
https://mrtoasted.com/~dreamer/owl/elf_gcc10.txt
https://mrtoasted.com/~dreamer/owl/elf_gcc12.txt
And for good measure also a build with the linker script patched for OWL2:
https://mrtoasted.com/~dreamer/owl/elf_gcc10_owl2.txt
And the patch used:
https://mrtoasted.com/~dreamer/owl/WindDrone.pd
Ok, so first of all I’ve mentioned wrong linker script, the default one is called owl2.ld and by setting platform to OWL3 you will use owl3.ld which has more RAM for patch code, specifies a different patch address and enables support for double precision FPU. I think you might have figured that out already, just mentioning it to make sure there’s no confusion.
So you say that both files built with GCC10 here are not working? It looks their size is ok and they should fit even in OWL2 SRAM.
Btw, I’ve tried running ./build.sh here and a few things failed, are there any uncommitted changes to this?
Hmmm, when I build with gcc-10.2 now it doesn’t complain about the size … but before it certainly did! (would give the same message about not fitting in region). Too bad my Lich is now dead, so I can’t test anything any more 
Which parts are failing on that script? I know it’s not a pretty setup, but it should work.
Lich is undying by definition! See how to force bootloader on Lich
Regarding plugdata build errors, first of all it gets a 404 when downloading http://ftp.de.debian.org/debian/pool/main/a/alsa-lib/libasound2_1.1.3-5_amd64.deb .
~/dev/rebeltech/plugdata-heavy-toolchain
--2023-09-20 00:22:31-- http://ftp.de.debian.org/debian/pool/main/a/alsa-lib/libasound2_1.1.3-5_amd64.deb
Resolving ftp.de.debian.org... 141.76.2.4
Connecting to ftp.de.debian.org|141.76.2.4|:80... connected.
HTTP request sent, awaiting response... 404 Not Found
2023-09-20 00:22:32 ERROR 404: Not Found.
ar: /tmp/tmp.HNKZGxHjJb: file format not recognized
tar: data.tar.xz: Cannot open: No such file or directory
tar: Error is not recoverable: exiting now
cp: cannot stat './usr/lib/x86_64-linux-gnu/libasound.so.2.0.0': No such file or directory
Btw, I’m running Gentoo on aarch64, so the file would be fairly useless
After compiling OWL libs it thows the following:
~/dev/rebeltech/plugdata-heavy-toolchain/OwlProgram ~/dev/rebeltech/plugdata-heavy-toolchain
In file included from LibSource/ColourScreenPatch.cpp:6:
./Source/PatchProcessor.h:5:10: fatal error: Patch.h: No such file or directory
5 | #include "Patch.h"
| ^~~~~~~~~
compilation terminated.
make: *** [compile.mk:202: Build/ColourScreenPatch.o] Error 1
I guess it doesn’t see it in OwlProgram/LibSource/ for whatever reason.
There was another error, but turns out it was caused by not running it in virtualenv.
No it’s totally fried. When I plug it in it just completely burns up and is totally unresponsive.
Ah, yes the toolchain is not at all tested on arm64 Linux, this will certainly require additional work 
You might test if your OWL digital board is functional by powering it from USB. If not, then you might have to replace it. Otherwise something related to power supply is not working, likely on Lich itself. Might be a dead power regulator, might be something else.
Yeah it does show up, but gets very hot and then after a while disconnects:
[1230610.154759] usb 5-3.4.1: new full-speed USB device number 75 using xhci_hcd
[1230610.256197] usb 5-3.4.1: New USB device found, idVendor=1209, idProduct=dada, bcdDevice= 2.00
[1230610.256202] usb 5-3.4.1: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[1230610.256204] usb 5-3.4.1: Product: OWL-LICH
[1230610.256206] usb 5-3.4.1: Manufacturer: Rebel Technology
[1230610.256208] usb 5-3.4.1: SerialNumber: 2059388F434E
[1230637.587556] usb 5-3.4.1: urb status -32
[1230637.613827] usb 5-3.4.1: urb status -32
[1230637.635344] usb 5-3.4.1: urb status -32
[1230637.720177] usb 5-3.4.1: urb status -32
[1230637.735507] usb 5-3.4.1: urb status -32
[1230637.755811] usb 5-3.4.1: urb status -32
[1230637.757598] usb 5-3.4.1: urb status -32
[1230637.771745] usb 5-3.4.1: urb status -32
etc ..
Will contact Befaco about replacing or upgrading the board.
Finally got a replacement/upgrade OWL board (v3).
So I’ll circle back on this effort soon-ish.
@antisvin btw before we could support aarch64 Linux we need to find an alternative for the build-anywhere tools that we currently use. This project is for x86 only and is anyway quite outdated. Hasn’t seen activity in years and has quite some old tools.
For aarch64 we indeed would need to make some platform-specific changes as well.
1 Like