Same for me... This is the reason why this is not a stroll but climbing Mt. Fuji

And why it takes that long.
I see what you did there
I just have started my PandaES to check how the working setup was built. And it turned out that v6.5-rc2 changed the device tree subdirectory structure (to the better) but that is not handled properly by my build scripts.
Why do I work on PandaES? Because it has one of the handsfree speaker drivers wired to a jumper. And it is easier to have a remote controllable setup than the Pyra. And, I have (had?) a working 3.15 AESS setup - but did not yet find the SD card.
I got sound from the legacy interface with a Letux kernel and device tree I received from
@hns. I still get "Invalid argument" when trying the AESS sound path, so not much progress. I'll try and replicate the kernel build in my own build environment.
On a related topic, I found this talk today:
They present a tool for producing firmware files for the Linux audio SoC subsystem. The tool is called "alsatplg" (ALSA topology) and is part of the official ALSA project. It comes bundled with alsa-utils on any modern Linux distro. The tool takes plaintext configuration files (and blobs) and produces a firmware file to be loaded by the Linux kernel. Support for the firmware format was merged in Linux-4.2, and considered stable in Linux-4.8. The current firmware ABI version is 5, but ABI version 4 is also compatible.
What's especially interesting in the talk is that they mention that the tool was initially developed by Liam Girdwood when he was working for TI and the OMAP processors. He later joined Intel and continued working on it. Liam Girdwood is also the name you find in most commits for the AESS firmware repositories. The official AESS firmware, released by TI for Linux-3.8, has firmware ABI version 1.
@hns has spent a considerable amount of time to update the AESS firmware repositories to produce an AESS firmware that can be loaded by mainline Linux. The only way to produce it is by compiling the tools and binary on a compatible board itself, and this compilation breaks from time to time when kernel headers change. Apart from that, the code for generating the firmware is quite bad and hard to understand IMHO. This is not really a good situation.
So, an idea took form: since the firmware
@hns have converted can successfully be loaded by Linux, it should be compatible with firmware ABI version 4 or 5. What if we can use the alsatplg tool to decode it back into plaintext configuration files (and blobs)? Then we would have the firmware information in a much more readable format and a well-maintained tool for compiling it! Unfortunately, it wasn't that easy
Code:
$ alsatplg -d omap_aess-adfw.bin -o omap_aess-adfw.bin.decoded
ALSA lib decoder.c:98:(snd_tplg_decode) first block must be manifest (value 3)
failed to decode context omap_aess-adfw.bin: Invalid argument
The manifest block is actually described in the video above and shouldn't be
that hard to inject into the binary, but I haven't tried yet.
Anyone feeling adventurous could have a try!
Since we already have a stable firmware binary, I will not focus that much on it for now. I'll focus on getting AESS support working (unless
@hns beats me to it)