Jump to content

Recommended Posts

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

Posted

Hi Igor,

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

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

Posted

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.

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

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:

 

root@egpr:~# dmesg | grep mmc
[ 3.527911] sunxi-mmc 1c0f000.mmc: Got CD GPIO
[ 3.561922] sunxi-mmc 1c0f000.mmc: base:0xf0d78000 irq:26
[ 3.598670] mmc0: host does not support reading read-only switch, assuming write-enable
[ 3.601226] mmc0: new high speed SDHC card at address 0002
[ 3.601725] sunxi-mmc 1c11000.mmc: base:0xf0d7c000 irq:27
[ 3.602208] mmcblk0: mmc0:0002 00000 3.70 GiB
[ 3.604333] mmcblk0: p1
[ 3.614775] sunxi-mmc 1c11000.mmc: smc 1 err, cmd 8, RTO !!
[ 3.618939] sunxi-mmc 1c11000.mmc: smc 1 err, cmd 55, RTO !!
[ 3.619779] sunxi-mmc 1c11000.mmc: smc 1 err, cmd 55, RTO !!
[ 3.620608] sunxi-mmc 1c11000.mmc: smc 1 err, cmd 55, RTO !!
[ 3.621434] sunxi-mmc 1c11000.mmc: smc 1 err, cmd 55, RTO !!
[ 3.661960] mmc1: new DDR MMC card at address 0001
[ 3.662858] mmcblk1: mmc1:0001 P1XXXX 3.60 GiB
[ 3.663268] mmcblk1boot0: mmc1:0001 P1XXXX partition 1 16.0 MiB
[ 3.663657] mmcblk1boot1: mmc1:0001 P1XXXX partition 2 16.0 MiB
[ 3.664771] sunxi-mmc 1c11000.mmc: smc 1 err, cmd 18, RD RTO !!
[ 3.664835] sunxi-mmc 1c11000.mmc: data error, sending stop command
[ 3.664900] mmcblk1: timed out sending r/w cmd command, card status 0x900
[ 3.664920] blk_update_request: I/O error, dev mmcblk1, sector 0
[ 3.664935] Buffer I/O error on dev mmcblk1, logical block 0, async page read
[ 3.665283] sunxi-mmc 1c11000.mmc: smc 1 err, cmd 18, RD RTO !!
[ 3.665319] sunxi-mmc 1c11000.mmc: data error, sending stop command
[ 3.665374] mmcblk1: timed out sending r/w cmd command, card status 0x900
[ 3.665387] blk_update_request: I/O error, dev mmcblk1, sector 0
[ 3.665397] Buffer I/O error on dev mmcblk1, logical block 0, async page read
[ 3.665423] mmcblk1: unable to read partition table
[ 4.097070] EXT4-fs (mmcblk0p1): mounted filesystem with writeback data mode. Opts: (null)
[ 6.673828] sunxi-mmc 1c11000.mmc: smc 1 err, cmd 18, RD RTO !!
[ 6.673976] sunxi-mmc 1c11000.mmc: data error, sending stop command
[ 6.674082] mmcblk1: timed out sending r/w cmd command, card status 0x900
[ 6.674107] blk_update_request: I/O error, dev mmcblk1, sector 7552896
[ 6.675066] sunxi-mmc 1c11000.mmc: smc 1 err, cmd 18, RD RTO !!
[ 6.675156] sunxi-mmc 1c11000.mmc: data error, sending stop command
[ 6.675277] mmcblk1: timed out sending r/w cmd command, card status 0x900
[ 6.675301] blk_update_request: I/O error, dev mmcblk1, sector 7552896
[ 6.675318] Buffer I/O error on dev mmcblk1, logical block 944112, async page read
[ 6.677395] sunxi-mmc 1c11000.mmc: smc 1 err, cmd 18, RD RTO !!
[ 6.677492] sunxi-mmc 1c11000.mmc: data error, sending stop command
[ 6.677641] mmcblk1boot1: timed out sending r/w cmd command, card status 0x900
[ 6.677665] blk_update_request: I/O error, dev mmcblk1boot1, sector 32640
[ 6.678112] sunxi-mmc 1c11000.mmc: smc 1 err, cmd 18, RD RTO !!
[ 6.678179] sunxi-mmc 1c11000.mmc: data error, sending stop command
[ 6.681968] mmcblk1boot1: timed out sending r/w cmd command, card status 0x900
[ 6.682006] blk_update_request: I/O error, dev mmcblk1boot1, sector 32640
[ 6.682023] Buffer I/O error on dev mmcblk1boot1, logical block 4080, async page read
[ 6.684057] sunxi-mmc 1c11000.mmc: smc 1 err, cmd 18, RD RTO !!
[ 6.684162] sunxi-mmc 1c11000.mmc: data error, sending stop command
[ 6.684267] mmcblk1boot0: timed out sending r/w cmd command, card status 0x900
[ 6.684290] blk_update_request: I/O error, dev mmcblk1boot0, sector 32640
[ 6.684750] sunxi-mmc 1c11000.mmc: smc 1 err, cmd 18, RD RTO !!
[ 6.684853] sunxi-mmc 1c11000.mmc: data error, sending stop command
[ 6.684939] mmcblk1boot0: timed out sending r/w cmd command, card status 0x900
[ 6.684958] blk_update_request: I/O error, dev mmcblk1boot0, sector 32640
[ 6.684973] Buffer I/O error on dev mmcblk1boot0, logical block 4080, async page read
[ 7.004023] sunxi-mmc 1c11000.mmc: smc 1 err, cmd 18, RD RTO !!
[ 7.004111] sunxi-mmc 1c11000.mmc: data error, sending stop command
[ 7.004284] mmcblk1: timed out sending r/w cmd command, card status 0x900
[ 7.004307] blk_update_request: I/O error, dev mmcblk1, sector 7552896
[ 7.006156] sunxi-mmc 1c11000.mmc: smc 1 err, cmd 18, RD RTO !!
[ 7.006253] sunxi-mmc 1c11000.mmc: data error, sending stop command
[ 7.006346] mmcblk1: timed out sending r/w cmd command, card status 0x900
[ 7.006369] blk_update_request: I/O error, dev mmcblk1, sector 7552896
[ 7.006385] Buffer I/O error on dev mmcblk1, logical block 944112, async page read
[ 7.024436] sunxi-mmc 1c11000.mmc: smc 1 err, cmd 18, RD RTO !!
[ 7.024551] sunxi-mmc 1c11000.mmc: data error, sending stop command
[ 7.024685] mmcblk1boot0: timed out sending r/w cmd command, card status 0x900
[ 7.025139] sunxi-mmc 1c11000.mmc: smc 1 err, cmd 18, RD RTO !!
[ 7.025200] sunxi-mmc 1c11000.mmc: data error, sending stop command
[ 7.025338] mmcblk1boot0: timed out sending r/w cmd command, card status 0x900
[ 7.025363] Buffer I/O error on dev mmcblk1boot0, logical block 4080, async page read
[ 7.028499] sunxi-mmc 1c11000.mmc: smc 1 err, cmd 18, RD RTO !!
[ 7.028580] sunxi-mmc 1c11000.mmc: data error, sending stop command
[ 7.028724] mmcblk1boot1: timed out sending r/w cmd command, card status 0x900
[ 7.031224] sunxi-mmc 1c11000.mmc: smc 1 err, cmd 18, RD RTO !!
[ 7.031312] sunxi-mmc 1c11000.mmc: data error, sending stop command
[ 7.031433] mmcblk1boot1: timed out sending r/w cmd command, card status 0x900
[ 7.031462] Buffer I/O error on dev mmcblk1boot1, logical block 4080, async page read
[ 7.785334] EXT4-fs (mmcblk0p1): re-mounted. Opts: commit=600,errors=remount-ro

 

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

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

Posted
What is changed for solving the DT problem?

 

I haven't done anything in this area.

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.

 

 

 

root@chr-vm-yocto:/data/armbian-cust# ./run.sh
Updating '.':
At revision 39.
[ o.k. ] This script will try to update
Already up-to-date.
Already on 'master'
Your branch is up-to-date with 'origin/master'.
[ o.k. ] Preparing [ host ]
[ o.k. ] Build host OS release [ trusty ]
[ o.k. ] Using user configuration override [ userpatches/lib.config ]
[ o.k. ] Starting Armbian build script [ @host ]
[ o.k. ] Building [ Armbian 5.16 Lime2 Debian jessie next ]
[ o.k. ] Syncing clock [ host ]
[ o.k. ] source downloading [ @host ]
[ o.k. ] ... you have latest sources [ u-boot v2016.05 ]
[ o.k. ] ... you have latest sources [ linux-vanilla v4.6.2 ]
[ o.k. ] ... you have latest sources [ sunxi-tools ]
[ o.k. ] ... you have latest sources [ sunxi-display-changer ]
[ o.k. ] Compiling sunxi tools [ @host & target ]
[ o.k. ] Cleaning [ u-boot/v2016.05 ]
[ o.k. ] Cleaning [ linux-vanilla/v4.6.2 ]
[ o.k. ] Creating board support package [ lime2 next ]
[ o.k. ] Fingerprinting [ Armbian 5.16 Lime2 Debian jessie next ]
[ o.k. ] Building package [ linux-jessie-root-next-lime2 ]
[ 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 [ 3 days old ]
jessie-ng-armhf.f9b...65e.tgz: 264MB [60,4MB/s] [==============================================================================================>] 100%
[ o.k. ] Applying distribution specific tweaks for [ jessie ]
[ o.k. ] Applying common tweaks
[ o.k. ] Installing kernel [ linux-image-next-sunxi ]
[ o.k. ] Installing u-boot [ linux-u-boot-next-lime2 ]
[ o.k. ] Installing headers [ linux-headers-next-sunxi ]
[ o.k. ] Installing DTB [ linux-dtb-next-sunxi ]
[ o.k. ] Installing board support package [ lime2 ]
[ o.k. ] Installing extra applications and drivers
[ o.k. ] Installing linux firmware [ 5.16 ]
[ o.k. ] Installing [ armbian-hostapd-jessie_5.16_armhf.deb ]
invoke-rc.d: policy-rc.d denied execution of stop.
invoke-rc.d: policy-rc.d denied execution of start.
[ o.k. ] Installing [ armbian-tools-jessie_5.16_armhf.deb ]
[ 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 ]
Enter new UNIX password: Retype new UNIX password: passwd: password updated successfully
patching file /etc/rsyslog.conf
Updating packages. It will take some time.
RPi-Monitor customization.
Installing application staff.
Installing NodeJS and add-ins.
OK
[ o.k. ] Preparing image file for rootfs [ lime2 jessie ]
[ o.k. ] Current rootfs size [ 1043 MiB ]
[ o.k. ] Creating blank image for rootfs [ 1589 MiB ]
1,55GB [ 120MB/s] [=============================================================================================================================>] 100%
[ o.k. ] Creating partitions [ root: ext4 ]
[ o.k. ] Copying files to image [ tmprootfs.raw ]
956.22M 99% 49.42MB/s 0:00:18 (xfr#47752, to-chk=0/60190)

sent 959.81M bytes received 963.94K bytes 49.27M bytes/sec
total size is 960.13M speedup is 1.00
[ o.k. ] Copying files to /boot partition [ tmprootfs.raw ]
19.66M 99% 141.78MB/s 0:00:00 (xfr#124, to-chk=0/130)

sent 19.67M bytes received 2.40K bytes 39.34M bytes/sec
total size is 19.66M speedup is 1.00
[ o.k. ] Free space: [ SD card ]
tmpfs 1,5G 1,1G 455M 70% /data/armbian-cust/output/cache/sdcard
/dev/loop0p1 1,5G 1,1G 407M 73% /data/armbian-cust/output/cache/mount
[ o.k. ] Writing bootloader [ /dev/loop0 ]
[ o.k. ] Copying image file [ Armbian_5.16_Lime2_Debian_jessie_4.6.3.raw ]
[ o.k. ] Done building [ /data/armbian-cust/output/images/Armbian_5.16_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 [ 7 min ]

 

 

 

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

 

Best regards

Chris

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:

 

 


Installing NodeJS and add-ins.
OK

> bufferutil@1.2.1 install /app/srv/node_modules/bufferutil
> node-gyp rebuild

make: Entering directory '/app/srv/node_modules/bufferutil/build'
CXX(target) Release/obj.target/bufferutil/src/bufferutil.o
SOLINK_MODULE(target) Release/obj.target/bufferutil.node
COPY Release/bufferutil.node
make: Leaving directory '/app/srv/node_modules/bufferutil/build'

> serialport@4.0.0 install /app/srv/node_modules/serialport
> node-pre-gyp install --fallback-to-build

node-pre-gyp ERR! Tried to download: https://github.com/EmergingTechnologyAdvisors/node-serialport/releases/download/4.0.0/serialport-v4.0.0-node-v47-linux-arm.tar.gz
node-pre-gyp ERR! Pre-built binaries not found for serialport@4.0.0 and node@5.12.0 (node-v47 ABI) (falling back to source compile with node-gyp)
make: Entering directory '/app/srv/node_modules/serialport/build'
CXX(target) Release/obj.target/serialport/src/serialport.o
CXX(target) Release/obj.target/serialport/src/serialport_unix.o
CXX(target) Release/obj.target/serialport/src/serialport_poller.o
SOLINK_MODULE(target) Release/obj.target/serialport.node
COPY Release/serialport.node
make: Leaving directory '/app/srv/node_modules/serialport/build'

> utf-8-validate@1.2.1 install /app/srv/node_modules/utf-8-validate
> node-gyp rebuild

qemu: uncaught target signal 11 (Segmentation fault) - core dumped
Segmentation fault (core dumped)
gpr-server@0.0.1 /app/srv
├─┬ bufferutil@1.2.1
│ ├── bindings@1.2.1
│ └── nan@2.3.5
├── ip@1.1.3
├─┬ serialport@4.0.0
│ ├─┬ commander@2.9.0
│ │ └── graceful-readlink@1.0.1
│ ├─┬ debug@2.2.0
│ │ └── ms@0.7.1
│ ├── es6-promise@3.2.1
│ ├─┬ node-pre-gyp@0.6.29
│ │ ├─┬ mkdirp@0.5.1
│ │ │ └── minimist@0.0.8
│ │ ├─┬ nopt@3.0.6
│ │ │ └── abbrev@1.0.9
│ │ ├─┬ npmlog@3.1.2
│ │ │ ├─┬ are-we-there-yet@1.1.2
│ │ │ │ ├── delegates@1.0.0
│ │ │ │ └─┬ readable-stream@2.1.4
│ │ │ │ ├── buffer-shims@1.0.0
│ │ │ │ ├── core-util-is@1.0.2
│ │ │ │ ├── inherits@2.0.1
│ │ │ │ ├── isarray@1.0.0
│ │ │ │ ├── process-nextick-args@1.0.7
│ │ │ │ ├── string_decoder@0.10.31
│ │ │ │ └── util-deprecate@1.0.2
│ │ │ ├── console-control-strings@1.1.0
│ │ │ ├─┬ gauge@2.6.0
│ │ │ │ ├── aproba@1.0.4
│ │ │ │ ├── has-color@0.1.7
│ │ │ │ ├── has-unicode@2.0.1
│ │ │ │ ├── object-assign@4.1.0
│ │ │ │ ├── signal-exit@3.0.0
│ │ │ │ ├─┬ string-width@1.0.1
│ │ │ │ │ ├─┬ code-point-at@1.0.0
│ │ │ │ │ │ └── number-is-nan@1.0.0
│ │ │ │ │ └─┬ is-fullwidth-code-point@1.0.0
│ │ │ │ │ └── number-is-nan@1.0.0
│ │ │ │ ├─┬ strip-ansi@3.0.1
│ │ │ │ │ └── ansi-regex@2.0.0
│ │ │ │ └── wide-align@1.1.0
│ │ │ └── set-blocking@2.0.0
│ │ ├─┬ rc@1.1.6
│ │ │ ├── deep-extend@0.4.1
│ │ │ ├── ini@1.3.4
│ │ │ ├── minimist@1.2.0
│ │ │ └── strip-json-comments@1.0.4
│ │ ├─┬ request@2.72.0
│ │ │ ├── aws-sign2@0.6.0
│ │ │ ├── aws4@1.4.1
│ │ │ ├─┬ bl@1.1.2
│ │ │ │ └─┬ readable-stream@2.0.6
│ │ │ │ ├── core-util-is@1.0.2
│ │ │ │ ├── inherits@2.0.1
│ │ │ │ ├── isarray@1.0.0
│ │ │ │ ├── process-nextick-args@1.0.7
│ │ │ │ ├── string_decoder@0.10.31
│ │ │ │ └── util-deprecate@1.0.2
│ │ │ ├── caseless@0.11.0
│ │ │ ├─┬ combined-stream@1.0.5
│ │ │ │ └── delayed-stream@1.0.0
│ │ │ ├── extend@3.0.0
│ │ │ ├── forever-agent@0.6.1
│ │ │ ├─┬ form-data@1.0.0-rc4
│ │ │ │ └── async@1.5.2
│ │ │ ├─┬ har-validator@2.0.6
│ │ │ │ ├─┬ chalk@1.1.3
│ │ │ │ │ ├── ansi-styles@2.2.1
│ │ │ │ │ ├── escape-string-regexp@1.0.5
│ │ │ │ │ ├─┬ has-ansi@2.0.0
│ │ │ │ │ │ └── ansi-regex@2.0.0
│ │ │ │ │ ├─┬ strip-ansi@3.0.1
│ │ │ │ │ │ └── ansi-regex@2.0.0
│ │ │ │ │ └── supports-color@2.0.0
│ │ │ │ ├─┬ is-my-json-valid@2.13.1
│ │ │ │ │ ├── generate-function@2.0.0
│ │ │ │ │ ├─┬ generate-object-property@1.2.0
│ │ │ │ │ │ └── is-property@1.0.2
│ │ │ │ │ ├── jsonpointer@2.0.0
│ │ │ │ │ └── xtend@4.0.1
│ │ │ │ └─┬ pinkie-promise@2.0.1
│ │ │ │ └── pinkie@2.0.4
│ │ │ ├─┬ hawk@3.1.3
│ │ │ │ ├── boom@2.10.1
│ │ │ │ ├── cryptiles@2.0.5
│ │ │ │ ├── hoek@2.16.3
│ │ │ │ └── sntp@1.0.9
│ │ │ ├─┬ http-signature@1.1.1
│ │ │ │ ├── assert-plus@0.2.0
│ │ │ │ ├─┬ jsprim@1.3.0
│ │ │ │ │ ├── extsprintf@1.0.2
│ │ │ │ │ ├── json-schema@0.2.2
│ │ │ │ │ └── verror@1.3.6
│ │ │ │ └─┬ sshpk@1.8.3
│ │ │ │ ├── asn1@0.2.3
│ │ │ │ ├── assert-plus@1.0.0
│ │ │ │ ├── dashdash@1.14.0
│ │ │ │ ├── ecc-jsbn@0.1.1
│ │ │ │ ├── getpass@0.1.6
│ │ │ │ ├── jodid25519@1.0.2
│ │ │ │ ├── jsbn@0.1.0
│ │ │ │ └── tweetnacl@0.13.3
│ │ │ ├── is-typedarray@1.0.0
│ │ │ ├── isstream@0.1.2
│ │ │ ├── json-stringify-safe@5.0.1
│ │ │ ├─┬ mime-types@2.1.11
│ │ │ │ └── mime-db@1.23.0
│ │ │ ├── node-uuid@1.4.7
│ │ │ ├── oauth-sign@0.8.2
│ │ │ ├── qs@6.1.0
│ │ │ ├── stringstream@0.0.5
│ │ │ ├── tough-cookie@2.2.2
│ │ │ └── tunnel-agent@0.4.3
│ │ ├─┬ rimraf@2.5.2
│ │ │ └─┬ glob@7.0.5
│ │ │ ├── fs.realpath@1.0.0
│ │ │ ├─┬ inflight@1.0.5
│ │ │ │ └── wrappy@1.0.2
│ │ │ ├── inherits@2.0.1
│ │ │ ├─┬ minimatch@3.0.2
│ │ │ │ └─┬ brace-expansion@1.1.5
│ │ │ │ ├── balanced-match@0.4.1
│ │ │ │ └── concat-map@0.0.1
│ │ │ ├─┬ once@1.3.3
│ │ │ │ └── wrappy@1.0.2
│ │ │ └── path-is-absolute@1.0.0
│ │ ├── semver@5.2.0
│ │ ├─┬ tar@2.2.1
│ │ │ ├── block-stream@0.0.9
│ │ │ ├─┬ fstream@1.0.10
│ │ │ │ └── graceful-fs@4.1.4
│ │ │ └── inherits@2.0.1
│ │ └─┬ tar-pack@3.1.4
│ │ ├─┬ fstream@1.0.10
│ │ │ ├── graceful-fs@4.1.4
│ │ │ └── inherits@2.0.1
│ │ ├─┬ fstream-ignore@1.0.5
│ │ │ ├── inherits@2.0.1
│ │ │ └─┬ minimatch@3.0.2
│ │ │ └─┬ brace-expansion@1.1.5
│ │ │ ├── balanced-match@0.4.1
│ │ │ └── concat-map@0.0.1
│ │ ├─┬ once@1.3.3
│ │ │ └── wrappy@1.0.2
│ │ ├─┬ readable-stream@2.1.4
│ │ │ ├── buffer-shims@1.0.0
│ │ │ ├── core-util-is@1.0.2
│ │ │ ├── inherits@2.0.1
│ │ │ ├── isarray@1.0.0
│ │ │ ├── process-nextick-args@1.0.7
│ │ │ ├── string_decoder@0.10.31
│ │ │ └── util-deprecate@1.0.2
│ │ └── uid-number@0.0.6
│ └─┬ object.assign@4.0.4
│ ├─┬ define-properties@1.1.2
│ │ └── foreach@2.0.5
│ ├── function-bind@1.1.0
│ └── object-keys@1.0.10
└─┬ ws@1.1.1
├── options@0.0.6
└── ultron@1.0.2

npm ERR! Linux 4.2.0-27-generic
npm ERR! argv "/usr/bin/nodejs" "/usr/bin/npm" "install"
npm ERR! node v5.12.0
npm ERR! npm v3.8.6
npm ERR! code ELIFECYCLE

npm ERR! utf-8-validate@1.2.1 install: `node-gyp rebuild`
npm ERR! Exit status 139
npm ERR!
npm ERR! Failed at the utf-8-validate@1.2.1 install script 'node-gyp rebuild'.
npm ERR! Make sure you have the latest version of node.js and npm installed.
npm ERR! If you do, this is most likely a problem with the utf-8-validate package,
npm ERR! not with npm itself.
npm ERR! Tell the author that this fails on your system:
npm ERR! node-gyp rebuild
npm ERR! You can get information on how to open an issue for this project with:
npm ERR! npm bugs utf-8-validate
npm ERR! Or if that isn't available, you can get their info via:
npm ERR! npm owner ls utf-8-validate
npm ERR! There is likely additional logging output above.

npm ERR! Please include the following file with any support request:
npm ERR! /app/srv/npm-debug.log
[ o.k. ] Preparing image file for rootfs [ lime2 jessie ]

 

 

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

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:

 


#!/bin/bash

if [ ! -d "/media/sda2/armbian" ]; then
echo Armbian storage does not exist or SSD 2nd partition is not mounted!
exit 1
fi

# Find latest Armbian file
LastArmbian=$(echo /media/sda2/armbian/$(ls -1t /media/sda2/armbian | grep Armbian) | awk -F" " '{print $1}')
if [ ! -f "${LastArmbian}" ]; then
echo Armbian file does not exist!
exit 2
fi

COUNT=0
while [ $COUNT -lt 2 ]; do
if [ -b "/dev/mmcblk${COUNT}boot0" ]; then
eMMCDevice=mmcblk$COUNT
fi
let COUNT=COUNT+1
done

if [ ! -b "/dev/${eMMCDevice}" ]; then
echo eMMC device does not exist!
exit 3
fi

if [ "X$(lsblk | grep ${eMMCDevice} | grep part | grep /)" != "X" ]; then
echo eMMC device is mounted!
exit 4
fi

echo -e "Latest Armbian file:\t$LastArmbian"
echo -e "eMMC Device to update:\t/dev/${eMMCDevice}"

echo -e "Updating eMMC Device ..."

dd if="${LastArmbian}" of="${eMMCDevice}"
(echo x; echo i; echo 0x$(date +%y%m%d%H); echo r; echo w;) | fdisk "/dev/${eMMCDevice}"
tune2fs -U $(uuidgen) "/dev/${eMMCDevice}p1"

lsblk && blkid

 

 

Script to write Armbian image to SATA SSD:

 

 

#!/bin/bash

if [ ! -d "/media/sda2/armbian" ]; then
        echo Armbian storage does not exist or SSD 2nd partition is not mounted!
        exit 1
fi

# Find latest Armbian file
LastArmbian=$(echo /media/sda2/armbian/$(ls -1t /media/sda2/armbian | grep Armbian) | awk -F" " '{print $1}')
if [ ! -f "${LastArmbian}" ]; then
        echo Armbian file does not exist!
        exit 2
fi

if [ -b "/dev/sda1"  ]; then
        SSDDevice=/dev/sda1
else
        echo SSD device does not exist!
        exit 4
fi

umount /media/sda1
mkfs.ext4 "${SSDDevice}"
if [ "X$(lsblk | grep sda1 | grep /)" == "X" ]; then
        mount "${SSDDevice}" /media/sda1
fi

echo -e "Latest Armbian file:\t$LastArmbian"
echo -e "SSD Device to update:\t${SSDDevice}"
echo -e "Updating SATA SSD Device ..."

mount -o loop,offset=1048576,ro,noexec "${LastArmbian}" /mnt

rsync -aH /mnt/ /media/sda1
sed -i 's/\/dev\/mmcblk0p1/\/dev\/sda1/g' /media/sda1/etc/fstab
sed -i 's/,data=writeback,/,/g' /media/sda1/etc/fstab
cat /media/sda1/etc/fstab
touch /media/sda1/root/.no_rootfs_resize

umount /mnt
umount /media/sda1

lsblk && blkid

 

 

Best regards

Chris

 

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

 

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?

Posted

Hi tkaiser,

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

Posted

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?

Posted

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

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

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

Posted

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

Posted

Thanks Igor,

 

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

Posted

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

Posted

Thanks Zador,

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

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

 

 

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:

 

 

A20-OLinuXino-LIME2 is product of the continual improvement of our OSHW OLinuXino boards based on your feedback, tips and suggestions.
The major differences to A20-OLinuXino-LIME are:
1. Much better routing of DDR3 memory. We increased the number of layers to 8 vs the 6 layers in LIME, we put the DDR3 memory closer to the A20, we layout the tracks shorter, as result now LIME2 runs with DDR3 on 532Mhz on LIME there were problems to run DDR3 at more than 400Mhz.

 

 

 

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

Posted

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

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.

 

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

Posted

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.

Posted

Thanks Zador,

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,

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.
×
×
  • Create New...

Important Information

Terms of Use - Privacy Policy - Guidelines