Armbian for Amlogic S9xxx kernel 5.x

[AndrewDB]

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. 

[AndrewDB]

6 minutes ago, Reddwarf said:

@balbes150 Will this TV Box work well with your image(s) and will the HD be supported? https://www.banggood.com/THL-Super-Box-Amlogic-S912-2GB-RAM-16GB-ROM-TV-Box-Hard-Disk-Case-Smart-APP-Control-p-1323245.html?rmmds=search&ID=47184&cur_warehouse=CN

Since the S912 SoC does not have an on-chip SATA controller, I assume a USB 2.0 to SATA bridge chip is used... so it should work with the adequate driver module,  but don't expect any better performance than with your average USB flash key. And of course a much cheaper solution is to use a normal S912 TV box and just plug an external USB hard disk.

[xispita]

2 hours ago, AndrewDB said:

To get more RAM for these headless compile nodes I guess I have to recompile the kernel and disable video completely, but I have not tried it yet, it's on my TODO list.

Hi thanks for the reply, for compile the kernel and update in the device it's a complicated thing (I saw your tests to compile in the farm it's not easy to using the compiled kernel  in the devices) ? If I disable the video completely means I will have the entire 1GB for the system right ? (or need to disable more things?)

[balbes150]

1 hour ago, Reddwarf said:

Will this TV Box work well with your image(s) and will the HD be supported?

I don't have the equipment to check and answer. I can only assume by analogy with another model that I have (Tronsmart Vega S95 Telos). In Telos also has a SATA port. But it only works on Android. In Linux, SATA is not visible (need exact parameters for the activation of the port in the DTB). I tried to get this information from the manufacturer, but did not get it. From your model I see a similar situation -   have it only Android. Therefore, I think if the manufacturer does not provide the necessary information and sources, this SATA port will not work in Armbian (Linux). I will not disassemble the firmware and study reverse engineering. I won't waste my time making profits for those who don't want to provide support for their Linux hardware.

 

 

[Reddwarf]

26 minutes ago, balbes150 said:

I don't have the equipment to check and answer. I can only assume by analogy with another model that I have (Tronsmart Vega S95 Telos). In Telos also has a SATA port. But it only works on Android. In Linux, SATA is not visible (need exact parameters for the activation of the port in the DTB). I tried to get this information from the manufacturer, but did not get it. From your model I see a similar situation -   have it only Android. Therefore, I think if the manufacturer does not provide the necessary information and sources, this SATA port will not work in Armbian (Linux). I will not disassemble the firmware and study reverse engineering. I won't waste my time making profits for those who don't want to provide support for their Linux hardware.

 

 

I see. Pity the manufactureres are not more forthcoming, but so is life, I guess...

[AndrewDB]

42 minutes ago, balbes150 said:

I don't have the equipment to check and answer. I can only assume by analogy with another model that I have (Tronsmart Vega S95 Telos). In Telos also has a SATA port. But it only works on Android. In Linux, SATA is not visible (need exact parameters for the activation of the port in the DTB). I tried to get this information from the manufacturer, but did not get it. From your model I see a similar situation -   have it only Android. Therefore, I think if the manufacturer does not provide the necessary information and sources, this SATA port will not work in Armbian (Linux). I will not disassemble the firmware and study reverse engineering. I won't waste my time making profits for those who don't want to provide support for their Linux hardware.

 

 

Hi Oleg, I believe the Tronsmart Vega S95 Telos has a USB to SATA bridge JM20329 (datasheet: http://www.jmicron.com/PDF/brief/jm20329.pdf) which may be supported by recent Linux kernels.

The Tronsmart Vega S95 Telos was reviewed at CNX Software and they provided a pic of the board here: 

[AndrewDB]

1 hour ago, xispita said:

Hi thanks for the reply, for compile the kernel and update in the device it's a complicated thing (I saw your tests to compile in the farm it's not easy to using the compiled kernel  in the devices) ? If I disable the video completely means I will have the entire 1GB for the system right ? (or need to disable more things?)

Hi xispita, the Linux kernel always reserves some memory for its internal use so it's impossible to have the full 1GB for applications. Also, sometimes it's possible to disable the video driver and recover some RAM without having to recompile the kernel, just by passing some arguments on the kernel command line (that's found in the file uEnv.ini in the BOOT partition on Armbian images).

I would have to investigate this issue but have not had enough time yet. As soon as I have some news on this front I'll post here in this thread.

You can also do some research on your side by googling "running linux headless command line parameters" or something similar to see if you find some relevant information. Surely somebody must have investigated this before! 

[xispita]

1 hour ago, AndrewDB said:

Hi xispita, the Linux kernel always reserves some memory for its internal use so it's impossible to have the full 1GB for applications. Also, sometimes it's possible to disable the video driver and recover some RAM without having to recompile the kernel, just by passing some arguments on the kernel command line (that's found in the file uEnv.ini in the BOOT partition on Armbian images).

I would have to investigate this issue but have not had enough time yet. As soon as I have some news on this front I'll post here in this thread.

You can also do some research on your side by googling "running linux headless command line parameters" or something similar to see if you find some relevant information. Surely somebody must have investigated this before! 

 

So I need to do further research do understand better about the kernel options then :)

About the suggestion from @balbes150 have you tried to use the meson-gxm-q201-1gb.dtb from the link https://yadi.sk/d/6dGnDzxI9Zc6Dg in your M8 ? (I have checked your fw_printenv file output and saw the same as mine here)

 

 

 

[AndrewDB]

1 hour ago, xispita said:

 

So I need to do further research do understand better about the kernel options then :)

About the suggestion from @balbes150 have you tried to use the meson-gxm-q201-1gb.dtb from the link https://yadi.sk/d/6dGnDzxI9Zc6Dg in your M8 ? (I have checked your fw_printenv file output and saw the same as mine here)

 

 

 

Yes I tried that dtb with the Armbian 5.67 with kernel 4.19.7 and the result was the same, u-boot loads the kernel but the TV box does not finish booting. And I don't have a USB serial cable on the Km8P so I can't diagnose the problem. So for the moment I am still using kernel 3.14.29 on these S912 TV boxes.

[balbes150]

Found a strange behavior of the MPV on the latest builds. If  start playing a video file (720p) on the desktop with a resolution of 1080p, with the option "--vo=x11". The video is shown without brakes in a window with a size of 720 (equal to the resolution of the video). If try to expand to full screen, the video starts to slow down. If  run 1080p video, the windowed video slows down, but if you switch to full screen, it works without brakes. If change the desktop resolution to 720, 720p video works without brakes in windowed and full-screen mode. I don't understand why the 1080 video with the 1080 desktop is slow, but works full screen without brakes. What is the reason for this behavior ?

[talraash]

37 minutes ago, balbes150 said:

Found a strange behavior of the MPV on the latest builds. If  start playing a video file (720p) on the desktop with a resolution of 1080p, with the option "--vo=x11". The video is shown without brakes in a window with a size of 720 (equal to the resolution of the video). If try to expand to full screen, the video starts to slow down. If  run 1080p video, the windowed video slows down, but if you switch to full screen, it works without brakes. If change the desktop resolution to 720, 720p video works without brakes in windowed and full-screen mode. I don't understand why the 1080 video with the 1080 desktop is slow, but works full screen without brakes. What is the reason for this behavior ?

Spoiler

Такое поведение было во всех релизах) ИМХО, связано это в первую очередь со скалингом видео, с софтварным скалингом. С 720p soc еще справляется, в режиме "в окне" с 1080p  - уже проблемно. При проигрывание в фулскрине соответствующего разрешения ничего скалить не нужно, и соответственно проблем нет. P.S. Видел упоминанние про puppyrus, но упорно не получается зарегестрироваться на puppyrus, просто не приходит письмо активации на ящик gmail)

 

[Reddwarf]

5 hours ago, talraash said:

  Hide contents

Такое поведение было во всех релизах) ИМХО, связано это в первую очередь со скалингом видео, с софтварным скалингом. С 720p soc еще справляется, в режиме "в окне" с 1080p  - уже проблемно. При проигрывание в фулскрине соответствующего разрешения ничего скалить не нужно, и соответственно проблем нет. P.S. Видел упоминанние про puppyrus, но упорно не получается зарегестрироваться на puppyrus, просто не приходит письмо активации на ящик gmail)

 

Would be nice if we others could read it

[Turgus]

Google translates it that way:
This behavior was in all releases) IMHO, this is primarily due to the scaling video, with software scaling. With the 720p, soc still manages, in the "in window" mode with 1080p - already a problem. When playing the corresponding permission in fullscreen, you don’t need to sign anything, and accordingly there are no problems. P.S. I saw a mention about puppyrus, but I can’t persistently fail to register for puppyrus, the activation letter just does not come to the gmail box)

[Reddwarf]

9 minutes ago, Turgus said:

Google translates it that way:
This behavior was in all releases) IMHO, this is primarily due to the scaling video, with software scaling. With the 720p, soc still manages, in the "in window" mode with 1080p - already a problem. When playing the corresponding permission in fullscreen, you don’t need to sign anything, and accordingly there are no problems. P.S. I saw a mention about puppyrus, but I can’t persistently fail to register for puppyrus, the activation letter just does not come to the gmail box)

Well I suspected it to be a scaling problem also, but should not the GPU take care of scaling? Or is it still not used?

[talraash]

@Reddwarf It's vpu job...  https://dri.freedesktop.org/docs/drm/gpu/meson.html But without properly work v4lm2m, with software decoding we don't have hw scaling, and default scaling algorithm very heavy I mention early that if you play video which does not match with display resolution use --sws-scaler=fast-bilinear it give a huge performance boost

P.S. Sorry for russian only, but that message was mainly for balbes150

[Reddwarf]

1 minute ago, talraash said:

@Reddwarf It's vpu part... https://dri.freedesktop.org/docs/drm/gpu/meson.html I mention early that if you play video which does not match with display resolution use --sws-scaler=fast-bilinear it give a huge performance boost

I see. Bilinear certainly is faster but not so good quality... Would it not be possible to have the Mali prescale every frame to display resolution in fullscreen mode?

[amirul]

On 1/31/2019 at 7:08 PM, amirul said:

Oops my bad, p201 it is then. All good now :-)

 

The box turns off after a few minutes of activity. Perhaps heat or segfault?

 

Armbian_5.74_Aml-s905_Ubuntu_bionic_default_4.20.5_desktop_20190304.img on S11 meson-gxbb-p201.dtb

hdmi screen turns black after a few minutes running, box still accesible via ssh. Possible to get screen back on but not sure on exact sequence (turn display off-on, disconnect-connect hdmi cable etc).

armbianmonitor gives some weird temperature figure

Time        CPU    load %cpu %sys %usr %nice %io %irq   CPU
01:17:26: 1752MHz  0.77  18%   3%  14%   0%   0%   0% 4294967295.0°C

[AndrewDB]

6 hours ago, amirul said:

Armbian_5.74_Aml-s905_Ubuntu_bionic_default_4.20.5_desktop_20190304.img on S11 meson-gxbb-p201.dtb

hdmi screen turns black after a few minutes running, box still accesible via ssh. Possible to get screen back on but not sure on exact sequence (turn display off-on, disconnect-connect hdmi cable etc).

armbianmonitor gives some weird temperature figure

Time        CPU    load %cpu %sys %usr %nice %io %irq   CPU
01:17:26: 1752MHz  0.77  18%   3%  14%   0%   0%   0% 4294967295.0°C

No problems with armbian monitor here:

andrew@mxqpro4k:~$ cat /sys/class/hwmon/hwmon0/temp1_input
38000
andrew@mxqpro4k:~$ armbianmonitor -m
Running unprivileged. CPU frequency will not be displayed.
Stop monitoring using [ctrl]-[c]
Time        CPU    load %cpu %sys %usr %nice %io %irq   CPU

08:21:12:   ---      0.09   0%   0%   0%   0%   0%   0% 39.0°C
08:21:17:   ---      0.08   0%   0%   0%   0%   0%   0% 39.0°C
08:21:22:   ---      0.08   0%   0%   0%   0%   0%   0% 39.0°C^C

The box does not turn off, it's probably the HDMI output that is disabled after 300s (5 minutes). Either a hardware problem with monitor detection or a small bug in the hdmi driver code.

[balbes150]

17 hours ago, talraash said:

Sorry for russian only, but that message was mainly for balbes150

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

[Tommy21]

Is it possible to put, in my case hdmi monitor to sleep, without the need for manually turning it off, i know this is maybe silly question that crossed my mind, but i do want to know.

I know i've read somewhere that power management functions like suspend or hubernate are impossible to implement, but this shouldn't be impossible?

[talraash]

38 minutes ago, Tommy21 said:

Is it possible to put, in my case hdmi monitor to sleep, without the need for manually turning it off, i know this is maybe silly question that crossed my mind, but i do want to know.

I know i've read somewhere that power management functions like suspend or hubernate are impossible to implement, but this shouldn't be impossible?

I didn't try, but dpms may work... https://wiki.archlinux.org/index.php/Display_Power_Management_Signaling

[AndrewDB]

@balbes150

Hello Oleg,

I am trying to change some u-boot parameters on a S905X TV box on which I have installed your Armbian 5.67 Ubuntu Bionic image, flashed to the internal eMMC. I have also flashed the new u-bootS905X.img.

So it's booting OK from the eMMC, but it is changing the MAC address of the Ethernet interface at every boot.

I have tried to run the fw_printenv tool to check the u-boot parameters but it complains about non existent /etc/fw_env.config.

 

Would you know what I have to write in fw_env.config?

 

# <device>   <offset> <length>
/dev/mmcblk1 0x??????? 0x??????

 

Thank you for your help. 

[balbes150]

7 hours ago, AndrewDB said:

Would you know what I have to write in fw_env.config? 

In the 4.1x kernel, it is not possible to use fw_printenv for look ENV u-boot. The easiest thing is to use the UART console. If its there is no the are possible options. If your new u-boot uses the old scheme (u-boot-2015), you can run the old version of Armbian or LE from external media and see the options. If this is already a new version of u-boot-2018, you need to look at the build options to use an external script that can read and save the current ENV values to a text file at startup.

[amirul]

On 2/6/2019 at 9:18 AM, amirul said:

Armbian_5.74_Aml-s905_Ubuntu_bionic_default_4.20.5_desktop_20190304.img on S11 meson-gxbb-p201.dtb

hdmi screen turns black after a few minutes running, box still accesible via ssh. Possible to get screen back on but not sure on exact sequence (turn display off-on, disconnect-connect hdmi cable etc).

5.73 does this as well.

5.60 is ok

[dbsharpe]

1 hour ago, amirul said:

5.73 does this as well.

5.60 is ok

I'm using a meson-gxbb-p201.dtb box and have noticed issues from version to version (i.e. sound on kernel 4.20.2) as well as screen powered off. Had to use systemctl restart  lightdm.service to get the screen back.
Problem are fixed by using the dtb from Armbian_5.73_Aml-s905_Ubuntu_bionic_default_4.20.2_desktop_20180129.img.xz (even though I'm running 4.20.2-aml-s9xxx kernel)

[amirul]

On 2/7/2019 at 8:31 PM, dbsharpe said:

I'm using a meson-gxbb-p201.dtb box and have noticed issues from version to version (i.e. sound on kernel 4.20.2) as well as screen powered off. Had to use systemctl restart  lightdm.service to get the screen back.
Problem are fixed by using the dtb from Armbian_5.73_Aml-s905_Ubuntu_bionic_default_4.20.2_desktop_20180129.img.xz (even though I'm running 4.20.2-aml-s9xxx kernel)

After an update, X segfaults after a while running 5.73

Seems that its a tv fault. Switching to a different TV cured it.

 

Still with weird screen blanking, using meson-gxbb-p201.dtb from 5.60 is better

Edited February 9, 2019 by amirul
Update

[balbes150]

On 2/5/2019 at 6:26 PM, talraash said:

Such behavior was in all releases) IMHO, it is connected first of all with a video scaling, with a software scaling. With 720p soc still copes, in the "window" with 1080p - already problematic. When playing in full screen proper permission nothing grin do not need, and therefore there is no problem

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).

[balbes150]

On 2/4/2019 at 4:55 PM, Reddwarf said:

I see. Pity the manufactureres are not more forthcoming, but so is life, I guess...

I looked at the description and details. perhaps something and make with this equipment. But for this i'm need to have real equipment available for development and testing. I wrote to the manufacturer, if he is interested in supporting this model on the Armbian platform, then it is possible to make a working system for this model.

[Hugh]

I have an s912 box that is waiting for Armbian (or some other Linux distro other than Android).  The problem is support for the Mali T820mp3 (I think that is the GPU).

 

There seems to be some progress on Panfrost, the open source driver for recent Mali GPUs.  https://www.phoronix.com/scan.php?page=search&q=Panfrost

 

Is Panfrost getting good enough for inclusion in Armbian?  Is it something the project is interested in?

 

(Lima is interesting to those who have chips with Mali 400/500 GPUs (eg. S905).  From reading above, it looks to me as if Lima is included but not yet 100% functional.)

[gameseg]

On 2/3/2019 at 4:36 AM, balbes150 said:

Steps the right. But if you are editing scripts, you need to edit everywhere. Now you need to start the system from USB. Open "BOOT_EMMC" section , open "uEnv.ini" and check (fix) in it the partition names on "ROOT_EMMC" and "BOOT_EMMC". Just open the section "ROOT_EMMC" and check (fix) the file "/etc/fstab" (specify the correct label, must be specified "ROOT_EMMC" and " BOOT_EMMC")

It works!!! I only changed my "uEnv.ini" file in boot_emc to represent "mmcblk0p2" and now I can boot from eMMC. Thank you!