mdel

on my a95x box i had to use that command to activate the second usb port : # power on second usb port echo 0x1 > /sys/devices/platform/dwc2_a/buspower your box may have a different layout so check the values of your /sys/devices/platform/dwc2_[X]/buspower values to find the one that is "0", that's the one you'll want to set to 0x1. I added that command to my /etc/rc.local script so that it gets activated at boot.

Did a simple benchmark on H3 and S905, both use armbian 5.20 (s905 is not an official armbian image and is not really an idle system) H3 : openssl speed -evp aes-128-cbc Doing aes-128-cbc for 3s on 16 size blocks: 2496591 aes-128-cbc's in 3.00s Doing aes-128-cbc for 3s on 64 size blocks: 1359414 aes-128-cbc's in 3.00s Doing aes-128-cbc for 3s on 256 size blocks: 358603 aes-128-cbc's in 3.00s Doing aes-128-cbc for 3s on 1024 size blocks: 90918 aes-128-cbc's in 3.00s Doing aes-128-cbc for 3s on 8192 size blocks: 11410 aes-128-cbc's in 3.00s OpenSSL 1.0.1t 3 May 2016 built on: Fri Sep 23 19:23:52 2016 options:bn(64,32) rc4(ptr,char) des(idx,cisc,16,long) aes(partial) blowfish(ptr) compiler: gcc -I. -I.. -I../include -fPIC -DOPENSSL_PIC -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -DL_ENDIAN -DTERMIO -g -O2 -fstack-protector-strong -Wformat -Werror=format-security -D_FORTIFY_SOURCE=2 -Wl,-z,relro -Wa,--noexecstack -Wall -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DAES_ASM -DGHASH_ASM The 'numbers' are in 1000s of bytes per second processed. type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes aes-128-cbc 13315.15k 29000.83k 30600.79k 31033.34k 31156.91k S905 : openssl speed -evp aes-128-cbc Doing aes-128-cbc for 3s on 16 size blocks: 9116734 aes-128-cbc's in 3.00s Doing aes-128-cbc for 3s on 64 size blocks: 2825024 aes-128-cbc's in 3.00s Doing aes-128-cbc for 3s on 256 size blocks: 758392 aes-128-cbc's in 3.00s Doing aes-128-cbc for 3s on 1024 size blocks: 193156 aes-128-cbc's in 3.00s Doing aes-128-cbc for 3s on 8192 size blocks: 24278 aes-128-cbc's in 3.00s OpenSSL 1.0.1t 3 May 2016 built on: Fri Sep 23 18:26:35 2016 options:bn(64,64) rc4(ptr,char) des(idx,cisc,16,int) aes(partial) blowfish(ptr) compiler: gcc -I. -I.. -I../include -fPIC -DOPENSSL_PIC -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -DL_ENDIAN -DTERMIO -g -O2 -fstack-protector-strong -Wformat -Werror=format-security -D_FORTIFY_SOURCE=2 -Wl,-z,relro -Wa,--noexecstack -Wall The 'numbers' are in 1000s of bytes per second processed. type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes aes-128-cbc 48622.58k 60267.18k 64716.12k 65930.58k 66295.13k Now, i will test that H3 in real world conditions but i must say that if it actually reflects those benchmark, i'm going to be disappointed.

thx for your answers i'm not sure i understand why using the crypto engine won't speed things up, does it run at a fixed clock and does not scale to the cpu speed ? According to those benchmarks you should get +10-40% performance gain with SS (A10/A20 tests ?), not sure what happens with negative gains for SS DMA though.. i did read montjoie's page but i don't quite understand the current state of things. I did not see where the current sun8i-ce driver can be found. H3 sun8i-ce shows AES/DES/3DES-CBC as "ok", can i test that with current Armbian kernel ? Reading this log https://irclog.whitequark.org/linux-sunxi/2016-07-09, something should work with BSP kernel. Anyways i was able to improve performance a bit by tweaking tun-mtu parameters, i now get around 70Mbps. I first discarded those tweaks as openvpn's connection log showed warnings about server expecting other values, but it seems to work with the client parameters.

quick followup with my reboot problems (still using a 5.20 image with failed fs resize). here's the serial log output : U-Boot SPL 2016.09-armbian (Sep 15 2016 - 01:16:52) DRAM: 1024 MiB Failed to set core voltage! Can't set CPU frequency Trying to boot from MMC1 it seems i still have some boot problems, here's a log of a failed reboot (from within uboot), then a successful power cycle. http://paste.ubuntu.com/23232833/ is it the same thing as the previous uboot problems ? i also got another failed boot error that does not appear in this log, it was something about the init mmc clock ("fatal error"), i then got dropped to a prompt. i will try to reproduce it.

this is the same serial as my x2 which had troubles booting with previous armbian images, but now with 5.20 it works much better. to get console boot messages you need to solder cables on the board.

okay i managed to boot from usb stick, using my box dtb.img (stripped), haven't tried other dtbs. here's the serial log of that boot : http://paste.ubuntu.com/23228629/ unfortunately the system became unresponsive during apt-get update and ended up freezing, can't ssh. i will try again from another sd card, i will also try your minicom command thx. -- edit fixed pastebin -- sorry there seem to be an interrupted boot in that pastebin, the usb boot should show a dtb.img of "45056 bytes read" which is my "stripped" dtb.img bin and somehow almost twice the size of your dtbs ??

sorry i just realized i didn't follow the topic. i want to confirm that with the lastest Armbian_5.20_Beelinkx2_Debian_jessie_3.4.112.img, it seems to have fixed my boot issues as well. I only have used it for a day but did many shutdown / upgrades / reboots and haven't seen the "purple no boot" behavior that i had previously. I do have some reboot / shutdown "problems" : got a faulty reboot (shutdown -r now) with it stuck on purple but power cycling solved it. got a weird halt (shutdown -h now) with no red light on (no led), and others with red light but that i couldn't start from the power button or remote, but i don't know if it's possible or not. Also it's probably not relevant, as i stepped on the wires during first boot, but the sd card resize did not work, i will try again.

i believe i installed your aml_autoscript update through android here's my /dev/block/env from adb : i can see : bootcmd=run start_autoscript; run storeboot start_autoscript=if usb start; then run start_usb_autoscript; fi; if mmcinfo; then run start_mmc_autoscript; fi; start_mmc_autoscript=if fatload mmc 0 11000000 s805_autoscript; then autoscr 11000000; fi; start_usb_autoscript=if fatload usb 0 11000000 s805_autoscript; then autoscr 11000000; fi; should it echo anything ? maybe inside the s805_autoscript, i haven't checked that. For the serial i'm using the basic command : screen /dev/ttyUSB0 115200 8N1 i can interrupt boot by slamming "enter", then i get to a prompt but can't type anything, tried to disconnect / reconnect the terminal but no luck. i haven't tried booting from usb yet, i will this afternoon.

hello i've tried to boot your lastest Armbian_5.20_Vegas805_Ubuntu_xenial_3.10.102_20160923.img image on my S85 box, from the sd card (same sd card i've been using for openelec on this box). unfortunately the result is always the same, "google tv" splash for a few seconds then "no hdmi" output and no activity visible. i've tried with my dtb and all the dtbs included in your image. so i've soldered a serial and dumped the boot logs : android boot log (ends with a proper "shutdown") : http://paste.ubuntu.com/23224373/ ubuntu image log : http://paste.ubuntu.com/23224374/ i wanted to test some commands to load my dtb and boot the kernel manually but for some reason i have a very hard time interrupting the boot, when i use "enter" it does nothing and boots, and when i use space, it stops the boot process but i don't get a prompt and can't type anything (i'm using screen). i can interrupt with enter but then i can't type anything on the prompt, i'll try some different serial configurations. i hope it helps.

Could someone remind me of the status of the H3 crypto engine, both hardware (capabilities, aes-ni ?) and software (mainline or vanilla kernels) ? I've been testing openvpn on an amlogic s905 box (still need to fix my beelink x2 problems) and as expected i'm hitting a cpu bottleneck. i've been able to achieve around 60Mbps (Blowfish-cbc, usb hdd, ext4) but openvpn being single threaded the cpu load maxes out thus limiting openvpn's bandwidth. Unfortunately as with most vpn providers you can't tweak all parameters and so, changing the tun-mtu size is not possible and has to stay at the default 1500 value. I will perform some tests on my beelink x2 or opi pc, but i'd like to know what would the benefits be (if any) of using an H3 in an openvpn context. thank you

i will do more tests tomorrow the firmware images for my box are on the Mega.cz link above. i did not put the dtb directly there yet, because i don't know if my dtb extraction tool works or not. You'll find a "boot.img" in the "dump" and "firmwares/extract" directories which are the /dev/block/boot blob that contain the dtb bin. i use "split_bootimg.pl" script from cnxsoft tutorial to extract the dtb.img but as i tried to explain above, i'm not sure the dtb blob is good.

ok thx for the explanation, sorry i should have tried from sd card and it did work fine. Your s805_autoscript udpate is okay now and i've checked my /dev/block/env to make sure your modifications are there. now i'm trying to boot your image Armbian_5.17_Vegas85_Debian_jessie_3.10.102_20160915.img i get two behaviors depending on which dtb.img file i'm using : - when using your m201_1G/dtb.img, or my box dtb.img (with stripped headers, i'll explain below), i get no hdmi output (monitor says "no input") an no boot as far as i can tell, network light is on (not active), no dhcp request sent by the box. - when i use my "split_bootimg.pl" dtb.img, taken from the /dev/block/boot of my box, or from a stock image, android boots as if no sd card was inserted. here's the some firmware data for that box : Beelink s85 firmwares and my dump i'm feeling that split_bootimg.pl tool does not extract dtb.img properly for those s805 boot blob. When i use it, the boot-second.gz generated is larger and has some kind of header at the beginning which makes dtc send "bad magic number" error when trying to decompile to dts. i did find a workaround (remove hex header, that's why i called it "stripped"), then dtc works fine and dts output is clean and i get the "no hdmi" boot as described above.

@@balbes150 i'm having trouble installing your aml_autoscript on my s85 box, when it reboots in recovery i get the following errors : E:footer is wrong E:signature verification failed Installation aborted. I see this is a common error, but i don't know much about android an didn't find an easy trick to fix that myself. The update files are on the root of my USB stick, and tried again from within recovery (update from external -> udisk) but got the same error. thx

nice i'll test on my beelink s85 your multiboot link is the same as the image link

@@balbes150 i see that in your s805 git revision you've replaced some s812 configuration with s805, and i remembered i have an s812 box here as well, it's an M8S i think. if you want to test please let me know, it should be a 2G/8G box.

@@bellad nice, it looks a lot like my box output, same dtb commands. try to get the output of the "help" command as balbes150 requested. thx

from which system do you want the command "help" output ? here i was in android adb, i don't have serial on that box to get into uboot command and don't really know if it can be done without it. i grab the uboot environment from "strings /dev/block/env" the s85 box as an otg port, not sure if it can be used to get into uboot.

@@balbes150 i also have a few s805 boxes lying around, i wouldn't mind testing your images on hem too (i think i have at least one black mxq and one beelink s85, the two have different boards). here's the current uboot env of my s85, it was most certainly modified by an openelec boot image, through a recovery update process. I don't think i have an original uboot dump, but there should be some stock firmware around so i could restore it. there's also a "dtb load from firmware", so universal dtb could work.. i'm not quite sure why the dtb load command here ("imgread dtb boot ${loadaddr}") is different from your autoscript one ("store dtb read $dtb_loadaddr") ? and no use of dtb specific address..

okay my 1GB box shows 777MB of free ram so 194MB of reserved fb ram should be about it. I have not observed the oom behavior yet but i'm about to run out of it on that box and hopefully start swapping. although i wouldn't really mind having the main userland process killed (torrent client). Am i correct in assuming you modified the global update script, not the s905_autoscript ? Then would it possible to achieve the same thing from the s905_autoscript, in order to preserve a default "fb on" for systems that would require it ?

do you know how much memory is freed and if it's proportional to the total memory or if it's a default fixed value ? then when disabled are there any other features of the soc hardware that get affected ? thx

okay yes i know about aml_ & s905_ autoscripts. i'l check what you changed in your v0.5. i also know that LE has its own batch of uboot env vars LExxx. At some point one distro will conflict with another one if not careful, but i guess there's no other way to enable usb/sd direct boot and keep the original aml_autoscript "recovery only" feature. Anyways so to sum up my test of your alt linux image above, its aml_autoscript did not work on my a95x recovery mode, but the s905_autoscript did work ( once renamed aml_autoscript), so i'm not sure what went wrong with the original aml_autoscript there. And just to let your know, once alt linux finished booting, it didn't dhcp the network so i couldn't get to the web interface. I didn't play with it much, i did see the rj45 port light up and "ip link show" had an eth0 interface but no lan ip.

okay, so with your alt_ddBR_multidtb_v0_03_16GB__20160908.img, the hdmi display is fine. But then i feel i must also be more specific about my setup. I'm not using a tv (i don't have a tv here), but a pc monitor (16/10 1920x1200) with a hdmi-hdmi cable (not hdmi-dvi). So yes the on screen display of that linux boot is okay. As i said above the only thing that i did manually, was to remove the aml_autoscript which did not work in recovery mode and renamed the s905_autoscript to aml_autoscript and then the linux boot worked.

okay as i did with your previous images, i renamed your s905_autoscript to aml_autoscript and used toothpick recovery and this time it worked, so maybe your current aml_autoscript does not work as expected ? i will try again to make sure. now you image is starting i'll check the boot messages. when it's finished what should i do then ? --- okay i have the "s905 login" prompt in your pdf you say : "The launch of the ddBR system from SD card is faster, but requires more control over the naming of the media before starting the procedures for backup and restore." but i'm not quite sure what i have to do, is it simply a linux to do a dd backup / restore of the internal emmc ? okay i didn't see your pdf had many pages so i'm reading now..

@@balbes150 i've burnt your alt_ddBR_multidtb_v0_03_16GB__20160908.img image to SD card (32GB) and i'm trying to run in a my other a95x (brand new out of the box). i have not installed your "android update" script to autoboot s905_autoscript from sdcard and usb. And as it is, it doesn't seem to see your aml_autoscript in recovery mode, i always end up in the android recovery. I tried starting recovery with the toothpick method and with adb reboot recovery but no luck.. this is the current (vanilla) uboot env of that a95x (s905) box : as you can see it should start your aml_autoscript from sd card in recovery but that doesn't work.. i can try another media, or do you want me to flash your "android update" and not test the original aml_autoscript recovery mode ?

i will receive one 16GB USB3 stick in a few days. I do have a few 16GB and 32GB SD cards, and i could also use a sd card usb adapter.. do you want me to test something ?