tpm8

I used some time the last days to do some tests. Here first results with 5.25 official u-boot from armbian:
 
cubietruck1   -> 2 limatester-runs without freeze (but freezed before and was more stable in operation with u-boot 5.25 then with 5.20) cubietruck2 -> 2 limatester-runs runs without crash (but freezed before and was much more stable in operation with u-boot 5.20 then with 5.24/5!) cubietruck3 -> freeze after 10 mins limatester, multiple tries see above (most start of the "Checkerboard" tests) cubietruck4 -> reproducable freeze at limatester-start at "got 100MB, trying mlock ...", multiple tries cubietruck5 -> 2 limatester-runs without freeze Now I focus my tests on "Cubietruck3" for the beginning and tried the tpm8-u-boot-384 there. Result: Freeze in the second limatester loop ... so Interestingly later then the 10 mins before, but freezed still fast.
 
Now I test the tpm8-u-boot-432 on that "Cubietruck3" and is currently in limatester-loop #4 (also with 1000MB instead of 100MB) and still running. I can test the whole day. I moved the InfluxDB to a Intel-Nuc (also because of 64bit).
 
Further plan is:
- let it run with 432-u-boot for a while
- try 432-u-boot on "Cubietruck4" and see if limatester starts at least :-)
- test 432-u-boot also on "Cubietruck5" to see if this works too
 
Ingo F

I think it's related to bug in wireless driver (ap6210) which sometimes causes crash on unload / shutdown. If you don't need wireless, disable this module and you should be fine.

@tpm8: So uboot written:
root@cubietruck3:~# dd if=u-boot-sunxi-with-spl_20161122.bin of=/dev/mmcblk0 bs=1024 seek=8 530+1 records in 530+1 records out 543026 bytes (543 kB, 530 KiB) copied, 0.124085 s, 4.4 MB/s rebootet ... time counts now :-)

Ok. Mine has SKhynix SKhynix H5TQ4G63AFR-PBC DRAM chips. The board says CUBIETRUCK V1.0-06.06 printed on it.
 
Link to photo of the board: http://workupload.com/file/hGEwhZh
 
I also managed to compile latest u-boot. As soon as the other unit arrives I'm going make further tests.

I've prepared a new SD card from scratch with 5.20 image + all updates  + 5.24 beta u-boot for the test. Several reboots with this clean image but still unstable on my cubietruck. Probably a different hardware revision?
 
On my "production" SD card with u-boot 5.20 (otherwise same packages and same jessie legacy kernel) everything is rock solid. There i can Lima Tester for hours without problems.
 
In order to completely rule out hardware problems I've ordered another (used) cubietruck. As soon as it is delivered I'm able to do more testing.

True, today's build is broken ... fixing / will be fixed ASAP.

Testing now with latest stable u-boot ... v2016.11 ... it seems stable, but will leave until morning.

ok - here is my feedback, unfortunately uboot 5.24 does not fix it for me.
 
Cubietruck, Jessie Legacy kernel (3.4.112-sun7i) Image 5.20 with all updates. Stability tests witch cpufreq-ljt-stress-test and Lima Memtester.
 
uboot 5.23: Kernel crashes after few seconds during load, Error on console:
Unable to handlE kernel NULL pointer dereference at virtual address 000000 uboot 5.24 beta (linux-u-boot-cubietruck_5.24.161109_armhf.deb): Kernel crashes after few seconds during load, Error on console:
Unable to handle kernel paging request at virtual address xxxxxx Downgrading uboot to 5.17 or 5.20 - everything is rock solid. No problems during complete runs of cpufreq-ljt-stress-test and Lima Memtester.
 
Tobias

ok - here is my feedback, unfortunately uboot 5.24 does not fix it for me.
 
Cubietruck, Jessie Legacy kernel (3.4.112-sun7i) Image 5.20 with all updates. Stability tests witch cpufreq-ljt-stress-test and Lima Memtester.
 
uboot 5.23: Kernel crashes after few seconds during load, Error on console:
Unable to handlE kernel NULL pointer dereference at virtual address 000000 uboot 5.24 beta (linux-u-boot-cubietruck_5.24.161109_armhf.deb): Kernel crashes after few seconds during load, Error on console:
Unable to handle kernel paging request at virtual address xxxxxx Downgrading uboot to 5.17 or 5.20 - everything is rock solid. No problems during complete runs of cpufreq-ljt-stress-test and Lima Memtester.
 
Tobias