8 ms·

ASUS Tinker Board’s Debian and Kodi Linux Images, Schematics and Documentation

73 points by tagrun 10y ago

general_ai 10y ago
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 10y ago
  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 10y ago
    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).
- digikata 10y ago
  I would caveat that to add if you're planning on running linux, 64-bit in the upscale ARM chips makes a lot more sense. But if you're running in the 'deeply' embedded space, there are plenty of 32bit ARMs (without MMUs) in the -M/-R family that are used for developing bare metal or RTOS that will be around for a long time and the experience will carry forward just fine.
Quequau 10y ago
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.
- 2bluesc 10y ago
  I'd love to know of SoC vendor that does. Intel and Wolfson are the only chip vendor that delivers above and beyond for Linux drivers that come to mind. Everything else is hack city in proprietary kernel forks that never see the light of mainline.
  - stass 10y ago
    Drivers != Linux drivers. Also, TI and Freescale are both good with providing official driver source code of decent quality. Even Broadcom contributed a lot of drivers upstream.
    - digi_owl 10y ago
      Heads up, Freescale is part of NXP Semiconductors now.
      - rjsw 10y ago
        And soon to be part of Qualcomm.
    - 2bluesc 10y ago
      > Drivers != Linux drivers. Can you elaborate on this? In theory they should be equal and the less userspace supporting tools for hardware the better. I guess I don't count userspace "drivers" as real drivers. Almost every time I've seen them they are epic hacks. Other times they are evading the GPL. > Also, TI and Freescale are both good with providing official driver source code of decent quality. Even Broadcom contributed a lot of drivers upstream. Come on now. I've worked on integrating Qualcomm, TI and Broadcom SoCs in to products. TI does quite a bit better then most, but I'd love to understand why an old chip that's built in to tons of industrial products like the AM3359 still has a kernel fork for it's advance features like the PRUSS. I worked on a project I first built 6 years ago on that platform and was appalled that they still hadn't managed to mainline the code. I haven't used the iMX directly, but I get the impression Freescale/NXP is similar to TI: drivers and datasheets are available, but the corporate will to merge to mainline isn't. I hope Qualcomm doesn't crush this. Is there any good reason my 2016 Google Pixel smartphone is running kernel 3.18? Ask Qualcomm. Broadcom, you have got to be kidding me? The Raspberry PI is treated as a continuous PR vehicle, no real reference manuals or proper datasheets to speak of for the public. Not to mention their "support" for their WiFi and Bluetooth drivers requires ripping up Windows drivers to extract firmware updates to try and make them half work on Linux.
krylon 10y ago
Honest question: Can somebody explain to me why I would want to get this instead of a Raspberry Pi or a Beagle Bone?
- vegabook 10y ago
  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 10y ago
    it is still pretty hard to find ARM with USB3 these days for DIY
    - shoonmcgregor 10y ago
      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.
      - deleted 10y ago
        [deleted]
      - ausjke 10y ago
        I just use celeron boards (mini-itx) that has everything I need and is still low-power
      - deleted 10y ago
        [deleted]
        shoonmcgregor 10y ago
        I just posted an Ask HN about it. I'm going to produce the boards as part of the Make/100 kickstarter project https://news.ycombinator.com/item?id=13500403 https://news.ycombinator.com/item?id=13500403
tashbarg 10y ago
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 10y ago
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=TInker%20Board/2GB&SLanguage=en-ene&os=8 http://stw.asus.com/download/download.aspx?product=1&model=T...
throw2016 10y ago
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 10y ago
  How do they get around the GPL license?
westmeal 10y ago
That is an interesting little board. May have to wait and see for actual docs.
cordite 10y ago
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.
JustSomeNobody 10y ago
This looks interesting, but I'd rather have a pi with Gigabit Ethernet.

73 points by tagrun 10y ago

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 10y ago
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 10y ago
  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).
digikata 10y ago
I would caveat that to add if you're planning on running linux, 64-bit in the upscale ARM chips makes a lot more sense. But if you're running in the 'deeply' embedded space, there are plenty of 32bit ARMs (without MMUs) in the -M/-R family that are used for developing bare metal or RTOS that will be around for a long time and the experience will carry forward just fine.

Quequau 10y ago

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.

2bluesc 10y ago
I'd love to know of SoC vendor that does. Intel and Wolfson are the only chip vendor that delivers above and beyond for Linux drivers that come to mind. Everything else is hack city in proprietary kernel forks that never see the light of mainline.
- stass 10y ago
  Drivers != Linux drivers. Also, TI and Freescale are both good with providing official driver source code of decent quality. Even Broadcom contributed a lot of drivers upstream.
  - digi_owl 10y ago
    Heads up, Freescale is part of NXP Semiconductors now.
    - rjsw 10y ago
      And soon to be part of Qualcomm.
  - 2bluesc 10y ago
    > Drivers != Linux drivers. Can you elaborate on this? In theory they should be equal and the less userspace supporting tools for hardware the better. I guess I don't count userspace "drivers" as real drivers. Almost every time I've seen them they are epic hacks. Other times they are evading the GPL. > Also, TI and Freescale are both good with providing official driver source code of decent quality. Even Broadcom contributed a lot of drivers upstream. Come on now. I've worked on integrating Qualcomm, TI and Broadcom SoCs in to products. TI does quite a bit better then most, but I'd love to understand why an old chip that's built in to tons of industrial products like the AM3359 still has a kernel fork for it's advance features like the PRUSS. I worked on a project I first built 6 years ago on that platform and was appalled that they still hadn't managed to mainline the code. I haven't used the iMX directly, but I get the impression Freescale/NXP is similar to TI: drivers and datasheets are available, but the corporate will to merge to mainline isn't. I hope Qualcomm doesn't crush this. Is there any good reason my 2016 Google Pixel smartphone is running kernel 3.18? Ask Qualcomm. Broadcom, you have got to be kidding me? The Raspberry PI is treated as a continuous PR vehicle, no real reference manuals or proper datasheets to speak of for the public. Not to mention their "support" for their WiFi and Bluetooth drivers requires ripping up Windows drivers to extract firmware updates to try and make them half work on Linux.

krylon 10y ago

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

vegabook 10y ago
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 10y ago
  it is still pretty hard to find ARM with USB3 these days for DIY
  - shoonmcgregor 10y ago
    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.
    - deleted 10y ago
      [deleted]
    - ausjke 10y ago
      I just use celeron boards (mini-itx) that has everything I need and is still low-power
    - deleted 10y ago
      [deleted]
      - shoonmcgregor 10y ago
        I just posted an Ask HN about it. I'm going to produce the boards as part of the Make/100 kickstarter project https://news.ycombinator.com/item?id=13500403 https://news.ycombinator.com/item?id=13500403

tashbarg 10y ago

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 10y ago

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=TInker%20Board/2GB&SLanguage=en-ene&os=8 http://stw.asus.com/download/download.aspx?product=1&model=T...

throw2016 10y ago

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 10y ago
How do they get around the GPL license?

westmeal 10y ago

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

cordite 10y ago

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.

JustSomeNobody 10y ago

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