gkkpch

The Volumio team is currently investigating whether our sopine64 based motivo board (https://volumio.org/epic-journey-called-volumio-motivo/) could boot from usb using SPI flash. I'm aware of the sunxi SPI developments in u-boot and mainline kernel, and that we theoretically should be able to flash the SPI-NOR chip with the correct u-boot version using FEL mode. I also read that armbian has been prepared for booting from usb (as @martinayotte mentioned in other places). My question is, did anyone actually do anything in this direction, is there something I could help testing wit

Was this you: I2S on Pine64 Euler bus ? If not, please message volumio(at)bluewin.ch

So far so good, after googling a little, fixing the Alsa compile issues in the ES90x8q2m codec module proved simpler than I thought. The issues were mainly due to switching from obsolete structs to new ones and a renamed API call. This was finalised in 4.16 by removing the obsolete code, luckily there were no functional changes. With that the question mark for the pcm512x codec could also be eliminated, which completes my patch file for the first two DACs and corresponding DT overlays. Due changed priorities I can't continue until the weekend (max 1 day, then a few days off

Jamess (Asus) located the sample rate issue, seemingly due to an RK commit for a "fix" in the rockchip clock driver. They will now check with RK why that was done. Good thing: it did not make it into upstream, so with 4.19.y we should be fine for the (time being).

Somewhere after 4.16 (or 4.15) the ALSA "snd_soc_code" structure was changed to something like "soc_snd_component" and "snd_soc_component_driver", which means the codec part of the ES driver does not compile anymore and needs to be adapted to fit the new requirements. This must have been done for all standard codecs, I willl need to find some commits to see what it needs. This is going to be a challenge, but as ES90x8Q2M has no priority for the armbian community, I will postpone it in favor of more popular devices. The Allo Piano driver has been ported, there are some question mark

So, my build environment is now ready (don't use Armbian very often), played with compiling 4.19.y, saving and re-using patches (new to me), all fine, ready to go. I have checked the DT overlays for our ES90x8Q2M DAC and the Allo Piano DAC against the dts for the tinkerboard on kernel 4.19.y. They still seem to fit, so I will start with those as these DACs are still lying on my desk. The overlays compiled OK, next step is to add the drivers. Also has a quick look at the boot.cmd to see how you handle the overlay loading, no issues there for a volumio test image (easier fo

got it, just forgot to add BRANCH=dev

small but important question: where do I find the sources?

OK, as this will give me the opportunity to see if 4.19 has the same i2s issues as explained to @TonyMac32 Count me in for the dt overlay and es90x8q2m alsa driver I contributed to the Asus TinkerOS kernel for Volumio's primo box (see https://volumio.org/blog/) However, I do not know in detail what else Asus initially changed to get PI compatible DACs to work with the Tinkerboard MCLK. This will need some digging. This DT overlay work will also get very interesting for Volumio and the Rock64. An upcoming board revision is going to to fix the RPi 40-pin gpio co

living in CH for nearly 40 years obviously rubbed off on me

We only use the Asus kernel because of DAC support. There were many commits between 4.4.71 and 4.4.132 and I have no idea if any of that went upstream. Though with Rockchip we have reasonable new kernels (not like the <3.18 many others have), they don't appear reliable all the time. It's not the first thing that went kaputt unnoticed.

this what helped to check the frequency Frequency counter

Asus is aware of it and we are working together to get this solved

and last but not least, if you were doing anything with I2S devices, keep clear at the moment. We have a serious issue with the Asus/ Rockchip i2s driver (or related components) outputting streams not at the sample rate frequency they are supposed to have. It is not a huge deviatian, but some people could hear it and reported it. Tests with kernel version 4.4.71 shows the problem is not there, we now have version 4.4.132+ with the problem being there. Measurement by externals showed, the problem also includes Armbian.

the hw_intf.conf implementation in u-boot is very much hardcoded with the allowed parameters, be aware of that, but shows a possible way of doing it is a more flexible way.