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.
I’ve finally had some time to work on this. The main breaking change I had to do to OwlProgram was to disable building the web libraries, but other than that we now have a working prototype for building and flashing OWL2 programs:
I have tested it on Linux and macOS x86_64 and mainly Windows needs to be confirmed.
We can export the source (including our included version of OwlProgram), a binary, load the patch into memory or store it into one of 8 slots (not sure how many is feasible, I read somewhere up to 39 slots?)
Eventually we should also add board selection for OWL3, although I’m not sure how best to add the precompiled library. Maybe we need separate copies of OwlProgram for either OWL2 or OWL3?
There is also still the limitation of our Linux toolchain not being available for ARM as we have not found time or resources to replace the build-anywhere tools.
[edit: can’t post more than 3 times consecutively, so I will edit this post instead]
Hmmm, so I was under the impression that if the libraries were built with make libs PLATFORM=OWL2 that they would only work for modules built with PLATFORM=OWL2 as well. However I just built a module with PLATFORM=OWL3 using these libraries and didn’t get any errors and it successfully flashed etc. 
Glad to hear that something OWL-related still moves forward
store it into one of 8 slots (not sure how many is feasible, I read somewhere up to 39 slots?)
That’s a compile time option (because some we need to statically allocate metadata in firmware). The default value is 40. It could be that just 39 are usable if we need one entry for storing the patch loaded to memory.
I was under the impression that if the libraries were built with
make libs PLATFORM=OWL2that they would only work for modules built withPLATFORM=OWL2
It’s likely not a problem, because PLATFORM=OWL3 does the following:
-mfpu=fpv5-d16 instead of -mfpu=fpv4-sp-d16
The former is irrelevant for building libraries as it takes effect only when linking final patch binary.
Newer FPU supports native 64 bit float maths. It also has a few new instructions, one thing that is definitely relevant is hardware instruction for getting min/max of 2 floats in 32 bit. I think what you describe (build libs for OWL2, patch for OWL2 or OWL3) should be safe to use, because newer FPU mode is a superset of previous.
Maybe you should allow choosing OWL1 platform too, its only effect compared to OWL2 is that it limits patch size (again, happens when linking it). This would prevent users from building a patch that fails on OWL1 hardware.
Ah indeed, diff between OWL1 and OWL2 is only the linker script: https://github.com/RebelTechnology/OwlProgram/blob/develop/compile.mk#L61-L75
Thing is I thought that between OWL2 and OWL3 the architecture being different would also mean the libraries wouldn’t be compatible.
I’ll add OWL1 as an option if that means that all the OG users can also make use of this.
So now the main thing will really be testing on Windows … so if anybody is willing to throw themselves at that let me know
Plugdata test builds are here: also add OWL1; build for ALL the OWLs! · Wasted-Audio/plugdata@78afd04 · GitHub
Toolchains are here: run arm-gcc cleanup · Wasted-Audio/plugdata-heavy-toolchain@14eb648 · GitHub
The toolchain needs to be extracted to Documents/plugdata/Toolchain/ or equivalent for the chosen OS.
When manually installing the toolchain you will also have to manually set execution bits for all relevant binaries.
For macOS I also had to strip the quarantine bit on these.
Rebeltech library is only using OWL2 platform and it’s suitable for all devices. It should probably be considered as the default platform in this case.
If a patch is too large for running on OWL1 hardware, we can force a compile time error if correct platform is set when building for that device. That’s more convenient than getting an error later when trying to run it, but it’s a matter of saving user’s time in this situation.
Yeah indeed for the user it would be convenient to get such an error at compile time “patch is too large for target platform” or something.
Only for OWL3 boards that want to load an OWL2 built patch that is larger than 80kb this would not be possible to detect.
Not sure if FirmwareSender then gives us any useful error?
Alright, I was able to borrow a friends’ Windows laptop and do some back-and-forth with the Windows toolchain.
And it totally works now!
Really nice to not have to install a driver because of MIDI
Hopefully we can make this available in the next release of plugdata!
Only thing I’m not 100% certain about is calling it OWL Platform.
Should it say Rebel Tech OWL instead?
(using Technology seems like it would be too long)
I’m not the person to ask about it (and that person likely won’t see the message), however I’d say that generally Martin didn’t use company name as part of product name. I.e. see his description on OWL docs page:
The OWL platform is actively developed by Rebel Technology.
So the first option sounds more natural to me. If you choose the second name, it’s better to keep full “Technology” as this is just an informal way to abbreviate it and there are other businesses that use “Rebel Tech” as brand name.
See I knew I didn’t make up “OWL Platform” out of thin air haha.
I have now set the Store slots in the plugdata UI to have hex values in the drop down.
Afaict slot 0 is reserved for Load so that leaves 1-F options which is 15 slots to store patches in.
For now I think this is good enough, most users won’t hit this limit and especially for Befaco Lich this is the most user friendly as the store slots coincide with what the 7-segment display can show.