A little excursion to Linux on ARM and ArchLinux on the Mele A1000 / A2000
Hello.
Watching videos on youtube, how ubuntu is run on single-board computers like the Mele A1000 or MK802, I decided that I needed to do something with performance and at the same time run ArchLinux on this device, since this, for some reason, has not been done yet.
Why do we see that all devices on ARM and MIPS work so slowly as desktop systems? The reasons are many:
If for the x86 the first is almost irrelevant, since everyone has FPUs and optimizations for a specific processor give no more than 5-10% of performance, then ARM devices can get a tremendous increase, for Mele it is something like 30% to 150% on complex tasks with a floating point (such as video decoding).
Since there is practically no full support in the mainline-core of real devices, and not test boards, we have to use a kernel from the manufacturer, which is good if the third branch. Moreover, changes to the core are often made through the backside, which is why in the configuration menu we get the missing dependencies between the options and almost the inability to port these changes to more recent kernels by means of enthusiasts (this, of course, not for everyone).
Maintainers of distributions do not want to spend power, computational power and disk space for additional repositories, and for a very long time they compiled everything either with FPU emulation or with softfp (it allows using FPU, but is compatible with emulation), but with optimizations for ARMv5, but About a little over a year ago, when the Cortex-A8 went to the masses, the maintainers thought about it and decided to try compiling everything with hardware floating point. So, ubuntu 12.04 was the first mass distribution in which the armhf repository appeared. This is a big progress, only it gives Cortex-A8 a gain of 20% -40%, compared to softfp, all applications are now built under ARMv7, but this is not enough.
To date, there are 3 distributions that have hardware floating point repositories: ArchLinux-ARM, Ubuntu, and Fedora. Because I love ArchLinux, the choice is obvious to me.
“Why do maintainers collect packages without NEON?”, You ask:
ARMv7 without NEON instruction set (for example, Marvell Armada in a CuBox device)
Cortex-A8 (ARMv7 + NEON, Chinese devices with Allwinner A10: Mele, MK802, MiniX)
Cortex-A9 without NEON (nVidia Tegra 2 in Toshiba AC100)
Cortex-A9 with NEON
It should be noted that the VFP in Cortex-A9 is already almost as fast as the NEON, and the optimization for NEON is more a matter of energy saving than of performance.
')
CFLAGS:
Video hardware acceleration does not work.
It is not yet clear if gles works, because glxinfo says that direct rendering: yes, glxgears are spinning, but somehow not very. As a server, you can use.
How to write all this on a USB flash drive can be read on the link:
www.cnx-software.com/2012/07/20/nightly-builds-for-allwinner-a10-u-boot-linux-kernel-and-hardware-packs
To start the interface, go to ssh root / root and type startx
If you have the desire and opportunity to help, you love ArchLinux and want to see it on Chinese devices on Allwinner, please contact me.
And a little more information: Allwinner is working with XBMC on video acceleration in XBMC for Android. It will be a real STB, but now somehow there is even nothing.
Download: rghost.ru/39743296
Watching videos on youtube, how ubuntu is run on single-board computers like the Mele A1000 or MK802, I decided that I needed to do something with performance and at the same time run ArchLinux on this device, since this, for some reason, has not been done yet.
Performance problem
Why do we see that all devices on ARM and MIPS work so slowly as desktop systems? The reasons are many:
- All devices are different. Some support one set of commands, some - another. Some have FPUs, some do not. Some ARMv5, others ARMv6, third ARMv7
- Compiler non-optimized.
- Indiscretion / inaction of manufacturers.
- The complexity of support and the sluggishness of distribution maintainers.
If for the x86 the first is almost irrelevant, since everyone has FPUs and optimizations for a specific processor give no more than 5-10% of performance, then ARM devices can get a tremendous increase, for Mele it is something like 30% to 150% on complex tasks with a floating point (such as video decoding).
Since there is practically no full support in the mainline-core of real devices, and not test boards, we have to use a kernel from the manufacturer, which is good if the third branch. Moreover, changes to the core are often made through the backside, which is why in the configuration menu we get the missing dependencies between the options and almost the inability to port these changes to more recent kernels by means of enthusiasts (this, of course, not for everyone).
Maintainers of distributions do not want to spend power, computational power and disk space for additional repositories, and for a very long time they compiled everything either with FPU emulation or with softfp (it allows using FPU, but is compatible with emulation), but with optimizations for ARMv5, but About a little over a year ago, when the Cortex-A8 went to the masses, the maintainers thought about it and decided to try compiling everything with hardware floating point. So, ubuntu 12.04 was the first mass distribution in which the armhf repository appeared. This is a big progress, only it gives Cortex-A8 a gain of 20% -40%, compared to softfp, all applications are now built under ARMv7, but this is not enough.
To date, there are 3 distributions that have hardware floating point repositories: ArchLinux-ARM, Ubuntu, and Fedora. Because I love ArchLinux, the choice is obvious to me.
Devices
“Why do maintainers collect packages without NEON?”, You ask:
ARMv7 without NEON instruction set (for example, Marvell Armada in a CuBox device)
Cortex-A8 (ARMv7 + NEON, Chinese devices with Allwinner A10: Mele, MK802, MiniX)
Cortex-A9 without NEON (nVidia Tegra 2 in Toshiba AC100)
Cortex-A9 with NEON
It should be noted that the VFP in Cortex-A9 is already almost as fast as the NEON, and the optimization for NEON is more a matter of energy saving than of performance.
')
What was done
- Took the last U-Boot and kernel from dl.linux-sunxi.org/nightly/latest
- Recompiled important packages with NEON and Cortex-A8 optimizations (glibc, xz, bzip2, gzip, bash, openssl, zlib)
- Recompiled packages I have reached out to (mplayer2)
- Added video driver and GLES library (not sure about performance)
- Everything compiled Linaro GCC, because He is the most optimized for ARM.
CFLAGS:
march=armv7-a -mfloat-abi=hard -mfpu=neon -ftree-vectorize -mvectorize-with-neon-quad -mcpu=cortex-a8 -mtune=cortex-a8 -mthumb -O2 -pipe -fstack-protector --param=ssp-buffer-size=4 -D_FORTIFY_SOURCE=2Video hardware acceleration does not work.
It is not yet clear if gles works, because glxinfo says that direct rendering: yes, glxgears are spinning, but somehow not very. As a server, you can use.
How to write all this on a USB flash drive can be read on the link:
www.cnx-software.com/2012/07/20/nightly-builds-for-allwinner-a10-u-boot-linux-kernel-and-hardware-packs
To start the interface, go to ssh root / root and type startx
If you have the desire and opportunity to help, you love ArchLinux and want to see it on Chinese devices on Allwinner, please contact me.
And a little more information: Allwinner is working with XBMC on video acceleration in XBMC for Android. It will be a real STB, but now somehow there is even nothing.
Download: rghost.ru/39743296
Source: https://habr.com/ru/post/146877/
All Articles