tkaiser

No, length is ok now but I missed before that the whole process is wrong This can only work if you boot Allwinner's u-boot starting Android since only then the compiled sys_config.fex is available at that memory address.

Hmm... wens wrote the size has to be converted to hex (0x8A74). Yes, both files are identical but I get empty files as result: 'size: 218180 (0 sections)' You don't need to fear frying things There's still thermal protection (throttling with very conservative settings). But I would prefer the following: sudo armbianmonitor -p minerd --benchmark This uses cpuminer and if the box with Beelink X2 fex is using 1.1V by default it should be able to freeze the board within seconds at 1.2 GHz (so better backup/clone the SD card first since this is the only thing that could happen: fs corruption due to OS freezing/crashing)

Yes, thank you. But as already explained the difference in thermal behaviour is most probably the result of the device now switching between 1.1V and 1.3V CPU voltage whereas it was sitting on 1.1V before all the time. Has anyone of you already tried to 'modprobe xradio_wlan' module now? Since maybe Wi-Fi works already? And then running a heavy benchmark with Beelink X2 fex crashing the device would be a useful test to see whether the assumption that this board uses 1.1V by default is correct or not.

Often buttons labeled u-boot are there to enter FEL mode. In case the box doesn't have a Micro/Mini USB port most probably one of the type A receptacles is the OTG port so you would need a standards violating A-to-A USB cable to make use of: http://linux-sunxi.org/Beelink_X2#FEL_mode

So at least no newer XR819 firmware used here. AFAIK you won't find the sys_config.fex stuff sitting in a filesystem. Maybe worth a try now: http://linux-sunxi.org/Sunxi-tools#script-extractor

Honestly I don't care since wasting time on supporting TV boxes is stupid anyway (from a developer's point of view). Please check schematics of your TV box with which voltage H2+ is fed here by default and then get back to us. Otherwise provide original sys_config.fex used by manufacturer with Android. To understand 'the problem' you need to dive into DVFS basics, then realize that we have 3 types of H2+/H3 devices: no voltage regulation, primitive voltage regulation (only 1.1V and 1.3V) and sophisticated voltage regulation (I2C accessible SY8106A chip able to adjust voltage in 20mV steps). Beelink X2 has no voltage regulation and we believe H3 is fed with 1.3V (since the device seems to run stable at 1200 MHz). This thingie here obviously implements primitive voltage regulation and when you use the Beelink X2 fex it will remain at the default voltage set by resistors (or whatever -- I'm no hardware guy). The voltage shown by RPi-Monitor is irrelevant since this is just parsing fex or DT and doing some math. If you write in the fex file 15000V RPi-Monitor will display this regardless of the real voltage used. If this TV box is set to 1.1V it will most probably become instable or even crash when you run demanding workloads when you allow the SoC to clock up to 1.2 GHz (very easy to test when switching back the X2 fex with some demanding benchmark). If the default voltage is set higher then the board should run stable at higher clockspeeds. It's a trial&error game since TV boxes aren't dev boards (no schematics available -- that's why extracting the sys_config.fex stuff is that important)

What the heck are talking about? A system that freezes or crashes has to be powercycled afterwards. This obviously is not happening here, isn't it? Do you refer to your Banana not being reactive any more every hour at a specific minute but then shortly after everything is fine again? If so and you use slow storage that can be caused by any heavy IO activity (especially random IO). You have 64.76 IO transactions per second on /dev/sda2 ON AVERAGE SINCE LAST BOOT, something's constantly hammering your disk. Just stop this and you're done (use iostat, iotop or every other tool that is appropriate to nail down such 'problems' on Linux)

I've not checked recently but if there's still no schematics released on orangepi.org but there are OS images available claiming working Wi-Fi then anyone of you should download such an OS image, see whether Wi-Fi works and if that's the case we need script.bin ('apt install sunxi-tools' then bin2fex is available) and the output of the following uploaded to an online pasteboard service: lsmod dmesg iwconfig It's only about the mmc1/wlan nodes in sys_config.fex (script.bin). As soon as they're known and adapted loading the 8189es driver should work (I guess you already tried out a 'modprobe 8189es' already?) Edit: Hmm... I checked for this with an old OS image from Xunlong already half a year ago: So does 'modprobe 8189es' work or not? In case someone tried out please output of 'iwconfig' afterwards and armbianmonitor -u again.

Which crash? According to the provided log the system has been rebooted on 'Thu Sep 28 15:17:14 MSK 2017' and is running fine. If you want to follow this 'issue' I would better try to clarify what the 'issue' could be... Maybe suspicious: Ethernet connection is 100 MBits/sec.

As expected. To get at least some information inserted into this thread what about posting output from 'armbianmonitor -u'?

The script is malformed in the forum post. As soon as you remove the empty lines / doubled linebreaks (most probably a copy&paste failure comping from Windows where CRLF is used?) it should work. Maybe @nopnop2002 can fix his post (since removing all empty lines ruins formatting)

Ok, then it should be possible to extract the relevant data from a running Linux accessing the the eMMC. But I'm too stupid to do the necessary calculations for an appropriate dd call and still too much of an u-boot/bootloader noob to be of any help at this stage. Once we have the blob able to be converted with bin2fex I could jump in again.

Why? Check https://forum.armbian.com/index.php?/topic/4583-rock64/&do=findComment&comment=37829 for example to get a clue which advantages the more modern CPU might have if you need AES encryption (still needs real-world tests of course, the numbers there are just a comparison at 'proof of concept' level). Then these Marvell things are made for NAS and router purposes unlike tablet, phone and TV box SoCs on other SBC. CPU utilization for IO and network related tasks is often less compared to other platforms due to better internal design. But if CPU horsepower is really sufficient depends on the types of applications of course. If the box should do video transcoding or also build kernels the HC1 will outperform Espressobin of course. That's one of the reasons I still look forward to more RK3328 variants since quad-core and most probably video transcoding possible HW accelerated using Rockchip's video engine. But still lack of IO possibilities of course.

Nope, it's still just like this though I moved from legacy to mainline kernel in the meantime and have the stuff to be seeded on an USB thumb drive to get an idea whether my daily seeding volume (a little bit more than 2 GB per day) was the result of poor random IO of the SD card used before. Seems it's not since it's still just 2.x GB per day. Impossible to answer since 'use case first'.

Johnrego maybe just ran into the usual 'connected eth0 and wlan0 to same network, disconnect eth0 and wlan0 stops to work' (which resolves itself after 10 minutes or something like that since then the AP/router both interfaces were connected to learned that wlan0's MAC/IP address has now to be connected directly and not using the disappeared one from eth0). If you want some progress on the 'issue' (whatever that is) please provide at least any INFORMATION (no one has a clue yet which distro you use on which board with which kernel and so on). Best idea is output from 'armbianmonitor -u' first and then also 'netstat -rn' in working and non working state. And just as a general remark: People thinking zeroconf would be evil can simply do an 'apt purge avahi-autoipd' and should be happy again. The purpose of avahi-autoipd is being able to setup a board with Armbian truly headless even without any network infrastructure (especially no DHCP server needed) available but just a network cable. If you boot for example an Orange Pi Zero with most recent Armbian images then you can connect later the Ethernet cable to your laptop and simply do a 'ssh root@orangepizero.local' which will work.

Yeah, but with wrong DVFS settings (PMIC = 0) so hotter than necessary and also consuming a little bit more than necessary. It's as simple as grabbing https://pastebin.com/raw/ghjyAPju with wget and then running fex2bin with the file as input and /boot/script.bin as output. Followed by a reboot. Thank you. It seems you still have the full Android install on eMMC! Can you please try to extract sys_config.fex? Once we have this it's just a matter of a little bit more copy&paste to get Wi-Fi working if it currently works in Android. Please follow wens' instructions how to get such a fex file from Android: https://github.com/linux-sunxi/sunxi-boards/commit/4a432501c910fddf759dd1171b15b0327b0d787a

I would go with the Beelink X2 image (since eMMC support) and trying out this fex: https://pastebin.com/ghjyAPju (naively assuming it's as close to H2+ reference design as OPi Zero is). Cooler_table, Wi-Fi, THS and DVFS settings are from OPi Zero, rest from Beelink X2. Feedback welcomed.

IIRC this could be Wi-Fi driver being loaded. As usual: 'armbianmonitor -u' output please.

Can you please provide output from 'armbianmonitor -u'? Beelink X2 image is wrong since feeding the SoC all the time with 1.3V but the DRAM settings (624 MHz vs. 408 MHz for an OPi Zero image) might be better. As already said somewhere else it would be great if someone could extract the sys_config.fex stuff from the Android running on this thing then we could add an optimized fex file to Armbian's repo which could then also be used as the base for mainline kernel DT.

That's funny

You get dual antenna / dual band USB dongles for a few bucks that show magnitudes better performance compared to those onboard SBC jokes you're now thinking of.

Well, obviously the overhead trashes performance with small chunks. When comparing the numbers with another Cortex-A7 then it's again an indication that the MTK SoC is clocked with just 1040 MHz (I would assume it's 1042). I added the numbers to our list: https://forum.armbian.com/index.php?/topic/4583-rock64/&do=findComment&comment=37829

Ask Gary? Two questions (for him): How does openssl performance look like using the standard benchmark above? How do they want to move from PoC to productive? Seems the current MTK vendor kernel does not receive frequent updates (still at 4.4.70), how should users cope with cryptodev if they need to compile the stuff themselves and out-of-tree and will BPi then provide rebuilt openssl packages to make use of the engine?

No idea if that's really true since the SoC is said to support proprietary MTK crypto extensions. So once MTK demonstrates how to use this stuff (in a reasonable way, you want this functionality available in a way that later kernel updates don't break everything) you could ask them for the output of for i in 128 192 256; do openssl speed -elapsed -evp aes-${i}-cbc ; done Also I don't agree on the conclusions wrt disk/USB performance since you can test for this stuff only with great performing devices (SSDs that are known to exceed 500 MB/s in every situation eg. Samsung Pro 850 with at least 256 GB -- the 128GB variant has lower write performance). Anyway: it was such a sh*t show getting any information about R2 since the 'sinovoip team bpi' guy actively blocked everything, it seems this still continues and playing early adopter is always just a great recipe to waste your own time... feel free to continue here but please don't expect further feedback

I disagree. 'USB for storage' in general is a technology best described as 'cheap consumer crap'. The USB3-A receptacle is IMO a bad joke and responsible for a lot of USB3 interconnection hassles (still looking forward to get USB-C everywhere since this connector is not such a brain-dead fail) and especially ODROID-XU4 is plagued by this (due to mechanical tolerances I guess). My personal learning from this was to try to avoid USB3-A where possible so if the device has not USB-C then an USB3-to-SATA bridge should be interconnected with the SoC directly on the PCB as it's done on ODROID-HC1 now or as it will be soon done on Cloudmedia's 'Transformer' (a stackable ROCK64 with JMS578 in metal enclosure somewhat similar to HC1 -- no infos known yet since Pine people prefer to share this only with their 'elite moderator club' at https://forum.pine64.org). But still then the usual underpowering issues are possible on devices that for whatever reasons prefer a 5V DC-IN input instead of 12V to provide stable 5V to connected disks. Me as an electrics noob found 'Nominal Animal's explanations here interesting.