TonyMac32

hmmm ok. So the -rc8 show the issue before you disabled SDR104? Just trying to narrow down the issue. What I understand is that, at least for eMMC (and so I would assume SD, but it may not be), before recent clock fixes the old data clock rates were, in reality, only half the desired setting, so now limitations of some boards like the C2 are showing up that weren't known before.

One last question, can you give the kernel versions so I can see if this is an issue that has been addressed upstream or if it's still an active concern? With any support request it's helpful to provide the output of "armbianmonitor -u"

Tinker is suffering the same. :-/

I was planning on trying that tonight, I'll share notes if you will. ;-)

Very nice, built a 4.4 image, working well so far! Need to dig up an nvme, suggestions on an affordable one? My build machine and main desktop aren't giving up theirs. ;-)

Is it UHS in general or only the highest speed modes? for example, disabling SDR104 may be enough?

Honestly I pick up stories on CNXsoft and from this forum. Otherwise it's "who you know".

@tkaiser I had something messing with the GPIO pins, after a good cleaning we're back to the proper function. I hadn't tried it on the S yet, my early test board would shut down if you tried to power it via GPIO so I was overly suspicious I think.

Bump for anyone watching, updates.

Almost certainly a power supply or SD card issue. Lots of cards will work in laptops/phones that are still no good, and power supply issues are a constant. Are you using the microUSB or barrel jack?

**UPDATE August 9 2018** After some messing around I determined I had some sort of contaminant on my Tinker Board GPIO pins interfering with their conductivity. I have rerun my GPIO powering test and added the results below, there is no additional drop ( @tkaiser, @Frank Wu I apologize for the bad information) Other small updates include a possible reason for the small voltage reporting measurement error. After having received an official Tinker Board Power supply, I submit my findings: Test load hardware: Tinker Board S with internal voltage monitoring Condition: No peripherals save mouse/keyboard/small cooling fan to prevent throttling Load: minerd --benchmark Measurement: For this I diverged from my typical labor-intensive periodic check with a meter and instead allowed the Tinker S to do the work. It for sure added noise to the measurement, and so some uncertainty, however I think for the purpose here it is sufficient. The Tinker S reads low when you get to the 5.0V area. I measured the system voltage at 5.11V using the chassis supply, Tinker reported 5.02, however the values converged as they approached 4.7 Volts. This is possibly due to the reference voltage for the ADC drifting ever so slightly with or without load. With the new GPIO information, my meter and the Tinker Board were registering almost exactly the same voltage (within 0.02 volts) during the test, at 5 volts under load. As to the supply itself: Laser marked info is a nice touch, molded strain reliefs at the adapter and the plug, rocker switch for power, and 18 AWG wire. Electrical: 5.0 V 3.0 A. This will be operating near the bottom end of the spec for USB peripherals on the Tinker due to voltage drop. The wire is heavy gauge and is in a "lamp cord" format, the jacket is flexible so I don't foresee too many internal strain breaks in anyone's future while using this supply. Data: Analysis/Commentary (very loose format): Using a 5.25 V chassis supply with my standard issue 1.5 meter 20 AWG cable that has seen a few hundred mate/unmate cycles for comparison, you can see that the system really needs to see more than 5V at the microUSB connector, and that cable age and wire gauge matter (my cable showed significantly more than 200 mV of drop, the new Tinker Board supply is showing a good bit less (the 4.9+ V spike is an anomaly I am attributing to the sudden release of electrical load) Keeping an eye on the dmesg for indications of my USB peripherals resetting yielded no complaints. It is experiencing excursions just below the acceptable minimum, so that will be something to look out for. There is also the simple reality that the Tinker Board is not adequately cooled to pull this sort of current continuously, it goes into thermal throttling within seconds under full CPU load. Recommendations for consumers: This supply will work, and is at least on par with the other similar units on the market. The large conductors reduce one of the most common causes of voltage drop, and connector, I assume, is validated to exceed the 1.8 Amp minimum spec requirement for micro USB as per @Frank Wu. Such a validation provides some insight into the voltage loss, as increased voltage loss results in increased power dissipation at the connector, the thing being actively minimized by such design/test work. Recommendation to ASUS: If it is at all possible request the supplier increase the output voltage of this supply by 250 mV. At that point it could be considered the "go-to" supply for anyone wanting to maintain the micro-USB RPi form-factor compatibility.

Received an official Tinker Board supply today, will make a new topic for it, but the short version: 5.0 V 3.0 A, so no breathing room to cover voltage drop. 18 AWG wire size, "lamp cord" style. nice little switch (rocker, no illumination) Seems very stable under load. Some notes on the Tinker S: It's reported voltage calculations are a little bit off, at 5V it reads about 0.1 volts low, and at 4.6 it is reading a bit high. I'll have to properly probe it to verify and see if this is the case across my boards. This is most likely due to reference voltage drift on the ADC. The new supply configuration is set up, it introduces a large voltage drop if powering via GPIO, enough that 5.25 volts to the I/O pins reads at least 300 mV or so lower than 5.25 on the microUSB port. After some cleaning of the terminals I got the expected results, I apologize for the false alarm

We don't support any of these boards, I have the i96 version of the 2G and never booted it. I'm afraid, unless a random user has experience, we've no help to give you on this topic.

That would be my recommendation.

I thought so, but it didn't seem to have an effect. I'll try again later. Removing all the conditional logic and just echoing the device value worked fine, other than formatting to 20 digits of precision (no printf in the Tinker case). The removal of the single quotes works in the if, but it didn't seem to do anything in the context of the for statement, I wonder if the \ is being interpreted/passed incorrectly.

Hmm, something isn't pleased at either the '' in the for .. in .. do or the checks. If I simply echo the value it works, otherwise nothing.

Haha no, I have seen that tonymac's work though. I'm not much of an Apple fan, personally, the tech is nice but the price isn't. Take a look at docs.armbian.com and give building a try, we're always happy to have help!

I saw that as well looking through the available docs. If the performance seems on par with rk3328, then perhaps that's a plausible enough answer.

@tkaiser I was bugfixing but saw you got to it first, I assume after a reboot this should show up in armbianmonitor -m? So far nothing. I've verified that /sys/bus/iio/devices/iio:device0/in_voltage2_raw exists and does read values that, after the math jumble of doom, seem correct.

Checking cpufreq OPP... Done. Executing tinymembench. This will take a long time... Well, no luck, apparently nothing about size is in the node. what you can see is what is in the fliers, data/instruction cache per cpu and a unified level 2.

I provided a quick answer via my phone earlier so here is a bit more complete: Use a shorter cable if at all possible, and check the conductor size. OK, so 150 mV of loss isn't great, but it's not unheard of either. The "S" has, as you pointed out, some hardware for detecting power supply issues, I would guess this could potentially result in some minimal losses the standard Tinker did not have. My Tinker S, using a 1.5 meter USB cable I purchased on the basis of it's wire gauge (20 AWG I think? I doubt it's 18...), 5.25 V supply, 10 Amps, is reading 5.17 Volts at idle on the USB Master port. running "minerd --benchmark" to load the CPU I dropped to 4.8.

Firstly I have not tested a Tinker S specifically, the power input I different. But the answer is no, without using gpio you cannot overcome the voltage drop. I have no read the data sheet for the RK808 PMIC, but I doubt you can cross the 5.5V threshold without possible damage.

OK, verified hotplug issue on Rockchip when building a 4.18-rc. Also verified there are a seemingly random assortment of other bugs.

If you get VPU working on RK3288 this will be a crazy SBC year, since Amlogic video code is being reviewed, Allwinner is working, etc. This USB hotplug issue, I saw it on Amlogic, but I didn't see it on Rockchip. I did miss a few weeks though 4.17.7 or so I think it "disappeared" from being a problem on Amlogic.