tkaiser

This is an octa-core design made for TV boxes. IMO it's totally understandable that Amlogic does something equivalent to Intel's TurboBoost: reduce possible clockspeeds when all cores are in use. That way you end up with only 1.2 GHz when all 8 cores are busy. Given how DVFS works (increasing the VCore voltage a lot to provide laughable MHz boosts at the upper end of the DVFS scale) this is understandable both from a consumption and thermal point of view. This is a TV box SoC made for clueless people (Android users who think 'higher number' is 'better number'). All that's necessary for S912 TV boxes to sell are some BS marketing numbers ('octa-core at 2GHz' confirmed by shitty tools like CPU-Z and Geekbench) and all that's necessary to let those S912 TV boxes work ok-ish is limiting the CPU cores to sane operational defaults. The way Amlogic implements it (controlling this stuff from a BLOB and let the kernel report only bogus numbers) allows for both. Since all Android TV box SoC vendors play the same game I wouldn't call this cheating any more. It's just what a specific market demands (clueless people looking at irrelevant numbers instead of what's important)

I would prefer to do it correctly: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=892768 And IMO there's no need to hurry and I honestly do not understand the bunch of hacks recently added to get 18.04 built now...

Not really. A barrel jack was only on the K2, all other FriendlyELEC boards only have Micro USB for DC-IN (they sell a very good Micro USB cable for as less than 2 bucks) a 4 pin connector suitable to be combined with their PSU-ONECOM module (allowing to attach a 4.0/1.7mm barrel PSU) Just check http://www.friendlyarm.com/index.php?route=product/product&path=69&product_id=176, scroll to the bottom and check Shipping List. The more expensive boards ready to attach a lot of USB consumers are always sold with their great Micro USB cable (20 AWG rated or something like that. Pretty safe wrt voltage drops)

OMV runs on boards with 256 MB RAM or less. Filesharing daemons aren't RAM hungry and usually all this RAM ends up as filesystem buffers/caches anyway so in home/SOHO situations it's usually just wasted. Therefore it only depends on what you're trying to achieve. Tons of Docker containers --> more RAM. Software that eats RAM for no reason (e.g. some torrent stuff) --> more RAM. But for a simple NAS even 1 GB is more than sufficient.

RTL8211 is used as PHY on all GbE capable SBC I know. The majority of boards uses RTL8211E, some RTL8211F and Olimex used also RTL8211CL a while ago. Pretty much irrelevant since always the GbE MAC implementation lives inside the SoC and the RTL8211 PHY is just attached via RGMII (so the MAC and PCIe parts of these RealTek chips are not used on SBC anyway. Might change soon since more and more SoCs are PCIe equipped). But even on the soon to be released Orange Pi R2 the two RTL8211E are only used as PHY and attached via RGMII (RTD1296 has 3 GbE MACs but only one internal GbE PHY so for the two additional GbE interfaces external PHYs are needed):

What about not removing stuff but configuring backends: https://insights.ubuntu.com/2017/07/05/quick-and-easy-network-configuration-with-netplan

You're talking about Parallels and show a crashdump mentioning Virtualbox (org.virtualbox.kext.*). In any case what should we do here with some virtualization software running on macOS crashing due to some USB related bug(s)?

http://wiki.friendlyarm.com/wiki/index.php/NanoPi_K1_Plus RPi 3 form factor like their K2, maximum DRAM (2GB), Gigabit Ethernet, Wi-Fi with onboard aerial provided by RTL8189ETV, still using their own/new eMMC socket. According to schematics and their Github repo a SY8106A voltage regulator is used which is great news since then it's possible to clock the H5 well above 1.3 GHz.

Armbian supporting way too many boards and download statistics telling that this is a device not that popular. End user support ended, we won't do any testing on the hardware but since u-boot and kernel packages are per board family and we most probably will never give up Allwinner A20 you're fully supported. Just keep in mind that from time to time u-boot + kernel updates bricked some boards and that nothing is tested on the specific board so simply be careful with those updates (use armbian-config to block the updates and do an SD card backup first prior to updating from time to time).

TL;DR: the following is a simple summary of the issue: Amlogic SoCs contain an own embedded microcontroller (Cortex-M3) used for controlling power and clocks A proprietary and closed source firmware is loaded on the M3 at boot. This stuff is contained in the bl30.bin blob we have to include This firmware controls the real clockspeeds, ignores what the cpufreq framework running in the Linux kernel wants and even reports back bogus clockspeeds (the kernel wants to set 1512 MHz, the M3 ignores this and sets 1416 MHz instead but the code returns faked 1512 MHz) Various tests showed that this is not related to thermal protection but just to $something we currently don't understand and out of our control Hardkernel are the only ones who managed to get a bl30.bin blob from Amlogic for their ODROID-C2 that does not cheat on us but honours the cpufreq framework, sets the wanted clockspeeds and also returns real and not faked cpufreq values. On all other Amlogic SBC situation is different Talking about 'not entirely honest' when it's about bold lies is funny It's some proprietary crap that controls DVFS on Amlogic SoCs (a bl30.bin BLOB loading some firmware on the embedded Cortex-M3 which controls DVFS/cpufreq on its own) and Hardkernel is the only vendor that got this BLOB from Amlogic in a way where the installation does not cheat on you. In case the BLOB does also DRAM initialization (most likely) it should be hard to exchange it between boards. https://forum.armbian.com/topic/2138-armbian-for-amlogic-s912/?do=findComment&comment=43338 (S912 and S905X are both known to cheat on the Linux kernel. The cpufreq values are all faked. Most probably this does also apply to all S905 devices except ODROID-C2 since Hardkernel managed to get a fixed BLOB from Amlogic)

The error message is an u-boot message and u-boot has been read from SD card. So most probably it's SD card corruption. Armbian instructions are pretty clear how to deal with images and SD cards (CHECKING download integrity -- not possible with fake images -- and TESTING them in case errors occur): https://docs.armbian.com/User-Guide_Getting-Started/#how-to-check-download-authenticity

You did not. BPi M2 Zero is not supported by Armbian (same with BPi M64). Can a moderator please adjust the title of this thread: 'Problems with fake Armbian images' or something like that?

Every board has LTE support since all available external modems are USB based. Even if they appear as mPCIe card. They always rely on USB2 signals present on pins 36 and 38 of the mPCIe connector. On some boards the mPCIe slot is not standards compliant (eg. Banana Pi R2, there the board maker 'forgot' to route USB2 to the mPCI connector) and also some mPCIe cards are not standards compliant (Sierra Wireless MC74 for example uses a proprietary USB3 pin out). Since all mPCIe modems are USB based these things here work. But they always rely on an USB connection to the mPCIe slot. So simply save a lot of money and use an LTE USB dongle directly. If you're fine using an Android phone without phone enclosure and display then Orange Pi 4G-IoT might be something for you...

For a RealTek module? @Somya Chawla: 'I did it correctly but it doesn't work' is nothing anyone can help you with. You better start to describe the problem you run into and provide output of 'armbianmonitor -u'.

Are you aware that Allwinner's crypto engine is nothing you want to use? Did you already have a look at ARMv8 crypto extensions (almost all 64-bit ARM SoCs support with two known exceptions: the Broadcom thing in the Raspberries and Amlogic S905 on ODROID-C2)? WiFi can be USB or PCIe attached, with 3G/4G it's always USB2 even if the modules fit into a mPCIe slot. Onboard WiFi is usually crap since limited to 2.4GHz and if 5GHz is possible limited to a single antenna. So you better explain your use case first and other constraints (e.g. space) to get any reasonable advise...

Anyone of the RK guys here ever looked into DRAM timings? Or did you already run memtester? On Allwinner boards we used in the past this to test for DRAM related instabilities: http://linux-sunxi.org/Hardware_Reliability_Tests#Reliability (the idea is to force the GPU consume as much memory bandwidth as possible while memtester is running in parallel -- this unlike 'memtester only' is way better suited to discover memory timing issues that of course can result in freezes/crashes)

Quite possible that different DVFS settings are used. IIRC @TonyMac32 switched with kernel/settings from Tinker sources to upstream Rockchip BSP a while ago. The individual DVFS OPP should be accessible from userspace (sysfs -- but don't know details. I skipped RK3288 entirely so far)

And a connector rated for 1.8A max with a device that can draw easily a lot more with connected peripherals. Yes, that's the reality out there and engineers know about this (or they aren't engineers). Those lousy RPi folks unfortunately started with this Micro USB crap and now other board makers do the same just to advertise their boards as being totally compatible. Too bad you do not want to understand what the problem is and where to measure. In my personal opinion Armbian should really stop trying to support these piles of crap equipped with Micro USB for powering since average users are either not able or willing to understand what's happening (seriously: if it's about THE BOARD being undervolted how on earth should measuring at the wrong location help getting a clue?! Of course you have to generate a real load and measure behind the shit connector to get an idea how severe the voltage drops THERE)

This is just one part of the problem. The other one is the VOLTAGE DROP! Crappy PSUs provide either 5V or 2A but not both at the same time. And then there's cable and contact resistance and voltage available to the board being way lower than the one provided by the PSU. Now the third time: https://forum.armbian.com/topic/4614-asus-tinker-board/ Power supplied to micro USB port: 5.25 volts 800 - 950 mA "normal" use Playing a Youtube Video (software render) this hits 1.7 Amps Voltage present at Tinker Board USB Host port: 4.7 Volts under "normal" use Playing a Youtube Video this drops to 4.2 Volts, meaning a > 1 Volt drop. This is simply insane. And the direct result of using this shitty connector.

Of course. Thank you for the confirmation. BTW: It's really easy to get the problem by clicking at the links I provided above: https://forum.armbian.com/topic/6934-stability-problem-tinker-board/?do=findComment&comment=52629 If you want to measure how crappy Micro USB is (it's the VOLTAGE DROP we have to look after) then how do you want to measure on the wrong side of the cable? Contact and cable resistance are the problem so of course you have to measure AT THE BOARD and behind the crappy connector to get an idea what's happening!

Where? At the power source? Or when you power through Micro USB at the GPIO pins? The problem is the insane voltage drop occuring under load. To measure this effect you need to measure at the board and not at the PSU.

Very funny So you did not measure on the GPIO pins but on the wrong side of the USB cable, right? https://forum.armbian.com/topic/3327-asus-tinkerboard/?do=findComment&comment=31711 Micro USB for such a power hungry board is still one of the most crappy ideas an 'engineer' can have. The problem is not that you can buy cables that are 20AWG rated and that there exist PSUs that are able to provide 2A at 5V. The problem is that the Micro USB connector encourages users to use average (crappy) USB cables and average (crappy) chargers/PSUs. They provide either 2A or 5V but not both at the same time. And there's nothing to discuss since this problem is real. Check @MickMake's video I linked too above.

See the numbers for RPi 3 B+: 115 minutes 'overclocked' vs. 136 minutes with stock settings. That's an 18% increase in 'benchmark numbers'. CPU clockspeed raised by 12% and DRAM clockspeed raised by 27.5% with the 'overclocked' settings. Now as an excercise as already mentioned: Rock64 vs. ODROID-C2. Both use Cortex-A53 with 64-bit kernel and userland, the CPU clockspeed difference isn't that much so why does the ODROID-C2 perform that better? Search for tinymembench numbers and you've the answer. The Raspberry Pi is a 2011 design (only ARM cores exchanged, everything else is still the same, just clocked slightly faster each year). It performs like that of course.

No idea. For me the Tinkerboard is simply 'broken by design' and so I never looked into any details. But you might find the information here:

If you do not already power the board via GPIO pins then it's most likely the crappy Micro USB connector (voltage drop by design). https://forum.armbian.com/topic/4614-asus-tinker-board/ https://forum.armbian.com/topic/6506-tutorial-3d-video-acceleration-and-opencl-in-rk3288-boards-with-new-44-default-kernel/