FrikoAnPulento

Hello, same problem here. I've manually downloaded files, manually uncompressed them and added .download-complete file and then run compile again. Now it works, but would be nice to fix it. If you need more info about the problem just ask P.S. I can say that I had to download toolchains from browser, because wget got several download errors (probably due to connection issue). Could be related to the problem?

I've checked sun4i drm driver sources. The reason because I was setting DRM_BUS_FLAG_PIXDATA_NEGEDGE was because, in file include/drm/drm_connector.h is written: /* drive data on pos. edge */ #define DRM_BUS_FLAG_PIXDATA_POSEDGE (1<<2) /* drive data on neg. edge */ #define DRM_BUS_FLAG_PIXDATA_NEGEDGE (1<<3) (in kernel 5.9 is a bit different, but concept is still the same). I need to drive data in negative edge, so I've set DRM_BUS_FLAG_PIXDATA_NEGEDGE. Then, in file drivers/gpu/drm/sun4i/sun4i_tcon.c is written: /* * On A20 and similar SoCs, the only way to achieve Positive Edge * (Rising Edge), is setting dclk clock phase to 2/3(240°). * By default TCON works in Negative Edge(Falling Edge), * this is why phase is set to 0 in that case. * Unfortunately there's no way to logically invert dclk through * IO_POL register. * The only acceptable way to work, triple checked with scope, * is using clock phase set to 0° for Negative Edge and set to 240° * for Positive Edge. * On A33 and similar SoCs there would be a 90° phase option, * but it divides also dclk by 2. * Following code is a way to avoid quirks all around TCON * and DOTCLOCK drivers. */ if (info->bus_flags & DRM_BUS_FLAG_PIXDATA_DRIVE_POSEDGE) clk_set_phase(tcon->dclk, 240); if (info->bus_flags & DRM_BUS_FLAG_PIXDATA_DRIVE_NEGEDGE) clk_set_phase(tcon->dclk, 0); So, setting NEGEDGE seemed to me the only reasonable option. I don't have an A20 to check if it's true or not, but seems like on A13 it works in the opposite way! (still same in kernel 5.9) Default il positive edge and 120 (not 240, but it works anyway, because data is stable when display is sampling) is negative edge. Can someone experienced with A20 tell me if this comment is right? (so I can know if is worth submit a patch to linux mainteiners?)

I've dig in. It seems that my problem is related to (so called in drivers/manuals) "clock phase": at address 0x01C0C088 (read with devmem2 0x01C0C088) I found that bits 28:29 are set to 00, which A13's manual says: used DCLK0(normal phase offset) I've manually edit that bits with devmem2 0x01C0C088 w 0x20000000 first (used DCLK2(2/3 phase offset)), and find that the image now is stable. I've check the clock, but data is changing on higher clock state. Still not changing on falling edge. So, I've set register to devmem2 0x01C0C088 w 0x10000000 And finally data seems changing during clock's falling edge. So, I changed my patch with this +static const struct display_timing ampire_am320240l9tnqw_00h_timing = { + .pixelclock = { 6500000, 6500000, 6500000 }, + .hactive = { 320, 320, 320 }, + .hfront_porch = { 20, 20, 20 }, + .hback_porch = { 68, 68, 68 }, + .hsync_len = { 10, 10, 10 }, + .vactive = { 240, 240, 240 }, + .vfront_porch = { 4, 4, 4 }, + .vback_porch = { 18, 18, 18 }, + .vsync_len = { 1, 1, 1 }, +}; + +static const struct panel_desc ampire_am320240l9tnqw_00h = { + .timings = &ampire_am320240l9tnqw_00h_timing, + .num_timings = 1, + .size = { + .width = 70, + .height = 53, + }, + .bus_format = MEDIA_BUS_FMT_RGB666_1X18, + .bus_flags = DRM_BUS_FLAG_PIXDATA_POSEDGE, +}; + And now is working! ...to be continued

Find a bettere solution: msleep introduces audio latency. I need to have real time audio, so I've changed my approach to this: First, I've disabled power management for A13's power amplifier: From e3838f63a589e8e49b071f0c3d8646bc9cd01582 Mon Sep 17 00:00:00 2001 From: Marjan Trexom <****> Date: Tue, 8 Sep 2020 12:15:20 +0200 Subject: [PATCH] disable EN_DA and PA_EN --- sound/soc/sunxi/sun4i-codec.c | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/sound/soc/sunxi/sun4i-codec.c b/sound/soc/sunxi/sun4i-codec.c index a84e83085..018cc9656 100644 --- a/sound/soc/sunxi/sun4i-codec.c +++ b/sound/soc/sunxi/sun4i-codec.c @@ -706,8 +706,8 @@ static const struct snd_soc_dapm_widget sun4i_codec_codec_dapm_widgets[] = { NULL, 0), /* Digital parts of the DACs */ - SND_SOC_DAPM_SUPPLY("DAC", SUN4I_CODEC_DAC_DPC, - SUN4I_CODEC_DAC_DPC_EN_DA, 0, + SND_SOC_DAPM_SUPPLY("DAC", SND_SOC_NOPM, + 0, 0, NULL, 0), /* Analog parts of the ADCs */ @@ -743,8 +743,8 @@ static const struct snd_soc_dapm_widget sun4i_codec_codec_dapm_widgets[] = { SUN4I_CODEC_ADC_ACTL_PREG1EN, 0, NULL, 0), /* Power Amplifier */ - SND_SOC_DAPM_MIXER("Power Amplifier", SUN4I_CODEC_ADC_ACTL, - SUN4I_CODEC_ADC_ACTL_PA_EN, 0, + SND_SOC_DAPM_MIXER("Power Amplifier", SND_SOC_NOPM, + 0, 0, sun4i_codec_pa_mixer_controls, ARRAY_SIZE(sun4i_codec_pa_mixer_controls)), SND_SOC_DAPM_SWITCH("Power Amplifier Mute", SND_SOC_NOPM, 0, 0, -- 2.17.1 Than, power amplifier was off by default (DAPM is responsible for turning on various widgets), so I've manually edit the register bit in the probe function From 78fbd23b3eae8e442e5a7d67814a961bd5579e73 Mon Sep 17 00:00:00 2001 From: Marjan Trexom <****> Date: Tue, 8 Sep 2020 16:01:00 +0200 Subject: [PATCH] Manually Enable PA in probe --- sound/soc/sunxi/sun4i-codec.c | 23 +++++++++++++++++++++++ 1 file changed, 23 insertions(+) diff --git a/sound/soc/sunxi/sun4i-codec.c b/sound/soc/sunxi/sun4i-codec.c index 018cc9656..db6b1f18d 100644 --- a/sound/soc/sunxi/sun4i-codec.c +++ b/sound/soc/sunxi/sun4i-codec.c @@ -224,6 +224,26 @@ /* TODO H3 DAP (Digital Audio Processing) bits */ +/* register bit change*/ +int codec_wrreg_bit(void __iomem *reg, unsigned int bit, unsigned int bvalue) +{ + int change; + unsigned int old, new, mask, value; + + mask=0x1<<bit; + value=bvalue<<bit; + + old = readl((reg)); + new = (old & ~mask) | value; + change = old != new; + + if (change){ + writel((new),(reg)); + } + + return change; +} + struct sun4i_codec { struct device *dev; struct regmap *regmap; @@ -1701,6 +1721,9 @@ static int sun4i_codec_probe(struct platform_device *pdev) goto err_assert_reset; } + codec_wrreg_bit(base+SUN4I_CODEC_DAC_DPC, SUN4I_CODEC_DAC_DPC_EN_DA, 0x1); + codec_wrreg_bit(base+SUN4I_CODEC_ADC_ACTL, SUN4I_CODEC_ADC_ACTL_PA_EN, 0x1); + return 0; err_assert_reset: -- 2.17.1 Now you can enjoy real-time audio on your A13 without annoying fade in!

Hello, I'm trying to writing a patch for /gpu/drm/panel/panel-simple.c in order to make my 3.5" ampire works with my Olimex's A13 som board. I've correctly set display frequencies and parameters, and the image is displayed correctly... ...except for some random pixel wich sometimes changes color. I dig out with my oscilloscope and find that RGB data changes on clock's rising edge. Display's datasheet request data to be changed on falling edge insted. So, I've tryied to set the property, but nothing changed: data still changes on rising edge. Here's the core of my patch: diff --git a/drivers/gpu/drm/panel/panel-simple.c b/drivers/gpu/drm/panel/panel-simple.c +static const struct display_timing ampire_am320240l9tnqw_00h_timing = { + .pixelclock = { 6500000, 6500000, 6500000 }, + .hactive = { 320, 320, 320 }, + .hfront_porch = { 20, 20, 20 }, + .hback_porch = { 68, 68, 68 }, + .hsync_len = { 10, 10, 10 }, + .vactive = { 240, 240, 240 }, + .vfront_porch = { 4, 4, 4 }, + .vback_porch = { 18, 18, 18 }, + .vsync_len = { 1, 1, 1 }, + .flags = DISPLAY_FLAGS_PIXDATA_NEGEDGE, +}; + +static const struct panel_desc ampire_am320240l9tnqw_00h = { + .timings = &ampire_am320240l9tnqw_00h_timing, + .num_timings = 1, + .size = { + .width = 70, + .height = 53, + }, + .bus_format = MEDIA_BUS_FMT_RGB888_1X24, + .bus_flags = DRM_BUS_FLAG_PIXDATA_NEGEDGE, +}; + I've tryied many combination of flags, but nothing changes. I've tryied changing other parameters (like porches) and I can see the changes, so I know that driver loads this timings. Can someone please help me find out what I'm doing wrong? ### armbian-release: # PLEASE DO NOT EDIT THIS FILE BOARD=olimex-som-a13 BOARD_NAME="SOM-A13" BOARDFAMILY=sun5i BUILD_REPOSITORY_URL=https://github.com/olimex/build BUILD_REPOSITORY_COMMIT=65b71245 VERSION=5.92 LINUXFAMILY=sunxi BRANCH=next ARCH=arm IMAGE_TYPE=user-built BOARD_TYPE=csc INITRD_ARCH=arm KERNEL_IMAGE_TYPE=zImage uname -r 5.0.21-sunxi P.s. I know this is not the last version, but is the only one that seem to work with olimex's patches.

Ok, it seems like the problem lays in the hardware. In latest kernel's sun4i-codec driver I found this: static int sun4i_codec_spk_event(struct snd_soc_dapm_widget *w, struct snd_kcontrol *k, int event) { struct sun4i_codec *scodec = snd_soc_card_get_drvdata(w->dapm->card); gpiod_set_value_cansleep(scodec->gpio_pa, !!SND_SOC_DAPM_EVENT_ON(event)); if (SND_SOC_DAPM_EVENT_ON(event)) { /* * Need a delay to wait for DAC to push the data. 700ms seems * to be the best compromise not to feel this delay while * playing a sound. */ msleep(700); } return 0; } I've added the same msleep(700) to my kernel via userpatches and I solved the problem. (I know I should use the last kernel version, but I'm bounded to olimex's patches to make armbian work on A13, and they didn't update them)

Hello, I've recently build a custom image for Olimex's A13 SOM (details here) ### armbian-release: # PLEASE DO NOT EDIT THIS FILE BOARD=olimex-som-a13 BOARD_NAME="SOM-A13" BOARDFAMILY=sun5i BUILD_REPOSITORY_URL=https://github.com/olimex/build BUILD_REPOSITORY_COMMIT=65b71245 VERSION=5.92 LINUXFAMILY=sunxi BRANCH=next ARCH=arm IMAGE_TYPE=user-built BOARD_TYPE=csc INITRD_ARCH=arm KERNEL_IMAGE_TYPE=zImage uname -r 5.0.21-sunxi I am able to play audio via DAC output using alsa. What I've noticed is that when I play and audio file for the first time (in the last 5 seconds) it starts very quiet, than the volume increases to a normal loudness. If I play the same file again immediately after its end the volume is normal. After 5 seconds without playing anything I hear a "click" from the speaker and after that, if I play a file, it starts again very quiet. I tried with both mplayer and mpg123, so I think the problem is in alsa settings. I've searched about alsa standby, but I didn't find anything. Can someone help me? In the attachments my /var/lib/alsa/asound.state asound.state

hello @Werner, first of all thank you for your reply. Yes, I'm aware of it. I was writing here to get help, not to blame anyone (as I said, I'm new to armbian). I check out compile.sh script in build directory and understand how it works. As you said, I see that I need to enable some options in linux-sunxi-default.config, and that the best way to do it is by creating a new file in userpatches called linux-sunxi-default.config. (probably would be also better creating a patch in userpatches/kernel/sunxi-next-olinuxino, but I've never had time to test it now...). So, I've copied old config/kernel/linux-sunxi-default.config to userpatches/linux-sunxi-default.config and changed: #CONFIG_USB_NET_SMSC95XX is not set to CONFIG_USB_NET_SMSC95XX=m for adding usb/eth driver and #CONFIG_USB_VIDEO_CLASS is not set to CONFIG_USB_VIDEO_CLASS=m for adding webcam drivers. Hope this will help other newbies

Hello, I'm new to Armbian. I've recently tried Olimex's image for a13 (https://github.com/OLIMEX/build). I saw (and read) on armbian's guide that there's the possibility to customize images build. I need to add two specific drivers (smsc95xx for my eth interface and uvcvideo for my webcam) to kernel. I can find their sources in build\cache\sources\linux-mainline\linux-5.0.y\drivers, but they are not listed in various "modules.order" files (ok, so that's why my devices doesn't get loaded). If I want to add these modules to kernel the only way is to create a patch for "modules.order" in userpatches\kernel (if it's the right directory), or there's a cleaner way (like a .config file) to add them?

Hello, I'm using Armbian (kernel version 5.0.21-sunxi) on an Olimex a13 SOM. I'm trying to implement wiegand interface on GPIO pins, that means that I have to fire interrupts on 50uS pulses. I solved my problem with writing down a driver capturing edge triggered inputs. So, with some readers (200uS pulses, 1.5ms between pulses) i can get all data, but with other readers (e.g. 100uS pulse, 500uS between pulses) I miss some interrupts (e.g. I have a wiegand42 reader and sometimes I get 41 interrupts, sometimes I get 39 or 36). I read that kernel fires new interrupt only when the previous interrupt function has returned, so I tested it with just adding a "counter++" and "if (counter>41)" and I'm still not able to get every interrupt. I found on forums that allwinner a13 has an external 24MHz oscillator (Q1 in this schematic https://www.olimex.com/Products/SOM/A13/A13-SOM-512/resources/A13-SOM512_sch.pdf ) that can be configured to trigger interrupt events faster. I tried to add to kernel sources patch found in here (https://linux-sunxi.org/External_interrupts), but gives me error while kernel compiles. I've also read this topic ( https://forum.armbian.com/topic/4787-gpio-pa19-hardware-interrupts/?tab=comments#comment-36517 ), but I can't figure out how to enable 24MHz oscillator in device tree (I tried "input-debounce = <0x1>;" on "pinctrl@1c20800" without result). Could someone help me in enabling 24MHz oscillator for firing external interrupts? Here's my pinctrl section of device tree: