I'm not sure if this has been asked before, but I really need to double-check this - what's the status of 64-bit UEFI support on Bay Trail architecture? I understand that the build of Android on Bay Trail tablets uses a 64-bit Linux kernel, does it also use a 64-bit EFI bootloader?
Many thanks for helping to clarify this query!
Hi Casey, hi Lynn,
Thank you so much for the answer! My company wishes to sell consumer tablets preinstalled with Fedora Linux, and from what we've seen so far, Bay Trail chips are extremely powerful for its price but only supported 32-bit UEFI on Windows tablets, so this was a major concern for us.
Much appreciated for your help!
I wish you luck on your project. Another engineer confirmed that Android on Bay Trail supports both 64-bit Linux kernel and 64-bit EFI boot loader since BIOS version 80.21. Hope to talk with you again sometime in the Embedded Community!!
Hi, Hugh Tay! I am glad to hear that you have been connected with Intel and our partners. I'm sure that they will assist you as much as possible.
FWIW I've got Inari 8 with 64-bit firmware which does boot (that's how we get down to another set of peripheral driver problems so far).
Thanks for introducing the Inari 8 tablet. We've also managed to obtain a tablet with 64-bit firmware from another ODM, but we've also gotten down to another set of driver problems as well. =)
Actually we thought it might have been common across Bay Trail devices, (discussion @ /message/10098# 10098 https://embedded.communities.intel.com/message/10098# 10098) but it seems unique only to the model that we have.
In any case, we'll definitely check out the Inari 8!
Which problems exactly are bugging you? I've outlined mine ones in /thread/7507 this thread, and Broadcom firmware/nvram files for Inari Android have arrived since (didn't try out these during this round as my older kernel experiments were pretty messy and I'd better rebuild from scratch -- and here's the question of the base version, 3.10-yocto, 3.16/3.17 or whatever as briefly discussed there either).
Judging by Inari kernel patches some problems are going to be unique to each particular platform indeed, and it's worrying (wish Intel was talking to board designers and ODMs so that the divergences were kept to reasonable minimum and ideally got merged into intel kernel tree quickly).
The tablet itself is pretty nice indeed, 1920x1200 is what bought me (a short-sighted historically HiDPI person).
LynnZ welcome :-)
Each platform having its own unique issues is a major headache indeed! Our key driver-specific issues are mainly multitouch & Wifi - multitouch works at random times on random platforms whenever it's in the mood, and Wifi doesn't work at all on any platform because apparently no ODM wants to use Wifi modules with open-source drivers.
And we also encountered hardware-specific issues unique to their platforms - e.g. the 64-bit UEFI-ready tablet I mentioned previously turns off its USB hub within 5 min of booting up with no way of getting it back on apart from a hard reset, another 32-bit UEFI tablet we have can only use 1.4gb of RAM despite being able to detect 2gb (even in the original Win 8.1 install), and yet another 32-bit UEFI tablet requires the ODM's manual reset when the battery goes flat.
So, with this experience I'm quite amazed that... (1) Intel accepts such standards from their ODM partners, and (2) that there can be platform-specific issues despite Intel prescribing the components & parts to be used for Bay Trail architecture.
I guess we should pay more attention to the Inari tablet from now, if the hardware/driver issues get sorted out then maybe this could become the standard 'reference' for Linux tablets and developers, and we'd be happy to get on the bandwagon especially since it has a FHD display. =)
Many thanks for your input,
Latest news of 3.18-rc4 on Inari 8:
kernel: brcmfmac: brcmf_cfg80211_escan: Connecting: status (3)
kernel: brcmfmac: brcmf_cfg80211_scan: scan error (-11)
I haven't seen any RAM size or USB related issues on this tablet running 64-bit firmware and kernel so far.
So my /thread/7507 showstopper list is slowly shrinking but not there yet.
Thanks for the info, this is great news!
It was just a few kernel subversions ago that almost nothing worked, and now we have significant support for many of the essential features of a tablet. With this level of continued commitment from Intel & the kernel devs it looks optimistic that we will see fully functional GNU/Linux distros working across the Bay Trail platforms soon.
By the way it seems that there isn't much gyro/accel support built into the kernel yet (or there aren't many open source drivers out there)... do you use a 3rd party binary blob for your Inari tablet or does it not work for you either?
Heh, and I've got broadcom wifi https://bugzilla.kernel.org/show_bug.cgi?id=88061 working too (with 3.18-rc4) an hour or two ago.
Is there any wiki in addition to this forum around so that some kind of status whiteboard could be maintained for some known devices?
Re sensors, IIO modules are loaded by udev here but I was unable to get anything resembling real data off sysfs interface for those, maybe https://github.com/mer-packages/sensorfw sensorfw will be useful to you too (https://gitorious.org/sensorfw gitorious repo looks abandoned). I didn't examine the Android tree that's handy regarding sensors closely enough, there are two blocker problems /message/10270 remaining so far: suspend and brightness.
So far the only status whiteboards I know are https://www.happyassassin.net/fedlet-a-fedora-remix-for-bay-trail-tablets/ Fedlet which posts updates for Fedora-based distros and http://www.jfwhome.com/2014/03/07/perfect-ubuntu-or-other-linux-on-the-asus-transformer-book-t100/ Ubuntu on T100 but the guy hasn't posted any updates for some time now. The disadvantage of these 2 whiteboards is that since they are unofficial projects some of the hacks or firmware they use might not be upstreamed into the main kernel tree so there's no guarantee that something that works now might not break later. The advantage of course is that we have a good sense of where the 2 major distros stand in terms of Bay Trail hardware support.
I don't know of any distro-agnostic (i.e. pure kernel) whiteboard, perhaps we could/should start one.