Apart from the specs, it’s worth noting the Tinker Board S retails for $85.
More than 2x the latest Pi. Nearly 3x.
That depends on your country and retailer.
For me, the Tinker board plus shipping cost 1.3 times the price of a Pi plus shipping
Rose tinted glasses are difficult to see through.
Rose tinted glasses are difficult to see through.
DavidS wrote: ↑Tue Dec 11, 2018 1:53 amWhere does the extra RAM help when you are using less than 128MB maximum?
Where is a good reference on programming the tinkerboards GPU?
How do you boot RISC OS on the tinkerboard?
These are questions that when answered may make the tinkerboard worth half a look as a desktop computer.
who really needs RISC OS as desktop replacement? The way to go for the tinker is clearly linux and nothing else cause all the development happens for Linux (e.g. hardware acceleration, GPU etc.). If you count android as linux as well... I never booted android on any of my SBCs even when they're capable of booting it, I don't see a reason to use android.
In case 128MB ram is all you need, the tinker might be an overkill (if we talk about desktop, I'm quite confident that 128MB will not be enough - not my field and I'm barley interested in desktop).
Tinkers RK3288 SoC is a rather outdated one.. The CPU cores are old (but fast), interfaces are similar slow and 'not that exciting' as the RPi (except proper GbE ) and the overall support is good (from kernel-side). Hardware accelerated video decoding seems to work even with 4k and from what I heard Kodi and all these TV-box stuff seems to work. Hardware accelerated videodecoding in browser (e.g. chromium/firefox) may be problematic.
If you're more interested in a 64bit system with a powerful SoC I would go for one of the new RK3399 based ones... big.LITTLE (2x A72 4x A53), USB 3.0, PCIe 4x, and when the right PMIC is used USB-C PD compatible (check which board you buy, not all of them follow the PD standard!). From kernel-side the SoC is well supported, user-space stuff is on a good way.
to have fun with Kodi you need two things working (out of the RPi world). You need mali drivers for the interface and hardware accelerated video decoding (in arm world video decoding doesn't happen on the GPU, it happens on the VPU). Linux mali drivers are available for RockChip SoCs, VPU drivers too, but this stuff isn't always fully working on the images *joe random* provides. I've no idea if tinkerOS delivers mali-drivers and VPU-drivers cause I never used the tinkerOS. On my favorite distribution, there's a script taking care that the drivers can be installed if someone wants it. But by default mali and VPU drivers in userspace aren't delivered (yet). Depending on your needs you might need different mali userspace drivers, we let the user decide which one he wants.
The Kernel doesn't matter, but for sure, the tinker and raspbian doesn't share the same kernel. RockChip provides a 4.4 out of tree kernel and send patches to mainline so that the SoC is also supported in mainline kernel. Raspbian is based on a 4.x (do you guys switched to 4.19 or still at 4.14?) kernel which is also out of tree. On user-space both are based on debians armhf packages, but this hasn't much to do with the kernel. Due to 64bit architecture of the newer RPis it would be possible to run those on a 64bit ARM64 debian but this would break backward compatibility with older RPis.. means you've to provide more than one Raspian depending on which RPi you use. Something the RPi guys and girls avoid (probably to avoid the support nightmare - people will download the wrong one and then complain that it doesn't work)... The tinker is a 32bit only board.
Providing a "raspian" for random board isn't as hard. Download a RPi image, throw out the kernel and replace it by yours and glue it together with an u-boot which is able to boot on your board and you're done. But it doesn't make sense. Raspbian is adjusted for RPis you won't have 'the RPi experience' cause you have a raspian rootfs. The proper way here is to debootstrap https://wiki.debian.org/Debootstrap a debian or ubuntu (either with armhf or arm64 packages depending on your board) and glue it then together with proper kernel and u-boot for your board (currently arm on debian needs often/everytime? a custom kernel to support those boards properly). Such a properly crafted image will give you a much better experience than a raspian rootfs glued with an other kernel and u-boot (it's also a bit more work to do.. ).
Out of RPi world, you might neet to be a bit more experienced to get everything properly working, but once it's there you get some interesting boards which may fit better for your use-case than the RPi. If you're not willing to do this extra work and/or proper research which SBC fits best for your needs chances are high that you buy the wrong one. The RPi may then be the better board for you. But for my needs (all headless, NAS/Network/IoT) there are a bunch of boards which fit a way better than the RPi would, cause they're more powerful (NAS with real GbE and attached storage which is able to saturate GbE) or cheaper (IoT nodes) with less power consumption.
Doesn't mean the RPi is bad - it just doesn't fit well for my use-cases. But it's often a bit more work to get what you want... on the other hand, currently all my SBCs run with a (slightly patched) 4.19 mainline kernel since weeks. It all depends on the time you're willing to invest and the experience (it's not as hard as you assume in the beginnings and it doesn't need that long to get familiar with it)...