wahlm
-
Posts
12 -
Joined
-
Last visited
Content Type
Forums
Store
Crowdfunding
Applications
Events
Raffles
Community Map
Posts posted by wahlm
-
-
I put some fresh armbian buster image to my cubieboard (1). Although no (real) application was installed, a load of around 20-30% could be seen. First I located the K-worker problem on A20 based boards thread and blacklisted sun4i_gpadc and sun4i_gpadc_iio. But after removing my display and booting the system still there was some kworker load almost stopping the system every 5-10 seconds.
Digging deeper I found a description and a possible solution of the problem. Looking a my Olimex A20 Lime2 which I am currently testing with the new olimage by Olimex because of the never solved gigabit problems of my board, the same behaviour could be seen. The modules sun4i_gpadc and sun4i_gpadc_iio were already blacklisted, but the headless system showed the same kworker activity. I tried the suggestion and removed the sun4i_drm_hdmi module and immediately the kworker activity stopped and load went down to almost 0.
Unfortunately the stock armbian kernel image configures CONFIG_DRM_SUN4I_HDMI not as module. So I had to build my own kernel with setting CONFIG_DRM_SUN4I to m. Then I could remove the sun4i_drm_hdmi module, too. I saw the expected behaviour: The kworker activities are gone and load went down to almost 0.
So my suggestion is to change the stock kernel configuration for CONFIG_DRM_SUN4I to module. Then headless users can blacklist the module sun4i_drm_hdmi and don't need to build their own kernels.
-
Hi,
unattended-upgrade is active by default. So updates (except kernel) are installed automatically. Have a look at /var/log/apt/history.log* for the installation history.
Bye,
wahlm
From my a20lime2 jessie headless server:
Start-Date: 2016-12-14 06:31:10
Commandline: /usr/bin/unattended-upgrade
Upgrade: apt:armhf (1.0.9.8.3, 1.0.9.8.4), libapt-pkg4.12:armhf (1.0.9.8.3, 1.0.9.8.4), apt-utils:armhf (1.0.9.8.3, 1.0.9.8.4), libapt-inst1.5:armhf (1.0.9.8.3, 1.0.9.8.4), apt-transport-https:armhf (1.0.9.8.3, 1.0.9.8.4)
End-Date: 2016-12-14 06:31:25
Start-Date: 2016-12-24 06:38:47
Commandline: /usr/bin/unattended-upgrade
Upgrade: libxml2:armhf (2.9.1+dfsg1-5+deb8u3, 2.9.1+dfsg1-5+deb8u4)
End-Date: 2016-12-24 06:38:49
-
Hi,
So if I understand it correctly, you don't have any reliability problems. This is not particularly surprising. For example, "only" around 20% of the Orange Pi PC boards are failing when the DRAM is clocked at 672MHz: the https://linux-sunxi.org/Orange_Pi_PC#DRAM_clock_speed_limit
Not every board is exactly identical. Some of them are overclockable, the others are not so much. The question is whether the happy 80% majority is willing to let these 20% of losers suffer
from what I read in the github PR, it seems I am more among the lucky 10% with a a20lime2 board running reliably at 480 Mhz
. But I always prefer reliability to speed, so I have no problem that the configuration is changed to 100% of the boards running reliably! My board even gets more reliable then .Bye,
wahlm
-
Hi,
Some of the memory bandwidth may be drained by the screen refresh. Even if you don't have any monitor connected, the board still might be trying to send some data over a non-connected HDMI interface and waste some memory bandwidth. If you are using an older 3.4 kernel, then you can try to run "echo 1 > /sys/devices/platform/disp/graphics/fb0/blank" command before running the benchmark.
yes, I still use the 3.4 kernel and blanking the HDMI improved the benchmark results a lot. So the values are even better than tkaiser's. Maybe his results were influenced by HDMI output, too.
Find my new tinymembench results for the a20lime2 below.
Bye,
wahlm
a20lime2:~/tinymembench# echo 1 > /sys/devices/platform/disp/graphics/fb0/blank a20lime2:~/tinymembench# ./tinymembench tinymembench v0.4.9 (simple benchmark for memory throughput and latency) ========================================================================== == Memory bandwidth tests == == == == Note 1: 1MB = 1000000 bytes == == Note 2: Results for 'copy' tests show how many bytes can be == == copied per second (adding together read and writen == == bytes would have provided twice higher numbers) == == Note 3: 2-pass copy means that we are using a small temporary buffer == == to first fetch data into it, and only then write it to the == == destination (source -> L1 cache, L1 cache -> destination) == == Note 4: If sample standard deviation exceeds 0.1%, it is shown in == == brackets == ========================================================================== C copy backwards : 257.2 MB/s (1.2%) C copy backwards (32 byte blocks) : 835.4 MB/s C copy backwards (64 byte blocks) : 881.3 MB/s C copy : 827.9 MB/s C copy prefetched (32 bytes step) : 856.1 MB/s C copy prefetched (64 bytes step) : 871.6 MB/s C 2-pass copy : 690.5 MB/s C 2-pass copy prefetched (32 bytes step) : 726.2 MB/s C 2-pass copy prefetched (64 bytes step) : 716.6 MB/s C fill : 2037.7 MB/s C fill (shuffle within 16 byte blocks) : 2037.8 MB/s C fill (shuffle within 32 byte blocks) : 355.7 MB/s (3.9%) C fill (shuffle within 64 byte blocks) : 381.4 MB/s (4.8%) --- standard memcpy : 540.2 MB/s standard memset : 2037.4 MB/s --- NEON read : 1202.0 MB/s NEON read prefetched (32 bytes step) : 1367.7 MB/s NEON read prefetched (64 bytes step) : 1359.0 MB/s NEON read 2 data streams : 353.0 MB/s NEON read 2 data streams prefetched (32 bytes step) : 673.5 MB/s NEON read 2 data streams prefetched (64 bytes step) : 708.1 MB/s NEON copy : 897.3 MB/s NEON copy prefetched (32 bytes step) : 898.8 MB/s NEON copy prefetched (64 bytes step) : 943.3 MB/s NEON unrolled copy : 920.6 MB/s NEON unrolled copy prefetched (32 bytes step) : 843.2 MB/s NEON unrolled copy prefetched (64 bytes step) : 880.7 MB/s NEON copy backwards : 850.2 MB/s NEON copy backwards prefetched (32 bytes step) : 876.2 MB/s NEON copy backwards prefetched (64 bytes step) : 919.8 MB/s NEON 2-pass copy : 754.6 MB/s NEON 2-pass copy prefetched (32 bytes step) : 794.8 MB/s NEON 2-pass copy prefetched (64 bytes step) : 813.1 MB/s NEON unrolled 2-pass copy : 677.1 MB/s NEON unrolled 2-pass copy prefetched (32 bytes step) : 633.9 MB/s NEON unrolled 2-pass copy prefetched (64 bytes step) : 677.5 MB/s NEON fill : 2037.9 MB/s NEON fill backwards : 2037.7 MB/s VFP copy : 927.5 MB/s VFP 2-pass copy : 685.8 MB/s ARM fill (STRD) : 2037.8 MB/s ARM fill (STM with 8 registers) : 2037.9 MB/s ARM fill (STM with 4 registers) : 2038.0 MB/s ARM copy prefetched (incr pld) : 914.2 MB/s ARM copy prefetched (wrap pld) : 861.5 MB/s ARM 2-pass copy prefetched (incr pld) : 764.6 MB/s ARM 2-pass copy prefetched (wrap pld) : 729.8 MB/s ========================================================================== == Framebuffer read tests. == == == == Many ARM devices use a part of the system memory as the framebuffer, == == typically mapped as uncached but with write-combining enabled. == == Writes to such framebuffers are quite fast, but reads are much == == slower and very sensitive to the alignment and the selection of == == CPU instructions which are used for accessing memory. == == == == Many x86 systems allocate the framebuffer in the GPU memory, == == accessible for the CPU via a relatively slow PCI-E bus. Moreover, == == PCI-E is asymmetric and handles reads a lot worse than writes. == == == == If uncached framebuffer reads are reasonably fast (at least 100 MB/s == == or preferably >300 MB/s), then using the shadow framebuffer layer == == is not necessary in Xorg DDX drivers, resulting in a nice overall == == performance improvement. For example, the xf86-video-fbturbo DDX == == uses this trick. == ========================================================================== NEON read (from framebuffer) : 50.2 MB/s NEON copy (from framebuffer) : 49.2 MB/s NEON 2-pass copy (from framebuffer) : 48.7 MB/s NEON unrolled copy (from framebuffer) : 47.5 MB/s NEON 2-pass unrolled copy (from framebuffer) : 48.0 MB/s VFP copy (from framebuffer) : 242.6 MB/s VFP 2-pass copy (from framebuffer) : 275.5 MB/s ARM copy (from framebuffer) : 176.3 MB/s ARM 2-pass copy (from framebuffer) : 166.5 MB/s ========================================================================== == Memory latency test == == == == Average time is measured for random memory accesses in the buffers == == of different sizes. The larger is the buffer, the more significant == == are relative contributions of TLB, L1/L2 cache misses and SDRAM == == accesses. For extremely large buffer sizes we are expecting to see == == page table walk with several requests to SDRAM for almost every == == memory access (though 64MiB is not nearly large enough to experience == == this effect to its fullest). == == == == Note 1: All the numbers are representing extra time, which needs to == == be added to L1 cache latency. The cycle timings for L1 cache == == latency can be usually found in the processor documentation. == == Note 2: Dual random read means that we are simultaneously performing == == two independent memory accesses at a time. In the case if == == the memory subsystem can't handle multiple outstanding == == requests, dual random read has the same timings as two == == single reads performed one after another. == ========================================================================== block size : single random read / dual random read 1024 : 0.0 ns / 0.0 ns 2048 : 0.0 ns / 0.0 ns 4096 : 0.0 ns / 0.0 ns 8192 : 0.0 ns / 0.0 ns 16384 : 0.0 ns / 0.0 ns 32768 : 0.0 ns / 0.0 ns 65536 : 6.2 ns / 10.8 ns 131072 : 9.7 ns / 15.1 ns 262144 : 13.1 ns / 19.0 ns 524288 : 104.0 ns / 164.7 ns 1048576 : 154.8 ns / 216.7 ns 2097152 : 187.0 ns / 241.8 ns 4194304 : 203.7 ns / 252.2 ns 8388608 : 214.2 ns / 260.3 ns 16777216 : 225.6 ns / 273.7 ns 33554432 : 242.0 ns / 301.4 ns 67108864 : 272.5 ns / 361.8 ns
-
Hi,
I would suggest to use an improved version of a10-meminfo from https://github.com/ssvb/a10-dram-tools
again thanks for the hint. It seems I missed a lot of already available info
. But my boards worked reliably up to now, so there was no need to dig into investigation.Anyway, here are the results of the improved version of a10-meminfo for the a20lime2. Seems the (already existing) values of the older version are still reliable.
Bye,
wahlm
a20lime2:~/a10-dram-tools# ./a10-meminfo dram_clk = 480 mbus_clk = 300 dram_type = 3 dram_rank_num = 1 dram_chip_density = 4096 dram_io_width = 16 dram_bus_width = 32 dram_cas = 9 dram_zq = 0x7b (0x5294a00) dram_odt_en = 0 dram_tpr0 = 0x42d899b7 dram_tpr1 = 0xa090 dram_tpr2 = 0x22a00 dram_tpr3 = 0x0 dram_emr1 = 0x4 dram_emr2 = 0x10 dram_emr3 = 0x0 dqs_gating_delay = 0x05050505 active_windowing = 0
-
Hi,
Just remove this kernel cmdline option. It serves no purpose anyway: https://github.com/linux-sunxi/linux-sunxi/commit/90e6c43fe04755947e252c3796c6b5c00e47df02
ok, thanks for the hint! From what I remember, I did not set that option and therefore it is/was part of the armbian default config. Anyway I removed it from the kernel cmdline of my a20lime2 and ran lima-memtester 100M without a problem for about 80 minutes. As it is a headless system I could not check the cube animations, but no error was reported at the (ssh-)console and there were 5 full loops reached at this time.
I then cancelled the test to check the DRAMs on the board. It has Samsung K4B4G1646D-BCK0 (datecode 516) assembled. In addition I saw that I placed a heatsink to the A20 (forgot about that...). The board is housed in the standard Olimex plastic case. My board is Rev.C.
Bye,
wahlm
-
Hi,
as an addition here are the a10-meminfo results from my CubieBoard 1 and CubieTruck both running cubian. At least the CubieTruck shows a lower dram_clk.
Both systems run 24h/7d since a long time (1-2 years) without problems and have 2,5" HDDs attached via SATA.
But it has to be verified that the results of a10-meminfo are reliable...
Bye,
wahlm
root@cubie:~/a10-meminfo# ./a10-meminfo dram_clk = 480 dram_type = 3 dram_rank_num = 1 dram_chip_density = 4096 dram_io_width = 16 dram_bus_width = 32 dram_cas = 6 dram_zq = 0x7b dram_odt_en = 0 dram_tpr0 = 0x30926692 dram_tpr1 = 0x1090 dram_tpr2 = 0x1a0c8 dram_tpr3 = 0x0 dram_emr1 = 0x0 dram_emr2 = 0x0 dram_emr3 = 0x0 root@ctruck:~/a10-meminfo# ./a10-meminfo dram_clk = 432 dram_type = 3 dram_rank_num = 1 dram_chip_density = 8192 dram_io_width = 16 dram_bus_width = 32 dram_cas = 9 dram_zq = 0x7f dram_odt_en = 0 dram_tpr0 = 0x42d899b7 dram_tpr1 = 0xa090 dram_tpr2 = 0x22a00 dram_tpr3 = 0x0 dram_emr1 = 0x4 dram_emr2 = 0x10 dram_emr3 = 0x0
-
Hi,
I just tried a10-meminfo on my stable a20lime2 and a10lime with the old u-boot versions (see below). Funny thing is that the tool is reporting 480 Mhz for both systems!
I tried running lima-memtester, but both systems are server/headless and use sunxi_no_mali_mem_reserve in kernel command line. So lima-memtester is terminating at start.
The question is why my a20lime2 tinymembench results compared to the results of tkaiser's are showing a lower performance. Maybe there are some other parameters beside the dram_clk involved? Or does it depend on the type/vendor of RAM used on the board?
Bye,
wahlm
root@a10lime:~/a10-meminfo# ./a10-meminfo dram_clk = 480 dram_type = 3 dram_rank_num = 1 dram_chip_density = 4096 dram_io_width = 16 dram_bus_width = 16 dram_cas = 6 dram_zq = 0x7b dram_odt_en = 0 dram_tpr0 = 0x30926692 dram_tpr1 = 0x1090 dram_tpr2 = 0x1a0c8 dram_tpr3 = 0x0 dram_emr1 = 0x4 dram_emr2 = 0x0 dram_emr3 = 0x0 a20lime2:~/a10-meminfo# ./a10-meminfo dram_clk = 480 dram_type = 3 dram_rank_num = 1 dram_chip_density = 4096 dram_io_width = 16 dram_bus_width = 32 dram_cas = 9 dram_zq = 0x7b dram_odt_en = 0 dram_tpr0 = 0x42d899b7 dram_tpr1 = 0xa090 dram_tpr2 = 0x22a00 dram_tpr3 = 0x0 dram_emr1 = 0x4 dram_emr2 = 0x10 dram_emr3 = 0x0
-
Hi,
I installed my a20lime2 in october 2015 (it was Armbian_4.5_Lime2_Debian_jessie_3.4.109) and although not highly loaded worked since then without a single problem or crash. So I was quite astonished about the problems reported in this thread. I frequently updated the system using aptitude. So I tried to find out why my system is working stable.
I have a 2,5" HDD connected via SATA and I had done a rsync of around 600GB to the a20lime2 short time ago and it succeeded without a problem.
Anyway, I found out that although the deb-packages for kernel, firmware and root filesystem were installed and so updated regularily, the u-boot deb-package was not installed! So I found out that I still use the u-boot of the installation image:
a20lime2:~/tinymembench# dd if=/dev/mmcblk0 bs=48K count=1 | strings | grep -i "U-Boot" 1+0 records in 1+0 records out 49152 bytes (49 kB) copied, 0.0081478 s, 6.0 MB/s U-Boot U-Boot SPL 2015.07-armbian-sun7i (Oct 11 2015 - 16:53:01) U-Boot 2015.07-armbian-sun7i for
I thought the missing u-boot deb-package was my fault, but I checked my armbian a10lime (first install with Armbian_5.00_Lime-a10_Debian_jessie_3.4.110) and found it missing there, too. It still had U-Boot SPL 2016.01-armbian-sun7i (Feb 10 2016 - 20:08:59) installed. So either I did something systematically wrong or the deb-package was not installed on these old images.
Maybe this can explain why users with old and updated installations (like me) don't see the problem.
I added my tinymembench results at the bottom. Comparing the results, it confirms that my board is running at a lower DRAM-speed than tkaiser's.
Bye,
wahlm
a20lime2:~/tinymembench# ./tinymembench
tinymembench v0.4.9 (simple benchmark for memory throughput and latency)
==========================================================================
== Memory bandwidth tests ==
== ==
== Note 1: 1MB = 1000000 bytes ==
== Note 2: Results for 'copy' tests show how many bytes can be ==
== copied per second (adding together read and writen ==
== bytes would have provided twice higher numbers) ==
== Note 3: 2-pass copy means that we are using a small temporary buffer ==
== to first fetch data into it, and only then write it to the ==
== destination (source -> L1 cache, L1 cache -> destination) ==
== Note 4: If sample standard deviation exceeds 0.1%, it is shown in ==
== brackets ==
==========================================================================
C copy backwards : 230.6 MB/s (0.9%)
C copy backwards (32 byte blocks) : 704.1 MB/s (1.3%)
C copy backwards (64 byte blocks) : 723.9 MB/s (1.7%)
C copy : 594.2 MB/s (0.2%)
C copy prefetched (32 bytes step) : 695.9 MB/s (0.7%)
C copy prefetched (64 bytes step) : 700.7 MB/s (0.8%)
C 2-pass copy : 553.2 MB/s (0.2%)
C 2-pass copy prefetched (32 bytes step) : 590.4 MB/s
C 2-pass copy prefetched (64 bytes step) : 603.4 MB/s (0.5%)
C fill : 1571.4 MB/s (0.6%)
C fill (shuffle within 16 byte blocks) : 1572.7 MB/s (0.5%)
C fill (shuffle within 32 byte blocks) : 301.7 MB/s (2.4%)
C fill (shuffle within 64 byte blocks) : 316.4 MB/s (2.7%)
---
standard memcpy : 454.3 MB/s
standard memset : 1571.7 MB/s (0.7%)
---
NEON read : 963.8 MB/s
NEON read prefetched (32 bytes step) : 1131.9 MB/s
NEON read prefetched (64 bytes step) : 1145.7 MB/s (0.2%)
NEON read 2 data streams : 324.0 MB/s (0.7%)
NEON read 2 data streams prefetched (32 bytes step) : 603.5 MB/s
NEON read 2 data streams prefetched (64 bytes step) : 635.2 MB/s (0.6%)
NEON copy : 633.8 MB/s (0.7%)
NEON copy prefetched (32 bytes step) : 719.1 MB/s
NEON copy prefetched (64 bytes step) : 738.2 MB/s (0.8%)
NEON unrolled copy : 640.0 MB/s (0.6%)
NEON unrolled copy prefetched (32 bytes step) : 675.4 MB/s (0.7%)
NEON unrolled copy prefetched (64 bytes step) : 711.1 MB/s (0.7%)
NEON copy backwards : 715.8 MB/s (0.8%)
NEON copy backwards prefetched (32 bytes step) : 733.0 MB/s (0.7%)
NEON copy backwards prefetched (64 bytes step) : 759.4 MB/s
NEON 2-pass copy : 594.2 MB/s
NEON 2-pass copy prefetched (32 bytes step) : 647.0 MB/s (0.7%)
NEON 2-pass copy prefetched (64 bytes step) : 660.9 MB/s (0.7%)
NEON unrolled 2-pass copy : 526.7 MB/s (0.3%)
NEON unrolled 2-pass copy prefetched (32 bytes step) : 506.7 MB/s (0.5%)
NEON unrolled 2-pass copy prefetched (64 bytes step) : 542.1 MB/s (0.4%)
NEON fill : 1568.9 MB/s
NEON fill backwards : 1652.2 MB/s
VFP copy : 650.8 MB/s (0.7%)
VFP 2-pass copy : 525.8 MB/s (0.4%)
ARM fill (STRD) : 1570.9 MB/s (0.7%)
ARM fill (STM with 8 registers) : 1570.5 MB/s (0.8%)
ARM fill (STM with 4 registers) : 1571.3 MB/s
ARM copy prefetched (incr pld) : 732.3 MB/s (0.7%)
ARM copy prefetched (wrap pld) : 627.4 MB/s
ARM 2-pass copy prefetched (incr pld) : 628.6 MB/s (0.7%)
ARM 2-pass copy prefetched (wrap pld) : 585.3 MB/s
==========================================================================
== Framebuffer read tests. ==
== ==
== Many ARM devices use a part of the system memory as the framebuffer, ==
== typically mapped as uncached but with write-combining enabled. ==
== Writes to such framebuffers are quite fast, but reads are much ==
== slower and very sensitive to the alignment and the selection of ==
== CPU instructions which are used for accessing memory. ==
== ==
== Many x86 systems allocate the framebuffer in the GPU memory, ==
== accessible for the CPU via a relatively slow PCI-E bus. Moreover, ==
== PCI-E is asymmetric and handles reads a lot worse than writes. ==
== ==
== If uncached framebuffer reads are reasonably fast (at least 100 MB/s ==
== or preferably >300 MB/s), then using the shadow framebuffer layer ==
== is not necessary in Xorg DDX drivers, resulting in a nice overall ==
== performance improvement. For example, the xf86-video-fbturbo DDX ==
== uses this trick. ==
==========================================================================
NEON read (from framebuffer) : 45.0 MB/s
NEON copy (from framebuffer) : 44.3 MB/s
NEON 2-pass copy (from framebuffer) : 43.6 MB/s
NEON unrolled copy (from framebuffer) : 43.7 MB/s (0.3%)
NEON 2-pass unrolled copy (from framebuffer) : 43.3 MB/s
VFP copy (from framebuffer) : 240.7 MB/s (0.5%)
VFP 2-pass copy (from framebuffer) : 248.4 MB/s (0.5%)
ARM copy (from framebuffer) : 165.7 MB/s (0.7%)
ARM 2-pass copy (from framebuffer) : 150.3 MB/s
==========================================================================
== Memory latency test ==
== ==
== Average time is measured for random memory accesses in the buffers ==
== of different sizes. The larger is the buffer, the more significant ==
== are relative contributions of TLB, L1/L2 cache misses and SDRAM ==
== accesses. For extremely large buffer sizes we are expecting to see ==
== page table walk with several requests to SDRAM for almost every ==
== memory access (though 64MiB is not nearly large enough to experience ==
== this effect to its fullest). ==
== ==
== Note 1: All the numbers are representing extra time, which needs to ==
== be added to L1 cache latency. The cycle timings for L1 cache ==
== latency can be usually found in the processor documentation. ==
== Note 2: Dual random read means that we are simultaneously performing ==
== two independent memory accesses at a time. In the case if ==
== the memory subsystem can't handle multiple outstanding ==
== requests, dual random read has the same timings as two ==
== single reads performed one after another. ==
==========================================================================
block size : single random read / dual random read
1024 : 0.0 ns / 0.0 ns
2048 : 0.0 ns / 0.0 ns
4096 : 0.0 ns / 0.0 ns
8192 : 0.0 ns / 0.0 ns
16384 : 0.0 ns / 0.0 ns
32768 : 0.0 ns / 0.0 ns
65536 : 6.8 ns / 10.8 ns
131072 : 10.7 ns / 15.1 ns
262144 : 14.1 ns / 19.5 ns
524288 : 112.3 ns / 176.5 ns
1048576 : 167.1 ns / 233.7 ns
2097152 : 201.2 ns / 260.7 ns
4194304 : 219.5 ns / 272.0 ns
8388608 : 230.4 ns / 280.6 ns
16777216 : 242.4 ns / 294.9 ns
33554432 : 260.8 ns / 328.5 ns
67108864 : 297.0 ns / 398.2 ns -
Hi Baos,
the mac address is not invalid, but it is marked as a locally administered address. The mac addresses devices usually get from their manufacturer are universally administered addresses. So it seems the SW on your router doesn't like these perfectly valid addresses.
I fear Igor doesn't have an Organizationally Unique Identifier (OUI) to create UAA mac addresses
, so LAA is the correct way to go.Bye,
wahlm
-
Hi Igor and all,
after running armbian on my A20 lime2 for a long time, I decided to switch to armbian on my A10 lime, too (from jessie with a eewiki-based self-compiled kernel). So far it works as perfect as the A20, but there are two small and funny things with the
Armbian_5.00_Lime-a10_Debian_jessie_3.4.110.zip
image I used:
After login the nice armbian banner stated that my A10 lime is a cubieboard
. I have a cubieboard, too. So I double checked...The problem is located in /etc/init.d/armhwinfo, There all "sun4i" boards are simply "Cubieboard". I had to adapt the LED check which is
used to detect Lime and Lime2 a bit and added the Lime A10. I checked the LEDs path on my cubian based cubieboard 1 and it
was different, so hopefully the LED check correctly detects the Lime A10.
During test (restarting service armhwinfo) I saw that the detected ID is appended to /var/run/machine.id. I had a funny banner with Cubieboard and 2 times Lime A10
.Here is what I changed finally:
--- armhwinfo.org 2016-02-11 23:58:47.000000000 +0100 +++ armhwinfo 2016-04-07 12:17:16.848138250 +0200 @@ -17,6 +17,8 @@ HARDWARE=$(cat /proc/cpuinfo | grep Hardware | awk '{print $3}') GMAC=$(dmesg | grep "sun6i_gmac") LEDS=$(dmesg |grep "green:ph02:led1") +# a10 lime +LEDS2=$(dmesg |grep "green:ph2:led1") TERMINUS=$(lsusb | grep "1a40:0101") SWITCH=$(dmesg | grep "BCM53125") INTERUPT=$(cat /proc/interrupts | grep "eth0") @@ -55,8 +57,12 @@ ID="Orange H3" fi if [ $HARDWARE = "sun4i" ] || [ $HARDWARE = "Allwinner" ]; then + if [ "$LEDS2" != "" ]; then + ID="Lime A10" + else ID="Cubieboard" fi + fi if [ $HARDWARE = "sun7i" ] || [ $HARDWARE = "Allwinner" ]; then # redistribute irq to dedicated core if [ "$INTERUPT" != "" ] && [ "$CORES" -gt 1 ]; then @@ -115,7 +121,7 @@ if [[ $MACHINE == *M2* ]]; then ID="Banana M2"; fi echo -e "[\e[0;32m ok \x1B[0m] Starting ARM hardware info: $ID" -echo $ID >> /var/run/machine.id +echo $ID > /var/run/machine.id ;; stop|reload|restart|force-reload|status) echo -e "[\e[0;32m ok \x1B[0m] Stopping ARM hardware info ..."The second issue was an (compared to the A20) incredibly high temperature: 72,2.
I checked /etc/update-motd.d/30-sysinfo and found out that although it is commented as "only on A20", the a20-tp-hwmon reading
is available at the A10 lime, too. Whatever this value is, the correct temperature seems to be at i2c. I got a 37,8 there.
So I commented out the A20 temp reading, but this is surely just a quick hack...
--- 30-sysinfo.org 2016-02-11 23:58:47.000000000 +0100 +++ 30-sysinfo 2016-04-06 23:06:55.713259579 +0200 @@ -106,9 +106,9 @@ fi # if we are reading from A20 -if [ -d "/sys/devices/platform/a20-tp-hwmon/" ]; then - board_temp=$(cat /sys/devices/platform/a20-tp-hwmon/temp1_input | awk '{printf("%d",$1/1000)}') -fi +#if [ -d "/sys/devices/platform/a20-tp-hwmon/" ]; then +# board_temp=$(cat /sys/devices/platform/a20-tp-hwmon/temp1_input | awk '{printf("%d",$1/1000)}') +#fi # where it should be if [ -d "/sys/devices/virtual/thermal/thermal_zone0/" ]; thenFinally I want to send you a big thank you for providing armbian!
Bye,
wahlm
Headless systems and sun4i_drm_hdmi (A10/A20/...)
in Advanced users - Development
Posted
Thanks for the suggestion! I just forked the repo and will provide a PR.