wtarreau Posted February 27, 2017 Posted February 27, 2017 Yes, you are correct. It was on powersave, those are now on proper speed: type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes aes-128 cbc 79215.37k 86050.52k 89357.40k 90211.33k 90456.06k bf-cbc 50721.71k 57495.64k 59830.53k 60454.91k 60631.72k I've just tested on my MiQi and got about 2% higher performance at 1.8 GHz : type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes aes-128 cbc 80197.72k 87590.12k 91353.34k 92255.91k 92520.45k bf-cbc 52186.86k 59762.60k 62007.89k 62678.36k 62876.33k At 2.0 GHz I get this : type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes aes-128 cbc 88145.11k 97268.91k 101094.74k 102091.43k 102386.35k bf-cbc 57751.12k 66213.18k 68619.26k 69361.66k 69580.12k My openssl is build in thumb mode with the following options under linaro gcc-4.7.4 : armv7thf-gcc47l_glibc218-linux-gnueabi-gcc -I. -I.. -I../include -fPIC -DOPENSSL_PIC -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -mcpu=cortex-a9 -mlittle-endian -O3 -fomit-frame-pointer -march=armv7-a -D__ARM_MAX_ARCH__=7 -O3 -Wall -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DAES_ASM -DBSAES_ASM -DGHASH_ASM Given that most AES code is written in asm, this 2% performance gain likely comes from the rest of the code and could be caused by the mcpu=cortex-a9 build options, I'm forcing it everywhere as I found it to perform better on the RK3288 than mcpu=cortex-a17 on most programs. I suspect that the A17 core in the RK3288 is more of an A12 (as reported in cpuinfo) hence closer to A9 than what the A17 was supposed to be before ARM decided that both were the same. 2
Igor Posted March 1, 2017 Posted March 1, 2017 For comparison: 1.99 GHz type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes aes-128 cbc 87295.72k 94739.03k 98363.39k 99325.95k 99562.84k bf-cbc 55820.25k 63628.57k 65862.06k 66524.84k 66680.15k 2.14 Ghz (maximum possible value for my board) aes-128 cbc 93640.97k 101616.77k 105520.55k 106535.94k 106785.45k bf-cbc 59887.06k 68163.84k 70644.39k 71375.19k 71538.01k 1
tkaiser Posted March 1, 2017 Posted March 1, 2017 44 minutes ago, Igor said: 2.14 Ghz (maximum possible value for my board) Did you still power the board through Micro USB or fan header? OpenSSL Distro packages (Xenial?) or self-compiled with Willy's settings?
Igor Posted March 2, 2017 Posted March 2, 2017 8 hours ago, tkaiser said: Did you still power the board through Micro USB or fan header? OpenSSL Distro packages (Xenial?) or self-compiled with Willy's settings? Xenial packages and by best micro USB cable. Not long after tests I experienced instability and power cycling due to excessive heat. Board was hot like hell and when it was cooled down, everything was back to normal. Heat dissipation that I used was clearly not enough when overclocking.
jernej Posted March 20, 2017 Posted March 20, 2017 Using latest u-boot-rockchip repo I managed to add MiQi support to U-Boot. Not everything is properly configured yet, but it should be able to boot kernel. @Igor now that SPL is working again, maybe we should go away from that binary blobs?
Igor Posted March 21, 2017 Posted March 21, 2017 6 hours ago, jernej said: Using latest u-boot-rockchip repo I managed to add MiQi support to U-Boot. Not everything is properly configured yet, but it should be able to boot kernel. @Igor now that SPL is working again, maybe we should go away from that binary blobs? Sure, why not. I added a patch but had troubles booting ... have to check later what am I doing wrong.
jernej Posted March 21, 2017 Posted March 21, 2017 14 minutes ago, Igor said: I added a patch but had troubles booting ... have to check later what am I doing wrong. Do you use this procedure for flashing U-Boot?
Igor Posted March 21, 2017 Posted March 21, 2017 I suspect that I need to change that ... thanks for the tip.
jernej Posted March 21, 2017 Posted March 21, 2017 It seems that this method is already used: https://github.com/igorpecovnik/lib/commit/ba61ffe1011be5ab436856886ca7b55ab0c6f590
Igor Posted March 21, 2017 Posted March 21, 2017 7 minutes ago, jernej said: It seems that this method is already used: https://github.com/igorpecovnik/lib/commit/ba61ffe1011be5ab436856886ca7b55ab0c6f590 This is used for ASUS Tinkerboard. I'll check ASAP if it works here.
Igor Posted March 21, 2017 Posted March 21, 2017 (edited) With both methods you ended up with bricked MiQi ... then use tweezers to short resistor, force maskrom mode and reflash stock u-boot. Something is wrong. Edit: It stuck at displaying: U-Boot SPL 2017.03 Edited March 21, 2017 by Igor stuck point
jernej Posted March 21, 2017 Posted March 21, 2017 Hm, I never had to short resistor. First I invalidated eMMC bootloader using built in U-Boot command, so board always boots to special USB mode. Then I just played with flashing U-Boot with SPL to SD card... Which repo are you using for a base? I will provide compiled version later this day.
Igor Posted March 21, 2017 Posted March 21, 2017 Well I flashed to eMMC 4 minutes ago, jernej said: Which repo are you using for a base? I will provide compiled version later this day. Denx 2017.03 + your patch.
jernej Posted March 21, 2017 Posted March 21, 2017 I couldn't make it work with 2017.03-rc3 and according to log, 2017.03 release doesn't change much. Try to use rockchip next repo or alternatively, use miqi-new branch from my u-boot repo. I'm also not sure if eMMC works properly. I have to recheck DT. As I said, early success
jernej Posted March 21, 2017 Posted March 21, 2017 @Igor, you can try this: https://transfer.sh/CjnKx/u-boot-rockchip-miqi-sdcard.bin just flash it with 32KiB offset (or 64 sector as said by readme).
jernej Posted March 23, 2017 Posted March 23, 2017 Ok, now it should be fully supported (eth, usb, video, emmc, etc.) https://github.com/jernejsk/u-boot/tree/miqi Binary (14 days available): https://transfer.sh/fVGr4/u-boot-rockchip-miqi-sd.bin Unfortunately, many patches are not in any stable release, so for testing purposes it would be best just to use my branch and miqi-rk3288_defconfig
TonyMac32 Posted March 24, 2017 Posted March 24, 2017 On 3/21/2017 at 5:40 AM, Igor said: With both methods you ended up with bricked MiQi ... then use tweezers to short resistor, force maskrom mode and reflash stock u-boot. Something is wrong. Edit: It stuck at displaying: U-Boot SPL 2017.03 Just a thought. the boot loader offset locations *should* be hardware bound by the SoC, there shouldn't be any difference between MiQi and Tinker Board unless the MiQi is using an SPI device to load a bootloader, but that does not sound like the case. With the cat command throwing it's data away instead of adding it to the output binary, the Tinker Board did exactly as you describe here, only showed the U-Boot SPL message.
Shimon Posted April 2, 2017 Posted April 2, 2017 As @tkaiser mentioned elsewhere, there's currently a great bargain on Chiptrip Q8 at GB. Libreelec already runs on Ugoos UT3+, and with Linux support bound to improve in the coming months, this looks very attractive. Great minds think alike, eh @mdel?
Recommended Posts