ASUS Tinker Board’s Debian and Kodi Linux Images, Schematics and Documentation
1–10 of 37 posts
Re: ASUS Tinker Board’s Debian and Kodi Linux Images, Schematics and Documentation
#2Re: ASUS Tinker Board’s Debian and Kodi Linux Images, Schematics and Documentation
#3Re: ASUS Tinker Board’s Debian and Kodi Linux Images, Schematics and Documentation
#4Rockchip 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.
Everything else is hack city in proprietary kernel forks that never see the light of mainline.
Re: ASUS Tinker Board’s Debian and Kodi Linux Images, Schematics and Documentation
#5Rockchip 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.
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.
Also, TI and Freescale are both good with providing official driver source code of decent quality. Even Broadcom contributed a lot of drivers upstream.
Re: ASUS Tinker Board’s Debian and Kodi Linux Images, Schematics and Documentation
#6IMO 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 instru…
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.
Re: ASUS Tinker Board’s Debian and Kodi Linux Images, Schematics and Documentation
#7IMO 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 instru…
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 cap…
Re: ASUS Tinker Board’s Debian and Kodi Linux Images, Schematics and Documentation
#8Rockchip 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.
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)