TonyMac32

To my knowledge this has always been the case. I'm looking into whether or not this is bootloader related I think the C2 was doing something similar?, as for the light: The Red LED does not appear to be software controlled from the schematics. DC-in goes through what I think is a reverse voltage/backfeed protection circuit and then through a step-down to 3.3V feeding the diode. No software intervention.

@Igor I think we can push 4.14 to NEXT, I have it ready to push, but there is the disabled RT patch that I haven't looked at. (I'd forgotten all about it honestly) Leave it for review later? And can I push the changes? Changes: -NEXT to 4.14.y (LTS?) -Patchset as discussed above. _ _ _ | | ___ _ __ ___ | |_ __ _| |_ ___ | | / _ \ | '_ \ / _ \| __/ _` | __/ _ \ | |__| __/ | |_) | (_) | || (_| | || (_) | |_____\___| | .__/ \___/ \__\__,_|\__\___/ |_| Welcome to ARMBIAN 5.35 user-built Debian GNU/Linux 9 (stretch) 4.14.1-meson64 System load: 1.48 0.38 0.13 Up time: 0 min Memory usage: 3 % of 1850MB IP: 10.0.0.101 Usage of /: 9% of 29G New to Armbian? Check the documentation first: https://docs.armbian.com This kernel/patchset likewise results in a workable NanoPi K2 (minus wifi at the moment), can be tested.

Indeed, it took me 20 minutes while watching Youtube videos about cats. @chwes initial recommendation is still the right one, he is just shamelessly promoting his GPIO project (I use it too ).

Thank you for the clarification, @Da Xue. I'm currently testing out the 4.14 mainline patchset, so far I've been pinging the board for 12 hours and am now (30 minutes) running an SSH from it without the ethernet going down. I'm going to add an SSH into the board as well and let it run something or other that keeps the network traffic flowing. [edit] 2 hours with a self-refreshing webpage and an outgoing and incoming SSH session display "top" and no network drops. [edit 2] I added an audio stream to the mix and it proved to be too much, I lost connectivity with the device.

#TinkerFire

I saw that, and was going to play with it next. Thanks again!

Le Potato Dev updated with 4.14 Libretech patchset, thanks to @Neil Armstrong . Anyone willing please build/test, the intention is this become the "next" image.

The current image is a "testing" release for that reason. Also, 4.13 is an "in progress" support situation for the meson-gxl, I'm running 4.14 with the current patchset through some testing to move NEXT to it.

http://www.x-powers.com/en.php/Info/product_list/cat_id/31 The AXP8036 seems a lot like the Realtek USB audio on the Tinker Board, it doesn't exist. ;-) (I assume it physically does, but datasheets seem impossible) Does not look like there is any hope for voltage scaling however, that is a fixed regulator. Hmmm... Is this supposed to go back to VDD-CPUFB on the SoC? That would be my guess, otherwise why not tie them together? There are fuses on a lot of boards, the RPi's, Le Potato, the Khadas VIM, it is one of the hazards of bypassing the factory connector (even if it is u-USB). They're always self-resetting thermal polyfuses, although it's always extremely important to understand how long it takes one of those things to "blow". for instance, if that's a 2 Amp "hold" fuse like the Littlefuse 1812L series, it will take 8 amps a maximum of 2 seconds to make it go fully open. In that example it also has a series resistance of 20 to 70 m-ohms. I don't see a header for DC-in, but that's not surprising.

@Da Xue, I can't find where that would go in stmmac_main.c, I would guess there are some other patches leading up to that one? static void moniter_tx_handler(struct work_struct *work) does not appear to exist in any kernel I can find.

Thanks @Da Xue. If no one gets to it before I do, I'll test it this this evening (Eastern US)

[UPDATE] Turns out the NanoPi K2 was also affected by the Amlogic ATF allocation issue, I patched the device tree to rectify the issue. Not well tested, but I could kill it in a matter of seconds before, it does not fail under any memory-intensive test I could throw at it quickly.

@Igor I'm seeing the same behaviour from the NanoPi K2 (same reference design). Not being 1st priority I haven't dug in too deeply. I applied the ATF patch similar to the meson-GXL (Le Potato) and that fixed it on the K2.

The Tinker Board legacy did this, I had to change frequency governors from "conservative" to "ondemand". That's assuming you haven't already done that. ;-)

It is common with anything designed for developers/marketed to hobbyists. I feel like this would have been common at old radio club meetings, where someone forgot to wire in an antenna... In reality the board makers needs to include some of this education in the package if they are working this way, human nature does not include reading the FAQ when joining a forum.

Also remember these TV boxes are not usually cooled very well, so they go into thermal throttling quickly. As you'll see reading below, the closed-source Amlogic bootloader blobs may also have a say in the quality of your experience, they seem to vary significantly. I'm experimenting with a TV box right now which runs horribly no matter what "ROM" I put on it, so I'm starting to suspect the bootloader. If the Khadas VIM was a Bugatti Veyron, the mini M8S II is currently a Volkswagen Rabbit with a dead cylinder and bad fuel...

I have a few of those little guys, that's funny.

I tested this out, I can control those pins. Is the issue that the SPI driver can show up and smash everything? And if so, is this possible accidentally, or would it have to be triggered by an unsuspecting user? Side note for @tkaiser I was getting about 160-190 mA consumption (varied widely) on the vendor image, with the nightly Armbian I get about 150.

Well, I had some trouble at first, since I'm bread boarding without shield and missed Without (e.g. connector.J1p7 or connector.J2p5) duh... I will come back after I spend some time playing.

Feedback and requests appreciated, obviously I don't have infinite resources and time, but ideas are always good. Also, there is a test image specifically for the Duo, so far so good. https://www.armbian.com/nanopi-duo/

Any reason you're not using 4.13? 4.14 is still a Dev release, it's not fully patched.

I put up a blog about "breadboarding for cheap misers" showing some simple ways to make certain components breadboardable (like USB A Host connectors), leading up to "Breadboarding with the NanoPi Duo". This thing is a lot of fun, to be honest.

Submitted the fixes to ASUS as well, should be included in their next kernel: Pull request

I had seen the website updates with the names a couple days ago, hadn't caught the campaign, good catch. @tkaiser I agree with you on the powering situation, I wish we could at least see a dedicated pin header for those who know better.

Unfortunately, being beta, I don't believe any of the changes are reflected in the github. I do need to go through and see what's been added to the Tinker-specific kernel in the past few months, and again see what I can do to make it work with MiQi (This is not MiQi's fault, this is pure Tinker Board nonsense).