TonyMac32

Let me take a look, I hadn't noticed that. I see it on mine as well.

So mash the enter key while in a serial terminal during boot. I believe that works, they didn't disable it.

http://www.friendlyarm.com/index.php?route=product/product&product_id=151 add the I2S DAC (has IR on it) and you should be able to make that work. If you don't need wireless the nanoPi Neo is cheaper and also has the same DAC+IR addon. I use that for exactly that purpose (I don't use the IR though) You can go without the DAC and use the onboard audio as well, you'll just have to add an IR somewhere.

I don't have a C2, but please update the topic to reflect the board in question, in this case "Odroid C2 Default eMMC issue".

https://github.com/TinkerBoard/debian_kernel/pull/5#issuecomment-367930082 So, if anyone wishes to contribute to the official ASUS kernel, it will be much easier.

Are there Linux drivers for that keyboard? I feel like we talked about that before, do you have the lsusb output while it's plugged in? Sent from my Pixel using Tapatalk

Update: upcoming default (4.4-rockchip)image update will include services loading bluetooth on boot automagically.

Hello Bluetooth. Thanks @Igor for the services help, loading on boot no problem. Played some music through the board from my phone over Bluetooth, nice and smooth.

your kernel: Linux version 4.4.112-rockchip (root@xeon) (gcc version 5.5.0 (Linaro GCC 5.5-2017.10) ) #7 SMP Thu Jan 25 01:04:58 CET 2018 Did you build this one? And from which source? the kernel config could be the problem. I followed these instructions using my uploaded kernel packages with no issue. I also see we need to go in and kill off that excessive debug message in this kernel on the WiFi as well...

@Igor I'm going to roll back the Tinker S board ID patch until I can get more information (GPIO errors all over the place) and we should be good for a new image. The bluetooth service still doesn't work, I even checked the ASUS one, so I'm not surewhat's going on there, I'll try their rtk_hciattach quickly tonight to see if it is somehow better. (the one I've included works on the command line with no issues, but won't load properly with systemd)

Remember the part about freezing your kernel so the changes don't disappear after updates ;-)

@Meta I'd be careful with the term "as advertised". ASUS sells it as a Pi killer, and it is, even with the drawbacks. It is not a workstation or a server, it's a multimedia desktop / thingy. My biggest grief with the design concerns the decisions that could have gone differently to make it better at the things a typical Armbian user wants, like the soundcard having a dedicated USB while everything else has to share, no dedicated power option besides the microUSB, etc. I'm waiting for even one company to provide a board with a header for powering the board without using the microUSB, so far nothing. Now, if you want faster board there aren't a lot of options unless you're doing something that ARMv8 has extra support for that will overcome the slowness of an a53 vs the a17. The Odroid XU4 has 4 A15 cores and I believe performs similarly, and has a bonus of 4 small cores as well. In more practical terms, it also has USB 3.0. Downsides are GPIO are 1.8 volt, cases are expensive or cheap feeling, and the processor goes from 40 to 80 C in about 1 second, being very hard to cool (I liquid cooled mine just for kicks). It is what runs my Plex server. Otherwise I think even the 3399 is only questionably faster in certain use cases, only having 2 high-powered cores and 4 "slow" ones. With the new "S" model there is voltage detection to see if the supply is dropping. I need to look closer at it, it may be possible to avoid writing to external media in that situation/etc, helping to safegaurd data. Otherwise, like with all other boards, power the drive separately from the tinker. If you want to do industrial grade things, get a chassis supply with at least 10 amps available and power all the components accordingly. I want to design a power supply hat for pi-factor boards, focusing on cheap + effective, if there's interest I can give it some priority. It would ideally expose barrel jack, and a terminal block, and possibly put a USB A to power externals. Like the Pi touchscreen.

That should be adequate, verify it's accuracy with a dummy load to make sure. As for the shunt, how were you reading it with the Tinker board that allowed a power disturbance of that type? Nevermind, misread. ;-)

The USB ports are through a hub, what else is plugged into USB? Also, what cpu governor are you using? I'm afraid my knowledge of the internal working of pulseaudio is non-existent, hopefully someone else reading this will be of benefit.

updated OP

Tinkerboard Onboard audio is now available out of the box for build-it-yourself enthusiasts on default kernel. New image should be ready in the following days.

Win32disk imager is the only tool I have had repeatedly corrupt writes. Do you have any empirical evidence for your claim? I use etcher everyday with no failures.

First we need the output of armbianmonitor -u Then, we can have an idea what's going on. What is attached, what is powered by, etc.

I put this on the bug, but did you try https://www.sdcard.org/downloads/formatter_4/

yeah. I'm sure, I can probably find some examples for that. The permissions are in the build system now, so item 0 should be unneeded.

A major bonus with these new H6/RK3399 boards is that we shouldn't have to worry about micro-usb. if you want the "cool stuff" you need 12V.

A20: @Igor - legacy kernels should go out due too overall bad kernel quality - reboot/poweroff problems on some boards H3: @chwe - CSI (camera) doesn't work on mainline, gc2035 needs an small script in legacy to start up properly - Armlogic: @TonyMac32 - Mainline support effort is still relatively new. Things like USB, audio, etc are WIP. - "Legacy" kernel that is stable is old and EOL (3.14) and I haven't fooled with it. In that world and all others Amlogic, @balbes150 is the master. - Newer legacy kernel is still a work in progress (4.9 w/bugs) - u-boot blobs are lame and make using mainline u-boot difficult (need both legacy 2015 and mainline u-boot to get a working image) - Lower quality of open source information, all more or less community driven by a very small group, unlike with say Rockchip with a large amount of published info from Rockchip themselves. Rumor/commits say this may change with newer IoT processors. Freescale: @Igor - the legacy kernel is getting obsolete. No point to have it. - possible to implement hw video acceleration on mainline kernel - Solidrun has new 4.9 kernel, but can be safely ditched for mainline Rockchip (I suggest only the one we support at the moment, not RK3399): @chwe - CSI (tinkerboard, rk3288) is supported (RK 4.4 bsp kernel) by kernel (OV6547 OV5640, imx219 - RPI-cam V1.3 resp. V2) but doesn't show up properly when booting) @TonyMac32 - Igor and tkaiser are already seeing this, but mkimage/uboot/trust can be finicky. luckily that's a "figure it out and move on" situation, but it is likely to cause headaches. - 4.4 kernel is an increasingly old kernel, now 2 LTS's in the past, however still much better than a lot of others (also has a lot of activity) - RKwifi is something I don't know the reason for. I don't know why it exists, I don't know what it does (other than cause problems). It is a wrapper for some wifi drivers/an rfkill system - Rockchip likes to use their own subsystems in many things, like the "MPP" system for media playing. This has different capabilities per SoC, so may not behave predictably to simply be able to say we know how to use it. Marvell ARMADA: @Igor - missing SFP support in mainline Armbian related scripts: @chwe - h3consumption is legacy only -

I'll start over with a clean file and see. @JMCC that cleared it right up. Very nice. it gets quite upset about the touchscreen being attached though, I'll probably have to figure that out. Perhaps a script the user can run to enable this stuff would be best glmark2-es2 score was 54, it seemed to be locking fps to the screen refresh, webgl worked perfectly, youtube was smooth at 1080p even without hardware decode.

I'm getting "Section" is not a valid keyword in this section"

I was going to do some more checking on this right away, but I forgot to take the highspeed out of the SD device tree and now it won't boot. I'll be back after dinner when I swap my old device tree back in. (I have a very old potato without the 1.8volt line. You would think after messing up so often I'd stop. Nope.)