balbes150

New ver How to get HW for s905
 
https://forum.khadas.com/t/armbian-kodi-ubuntu-debian-for-sd-usb-emmc/825/305?u=balbes150

New image 5.75
 
 
How to get HW for s905x
 
https://forum.khadas.com/t/armbian-kodi-ubuntu-debian-for-sd-usb-emmc/825/299?u=balbes150
 
 

New image 5.75
 
 
How to get HW for s905x
 
https://forum.khadas.com/t/armbian-kodi-ubuntu-debian-for-sd-usb-emmc/825/299?u=balbes150
 
 

New image 5.75
 
 
How to get HW for s905x
 
https://forum.khadas.com/t/armbian-kodi-ubuntu-debian-for-sd-usb-emmc/825/299?u=balbes150
 
 

Using mpv from the command line console should give you a log, with info about the decoder and display driver it is using. Also with gst-play-1.0 for gstreamer.
 
Also, running glmark2-es2 will tell you whether it is using Mesa SW emulation, or Mali.
 
For last, if you have configured chromium to use acceleration (like my script does), you can check whether it is working by typing in the address bar "chrome://gpu"
 
Edit: And, of course, you can also check /var/log/Xorg.0.log

Well, no fancy introduction here, because this doesn't pretend to be a script for the general use, only for testers who want to try the current *very early* status of the media capabilities in the Armbian meson mainline kernel.
 
Warning: It will replace your current kernel with a pre-compiled nightly 4.19.20.
 
Instructions:
Download, untar and run. If you need further instructions, then you are not ready for this script (again, it is very unpolished, not for general use).
 
Download link: https://mega.nz/#!YvYUhayC!CI1fl52V4tV0G4oqUib4W-NlMpVSpLDp8kmo74g-V08
 
Things that you can try with this script, on a X session:
 
Use a 1080p@30fps h264 video, and play it with "mpv -hwdec <filename>". You'll see in the logs that it is decoding through v4l-m2mcopy Install and run glmark2-es2 Use Chromium WebGL Play a 1080p@30fps video in YouTube in full-screen smoothly. I'm pretty sure it is not really using HW decoding as it claims (there is no  initialization message in dmesg), but it's smooth for sure.  
Gstreamer is tested not to work, in some other forum I was told that Bionic version is not enough and I need to compile a newer one.
 
Performance is not in any way good, but it is a starting point. Anyway, the first TO-DO is getting the mali module integrated into the kernel, so there is no need to compile it separately.

To complete the comparison it is desirable to add how much money is spent on them (for RPi this should include power supply, remote control, SD card, HDMI cable and stuff that is in the TV box).

When running the tests, I disabled the soft scaling and used only one parameter passed to MPV (vo=x11). I tried to set options hardware and software decoders, the result is the same. Used the last version of FFMPEG and MPV were collected using support v4l2m2m. Likely to need any additional options which need to point to the new FFMPEG to use hardware transform, but I don't understand it. If anyone wants to try to find the right options on the site in the directory 5.74\S905 are the image and new packages (which are built with support for v4l2m2m).

Admin wrote and gave a link to your message. If there are problems, write me in PM here.

With some further optimization, kernel compile times using distcc on my small S9XXX TV box build farm with 28 Cortex-A53 cores is:
 
time make -j28 CC="distcc gcc" Image modules dtbs
 
real    15m31.226s user    89m33.590s sys     10m34.380s
More details here: http://wiki.loverpi.com/specs:sbc:distcc-kernel-compile
 
This is all thanks to Oleg's great work on providing Ubuntu images for Amlogic S9XXX based TV boxes, so again, thank you Oleg for your amazing work. 

My memory test numbers
 
TV box MX10 in the line will indicate what dtb and what is the result
core 4.4
mx10  328
a5x     576
a5x-1300    597
a5x-1500    621
kernel 5.0
there's one working dtb MX10 - 336.
 
TV box MVR9 (adjusted for the size of the RAM test output is reduced to 500 units)
4.4
a5x    531
a5x-1300    559
a5x-1500    566
trn9   604
trn9-1500    619
5.0 here is here sign in,
mx-10     278
rock64    280
It is unclear what the test was measured at 5.0 MVR9
 
Otherwise, it becomes clear why subjectively after the transition to a new DTB on MX10 was a feeling of similar work with MVR9 , memory speed is almost equal.

Then wait until I can check the dtb you sent from kernel 3.14 and build a new version.
It's not going to be fast.

Then wait until I can check the dtb you sent from kernel 3.14 and build a new version.
It's not going to be fast.

I remember trying the adb method to get the dts, but my developer options did not have "Internet/wifi debugging" checkbox.
 
I found a release of the firmware from geekbuying for a A5X Box and used
https://roc-rk3328-cc.readthedocs.io/en/latest/fw_pack_unpack.html
to unpack the img into smaller img files from update.img
 
then used
https://github.com/PabloCastellano/extract-dtb
to extract the dtb (try on all the smaller img files created from unpacking update.img)
 
and then used dtc to decompile.
 
 

Agree. Getting to the Android .dts took me some time, as many of the proposed procedures did not work for me.
My workflow:
Have Android running on the box, developper mode active. In the settings I had a strangely named checkbox like "Internet debugging", switched on Have Android studio installed Could use adb to connect to the box, even without usb, just via lan/wlan adb root worked out of the box, devices like this one seem to be rooted by default? used adb to download the device-tree directory (have android not at hand now, should not be to hard to find) used dtc to convert It took me some time to realize that dtc can handle device-tree directories (-I fs option, see manual)
 
Starting point for documentation: https://www.kernel.org/doc/Documentation/devicetree/usage-model.txt

Yes.
 
I am now watching YouTube with my wife on full screen TV in 1080p TV mode with fan on MVR9 without brakes and friezes. Temperature output in the range of 60-65 degrees. Video goes without brakes and friezes.

Processors rk3328 powerful and require a good cooling system. You have not changed the housing and no fan. Therefore, the system heats up very quickly and reaches the adjustment temperature (70-80 in the dtb mx10 and 75-85 files on the a5x files). Here I described the test results when playing 4K video. After the addition of a normal cooling system (and USB fan), the temperature did not exceed 50-55 degrees under maximum load.
 
 

Glad to read I seem to have created something useful.
 
My box is a scishion ai one alike one, MXQ pro max labeled box. The board is labeled TX-RX4B-V02.
 
My workflow:
Used adb to read the device tree directory from the box running android. Converted to android.dts file using dtc. For armbian used the ...box.dtb because the device could boot using that one. Converted dtb to dts using the "sorted" option of dtc for comparison (a). Converted dtb to dts without the "sorted" option for optimization (b). Used a merge utility (meld) to compare (a) against android.dts Put the found differences into (b), used dtc to compile. Too easy
 
Now, compare and merge... Using dtc to decompile a dtb to text format means there is no symbolic info - names as found in the kernel sources .dts(i) files 
and rockchip documentation are not available. Its just like reading and trying to understand a compiled app from a debugger listing without symbols.
Reading the kernel documentation regarding the device tree mechanism turned out to be very helpful.
 
I think this kind of workflow is suitable for proof of concept. It is really not suitable for anything else.
 
Its very easy to make mistakes. Easy to detect if the device refuses to boot, but there are many more possibilities.
 
Reading things like ... "did not work... suddenly did... then stopped to work again...":
This can mean pin settings (called pad nowadays, ok) might be wrong.
Reset or chip enable signals of peripheral chips are wired to soc gpios. If the mapping of those gpios to driver functions is wrong - anything can (and will) happen.
 
Regarding dram settings
These numbers count in pico seconds. And a pico second is a dammed short time. The right values depend on used chips and pcb layout and must be
set very carefully. Just using the values suitable for one board with an other... might work - or not - or temporary.
 
Regarding the wifi chip
The soc pads wired to the 8723 on my pcb differ from the standard ones and an other mmc peripheral of the soc is used for sdio connection. 
It might well be, that other pcb's are wired the same way and that 8723bs and 8723cs are mostly compatible.

 

Checked 4K playback (full screen) on TV boxes. The main cause of the brakes and stop playback 4K  - overheating. If run a 4K video in MPV or Gstreamer, within the first few tens of seconds the temperature rises to a critical 70 (this is the first stage of regulator) and the video begins to slow down and does not play smoothly. When reach the next level of adjustment 80, the video simply stops working. I added a fan and the temperature immediately dropped when playing 4K to 45-55. And all the video began to work smoothly during the entire playback period. By the way. there was a reason for the green bars when working in 4K mode on MX10-incorrect parameters in DTB. Now assembled a new version of Armbian 5.73 with new DTB (memory optimization and increased frequency to 1500). I run the system on MX10 with TV 4K, MPV gstreamer KODI - everything works on a full screen without interference.
 
By the way, it is very convenient to run "armbianmonitor-m" through the UART console (or SSH console) and see the temperature in real time with any playback program.

This driver uses private binary blobs from ARM. LIMA is completely open data. I prefer to use the open version.
 
What the dtb has been used and what exactly the version of the image.
 
The 3.14 kernel is very outdated and no longer supported, so I don't use it anymore.
 
 LIMA drivers are in the image. Only the correct version of MESA with LIMA support is missing (and  may need to build programs using LIMA \ MESA-LIMA).
 
Write in detail all the steps that you did. Without this, there is no point in making assumptions.
 
Very useful information. Thanks.
 
Do you have a UART console on it ?
 
The problem is not with the kernel, but with your hardware (the manufacturer's support for it). The manufacturer of your model doesn't want to do anything for it to work with the new kernel.
 
You have a model with a network card 100Mb, it needs dtb p201
 
S11 Hardware:    
CPU: Amlogic S905 Quad-core A53 2.0GHz 64bits
GPU: Penta(5) core Mali 450
Android Version: 5.1
RAM: 1G
ROM: 8G
WiFi: Built in 2.4G WiFi
Ethernet: 10/100 mbps RJ45

Hello all,
First I would like to thank Balbes150 for his amazing work. I am using his Armbian images on the five various Amlogic S9XXX TV boxes I have.
Thank you very much, Oleg! Fantastic work! 
What I have right now on my workbench:
1) MXQ Pro 4k, S905, 1GB/8GB RAM/ROM, running Armbian Ubuntu 18.04 server 5.67 with kernel 4.19.7. I am using meson-gxbb-p201.dtb.
2) M9C Max 4k, S905X, 2GB/16GB RAM/ROM, also running Armbian Ubuntu 18.04 server 5.67 with kernel 4.19.7. I am using meson-gxl-s905x-p212.dtb.
3) 3 x Mecool KM8 P, S912, 1GB/8GB RAM/ROM, running Armbian Ubuntu 18.04 server 5.44 with kernel 3.14.29. I am using gxm_q201_1g.dtb. These boxes are used as a distcc build farm, which I have documented here: http://wiki.loverpi.com/specs:sbc:distcc-kernel-compile
 
I can get the kernel to compile in just under 17 minutes on the build farm, instead of 44 minutes on a single S912 box or more than an hour on the S905/S905X boxes!
 
All TV boxes are booting from Samsung EVO micro SD cards, and yes, it's important to use good SD cards, as repeatedly suggested in the Armbian documentation. 
 
I have a USB serial cable soldered to my MXQ Pro 4k TV box, this has been very helpful to play around with u-boot.
 
I have a question for anybody who also has a Mecool KM8 P S912 box: have you been able to boot any Armbian image with a 4.xx Linux kernel? What dtb file did you use? I have been unable to boot anything other than the 3.14.29 kernel on these S912 boxes. Thanks for any answer on this issue.
 

I made a few adjustments to the device tree for my XT-RX4B-V02 based box. The intermediate results look promising:
wifi (RTL8723CS) basically works memory perf: armbian@rk3328:~$ dd if=/dev/zero of=/tmp/testfile bs=1M count=1000 1000+0 records in 1000+0 records out 1048576000 bytes (1.0 GB, 1000 MiB) copied, 1.70386 s, 615 MB/s ... this was within an x11vnc session, on multiple tests I constantly get values greater than 550MB/s (The board has 4GB DDR3/1600 ram)
 
Notes
I never experienced stability issues. As the mounted "heatsink" is more than dubious, I lowered the temp limits just to stay on the safe side. Scaling down the cpu-frequency on temp limit works flawlessly.

The voltage settings used in Android are slightly lower than the ones in use. I had no time to test, might improve temps a bit.
 
There are still a number of issues, maybe someone around could kick in?
Wifi client: Connect using nmtui is fine, but how to auto-connect on system start?
The adapter chooses a random mac on boot. I think assigning a static one would help - I just did not find a proper way of doing so... dmesg tells me that there are still a number of device tree issues that might prevent the gpu from working properly. Bluetooth (RTL8723CS) does not work yet (while usb bluetooth dongle is fine). I got the impression (might be wrong) that chip support will still take some time, but I'd like to get the device tree right and don't know how to prove that I got pins/uart/device tree settings right. @balbes150 lsmod tells me 8723cs and 8723ds get loaded. Removing 8723ds.ko helps - what would be the right way of dealing with such situation? OT side notes:
x11vnc. I had issues with disconnecting windows viewers that took me some time to resolve. I found the resolution here: https://thespecter.net/blog/technology/opensourcediy/x11vnc-stack-mashing-detected/ (just add -noxrecord to x11vnc command line) In headless mode I get 1024*786 on boot. Simply calling xrandr --fb 1920x1080 works well. Best
rk3328-box-RX4B-V02-WIP190129.dts

New version 5.73.
1. A separate section for images with the s905 LIMA driver has been added to the catalog.  Notice is images in which there is only the kernel driver LIMA, HW support for DE until they do not. For HW you need to collect a special version of MESA-LIMA. I tried to build it, but I have a bug at the end of the build. May be there is a wish to collect the desired version of MESA-LIMA and help the process of the emergence HW to s905 ? 
 
2. In the usual directory S905  Assembly for without driver LIMA.
 
3. I built an FFMPEG package with support for decoding using HW. To check, you can download the package and install it in the system with the command "dpkg". When checking the work I was able to run FFMPEG command decode test video.
 
HW
ffmpeg -c:v h264_v4l2m2m -i Test.mkv -f null /dev/null
 
not HW
ffmpeg -c:v h264 -i Test.mkv -f null /dev/null
 
When you start to S905 , when using the decoder with HW h264 decoding speed is equal to 11.9 , without using HW decoding speed is equal to 4.3. When tested on S912-with HW speed 12 , without HW speed 7.9.
 
I tried running the video using ffplay.
 
HW
ffplay -vcodec h264_v4l2m2m Test.mkv
 
not HW
ffplay -vcodec h264 Test.mkv
 
It shows the test video, the sound is correct, but the video is played in the braked mode (as if the deceleration is enabled). Maybe there's something I'm doing wrong when building or testing. I would appreciate it if someone could find a reason why the video is stalled.
 
https://yadi.sk/d/9igaopSIabKsjw

New version 5.73.
1. A separate section for images with the s905 LIMA driver has been added to the catalog.  Notice is images in which there is only the kernel driver LIMA, HW support for DE until they do not. For HW you need to collect a special version of MESA-LIMA. I tried to build it, but I have a bug at the end of the build. May be there is a wish to collect the desired version of MESA-LIMA and help the process of the emergence HW to s905 ? 
 
2. In the usual directory S905  Assembly for without driver LIMA.
 
3. I built an FFMPEG package with support for decoding using HW. To check, you can download the package and install it in the system with the command "dpkg". When checking the work I was able to run FFMPEG command decode test video.
 
HW
ffmpeg -c:v h264_v4l2m2m -i Test.mkv -f null /dev/null
 
not HW
ffmpeg -c:v h264 -i Test.mkv -f null /dev/null
 
When you start to S905 , when using the decoder with HW h264 decoding speed is equal to 11.9 , without using HW decoding speed is equal to 4.3. When tested on S912-with HW speed 12 , without HW speed 7.9.
 
I tried running the video using ffplay.
 
HW
ffplay -vcodec h264_v4l2m2m Test.mkv
 
not HW
ffplay -vcodec h264 Test.mkv
 
It shows the test video, the sound is correct, but the video is played in the braked mode (as if the deceleration is enabled). Maybe there's something I'm doing wrong when building or testing. I would appreciate it if someone could find a reason why the video is stalled.
 
https://yadi.sk/d/9igaopSIabKsjw