jock

@Sergei Steshenko Apparently the purple line and audio issues with HDMI are gone in kernel 5.1! Here is an experimental image (Armbian 5.88 + Kernel 5.1.7) if you want to give it a chance.

Yeah, that's an issue I partially addressed and it is related to the peculiar PMU integrated circuit controlling the power of the SoC. Without a reference implementation, it is hard to get the job done.

I'll take a look to the script. Never dig into, just tried a couple of times to check if it was working on our tv box. By the way, there are more options for your setup: use the nand-sata-install script to install armbian on the internal eMMC and then burn a pristine armbian image directly on the hard drive. This way u-boot gets installed in the embedded flash: it is programmed to first check for bootable SD card, then for bootable USB device and, if nothing can be found, tries to boot from embedded flash. (Remember to remove the bootable SD card from the tv box slot) The get a swap partition, you can easily use a tool like gparted and edit the partitions table of the hard drive later. ext4 partitions can easily shrink with no data loss.

Yeah I remember the workaround (it was about editing pulseaudio conf files). This other solution is not a workaround: it's about of making ALSA aware of HDMI and SPDIF devices. This information is then used by Pulseaudio to properly label the devices. It's much better and it is the proper way to do it. The previous workaround is not needed anymore. BTW, ALSA and Pulseaudio do different things. ALSA is an abstraction layer over the hardware, but also has some "software" capabilities, like support for plugins, mixing, etc... Pulseaudio is an audio server which has the same software capabilities of ALSA, but also does something more. It looks to me that ALSA is quite messy, it just does too many things without a clear separation of concepts. I studied it a bit to grasp the bits to understand how to solve the label problem, still I don't understand how it is possible the solution I found works

Mmmh, truly I don't know exactly. I guess the script does everything to setup the whole thing, but I never tried.

That's an HDMI problem, so optical output is always fine (maybe you're interested in giving the sound devices the right names, check this) The bug, as far as I know, is not being actively worked on. @Myy imported some patches that tweaked the HDMI clocks which got into newer kernels, but the problem was not solved.

@Sergei Steshenko Yeah, the bug of the purple line appears in text mode too, because (I guess) it's somewhere in the HDMI kernel driver, so it is not happening in X only. I don't really remember, but it was there (sort-of) in the legacy 4.4 rockchip kernel too, but I'm not totally sure. It's curious your monitor supports only one mode. Usually monitors expose via EDID a list of modes and one mode is "preferred", which is usually the native resolution. Did you try your monitor on a regular PC to check if it really supports just one mode? @pro777 had issues with resolution modes because his box was not reporting any EDID at all, maybe yours has the same issue. Both your issues with the refresh rate and sound are quite strange: changing the refresh rate should not make X crash at boot. Sometimes, expecially with older (<4.20) kernels, it may happen that sound disappears even without the purple line: my guess is that it is the very same problem in the HDMI driver of the purple line, something like bad clocks or bad parameters.

@Sergei SteshenkoThe purple line is a bug in the kernel HDMI driver. It appears in all rk3288 devices. Plugging and unplugging is a solution, but you can also turn the monitor off and on or use xrandr to switch resolution, for example: xrandr --output HDMI-1 --mode 1920x1080 The purple line appars every other time HDMI change status, so a software solution with xrandr you have to switch to another resolution, then to a third resolution and finally back to your native resolution. You can easily make a script to automatize the workaround.

Hello, unfortunately there isn't a dual boot feature: the main reason is that the u-boot version originally shipped with the box is from 2014. It is quite outdated and it is able to boot Android boot images only. When I started the project I made the design choice to support mainline u-boot to best support Armbian. In theory the original u-boot can boot from an external SD card, but the kernel, initramfs and other bits should be "mangled" to fit into an Android boot image, something I never experimented with. The bootlog is available only from the serial port, so no way to show it up on screen. If you take a look to the Armbian downloads page you can download the CSC official image and found the instructions to backup and restore the existing eMMC image.

Normally the media script should provide the EGL/OpenGL ES proprietary libraries as substitutes for mesa EGL/OpenGL ES implementation, so once you install the media script you won't be bothered with updates anymore. This at least happens with the media script for RK3288, which I am happily using. Of course if you install the Mali libs manually, they will be overwritten by updates with software mesa implementation. BTW, gl4es works fine: I'm playing various AAA old titles (Quake, Quake 2, Quake III, Jedi Outcast, Jedi Academy) on RK3288 and games are running very well with Mali proprietary blobs.

@gen2thomas AFAIK the tinkerboard analog output is handled by an internal device attached to the bus, but SPDIF and HDMI audio devices are handled by the SoC itself, so it is not proper to describe them as "USB-Audio" in asound.conf I have a rk3288 tvbox without the analog part, and found (by trial and error) a solution the the pulseaudio naming with this asound.conf: https://github.com/paolosabatino/armbian-build/blob/224c6ed3c1599263bfb4c4a2f21584eb5b73f940/packages/bsp/rockchip/asound.conf It works flawlessy for me, but it is required to change the simple-audio-card,name property in the tinkerboard device tree from rockchip,tinker-codec (which I think is "improper", can't find any other audio device with this naming style) to DW-I2S-HDMI (for HDMI) and SPDIF (for SPDIF). Dunno if it solves your passthrough problem or whatever, but may be a step in the right direction (I'd like to submit a merge request soon) See also:

Some people noticed that Pulseaudio mixes is showing "Built-in Audio" for all the audio devices of the SBCs. I investigated and found that the issue is related to ALSA: the devices are not really exposed by their real hardware connection (HDMI, SPDIF, ...) but just as "hw" devices. Pulseaudio is interpreting this as built-in audio because does not know anything else of the device. I'm no ALSA expert at all, copied some already existing configuration files without really understanding what I did, I found a solution. To solve the problem with SPDIF and HDMI you need to place the following two configuration files in /usr/share/alsa/card. Call the first one SPDIF-OUT.conf and the second one HDMI-OUT.conf # configuration for SPDIF connections which just expose the # audio out device <confdir:pcm/iec958.conf> SPDIF-OUT.pcm.iec958.0 { @args [ CARD AES0 AES1 AES2 AES3 ] @args.CARD { type string } @args.AES0 { type integer } @args.AES1 { type integer } @args.AES2 { type integer } @args.AES3 { type integer } type hw card $CARD } # configuration for HDMI connection which just expose the # audio out device <confdir:pcm/hdmi.conf> HDMI-OUT.pcm.hdmi.0 { @args [ CARD DEVICE CTLINDEX AES0 AES1 AES2 AES3 ] @args.CARD { type string } @args.DEVICE { type integer } @args.CTLINDEX { type integer } @args.AES0 { type integer } @args.AES1 { type integer } @args.AES2 { type integer } @args.AES3 { type integer } type hw card $CARD } Then discover your audio device names: $ aplay -l **** List of PLAYBACK Hardware Devices **** card 0: SPDIF [SPDIF], device 0: ff8b0000.sound-dit-hifi dit-hifi-0 [] Subdevices: 1/1 Subdevice #0: subdevice #0 card 1: DWI2SHDMI [DW-I2S-HDMI], device 0: ff890000.i2s-i2s-hifi i2s-hifi-0 [] Subdevices: 0/1 Subdevice #0: subdevice #0 Mine are "SPDIF" and "DW-I2S-HDMI" - these two strings come from the device tree so each board may have their own peculiar device names. And finally edit the file /usr/share/alsa/conf/aliases.conf adding the cards to the list, to get something like this (I just added the SPDIF and DW-I2S-HDMI device at the bottom of the list to alias to the right cards): # # Define aliases for various drivers # YMF724 cards.YMF744 YMF724F cards.YMF744 YMF740 cards.YMF744 YMF740C cards.YMF744 YMF754 cards.YMF744 CMIPCI cards.CMI8338 CMI8738 cards.CMI8338 CMI8738-SWIEC cards.CMI8338-SWIEC CMI8738-MC4 cards.CMI8738-MC6 'E-mu APS' cards.EMU10K1 'GUS MAX' cards.GUS 'GUS ACE' cards.GUS 'GUS Extreme' cards.GUS 'AMD InterWave' cards.GUS 'Dynasonic 3-D' cards.GUS 'InterWave STB' cards.GUS au8810 cards.AU8810 au8820 cards.AU8820 au8830 cards.AU8830 Prodigy71 cards.Aureon71 Prodigy71LT cards.Aureon71 Prodigy71HIFI cards.Aureon71 Aureon71Univ cards.Aureon71 VIA82XX-MODEM cards.ICH-MODEM 'MPU-401 UART' cards.MPU-401 'VX222/Old' cards.VX222 'VX222/v2' cards.VX222 'VX222/Mic' cards.VX222 'CMI8330/C3D' cards.CMI8330 'SB AWE' cards.SBAWE 'SB Pro' cards.SBPro 'PMac Burgundy' cards.PMac 'PMac DACA' cards.PMac 'PMac Tumbler' cards.PMac 'PMac Snapper' cards.PMac 'PMac Screamer' cards.PMac 'PMac AWACS' cards.PMac 'PMac Toonie' cards.PMacToonie AppleOnbdAudio cards.PMacToonie 'USB US-X2Y' cards.US-X2Y 'Serial MIDI' cards.SerialMIDI 'Prodif Plus' cards.ProdifPlus ESM1 cards.ES1968 ES1978 cards.ES1968 Allegro cards.Maestro3 Canyon3D-2 cards.Maestro3 Azalia cards.HDA-Intel aaci-pl041 cards.AACI AV66 cards.CMI8788 AV100 cards.CMI8788 AV200 cards.CMI8788 CMI8786 cards.CMI8788 CMI8787 cards.CMI8788 SPDIF cards.SPDIF-OUT DW-I2S-HDMI cards.HDMI-OUT <confdir:pcm/default.conf> <confdir:pcm/dmix.conf> <confdir:pcm/dsnoop.conf> Now running aplay -L you should see, among the other generic devices, spdif and HDMI devices with the proper device tag: $ aplay -L ... iec958:CARD=SPDIF,DEV=0 SPDIF, IEC958 (S/PDIF) Digital Audio Output ... hdmi:CARD=DWI2SHDMI,DEV=0 DW-I2S-HDMI, HDMI Audio Output ... Then reboot (or run pulseaudio -k from a shell as non-root user) and finally pulseaudio mixer should show this: I'm eager to understand what the hell I did, but also I would like to transform the thing in something that works directly from asound.conf instead of having cards configuration files in alsa directories, so any correction and explanation is very welcome

Hello, I would like to tinker with a wayland-based desktop environment. What are the basics I need to know and what are the steps to setup it on armbian? Thanks in advance

Sorry, but it won't work: rk3229 it a totally different SoC which requires different kernel drivers and thus different device trees etc... etc... Also rk3229 is not supported by mainline kernel and rockchip does not provide any sort of opensource documentation or source code for it. You may try to tinker with the original android kernel: booting a debian stretch using that kernel may be at hand, but surely it may require quite some work and knowledge.

rkdeveloptool, as far as I can remember, can't backup the existing bootloader. When you read the whole eMMC using rkdeveloptool, it skips the first 4 megabytes where the bootloader resides. I think other tools, like the AndroidTool for Windows, can backup the existing bootloader too. You could backup manually the bootloader partition accessing a running android installation via serial port. rk3288_ubootloader_v1.01.06.bin came from the original rockchip rkbin repository, now removed but mirrored on github by armbian people. It is a collage of some rockchip binaries and an ancient u-boot binary into a single file. I don't think backing up the bootloader worth it, as the one provided by rockchip looks the same as the one installed on the device. Also if you want to run armbian, the original bootloader is replaced by a recent and up-to-date mainline u-boot.

maybe sudo depmod -a can be useful to refresh the modules depencies

Are you sure you have NAND chip? Usually tv boxes have standard eMMC chips which should be supported by latest mainline kernels: linux-meson.com

AFAIK 8189ETV driver is not in armbian for meson64 and neither in mainline kernel at the moment. You have to compile it yourself from sources you can find here: https://github.com/jwrdegoede/rtl8189ES_linux You may also integrate it into armbian build system as a patch for the kernel, so when you build your armbian distro you also compile the driver as module: I did it as an experiment in my own armbian fork for mxq-s905-v20 tv box board (which is commercially known as Nexbox MXQ Pro, with S905 SoC) and it works very well. You may try to use this patch, which should be enough to integrate the driver into the kernel during armbian building. Just put the patch in the same directory (patch/kernel/meson64-next) and you should go. If you want to compile the driver yourself on the running system instead, don't forget to install the linux headers first. Side note: the driver works flawlessy with 4.19 kernel, but you report your next flavour is using 5.0 which looks strange to me since 5.0 should be dev flavour. Maybe the driver works on 5.0 too, but I never tried

@bambam Are you still connected with wifi? 3Mb/s over wifi is respectable for a basic 802.11n wifi link, considering also that SMB has some amount of traffic overhead. The iperf log you posted, looks like it is over local loopback, since 4Gbit/s seems way too much to me...

The kernel log is quite explicit: the gpio-rc-recv kernel driver is failing to use the gpio pin. Most probably the gpio pin is not correctly configured in the device tree so the driver does not know which gpio pin to use.

Hello @hexdump, I'm glad you find my work useful! About your questions: 1. I programmed a small userspace program that reads the memory controller memory-mapped space to get most of the timings and settings. In the u-boot device tree source file I commented the exact location where the bits are extracted (see here). This stack overflow post may be useful for you, also I distinctly remember had to recompile kernel with CONFIG_STRICT_DEVMEM option disabled to access memory-mapped device memory. 2. low chance, mostly because q8 uses LPDDR2 and other tvboxes uses DDR3. It is very unlikely that a board works and works stable with the timings of another board. By the way, for Q8 the timings in the device tree file are not used actually. 3. as long as you get the memory timings, u-boot should boot fine. For Q8 boards I must use the rockchip binary bootloader (see here) that does memory initialization and timings autodection, so the timings in the DTB file are not used at all. I put them there for completeness and because I wanted to explore the possibility to add LPDDR2 support to u-boot. For your board, you can either use the rockchip binary bootloader or directly start from u-boot, because u-boot can do memory initialization for DDR3 memory, but you have to supply the memory timings yourself via DTB-file because u-boot can't do timings autodetection.

I don't have a MiQi, but AFAIK armbian-config should already do what you ask

I can confirm that latest armbian with next kernel (4.19) on rk3288 works flawlessy with prolific USB-to-serial adapters: 15567.072909] usb 2-1: new full-speed USB device number 2 using dwc2 [15567.281604] usb 2-1: New USB device found, idVendor=067b, idProduct=2303, bcdDevice= 3.00 [15567.281616] usb 2-1: New USB device strings: Mfr=1, Product=2, SerialNumber=0 [15567.281623] usb 2-1: Product: USB-Serial Controller [15567.281630] usb 2-1: Manufacturer: Prolific Technology Inc. [15567.318362] usbcore: registered new interface driver pl2303 [15567.323408] usbserial: USB Serial support registered for pl2303 [15567.323550] pl2303 2-1:1.0: pl2303 converter detected [15567.327312] usb 2-1: pl2303 converter now attached to ttyUSB0 I use it daily with Arduino IDE to develop and push things to ESP8266 and works without issues.

Looking for No currently active connector found on google tells that it is probably a message coming from kernel DRM. Maybe the 7" LCD screen is not advertising itself correctly to the HDMI interface, or there's a bug in the DRM kernel code which prevents it working correctly. I had to deal with a couple of Full-HD industrial panels (via DVI) and they usually refuse to display anything when they are not configured exactly with the resolution and refresh rate they expect. I think this is a remote possibility, but supplying EDID manually may interfere somehow. You can read back EDID from the display using get-edit tool (see this for an example), at least you can understand if the display is advertising its modes correctly: get-edid -b 5 | parse-edid

Pretty interesting device! I see from the Internet it has an embedded SATA slot, RTC, 802.11ac wifi, HDMI IN and it has Mali-T860 GPU on a 4-core A53 design, where all other chinese propose outdated GPUs Also the "legacy" kernel looks recent enough, which is nice to start with. Congratulations and keep it up edit: bringing u-boot to boot is one of the most difficult tasks, I faced it when I had to deal with it and Chiptrip Q8 RK3288 (xt-q8l-v10) tv box because I had to use the vendor bootloader and chaining it to u-boot SPL which, in turn, boot the real u-boot.