yashsingh1/xdaforums huggingface dataset:
[Windows 8 Development and Hacking] TrueNix:
Hey guys please go to Asus support and ask for UEFI 64bit support,I have already done it.

ASUS CASEID=RWTM20140129194133647-522	Please click here if you wish to reply this mail!

Dear Valued Customer,

Thank you for contacting Asus Technical Support Service

Please accept our apologies for your situation and your inconvenience.

Your complaint has been registered and the proper officials will be notified.

Thank you.

Asus Technical Support Team

---------- Original Message ----------

From : ruslank.qa@gmail.com

Sent : 1/29/2014 11:41:34 AM

To : "techsupport@asus.com"

Subject : <TSD> Satisfaction-ISR(EN) : UEFI 64bit Support URGENT!!!

[CASEID=WTM20140129194133647]

Apply date : 2014/01/29 11:41:33(UTC Time)

[Contact Information]

Name : Kuznetsov

Email Address : ruslank.qa@gmail.com

Phone Number : +972542382538

Country : Israel[מְדִינַת יִשְׂרָאֵל / دَوْلَةُ إِسْرَائِيلَ]

[Product Information]

Product Type :

Product Model :

Product S/N :

[Comment]

Subject : UEFI 64bit Support URGENT!!!

Topic : 1 .Product Quality; 2. Service Quality; 3. Others

Description :

Hi, please add UEFI 64bit support to T100TA its very important for me.

Thanks.
[Windows 8 Development and Hacking] EpicLPer:
Can you tell me more about your Dual Boot on the Encore? I tried to boot Ubuntu via USB but I had no luck...

Windows just tells me (or the UEFI from Toshiba) "No Stick" or something like that and throws me out to the HDD, USB, etc. menu to choose from. If I select the stick again it boots into Windows...
[Windows 8 Development and Hacking] TrueNix:
I have found some Intel's android binaries

here >> http://software.intel.com/en-us/android/articles/android-43-jelly-bean-x86-emulator-system-image

is any one able to compile?

Edit: Here is installation manual

http://software.intel.com/en-us/and...ly-bean-43-installation-instructions-manually
[Windows 8 Development and Hacking] SixSixSevenSeven:
A binary is the result of compiling. You compile source code to produce a binary.

Also this is an android 4.3 image for the Android SDK's built in emulator. It is not an installable operating system for your tablet.
[Windows 8 Development and Hacking] TrueNix:
Thanks for an explanation.:good:
[Windows 8 Development and Hacking] krook1:
MicroSD for boot

Is it possible to boot using the microSD card, instead of USB?

I could not see it as being listed when I get to the boot menu.

Could not also get Rufus to write to the card in the slot.
[Windows 8 Development and Hacking] SixSixSevenSeven:
Sadly no you cannot boot from microSD. That is a fairly common restriction though.
[Windows 8 Development and Hacking] AdamWill:
In case anyone wondered - I haven't forgotten about or given up on this, and progress for regular Linux distros (I'm afraid I don't give a flying **** about Android, I bought this thing explicitly to have a tablet which *didn't* run Android) is happening, it's just not happening in ways worth making a huge fuss about yet. But I'm in touch with some devs at Intel who are interested in improving the Linux driver support for these things. Mostly we've been running to stand still with recent kernels so far - changes keep landing in 3.13/3.14 that broke stuff that worked before, and then we fix those, and it's kinda progress, but basically the system works like it did before =)

I can build and boot a Fedora image on these using fallback graphics, and use GNOME Shell okay with the touchscreen. But without accelerated graphics and network, it's just not worth putting out images for people or making a song and dance about it. As soon as we have modesetting and some kind of wireless function going I'll probably stick an image up somewhere for people to poke.
[Windows 8 Development and Hacking] Sacob:
any news about that?
[Windows 8 Development and Hacking] zombie673:
Good to hear that people are still working on this, and I'm happy to hear that there has been more headway. How goes the android front?
[Windows 8 Development and Hacking] JoinTheRealms:
Will jump into thhis project in the next few days, picking mine up today (need a few days to get angry at windows before i install linux lol) Ive been porting GNU/Linux to the arm based tegra3 Asus Transformers and the port is pretty much complete. From what ive seen, we should be able to get atleast 2.4GHz wifi working using Android bcm4329 firmware and recompiled module.

Hopefully Intel can come to the party with modified VESA drivers for these devices, im pretty sure they will

edit wrong broadcom chip, but this firmware was provided by broadcom for the bcm43241 https://www.dropbox.com/s/8m9n4qolf76iz11/brcmfmac-sdio.zip
[Windows 8 Development and Hacking] Jhong2:
I just picked up by t100 today, and plan to get Ubuntu working well on it.

According to this bug report, cross-arch is now working in the latest Ubuntu kernel builds, so it should be no problem running 64-bit kernel from the T100's 32-bit UEFI.

[MENTION=1512020]AdamWill[/MENTION]: History keeps repeating with Intel. Had the same problem with my old netbook and Poulsboro drivers. I'm assuming the 2d Vesa BIOS bug is fixed at least now?

For the sound I'm hoping it's not too dissimilar from the alc5632 driver -- it should be a good starting point at least.

The devil will be in the detail -- orientation, light sensor and power management.
[Windows 8 Development and Hacking] zombie673:
Good to hear! If anyone needs help testing things, let me know.
[Windows 8 Development and Hacking] Jhong2:
Using the latest 14.04 Ubuntu daily (kernel 3.13), managed to get (2d) native resolution by disabling KMS.

Compiled my own bootia32.efi using latest grub sources (the one in the op here works but seemed to be buggy, may have just been me). Just needed nomodeset as a kernel parameter to boot.

Since there's no display modesetting, you need to do a reboot cycle after using the BIOS. If you come directly from there to GRUB, you're stuck in 800x600. However after a reboot, you'll get native resolution. I think kms will be fixed in the current kernel, as the bug was mentioned on the lkml. Then we can specify video=VGA-1:1366X768@60.

Time to start following drm-intel I guess now.
[Windows 8 Development and Hacking] AdamWill:
Heh, I was involved in the Poulsbo go-round too (my initial blog post is what Phoronix picked up on). This isn't really the same thing; the hardware involved is basically sane and the support for it is mostly there, it's just finicky details missing mostly, and then some non-Intel hardware (none of these devices have Intel wireless AFAICT).

I have a Fedora-based image up for public download now at https://www.happyassassin.net/fedlet-a-fedora-remix-for-bay-trail-tablets/ , though the current one is hardwired to 800x1280 for the 8" tablets. I keep meaning to put up a 1366x768 version but didn't get around to it yet. It's nowhere near done, but at least usable. I think the T100 wifi might actually work out of the box on Fedora, given what I know about it (the relevant driver and firmware are both present in Fedora kernels, at least) but I don't have a T100 to test.

I have various miscellaneous bits that back the Fedora image up at https://github.com/AdamWill/baytrail-m which may possibly be of use to you - though I'm building off Fedora Rawhide, so the kernel patches are all against 3.14rc2, for instance - and I'll dump the current list of relevant bug reports here:

https://bugzilla.kernel.org/show_bug.cgi?id=69831

https://bugzilla.kernel.org/show_bug.cgi?id=68291

https://bugzilla.kernel.org/show_bug.cgi?id=67921 (only for v8p)

https://bugzilla.kernel.org/show_bug.cgi?id=69011

https://bugzilla.kernel.org/show_bug.cgi?id=67911

https://bugzilla.kernel.org/show_bug.cgi?id=65841 (only 32-bit kernels)

https://bugs.freedesktop.org/show_bug.cgi?id=71977, https://bugzilla.kernel.org/show_bug.cgi?id=68451 and https://bugs.freedesktop.org/show_bug.cgi?id=74657 (video mode detection stuff)
[Windows 8 Development and Hacking] Jhong2:
Thanks, I might have to give that a try...

I've tried with a bunch of kernels; 3.14-rc2 mainline and drm-intel-nighty. Of these, 3.14-rc2 seems to be the worst; it still needs nomodeset, but I also need to add noacpi to prevent a kernel panic.

All very disappointing, was hoping I would get further with the bleeding edge builds.

Now I'm working from an installed Ubuntu, I'm also having trouble getting a grub efi image to work; I keep having to boot manually from the grub2 command line, which works but gets old fast. It also only seems to work if I've just come from the bios; without that I get a tight boot loop.

EDIT

Accelerated graphics with KMS seems to work on 3.13 with the kernel parameter video=VGA-1:1366x768e

The 'e' apparently prevents probing the screen for supported modes, which causes the crash...

This is with the drm-intel-next kernel.

Still get panic on 3.14, need to debug
[Windows 8 Development and Hacking] Jhong2:
Made a fair bit of progress.

Managed to get 3.14-rc2 booting no problem, and grub installed properly, so am booting up normally; it just needs the video=VGA-1:1366x768e parameter.

Xrandr works fine, so screen rotation will be no problem once we have the accelerometer / orientation sensor cracked.

I got wifi working using the brcmfmac43241b4-sdio driver, but signal strength was weak. I believe this was because the nvram obtained through nvramtool was not correct; AFAIK (and I'm still learning on this), since uefi is 32-bit, access to uefi / nvram vars is unavailable from within a 64-bit linux. So instead I tried to extract nvram from a uefi shell, and converted the hexdump to ascii. This seems to work much better. I've attached the nvram as brcmfmac4321b4-sdio.txt. This just needs to be copied to /lib/firmware/brcm along with the firmware.

All ACPI is basically still broken, but I'll see what we can get.

Sound seems a long way off. ACPI IDs have been added for the "Intel SST audio device" since kernel 3.13, but Intel hasn't provided a driver yet. Haven't looked closely yet.

It seems someone is working on the battery monitor.
[Windows 8 Development and Hacking] thetoady:
I have a dell venue 8 pro but still following this thread as probably very relevant. With that said, I assume the T100 has the same issue as the dell in that it can't boot off the SD Card (And hence why all the work to having it boot off of USB).

has anyone thought of getting it to boot off a small boot partition on the emmc and have it mount the root file system off of the (possibly partitioned) sd card?
[Windows 8 Development and Hacking] Jhong2:
Sure, it boots off the internal flash no problem. I just replaced <efi>/Boot/bootia32.efi with the one created by grub-mkconfig.

The root file system can then be mounted from anywhere accessible -- but the problem you will have is; I don't think the external SD is available prior to boot (I didn't try, but others have said so). I just divvied up the emmc and will eventually remove Win8 anyway. In your case, why not just add a small root partition? Doesn't have to be big.
[Windows 8 Development and Hacking] thetoady:
I'm arguing it doesn't even need to be big. linux is designed to have a boot partition on a different media than the regular root file system (this was common practice back in the "olden days" when lilo couldn't boot a kernel if it was stored too far down the disk, so one would make their boot partition be at the front of the disk, and once the kernel was booting, it could mount a root partition from anywhere. same concept here. just need a place to store a kernel and the the initial ram disk that is used to setup the system the normal root fs can be on the sd.

also in practice the best thing will be for there to be a touch friendly (or at least a volume / windows button friendly) boot loader :)
[Windows 8 Development and Hacking] AdamWill:
You need to build sdhci_acpi into the initramfs to boot off the internal storage - see https://bugzilla.redhat.com/show_bug.cgi?id=1063556 . Patched in upstream dracut, now, but there isn't a release with the patch yet.

If you're building current kernels you also probably want this patch:

https://github.com/AdamWill/baytrai...-setpoint-to-90-temporary-hack-for-BKO-.patch

to dodge a major performance regression, see https://bugzilla.kernel.org/show_bug.cgi?id=70941 .

The sound drivers aren't done yet, and will require firmware, apparently: http://mailman.alsa-project.org/pipermail/alsa-devel/2014-February/072807.html

---------- Post added at 08:12 PM ---------- Previous post was at 07:26 PM ----------

BTW, is /sys/bus/sdio/devices populated on the T100? Is the wireless connected via PCI or SDIO, do you know?
[Windows 8 Development and Hacking] JoinTheRealms:
It uses SDIO
[Windows 8 Development and Hacking] Jhong2:
Thanks, yes I've looked through your repository, and been tracking asoc sound as well.

I've also merged the mixed-mode branch of mfleming's git repository -- looks like he's getting EFI runtime services to work in mixed-mode.

Looking through my ACPI DSDT I aso notice that the tablet buttons are in INTCFD9 / PNP0C40. This is a GPIO button array. Looking through your posted dmesg on linux-acpi, you have the same device on your Dell, so I assume these are common to all Bay Trail devices. As far as I can see, no driver exists in linux for this device yet. I'm thinking of writing one... am quite new to it, but it looks like i can hook up the ACPI ID to some pre-existing handlers and use the gpio-key stuff.
[Windows 8 Development and Hacking] Jhong2:
UPDATE

- Trying 3.14-rc4 mainline, performance seems better (but could be subjective).

- Keep trying to compile Intel's sound driver in the intel/haswell-dsp branch of the asoc tree, but no luck yet, can't get them to link. Will keep trying.

- I've written a driver for the tablet buttons, should work on all Baytrail tablets as it's a standardized 5-button spec (Microsoft call it a "Windows-compatible Button Array" and have written down exactly how it should be implemented) -- will share it soon, hopefully someone can test and ack it so I can submit it.

- Here (take from lib/udev and etc/udev) are some udev scripts for Ubuntu that enable/disable the onboard keyboard when docked/undocked. To use them, you'll first have to turn on the Onboard keyboard in settings -> accessibility, set it to show an icon, disabled by default.

- In the same repository I've also added my extracted nvram. I've also added a couple of other nvrams that I've been playing with to try to improve wifi reliability. See if you have any luck with any of them (you can test by copying them to /lib/firmware/brcm/brcmfmac43241b4-sdio.txt, then modprobe -r brcmfmac && modprobe brcmfmac)

- I fear poweroff will only work for this thing with efi runtime enabled. Which isn't going to happen on 64-bit until the above-mentioned mixed-mode branch gets approved. I'll keep playing to see if there's another way.
[Windows 8 Development and Hacking] Alex Atkin UK:
I don't understand why this is such slow going. The previous Atom had better support than on Windows (64bit support), it baffles me what is going on here.

I thought Intel were supposed to be good supporters of Linux, why so slow at getting the support for this chip? Have Microsoft bribed them to be slow or something?

Kudos to everyone who keeps trying the latest code to get this working, but it really shouldn't be THIS hard. :crying:

Then again when we ONLY have 32bit drivers for Windows due to connected standby, yet those drivers are so poor that the battery life on connectedy standby is useless, there is no good reason not to have 64bit support either as I would prefer normal standby right now. If I want to be alerted to something immediately I would have that alert on my phone, does anyone actually use a tablet for that sort of thing?
[Windows 8 Development and Hacking] Jhong2:
Support is getting there, but the current state might be reflective of the fact that this is a stop-gap for Intel while they play catch-up to ARM in the tablet market. As I understand it, they'd like to integrate as much as possible onto the SoC, but they're still only part-way there, with many more off-chip devices than they had hoped. So this is just a pit-stop on their roadmap, and is quite expensive for them to sell in the current incarnation.

Anyway, more progress:

I believe all the sensors (orientation/accelerometer, ambient light and the camera) are connected via i2c. However until now I wasn't able to probe them, and i2cdetect turned up nothing other than the Intel graphics and the touchscreen, which are obviously already working. Looking through the ACPI DSDT though, I found them, and they're already handled by the i2c-designware driver I think.

sudo modprobe i2c-designware-core
sudo modprobe i2c-designware-platform
sudo modprobe i2c-dev

Identifies them and puts entries in sysfs and /dev... 7 entries in addition to the i2c associated with the Intel graphics.

Now it's just a matter of figuring out which devices are which and how to communicate with them. i2c is relatively simple once we can figure out what we're talking to. sensors-detect can probe the devices and displays what addresses they respond on.

Here are some leads...

- The Light sensor is a capella CM3218x -- there's already a driver for that in the kernel. i2c-cm32181 (needs i2c-smbus I think. Also, this was not compiled by default in Ubuntu .config. It's under Device Drivers -> Industrial I/O -> Light sensors)

- The accelerometer is invensense -- may be handled by the ivn-mpu6050 driver

- The camera is on the Intel i2c controller and is probably a mt9m114 sensor. There is a driver for Linux for this already already, but I think it needs to be converted to the new v4l2/soc_camera format. Looks like there's one in Android, so this shouldn't be too hard.

Both the light sensor and accelerometer should provide interfaces under iio in sysfs once they are working. The camera should work with v4l2 and soc_camera_platform.
[Windows 8 Development and Hacking] AdamWill:
Sound is working for me now, with the latest patches from https://git.kernel.org/cgit/linux/kernel/git/lrg/asoc.git/log/?h=intel/haswell-audio-dsp (take the entire set since 3.14rc1), plus "ASoC: Intel: byt-rt5640: Update internal mic and speaker kcontrol names" , "ASoC: Intel: byt-rt5640: Use init time DAI format" , "ASoC: Intel: sst-acpi: Fix Oops in case of missing firmware" , plus https://lkml.org/lkml/2014/2/18/127 , https://lkml.org/lkml/2014/1/20/88 , https://github.com/rjwysocki/linux-pm/commit/b2a51a6d0f96308251cfa41b793c43d0316e3b16 . I put all this in kernel config:

CONFIG_PWM_LPSS=m

CONFIG_SND_SOC=m

CONFIG_SND_SIMPLE_CARD=m

CONFIG_SND_DESIGNWARE_I2S=m

CONFIG_SND_ATMEL_SOC=m

CONFIG_SND_SOC_INTEL_SST=m

CONFIG_SND_SOC_INTEL_SST_ACPI=m

CONFIG_SND_SOC_INTEL_HASWELL_MACH=m

CONFIG_SND_SOC_INTEL_BROADWELL_MACH=m

CONFIG_SND_SOC_INTEL_BAYTRAIL=m

CONFIG_SND_SOC_RT286=m

CONFIG_SND_SOC_RT5640=m

CONFIG_SND_SOC_INTEL_BYT_RT5640_MACH=m

Some of that's probably unnecessary, but better safe than sorry. You may also need "ASoC: Intel: Baytrail: Fix implicit declaration of function 'memcpy_fromio'" - I didn't, but apparently it breaks the build in some circumstances.

Get the firmware from https://chromium-review.googlesource.com/#/c/179012/ (note it's not legally redistributable, so don't redistribute it to anyone...) and stick it in /usr/lib/firmware/intel . The needed ALSA mixer config is at https://github.com/AdamWill/baytrail-m/blob/master/alsa/t100_B.state .

On the buttons - I would expect someone at Intel is likely to implement support for it, so you might be duplicating work, but hey, maybe you'll get it done first and save them some time :) I'll ask my Intel contacts if anyone's working on it at present. It'd be nice to have those buttons hooked up for sure.

---------- Post added at 02:45 PM ---------- Previous post was at 02:41 PM ----------

It's probably not: support for the turbo pstates got merged between rc3 and rc4. http://permalink.gmane.org/gmane.linux.kernel/1646867

Cool! If you stick it up I'll test it on the fedlet.

There's a pair of quirk patches in my git repo which make shutdown/reboot work flawlessly for me on the V8P, and I believe Alan Cox says it works fine on the T100 too. I also stuck in a quirk for the Miix 2 which should work, but no-one with a Miix 2 confirmed yet.

https://github.com/AdamWill/baytrai...-on-Baytrail-tablets-Dell-Venue-8-Pro-L.patch

https://github.com/AdamWill/baytrail-m/blob/master/kernel/dv8p-poweroff.patch

(despite the name of the second it's not v8p-specific).
[Windows 8 Development and Hacking] Jhong2:
Great! Will give it a try! I never managed to merge the haswell-dsp branch into mainline and get it to compile/link, so maybe that last link will do the trick (most of the individual patches seem to be merged in haswell-dsp now btw...)

Also, the gpio/lpss IDs were reverted from mainline as they caused Alan's T100 not to boot up right? So not sure what to do with that...

Intel's insistence on the firmware license (and dumping it in Chrome OS first rather than upstreaming it) is bizarre. Anyway, it's on the Internet now and I think we have fair use to our own hardware.

I'm plodding along -- I think this is holding me up, the gpiolib stuff is all new. My status is here, but it's all scaffold for now, don't bother testing it.

Yes saw that -- it certainly feels better! Since I was compiling all the time I also turned on the atom optimizations. they seem to help too.

Any thoughts on power management (battery, AC adapter are both in the ACPI DSDT so I'm not sure what the problem is...). Any suspend/resume recipes? I played with hibernate, but the display is corrupted on resume.

Yeah, I went through your patches. From my reading, the reboot patch is effectively the same as the reboot=pci kernel parameter.

For the shutdown patch however, it reads as if EFI services need to be enabled?

if efi_enabled(EFI_RUNTIME_SERVICES))

They aren't on 64-bit....

BTW got PM from Alan (says he can't post in 'developers' due to post limitation -- how ridiculous is that?). He mentioned there are other ways around this... but I don't know what yet....
[Windows 8 Development and Hacking] AdamWill:
Oh, I'm pretty sure they intend to upstream it to linux-firmware, it's just not done yet. Probably have to sacrifice the right number of chickens to the Legal Gods first, or something. The license in the chromiumos tree is clearly intended for ODMs rather than for end users directly, and it's clearly a generic license they use for all kinds of stuff (going by the wording I suspect they use it to cover, for e.g., video playback acceleration drivers with h264 codecs embedded in them, and stuff like that).

Cool, I'll keep an eye on it.

I'm just the monkey, any actual code work here is way beyond me. I just bash patches together. Jan Michael Brummer (one of the guys I'm talking to at Intel) told me back a couple of weeks ago that they were working on it and had some initial progress, but it wasn't upstreamable yet. Not sure of the current status. There is a bug report on it: https://bugzilla.kernel.org/show_bug.cgi?id=69011

Suspend/resume works for me on Fedlet, but I think the screen backlight is left on (which will obviously suck substantial power), and sound doesn't survive the suspend/resume cycle yet (Liam tells me that's a WIP). My USB wifi doesn't survive it either, but it pops back up if you unplug/replug. I saw moderate display corruption in X only one time (other times it worked fine), and a ctrl-alt-f2/ctrl-alt-f1 cycle fixed that. I generally don't bother with hibernation on anything, I just don't see the point.

D'oh, yeah, you're right. I thought to check the quirk patch for EFI service dependent stuff, but not the poweroff patch. Fedlet is straight 32-bit, so it does work there.

Colour me intrigued :) From a discussion we had today it sounds like the basic plan here is to get mixed-mode working properly and then actually add support for it to mainline Fedora, at which point I can stop doing fedlet builds, which would be a blessing. Glad Alan got in touch, I figure one of the things I can actually help with is making sure everyone working on this stuff is talking to each other :)