TonyMac32

Hmm, it may be about power consumption as well, if the driver doesn't bring it up (like a headless application) you might save some mW. As it stands I'm going to patch to enable them all in the board DTS's. I'll take a look at that bluetooth driver tonight as well. If it could do PlanetSide 2 I'd be happy. Of course that game makes my i7-6800k cry, and it's a 4-year old game...

Right, the patch is changing that to "disabled" for mainline, unless a new revision comes out. You don't think you need a 16 GB RAM rk3288 board?

For curiosity I built Stretch for the Tinker Board a week or so ago, it worked then. Let me try it again and see/share the results.

I started adding some current Rockchip patches to the 4.13 dtsi for rk3288, there are a couple iommu entries added that are related to the vcodec. I haven't pushed them yet because either adding them in "disabled" state or the 64-bit register values in these entries shut down my HDMI output, I had to status ok them in the dts for the board and fix the 64-bit entries. For the curious, Rockchip is pushing to use 64-bit values to support lpae: https://patchwork.kernel.org/patch/9878101/ They are making other patches assuming this one will go through, although it hasn't been accepted yet. https://patchwork.kernel.org/patch/9878013/ https://patchwork.kernel.org/patch/9907831/

Yeah, I kind of signed off when a FriendlyARM document got put up as BPi's, and contradicted the post it was in. Not to mention this happened minutes after I said we should be open and honest if we want this thing to work out. I'm very disappointed. Now, since I don't know the structure of BPi's company, it is possible Lion just copied that from their blog, where the same falsification existed, without realizing. That's why I didn't jump up and down and rant about it. As you can see I've done my best to continue a civil conversation. Perhaps others would care to endeavor to likewise treat us with improved control of their tongues. Or fingers, as it were.

Armbianmonitor may need tweaked for Aarch64, I got the same result on Le Potato Selecting previously unselected package libcurl4-gnutls-dev:arm64. (Reading database ... 123334 files and directories currently installed.) Preparing to unpack .../libcurl4-gnutls-dev_7.47.0-1ubuntu2.2_arm64.deb ... Unpacking libcurl4-gnutls-dev:arm64 (7.47.0-1ubuntu2.2) ... Processing triggers for man-db (2.7.5-1) ... Setting up libcurl4-gnutls-dev:arm64 (7.47.0-1ubuntu2.2) ... checking build system type... aarch64-unknown-linux-gnu checking host system type... aarch64-unknown-linux-gnu checking target system type... aarch64-unknown-linux-gnu checking for a BSD-compatible install... /usr/bin/install -c checking whether build environment is sane... yes checking for a thread-safe mkdir -p... /bin/mkdir -p checking for gawk... no checking for mawk... mawk checking whether make sets $(MAKE)... yes checking whether make supports nested variables... yes checking whether to enable maintainer-specific portions of Makefiles... no checking for style of include used by make... GNU checking for gcc... gcc checking whether the C compiler works... no configure: error: in `/usr/local/src/cpuminer-2.4.5': configure: error: C compiler cannot create executables See `config.log' for more details make: *** No targets specified and no makefile found. Stop. section of config.log:

Well shit.

Perhaps as an aid to our mutual understanding, would it be possible to link to a schematic and all released technical documents here, and provide an up to date image/layout of the board? I see a few things on the Banana Pi site that are... awkward. There are at least 2 revisions of the board on display with different port layouts, and the power jack next to the microUSB is labelled as "12 V" is that accurate? I don't know what that PMIC is off hand, so I'd be very unlikely to use that power jack unless you provided the adapter. I think there is potential, however I am an automotive engineer, everything document I make must be defensible in a court of law, so I am very specific and I require a lot of verified documentation. I am by no means looking for perfection, but it should be accurate enough that I can Follow it without destroying the device Compile a generic linux without relying explicitly on your repo. Observe something near the advertised performance specs during empirical testing Identify all the right parts found in documentation. We need a thread where @Lion Wang @Nora Lee and @sean.wang are following and replying as is needed. We are not asking any questions that should be unexpected, most vendors provide schematics and most vendors have reasonably accurate datasheets. Our feedback should be very carefully considered, we are an educated user base, something development teams almost never have access to. We have people that use these single board computers in industrial and other applications, when they say "It would be really great if..." They know what they're talking about. Now, I do not speak for the team, I only speak for myself and hopefully as a sane and intelligent individual: My recommendation on getting Armbian support for boards is to come here, reach out to the Armbian community, and provide accurate and complete documents, ask us questions, listen to our answers, etc. Lion_Wang, the figure you posted shows WiFi + BT as OK, but you say it isn't complete. I see it's listed as AP6212 here, but on the R2 manual it says: " banana pi BPI-R2 have support MTK6625L wifi&BT 4.1 chip onboard. " <--- That is the sort of thing that causes trouble and upsets people. The schematics are better than nothing, but they are scrubbed of IC names, values, etc, so really there is a limit to what value they are. I do at least see +12V being specified there, and consistently through, so OK. I was bracing myself for magic smoke everywhere...

I did not say there was, I was addressing your assertions that they were useless to software developers, in case anyone had a similar opinion or hadn't considered it before. Now, let's all bring the combative nonsense and slander down a notch, shall we?

In the case of specific hardware with partial or incorrect device trees, etc, the schematics are quite useful for pin numbers etc. There are always examples of features not fully implemented, even when advertised. As an Electrical Engineer, I would politely remind you that code does not execute in a magical place where no physics exist. Things like "can this board be powered via GPIO?" "What is the maximum current available via USB?". "Is the SD regulator capable of switching to 1.8V for high speed?" "How are the processor opp voltages derived?". All require schematics to verify, especially when the company spends all their time on new boards and almost none on support.

Kernel 4.13 iperf3: Connecting to host, port 5201 [ 4] local port 48346 connected to port 5201 [ ID] Interval Transfer Bandwidth Retr Cwnd [ 4] 0.00-1.00 sec 11.7 MBytes 98.4 Mbits/sec 0 129 KBytes [ 4] 1.00-2.00 sec 11.4 MBytes 95.9 Mbits/sec 0 143 KBytes [ 4] 2.00-3.00 sec 11.2 MBytes 93.8 Mbits/sec 0 150 KBytes [ 4] 3.00-4.00 sec 11.2 MBytes 93.8 Mbits/sec 0 150 KBytes [ 4] 4.00-5.00 sec 11.2 MBytes 93.8 Mbits/sec 0 150 KBytes [ 4] 5.00-6.00 sec 11.2 MBytes 93.8 Mbits/sec 0 150 KBytes [ 4] 6.00-7.00 sec 11.5 MBytes 96.4 Mbits/sec 0 150 KBytes [ 4] 7.00-8.00 sec 11.2 MBytes 93.8 Mbits/sec 0 150 KBytes [ 4] 8.00-9.00 sec 11.2 MBytes 93.8 Mbits/sec 0 150 KBytes [ 4] 9.00-10.00 sec 11.2 MBytes 93.8 Mbits/sec 0 150 KBytes - - - - - - - - - - - - - - - - - - - - - - - - - [ ID] Interval Transfer Bandwidth Retr [ 4] 0.00-10.00 sec 113 MBytes 94.8 Mbits/sec 0 sender [ 4] 0.00-10.00 sec 112 MBytes 94.2 Mbits/sec receiver Connecting to host, port 5201 Reverse mode, remote host is sending [ 4] local port 48350 connected to port 5201 [ ID] Interval Transfer Bandwidth [ 4] 0.00-1.00 sec 11.3 MBytes 95.1 Mbits/sec [ 4] 1.00-2.00 sec 11.2 MBytes 94.2 Mbits/sec [ 4] 2.00-3.00 sec 11.2 MBytes 94.2 Mbits/sec [ 4] 3.00-4.00 sec 11.2 MBytes 94.2 Mbits/sec [ 4] 4.00-5.00 sec 11.2 MBytes 94.2 Mbits/sec [ 4] 5.00-6.00 sec 11.2 MBytes 94.2 Mbits/sec [ 4] 6.00-7.00 sec 11.2 MBytes 94.2 Mbits/sec [ 4] 7.00-8.00 sec 11.2 MBytes 94.1 Mbits/sec [ 4] 8.00-9.00 sec 11.2 MBytes 94.2 Mbits/sec [ 4] 9.00-10.00 sec 11.2 MBytes 94.2 Mbits/sec - - - - - - - - - - - - - - - - - - - - - - - - - [ ID] Interval Transfer Bandwidth Retr [ 4] 0.00-10.00 sec 113 MBytes 94.9 Mbits/sec 0 sender [ 4] 0.00-10.00 sec 112 MBytes 94.4 Mbits/sec receiver Fast ethernet is indeed fast ethernet

Le Potato is the first board from Libre.computer: https://libre.computer/products/boards/aml-s905x-cc/ Basic information is on the link above, here's the TL;DR: Raspberry Pi 2 form factor clone, with 64-bit quad-core Amlogic S905X 1 or 2 GB RAM eMMC and SD support HDMI 2.0 for 4k support 100 Mb Fast Ethernet Extra headers for I2S, UART, etc (nice feature I think) IR receiver Advertised to have low power consumption Powered via micro-USB based on: Amlogic P212 reference board Use Case: Media Player (retro gaming?) I've been using a board now for a few weeks, I have kernels 4.13 and 3.14 running, however 3.14 does not yet have a proper device tree so it's a bit rough around the edges (display support is not really there) http://sprunge.us/GUgX - eMMC was not installed for this, it has boot preference over the SD. Pros: Familiar form factor for a lot of people The board isn't doing anything "fancy", no real "gimmicks" eMMC should be a boost to performance. (Untested so far on my part) S905X, 4K and built-in IR should make for a good multimedia machine Dedicated fast ethernet, not sharing USB bandwidth like the Pi. Cons: micro-USB powered, although so far the board seems to live up to its low consumption promise. Still has the potential issue if the 4x USB's are loaded. Fast Ethernet, this board will not be a server. Mali 450 (only really a con if gaming is on your To-Do list) No wifi/BT (that's a con for some people, for others it's a pro) USB Hub. My understanding is not all 4 ports come from 1 hub, but there is no indication of which ports are which IR sensor position makes using Pi cases a bit more problematic (my favorites are the solid aluminum ones) U-boot blob (U-boot source available, but compilation in-script is problematic (2015.01 U-Boot) ) Yes, Fast ethernet is a pro and a con. It isn't on the USB like the pi, pro. It's only Fast ethernet, con. Using the built-in phy keeps the component count down. Power Consumption: Using 5.25 Volts 2000 mA supply. (Reading at GPIO header, wireless mouse, keyboard.) 5.28 V Idle 5.22 V Youtube video with no acceleration (minerd won't compile, I haven't debugged) 5.11 V Youtbe video + spinning disk 2.5" HDD on USB (it did not initially want to spin up, even hooked to 2 ports) Not bad, must be an above-average micro-USB socket.

I can of course take a look, I tried this with a script and had some limited success, although the initialization would ultimately fail.

@chwe as long as it is not banana Aldi beer... (There is Aldi here, it does quite well) There is an old saying, I feel it applies here:. "Fool me once, shame on you. Fool me twice, shame on me." I know for a fact I would not buy another ASUS board, if they send me one to evaluate and it turns out to be amazing, my mind could be changed. And that is with only one bad board, imagine 3,4,5? "Same old story, same old song and dance".

Which kernel is it? 4.11 does not have wifi support, it doesn't have the driver.

A 4.13 DTS patch just popped up on patchwork for Rock64, in case anyone is interested. https://patchwork.kernel.org/patch/9892325/ There was a small mountain of patches stuffed in there yesterday, should go through them

I'm not worried about the dts or the drivers themselves, it's this chunk in particular: diff --git a/arch/arm/mach-rockchip/rockchip.c b/arch/arm/mach-rockchip/rockchip.c index 7fbecd0..4a81c18 100644 --- a/arch/arm/mach-rockchip/rockchip.c +++ b/arch/arm/mach-rockchip/rockchip.c @@ -23,6 +23,7 @@ #include <linux/clocksource.h> #include <linux/mfd/syscon.h> #include <linux/regmap.h> +#include <linux/i2c.h> #include <asm/mach/arch.h> #include <asm/mach/map.h> #include <asm/hardware/cache-l2x0.h> @@ -33,6 +34,18 @@ #define RK3288_GRF_SOC_CON2 0x24C #define RK3288_TIMER6_7_PHYS 0xff810000 +static struct i2c_board_info __initdata i2c_devices_tinker_mcu[] = { + { + I2C_BOARD_INFO("tinker_mcu", 0x45), + }, +}; + +static struct i2c_board_info __initdata i2c_devices_tinker_ft5406[] = { + { + I2C_BOARD_INFO("tinker_ft5406", 0x38), + }, +}; + static void __init rockchip_timer_init(void) { if (of_machine_is_compatible("rockchip,rk3288")) { @@ -80,6 +93,9 @@ static void __init rockchip_dt_init(void) rockchip_suspend_init(); of_platform_populate(NULL, of_default_bus_match_table, NULL, NULL); platform_device_register_simple("cpufreq-dt", 0, NULL, 0); + + i2c_register_board_info(3, i2c_devices_tinker_mcu, ARRAY_SIZE(i2c_devices_tinker_mcu)); + i2c_register_board_info(3, i2c_devices_tinker_ft5406, ARRAY_SIZE(i2c_devices_tinker_ft5406)); } static const char * const rockchip_board_dt_compat[] = {

Sometimes I need to feel better about my Tinker Board. This makes it all better.

HID is now working, of course the touch input does not rotate with the screen (perfect compatibility with raspberry pi! ) I can link to the Deb packages for the kernel/dtb if anyone wants to try them out, and if anyone with a MiQi can make sure they don't break anything before I push the patch to the repo.

Sadly @tkaiser is right, the advertised specs and potential of such a board is great, but the reality is lacking any attention to detail or due diligence. It is a terribly disappointing board in my honest opinion. Now, to the task at hand: behold Armbian legacy with DSI display. 4.4 kernel I'm going to have to take a look at why this doesn't work on later kernels. No HID device yet, so still to-do items. [EDIT] I found the touchscreen driver, we'll see. Then I'll have to have someone with a MiQi test that everything is still ok on their side.

I read that too, so it rolled out in RC4? Left hand doesn't know what the right hand is doing...

Trying on 4.4 kernel tonight, I got an entirely different behavior, no backlights or anything, and a command received message. I am going to review the code tomorrow to make sure I didn't miss a patch, it should be saying more than that. [ 3.052832] tinker-mcu: tinker_mcu_probe: address = 0x45 [ 3.052849] tinker-mcu: send_cmds: 80 [ 3.105012] tinker-mcu: init_cmd_check: recv_cmds: 0xC3

*head explodes when vendor asks community to rewrite drivers*

Thank you @balbes150, I am not familiar with the Amlogic boot system, your material was a lot of help.