Amlogic S9xxx SoC family preliminary support

For Developers
#1

The aim of this writing is to encourage lede coders to create lede working image for Amlogic S9xxx SoC family.

Based on a few benchmark I did and shown at:
wiki.openwrt. org/doc/howto/benchmark.openssl [single core tests]
systemausfall. org/wikis/howto/AES-Performance [multi core tests]

The crypto performance of Amlogic SoC S905X is approximately same as my 2012 laptop' i5 sandy bridge [even with AES-NI]!

Without any lede's working image, I can reliably use S905 tvbox with Armbian distro to offload my ageing QCA953x moded ROM+RAM router's cpu load. The S905 tvbox is a very capable machine that can run kcptun client, shadowsocks client and ocserv server all at same time with average cpu load only 6~20%.

I've tried to run lede with success by using this way:

What I did is combining Armbian S905 kernel from: forum.armbian. com/index.php?/topic/2419-armbian-for-amlogic-s905-and-s905x
and Rapsberry Pi3 [arm64 too] lede rootfs image from: downloads.lede-project. org/releases/17.01.2/targets/brcm2708/bcm2710/lede-17.01.2-brcm2708-bcm2710-rpi-3-ext4-sdcard.img.gz

Due to incompatible kernel, I abandon it for daily routing tasks due to plenty of kernel' error msg, vlan 802.1q not working and I don't have usb-lan dongle to try.

Amlogic has been showing good gesture to open source community with some releases of their GPL work at:
openlinux.amlogic. com/wiki/index.php/Arm
odroid. com/dokuwiki/doku.php?id=en:c2_building_kernel

With IPQ806x powered router is around USD 150 but only 1/2 of S905 crypto performance, why don't we make use the S905 for USD 30 as a firewall/VPN front end and couple it with our own fully supported wireless router/AP :smiley:

2 Likes
OpenWrt ARM in Linux container
#2

I actually managed to run arm64 virtual image on S905 from http://downloads.lede-project.org/releases/17.01.2/targets/arm64/generic/lede-17.01.2-arm64-qemu-virt-initramfs.Image
however, the performance is undesireable and qemu-kvm is not available for debian arm64 yet

#3

Be careful of what you test here. openssl speed is good benchmark to test how well the generic crypto routines are implemented in OpenSSL and what the CPU and Memory can do. So on x86 with just AESNI and ARMv8 System (with a CPU that supports the aes crypto ISA) this can be fine. But some routers do have dedicated crypto offload engines. And these can really knock the socks off! Crypto offload is supported via the EVP API/Interface which is the default for most openssl-based applications.
(See: https://wiki.openssl.org/index.php/Libcrypto_API#High_Level_and_Low_Level_Interfaces )

For example the FritzBox 4040 (quad ARM A7 @ 700 MHz) struggles with "openssl speed -multi 4 aes-128-cbc"

 type             16 bytes     64 bytes    256 bytes   1024 bytes   8192 bytes
 aes-128 cbc      49911.62k    55785.21k    57423.18k    57808.37k    57959.08k

 (single core result):
 type             16 bytes     64 bytes    256 bytes   1024 bytes   8192 bytes
 aes-128 cbc      12089.79k    13885.17k    14351.14k    14473.10k    14533.32k

However, if the crypto offload is used: 'openssl speed -evp aes-128-cbc' produces this "amazing" result:

   type             16 bytes     64 bytes    256 bytes   1024 bytes   8192 bytes
   aes-128-cbc       7193.60k    39487.36k   112832.00k   708492.80k  6335692.80k

So, this measly 75€ router manages to "outclasses" an 3.9GHz Intel i7 4770 desktop CPU too (in the 1024 bytes case):

   type             16 bytes     64 bytes    256 bytes   1024 bytes   8192 bytes
   aes-128 cbc     573727.79k   623109.78k   643227.05k   638893.06k   641908.74k   648249.34k
   (This i7 has HyperThreading too, but the multi 8 result was slower)

However, of course the router can only pull this off, if you compare apples to oranges :wink:
So benchmarks on crypto performance alone are very deceiving.

1 Like
#4

Your device crypto benchmark looks like have no limits, the number is increasing exponentially :crazy_face:

Anyway, I've found out Stijn Tintel already commited some codes into staging.git here:
https://git.lede-project.org/?p=lede/stintel/staging.git;a=commit;h=698c80dee237f133251886c10f337c8bd31d2454

Lets keep this rolling and get one for yourself because:

  1. Debian says "Arm64 is a first-class release architecture in Stretch, with almost all packages built, and the standard installer working on various machines, and quite likely to work on new ones"
  2. With less than USD 30, you can get a S905 tvbox with ac adaptor, case, heatsink, ir remote control, built-in 8GB emmc & wlan included.
  3. Already ported to android, libreelec, armbian and many more to come [eg. freebsd].
#5

Please port LEDE to this SOC. I do own a WETEK Hub and would like to use it as AP, Bridge or Repeater.

#6

How is this progressing ? i'd like to run openwrt on my tv box as well

#7

Any news on this?

#8

Based on previous trends, to avoid too much patch & backport jobs, OpenWRT developer will only work with long term kernel versions.
The present Lede release is based on long term kernel 4.4, the Amlogic staging kernel commit is for mainline 4.12, the next long term kernel after that is 4.14.
The bad news is: there is long term kernel 4.9 between 4.4 and 4.14.
The good news is: the current snapshot builds is based on 4.14!
We can only hope that our #devel will soon start to include Amlogic on current snapshot.

Some Amlogic mainline development news:


#9

Please get the box that suitable for you from this list:

#10

What is the current status? Any pre-built images for my WetekHub already available?

#11

some info
https://git.openwrt.org/?p=openwrt/staging/stintel.git;a=shortlog;h=refs/heads/meson

1 Like
#14
1 Like
#15

thanks, I will try on my STB B860H

#16

Is someone able to use it on any tvbox or something else than vim devices?

#17

And it's still maintained! :metal:

I'll try my luck with Odroid N2.

#18

I had luck! :grinning:

Screenshot 2021-10-18 at 01-13-09 ODROID-N2 - Overview - LuCI
Screenshot 2021-10-18 at 01-13-09 ODROID-N2 - Overview - LuCI961×658 14.2 KB

Source is on my meson-odroidn2 branch: it's based on @stintel's work.

It's far from ready:

  • packaging the bootloader needs lot of work
  • CPU freq and governor missing
  • ...
2 Likes