TonyMac32

Current list of things to fix before I'm looking at Tinker cameras:
 
-Mali
-Touchscreen
-device tree overlays
-Tinker S hardware monitoring (voltage and headphone plug, eMMC availability with the jumper in recovery mode)
-Meson64 stuff for other boards that I also help maintain.
-something that will certainly require attention before now and then
-cameras that only work with 1 board.

My addiction got the best of me and I picked up a RockPro 64 as well.  ;-)
 
OK, back to the cellar...

Well, we're not a free resource for other people's projects in this specific of a context.  What you're proposing would easily double the workload I put into a side project that does not pay my bills, simply so you can have something for nothing, so they say.  I'm not trying to be rude, but I don't have time for every user's pet project, Once I get the latest Rockchip updates stabilized I may spend some time on getting the ISP driver working, or I may not, but that will be the limit, is to get the hardware to a functional level.  Any special or new functionality is outside of the scope of what I have time, resources, and in some cases knowledge.
 
 
And you think a loosely affiliated group of programmers doing this for their uses and enjoyment can?

I have created a branch for amlogic device mainline u-boot, I have successfully booted le potato now, it took some small adjustments to support the 2015 boot script.  Anyone wishing to try this use LIB_TAG="meson64-uboot"
 
Next steps:
 
use a proper boot script to take advantage of armbianEnv.txt and bring Le Potato to modernity.  using C2 as pattern bring up mainline support for K2

Sounds like ARM development summarized into 1 statement. 

Exynos 5422 media script released.  The most important new features compared to the steps posted a few months ago in this thread are a FFmpeg 3.4 supporting hardware encoding,  some Kodi with decoding acceleration (in addition to MPV), and the possibility to install in a headless machine with  non-X versions of the libs and programs. Besides, of course, the goodies already included in the RK3288 script, such as Netflix support or OpenCL samples.

Verify 110 ohms here, powered on no shield.

Because Linux support is not mature for the H6?  It's hard to release a distro for something that doesn't have proper kernel support. :-). 
 
@Vincen, The Asus Tinker Board, and MQMaker MiQi have experimental video decoder and GPU support.  I'm not as familiar with the other boards to know what they can and can't do in that department.

Most of us probably do some electronics along with the small computers, I've been part of "what does you desktop look like?" threads (terrible, by the way), thought I'd put up (the electronics part of) my workbench:
I wasn't about to lie and clean it up before hand...
 

This explains why I'm posting again.. I finally have a work area!

The

Hahaha no, I was excluded from "The list".  Only a joke, and there has been some quite loud opposition to naming a "king of the project" or an "inner circle". 
 
Personally I think a lot of this comes down to not wanting to assume the complexity of a larger project, but the project has decided it won't wait for that complexity and is now demanding it.  We're at the point where Armbian gets mentioned in kernel mailing lists about various SoC's, so our ability to address issues is becoming quite public.
 
I only push the branches because if someone makes a stupid branch we can kill the branch, and changes won't be wound around anything else that may be useful causing a horrific mess.  
 

Hahaha no, I was excluded from "The list".  Only a joke, and there has been some quite loud opposition to naming a "king of the project" or an "inner circle". 
 
Personally I think a lot of this comes down to not wanting to assume the complexity of a larger project, but the project has decided it won't wait for that complexity and is now demanding it.  We're at the point where Armbian gets mentioned in kernel mailing lists about various SoC's, so our ability to address issues is becoming quite public.
 
I only push the branches because if someone makes a stupid branch we can kill the branch, and changes won't be wound around anything else that may be useful causing a horrific mess.  
 

I experimentally booted an orange pi PC 2 image on mine.  Starting from there and correcting the device tree to match the actual hardware should be sufficient

To update my thoughts/observations:
 
Pros:
   
Exactly, to some extent this is the base model of Allwinner boards.  Short of a failure to build it correctly it is simply going to work.  (I drive a car without power windows or locks, so I'm partial to simple things)  Low development support footprint for something people will buy. Using all SoC peripherals, no random changing of wireless chips or ethernet PHY's to cause wrinkles/confusion. Also low development/support footprint. Faithful replication of RPi form factor (for those who are interested in that, which is a few people) Upstream mainline activity is basically done, the device trees/etc are already available, no exotic hardware All 3 boards share the entire device tree other than the processor compatible/include. Pin compatible, so the same board definition goes for all three.  Low development/support footprint again. Cons:
Typical "powered via micro USB, beware your system voltage" warning applies. Not sure how many devs have it/would be interested.  Somewhat mitigated by the "simplicity pro" No voltage scaling, although I'd have to see what the power costs truly are, and test stability. The biggest confusion I see is actually in the naming and marking scheme.  Users, after putting their heatsinks on, may forget which one they have and download the wrong image for their "ALL-H3-CC" (written on every board).  There are no distinguishing marks other than the giant "Hx" on the SoC itself, which you cover up.  I would like to think the average user could figure it out, but...  I propose this board series be placed in WIP. Typical statement about gpio powering/"no single board computer really meets the USB host spec for power delivery" etc.  Once I remember my details I can make an entry for it on the page.
 
I will need to change the H3/2+ config away from the current device tree and substitute in the correct one now that it exists.  Do we want separate configs for the H2+ and H3?  Or would it make any difference other than the user being confuses at seeing "H3" in their welcome screen?

SoC's have built-in support for changing frequency, generally.  So the "Magic" is a driver controlling a clock generator/multiplier.  However, most of the time, with reduced frequency you can reduce operating voltage a little bit to save on power and reduce heat.  In this case that isn't going to be an option, on the Allwinner-based boards that support it it's a bit of a hack in the first place, using a transistor on a gpio to change the target voltage of the system regulator by adding/removing a resistor from the regulator's "voltage setting".  This board does not support that.  On a board like the Tinker, Renegade, Rock64, there is a matched/recommended regulator chip PMIC that takes commands and adjusts the voltages accordingly in a much more controlled fashion.

Uhhhh yeah.. so uhm batteries.   Keyboard is good!

My Tritum h5 board came.   I just built an image from Dev branch using Tony's tritium-5.csc. w/ Kernel 4.14.43     Fired right up..... Even has console login on HDMI.   (although its not returning keystrokes at the console)
 
but I ssh'd in an all is well.    
 
Trying to understand a bit more about regression bug.   I'm running at 1.01ghz.  Is that related to regression bug?   Basically trying to understand on how I can help achieve parity with the Clock on my Opi PC2 or Prime. etc

Correct. A bit strange. There is a dw-hdmi patch that needs a fixup, but I tried to to no effect.

@Igor my support patches for this board do the opposite of the OPi PC2 image I tried, I get debug console with uboot on mine, but no kernel hdmi, the opi image made today has no uboot hdmi but does have kernel.  I'm sure I'm doing something ridiculous...  Any argument about uploading as CSC even though it's headless?  it's only a csc, uboot and kernel patch to add the dts's?

Available on Amazon and from most SBC companies, most are 3.3 volt logic, some (Odroid XU4) are 1.8 volt.  It is a USB to serial uart adapter.

Bumping this due to some random issues seen with PulseAudio and perhaps ALSA allegedly due to the PA scriptto properly name the onboard USB names.  @chwe, if you would so kindly take the last few posts from the Tinker Board Bluetooth thread involving audio and stuff them in here?

It comes from a few things, vendor relations is one of them, but not the only one.  There is often an issue with vendor software and documentation being incomplete/incorrect/non-existent, sometimes hardware bugs, etc.  It may be improving, I haven't checked recently.

Well, the channel is showing up in the sink devices for PA, but I'm not getting anything out via my monitor...  I'll do some more checking

let me build it and we'll see.  ;-)

Anything in-tree, I don't see a problem.
 
Yep. 
 
I have the service working on my end, I consolidated everything down a bit to reduce the number of working parts/etc, one thing that stuck out was the script @Jyu Ho pasted in had an else block which meant if the gpio was not initialized it would initialize it and then not attempt to reset/communicate, I was confused for a bit when I'd boot and have the GPIO ready but no bt.... 
 
@Igor, if this works as expected on every boot I'm going to try it on 4.4 and potentially avoid using the Rockchip rfkill altogether, it bypasses any unexpected software updates/"upgrades" that might happen, especially since the rtl8723bs isn't even technically supported so it is treated as "generic bt" [Done]
 
I'm going to do some cleanup and get this committed to next/dev.  I also apparently need to fix hdmi on dev, but Myy already took care of that. 
 
Updated first post to reflect status, stuck the historical info into a spoiler.
 

@Myy looky here.