Werner

Package update in the repos. It reverts back the addition of station-m1 and station-p1 kernels, to the previous state, when everything worked fine. We are keeping the "Depends" relationship to the legacy kernel, since the package actually depends on the legacy kernel: it won't work with a different kernel, and even more it will break the system if installed.

It begins at the far end of the USB. Pin 39/40 are next the USB.
When you use these jumper wires it is best to power with 2 power wires and 1 GND. So pins 2 and 4 you power with 5V. And pin 6 ground.
The M4V2 can consume up to 2A. Many jumper wires are not made for such high load. So dividing it over 2 wires makes sure there's no too much resistance.

Add serial console disk unlocking instructions at step 9.1. Serial console disk unlocking has been added as an option to the automated script as well.

Due to the insane amount of detail you gave with your error description it will take quite a while to sort things out.

Actually that is what I would do at first try.

Given the following comment posted in response to the new invalid message discussed above:
 
"Hi Werner, I didn't realise I'd posted this as a bug I'll post it elsewhere"
 
I took another look at the language in the big red warning message that is displayed for people posting new topics in the bug tracking forums.  While it would seem obvious to those of us on the inside what we are trying to communicate, to the novice user I think there is room to make it more clear.  To that end I have the following suggested wording changes:
 
Current text:
 
Wait!
To avoid common mistakes when opening issues use this form to make sure you have collected all necessary information and create your issue report at the correct place:
>> https://armbian.com/bugs <<
Issue reports that are not following these guidelines will be removed without further notice!
 
Suggested text:
 
Important Please Read Before Posting a New Topic (Bug Report)!
 
You are about to post a new topic in the Armbian Bug Tracker.  Armbian uses the sub-forums under "Bug tracker - supported boards and images only" as it's public facing bug reporting system. If you really intend to report a bug please fill out the following form to supply the necessary information for a valid bug report:
 
>> https://armbian.com/bugs <<
 
With limited resources the Armbian project is only able to spend time investigating bugs where all the requested information has been provided and for only the boards/images/software that are supported.  Your bug report will be considered invalid and receive no attention if you do not supply the requested information.
 
If you only have a question or are looking for help on something in general related to Armbian, you should be submitting your question in one of the "Community forums", such as "Common issues / peer to peer technical support" or "General chit chat", not in this bug reporting forum.

root@nanopi-r4s:~# armbianmonitor -u System diagnosis information will now be uploaded to invalid byte sequence for encoding "UTF8": 0x80 Please post the URL in the forum where you've been asked for. Well whatever: https://paste.debian.net/1181283/
 
I disabled all patches in misc that related to bootsplash because I didn't bother sorting out which patch especially was causing building to fail.
code { font-family: Consolas,"courier new"; color: crimson; background-color: rgba(0, 0, 0, 0.2); padding: 2px; font-size: 105%; } general-rkvdec_nv15.patch needed to be disabled in order to compile successful. Other patches that fail did not do harm.
 

 
Kernel config: https://github.com/EvilOlaf/build/blob/master/config/kernel/linux-rockchip64-dev.config
 
Just noticed the default zswap compressor flipped back to zstd and I hope tkaiser forgives me this flaw since this is just for testing purpose

Yes.
Also yes. Armbian by default uses 50% if available memory for zram. If you have a fast harddrive like SSD or NVMe attached it of course makes sense to put a common swap there.

maintenance complete

Moved to Common issues / peer to peer technical support since this is not a valid bug report

I don't see a problem with using the invalid label as it is invalid according to the directions the user has read (or not read).  What I think would improve this is giving the user more direction on what to do next.  I think some working changes in the post that closes the thread as invalid would be all that is necessary.  So instead of:
 
 
Your issue report is invalid for one or multiple reasons (non-exhaustive enumeration):
 
it has been stated at the wrong place
it lacks fundamental requested data
it could have been easily solved by a quick search and/or reading documentation
unsupported userspace/image/SBC
 
Since you refused to use the bug reporting form carefully and follow the information there as you have been asked for we have no intention to further investigate.
Please add missing information if applicable.
 
https://www.armbian.com/bugs
 
 
Something like:
 
Your issue report is not a valid bug report per the Armbian bug reporting instructions (https://www.armbian.com/bugs).  With limited resources the Armbian project is only able to spend time on issues where all the requested information has been provided and for only the boards/images/software that are supported.  Your report is invalid for one or more of the following reasons (non-exhaustive list):
 
- it is for an unsupported board or image
- it is for software that isn't supported (such as userspace modules installed on top of the core operating system)
- it has been logged in the wrong forum (for example requests for help that are not actual bug reports)
- it lacks requested data (armbianmonitor output)
- it could have been easily solved by a quick search and/or reading documentation
 
Please review what you have submitted and the bug logging instructions (https://www.armbian.com/bugs) and either add the required information or open a new topic in the correct forum (such as "Common issues / peer to peer technical support" or "General chit chat")
 
 
I think this softens the tone and tries to help the user do the right thing.  Which they likely still won't 
 
 
 

Hello,
 
Continuation of the topic the problem with capturing audio on CubieBoard2.
 
At the moment, the issue has been resolved.
In file sun4i-codec.c there was no description of the ADCIS register, which is responsible for selecting the sound source.
Modifications have been made to file sun4i-codec.c to select the Capture Source and Captute Level.
New sun4i-codec.c
Patch sun4i-codec.c
 
If it is possible to make these changes to the kernel for builds Armbian Buster & Armbian Focal.
This change is needed for the A20 processors.
 
With thanks
 
Oleg

It's possible to make it work if you enable all USB nodes in DT. It seems like some HW quirk.

I have tested with the daily version of 3/30/2021.    I found that I2C worked.   USB not worked. 
Two image are added.  These images are what I have captured.
(*) Also, I have noticed that Wifi is not ready either.
 
 

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.

Before complaining about an issue read this!
 
tl;dr: Put your Zero2 and/or any other H616 based device on the shelf and WAIT for proper support to come. And no. There is no ETA. Assuming usable state end 2021/beginning 2022.
 
Software support is still work in progress and under heavy development. Provided preview images can break any time. Do not report this, we are aware of that and can/will not help you with that if you are not willing to investigate and research by yourself.
Feel free to join fellow developers to their efforts to create proper software support. But don't waste our time with complains. Thank you!
 
https://github.com/apritzel/linux/commits/h616-v5
https://github.com/jernejsk/u-boot/tree/h616-v2
https://github.com/apritzel/arm-trusted-firmware/tree/h616-v2-wip
 
 
-----------------------------------------------------------------------------
 
I started to play with this board and obviously failed miserably creating a basic Armbian integration.
 
Anyway. These are the information I collected so far:
 
dtb extraction from Xulong image: https://pastebin.com/raw/Uni2JzBF
 
orangepimonitor 🙄  http://ix.io/2FM0
 
 
root@orangepizero2:/etc/apt# lsmod Module Size Used by zram 36864 2 sprdwl_ng 438272 0 sprdbt_tty 36864 2 uwe5622_bsp_sdio 294912 2 sprdbt_tty,sprdwl_ng  
kernel config: https://pastebin.com/raw/e2jTTZ7A

Obviously the author does not need further assistance. Therefore assuming solved.

PS send me one 

yeah I'm excited about 8Gig chips...  skeptical on AI functionality until there's a way to build DKMS against mainline..

I would take one

I would take one

Quite a while ago developers decided to rename the dev branch to edge to reflect its purpose better: https://armbian.atlassian.net/browse/AR-233
 
This now finally happened. Our documentation has been adjusted as well. For details feel free to check these commits:
 
https://github.com/armbian/documentation/commit/6c9985c9f5a0f593ab2593eb8054b6c658445d25
https://github.com/armbian/build/commit/0cdffb29b07305209efb12cf3b5ac6032d3a1153
 
For those who do automated and/or scripted building take note to adjust it accordingly.
 

Quite a while ago developers decided to rename the dev branch to edge to reflect its purpose better: https://armbian.atlassian.net/browse/AR-233
 
This now finally happened. Our documentation has been adjusted as well. For details feel free to check these commits:
 
https://github.com/armbian/documentation/commit/6c9985c9f5a0f593ab2593eb8054b6c658445d25
https://github.com/armbian/build/commit/0cdffb29b07305209efb12cf3b5ac6032d3a1153
 
For those who do automated and/or scripted building take note to adjust it accordingly.
 

Quite a while ago developers decided to rename the dev branch to edge to reflect its purpose better: https://armbian.atlassian.net/browse/AR-233
 
This now finally happened. Our documentation has been adjusted as well. For details feel free to check these commits:
 
https://github.com/armbian/documentation/commit/6c9985c9f5a0f593ab2593eb8054b6c658445d25
https://github.com/armbian/build/commit/0cdffb29b07305209efb12cf3b5ac6032d3a1153
 
For those who do automated and/or scripted building take note to adjust it accordingly.
 

Following the @lanefu School of Systems Administration ("here, hold my beer!"), I decided to just give it a go.  And IT VEERRRRRKS!   
 
Here are step by step instructions for my fellow nervous, trepidatious sorts out there:
 
1. Install kernel headers.  I did this through armbian-config (Software -> Headers_install), rather than dicker around trying to figure out which exact package I needed for my board and architecture.
 
2. Issue the following command:
 
$ sudo apt -t buster-backports install zfs-dkms zfsutils-linux  
Note: I did not have to enable backports, as apparently they already are "out of the box" in Armbian; however, follow instructions at link if this is not the case for you.
 
Result:
 
 
It took "a little while" to build the module(s).  Just be patient, go grab $BEVERAGE or whatever, take a break...
 
I don't know how to express how happy I am about this.  I have wanted to do ZFS on some ARM based device for literally years now.  RK3399 was very exciting when it came out, but took years to finally get stable.
 
A special thanks to all RK3399 devs, here and elsewhere, for making this a reality.  Beers are on me if/when we ever get around to having ArmbianCon!