gkkpch

Members
  • Content Count

    37
  • Joined

  • Last visited

Everything posted by gkkpch

  1. 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
  2. Was this you: I2S on Pine64 Euler bus ? If not, please message volumio(at)bluewin.ch
  3. 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
  4. 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).
  5. 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
  6. 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
  7. small but important question: where do I find the sources?
  8. 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
  9. living in CH for nearly 40 years obviously rubbed off on me
  10. 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.
  11. this what helped to check the frequency Frequency counter
  12. Asus is aware of it and we are working together to get this solved
  13. 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.
  14. 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.
  15. well, Asus did some things to u-boot that enabled them to load an overlay dtb at boot time, very similar to PRi (RPI uses config.txt, Asus uses hw_intf.conf) Not sure how Armbian manages this. Using Ayufan's script to load an overlay in runtime?
  16. Yep, agree. And the reason why I (core Volumio member) take great care not to title just any supported product as "audiophile". But, there are certain DAC's (and you don't need a pair of specialised ears) that make a hell of a difference. I'm an OS developer, not an audiophile, but from all I have come across and tested over the last few years, there is sooo much difference. And this is why people prefer some products over another. I happen to like the Allo products and spent some time getting them integrated, but there are lots of others...
  17. For volumio I added our own ES90x8q2m device (which helps the sale of our own Volumio hardware, see volumio.org) But there are other DACs TinkerOS can support too, I just added an Allo Piano, working on Allo Boss and Allo Digione. Not integrated in Asus yet, bus upcoming. These are all excellent DACs,
  18. Just a general question, Asus added support to TinkerOS for a number of known DACs from the RPi "audiophile" scene. (Take "audiophile" with care, not all DACs meet that standard and it is not really clear what that standard would be) Armbian does not seem to support any of the those, is there a specific reason for not adding that level of device tree overlay support?
  19. @IgorThanks for the fix, the kernel build script now works without any issues, much appreciated!! A volumio version with it, main focus SPDIF, works perfectly with excellent eth0 and usb performance. Tested it with a cubox 2iex, waiting for confirmation that i4pro also boots (expected as such, but did not work for a previous 4.15.<something>),
  20. What would I loose when compiling from the SR 4.9.y kernel repo directly, apart from not having the latest wifi stuff? Btw: In general, would you have issues with us (Volumio team, mainly me) to use your kernels/ uboot for some of the boards you support with Armbian? It is what I tried for cuboxi here, but got a little stuck because of the issues mentioned.
  21. Thanks, that did the trick! However, the dts problem is still there. And it would to be, because the vcc_3v3 regulator definition IS really missing from imx6qdl-sr-som.dtsi after patching. Just check it out when you have time. (still worth the effort, now I have a clean Ubuntu Bionic dev environment)
  22. Unfortunately Ubuntu Bionic does not work for me, tried in a VM and on a laptop, it throws the follwoing error while running the compile script: ./compile.sh [ o.k. ] Using config file [ config-default.conf ] [ warn ] This script requires root privileges, trying to use sudo [ o.k. ] Using config file [ config-default.conf ] [ o.k. ] This script will try to update remote: Counting objects: 31418, done. remote: Compressing objects: 100% (9720/9720), done. remote: Total 31418 (delta 21787), reused 30834 (delta 21269), pack-reused 0 Receiving objects: 100% (31418/31418), 228.85 MiB | 5.76 MiB
  23. I just finished a compile without the dts patches, that compiles OK (because the vcc_3v3 regulator definition is in imx6ql-sr-som.dtsi). Nevertheless it is a good thing to setup a Ubuntu Bionic machine and take it from there.
  24. Don't worry, pleased with your help already, even if it takes longer