Jump to content

Armbian customization

chradev

By chradev
in Allwinner sunxi

 Share

Recommended Posts

chradev

chradev

Posted
  • Author
Posted

Hi to All,

 

After pause I have tried to build Armbian with little changes in customization.

I have started from the scratch with idea to keep latest build as-is.

 

There is a view changes: Armbian rev. from 5.12 to 5.14; Kernel rev. from 4.5.5 to 4.6.2.

After first start a new set of compilers have been updated as well.

 

First try to build the kernel fails without any reason and errors.

Second Armbian build finished with 2 problems.

 

Command 'svn' I am using was not recognized.

After some search I found that subversion package was omitted and I have to add it to lib.config.

 

The second problem was very strange and related to RPI-Monitor installation.

Procedure to add RPI-Monitor repository to the aptitude source list was successful but apt-get update rise following errors:

Get:46 https://github.com XavierBerger/RPi-Monitor-deb/raw/master/repo/ Translation-en_US
Get:47 https://github.com XavierBerger/RPi-Monitor-deb/raw/master/repo/ Translation-en
Get:48 https://github.com XavierBerger/RPi-Monitor-deb/raw/master/repo/ Translation-en_US.UTF-8
Err https://github.com XavierBerger/RPi-Monitor-deb/raw/master/repo/ Packages
  Bad header line
Get:49 https://github.com XavierBerger/RPi-Monitor-deb/raw/master/repo/ Translation-en_US
Ign https://github.com XavierBerger/RPi-Monitor-deb/raw/master/repo/ Translation-en_US
Get:50 https://github.com XavierBerger/RPi-Monitor-deb/raw/master/repo/ Translation-en
Ign https://github.com XavierBerger/RPi-Monitor-deb/raw/master/repo/ Translation-en
Get:51 https://github.com XavierBerger/RPi-Monitor-deb/raw/master/repo/ Translation-en_US.UTF-8
Ign https://github.com XavierBerger/RPi-Monitor-deb/raw/master/repo/ Translation-en_US.UTF-8
Fetched 11.5 MB in 18s (625 kB/s)
W: Failed to fetch https://github.com/XavierBerger/RPi-Monitor-deb/raw/master/repo/Packages  Bad header line

E: Some index files failed to download. They have been ignored, or old ones used instead.

and the package and its dependencies can not be installed.

 

I did not find a way to solve the problem so install them manually.

 

Any ideas how to install RPI-Minitor at the customization process preferably or using apt-get at the firstrun script?

 

EDIT: I have found another package omitted : firmware-ralink - where to find the list of changes?

 

Best regards

Chris

chradev

chradev

Posted
  • Author
Posted

Hi Igor,

  On 6/20/2016 at 8:20 AM, Igor said:

Actually we never had firmware-ralink installed by default but our own firmware package which was recently reorganized. It's possible that something fell out. Which firmware do you miss?

 

https://github.com/igorpecovnik/lib/blob/master/extras/firmware.sh

Sorry for the delayed answer but in some reason notification stops working for me or cannot set it up.

 

I am using Olimex' MOD-WIFI-R5370-ANT module which searches for rt2870.bin.

That is way I have added firmware-ralink package to lib.config.

 

Best regards

Chris

chradev

chradev

Posted
  • Author
Posted

Hi to All,

 

After pause I have rebuild customized by me Armbian.

 

Meanwhile:

  • Armbian was migrated to ver. 5.15 and kernel ver. 4.6.3;
  • I move RP Monitor package to PACKAGE_LIST_ADDITIONAL in lib.config;
  • Other changes are minor.

After clean rebuild I have reached 2 problems:

 

In some reason patched and compiled version of sun7i-a20-olinuxino-lime2.dtb is not packed into the image.

Packed into the image file sun7i-a20-olinuxino-lime2.dtb seems to be without my patches.

File sun7i-a20-olinuxino-lime2.dts in the kernel source place is patched and compiled as expected.

After manual copying it from the kernel source place to /boot/dtb and restarting everything is ok.

 

RPI Monitor is installed but the version is old (2.9) and some functionality is missing.

As I suppose Igor put latest RPI Monitor version (2.10) into Armbian package repository.

Manual apt-get update/upgrade reported the system is up-to-date.

 

Where these problems come from?

 

Best regards

Chris

Igor

Igor

Posted
Posted
  Quote

RPI Monitor is installed but the version is old (2.9) and some functionality is missing.

As I suppose Igor put latest RPI Monitor version (2.10) into Armbian package repository.

Manual apt-get update/upgrade reported the system is up-to-date.

 

Actually I did a mistake and put an older version to repository, but it's corrected now, thanks. For DT patch, I would need to look deeper.

chradev

chradev

Posted
  • Author
Posted

Thanks Igor,

 

After apt-get update/upgrade RPI Monitor ver. 2.10 is installed.

RPI Monitor ver. 2.10 is also installed at image build.

 

It may not be related to Device Tree problem but I get following error messages at build time:

...

[ o.k. ] Starting build process for [ lime2 jessie ]
rm: cannot remove ‘/data/armbian-cust/output/cache/sdcard’: Device or resource busy
[ o.k. ] Extracting jessie-ng-armhf.f9b...65e.tgz [ 0 days old ]

...

[ o.k. ] Installing additional application [ USB redirector ]
cp: cannot stat ‘/data/armbian-cust/sources/usb-redirector-linux-arm-eabi/files/modules/src/tusbd/tusbd.ko’: No such file or directory
[ o.k. ] Calling host customization script [ customize-image-host.sh ]
[ o.k. ] Calling image customization script [ customize-image.sh ]

...

[ o.k. ] Done building [ /data/armbian-cust/output/images/Armbian_5.15_Lime2_Debian_jessie_4.6.3.raw ]
umount: /data/armbian-cust/output/cache/sdcard: device is busy.
        (In some cases useful info about processes that use
         the device is found by lsof(8) or fuser(1))
rm: cannot remove ‘/data/armbian-cust/output/cache/sdcard’: Device or resource busy
[ o.k. ] Runtime [ 9 min ]

Best regards

Chris

chradev

chradev

Posted
  • Author
Posted

Hi to All,

 

In addition to described above Device Tree problem I found one more with eMMC on my Lime2-eMMC.

After changing sun7i-a20-olinuxino-lime2.dtb with one from the build place of the kernel source tree eMMC did not work as before.

 

There you are boot messages from latest kernel 4.6.3:

 

  Reveal hidden contents

 

and 'lsblk' command output:

root@egpr:~# lsblk
NAME         MAJ:MIN RM  SIZE RO TYPE MOUNTPOINT
sda            8:0    0 55.9G  0 disk
├─sda1         8:1    0    5G  0 part
└─sda2         8:2    0 50.9G  0 part /media/sda2
mmcblk1boot0 179:16   0   16M  1 disk
mmcblk1boot1 179:24   0   16M  1 disk
mmcblk0      179:0    0  3.7G  0 disk
└─mmcblk0p1  179:1    0  3.5G  0 part /
mmcblk1      179:8    0  3.6G  0 disk

The errors like in 'dmesg' are printed after 'lsblk' kommand execution as well.

 

I have 2 Lime2-eMMC boards and they both do not work with new 4.6.3 kernel while working perfect with the kernels up to 4.6.2.

 

Any ideas where to search the problem?

 

Best regards

Chris

chradev

chradev

Posted
  • Author
Posted

Hi to All,

 

Today after rebuilding customized image for Lime2-eMMC I found that:

  • Armbian version was changed to 5.16
  • Kernel version is the same 4.6.3

and Device Tree problem described above is disappeared.

 

@Igor

What is changed for solving the DT problem?

 

Best regards

Chris

Igor

Igor

Posted
Posted
  Quote
What is changed for solving the DT problem?

 

I haven't done anything in this area.

chradev

chradev

Posted
  • Author
Posted

Hi Igor,

 

While trying to solve another build problem I found strange build behavior.

 

In 'lib.config' KERNELBRANCH is set to v4.6.2 but kernel version 4.6.3 is also present from previous build.

Build scripts check against v4.6.2 but final image is against v4.6.3.

 

 

  Reveal hidden contents

 

 

I did not observe such a behavior if kernel has to be rebuild.

 

Best regards

Chris

chradev

chradev

Posted
  • Author
Posted

Hi Igor,

 

One more uncleanly solved problem without any intervention:

 

In my custom build from customize-image.sh script I install Node.JS and a few modules.

Some of modules have native build and everything was perfect till Armbian ver. 5.16 when process crashes:

 

 

  Reveal hidden contents

 

 

The try to build inside the same environment against kernel version 4.6.2 has no problems.

The build with previous Armbian 5.15 with kernel 4.6.3 had no such problem as well.

 

And after a day tests to find the reason the build passes ok without anything done by me.

Meanwhile, there ware no changes in Armbian build scripts, build host and other staff incl. crashing package (utf8-validate).

 

Could be some instability in Armbian?

 

EDIT: Build with Armbian 5.17 and kernel 4.6.3 has no problems as well.

 

Best regards

Chris

chradev

chradev

Posted
  • Author
Posted

Hi to All,

 

I have just experiment with scripting of eMMC and SATA SSD/HDD updates.

They can manually write an Armbian image from second SSD partition while the system is booted from SD card.

 

Script to write Armbian image to eMMC:

 

  Reveal hidden contents

 

 

Script to write Armbian image to SATA SSD:

 

  Reveal hidden contents

 

 

Best regards

Chris

 

chradev

chradev

Posted
  • Author
Posted

Hi to All,

 

I am trying to choose the way to make eMMC root FS read only.

 

The main requirements are:

  • The same Armbian image has to be installed on both SSD (R/W root) and eMMC (RO root);
  • Armbian has to be used "as-is" and customized via corresponding scripts;
  • Firmware update of both SSD and eMMC has to be done without user participation at all;
  • U-Boot (with or without user intervention) will choose where to boot from (as described in this thread before);

As a reference following links can be helpful:

 

Any thoughts, recommendation and / or references to other projects or sources are welcome

 

Best regards

Chris

 

tkaiser

tkaiser

Posted
Posted

Sorry to disturb with another round of problems and providing no answer to the questions from last post.

 

I switched to user role, downloaded Armbian 5.14 (4.6.2, Xenial --> Armbian_5.14_Lime2_Ubuntu_xenial_4.6.2.7z), burned it to an SD card, booted my rather old Lime2... just to realize that a simple 'apt-get update' takes ages.

 

A quick iperf:

[  5]  0.0-10.0 sec   903 MBytes   757 Mbits/sec
[  4]  0.0-55.0 sec   256 KBytes  38.1 Kbits/sec

(yeah, Kbits/sec). So obviously our default install suffers from the broken networking on Lime2 but how to recover from this? I found the tip to revert back to u-boot 2015.10 and am building currently u-boot+kernel to try this out. I also installed @chradev's u-boot .deb from this thread before (but to no avail). My 'armbianmonitor -u' output as follows: http://sprunge.us/EHCh

 

Any ideas? Preferrable how we can solve this for all our Lime2 users?

chradev

chradev

Posted
  • Author
Posted

Hi tkaiser,

  On 7/14/2016 at 2:44 PM, tkaiser said:

Sorry to disturb with another round of problems and providing no answer to the questions from last post.

 

I switched to user role, downloaded Armbian 5.14 (4.6.2, Xenial --> Armbian_5.14_Lime2_Ubuntu_xenial_4.6.2.7z), burned it to an SD card, booted my rather old Lime2... just to realize that a simple 'apt-get update' takes ages.

 

A quick iperf:

[  5]  0.0-10.0 sec   903 MBytes   757 Mbits/sec
[  4]  0.0-55.0 sec   256 KBytes  38.1 Kbits/sec

(yeah, Kbits/sec). So obviously our default install suffers from the broken networking on Lime2 but how to recover from this? I found the tip to revert back to u-boot 2015.10 and am building currently u-boot+kernel to try this out. I also installed @chradev's u-boot .deb from this thread before (but to no avail). My 'armbianmonitor -u' output as follows: http://sprunge.us/EHCh

 

Any ideas? Preferrable how we can solve this for all our Lime2 users?

 

For solving Lime2 GBit Ethernet issue I am using Olimex' patch as described in my post here:

diff --git a/drivers/net/phy/phy.c b/drivers/net/phy/phy.c
index a6023f1..b76e496 100644
--- a/drivers/net/phy/phy.c
+++ b/drivers/net/phy/phy.c
@@ -170,6 +170,11 @@ int genphy_config_aneg(struct phy_device *phydev)
 {
     int result;
 
+    /* If PHY id is RTL8211CL then force MASTER configuration.
+     * No that two master PHYs cannot be connected directly! */
+    if(phydev->phy_id == 0x001cc912)
+        phy_write(phydev, MDIO_DEVAD_NONE, 0x09, 0x1B00);
+
     if (AUTONEG_ENABLE != phydev->autoneg)
         return genphy_setup_forced(phydev);

There is other solutions but above patch is working for me till now (Armbian 5.17, Debian jessie, kernel 4.6.3, uboot 2016.05 ).

You can also take a look on my post about SDC/eMMC support/booting and slow Ethernet fix.

I have many measures pointing the issue is solved at least for the boards Lime2-4GB (HW rev. C) and Lime2-eMMC (HW rev. E).

 

Best regards

Chris

tkaiser

tkaiser

Posted
Posted
  On 7/14/2016 at 3:18 PM, chradev said:

For solving Lime2 GBit Ethernet issue I am using Olimex' patch as described in my post here:

diff --git a/drivers/net/phy/phy.c b/drivers/net/phy/phy.c
index a6023f1..b76e496 100644
--- a/drivers/net/phy/phy.c
+++ b/drivers/net/phy/phy.c
@@ -170,6 +170,11 @@ int genphy_config_aneg(struct phy_device *phydev)
 {
     int result;
 
+    /* If PHY id is RTL8211CL then force MASTER configuration.
+     * No that two master PHYs cannot be connected directly! */
+    if(phydev->phy_id == 0x001cc912)
+        phy_write(phydev, MDIO_DEVAD_NONE, 0x09, 0x1B00);
+
     if (AUTONEG_ENABLE != phydev->autoneg)
         return genphy_setup_forced(phydev);

 

Thx, for whatever reasons simply exchanging u-boot with 2016.05 containing this patch didn't work. I re-created a whole new image with

./compile.sh \
	KERNEL_ONLY=no \
	BOARD=lime2 \
	PROGRESS_DISPLAY=plain \
	RELEASE=xenial \
	EXTENDED_DEBOOTSTRAP=yes \
	COMPRESS_OUTPUTIMAGE=no \
	FIXED_IMAGE_SIZE=4096 \
	ROOTFS_TYPE=btrfs

and this worked. Ethernet performance still isn't optimal but that's ok since the Lime2 will be playing webserver at a customer's location and more than 200 Mbits/sec aren't necessary. http://sprunge.us/eBZI

 

So thinking about our user base... how to proceed with Lime2? If I understood correctly the patch now prevents negotiation of a direct network connection between two hosts and only connections with a switch in between will work. I would suppose that's the 99 percent use case of Lime2 users therefore why not enabling this patch by default?

1
chradev

chradev

Posted
  • Author
Posted
  On 7/14/2016 at 6:16 PM, tkaiser said:

Thx, for whatever reasons simply exchanging u-boot with 2016.05 containing this patch didn't work. I re-created a whole new image with

./compile.sh \
	KERNEL_ONLY=no \
	BOARD=lime2 \
	PROGRESS_DISPLAY=plain \
	RELEASE=xenial \
	EXTENDED_DEBOOTSTRAP=yes \
	COMPRESS_OUTPUTIMAGE=no \
	FIXED_IMAGE_SIZE=4096 \
	ROOTFS_TYPE=btrfs

and this worked. Ethernet performance still isn't optimal but that's ok since the Lime2 will be playing webserver at a customer's location and more than 200 Mbits/sec aren't necessary. http://sprunge.us/eBZI

 

So thinking about our user base... how to proceed with Lime2? If I understood correctly the patch now prevents negotiation of a direct network connection between two hosts and only connections with a switch in between will work. I would suppose that's the 99 percent use case of Lime2 users therefore why not enabling this patch by default?

I have measured up to 900 Mbps with Lime2 boards with HW rev. C and E after adding that patch.

Take a look on this post: http://forum.armbian.com/index.php/topic/853-armbian-customization/page-4#entry8074

 

Really the problem come from negotiation and the patch overcome it setting Lime2 PHY as master.

 

I have successfully connect Lime2 with other computers using direct cable (without Ethernet switch).

The only case will not work is if the other port is also set to master.

 

In my opinion this patch can be enabled for all users and cases using A20.

 

Best regards

Chris

chradev

chradev

Posted
  • Author
Posted

Hi Igor,

 

After today's rebuild of Armbian I get following error after login:

egpr login: root
Password:
Last login: Wed Jul 20 03:48:49 EEST 2016 on ttyS0
Linux egpr 4.6.4-sunxi #1 SMP Sun Jul 17 18:33:28 EEST 2016 armv7l
/etc/update-motd.d/30-sysinfo: command substitution: line 90: syntax error near unexpected token `)'
/etc/update-motd.d/30-sysinfo: command substitution: line 90: `free -m | { awk '/Swap/ { printf("%3.0f", $3/$2*100) }' 2>/dev/null || echo 0 } | sed 's/ //g')'

The file '/etc/update-motd.d/30-sysinfo' was changed at last Armbian update from the repository.

 

Best regards

Chris

chradev

chradev

Posted
  • Author
Posted

Hi to All,

 

These days I have received a new Lime2-eMMC board from Olimex and mount it in one of my prototypes.

 

Unfortunately, the new board is hanging continuously and its behavior and details was reported on Olimex' forum:

  https://www.olimex.com/forum/index.php?topic=5419

 

Any ideas about how to identify the problem source are welcome

 

Find attached some RPI Monitor charts.

 

Best regards

Chris

lime2-emmc-hangs.pdfFetching info...

Igor

Igor

Posted
Posted

First I would try lowering RAM speed in u-boot. This is somehow must try in such cases.

chradev

chradev

Posted
  • Author
Posted

Thanks Igor,

 

  On 7/25/2016 at 7:11 PM, Igor said:

First I would try lowering RAM speed in u-boot. This is somehow must try in such cases.

 

I will try it.

 

Is it good idea to do it step by step or to set it directly as low as 374MHz for example?

And what will be conclusion if the hangs stops at given speed lower the 480MHz as it is set by default?

 

Best regards

Chris

zador.blood.stained

zador.blood.stained

Posted
Posted
  On 7/25/2016 at 8:37 PM, chradev said:

Is it good idea to do it step by step or to set it directly as low as 374MHz for example?

And what will be conclusion if the hangs stops at given speed lower the 480MHz as it is set by default?

You can try low enough value just to check if it solves the broblem, an if it does, you can bisect to find highest stable value (at least for your particular board).

chradev

chradev

Posted
  • Author
Posted

Thanks Zador,

  On 7/25/2016 at 8:47 PM, zador.blood.stained said:

You can try low enough value just to check if it solves the broblem, an if it does, you can bisect to find highest stable value (at least for your particular board).

 

 

I will report the results as soon as I have them.

 

Best regards,

Chris

chradev

chradev

Posted
  • Author
Posted

Hi to All,

 

Following Igor's and Zador's advises I have build U-Boot with 384 MHz DRAM speed and run it before more than 10 hours with a server and 4 clients application load.

Because the system do not hang for more than 10 hours I decided to add more load running continuously both 'iperf3' and 'stress' tests with following arguments:

  • iperf3 -s (on a Lime2-emmc) / while true; do iperf3 -c IP; done; (on a VM with Ubuntu 14.04 running on i7/Windows 7 desktop) - both connected via Linksys' WRT1900ACS routed over GBit LAN
  • while true; do stress -c 1 -i 1 -m 1 --vm-bytes 128M -d 1 --hdd-bytes 128M -t 60; done; - with disk operation running on SATA SSD

Total load and other parameters measured by RPI Monitor are:

  • ~8 (1 min averaged) CPU load
  • ~320kBps upload transfer rate
  • ~40MBps download transfer rate (~64MBps without stress test)
  • 210-430Mbps download bandwidth measured by iperf3
  • ~3.7W consumption measured by PMU
  • ~4.4W consumption measured before DC-IN
  • 960MHz CPU frequency (all the time)
  • Temperatures: 34°C CPU, 44°C PMU and 35°C Cooler

Unfortunately, the drawback is that the application clients decrease the visualization speed from 56 to 10 FPS because of server's overload but the good news is that the system continues running.

 

Best regards

Chris

 

 

2
chradev

chradev

Posted
  • Author
Posted

Hi to All,

 

It passes 18 hours without hangs - 10h at normal work load and 8h at high load as described in previous post.

See attached file for more details.

 

So my conclusion is that Lime2-eMMC board hangs are definitely coming from DRAM and possible reasons could be:

  • software: inappropriate DRAM settings for given chips (not sure but think Olimex has changed DRAM supplier)
  • hardware: bad routing and/or production process (board manufacturing or BGA chips soldering)

I cannot say if both Lime2-eMMC boards (with and without hangs) come from the the same PCB batch but definitely they are from different mount / soldering batches because we have bought them with a few months time offset.

 

As a beginning I will try to investigate first possible reason - DRAM settings in U-Boot which by default in ver. 2016.07 are:

CONFIG_DRAM_CLK=480
CONFIG_DRAM_MBUS_CLK=300
CONFIG_DRAM_ZQ=127
# CONFIG_DRAM_ODT_EN is not set
CONFIG_DRAM_EMR1=4
CONFIG_DRAM_TPR3=0
CONFIG_DRAM_DQS_GATING_DELAY=0
CONFIG_DRAM_TIMINGS_VENDOR_MAGIC=y
# CONFIG_DRAM_TIMINGS_DDR3_1066F_1333H is not set
# CONFIG_DRAM_TIMINGS_DDR3_800E_1066G_1333J is not set

Olimex said in their post from Oct 2014 DRAM on Lime2 can work at 532MHz:

 

  Reveal hidden contents

 

 

On the other hand in Sunxi post is recommended to use following U-Boot settings for Cubietruck board:

+S:CONFIG_DRAM_CLK=360
+S:CONFIG_DRAM_ZQ=123
+S:CONFIG_DRAM_EMR1=4
+S:CONFIG_DRAM_TIMINGS_DDR3_800E_1066G_1333J=y

Can somebody advise me what DRAM settings are good for Lime2 boards (-eMMC option with HW rev. E in particular)?

 

Best regards
Chris
 

lime2-emmc-hangs.pdfFetching info...

zador.blood.stained

zador.blood.stained

Posted
Posted
  On 7/26/2016 at 7:07 PM, chradev said:

So my conclusion is that Lime2-eMMC board hangs are definitely coming from DRAM and possible reasons could be:

  • software: inappropriate DRAM settings for given chips (not sure but think Olimex has changed DRAM supplier)
  • hardware: bad routing and/or production process (board manufacturing or BGA chips soldering)

I cannot say if both Lime2-eMMC boards (with and without hangs) come from the the same PCB batch but definitely they are from different mount / soldering batches because we have bought them with a few months time offset.

Well, linux-sunxi wiki page for Lime2 says

  Quote

DRAM is clocked at 480 MHz by the hardware vendor (in fact even 532Mhz is mentioned in the blog). But the reliability still needs to be verified. The board uses somewhat non-standard resistors for ZQ calibration (ZQ = 330 Ohm, SZQ = 330 Ohm), but at least they seem to be the same in Lime2 revisions from Rev.B to Rev.E according to the board schematics. Still it's best to always mention the board revision in the results table in order to avoid any surprises.

 

  On 7/26/2016 at 7:07 PM, chradev said:

Can somebody advise me what DRAM settings are good for Lime2 boards (-eMMC option with HW rev. E in particular)?

Try using lima-memtester to find the frequency that works for you. To make any kind of statements or decisions we need much bigger sample size

tkaiser

tkaiser

Posted
Posted
  On 7/26/2016 at 7:07 PM, chradev said:

Olimex said in their post from Oct 2014 DRAM on Lime2 can work at 532MHz

 

I asked Tsvetan back then whether this was a typo, he confirmed but I really doubt that they did reliability tests correctly. We had the discussion on linux-sunxi IRC a few weeks ago that all the time consuming stuff we were doing for H3 boards in 2016 (testing out DRAM reliabitlity) never happened with other Allwinner boards, especially A10/A20 where we deal with many devices with obviously wrong DRAM clock defaults in u-boot (480 MHz are asking for trouble unless it's confirmed 532 MHz works reliable on n out of n samples while n being bigger than 20 -- no one ever did this test)

 

You find some discussions in this IRC log: http://irclog.whitequark.org/linux-sunxi/2016-06-16 (unfortunately I didn't found the other reference where ssvb blamed u-boot maintainers for not acting responsibly), IIRC oliv3r (Olliver Schinagl) wanted to help starting DRAM reliability testing with Lime2.

chradev

chradev

Posted
  • Author
Posted

Thanks Zador,

  On 7/26/2016 at 7:27 PM, zador.blood.stained said:

Try using lima-memtester to find the frequency that works for you. To make any kind of statements or decisions we need much bigger sample size

I will try it but for me it is important to have stable settings for any Lime2-eMMC board because it will be used for production.

 

Thanks tkaizer,

  On 7/27/2016 at 6:14 AM, tkaiser said:

I asked Tsvetan back then whether this was a typo, he confirmed but I really doubt that they did reliability tests correctly. We had the discussion on linux-sunxi IRC a few weeks ago that all the time consuming stuff we were doing for H3 boards in 2016 (testing out DRAM reliabitlity) never happened with other Allwinner boards, especially A10/A20 where we deal with many devices with obviously wrong DRAM clock defaults in u-boot (480 MHz are asking for trouble unless it's confirmed 532 MHz works reliable on n out of n samples while n being bigger than 20 -- no one ever did this test)

 

You find some discussions in this IRC log: http://irclog.whitequark.org/linux-sunxi/2016-06-16 (unfortunately I didn't found the other reference where ssvb blamed u-boot maintainers for not acting responsibly), IIRC oliv3r (Olliver Schinagl) wanted to help starting DRAM reliability testing with Lime2.

I also try to contact them around Lime and Lime2 boards without success.

In my opinion they have no interest to produce Lime2 boards except for diversity.

This is obvious taking into account that they offer a price for a single boards only.

 

Any way I am trying to find stable Armbian build for Lime2-eMMC board.

This includes the best DRAM settings of course.

So any help in this direction is welcome.

 

Best regards

Chris

Guest
This topic is now closed to further replies.
 Share
Go to topic listing
×
×
  • Create New...

Important Information

Terms of Use - Privacy Policy - Guidelines

  I accept