TonyMac32

Here is mine:
 

@jpegxguy  For the mainline ethernet tx/rx delays, were those just copied from the Rock64 or were they empirically determined?  They're caused by trace impedance/etc, so they're tied to the specific hardware.  I'll dig up the thread/tool Ayufan and Tkaiser were using and see what I get, there might be some more to gain there, since obviously the default ones are fairly bad.
 
@Igor Any argument against moving Ayufan's RK3328 mainline to "next" and putting true mainline at "dev"?  I think it's to the point that 5.1/5.2 are nearly to RK3288 levels of support in mainline.
 
[edit]  Fixed the lower USB port on Renegade.

Another Tinker "case", this time one geared toward the developer who needs to access pins/jumpers: http://electricgraveyard.com/index.php/2019/03/07/asus-tinker-open-case-diy-kit/
 
Instead of flooding the forum with 100000 pictures, leave it over there.   The TL;DR is that it has a much nicer cooler included than the board gets initially, and the base itself is a nice stamping.

Potentially a WIP/csc until Armbian in general properly supports rk3399.  This isn't so much a libre computer issue as it is a u-boot/kernel issue, all Rockchip boards with high-spec ram have been a challenge to support because the Rockchip binary blobs aren't so great sometimes.  I have this board, I can test any PR's in the meantime while I clean up some other stuff

Here with round shapes. There's a black part on the feet that need to be colored. With the rounded one the eyes should be a little bit smaller.
I also like it. Tomorrow I'll also try to make a sky background.

@suberimakuri:
 
____ _ | _ \ ___ _ __ ___ __ _ __ _ __| | ___ | |_) / _ \ '_ \ / _ \/ _` |/ _` |/ _` |/ _ \ | _ < __/ | | | __/ (_| | (_| | (_| | __/ |_| \_\___|_| |_|\___|\__, |\__,_|\__,_|\___| |___/ Welcome to ARMBIAN 5.76 user-built Ubuntu 18.04.2 LTS 4.20.13-rockchip64 System load: 0.02 0.17 0.11 Up time: 8 min Memory usage: 14 % of 1998MB IP: 10.0.0.47 CPU temp: 48°C Usage of /: 12% of 15G [ General system configuration (beta): armbian-config ] So that works, although missing a USB port (bottom USB2 is not with us).

I almost think you should maintain some hard angularity to it, as the 2D.  Very nice though!

Success, Used the dts from here rk3399-roc-pc.dts and merged some of the kernel config from here firefly_linux_defconfig and presto! I have a booting Armbian image for the Renegade Elite 
 
 

@NicoD - Nice concept...
 
Put some muscles on the penguin - big ARM's for Armbian...

@lanefu will help around admin duties.

I have one in the mail, was told the Armbian H64 image works except for Ethernet, I'm guessing there's a small hardware difference that needs reflected in DTS.  Or I'm completely wrong, until I can see, I cannot know.

Haha. I still need to do that thermal comparison between factory, my Frankenstein above, and the nice case they sent me. It is far superior to the factory cooler, although it would still throttle in your situation.

Sent from my Pixel using Tapatalk

Yeah... well.. went without it, with just a passive cooler while powered through a USB charger. #SoRebel #MuchRockchip

That's the only reasonable way to do something stressful with an RK3288.  I'd add GPIO powering on top of that to be sure, since it not thermal throttling presents challenges for everything else in the system that might not have anticipated pulling 15 Watts for over an hour.

Hy
I answer myself :)
 
I have found what's going wrong.
 
tinkerboard register the interfaces in this files /etc/udev/rules.d/70-persistent-net.rule
When the eth0 is already used, the next mac adress takes eth1.
 
So the solution: delete this files /etc/udev/rules.d/70-persistent-net.rule

So I built some fresh Armbian images with dev kernels, and setup ubuntu mate and ran them on my tritium h5, and my le potato... and like I've got slack running in chromium n stuff, and desktop switching is pretty decent... and that's without acceleration.. just good 'ole brute force.
 
Basically my mind is blown that its usable and I'm going to retire my c2d dell desktop that's on my KVM and finally use an ARM SBC as a desktop!
 
 

the USB-C at the rear with the Ethernet port is the power-in, not hard to do backwards.
 
 

350 had plenty of problems, it's biggest strength was how cheap it was. The Mopar 318/340/360 was/is a far better engine series.
@Tido@chwe next time say $6. :-P

The thing I see with the V3s is the fact that it appears to be in the same price arena as the H3, and without full vdec/venc/camera support it doesn't have a single benefit over the H3 or a decent micro (esp32, etc)

Sent from my Pixel using Tapatalk

He also hung a lantern on it, so to speak:. "silly kitchen sink benchmarking". He's illustrating how numbers can be used to selectively represent reality.

Sent from my Pixel using Tapatalk

Indeed.  Had failure of idiotic plastic thermostat housing (replaced with Aluminum), then the timing chains flew out the side and bent a bunch of valves at 117k (miles).  The shortest lived engine I've ever had in an American car (I had a Stratus, but I may have crashed it)
 
To be fair to Cologne, the pushrod version of the engine was far better, but the weird fetish with overhead cams was it's undoing.  I'm swapping in a 5.0L V8 from an Explorer, since they were the same vehicle from the drivers seat forward it will be extremely easy, the donor vehicle with the engine in it costs about as much as a new head for that V6...  I agree the LS is solid, but the GM people are too insufferable, I can't do that to the Ford.  If a Dodge 318 fit in there, I'd gladly do that, the community would give me a high five for something different...

I can't help but think this will be a cyclical issue for that community then, he is far too sentimental (tunnel vision perhaps), and the platform is far too closed hardware wise.  Typical market forces will render them noncompetitive over and over as they cling to the familiar.
 
As always, the "open source platform" would be on a non-distributor SoC with a most likely closed source VC5, with all the typical paywalls up to be "permitted" to use the HEVC/etc.  Since Eben was willing to hide his camera tuning behind DRM on the VC4 devices, I can only imagine the uses for the improved security core... 
 
Again, not a problem, except they sit their in their tiny little hardware sandcastle with the tide coming in and claim to build unquestionably superior supercomputers.
 
 
I was a lot less sarcastic on this topic before I started reading their forums and seeing the excuses they give for basic lacking functionality, the technical 1/4 truths, some outright deception, hiding behind "millions sold" numbers instead of engaging technical questions...  The GbE one was too much, their assertion was that achieving 30% Gb throughput was irrelevant since it was attached to the network at GbE bit rates.  That's like me putting 300 kph rated tires on a Lada Riva and claiming to compete with Ferrari because the physical contact between the car and the street was capable of high speed operation...  (to be fair, the Lada may be more reliable than a Ferrari...  )

@Myy The patches I have in my rockchip-5.x-vpu branch is on top of v5.0-rc6 + mmind/for-next and not a rockchip tree.
 
All vpu related patches needed on top of v5.0-rc6: https://github.com/Kwiboo/linux-rockchip/compare/v5.0-rc6...rockchip-5.x-vpu (patch)
List of mmind/for-next patches rebased on v5.0-rc6: https://github.com/Kwiboo/linux-rockchip/compare/v5.0-rc6...rockchip-5.x (patch)
VPU related patches on top of mmind/for-next: https://github.com/Kwiboo/linux-rockchip/compare/rockchip-5.x...rockchip-5.x-vpu (patch)
 
I have started to send some of my patches to linux mailing list and more will follow.

Yes. Best wishes from my side as well.

Sent from my Pixel using Tapatalk

Take good care of him. More important than an sbc. Greetings.

Since the last round of Moronix madness didn't include a single RK3399 device I decided to give two rounds of silly kitchen-sink benchmarking a try using the 'reputable' Phoronix Test Suite:
 
https://www.cnx-software.com/2019/02/13/odroid-n2-amlogic-s922x-sbc/#comment-560987
 
For those thinking the N2 results would be better when running bare metal... I doubt it since of course I checked with sbc-bench first:
here's running sbc-bench on 'ODROID Bench' inside a container: http://ix.io/1BEM and there's the results Dongjin (@tobetter) shared with me few days ago (look at the timestamp, Hardkernel tested already weeks ago so they were pretty clear about which benchmark results to publish and which not): http://ix.io/1BsF The ODROID-N1 numbers are representative for each and every RK3399 device out there running at 2.0/1.5GHz with CONFIG_HZ=250. Scores might improve once Rockchip provides new DRAM initialization BLOBs especially on those boards using LPDDR4.