
ASUS Tinker Board’s Debian and Kodi Linux Images, Schematics and Documentation - tagrun
http://www.cnx-software.com/2017/01/24/asus-tinker-boards-debian-kodi-linux-images-schematics-and-documentation/
======
general_ai
IMO it's a mistake to develop a board that's not capable of running 64 bit ARM
code these days. While you might not need the address space capabilities,
aarch64 standardizes a lot of things that would otherwise bite you in the ass
if you develop software that needs to run on several flavors of ARM. I.e. all
64 bit ARMs have NEON and hard float. And not just any NEON, but NEON specific
to 64 bit ARM, with newer instructions. You get a _very_ nice lowest common
denominator to code against. Nicer, in some regards, than Intel. This is
especially egregious considering that Raspberry Pi 3 _does_ have 64 bit chip,
even though they run it in 32 bit mode. I guess what you're really buying in
this case is a hardware 4K video decoder.

~~~
deaddodo
As someone who has done some osdev on the ARM, this is true to a degree.

It's similar to ia32 vs amd64. From amd64, you can ensure that SSE exists and
guarantee that certain legacy features don't need to be coded around. Plus
additional GP registers are always nice and you know they're there (despite
usually leaving that to a compiler to manage).

With aarch64, you can ensure that VFP3+ and NEON both exist for FPU
capabilities and choose between them at your behest (FP accuracy vs speed).
You also get a few cryptographic features (AES, a couple SHA's and finite
field arithmetic). However, with x86 you're able to use the CPUs (more or
less) with feature flags since you can test for features in real-time. ARM
doesn't offer this to near the degree (since there is no BIOS/UEFI in most
boards), so you either code/compile directly for a certain CPU and it's
features or use something like U-Boot/Linux's device tree spec files to hint
at a boards feature set. You also have different entry points, clock speeds,
memory maps, etc. This is why you see most Linux/FreeBSD/Android releases
released per-board vs generic installers like with x86.

~~~
general_ai
Yes, my interest is basically at a level slightly above the OS, not bare metal
embedded or OS development per se. And the OS (at least Linux) will tell you
which features a given CPU supports. It's just that the variety on the 32-bit
side is so enormous, it's hard to be sure of anything. I.e. your particular
chip might not even have hardware FP. With aarch64 even the lowest common
denominator is better than just about any arm32 (modulo the specialized extra
hardware the particular chip might have).

------
Quequau
Rockchip has reputation for not following through with drivers for their ARM
SoCs. I wonder if this will suffer the same fate or if perhaps ASUS will pick
up the ball.

~~~
steeve
I've done some kernel and Linux on Amlogic and Rockchip. This is the number
one issue to me. For instance the ODROID C2 with non standard Linux kernel
3.14....

Even on Android you're stuck with old kernels and versions because SoC
providers only ship binary blobs for old kernels (and sometimes old forked
kernels)

~~~
sjuut
ODROID C2 has a quite OK mainline-kernel booting, check out the linux-
meson.org project. Or latest build status: [https://kernelci.org/boot/meson-
gxbb-odroidc2/](https://kernelci.org/boot/meson-gxbb-odroidc2/)

------
throw2016
Nearly all the dev boards with the exception on the Pi are on old kernels. A
lot of things especially gpu related don't work well. Even the Pi was booting
with a gpu blob untill a few months ago.

All these SOCs including the Rockchip 3288 and the newer 3399 work perfectly
on Android and Chrome seen in the Asus Flipbooks and the Samsung Chromebook
Pros. So perfectly good drivers that work on Linux exist. Yet something goes
missing between the cup and the sip. This is just selective self serving use
of open source by Google and ARM.

OEMs cannot release drivers unless ARM and other hardware manufacturers let
them, its like expecting Asus and MSI to release Intel or Nvidia drivers for
Linux without Intel and Nvidia's support. Google has huge influnce in this
ecosystem and can play a role in moving things along but they would rather
these devices just work on Android and Chrome.

~~~
FnuGk
How do they get around the GPL license?

------
cordite
I got burned with kodi on an arm unit, the ODROID (C1 or C2, don't remember
which) was capable of playing many things with the hardware decoder. But it
would fall short on anything other than basic MP4 and MPEG. The ODROID was far
more capable than the bananapi, raspberry pi, and other ARM units with HDMI
out.

------
krylon
Honest question: Can somebody explain to me why I would want to get this
instead of a Raspberry Pi or a Beagle Bone?

~~~
vegabook
Double the ram, twice as fast, gigabit ethernet. 4k. Still usb 2.0 though.
Much riskier on OS and software support/community though. If starting out I
would go Rpi. But this is defo a very well specced little board.

~~~
ausjke
it is still pretty hard to find ARM with USB3 these days for DIY

~~~
shoonmcgregor
I had the same issue (no ARM+USB3+gigabit boards) so I had to build a board
that had all of that plus mSata and minipcie.

~~~
ausjke
I just use celeron boards (mini-itx) that has everything I need and is still
low-power

------
tashbarg
ASUS has horrible Linux support on laptops based on SoC (even when the same
SoC is used in their Android products). Why should this be different?

------
heine
The Asus Page linked in the Article [1] now gives a 404. Maybe even this
hidden release was not intended?

[1]
[http://stw.asus.com/download/download.aspx?product=1&model=T...](http://stw.asus.com/download/download.aspx?product=1&model=TInker%20Board/2GB&SLanguage=en-
ene&os=8)

------
westmeal
That is an interesting little board. May have to wait and see for actual docs.

------
JustSomeNobody
This looks interesting, but I'd rather have a pi with Gigabit Ethernet.

