Jump to content

gkkpch

Members
  • Posts

    41
  • Joined

  • Last visited

Everything posted by gkkpch

  1. You misunderstood I was offering help with testing. Anyway, thanks for your explanation. I'm happy with my dts version as a patch for the armbian build (23.05), used to create Volumio' community porting. But I will make an effort to create an overlay for it, then do a PR as for the dts itself this makes no sense seeing Armbian is using overlays everywhere else.
  2. I used the armbian kernel and u-boot built .debs to create a Volumio image for Radxa Zero2 and Zero (via pre 23.05 to be precise, helping with that as well). Zero so far is absolutely flawless. I added SPDIF to the dts for both devices and informed Radxa about it. They promised to pick it up and create spdif overlays for both. The only issue I have with the Zero2 is wlan speed, it will never go over approx. 200Mb/s, where the zero reaches 433Mb/s easily. (My) both boards have the same AP6256 component. Who do I contact for further information, help with testing etc.? Jira/ altsassians tools I am not familiar with, so I apologize for being old school IT with ~40 years experience ...
  3. Additional information: Old u-boot is Khadas version "2015.01-geddbbf5", generated from Khadas Fenix New u-boot is Armbian version "2022.01-armbian" Error messages when issuing "gpio clear GPIOH_4" "GPIO: 'GPIOH_4' not found" "Command 'gpio' failed: Error -22" I do realise, that this was implemented in a different way with the legacy u-boot, I just wonder why it does not work with mainline. From the include files in include/dt-bindings/gpio it seems that GPIOH_4 has been defined.
  4. Hi, We're swapping the Khadas Fenix 4.9 and uboot v2015-01?? for the Armbian 5.10.y and corresponding mainline u-boot. In the "legacy" version we were able to use the u-boot script (then a dedicated boot.ini) for setting a gpio pin low like this gpio clear GPIOH_4 Unfortunately Armbian's mainline u-boot version does not recognize GPIOH_4 as a valid gpio pin name. Anyone able to help? Did the naming change? Gé
  5. 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 with? I know how to compile u-boot as I've done this with armbian's u-boot version 2019-04 which works fine with our motivo board. I must admit i'm not skilled enough to get this done on my own, any help or pointer in the right direction would be very much appreciated. Cheers - Gé
  6. 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).
  7. 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).
  8. 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 marks for the pcm512x codec (which it depends on), but it could be OK. The kernel compiles OK with all the patches, I'll build a Volumio image with it sometime this week and do the first test.
  9. 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 for me to use as a test environment instead of an Armbian build) I did not have much time today, hope to do a little more this weekend, next week should be OK again .
  10. small but important question: where do I find the sources?
  11. 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 compatibily and then opens potential for a range of popular RPi compatible DACs.
  12. living in CH for nearly 40 years obviously rubbed off on me
  13. 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.
  14. this what helped to check the frequency Frequency counter
  15. Asus is aware of it and we are working together to get this solved
  16. 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.
  17. 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.
  18. 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?
  19. 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...
  20. 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,
  21. 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?
  22. @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>),
  23. 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.
  24. 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)
×
×
  • Create New...

Important Information

Terms of Use - Privacy Policy - Guidelines