TRS-80

I too thought that it was important to file bug reports when things aren't working.  Open source is always a sort of beta test and one way people with less skills than developers could contribute is identifying problems, providing details, answering questions and testing solutions.
 
No one is "demanding" anything gets fixed - this is open source.  It is important, though, that known problems are identified and confirmed by other people so other users that run into the same problem in the future will know and can act accordingly.
 

Windows / Microsoft tried hard to kill GNU/Linux and F/LOSS for many years.  They don't deserve any Nice Things, IMO.  Let them die off already.
 
And ESXi is proprietary software.  Which also does not therefore deserve any community support, IMO.

Beside your current problem, they are super cool, anyway!  I mean, if you are into SBC, maybe you are (or will get) into these, too.  Many of us are doing Home Automation stuff, as well, with our SBCs! 
 
There is a whole world of different radios you can use, but for this the Wi-Fi based ones (searching Tasmota will get you started, but there are others, too) will probably fit your need best.
 
Wi-Fi switches (Tasmota especially) are even quite easy to get working these days, there is a pretty big community around them, etc.
 

Try this one https://gist.github.com/olehs/1cd3e5ddf45066380df68a70d6f8462a
You only need spi-add-cs1 overlay enabled
 

@user-2020-12-7,
 
To be honest this has been bothering me ever since your OP.  FWIW I had put this in my own personal issue tracker to follow up on until now.
 
So when some discussion came up today in IRC about this, and another user confirm that it's working again (I specifically ask him about screen), it made me think about this again.
 
I know it's stated in other thread you linked already, but apparently there was some issue with newer kernel, and therefore PineBook A64 was rolled back to legacy (5.4.y) in the meantime, which works well enough apparently.  As I am sure you are aware by now.
 
However I realize your OP was more about the term "Supported" on the download page.  I think misunderstanding may have come from not understanding what "Supported" means in terms of Armbian, so I will try to expand a bit on what has already been written at that link.
 
Supported is a more general and longer term condition, based on a lot of factors mentioned in linked article above.  And so, just because something breaks (even something so important as display on a laptop) does not mean that device suddenly becomes "not Supported."  If situation were impossible, or constant breakage, etc. then that would be a different story.
 
So I hope I help clear that up a bit and again I thank you for your concern and your report.  Cheers!
 
I am taking the liberty to mark my own post as solution in this case.
 
 

Of course not!  But they are about to... 
 
All jokes aside, I talk to anyone who seems even the slightest bit interested about the importance of Free Software every chance I get.  So my family have all heard the words of our Lord and Saviour rms many times by now. 
 
Second order shipped yesterday.  Projected to arrive 12/28.  It seems like they suddenly got busy.  I guess I am not the only one ordering "last minute" holiday gifts.
 
They contacted me about third order, because some colors (black) of design (penguin) were too close to item they were being printed on (dark blue).  Which I thought was nice of them.  Third order have not shipped as of time of writing (but I placed it one day after first two, and there was that confirmation delay).

If anyone is interested: I designed a new cover instead of the acrylic plate. I broke it because I tried to drill a hole into it to get access to the power pins:
 
I made a new one in Fusion 360 to be 3D-printed or laser cut: https://www.thingiverse.com/thing:4501621
With it you get access to all pins (power, PCIe, GPIO, serial and SPI) and the reset button. The picture is of version 1. The newer version on thingiverse has larger cutouts and holes.
 
 
 
 

I think so, I did a fresh install on the sd card from this file - Armbian_20.11.4_Helios64_buster_current_5.9.14.img.xz
 
Here is the dmesg output from after reboot. Can't access the previous boot records though. This one shows a lot of eth1 errors and warnings, but it hasn't crashed yet.
 
 
I tried to put the output in both spoiler and code. Hope it works.

Thank you very much for your work. I've been following your other thread once your tool's been one of the only ways I found to use Kodi on a RockPro64 in a server, without have to necessarily use LibreELEC.
 
I really appreciate what you've been doing!

Essentialy, yes. VPU is identical in last generation SoC's RK3328 and RK3399, lacking VP9 capabilities in the older RK3288.
 
GPU, on the other hand, is very similar in the high-end SoC's (RK3288 and RK3399), much faster and supporting OpenGLES 3 and OpenCL 1.2. The weaker one, RK3328, supports only GLES2 and no OpenCL, plus no ISP camera either.
 
There is also a parallel solution for Odroid XU4, I will document it soon. In that case, VPU decoding capabilities are reduced (no 4K, only 1080p). But GPU is the strongest one, as well as VPU encoding.

Hi robertoenr
 
It's simple like that. Follow guide of SteeMan, but NO NEED to hold Reset while booting, DO NOT PRESS OR HOLD ANYTHING while booting and DO NOT plug USB Keyboard while booting, you can plug USB Keyboard later, after see login screen
 
 

IT'S FINALLY HERE...

THE OFFICIAL ROCKCHIP-LEGACY MULTIMEDIA INTEGRATION
 
After two years of using a separate script to enable the multimedia features in RK3288/3328 Legacy Kernel, the whole framework has been incorporated to the official Armbian packaging system. The choice distro for this integration is Debian Buster (see FAQ at the end of this post about the reasons).
 
I. Installation
Download a Armbian Buster Legacy Desktop image for your board, and install it with the standard Armbian method. Install the complete multimedia solution with sudo apt update && sudo apt upgrade sudo apt install media-buster-legacy-tinkerboard --install-recommends ## Or ## sudo apt install media-buster-legacy-rk3328 --install-recommends The switch "--install-recommends" will add the whole Kodi binary addons collection (retro-gaming cores, music visualizations, screensavers, additional media decoders/encoders, vfs, etc.), plus the GLES-to-OpenGL wrapper "gl4es".  
II. Features
Accelerated GLES/EGL X desktop: No action needed. Accelerated Chromium, with WebGL and video display acceleration: No action needed Desktop video player capable of smooth 4K HEVC-HDR: Use the "Rockchip Gst Player" from the Multimedia menu, or choose it with right-click on the media file. Command-line 4K playing is also possible with "gst-play-1.0 --videosink=kmssink". RKMPP-accelerated MPV: Use normally for standard operation (windowed with mouse-operated GUI). For fullscreen, keyboard-operated mode, use the command line switch "--gpu-context=drm" (this will allow you to play smooth 4K).
        - See instructions below, in the next post, for playing Youtube videos up to 4k with this MPV. ISP Camera with real-time h.264/1080p HW encoding (RK3288 only): Using the Gstreamer Plugin. Check this wiki for instructions on how to use it. Most of it applies to Armbian, except for the selection of ov5647/imx219 camera, which must be done using DT overlays. OpenCL 1.2 support (RK3288 only): It will be fully functional, no further action needed. You can download some tests and examples from this link. Kodi 18.9 Leia with full RKMPP+GBM acceleration, 4K-HDR capable: You can start it from Light DM menu as your user account: 
 
Alternatively, you can also run it as a system service with these command lines: sudo systemctl disable lightdm sudo systemctl enable kodi-gbm sudo reboot  
Full collection of Kodi binary add-ons: Includes retrogaming cores, media encoders and decoders, PVR, screensavers, vfs and audio visualizations. They are all installed with the package "kodi-addons-full", but are disabled by default. They need to be enabled individually within the Kodi GUI. OpenGL 2.1 support through the gl4es wrapper: It is installed with the package "gl4es", with no further action needed.  
III. Sources
This is the list of the sources used for the packages:
 
IV. FAQ
¿Why did you use Debian Buster as a base for this implementation?
It was the most appropriate for several reasons. Upstream Rockchip-Linux developers use Debian buster, so the software could be ported with less modifications than if we chose a different distro. Besides, it is a completely stable distro, unlike Bullseye, which is a moving target as of today. It also has Chromium as a package, unlike Focal that uses snap instead. For last, it has a good backports repo, with several libs that would otherwise need to be compiled and maintained if we chose, for example, Focal.
  ¿Why Legacy instead of Mainline?
This is an implementation based on the vendor's BSP kernel. It has been tested and is reliable, which many people will prefer rather than having a bleeding-edge, less stable implementation. In addition to that, Mainline upstream multimedia support is still a WIP, and lacks many features that are only present on Legacy kernels.
  ¿Will you add new features to this implementation?
No, this implementation will only receive bug fixes if necessary. From now on, all multimedia work will be focused on Mainline and recent distros (like Focal or Bullseye). All new features will go there.

I just posted the announcement for the official Armbian Rockchip Legacy Multimedia Framework. As you can see on the announcement, I say that from now on all multimedia work will be done in Mainline.
 
That means integrating GPU and VPU acceleration into the official Armbian repos. The timeline is for next Armbian release, in February, if possible.
 
As of today, I am planning to include Kodi and MPV. So if anybody wants to help, it will be much appreciated. 

IT'S FINALLY HERE...

THE OFFICIAL ROCKCHIP-LEGACY MULTIMEDIA INTEGRATION
 
After two years of using a separate script to enable the multimedia features in RK3399 Legacy Kernel, the whole framework has been incorporated to the official Armbian packaging system. The choice distro for this integration is Debian Buster (see FAQ at the end of this post about the reasons).
 
I. Installation
Download a Armbian Buster Legacy Desktop image for your board, and install it with the standard Armbian method. Install the complete multimedia solution with sudo apt update && sudo apt upgrade sudo apt install media-buster-legacy-rk3399 --install-recommends The switch "--install-recommends" will add the whole Kodi binary addons collection (retro-gaming cores, music visualizations, screensavers, additional media decoders/encoders, vfs, etc.), plus the GLES-to-OpenGL wrapper "gl4es".
 
II. Features
Accelerated GLES/EGL X desktop: No action needed. Accelerated Chromium, with WebGL and video display acceleration: No action needed Desktop video player capable of smooth 4K HEVC-HDR: Use the "Rockchip Gst Player" from the Multimedia menu, or choose it with right-click on the media file. Command-line 4K playing is also possible with "gst-play-1.0 --videosink=kmssink". RKMPP-accelerated MPV: Use normally for standard operation (windowed with mouse-operated GUI). For fullscreen, keyboard-operated mode, use the command line switch "--gpu-context=drm" (this will allow you to play smooth 4K).
        - See instructions below, in the next post, for playing YouTube videos up to 4K with this MPV.
ISP Camera with real-time h.264/1080p HW encoding: Using the Gstreamer Plugin. Check this wiki for instructions on how to use it. Most of it applies to Armbian, except for the selection of ov5647/imx219 camera, which must be done using DT overlays. OpenCL 1.2 support: It will be fully functional, no further action needed. You can download some tests and examples from this link. Kodi 18.9 Leia with full RKMPP+GBM acceleration, 4K-HDR capable: You can start it from LightDM menu as your user account: 


Alternatively, you can also run it as a system service with these command lines: sudo systemctl disable lightdm sudo systemctl enable kodi-gbm sudo reboot Full collection of Kodi binary add-ons: Includes retrogaming cores, media encoders and decoders, PVR, screensavers, vfs and audio visualizations. They are all installed with the package "kodi-addons-full", but are disabled by default. They need to be enabled individually within the Kodi GUI. OpenGL 2.1 support through the gl4es wrapper: It is installed with the package "gl4es", with no further action needed.  
III. Sources
This is the list of the sources used for the packages:
 
IV. FAQ
¿Why did you use Debian Buster as a base for this implementation?
It was the most appropriate for several reasons. Upstream Rockchip-Linux developers use Debian buster, so the software could be ported with less modifications than if we chose a different distro. Besides, it is a completely stable distro, unlike Bullseye, which is a moving target as of today. It also has Chromium as a package, unlike Focal that uses snap instead. For last, it has a good backports repo, with several libs that would otherwise need to be compiled and maintained if we chose, for example, Focal.
  ¿Why Legacy instead of Mainline?
This is an implementation based on the vendor's BSP kernel. It has been tested and is reliable, which many people will prefer rather than having a bleeding-edge, less stable implementation. In addition to that, Mainline upstream multimedia support is still a WIP, and lacks many features that are only present on Legacy kernels.
  ¿Will you add new features to this implementation?
No, this implementation will only receive bug fixes if necessary. From now on, all multimedia work will be focused on Mainline and recent distros (like Focal or Bullseye). All new features will go there.

Did you create a bootable microSD card?
The U-Boot image is not on SPI yet - so it needs it will look for it on the SD and eMMC - if you haven't written the image on either of these you won't get any output on the console.

Throw away this intel shit. use the native build on rk3399. This is faster and without any stupid Trojans in Intel x86.
 
You use the source code from Friendlyelec , they are significantly worse. It is better to use the ones that go for rockchip64-legacy (there are also sources for analog audio 8323\8388)
 
https://github.com/150balbes/build/blob/armbian-tv/config/boards/station-p1.conf#L3
https://github.com/150balbes/build/blob/armbian-tv/config/sources/families/include/rockchip64_common.inc#L51
 
And the kernel config that WiFi works with.
https://github.com/150balbes/build/blob/armbian-tv/config/kernel/linux-rockchip64-p1-legacy.config
 
PS I wanted to create a PR with the change, but so far I have suspended it until we discuss and agree on these changes.

Since I had collected as much information from the broken AC adapter brick as possible, I decided to cut off the connector.  This revealed only 2 wires which meant there is only one possible configuration.  Both pins 1 and 2 must be 12V.
 
I grabbed one of my old computer power supplies, and fashioned a terminal connector to tie the 2 wires to the 12V rail and ground.  I verified the 4 pins on the connector, plugged it in and my Helios4 booted up without any issues.  I'm still waiting about a week and I'll swap out my 500W temporary PSU when it arrives.
 
For anyone with similar power issues, hopefully this thread may be helpful to them.
 
 
Here's the appropriate pinouts of the 4-pin AC adapter required for Helios 4 (see previous diagram for pin locations):
PIN 1: +12
PIN 2: +12
PIN 3: GND
PIN 4: GND

Rare mistake by Igor!
 
In few years I been lurking here, this is only time I can recall such thing happening.  Of course everyone make mistakes, and there were probably some I was not aware of, but this is first time I can remember such thing happening.

OK, relevant posts have been moved with the title that was suggested:
 
USB Type-C DisplayPort Alternate Mode Support for NanoPC-T4
 
Thanks @usual user for help keeping the forums organized! 

This is the reason there is the TV Boxes Club to provide a community to help with these unsupported builds.  Since you are using a TV box you will find no/limited support in the general forums for the reasons stated above.  Please read the work in process post in the TV Boxes club that is intended to set expectations around what to expect with armbian and TV boxes:
 

We don't deal with images you find on the internet. We don't know them and they represent extra cost on already extensive support service which you support with nothing. You pay zero and I need to waste lets say 50 EUR for dealing with the problem you have. I would need another few hours to see and understand changes in the image you use. Another lets say 500 EUR worth of research ... you pay nothing for and you press on us for assistance on a problem that is most likely not our work in 1st place.
 
Free support is limited to our work and its also further limited. We can't fix all problems, but we at least try if possible, while when 3rd party image is in question ... we don't even start.
 
Clear?

@grek I've been using compression since the get-go, and can't say I've had similar issues so far. The only time I had a kernel panic was from before I switched to the performance governor for the CPU. LZ4 is also a pretty light-weight compression algorithm, but it does increase CPU to a small degree.
 
Potential changes I have compared to your setup:
I run root (/) on ZFS I use full disk encryption via LUKS (that's an additional layer between ZFS and kernel) I use the performance governor My disks are limited to 3.0 Gbps SATA speed Things you could try:
Upgrade to the latest 5.9.14-rockchip64 kernel Upgrade to the latest ZFS 0.8.6 kernel modules Try the performance governor Do you use a swap partition? If yes, you could try to swapoff before repeating the process that paniced the kernel Wildcard idea: You could also try disabling the Armbian zram config in /etc/default/armbian-zram-config (I have it disabled)

As I said, there is one kernel config per board family, regardless of which packages are installed on userspace the kernel remains the same.  May people will want to download or build a console-only image and then install desktop on it (I do it quite often), so it makes sense to keep it this way.
 
Also, even people running headless may want to use the OpenCL features offered by panfrost, which is an additional reason for keeping it enabled.
 
Besides, having the graphics driver enabled in the kernel should not cause any kind of problem when you are not using the module (that is, no gpu accelerated apps running).  Mali drivers have always been enabled on legacy kernels, without being used in most cases, and it has never been an issue. If some problem ever arose from panfrost on servers, then it would be time to think about the best solution for it. But, as of today, it is not a problem at all, unless the contrary is proven.

It's been fixed to my knowledge. It was the mesa update that was buggy.
Still a few other bugs need to be worked out. But this problem seems to be gone. 

I do think there's another issue. Panfrost is enabled by default in desktop and server images, I don't know if it has a path for correct update. 
Certainly for server images I'd disable it since it can only make problems. For desktop I don't mind.

The other issue with ondemand governor I've not seen anymore. So might also be fixed. If anyone could confirm.

I have tested Focal Xfce desktop on a Rockpi-4b, with Firefox, glmark2, video playing, etc., for over half an hour, and didn't have any problem. I have not been able to reproduce the bug.
 
If someone can give me clear steps to reproduce it, I will try to look into it. Otherwise, I consider it solved.