Chromebooks were originally all based on Intel processor, but eventually ARM based Chromebooks got launched starting with Samsung Exynos, more recently Rockchip RK3288, and soon we’ll have Mediatek Chromebooks based on their latest Cortex A72 + A53 processor.
The platform is still in development, but some prototypes are being shown up at Computex 2015 in Taipei. The full specs are not available but we do know the laptop features MT8173 SoC with 2x Cortex A72 cores, 2x Cortex A53 cores, and a PowerVR GX6250 GPU. NotebookItalia is at Computex and in their short video below with can hear the spokesman claiming support for 4K video playback, 2K display, and the presence of Type C USB port that can be used to connect device, but also charging the laptop.
Mediatek Chromebooks should offer about twice the single thread performance as Rockchip RK3288 devices, thanks to the use Cortex A72 cores instead of Cortex A17 and a higher clock frequency (up to 2.4 GHz vs up to 1.8 GHz).
No word on pricing and availability so far.
Via Liliputing
Jean-Luc started CNX Software in 2010 as a part-time endeavor, before quitting his job as a software engineering manager, and starting to write daily news, and reviews full time later in 2011.
Support CNX Software! Donate via cryptocurrencies, become a Patron on Patreon, or purchase goods on Amazon or Aliexpress
Not a big fan of Chromebooks even though I do understand they have their target ( I’m not it ). I do see them as Linux laptops though and it’s one way of avoiding to pay MS anything.
ARM Chromebooks I just don’t like because they’re not easy to do a clean Linux install … GPU drivers are usually a no go and so is mainline kernel support sometimes….
Given that for a few $ more you can get an Intel CPU with excellent open source support thanks but no thanks.
@Marius Cirsta
I disagree, the market needs competition like this. Yes you are right about installing different distros, ARM are way behind when it comes to open source GPU drivers, but Intel would not be giving Bay trails away so cheaply if ARM were not snapping at their heels. Intel hates to see ARM in notebooks just as much as Microsoft hates to see chrome os in notebooks, worth buying one for that reason alone.
No screen size?
No benchmark? I like the Octange Benchmark to check a system’s performace easily: http://octane-benchmark.googlecode.com/svn/latest/index.html
@GMR 73
Oh I didn’t say this was bad, Intel needs competition for sure. I was just saying I’m not interested in this but I also realize I’m just a small minority, the majority of users will just use it as Chromebook and for them it’s just fine.
In fact with A72 it might even perform bettern than some Intel CPUs, let’s see. It’s a shame though that ARM is such a mess, closed source GPU crap, custom kernels and all that. The kernel situation is improving a bit though.
@Marius Cirsta
While I tend to agree that installation is a tad more difficult than running a distro-installer, it is nevertheless also not really hard to bootstrap a clean installation. There exist howtos for at least Debian and Arch – see bottom of [0] – and the process is similar for all ARM Chromebooks.
And as for mainline Linux kernels, when I look at my branch [1] for the RK3288 Chromebooks, the diff to mainline is quite small – the edp driver that is still worked on and the embedded controller [that will hopefully still make it to 4.2] are the biggest chunks apart from the Mali kernel part. Otherwise it’s really only tiny stuff and I even get accelerated WebGL on Debian without much hassle 🙂 .
[0] https://plus.google.com/u/0/+HeikoSt%C3%BCbner_x/posts/YxtKFJaGiv6
[1] https://github.com/mmind/linux-rockchip/tree/devel/somewhat-stable
It’s good to know things have progressed quite nicely where mainline kernel support is concerned but I’m still afraid of the GPU part. It might work now but what about in a 1-2 years’s time … I’d rather have something that’s in supported by mainline MESA and where installing any distro is easy peasy as it is on any x86 Intel SOC …
Besides for RK3288 we’re talking about MALI, from what I know the PowerVR situation is worse so no thanks from me I’m sticking with Intel till ARM gives up on their closed source MALI crap.
I was a big ARM till quite recently but I’ve become quite dissapointed by how things are going … I want things to just work for ARM like they do for x86 and we’re not quite there yet in many cases. Maybe ACPI for ARM will solve this but there’s still the GPU mess …
And yes I know about DT and all that, that’s another solution that could work I suppose but somehow ACPI seems easier even if it does have some problems itself.
@MMind
> “While I tend to agree that installation is a tad more difficult than running a distro-installer, it is nevertheless also not really hard to bootstrap a clean installation”
Think about it in 5 or 10 years, when you’ll want to re-install from scratch a machine without having any access to the proper DT (that will be lost in the limbs of the internet), and without having a proper kernel for that exact board you’re using, etc.
In comparison, I can still use my 15 years-old x86 PCs with up-to-date current Linux distributions…
@ade
Exactly my point and even with the right DT ( which is a big step forward compared to custom kernels anyway ) there’s just no guarantee everything will still work whereas you usually have no problem even with 10-15 year old x86 hardware so yeah that’s my problem with ARM stuff and I do hope they fix their s…. stuff
I’m planning on having the basic Veyron (RK3288) DT files in 4.3 🙂 . Although the internal display (the eDP controller) might take a bit longer, as there are still people working on the driver.
DT? I had to Google that … Device Tree, right? If so “A Device Tree (DT) is a description of the hardware in a system.”.
Wikipedia says “For ARM, use of device trees has become mandatory for all new SoCs. This can be seen as a remedy to the vast number of forks (of Linux and Das U-boot) that has historically been created to support (marginally) different ARM boards. Allegedly, the purpose is to move a significant part of the hardware description out of the kernel binary, and into the compiled device tree blob, which is handed to the kernel by the boot loader, replacing a range of board-specific C source files and compile-time options in the kernel.”
Interesting.
@Sander
Yes, that’s one (big) difference between x86 systems and other (MIPS, ARM) embedded systems : the x86 has some kind of introspection/abstraction (BIOS/ACPI/EFI) that allows it to boot “one kernel to rule them all” (said differently: the equivalent of the DT is already embedded within your BIOS. If you look at Coreboot source, you’ll see that each supported motherboard has a corresponding devicetree.cb file. When you just deal with Linux/kernel, all this complexity is hidden to you as a user). Embedded systems has nothing like that to introspect themselves, and this is why each board needs either a custom kernel that will describe the machine (this used to be done using “board files”, this is why you can’t just go to kernel.org and expect to compile and boot a kernel for your preferred tablet or smartphone) or another external way to describe the HW (the DT blob or DTB), that is passed to the kernel by the bootloader. You may find the .dts (source files for DT) for many boards in arch/arm/boot/dts in Linux kernel sources (same for arch/powerpc/boot/dts/ for PPC boards, since DT initially comes from the PPC world). It is questionable whether this is really the right place to put them, yet at least having the .dts in Linux kernel sources ensures those .dts some kind of long-term support.
My video of it is up: http://armdevices.net/2015/06/04/chromebook-on-arm-cortex-a72-mediatek-mt8173-big-little/
@ade
Thank you for your explanation!
Does this mean that you can have one (install) image containing different DT’s/DT-blobs that can run on any ARMv7 board, as long as the DT for that ARMv7 board is in the image?
So one image that you can install both on – for example – on Raspi2 and Cubox?
Unfortunately they seem to insist on keeping their crippled keyboard and touchpad that makes them hardly usable as a regular computer :-/