TonyMac32

*** This is educational material only concerning current limits and their effects on things like rise and fall times, and how they can theoretically impact SD cards.  The correlation with reality is purely theoretical and has not been empirically proven, the concept is correct but any specific values may be/ probably are off by some factor***
 
A lot of boards from various vendors inevitably have some difficulties with electrical signalling.  You see it in delay values, phase correction in software, etc.  The general prevailing theory is almost always "get it close and fix it in software".  But, the software team is not always clued in, or the physical reality is simply not able to be fixed that way.  Today I'll go into SD cards and the need for proper signal paths, limited capacitance along the way, and proper drive levels at the SoC.
 
This came to my attention while reviewing failures to boot on RK3328 devices, and while this particular issue may still be independent (no root cause confirmed as yet), I have a suspicion it is at least a contributing factor.
 
GPIO's on SoC's have, typically, current limiting on each pin or bank of pins.  For Rockchip, this limit defaults to 4mA, with 8 and 12 being available as optional settings.  This includes the SD card bus, clock, output, etc.  These current limits are exactly that, limits.  If the interface only needs 1 mA, it will only pull 1 mA, regardless of the GPIO drive setting.  if it needs more, however, it will only get what the drive setting allows.
 
SD card interface standards have 3 voltage signalling modes, SBC's only make use of 1 or 2 of them.  Many boards supply only 3.3V to the card, limiting to frequencies of 25 or 50 MHz.  Those that support UHS-I modes allow 1.8V signalling, and the range of speeds there include the original 25 and 50 MHz, but add higher speeds as well (100 and 208).  The higher speeds absolutely require the lower voltage, though the 25 and 50 Mhz speeds benefit from it as well due to improvements in rise/fall time with the smaller voltage transitions.
 
The SD standard requires a total line capacitance of 40 pF or less on each line, including the internals of the card.  I will simply assume 40 pF for the simulations, as it's likely few if any of these boards are "optimal" in that regard.
 
I'll be using LTSpice as an aid to show the effects of the current limitations, measuring voltage across the capacitance.  In reality there would be a complex impedance with the resistance I'm not modelling and the capacitance distributed throughout the system, which would cause some slightly different behavior.  This is mostly an educational introduction to the scary universe of high-frequency switching, so I'll skip the really gory details for the sake of readability.  In this circuit the LimiterDiode does exactly that, it limits current.
 

 
With a 4 mA limit into a 40 pF load at 3.3 Volts, 50 MHz, the signal is unusable.  Top in blue is the current sourced by the supply, stuck at the 4 mA limit at all times, below in red is the desired waveform, in green the result.
 

 
The board will crash if it attempts this.  Now, you might say, what if the board is extremely well made and the capacitance is lower?
 
Well, it looks like this (assuming 20 pF, which may not really be possible):
 

 
Still, no hope of operating properly.  Dropping to 25 MHz has roughly the same effect.  As I said, this is worst case, so don't jump down my throat about your board with the limits working at 4mA.  I am also assuming 4 mA source and sink limits, it may not be symmetrical, in which case the shape goes from triangle to shark fin.  Cutting the voltage almost in half by going to UHS-I signalling levels has the same effect (ratio wise vs the V_High value) as cutting the capacitance down.
 
On the ASUS tinker board this was discovered at some point, and the current limits increased to 8 mA.  I have not tried a card with no UHS support at 50 MHz (at least to my knowledge), the results at 3.3V/50MHz still look bad in my oversimplification, much like cutting voltage in half or capacitance or frequency, again, they all play into the same charge rate/time constant
 

 
At 25 MHz, however, 8 mA is far more reasonable:

 
Now to the big reason for 1.8 V signalling:

 
50 MHz, 1.8V, 40 pF, 8 mA drive.
 
Assumptions:  source/sink values both controlled.  It's possible this is not the case.  If there is no "sink" limit, or if you assume 20 mA sink limit:
 
 
3.3V signalling, 50 MHz, 40 pF load, 8 mA source, 20 mA sink:

 
Now, as a final bit, assume there were no current limits of any kind, and let's measure what the system would need to supply at 50 MHz 3.3V:

 
So 120 mA or so to create the exact waveform, assuming some sort of simulated resistance somewhere in the system (in reality there would be a measurable resistance and therefor a current lower than 120, but also a longer rise and fall time)  Needless to say, a lot more than 4.
 
This is mostly important for boards that do not implement the 1.8V signalling modes, but do have aggressive current limiting on the SD card I/O's.  50 MHz is a bad place to live at 3.3 volts given a mechanical connector with wide flat terminals, and routing that doesn't always get as much care as maybe it deserves.  RPI, a board with these issues, seems able to source/sink 16 mA, most likely accounting for it's ability (when not starving itself for power, cooking itself, etc) to be "overclocked" in highspeed 3.3V mode.  Rockchip can only push 12 mA, I haven't read up on Amlogic yet, so you can't expect to have the same performance if you're not willing to add the necessary support for 1.8V signalling.
 

ahahahahahha had the same problem. even bought a new power supply and a new sd card BUT!!!!! oh shit... the first login ask to change the password and the prompt say "current password". here I failed to enter 1234 again!!!! so the trick is to type twice 1234 and then the new password... anyone need a 16gb sd card????

one from the category: "Scientific Mob"
 
https://quillette.com/2018/09/07/academic-activists-send-a-published-paper-down-the-memory-hole/
 
Disclaimer,  I didn't read the paper fully, not my field of interest...  Only the blog post. But this one shows clearly what's IMO going wrong in the scientific community.  It's not a problem that they fight against papers they don't like/ or can't agree for whatever reasons. Scientific dispute is healthy for science. The way they choose is IMO wrong. You don't stand for your opinions if you do it behind the scenes.  You don't stand for them if you force half of a board to resign in case a publication gets not rejected. 
As soon as this gets public, no matter how valid your arguments are, as soon as it's becoming public that you used your standing and your power behind the scenes, your arguments are negligible. You loose IMO all your credibility for your arguments by choosing the wrong way. The other way will work for sure, but it harms credibility on more than one field. Not only for yours, but also for future disputes. It harms the scientific community when they use the same methods which are responsible for a decrease in trustiness of business, media or politics. If you  belief that the authors arguments and theories are so wrong it shouldn't be hard to fight with proper arguments right? We should be better than trash credibility only to get a paper not published which might be questionable. Not my field to properly sort out his nor his opponents arguments. A 'censorship'  of a paper which 'survived' the peer review process of a Journal is IMO wrong, or at least it needs a discussion with public statements how this could happen. 

Tried the newest build for the K2. You guys are awesome. It has not locked up once and i can install it on usb media. Thank you so much for the hard work.

20x20x1mm. Ordered them 18 months ago on Aliexpress for 2 bucks (5 pieces) but the link is dead. Anyway: I don't think such a copper shim is a good solution for end users. Heatsink able to be directly attached to SoC is better.
 
Will try again with my next RK3399 board with thermal glue between heatsink and copper shim and normal thermal paste between shim and SoC. Currently I fear a bit the shim could move when vibrations occur.

OK, the audio confusion that was going on is, I think, resolved.  I cleaned up my pa configuration patching and added a udev rule so pulseaudio doesn't enumerate the device twice (which it was doing)
 
udev rule targets the specific VID:PID of the onboard ALC4040 so external USB cards still work (currently listening to a 2007 Creative Labs X-Mod)  <--  Card is crappier than I remember.  Maybe some caps are bad after 11 years of abuse/neglect, I hear audible noise in my headphones.
 
Build and test if you would, it will be in the next release.
 
[edit]   Kernel 4.18 is now bootable, but needs some love before it's ready for use:  http://ix.io/1lpi

LOL! Yeah, asking the SoC vendor constantly cheating on users... haha, no, my simple approach is to stay away from everything where's Amlogic printed on!  

Thanks for your suggestion, we’ll check that.

Not bad at all.  If it isn't shorting anything out and you can tolerate the geometry, it is fine.  Stick with copper or aluminum for heat sinks, more mass results in higher temperature stabilty, more surface area means more dissipative value. 

On the RK3288 boards, if I am remembering correctly, the drive level is modified in the dts to avoid this issue.  Is that possible with the RK3328 at least?  I think the mmc IP is the same, but don't quote me on that.
 
[edit] 
https://github.com/torvalds/linux/blob/master/arch/arm64/boot/dts/rockchip/rk3328.dtsi#L1432
 
This part of the dtsi shows the default 4 mA drive levels for the pins.
 
Tinker Board sets the equivalent RK3288 pins to 8 mA: https://github.com/torvalds/linux/blob/master/arch/arm/boot/dts/rk3288-tinker.dts#L429
 
It would stand to reason you could do the same with RK3328: https://github.com/torvalds/linux/blob/master/arch/arm64/boot/dts/rockchip/rk3328.dtsi#L979
 
 

On the RK3288 boards, if I am remembering correctly, the drive level is modified in the dts to avoid this issue.  Is that possible with the RK3328 at least?  I think the mmc IP is the same, but don't quote me on that.
 
[edit] 
https://github.com/torvalds/linux/blob/master/arch/arm64/boot/dts/rockchip/rk3328.dtsi#L1432
 
This part of the dtsi shows the default 4 mA drive levels for the pins.
 
Tinker Board sets the equivalent RK3288 pins to 8 mA: https://github.com/torvalds/linux/blob/master/arch/arm/boot/dts/rk3288-tinker.dts#L429
 
It would stand to reason you could do the same with RK3328: https://github.com/torvalds/linux/blob/master/arch/arm64/boot/dts/rockchip/rk3328.dtsi#L979
 
 

I concur, and I have a feeling the editable nature of the wiki may be... impermanent, let's say.

It seems disabling SDR104 is enough

@martinayotte @hjc Successfully merged. https://github.com/armbian/build/commit/6d82a8974872ee261006d2cdf6726b7d13df5032

@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.

**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. 
 

**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. 
 

**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. 
 

**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. 
 

Hi~
 
About how we suggest to prevent the voltage drop.
Not much but can reference,
5V and full power as the spec. (e.g. some supply said 5v/2a (10W), but actually, when you asked v2a, you would see it may only provide 4.8v/2a) We would suggest using 3A (15W) to prepare for the high loadings. The cable with 20~18 AWG for large current power usage. We also provide the best and official choice, the Tinker Power Supply.
 
And you can check what is the current voltage in the system.
 
Take a look with this node, "/sys/bus/iio/devices/iio:device0/in_voltage2_raw".
If it had been there and assumed the function was normal. You can refer below sample code (python) to get voltage.
DETECT_VOLTAGE = 4.65 #4.65 ADC_IN2_RAW_PATH = '/sys/bus/iio/devices/iio:device0/in_voltage2_raw' with open(ADC_IN2_RAW_PATH) as in_voltage2_raw: val2_raw = int(in_voltage2_raw.readline()) val_input = float(val2_raw / ((82.0/302.0) * 1023.0 / 1.8)) + 0.1 print('Voltage: ' + str(val_input)) if val_input < DETECT_VOLTAGE: print('-- Low Voltage --') print('The system may turn off due to low power input (input voltage below 4.65V), when this happens, please disconnect high power consuming peripherals or change to a qualified power supply.') // In TinkerOS, you can find a service at "lib/systemd/system/voltage-detect.service" and similar codes "etc/init.d/voltage-detect.py".
 
Thanks.

That's the question we're working on.  I think we can handle all from one codebase, at least as long as there aren't too many Tinker Reboot workarounds on other boards (I have that "contained" so it doesn't break anything)
 
From kernel to kernel the MAli drivers need tweaking, and while @Myy does excellent work with this, I thought it easier to keep Next on an an LTS kernel, then if people want bleeding edge they can compile a Dev image.
 
Also, welcome back!

That's the question we're working on.  I think we can handle all from one codebase, at least as long as there aren't too many Tinker Reboot workarounds on other boards (I have that "contained" so it doesn't break anything)
 
From kernel to kernel the MAli drivers need tweaking, and while @Myy does excellent work with this, I thought it easier to keep Next on an an LTS kernel, then if people want bleeding edge they can compile a Dev image.
 
Also, welcome back!

I answered on my phone earlier, thread with benchmark: 
 

I am going to call the K2 I have a "close enough" to C2 board (both are Amlogic gxb dev boards in Pi form factor).
 
I would say that today, right this second that the switch would not be a great one in the case of either board.  That said, I only support/work with mainline kernels, and an RFC patchset has just been submitted for review to enable the video decoder hardware.  With that and the Mali driver you'd have a superior solution to the RPi in either case, hands down.  
 
As to the board vs board situation:
 
Le potato is lacking GbE, wifi.  It is, however, not incredibly expensive and has quite impressive memory performance compared to the C2. (Benchmarking thread has details).  That will be important for 4k video.
 
The C2 is the only Amlogic based device on the market that does not lie about it's current clock speed.  This has to do with some ugly history and past claims of "2.0 GHz" operation.  There is a whole thread here somewhere talking about clockspeed cheating.  As an HTPC that's not as important, and RPi is guilty of it as well, if not even worse depending on the board.
 
With the hardware support in mainline maturing so quickly, I'd guess the Amlogic devices will be a good bet for that use case very soon.  If you want wifi and GbE you'll want a C2/K2, if you want faster memory for potentially smoother playback go Le Potato.
 

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