s_frit

Yes it is the right patch. It is a "patch to a patch". The lines that seem irrelevant are just context lines in the patch that is being patched.

In case anyone else wants to look at T4 audio I thought I'd leave a few of my notes here, as I need to move on to other things for a while. The device tree audio widgets mention "MICBIAS1" but the rt5651 driver actually uses the lower case string "micbias1". This seems to be a bug in FriendlyElec's .dts (probably copied from some other realktek codec drivers which do use the uppercase spelling). Fixing this fixes an error message in the dmesg startup log. You can confirm this by looking for micbias in the rt5651 driver source code in the kernel tree. Armbian has a mechanism for shipping asound.state with the build. We should work out a canonical asound.state for the T4 and M4 boards and add it to Armbian build. However, I don't know if or how this interacts with pulseaudio. Maybe extra work is needed to get everything to play nice with pulse -- none the less, a working ALSA config would be a good start. I have yet to check this with an analog audio expert, but my reading of the T4 schematic is that the onboard Mic is connected to the codec in differential mode. However, by default the driver configures the codec in single-ended mode. The version of the driver in FriendlyElec's branch doesn't have the device tree binding to allow enabling differential mode for the Mic2 input (later versions of the driver for that codec do). TO TRY: add device tree binding to driver, add appropriate entry to device tree, see whether it improves onboard Mic audio quality. (should reduce noise/increase gain). NOTE: the DT binding docs for that codec which do have the binding for the differential mic input have an error in the docs. they misname the param and say something like diff-param=true; when it should just be differential-param; (not the real names). I'm still very new to Armbian and have no idea whether there are any common practices with regard to setting up audio on new boards. Guidance and feedback would be appreciated.

@ExieGlad it worked, thanks for testing it! I've submitted a patch to the Armbian github. Hopefully this will get included in a future release. https://github.com/armbian/build/pull/1289 By the way, I notice that Armbian provides a way to include an asound.state file as part of the distribution. That should allow working mixer settings to be shipped with Armbian.

@Exie Would you mind testing the attached NanoPi M4 device tree (rk3399-nanopi4-rev01.dtb) with your Armbian_5.76_Nanopim4_Ubuntu_bionic_default_4.4.174 image please? rk3399-nanopi4-rev01.dtb Copy it to /boot/dtb/rockchip (perhaps rename/backup the existing dtp first), then reboot. The result should be that you can play audio (with amixer commands) without any other clock manipulations. `cat /sys/kernel/debug/clk/clk_i2sout_src/clk_parent` should report `clk_i2s1`. Once you confirm that this works I will submit a pull request to get this fix included in the next Armbian build.

@Igor The fix for the audio quality issue on NanoPi M4 is to reinstate these lines in the rk3399-nanopi4-common.dtsi: @Igor Will you accept a patch that reinstates the &i2s1 entry (stops its removal by friendly-arm-hangs-without.patch#L85)? Sidenote: @hjcJust a heads-up: I'm fairly certain that the same fix is needed for the firefly rk3399 board. The same clock assignment generally appears in rk3399 boards when using i2s1 and the codec is not configured as master. For example the following rk3399-firefly-core.dtsi is included by many configurations, and performs the same clock mapping (also another GPLL mapping that I don't think is always needed): https://gitlab.com/TeeFirefly/FireNow-Nougat/blob/firefly-rk3399/kernel/arch/arm64/boot/dts/rockchip/rk3399-firefly-core.dtsi#L519 (But maybe firefly board also needs other ALSA mixer configuration for the codec before this can be tested.)

Great to hear that worked @Exie Hopefully we can get a fix into the device tree to route that clock correctly. I'm not exactly sure why the clock assignment was deleted.

@Exie are you using the 4.4.y legacy kernel, or a newer kernel? The reason I ask is that the Armbian build removes a device tree clock assignment for the I2S1 clock that I thought would be necessary for the NanoPi M4 codec to work properly: https://github.com/armbian/build/blob/master/patch/kernel/rk3399-default/friendly-arm-hangs-without.patch#L85 Would you mind posting the output of the following command while audio is running, please? sudo cat /sys/kernel/debug/clk/clk_i2sout_src/clk_parent If the output is clk_i2s0, you could try the following and see whether it improves the audio quality (probably best to run this while audio is not playing): su echo clk_i2s1 >> sudo cat /sys/kernel/debug/clk/clk_i2sout_src/clk_parent exit

Now that I've investigated making an ALSA UCM profile, I don't think that's necessary for the NanoPC T4 (although it could be useful for the M4 to distinguish between onboard and headset mic). For T4 it should be sufficient to just overwrite the global asound.state with the file that I posted earler, as follows: sudo cp asound.state.draft.201902018 /var/lib/alsa/asound.state Sidenote: For those who care about gain structure, I found the following values noted as "volumes for 0dB" defaults in plbossart's ALSA UCM profile. Probably with deep enough study these can be deduced from the 5651 data sheet. ADC Capture Volume = 47 DAC1 Playback Volume = 175 HP Playback Volume = 31 IN Capture Volume = 23 OUT Playback Volume = 31

I just posted a mixer configuration for NanoPC T4. Probably it works for M4 too: I wonder whether FriendlyElec are shipping an asound.state file with their distribution?

Here is a way to get the onboard audio working on NanoPC T4 (and probably M4 too). It kind-of works with pulseaudio, but I think more work is needed for a good solution for pulseaudio (need to develop a UCM profile). The attached asound.state file will configure the rt5651 codec mixer with sane settings. To use it: Download the attached asound.state.draft.201902018 Run the following command from a terminal (in whatever directory you downloaded the file): alsactl --file ./asound.state.draft.201902018 restore After that you should have working headphone audio and microphone capture. WARNING: this command may make a loud audible thump. Do not wear the headphones when running it. Note that in the absence of a ucm profile, pulseaudio might make its own changes to the codec mixer settings at login, so you should run the above alsactl restore command *after* logging into the desktop. You can try using alsactl globally to save the settings for use after reboot, but personally I have not yet found a good solution -- please let me know if you have any thoughts on permanent save/restore and pulseaudio interop. There is some general discussion about asound.state management here. If you run alsamixer from the command line you can adjust output level using "DAC1" and "HP". Hit F4 for capture, then the gain settings that appear to work for the internal microphone are "ADC", "ADC Boost Gain" and "IN2 Boost". ... So far I developed this configuration with the help of the following resources: plbossart's configuration for baytrail boards using the same ALC5651 codec: https://github.com/plbossart/UCM ALC5651 codec data sheet v0.92 https://e2e.ti.com/cfs-file/__key/communityserver-discussions-components-files/6/ALC5651-DataSheet_5F00_V0.92.pdf (Audio routing diagrams are on pages 4 and 5. Page 4 is the analog routing, page 6 is the digital routing.) NanoPC-T4 Schematic http://wiki.friendlyarm.com/wiki/images/f/f4/NanoPC-T4-1802-Schematic.pdf NOTE: Beyond the codec mixer settings I think there are some things that can be tweaked with the device tree and drivers that may improve the microphone noise floor, but I haven't gone too far into that yet. If anyone is interested I'm happy to share my notes or discuss details of the routings I chose. asound.state.draft.201902018

What does "massive problems" mean? Can you be more specific? People have reported that HDMI sound worked with NanoPC T4 but that the headphone jack did not work. Are you trying to use the headphone jack? I can't help you with pulseaudio or alsa install. But I think that the issue with the headphones jack is with alsa mixer settings. I have headphones working on NanoPC T4 now. Maybe the fix is the same for M4.

Hi Destmaster, Sorry about the delay. I've been away. I would check the startup log for relevant messages by running `dmesg`. If you have compiled any loadable kernel modules, check that they are being loaded by running `lsmod`. It would make it easier for people to help if you say exactly what you edited in the dtb. This is a good talk if you haven't seen it: https://www.youtube.com/watch?v=kb1yAt9d2k8 (ASoC: Supporting Audio on an Embedded Board, Alexandre Belloni). A a bunch of troubleshooting suggestions are given near the end. As for device tree overlays: overlays are something you can copy to your /boot dir without having to recompile the base .dtb (and potentially they will keep working after you upgrade Armbian). However I'm not 100% sure how device tree overlays are selected on Armbian (try searching the forum). Here are some links: Add an I2S mic using device tree overlay (on raspi) https://source.android.com/devices/architecture/dto A google search will give a bunch of tutorials and info on device tree overlays.

Workaround for latest `make scripts` issue is described here:

Same problem with `make scripts` with linux-headers-4.4.174-rk3399 Patching net/Kconfig also works around the issue. Thanks.

As far as I can tell, many, if not all, targets generate an identical postinst script for the linux-headers package by patching scripts/package/builddeb. A search of the Armbian build repo for "Compiling headers - please wait" produces 33 code results. This means that improving the postinst script (for example, as discussed here) requires updating 33 patch files. I'd be happy to help improve the situation, but I'm unsure how to proceed. Could we have a global postinst script for the linux-headers package, and somehow copy it into place? or must we use a patch file?

I just upgraded to the 4.4.174 headers from stable (with apt upgrade from the official armbian apt repo, not using side-loaded packages), and now there is a new problem with `make scripts`: ross@nanopct4:/usr/src/linux-headers-4.4.174-rk3399$ sudo make scripts scripts/kconfig/conf --silentoldconfig Kconfig net/Kconfig:83: can't open file "net/wireguard/Kconfig" scripts/kconfig/Makefile:37: recipe for target 'silentoldconfig' failed make[2]: *** [silentoldconfig] Error 1 Makefile:576: recipe for target 'silentoldconfig' failed make[1]: *** [silentoldconfig] Error 2 make: *** No rule to make target 'include/config/auto.conf', needed by 'scripts'. Stop. @Igor Is it possible that this is fixed with the [Wireguard fix] commit 53fcb9852 ?

Ok, I thought perhaps you were following some special instructions for editing the dts. I am working through a similar process to enable i2s1 on the NanoPC T4. So far I am just converting and editing the dtb files in a standard Armbian install. You can also install dtbo overlays, which I think is more robust.

Can you give a link to the FriendlyArm wiki page that you are talking about please? I don't see any instructions on modifying the dtsi on the NanoPC-T3 Plus page. You can install the standard Armbian image then use `dtc` (device tree compiler) to decompile the flattened device tree .dtb somewhere under /boot/dtb, then edit the .dts, then recompile it to .dtb. This is not the only way, maybe not even the best way, but it is one way to do it. If you are lucky the Armbian .dtb already has the node for i2s1 and you can just edit a few parameters. My understanding though is that it is not enough to enable the i2s, you also need a codec and to set up a simple-audio-card node. But please provide the link to the FriendlyArm wiki as this will help to be clear about what you are trying to do.

Following on from my previous status, where `make scripts` was failing, I found that selinux security related headers were absent from the linux-headers package. The best (most minimal) fix for this I found was to modify builddeb to add the security include files to the linux-headers package. The patch is an additional one line change (in addition to the fix-linux-headers-rk3399-pkg.patch above): +(cd $srctree; find security/*/include -type f) >> "$objtree/debian/hdrsrcfiles" With this change, both `make scripts` and my test kernel module compile successfully. And the test kernel module loads/unloads correctly. I think this is the good change because it only adds include files, and this addition is already done for sunxi-dev and rockchip-dev (maybe elsewhere too?) e.g.: https://github.com/armbian/build/blob/master/patch/kernel/sunxi-dev/general-packaging-4.20-dev.patch#L153 https://github.com/armbian/build/blob/master/patch/kernel/rockchip-dev/general-packaging-4.20-dev.patch#L153 @Igor I have attached a new patch file called fix-linux-headers-rk3399-pkg-v2.patch this patch includes the change from the previous patch. Please use the new -v2 patch to overwrite the existing fix-linux-headers-rk3399-pkg.patch in Armbian build. Once this propagates to the package repository I will re-run my tests. For future reference, here is how I performed the test: First, make sure that the existing linux-headers package is uninstalled: Then install the new (working) linux-headers package that I built using Armbian build (once Igor updates the repo, just install linux-headers in the usual way). Run `make scripts` as per https://docs.armbian.com/User-Guide_Advanced-Features/#how-to-build-a-wireless-driver `make scripts` should complete with no error. Then running `make` in lkm_example directory (described in my first post) should work. And you can follow the instructions in the tutorial to load/unload it from the kernel. fix-linux-headers-rk3399-pkg-v2.patch

I have made progress by applying the attached patch and rebuilding linux-headers-rk3399.deb I then installed the deb manually with `sudo dpkg -i ./linux-headers-rk3399_5.74_arm64.deb` then `sudo apt-get install -f` However now I'm getting a different error when compiling test kernel module attached above "/bin/sh: 1: ./scripts/recordmcount: not found": I have found some references to needing to "make scripts" in the headers directory, however I've been unable to find a way to do that successfully. Any hints would be appreciated. Update: when running `sudo make scripts` in /usr/src/linux-headers-4.4.172-rk3399 I get the following error This appears to be a similar issue to here: https://forum.armbian.com/topic/7253-rock64-cannot-install-wireguard-module-on-ubuntu-1804/ I will try the suggested fix once I have had some sleep. fix-linux-headers-rk3399-pkg.patch

For completeness, the issue is only present in friendlyarm 4.4 repo: https://github.com/friendlyarm/kernel-rockchip/blob/nanopi4-linux-v4.4.y/scripts/package/builddeb#L325 Which is the source for the default kernel for 'rk3399' family boards such as nanopc-t4 (https://github.com/armbian/build/blob/master/config/sources/rk3399.conf). It looks like the fix has already been applied to both the 4.4 and mainline ayufan-rock64 repositories (which are the source for 'rockchip64' boards): https://github.com/ayufan-rock64/linux-kernel/blob/release-4.4/scripts/package/builddeb#L325 https://github.com/ayufan-rock64/linux-mainline-kernel/blob/master/scripts/package/builddeb#L158 (not sure whether Armbian is sourcing the release-4.4 branch though).

This report applies to NanoPi-4 RK3399 boards (NanoPC T4, NanoPi M4, NanoPi NEO4) running Armbian Bionic (Friendlyarm-based legacy 4.4.y kernel). In other words, boards targeted by Armbian rk3399.conf and Friendlyarm kernel but *NOT* baords using rockchip64.conf and Ayufan kernel. There is a bug in the friendlyarm linux 4.4 version of /scripts/package/builddeb that causes the linux-headers package to be incomplete. Attempts to build out-of-tree kernel modules to fail with errors of the form "fatal error: ../../arm/include/asm/opcodes.h: No such file or directory". For example here is the output trying to build a simple kernel module from this tutorial: @hbmaennchen encountered the same problem when compiling an existing module here: https://forum.armbian.com/topic/8693-headers-44162/ This is a known bug that has been encountered in other kernel header distributions, for example here and here. The fix was applied to mainline in 2016 and is a one line change to the scripts/package/builddeb script. The fix was posted to LKML in March 2016 and was committed to mainline here: https://github.com/torvalds/linux/commit/962475ac2f9662fe69a9f86220ab31bbbf3911d2#diff-03db9657e7716d9ca27a586068430b37 Please could this patch be applied to the Armbian build process? I have no experience with Armbian build but if you need me to generate the patch in the correct format and submit a pull request I can do so, just let me know that you'd like me to do it. Update: my system information NanoPC T4 Ubuntu 18.04.1 LTS bionic 4.4.172-rk3399 header package installed: linux-headers-rk3399 Update: steps to reproduce Using a NanoPi-4 RK3399 board (NanoPC T4, NanoPi M4, NanoPi NEO4) running Armbian Bionic (Friendlyarm-based legacy 4.4.y kernel) First install the linux-headers package: $ sudo apt-get install linux-headers-rk3399 Then, place the attached files lkm_example.c and Makefile into a directory (e.g. named lkm_example). cd to that directory, and type `make`. You should then get the error in the spoiler above. The expected behavior is for the make to succeed without error (which should happen if you are running any other board with the appropriate linux-headers-... package, e.g. the same board with the dev kernel, and linux-headers-dev-rk3399 package installed. Makefile lkm_example.c

Are the heatsink mounting holes compatible with "every Northbridge cooler with a mounting hole distance of 60 mm" as for the RockPro64?

Hi, I'm interested in what the future holds too. For additional sources I can add: User Charbax on YouTube posts some interesting interviews from conferences and trade shows: https://www.youtube.com/user/Charbax/videos MickMake weekly roundups seem to cover all the SBC-related crowdfunding announcements: https://www.mickmake.com/ The following might not be in your price bracket, but this is what I've deduced: The ODROID N2 is on the horizon (with as-yet unknown SoC, possibly better than RK3399). https://www.cnx-software.com/2018/06/24/odroid-n1-canceled-due-to-ram-supply-issues-odroid-n2-coming-later-this-year/ VAMRS has an out-of-stock product listing for the RK3399-based ROCK960 Model C ($69) with no product details. I haven't seen it mentioned elsewhere, but comparing photos it seems to be a redesigned version of their Rock960 board, with no bundled eMMC (just a socket), different USB ports (no type-C connector), and the PMIC moved to the other side of the board: https://store.vamrs.com/products/rock960-model-c