Preface

Last Updated: 30/05/2020

Hello World

A perpetual work in progress (4-ish years now) and pretty damn complete. If you have time, you too can have Linux on your Bay Trail device and learn why things work and do not work. Primarily this article focusses on the Venue 8 Pro.



It's been a while, I'll be making edits and notes since Fedora 32 has me excited and makes my Venue 8 practically usable.

Fedora Powered Update, 14.05.2020

Anyone who ends up here trying to install Fedora 32 here's my quick notes.



There is an EFI related bug (happens to manifest on 32-bit UEFI) that seems to get triggered the moment Anaconda has finished the software install stage and goes about installing bootloader related material. The install process is basically dead at this point as the kernel throws its virtual arms in the air. This applies to Fedora 32 install media using kernel 5.6.6



i 1013.257618] BUG: unable to handle page fault for address: 000000001c4fce98 [ 1013.257626] #PF: supervisor write access in kernel mode [ 1013.257629] #PF: error_code(0x0003) - permissions violation [ 1013.257632] PGD 72950063 P4D 72950063 PUD 72951063 PMD 1c4000e1 [ 1013.257640] Oops: 0003 [#1] SMP PTI [ 1013.257645] CPU: 3 PID: 3739 Comm: systemd-udevd Not tainted 5.6.6-300.fc32.x86_64 #1

I initially thought maybe it was an SMP related bug and tried booting with "nosmp". This however resulted in Anaconda not finding the eMMC storage device but as a last attempt I disabled multi-core support in the system BIOS.



(Volume Down / F2 @ Power On) > BIOS > Advanced > Multi Core Support Set to "1" vs "All", revert after install + update is done.

This hunch resulted in Anaconda finishing the installation process succesfully. (Be advised that it will take a while, I think the whole process took about 1.5 hours as with a single CPU core the system spent most of its time at a load of 4 - 4.5)



As per the bug report above the fixes for this should already be upstream, so after the installation completed and doing a round of updates I turned all cores back on and my Venue 8 appears pretty happy sofar on kernel 5.6.11-300.



If you get "stuck" when updating SElinux related packages you'll probably find "restorecon" eating up CPU cycles, give it about 25 - 30 minutes. After the relabelling process is done DNF will continue and finish up.



Initial impression are _very_ good. Headphone detection works now, microphone input with an iPhone headset as well as the internal microphone switch and work fine, there is no more need to deploy UCM files to make audio behave right, touch works, IIO proxy + Wayland makes screen rotation happen in a literal "blink". The only "manual" labour sofar has been installing the ath6k firmware blobs. I'll let it do random things over the next few days, if I find something truly egregrious my dear reader I'll let you know.



Venue 11, Writings have moved.

- DV11P Writings -



In an effort to clean up and get to a point where only the latest information is on the base index I've begun migrating material for the DV11P to it's own page. The current index was already 95% Venue 8 oriented anyway.



Venue 8, Archived writings.

- DV8P Archive -



Like the Venue 11 segments, there's alot of cruft about the Venue 8 dating back to Kernels from yoinks ago. If you are missing something here there is good chance it's in the Archive.

The News

I'm currently testing Fedora 32 and, as of writing, my Venue 8 is at an record uptime of 6 days and 2 hours whilst discharing, charging, disconnecting, connecting, removing kernel modules, probing kernel modules, suspending, unsuspending, etc. Sofar I've had a couple of moments where I was anticipating the device had crashed but a little patience and pushing one of the hardware buttons would prove me otherwise.



I'm currently preparing a 2.0 of "iwup.py" which is a little tool I made in Python that monitors the WPA Supplicant and then reloads the kernel module if WiFi throws a wobbly.



It's been a long time since kernel 4.12 which, to me, fixed the most egregrious issues and made the tablet usable as long as you adhered to a couple of rules. Primarily, Do not hotplug USB and do not suspend. This was fine for me since I mainly used it for inflight entertainment and bits of nerdery after which it was turned off again. It is a delight to see all the improvements that have come to the latest Kernel.



<pre> Blocks are still horrible, for now hover to see the full content or use links, lynx, elinks. Re-doing CSS eventually.



Shout Box

A warm and sincere thank you to the 26500+ or so people (May Stats) that have come by and explored this slab of text since January 2016.



Lastly a shout out to the Dragonbox Pyra which is slowly nearing completion!



The Pyra is a made and designed in Europe, community driven, niche and unique piece of hardware which combines the best of a miniature tablet with a hardware keyboard and full Linux support.



Google Bait

Running Linux on the Dell Venue 8 Pro (5830), Intel Bay Trail tablet with Arch Linux and Friends



Ye ol' Index

Demo Time

More screenshots in The Archive.

First, Thank you Internets

Because wizards should be celebrated.



Adam Williamson - For his work on the Bay Trail Fedlet.

John Wells - Valuable clues on running Linux on the Asus T100.

Bastien Nocera - Patch collection and LKML posts.

Pierre Bossart - ALSA UCM files for Bay Trail Audio.

Hans de Goede - Fixing EFI to KMS handover. (Pipe / DSI fixes)

Jan-Michael Brummer - Bay Trail Kernel work, Protips and other input.



Fellow Linux Explorers, Arch Wiki and Kernel Devs - For obvious reasons.



The information collated and provided were an immense help in getting started on installing Arch, other distros and getting going.



Project Status

Currently Running

Fedora 32 on Venue 8, Kernel 5.6.11-300



The TL;DR; Version

When I started this journey at the end of 2015 everything was pretty horrible.



We are now 4-ish years onwards, and I get this silly idea of installing Fedora 32. I figured with the various news posts and kernel mailing list items I've seen come by, the support for Bay Trail would have improved and it has tremendously so. I'm planning on doing a couple of distro hops but right now install Fedora and enjoy.



There's a number of distributions out there with Multi-Arch support meaning that the media comes with 32-bit and 64-bit UEFI support. With newer Kernel releases in place it's also alot less painful to get a distro to boot.



Booting a 64-bit kernel with Grub works fine combined with Kernel 4.10+. No startup workarounds needed anymore. If you intend to have your rootFS on a MicroSD card you will need to keep bug #150881 in mind.



If you are a kernel developer, this is my giant bug report with kisses and strawberries on top.



Just the facts Ma'am.

The Goal

Getting Linux operational on "niche" hardware, documenting it and learning from it.



With Linux working, keep functional hardware out of landfills because of user dissatisfaction with Windows and it's associated behaviours.



Less dramatically: do Linux things and enjoy some media while being in control of my operating environment and it's components.



The Why

Having procured a Dell Venue 8 Pro & 11 Pro for various reasons, the opinions whether these models can run Linux reliably and how it can run Linux are all over the place. With the Venue 8 Pro being a Bay Trail device much of this likely applies to similar hardware. (Asus T100, Asus X205, Etc.)



This slab of text is my contribution from over 4+ years of fun and entertainment sofar in the journey of this learning experience. Some of it may be flat-out wrong or relying on too much assumption, perhaps it will inspire you to think out of the box.



The overall somewhat irreverent writing style is because I can, if you are expecting a super serious engineering tone go read RFC's or MANpages.



Technically, to make it all work you are reliant on at the bare minimum the Kernel 4.4+ series as this brings in a number of hardware support features such as PMIC, CrystalCove and Intel Atom SoC Support where the Venue 8 Pro is concerned.



Realistically, Kernel 4.10+ is where you want to be for basic proper operation. Ideally though, Kernel 4.12+



Lastly this article is oriented towards explorers and enthusiasts so some assumptions are in place here and there. Some explanation may also seem rather verbose to answer the "If you did X what would Y then do".



Bug Reports

@kernel.org ----------- #67921 - Dell Wireless 1537 / 1538 support #73081 - Fail to setup bluetooth on Dell Venue 8 / 11 Pro #86581 - Baytrail-T no sound #96571 - [CHV] Backlight init fails on Surface 3 #97330 - [CHV DSI] black screen #100356 - [DSI][BYT] Panel detection fail #101205 - [i915][BYT] Blank screen on DSI panel #109051 - intel_idle.max_cstate=1 required on BayTrail #111481 - Call trace with snd_soc_sst_mfld_ platform when suspend to freeze #150881 - mmc0: Failed to request irq 8: -16 #1830149 - [abrt] suspend_devices_and_enter. suspend_test.c:53 @freedesktop.org ---------------- #31313 - X rotates display with delay and black screen effect #82880 - Blackscreen on modesetting #85977 - Backlight support Dell Venue 8 Pro #96571 - Backlight init fails if module load order is wrong

Mailing & Reading List

Device Status

Venue 8 Pro (5830) on 5.6.11-300

MicroSD Card Slot Notes

Per Dell: SD card slot speeds on Dell Venue Tablets



Thread: Dell Venue 128GB MicroSD card support

uSD Cards used for testing

- 8GB, SanDisk Ultra (SDSDQUA-008G-UQ46A)

- 16GB, G.Skill (FF-TSDG32GA-C10)

- 32GB, Samsung Pro (MB-MG32D)

- 64GB, G.Skill (FF-TSDXC64GA-U1)



Venue 8 Pro (5830)

- SD, SDHC, SDXC Support

- Bus Speed: 25MB/s

- Tested: 8GB, 16GB, 32GB, 64GB cards.

- Untested: 128GB



BIOS Notes

The internet mentions that in BIOS release A03 for the Venue 8 there were settings allowing HS200 support (LPSS & SCC Configuration) for the internal eMMC and DDR50 support for the MicroSD card slot.



I've had a brief look at modifying the A14 BIOS but AMIBCP doesn't show me any of the "setup configuration" options, which would make adjustment a click of the button, leaving me only with the DMI data and generic BIOS strings.



It's probably very unwise to flash the previous BIOS back on, it likely bricks the tablet and even if it worked would likely make the unit very unstable.



My current theory is that maybe just taking the setup EFI module from the A03 release and swapping it into the A14 release may do the trick but right now the A03 setup module doesn't even register as valid so something seriously changed in the overall firmware structure over time.



This is the lowest on my priority list to have another look at for the time being.



Hat Tip to BIOS-Mods for valuable clues.

Overall Experience

With a recent kernel (5.6+) the Venue 8 Pro is a functional device providing me with a laptop like experience when combined with a USB wireless keyboard and mouse.



With a light workload I'm getting to 6 - 8 hours, on a battery that currently reports having 3238 mAh (65% of design capacity) life left in it, not bad considering the age of the device at this point.

Stability is excellent, in testing I've enjoyed several days of uptime where this was once measured in hours.

WiFi can be hit and miss, but this also seems to be an issue on Windows if the Internet is to be believed. Average is ~35 minutes of connectivity before having to reset the card.



Running Linux from a MicroSD card with BTRFS nets about 15-20MB/sec throughput, despite this, startup to login is about 8 seconds and programs launch pretty swiftly. It's good enough for me anyway.



Internal MMC nets about 155 - 165MB/sec.



MPV plays 8-bit and 10-bit fansubs fine. 8-bit H264 content is processed by the onboard decoder when enabled. Audacious and friends provide audio content. Firefox does Internets. Chrome is a little more "Finger friendly".



Speaking of Audio, it's set to 48Khz so any 44.1Khz has to be resampled which incurs a cost of processing cycles and is heavily dependent on using Pulseaudio.



Multi-touch is functional, with "onboard" installed (onscreen keyboard) I can hold down multiple keys so I assume that works correctly. Wayland has a multi-touch test which shows the hardware is doing the right things. Having said that, trying to use a UI designed for a mouse with your fingers...



Pen input works fine. Up to 255 pressure levels and the button can be configured as left, right or middle click.



Pen makes for a reasonable mouse replacement and is smooth in usage.



Preliminaries

I often excel in the virtues of hedonism and such is the pleasure of having something "just work" so I've tested a couple of distributions.



If you go with Fedora or Debian you'll be up and running with relatively little effort. Other distributions require you to simply add the 32-bit bootloader to the install media and then may require you to manually deploy it again after installation.



Public Service Announcements

The Venue 8 has a 32-bit UEFI (despite being a 64-bit capable system) you'll need an install / live media that has "bootia32.efi" lurking around to get started.



Use the newest possible Kernel. Some things may not work regardless of how hard you try.



You'll likely need the updated Atheros Wifi firmware files, and a UCM file to get audio to work.



It may also be beneficial to blacklist "snd_hdmi_lpe_audio" in your /etc/modprobe.d/blacklist.conf (remix as appropriate) so Pulseaudio doesn't end up with a dummy output.



Depending on your distribution of choice you may find yourself compiling a kernel to get things working such as PWM support which is required for brightness controls.

Fedora: Rawhide Kernel

You can consider trying the testing Kernel which last I tested was at 4.13.0, it is able to adjust the screen brightness correctly and most things appear well behaved with my limited testing.

dnf config-manager --add-repo=http://dl.fedoraproject.org/pub/alt/rawhide-kernel-nodebug/fedora-rawhide-kernel-nodebug.repo dnf update dnf install kernel

Should your startup go all wonky consider temporarily adding "enforcing=0" to your Kernel flags and letting the system do an auto-relabel to keep SELinux happy. Upon reboot things should go back to normal.



Hat tip to the Fedora Wiki.

Blank Screen: Failed panel detection

On older Kernels the handover between EFI and KMS is less then ideal resulting in people being left with a blank screen or being forced to use the nomodeset flag to atleast get a console and unaccelerated Xorg working.



From Kernel 4.9 onward this issue is fixed. However there appear to be some isolated cases where despite the improvements made Bay Trail devices still end up with a blank screen.



Parker's Venue 8 is such a case. I've been trying off and on to find clues to no avail and then I got an email reporting success with a little bit of hackery. Have a look at bug reports #100356 and #101205 for more details.

Session Manager: GDM

GDM comes with an onscreen keyboard out of the box that is activated when it detects a touch event into user / password fields which is very practical.



Session Manager: SDDM

SDDM comes with an onscreen keyboard out of the box that has to be summoned with a touch on the "virtual keyboard" button, unlike GDM where the keyboard pops up the moment a touch event in an input box is detected.

Session Manager: LightDM

Many distributions default to LightDM and while basic accessibility features are there adding an onscreen keyboard may require a little bit of effort. The virtual keyboard support is provided via Onboard.

Add Onboard to LightDM

#/etc/lightdm/lightdm.conf greeter-session=lightdm-gtk-greeter #/etc/lightdm/lightdm-gtk-greeter.conf keyboard=onboard

If you did it right "On Screen Keyboard" will show up as a selectable option under the accessibility menu.

uPower Daemon

If your device has an issue with battery management or is not able to detect Charger / AC correctly it may help to disable "upower" if you find your device shutting down the moment you log in to your graphical session be it using a Live system or an established install.

# Append to Kernel Parameters to "stop" systemd before the GUI comes in. # Usually accomplished by highlighting your boot option and # then pressing "e" for edit. # It may also help to remove "rhgb quiet splash" flags if present systemd.unit=multi-user # When prompted, press enter for maintenance mode. # Remove executable powers chmod -x /usr/bin/upower chmod -x /usr/lib/upower/upowerd pkill upower pkill upowerd systemctl disable upower.service # Resume Booting Ctrl + D or "exit" to resume boot to graphical.target

Should this not work as a last resort, pop to a TTY as soon as you can and quickly punch in those commands. I had to do it this way with Debian Live as the root account is locked at start up.

SquashFS

If you have a need to "remaster" a squashfs image, this is all you need. Keep in mind, the following assumes you have enough RAM with /tmp being tmpfs based.

unsquashfs -d /tmp/casper -f /mnt/stick/casper/filesystem.squashfs # remove, edit, remix, etc. mksquashfs /tmp/casper /tmp/filesystem.squashfs rm /mnt/stick/casper/filesystem.squashfs cp /tmp/filesystem.squashfs /mnt/stick/casper/

bootia32.efi - 32-Bit Bootloader

Grub and 32-bit UEFI

The gist of the _un_official story [citation needed], as I've cobbled it together, is that Intel relented to Microsoft to provide a 32-bit environment on the platform because they couldn't get the InstantGo feature to work right on Windows 8 in a 64-bit environment. This was fixed with Windows 8.1 supposedly, however many OEMs would still ship a 32-bit version of Windows 8.1 making it kinda moot so the UEFI was kept 32-bit anyway on those devices.



Officially the story [mirror] is effectively one of cost and 64-bit Windows not being the best fit on low memory / space devices.



Previously it took a certain ammount of effort to get Linux booting correctly but since Kernel 4.9 things have been good.



Likewise a number of distributions now have support for 32 and 64-bit UEFI out of the box, look for "multi-arch", and others have announced support planning to do so in the short term.



The Fedora Project

I've been looking for a more "official source" to link to for a proper bootloader package and have found a very suitable option.



You can copy the loader out of the Fedora 27 ISO be sure to take both "bootia32.efi" and "grubia32.efi" or alternatively the Fedora Project has a ready made RPM package.



For the time being we'll stick with the Fedora 26 release package as Fedora 27 made everything modular "grub2-efi-2.02-0.40.fc26.i686.rpm".



It's recommended you move your downloaded RPM to a folder of it's own and then proceed with the commands below.

# Extract's RPM to root of current folder. rpm2cpio grub2-efi-2.02-0.40.fc26.i686.rpm | cpio -idmv # If you have your install / live media ready. cp ./boot/efi/EFI/fedora/grubia32.efi /mnt/stick/boot/efi/bootia32.efi

Sofar this version has given me the best possible odds at getting various distributions to boot.



Jeff's Github

Jeff's version seems more amicable to booting vanilla Ubuntu, alternatively you can roll it yourself and remix to suit.



Making an EFI System Partition

We're assuming the internal storage is void of any partitions and we just want a place to park the bootloader while we juggle another Live media.

# Depending on your Live system sudo -s || su # Start Fdisk fdisk /dev/mmcblk1 # Follow the prompts "n" for new partition "1" for first partition First Sector: Enter for default Last Sector: +100M "t" to set partition type "1" to set type to "EFI System" "w" to write new partition table. # Format new partition with FAT 32 mkfs.vfat -F 32 /dev/mmcblk1p1 # Make a mount point mkdir /mnt/mmc_efi # Mount mount /dev/mmcblk1p1 /mnt/mmc_efi # Copy Loader cp /some/src/bootia32.efi /mnt/mmc_efi/

Reboot and set a boot entry for your freshly copied loader in the BIOS and do some science.

Boot Flags

A number of distros use "linuxefi" and "initrdefi" in their grub.cfg for initialisation over the more common "linux" and "initrd" but they appear to be inter-changable.



This is a good thing because many of the "bootia32.efi" binaries out there lack support for these "*efi" commands. From what I can read these commands exist to handle a scenario in which SecureBoot is used and the entire boot chain is signed and verified.



Supported Distributions

Before you read on, scope out the P.S.A in the preliminaries above.



Keep in mind that most distributions are configured for a normal desktop or laptop scenario. Overall performance will vary pending your choice of desktop, filesystem and so on.



32-bit is dead. Long live 32-bit. As such, unless mentioned specifically otherwise, 64-bit releases are referenced.



Sofar in testing GalliumOS get's top marks from me as the distro that mere mortals can install and is amazingly fast out of the box.



Current Picks

I want to run something today with little effort and amuse myself. Bonus points for Ubuntu flavouring.

GalliumOS

"And what I say unto you I say unto all, Watch."

- Mark 13:37 (KJV)

- Mark 13:37 (KJV) Arch / Antergos

"I'm a real traditionalist myself of course"

openSUSE Tumbleweed, Fedora 27, Debian, in that order.

Android X86: 7.1-rc1

The Android X86 7.1-rc1 release comes with 32-bit and 64-bit UEFI bootloaders, Kernel 4.9.31 and, as expected, makes touch input a first class citizen.



"Burn" iso to USB stick, insert stick, select from boot manager and the live session loads.



Some may experience the installer as a little cryptic. Basically use the paritioning tool to make two paritions. An EFI partition (type ef00) say 200MB in size as a safe bet and a Linux partition (type 8300). The installer will then ask which will be your root partition and then it will ask which parition to install Grub on.



The install itself takes minutes, deploys the right bootloader and after rebooting does the right thing.



Wifi, Audio, Rotation (with cold boot) work out of the box. The "meta" button next to the headphone jack doubles as a home button.



By default installation from "Unknown Sources" is disabled under Settings > Security. With this enabled F-droid is easily deployed.



With Kernel 4.12 this has the potential to be glorious and it's damn nice to see how smooth a UI can be on the Venue 8 compared to Windows / Linux.



Verdict: I'm not much of an Android user, but this has the potential to recycle so many tablets. Take it for a spin if you can.



Further Android Reading:

Antergos: 17.12

The Antergos install media comes with Kernel 4.13.12 out of the box.



Follow the steps as outlined to prepare your boot media just like you would for regular Arch Linux. Optionally you can add this antergos-grub.cfg for your convenience.



You won't have brightness control in the live session but after installation it works fine.



When doing automatic partitioning the installer doesn't like the Venue 8's MMC and tries to tinker with "/dev/mmcblk1rpmb" causing input/output errors.



RPMB is a Replay Protected Memory Block, the installer treats it as block device (when it shouldn't). Manual partitioning bypasses this issue. Remix as you see fit.

Let the installer run and let it finish, don't reboot and open a terminal.

# Become root sudo -s # The installer has already unmounted everything so... # Remount Root Filesystem mount /dev/mmcblkp2p2 /install # Remount EFI Filesystem mount /dev/mmcblkp2p1 /install/boot/efi # Change path cd /install # Prepare for Change Root mount -t proc proc proc/ mount -t sysfs sys sys/ mount -o bind /dev dev/ # Change Root into the Install Base chroot /install/ # These should already be installed by Cnchi. pacman -S grub efibootmgr os-prober # Deploy 32-bit Bootloader grub-install --target=i386-efi --efi-directory=/boot/efi --bootloader-id=Antergos --recheck # Generate a Config grub-mkconfig -o /boot/grub/grub.cfg

Reboot and optionally make a boot entry in the BIOS if it hasn't yet. Also consider telling LightDM not to use a webkit greeter as I got a black screen the moment it started but manually starting an X session is fine.



Verdict: Arch install with a couple of clicks and relatively painless, what's not to like.

Arch Linux: ∞

Arch Linux has been getting the job done since the start of this adventure.



Verdict: You are awaited. You will read eternal, Shiny and Chrome.



Debian: 9.1.3

There are a number of media available from the project. If you want a 64-bit userland you'll still need a 32-bit bootloader. Debian has a solution for this in the form of their "multi-arch" release. Otherwise the i386 release has a 32-bit UEFI bootloader out of the box and just works.



The Debian 9.1.3 release ships with Kernel 4.9.0. This time around I tried to install the system using a WiFi dongle but Debian did not approve of my Raspberry Pi wifi or my Ath9k USB dongle. Not wanting to try my luck with the internal WiFi by adding blobs manually I went with USB Ethernet which was fine.



Verdict: Debian the "universal operating system". Hurray for Debian!



Fedora: Workstation 27

Fedora joins the party in being able to boot 32-bit UEFI systems out of the box. Live sessions work as you'd expect and Anaconda correctly installs the distribution itself with the appropriate bootloader. It's pretty much on cruise control start to finish.



However, it did take me 5 attempts to get the installer going. Anaconda just "hangs" during the disk setup depending on feels. Be patient, 5th time lucky it took half a minute for the installer to move along.



My major gripe is how memory hungry Fedora 27 is overall and how slow / laggy Gnome 3 is. It feels worse then Fedora 26. After startup with Gnome on Xorg, memory use averaged out to 907MB of memory that's almost half of the Venue 8's available RAM. Tumbleweed is doing a much better job here.



Grub to Login startup time averaged to 31.77 seconds. Then add another 16 seconds for your desktop session to start.



Minor gripe number one, my "landscape" view is upside down. Tumbleweed doesn't have this issue. Minor gripe number two, if I tell GDM to lock rotation after login this lock is ignored.



Verdict: +1 for 32-bit UEFI support, Good job Fedora 27.

Fedora: Performance

Grub to GDM, 31.78 Seconds

GDM to Gnome 3 on Wayland, 15.5 Seconds, 935MB

GDM to Gnome 3 on Xorg, 16.4 Seconds, 907MB

GDM to Gnome Classic, 18.2 Seconds, 714MB

GalliumOS: 2.1

GalliumOS bills itself as "A fast and lightweight Linux distro for ChromeOS devices." being based on top of Ubuntu, it offers a Bay Trail optimised release which is what piqued my curiosity.



XFCE + Compton makes for a powerful combination and Kernel 4.12 is available from the testing repository. Meanwhile it's also one of the few distros that deployes zram out of the box for swap rather then the internal storage device.



You can try a straight boot from the Grub command line if you already have a bootloader on your EFI partition:



grub> root=(hd0) grub> configfile (hd0)/EFI/BOOT/grub.cfg

If you've copied your bootloader to the install media try the following change. We edit "linux" to "linuxefi" and "initrd" to "initrdefi". This can also be done on the fly within Grub by pressing "e".

# Original Boot Entry menuentry "GalliumOS Live Image and Installer" { linux /casper/vmlinuz boot=casper file=/cdrom/preseed/galliumos.seed acpi_osi=Linux tpm_tis.interrupts=0 galliumos_hwspec=baytrail gpiolib.acpi_lookup_can_try_crs=1 quiet splash -- initrd /casper/initrd.img } # Updated Boot Entry menuentry "GalliumOS Live Image and Installer" { linuxefi /casper/vmlinuz boot=casper file=/cdrom/preseed/galliumos.seed acpi_osi=Linux tpm_tis.interrupts=0 galliumos_hwspec=baytrail gpiolib.acpi_lookup_can_try_crs=1 quiet splash -- initrdefi /casper/initrd.img }

The installer benefits from having a network connection so installing with a USB ethernet adapter is recommended over relying on only the install media. Without a network connection it will fail to deploy Grub.



Verdict: The live session just works and is very very snappy performance wise, snappier after installing. Speaking of which the installation correctly deployed a 32-bit bootloader upon completion. Alot of love has gone into this and it shows.

openSUSE: Leap 42.3

In the previous update I dismissed Leap with its 4.4 series Kernel but by chance I came upon a thread where Richard Brown, the chairman of openSUSE mentions that there's plenty of backported material in their LTS kernel effectively on par with the 4.10 series.



Here's what is missing:

ath6kl: Missing device ID for Venue 8 WiFi

bytcr: Missing MCLK Parches

i915: Missing DSI pipe patches for boot handover

In short, challenge accepted. Use Jeff's version of the 32-bit UEFI Loader as the Fedora one hangs after loading the init ramdisk.

grub> configfile (hd0,msdos1)/EFI/BOOT/grub.cfg

Ignore the complaints Grub may have and make sure to add "nomodeset" to the kernel command line. You can now install Leap despite the installer looking a little awkward due to the display scaling. It won't install the bootloader for you but will finish everything up correctly. So before you reboot, copy your boot loader from the install media to your EFI partition and add a BIOS entry for it.



Then to boot your system:

grub> linux (hd0,gpt3)/@/boot/vmlinuz nomodeset grub> linux (hd0,gpt3)/@/boot/initrd grub> boot

As promised, the system runs appropriately albeit without modesetting.



One could add a newer kernel from the Kernel Repo to compensate for this or go for Tumbleweed.



Verdict: I have a lot more admiration for openSUSE now.

openSUSE: Tumbleweed

The eternal rolling release with all the latest goodness. Went with the KDE Plasma install which is actually very enjoyable to use on the Venue 8.



The Tumbleweed ISO is 2 parts, 1st part is boot segment, 2nd part is data. Same as Fedora, "linuxefi" and "initrdefi" are used so we'll take the following steps. 32-bit UEFI boot support has been discussed but hasn't shown up yet.

1: (RW) PC EFI

2: (RO) Installer Data

So with that in mind, the following applies:

dd if=openSUSE-Tumbleweed-DVD-x86_64-Current.iso of=/dev/sdX status=progress mkdir /mnt/stick mount /dev/sdX1 /mnt/stick cp /some/src/bootia32.efi /mnt/stick/EFI/BOOT/ # Depending on how well made your bootia32.efi is. find /mnt/stick/EFI/BOOT/grub.cfg -type f -exec sed -i 's/linuxefi/linux/g' {} \; find /mnt/stick/EFI/BOOT/grub.cfg -type f -exec sed -i 's/initrdefi/initrd/g' {} \; umount /mnt/stick

If you are left at the Grub startup prompt try the following, you have tab completion powers.

grub> configfile (hd0,msdos1)/EFI/Boot/grub.cfg

Grub may or may not complain about a couple of things missing but at the minimum you should get a selection menu to start the installer.



From here do as the Romans do. Follow the installer steps and let the installer do its thing. When it's almost done you'll get a polite message:

Execution: /usr/bin/shim-install Error: /usr/lib/grub2/i386-efi/modinfo.sh doesn't exist.

Keep calm and carry on. The installer will still deploy a grub.cfg and the other essentials so when everything is done copy your bootloader onto the eMMC EFI partition and then make a boot entry in the BIOS. Let the good times roll from there.



Verdict: Tremendous!

"32-bit UEFI boot in 64-bit Distro" openFATE #318252

openSUSE: Performance

Tumbleweed effectively uses half the memory Fedora 27, boots faster and feels snappier overall. No idea what GDM is doing but the overhead is rediculous for what is nothing but a session manager. The hand over time from GDM to the chosen session is also slower then SDDM.

Grub to GDM, 26.72 Seconds

Grub to SDDM, 21.72 Seconds

SDDM to IceWM, 2.3 Seconds, 186.5MB

SDDM to Enlightenment 21, 5.35 Seconds, 248MB

SDDM to Plasma on Xorg, 16.92 Seconds, 484MB

SDDM to Gnome 3 on Xorg, 64.59 Seconds, 479MB

GDM to IceWM, 3.35 Seconds, 402MB

GDM to Enlightenment 21, 7.50 Seconds, 492MB

GDM to Plasma on Xorg, 19.65 Seconds, 673MB

GDM to Gnome 3 on Xorg, 16.15 Seconds, 679MB

Ubuntu: 17.10

Before we continue, an honorable mention for "Linuxium" which is an Ubuntu for Bay Trail and Cherry Trail based devices. While I had a mixed experience with it previously I don't feel it warrants its own section any more seeing as how well Ubuntu 17.10 runs out of the box.



Ubuntu 17.10 comes with Kernel 4.13.0.21 and can be booted with Jeff's bootloader or Fedora's bootloader provided you change the boot commands to "linuxefi" and "initrdefi" respectively.



Remember to be connected to the internet during the installation so Ubuntu can install a 32-bit Grub correctly on your behalf. That's all there is to it really.

1: (RO) ISO Data

2: (RW) PC EFI

The ISO when burned to a USB stick will create 2 partitions, the EFI partition is relatively small so we'll make some space by deleting the 64-bit bootloader and copying a 32-bit version on.

dd if=ubuntu-17.10-desktop-amd64.iso of=/dev/sdX status=progress # Bootloader mkdir /mnt/stick mount /dev/sdX2 /mnt/stick rm /mnt/stick/efi/boot/{bootx64.efi,grubx64.efi} cp /some/src/bootia32.efi /mnt/stick/efi/boot/ # Optionally mkdir /mnt/bunty mount /dev/sdX1 /mnt/bunty mkdir -p /mnt/stick/boot/grub/ cp /mnt/bunty/boot/grub/grub.cfg /mnt/stick/boot/grub/ sed -i '1i root=(hd0)' /mnt/stick/boot/grub/grub.cfg # Unmount umount {/mnt/stick,/mnt/bunty}

If you didn't do the optional steps, boot your stick, when in Grub hit "c" and punch commands:

grub> root=(hd0) grub> configfile (hd0)/boot/grub/grub.cfg

Your screen will be dark for a moment or two followed by a familar purple background, just be patient and the live session will boot.



The installer finishes up and provided you are connected to the internet it correctly deploys a 32-bit bootloader which boots properly at the first reboot.



Don't really have any other comments. The new Gnome based environment feels faster then Fedora 27.



Verdict: 64-bit Ubuntu is as Ubuntu does and it does it very well indeed.



Preparing Arch Linux

I'm a big fan of Arch Linux so some things may not apply to your particular flavour of distro. I hope that you may atleast gleam helpful clues from all this.



Before we begin there are a couple of basic requirements:

Your device 90%+ charged.

Highly recommended to update to latest BIOS if you can.

USB Stick to fit Arch ISO.

MicroSD card reader.

OTG USB cable. (Venue 8 Pro)

USB Keyboard / Mouse.

USB Hub. If you're lucky ports on keyboard will suffice.

USB WiFi or USB Ethernet Adapter

MicroSD 16GB and up, if you want to dual boot with Windows.

Patience.

Preparing your install media

Make sure nothing of value is left on your USB stick then download the Arch Linux iso and clone to USB:



dd if=archlinux-2016.12.01-dual.iso of=/dev/sdX bs=4M && sync

Fire up GParted, select your USB storage device.



Right click > Manage Flags, then disable "esp".



This enables the boot partition on the stick to be modified as normally it's mounted read-only.



Eject your stick and re-plug, you can now modify the boot slice.

You'll need a 32-bit UEFI bootloader, there's a couple of options to get that sorted.



The UEFI spec expects the file to be called "bootia32.efi" if you want it to be auto detected. You can have a different name but that will require you to make a seperate boot entry and likely having to manually get Grub going with the internal command line.

Copy "bootia32.efi" to "/{Arch ISO USB}/EFI/boot/"

I've concocted a BayTrail Grub.cfg that has a number of helpful options if you don't feel like manually punching commands as outlined below. This version will fit the "201612" release, in case I don't get a chance to update be sure to search and replace accordingly. Grub will automatically pick it up when copied to the right path.

Rename "baytrail-grub.cfg" to "grub.cfg" Copy "grub.cfg" to "/{Arch ISO USB}/boot/grub/"

Fire up GParted again and renable the "esp" flag for your USB storage device.



Done.

Booting your install media

Disable secure boot

Turn on or restart your device



Press the "Volume Down" button / F2 key to enter the BIOS.



In the "Boot" section, set "Secure Boot" to "Disabled".



Exit and Save Changes



Boot from USB

Turn on or restart your device



Press the "Volume Up" button / "Down Arrow" or "F12" key to enter the "Boot Mode" menu.



Your USB stick should show up as "UEFI: Brand Foo USB"



You can either use the "Volume Up" button to scroll your selection followed by "Volume Down" to acknowledge or use your attached keyboard.



If all is right you'll be greeted by GNU Grub.

Booting your installer, Manually

If you don't have a need for fancy boot menus and are not using the grub.cfg mentioned above this is the process for you.



On the grub command line we must first set a root device:

root=(hd0)

If Grub complains, issue the "ls" command for a list of other sources.



Now we'll tell Grub what to boot, if root is set correctly you get tab complete powers. Keep in mind to match the "archisolabel" accordingly with the volume name of the ISO, here I'm using the December 2016 release.



Protips:

- You have tab-completion powers.

- Get each command perfectly right.



Console in Portrait Mode:

linux /arch/boot/x86_64/vmlinuz archisobasedir=arch archisolabel=ARCH_201612

Console in Landscape Mode:

linux /arch/boot/x86_64/vmlinuz archisobasedir=arch archisolabel=ARCH_201612 fbcon=rotate:1

Init Ramdisks and Boot:

initrd /arch/boot/intel_ucode.img initrd /arch/boot/x86_64/archiso.img boot

If you end up with a black screen after the initial init try adding "i915.modeset=0" or "modprobe.blacklist=efifb" to your kernel flags.

Installing Arch Linux

The December 2016 install media comes with kernel 4.8.11 which technically works well on the Venue Pro 8 but the MicroSD slot won't function out of the box which makes it hard to have your RootFS or home folder there.



Use a MicroSD reader in the interrim and be ready to compile a Kernel to work around bug #150881. Afterwards, with the magic of UUID, swapping the card from reader to internal slot becomes hassle free.



Remember that if you are doing a re-install to clean up your old kernel / initramfs files on the internal EFI partition.



Should you be installing on the internal eMMC you are good to go, this bug doesn't affect you.



If you still run into issues corruption or other issues during installation it may be worth having a look in the Power Management Section for possible clues.

If the deities smiled upon you then your device should be presenting the base Arch environment from which you can commence your installation as per the Beginners Guide.



Take note installing the bootloader is the step that will deviate, as by default it is assumed a 64-bit environment will have a 64-bit bootloader which is a no-go given we are dealing with 32-bit UEFI on the Venue 8 Pro. The Venue 11 Pro has a 64-bit UEFI and is thus fine.



Optionally, if you intend to dual boot you'll have to partition accordingly.



fstab

UUID's and MicroSD cart booting can in some cases anger the kernel.



See what works out best for you. Opt for /dev/mmcblkXpY if your lazy or have issues with UUIDs. UUID is preferred though as MMC device numbering can change.



Kernel 4.4.2 is happy with UUID's

Kernel 4.5rc5 got angry and has to resort to /dev/mmcblk.

Kernel 4.7+ is happy with UUID's again



Use "blkid" or "ls -l /dev/disk/by-uuid" to find your relevant UUID.



#Anonymized Example Data, Don't copy me bro. [root@DellV8 ~]# blkid /dev/mmcblk2: UUID="ea35b5b9-f40d-452d-a3c3-202ac21760b8" UUID_SUB="88259bb5-9001-4eb0-afff-db510e23ceea" TYPE="btrfs" /dev/mmcblk0p1: LABEL="WINRETOOLS" UUID="CE72DF8C72DF5985" TYPE="ntfs" PARTLABEL="Basic data partition" PARTUUID="ec343780-5fe4-4efd-9f3e-3f9186a12705" /dev/mmcblk0p2: LABEL="ESP" UUID="28DF-DE5B" TYPE="vfat" PARTLABEL="EFI system partition" PARTUUID="1e2e38fa-ebbd-4f6c-8b5d-b3dd36f5d850" /dev/mmcblk0p5: LABEL="PBR Image" UUID="12E8577CE8572987" TYPE="ntfs" PARTLABEL="Microsoft recovery pfrtition" PARTUUID="f6e919b1a-15df-4b51-a6d7-f53f843f4479" /dev/mmcblk0: PTUUID="22bcb65f-6194-47a6-b715-50b3c67ffdaa" PTTYPE="gpt" /dev/mmcblk0p3: PARTLABEL="Microsoft reserved pfatition" PARTUUID="ec343780-5fe4-4efd-9f3e-3f9186a12705" /dev/mmcblk0p4: PARTLABEL="Basic data partition" PARTUUID="2f1cd7fc-d51f-85ce-9151-ba195588e852" #Alternatively. [root@DellV8 ~]# ls -l /dev/disk/by-uuid total 0 lrwxrwxrwx 1 root root 15 Oct 5 00:04 12E8577CE8572987 -> ../../mmcblk0p5 lrwxrwxrwx 1 root root 15 Oct 5 00:04 28DF-DE5B -> ../../mmcblk0p2 lrwxrwxrwx 1 root root 13 Oct 5 00:04 ea35b5b9-f40d-452d-a3c3-202ac21760b8 -> ../../mmcblk2 lrwxrwxrwx 1 root root 15 Oct 5 00:04 CE72DF8C72DF5985 -> ../../mmcblk0p1

Dual Booting

For the boot department we'll use the EFI partition from the internal eMMC so there's no need to partition for one on the MicroSD card.



It bears repeating, if you've previously tried to install Linux in any form or have tried other experiments it's a good idea to clean up any old kernels (vmlinuz) or initram disks (initramfs / initrd) files.



A quick "lsblk" provides the clues we need.



[root@DellV8 ~]$ lsblk NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT mmcblk0boot0 179:16 0 4M 1 disk mmcblk0boot1 179:24 0 4M 1 disk mmcblk0rpmb 179:32 0 4M 0 disk mmcblk0 179:8 0 29.1G 0 disk ├─mmcblk0p1 179:9 0 1G 0 part ├─mmcblk0p4 179:12 0 22.3G 0 part ├─mmcblk0p2 179:10 0 500M 0 part ├─mmcblk0p5 179:13 0 5.2G 0 part └─mmcblk0p3 179:11 0 128M 0 part mmcblk2 179:0 0 29.8G 0 disk

Assuming the stock Dell configuration the second partition on the internal eMMC will be 500MB for EFI booting purposes.

mount /dev/mmcblk0p2 /mnt/boot

If you mounted the correct partition the following path should show you the Windows boot manager.

ls /mnt/boot/EFI/Microsoft/Boot

Swap

Why give up valuable space, use zramswap instead.



However, you'll need storage backed swap space if you'd like hibernation to function.



Reminder, BTRFS and swap files means you're gonna have a bad time.



Ext4-fs

You can partition your MicroSD card with a single partition for Linux use as per the guide if you intend to dual boot. Otherwise use your internal MMC as you see fit.

BTRFS

Assuming you are installing to a MicroSD card you can just feed the entire device to BTRFS and forgo partitions. Otherwise, again, do as you would.

Combined with SSD mode + compression it works wonderfully.

# Make btrfs filesystem mkfs.btrfs /dev/mmcblkX # Default zlib, for better compression. mount -o compress /dev/mmcblkX /mnt # Or use lzo, for speed. mount -o compress=lzo /dev/mmcblkX /mnt

Do make sure you install btrfs progs before you mkinitcpio, else you'll get complaints that btrfs.fsck is missing.

pacman -S btrfs-progs

Wireless

If you'd like to use "wifi-menu" you'll need a some extras.

pacman -S dialog wpa_supplicant

Deploying the bootloader

There may be some angry diagnostic output, don't worry but do pay attention.

pacman -S grub efibootmgr os-prober grub-install --target=i386-efi --efi-directory=/boot --bootloader-id=ArchLinux --recheck grub-mkconfig -o /boot/grub/grub.cfg

Power Management 3.0

It's been a long wait and an interesting journey but with Kernel 4.12 in hand we're actually in a very good place.



See the Kernel's System Power Management Sleep States documentation for additional background information.

Battery

pacman -S acpi acpi -V

As long as your battery is reporting for duty then capacity and charge status are correctly reported.



"Disappearance" Fix

TL;DR: Missing Battery? Suspend your device and patiently wait for your battery to drain.



Some time ago my Venue 8's battery decided to disappear, updating the BIOS brought it back and then a month later it disappeared again. Trying a forced reflash of the BIOS did not result in any change.



Now to clarify the battery itself still remains functional but the charging light gives no feedback (no white or orange colour) and software is unable to report any details such as charging status or charge level. Running the onboard diagnostics will show you there's something there but all the values are incorrect.



One characteristic of this "confused" power state is that the Venue 8 will turn on immediatly when pressing the power button where as under normal circumstances powering on requires a good 2 second press of the button. My theory is that in this instance it's almost like the power manager has a variable stuck where the tablet thinks it's always left in a stand-by state and it is never cleared. Because of this stand-by state it assumes it has a battery but never checks it exists and thus nothing is reported.



While I was testing suspend I forgot to keep track of time and thus drained the battery flat. Initially the Venue 8 refused to power on or show any signs of life but after leaving the charger connected for a couple of minutes the charging status light came on white which was a very promising sign.



I left the unit to charge for half an hour after which it turned on fine again. Booting into the system confirmed that things had turned back to normal and with an over night charge the system reported a full battery and a 9 hour possible run time.



Charging

A good 2A USB power supply is recommended. The charger block from the Venue 11 is also compatible.



You'll get the fastest charge rate when connected directly about ~1.49A, if you're charging via an OTG cable try to limit your connected USB devices. Your charge rate can easily drop to less then 0.5A when you have a USB hub + bits connected which effectively means your battery won't charge much at all whilst using your device.

Stability

Each new Kernel has progressively improved the stability of the Venue 8. Initially I was lucky to get an hour of uptime and at the very worst constant freezes, fast forward to the present and using the device for an entire day with few surprises is now achievable.



I've not had any issues with filesystem corruption since Kernel 4.7 and the slight performance drop that showed up around Kernel 4.9 seems to have been mitigated.



On AC power I've managed to get to 2 days and 7 hours straight, on battery as much as 10 hours and 33 minutes (2 Cores, audio streaming and light browsing) with randomly connecting the charger to see if it would upset things.



There seems to be some correlation with having removed and reinstated the ath6kl kernel modules. A number of days prior I had a full lock up some hours after an rmmod cycle after about a days worth of uptime.



The USB OTG port is still a weird creature. Using a powered OTG cable you can safely plug and unplug from both the Venue port or the OTG cable end. Unpowered it does not appreciate any plug and unplug activities on the Venue side, causing the system log to overflow with ACPI errors, but you can safely do things on the OTG cable end.

Suspend (4.12+)

echo "freeze" > /sys/power/state systemctl start systemd-sleep.service

With Kernel 4.12 suspend now operates correctly. The device will resume when either the "meta" button near the headphone jack or the power button is pressed. The volume buttons will not wake the device. Likewise any USB attached keyboard or mice will not wake it either.



Only niggles I've found sofar is that sound doesn't always re-initialize right if you had an audio source playing. Stopping any playback before suspend negates this issue. Plugging in a USB device may or may not anger it depending on your OTG cable situation.

Surprisingly Wifi is very well behaved and has sofar been reconnecting on resume.



I've done a test run of 3 days with 22 suspend / resume cycles without issue. During this I've kept an eye on the battery discharge rate and it averages out to about 2% per hour of stand by.



Hibernate

echo "disk" > /sys/power/state systemctl start systemd-hibernate.service

Kernel 4.12 delivers. Looks good overall. Wifi and Audio continue working correctly.

Suspend + Hibernate

systemctl start systemd-hybrid-sleep.service

Hibernate vs Suspend + Hibernate doesn't seem to have much performance difference at first glance but it works as per the above.

TuxOnIce

TuxOnIce is an alternative sub-system for hibernation that offers a more compelling feature set then the stock mainline sub-system does. (The author's webpage seems to be under construction at the moment so a wayback machine link is provided, alternatively see Wikipedia).



Tried to compile the latest git release but no luck today.



ToDo: Experiment more another day.

SDHCI ACPI

Previously one had to toggle certain power states, doesn't seem to matter on Kernel 4.12+



Power Adapter Check

I use this when testing so it disables things immediately upon boot when running from battery power.



I can confirm acpid sees "ac_adapter" and "battery" events which paves the way for automation. But this will suffice for now.

#!/bin/bash if [ -f /sys/class/power_supply/ADP1/online ] then ADP=`cat /sys/class/power_supply/ADP1/online` fi if [ "$ADP" -ne "1" ] then #Disable cores, turn off turbo, etc. fi

i915 / DRM

The Intel GPU kernel driver has a number of options that can be tried.

enable_rc6=1, does not seem to offer improvement.

enable_fbc=1, does not seem to offer improvement.



drm.vblankoffdelay=1, seems to save 0.05 - 0.09 watts when added to the kernel command line.

System Devices

Power Management can be enabled on i2c devices to save a little more. While PowerTop has an auto pilot I'm not sure if I want to trust it at present so we pass some selective flags. Saving up to another 0.4 watts.

#!/bin/bash #Observed from PowerTop. #Kernel echo '0' > '/proc/sys/kernel/nmi_watchdog' echo '1500' > '/proc/sys/vm/dirty_writeback_centisecs' #Intel Atom Power Control Unit echo 'auto' > '/sys/bus/pci/devices/0000:00:1f.0/power/control' #Intel Atom SoC Transaction Register echo 'auto' > '/sys/bus/pci/devices/0000:00:00.0/power/control' #Intel Atom Trusted Execution Engine echo 'auto' > '/sys/bus/pci/devices/0000:00:1a.0/power/control' #Intel Atom USB xHCI echo 'auto' > '/sys/bus/pci/devices/0000:00:14.0/power/control' #Suspecting main intel i2c. #Seems to trigger PM for all i2c devices and Atom GPU + Display. #The i2c reference can change, adjust accordingly. echo 'auto' > '/sys/bus/i2c/devices/i2c-9/device/power/control'

Power Monitoring

You can install "powertop", but powertop can be slow in refreshing the overall battery discharge rate. However, we can ask the kernel these things combined with a little math. Keep in mind you'll need to disconnect your power adapter to get a correct output.



#/bin/bash #Usage: watch -n 1 ./watts.sh V=`cat /sys/class/power_supply/BATC/voltage_now` A=`cat /sys/class/power_supply/BATC/current_now` ((P1 = $A * $V)) P2=`echo "$P1 / 1000000000000" | bc -l` printf "Current discharge rate of " printf %.2f $(echo $P2) printf " Watts.

"

Disable CPU Cores

I tend to live in shells most of the time so I don't need quad core power. Additionally, this saves about 0.2 watts in energy.



There was once a "sched_mc_power_savings" option but this seems missing after kernel 3.4 which was responsible for minimizing the number of cores used so idle cores could sleep in full. Meanwhile I'm curious as to why the P-State driver is not turning cores off.



In lieu of this, we force cores offline which achieves a "similar effect".

#!/bin/bash #Disable unneeded cores. echo 0 > /sys/devices/system/cpu/cpu1/online echo 0 > /sys/devices/system/cpu/cpu2/online echo 0 > /sys/devices/system/cpu/cpu3/online

#!/bin/bash #Enable all cores. echo 1 > /sys/devices/system/cpu/cpu1/online echo 1 > /sys/devices/system/cpu/cpu2/online echo 1 > /sys/devices/system/cpu/cpu3/online

C-State Tweaking

There is still bug #109051 but the Venue 8 seems very well behaved now.

P-State Tweaking

Set a maximum CPU frequency.

FYI, can cause i2c to complain in rare circumstances.

#Set maximum frequency to 500Mhz cpupower frequency-set -u 500MHz #Set maximum frequency to 1.84Ghz cpupower frequency-set -u 1.84GHz

Disable turbo state which can save up to another 0.8 watts of energy.

The CPU is also likely to generate less heat.

#!/bin/bash #Disable Turbo (no_turbo is true) echo 1 > /sys/devices/system/cpu/intel_pstate/no_turbo

#!/bin/bash #Enable Turbo (no_turbo is false) echo 0 > /sys/devices/system/cpu/intel_pstate/no_turbo

CPU Governor

Bay Trail CPU's are classified as being friends with the Sandy Bridge architecture and Intel recommends the "ondemand" governor for best results.



However, to minimize heat you can consider using "powersave" instead. Either you can set it on the command line or you can set it as a default when compiling the kernel.

cpupower frequency-set -g powersave

Disable WiFi

WiFi eats up to 0.25 watts of energy. Without a bluetooth keyboard in use this is a practical measure at the moment.

#!/bin/bash #Load WiFi kernel modules modprobe ath6kl_core modprobe ath6kl_sdio

#!/bin/bash #Remove WiFi kernel modules rmmod ath6kl_sdio rmmod ath6kl_core

Wattage

Based on Kernel 4.4 we started out originally around the 2.3 Watts mark, with tweaks applied we get the following.



Wifi off, XFCE: 1.15 Watts.

Wifi off, TTY: 1.12 Watts.



Power Sipping

Fun fact, a USB Mouse / KB dongle eats between 0.20 - 0.24 watts you can try and see if USB autosuspend works for you.



Your choice of wallpaper and UI theme can impact power use. Likewise your choice of application can impact power use. Visible applications that have interface elements that constantly refresh, for example the visualizer in Audacious can eat 0.2 watts. Simply hiding it becomes instant savings.



ToDo: New table with facts.



Wayland

Fedora 27, Gnome on Wayland

As per title, this is the shipping default. Screen rotation works as does touch input. So far so good.



If you are using MPV for media playback it will by default run in XWayland which doesn't play well with VA-API for hardware accelerated decoding.



The following switches offer a solution to this.

# MPV says: # "va_getDriverName() failed with unknown libva error, driver_name=(null)" # MPV native Wayland. (Decoder > GPU mem) mpv --opengl-backend="wayland" --hwdec="vaapi" /foo/bar.mkv # MPV through XWayland. (Decoder > System mem > GPU mem) mpv --hwdec="vaapi-copy" /foo/bar.mkv

Weston

Do not my friends expect alot of excitement here, it is still early days but we have a little progress since last time.



"libinput" shows touch capabilities for the digitizer and the "weston-simple-touch" demo confirms multi-touch magic when running under Weston. The same demo under Sway seems broken at this time. Mouse input is obviously fine in both lands.



For now a traditional X11 environment is more fruitful.

Mouse, Multi-touch input!

Pen?

Weston can rotate now with a config flag.

Sway: Rotation is not currently supported.

# Weston in landscape # ~/.config/weston.ini [output] name=DSI-1 transform=90

X.org

Intel Hardware

I've had little difficulty with the framebuffer overall since the start of this journey and you have two options to explore. You can use KMS or the Intel Graphics driver.

Xorg Essentials

pacman -S xorg-server xorg-xinit xorg-xinput xorg-xrandr

Input Devices

#Option 1, libinput is the future: pacman -S xf86-input-libinput #Option 2, tried and tested: pacman -S xf86-input-evdev

VA-API / Hardware Video Decoding

pacman -S libva-intel-driver mesa vdpauinfo

We can save battery by using the onboard H264 video decoder by deploying VA-API support. Combined with a supported player it means 5% cputime on a single core vs eating up 4 cores at XY% cputime.

ModeSetting

Using the KMS driver works fine, comes with Glamor and uses DRI2 by default.

#/etc/X11/xorg.conf.d/20-intel.conf Section "Device" Identifier "Intel Graphics" Driver "modesetting" EndSection

Intel DDX

pacman -S xf86-video-intel

If you want to enable Glamor, DRI3 and TearFree rendering, use the following config. Be advised the overall stability of all options combined is up in the air at present. Remember, only one "AccelMethod" at a time.



SNA (default) with TearFree enabled looks and feels great with no tearing.

Glamor uses slightly less power at approximately 0.01 Watt vs SNA.



Feel free to experiment with the config below.



Note: "TearFree" only works with SNA. Should not be needed with DRI 3 enabled.

#/etc/X11/xorg.conf.d/20-intel.conf Section "Module" Load "glamoregl" EndSection Section "Device" Identifier "Intel Graphics" Driver "Intel" Option "AccelMethod" "glamor" # Option "AccelMethod" "uxa" # Option "AccelMethod" "sna" Option "DRI" "3" # Option "TearFree" "true" EndSection

Xrandr

The "RandR" (Resize and Rotate) protocol is what allows for rotating the desktop as well as changing resolutions. It is also helpful in setting your scaling factor to keep everything reading by way of changing the DPI level. At this point in time it's normal if the screen stays black for a brief period as Xorg does its thing.



This tends to occur if you rotate in any direction that is not 180 degrees (mirrored) to your current setting.



This behaviour happens both with the Modesetting and Intel Xorg Driver.

Instant Change

Normal > Inverted

Inverted > Normal

Left > Right

Right > Left

Delayed Change

Normal, Inverted > Left, Right

Left, Right > Normal, Inverted

Commands

xrandr --screen 0 -o left xrandr --screen 0 -o right xrandr --screen 0 -o inverted xrandr --screen 0 -o normal

ToDo: Add DPI explaination. Default is pretty reasonable though.

Window Manager: XFCE

Let's install XFCE and not care for LightDM / MDM etc.

pacman -S xfce4 xorg-xinit echo "exec xfce4-session" > ~/.xinitrc startx

Window Manager: Enlightenment

Let's install Enlightenment. If you're happy to use your fingers, pen or keyboard to work the UI, it's decent.

pacman -S enlightenment terminology xorg-xinit echo "exec enlightenment_start" > ~/.xinitrc startx

Window Manager: Openbox

Let's install Openbox, if you feel adventurous.

Protip: learn about your .xprofile



pacman -S openbox openbox-themes obconf tint2 echo "exec openbox-session" > ~/.xinitrc startx

Pen Input

OpenTTD is hard to play without a "right mouse" button. By default Button 1 (bottom click) is mapped to "left" and Button 2 (upper click) to "middle".



Button 1 is shared with the pen tip so we seem to loose "left click" on the tip if we change it, Button 2 can be freely changed to right click.



Be advised, some may consider Pen Input somewhat sensitive.

xinput set-button-map "SYNA7500:00 06CB:00F2 Pen" 1 3 2 4 5

Rotation (Venue 8 Pro)

A modified rotation script based on the T100 version by John allows us to set the touch input, pen input and screen rotation appropriately but we are dependent on parsing the output of xinput and xrandr.

#!/bin/bash TOUCHSCREEN=`xinput | grep SYNA7500 | grep -v Pen | cut -f2 | cut -d= -f2` PEN=`xinput | grep SYNA7500 | grep Pen | cut -f2 | cut -d= -f2` CURR_ROT=`xrandr -q --verbose | grep DSI | cut -d" " -f 5` if [ "$CURR_ROT" == "normal" ]; then ROT_TO="right" SWAP_TO="1" INV_TO="0, 1" elif [ "$CURR_ROT" == "right" ]; then ROT_TO="inverted" SWAP_TO="0" INV_TO="1, 1" elif [ "$CURR_ROT" == "inverted" ]; then ROT_TO="left" SWAP_TO="1" INV_TO="1, 0" else ROT_TO="normal" SWAP_TO="0" INV_TO="0, 0" fi xrandr --screen 0 -o $ROT_TO xinput set-int-prop $TOUCHSCREEN "Evdev Axis Inversion" 8 $INV_TO xinput set-int-prop $TOUCHSCREEN "Evdev Axes Swap" 8 $SWAP_TO xinput set-int-prop $PEN "Evdev Axis Inversion" 8 $INV_TO xinput set-int-prop $PEN "Evdev Axes Swap" 8 $SWAP_TO

Add a desktop icon for seasoning.

#/home/user/Desktop/ [Desktop Entry] Name=Rotate Comment=Rotate the screen Keywords=rotate;screen; Exec=/path/to/rotate-script.sh Terminal=false Type=Application Icon=rotation-allowed-symbolic StartupNotify=true Categories=System;

For me personally, my desktop is already set in landscape and I just want the input rotated 90 degrees.

#!/bin/bash TOUCHSCREEN=`xinput | grep SYNA7500 | grep -v Pen | cut -f2 | cut -d= -f2` PEN=`xinput | grep SYNA7500 | grep Pen | cut -f2 | cut -d= -f2` CURR_ROT=`xrandr -q --verbose | grep DSI | cut -d" " -f 5` #XFCE, Openbox if [ "$CURR_ROT" == "right" ]; then SWAP_TO="1" INV_TO="0, 1" fi #Enlightenment if [ "$CURR_ROT" == "(0x47)" ]; then SWAP_TO="1" INV_TO="0, 1" fi xinput set-int-prop $TOUCHSCREEN "Evdev Axis Inversion" 8 $INV_TO xinput set-int-prop $TOUCHSCREEN "Evdev Axes Swap" 8 $SWAP_TO xinput set-int-prop $PEN "Evdev Axis Inversion" 8 $INV_TO xinput set-int-prop $PEN "Evdev Axes Swap" 8 $SWAP_TO

Firmware

Atheros 6K / Dell 1538 wireless

For wifi to work we need a newer release of the ath6kl firmware then is currently shipped in the Linux firmware package.



Qualcomm has these in their ath6kl firmware repo.

The AR6004 folder sits in /lib/firmware/ath6k/ on your filesystem.

Bay Trail SST Audio

Bay Trail SST Audio firmware is included by default.

The Intel folder sits in /lib/firmware/intel/ on your filesystem.



For reference, the intel firmware repo may have updated versions available if you run into difficulties.

ALSA

Bay Trail audio is a very odd beast. Weird mixers, everywhere...



ToDo: Scope ALSA Compress API and TinyCompress

Getting Started

pacman -S alsa-utils pulseaudio

Straight ALSA works but the overall experience is better with PulseAudio as it will make it easier to switch between headphones and speaker output as well as having input controls to toggle between device microphone or your headset microphone.



You may want to blacklist "snd_hdmi_lpe_audio" to keep things happy. - Thanks J-M!



Can confirm automatic sensing of a headphone jack being present works on recent Kernels. (5.6+)



Use Case Manager

This may still be the case on older distros, this is a legacy item at this point



For ALSA to properly configure the hardware we need a set of "Use Case Manager" files which help ALSA understand how the hardware works and what the correct default initialisation state should be.



I've had success using the "bytcr-rt5640" UCM data from Pierre's GitHub.

cp -rf bytcr-rt5640 /usr/share/alsa/ucm

Copy these in place as directed and just to be safe remove your current ALSA state file if present.



rm /var/lib/alsa/asound.state

Proceed to reboot to activate the UCM data and regenerate the state file. You should now have sound.



PulseAudio

pacman -S pulseaudio pavucontrol

Works, if you are so inclined. Out of the box resampling will cause CPU time overhead but fortunately we have ways of controlling this.

pulseaudio --dump-resample-methods

This command will show you all supported resampling methods from "cheapest" to most "expensive" CPU wise. Pick and then apply your choice pending on personal preference. "trivial" is the cheapest in my case and "soxr-vhq" the dearest. Make sure to uncomment the option.



#/etc/pulse/daemon.conf resample-method = trivial ; enable-remixing = yes

After this change make sure to either kill the daemon or restart.



Side Note, to see the configured output sample rate:

This: pacmd list-sinks | grep sample Returns: sample spec: s16le 2ch 48000hz

Speakers / Headphone Toggling

Something changed in 4.12.x that causes audio to fall completely silent when you try to change outputs. In some cases I've had the kernel refuse to detect audio exists afterwards and had to manually modprobe.



You can bypass Pulseaudio's management with ease.

#In alsamixer #Mute "Speaker Channel" #Unmute "Headphone" (at start), "HP Channel", "HP L", "HP R" #Volume control "HP" (slider)

Then reverse inverse steps to go back to speaker, or you can have both on if you so please.

48Khz or Bust

Keep in mind that most sources will output 44.1 Khz and in order for audio to come out at 48Khz you're dealing with resampling which can in some instances eat a fair chunk of CPU time.



If you're using Pulseaudio it will take care of this on your behalf and this can be tweaked. If you are using pure ALSA then Audacious and MPD offer a number of ways you can configure resampling it's worth taking a moment to scope it as it can impact battery life.



I tried to find a 44.1Khz firmware, looking at the original ASOC patch there may have been one but only the 48Khz one exists in the official repo.



48Khz technically makes more sense though, 44.1Khz is a compact disc mastering hold over.

Hardware Buttons

As per the kernel compiling notes, the physical buttons on the side and top of the Venue 8 are dependent on 2 kernel modules to function correctly: soc_button_array and gpio_keys.



For the Venue 11 only soc_button_array is needed.



By default the mappings are thus:

Power - ACPI power button.





Volume Up

- XF86AudioLowerVolume

- X11: Keycode 123

- TTY: keycode 115





- XF86AudioLowerVolume - X11: Keycode 123 - TTY: keycode 115 Volume Down

- XF86AudioRaiseVolume

- X11: Keycode 122

- TTY: keycode 114





- XF86AudioRaiseVolume - X11: Keycode 122 - TTY: keycode 114 Meta, "home" button with branding.

- Super_L

- X11: Keycode 133

- TTY: keycode 125

Power Button

While under Xorg the power button behaviour will depend on how your desktop environment is configured. On the console we can disable the default behaviour by changing the following:

#/etc/systemd/logind.conf HandlePowerKey=ignore

Volume Keys

With Xbindkeys we can map the volume buttons to do our bidding. You can find the PulseAudio variant on the Arch Wiki the following is for straight ALSA on Kernel 4.4.2.

#Increase Volume "amixer sset DAC1 5%+" m:0x0 + c:123 XF86AudioRaiseVolume #Lower Volume "amixer sset DAC1 5%-" m:0x0 + c:122 XF86AudioLowerVolume

GPIO reference

$ cat /sys/kernel/debug/gpio GPIOs 338-381, platform/INT33FC:02, INT33FC:02: gpio-16 (power ) in hi pad-8 offset:0x080 mux:1 fall rise GPIOs 410-511, platform/INT33FC:00, INT33FC:00: gpio-4 (volume_down ) in hi pad-99 offset:0x630 mux:0 fall rise up 20k gpio-5 (volume_up ) in hi pad-102 offset:0x660 mux:0 fall rise up 20k gpio-6 (home ) in hi pad-98 offset:0x620 mux:0 fall rise up 20k # works out to gpio354, gpio414, gpio415, gpio416

Fun with Industrial I/O

Sensors sit on the i2c bus and with Kernel 4.12+ it appears they initialize all the time now where as with pevious Kernels it would be luck of the draw.



If you struggle to see any IIO devices do a warm reboot on 4.4.0+ or a cold reboot / power down on 4.7.0+.



All the sensors get a new device / trigger number every time the kernel is started so don't make assumptions.



Hello Sensors

Meanwhile I fabricated a little script that talks to all the raw outputs and puts them into neat columns as shown in the screenshot.



#!/bin/bash # This scripts reads the various HID IIO Sensors. # Ex. usage: watch -n 0.2 './poll_iio.sh' # Device numbering changes every time things are initialized. # Little crude use of grep and cut. awk or sed could be nicer. iio_als=`cat /sys/bus/iio/devices/trigger*/name | grep als | cut -d '-' -f 2 | cut -c 4` iio_rot=`cat /sys/bus/iio/devices/trigger*/name | grep rotation | cut -d '-' -f 2 | cut -c 4` iio_gyro=`cat /sys/bus/iio/devices/trigger*/name | grep gyro | cut -d '-' -f 2 | cut -c 4` iio_magn=`cat /sys/bus/iio/devices/trigger*/name | grep magn | cut -d '-' -f 2 | cut -c 4` iio_accl=`cat /sys/bus/iio/devices/trigger*/name | grep accel | cut -d '-' -f 2 | cut -c 4` iio_incl=`cat /sys/bus/iio/devices/trigger*/name | grep incli | cut -d '-' -f 2 | cut -c 4` # Ambient Light Sensor als=`cat /sys/bus/iio/devices/iio\:device$iio_als/in_intensity_both_raw` # Rotation, doesn't seem to do much on Venue 8. rot=`cat /sys/bus/iio/devices/iio\:device$iio_rot/in_rot_quaternion_raw` # Gyro gyro_x=`cat /sys/bus/iio/devices/iio\:device$iio_gyro/in_anglvel_x_raw` gyro_y=`cat /sys/bus/iio/devices/iio\:device$iio_gyro/in_anglvel_y_raw` gyro_z=`cat /sys/bus/iio/devices/iio\:device$iio_gyro/in_anglvel_z_raw` # Magnetometer magn_x=`cat /sys/bus/iio/devices/iio\:device$iio_magn/in_magn_x_raw` magn_y=`cat /sys/bus/iio/devices/iio\:device$iio_magn/in_magn_y_raw` magn_z=`cat /sys/bus/iio/devices/iio\:device$iio_magn/in_magn_z_raw` magn_n=`cat /sys/bus/iio/devices/iio\:device$iio_magn/in_rot_from_north_magnetic_tilt_comp_raw` # Accelerometer accl_x=`cat /sys/bus/iio/devices/iio\:device$iio_accl/in_accel_x_raw` accl_y=`cat /sys/bus/iio/devices/iio\:device$iio_accl/in_accel_y_raw` accl_z=`cat /sys/bus/iio/devices/iio\:device$iio_accl/in_accel_z_raw` # Inclinometer incl_x=`cat /sys/bus/iio/devices/iio\:device$iio_incl/in_incli_x_raw` incl_y=`cat /sys/bus/iio/devices/iio\:device$iio_incl/in_incli_y_raw` incl_z=`cat /sys/bus/iio/devices/iio\:device$iio_incl/in_incli_z_raw` # Awkwardly formatted printf to prepare output for column. printf " Gyro, Accel., Magneto, Inclino, ALS, Rotation

-----------,----------,-------------,----------,---------,------------

X: $gyro_x, X: $accl_x, X: $magn_x, X: $incl_x, L: $als, R: $rot

Y: $gyro_y, Y: $accl_y, Y: $magn_y, Y: $incl_y, ,

Z: $gyro_z, Z: $accl_z, Z: $magn_z, Z: $incl_z, ,

, , N: $magn_n, , " | column -t -s ',' # -- END --

Manual Exploration

# Find our sensors and device numbers. cat /sys/bus/iio/devices/trigger*/name # Results als-dev0 magn_3d-dev1 dev_rotation-dev2 gyro_3d-dev3 accel_3d-dev4 incli_3d-dev5 # Find specific sensor grep -rn "als" /sys/bus/iio/devices/iio*/name # Result /sys/bus/iio/devices/iio:device0/name:1:als

Read out the ambient light sensor

# Shine a light on the device. Bright light value of 1500+. watch -n 0.2 'cat /sys/bus/iio/devices/iio\:device0/in_intensity_both_raw'

Read out magneto meter

watch -n 0.2 'cat /sys/bus/iio/devices/iio\:device1/in_rot_from_north_magnetic_tilt_comp_raw'

iwup.py - Is Wireless UP

About

You can find the full backstory and annotated source within the Python file itself. In short this tool will reload the ath6kl_sdio kernel module that powers the Venue 8 internal WiFi when WPA supplicant detects a connection drop. I've been using this myself since July '17 and been since polishing it to a point where I felt comfortable releasing it into the wild.



It may not be a perfect solution but atleast the connection drop stays short enough for my shells to stay connected.



The Python D-Bus module is realistically the only dependency you will need to install prior to use. It is assumed you are already joined to a network at the moment. Don't forget to chmod +x when you're ready.

Download

iwup.py - v1.2

Runtime Output

WPA D-Bus Bot v1.2 [%] No interface specified, assuming wlan0. [%] No module specified, assuming ath6kl_sdio. [#] Subscribed to 'PropertiesChanged' on NetworkManager. [#] Updating D-Bus Paths. [-] 16:12:36 [#] Path : /fi/w1/wpa_supplicant1/Interfaces/15 [#] Net : /fi/w1/wpa_supplicant1/Interfaces/15/Networks/0 [#] SSID : "SuperSmashTV" [#] Subscribed to 'PropertiesChanged' on WPA Supplicant. [-] 16:32:52 [!] - Disconnect Detected - [!] DeAuth, Reloading kmods. [-] 16:32:52 [#] modprobe: Phase 1, Removed module 'ath6kl_sdio'. [#] modprobe: Phase 1, Adding module 'ath6kl_sdio'. [#] modprobe: Phase 2, Confirming... [@] modprobe: Procedure complete. [-] 16:32:52 [!] - Interface Disabled... [-] 16:32:58 [#] NM Connectivity State: 4 [#] Updating D-Bus Paths. [-] 16:32:58 [#] Path : /fi/w1/wpa_supplicant1/Interfaces/17 [#] Net : /fi/w1/wpa_supplicant1/Interfaces/17/Networks/0 [#] SSID : "SuperSmashTV" [#] Subscribed to 'PropertiesChanged' on WPA Supplicant.

Wireless .alt.venue8

USB Dongles

Cheap and effective until the internal WiFi behaves as you'd expect. I've used the following dongles extensively without issues.

- RaspberryPi Wifi Dongle, Broadcom BCM43143 - Unbranded Pigtail, Ralink RT5390 - Nintendo Wi-Fi USB, Buffalo RT2570

Android Tethering

Ref: Arch Wiki: Android Tethering

A non-nerfed Android phone should be able to bridge WiFi to USB. I had success with an HTC One running Cyanogen 12.



See: Settings > Wireless & Networks > More > Tethering & portable hotspot > USB tethering.



When toggled the HTC phone changes it's USB identifier and the RNDIS kernel module kicks in.



The only downside to this method is that the phone will be charging from the tablet battery which is less then ideal. I tried a data-only USB cable but nothing is triggered unless there's power present.



If you have full root on your Android device you may have a chance at disabling the charger input by either using a terminal app or ADB. The following is specific to the HTC one and may not apply to other models but maybe it helps you in the right direction.



Keep in mind that depending on your UX that even with charging turned off your battery icon may still indicate it is charging. The best indentifier in my case is the status light as that will turn on and off depending on what the charger control is actually set at.

# Note: This was done via ADB which is part of the "android-tools" package. # sysfs Charge Controls root@evita:/sys/class/power_supply/battery # ls -l char* --w--w---- root root 4096 2016-08-15 23:33 charger_control --w--w---- root root 4096 2016-08-15 22:24 charger_timer -r--r--r-- root root 4096 2016-08-15 22:24 charging_enabled -r--r--r-- root root 4096 2016-08-15 22:24 charging_source # Disable charging, status light turns off. root@evita:/sys/class/power_supply/battery # echo 0 > charger_control root@evita:/sys/class/power_supply/battery # cat charging_enabled 0 # Enable charging, status light turns on. root@evita:/sys/class/power_supply/battery # echo 1 > charger_control root@evita:/sys/class/power_supply/battery # cat charging_enabled 7

iPhone Tethering

Ref: Arch Wiki: iPhone Tethering

An iPhone will only do mobile data tethering as WiFi is automatically used as a hotspot thus negating the possibility of making a WiFi-bridge.



An iPhone modded with a form of jailbreak may be able to control charging but I don't have a spare iDevice to test this.



Wireless "ath6kl"

Work in Progress: 4.14, still bag of hurt.

Getting WiFi to work

WiFi is based on the Qualcomm Atheros AR6004 series. While the driver has been in the kernel for quite some time the device ID for the Dell Wireless 1538 has arrived in Kernel 4.9 negating the need for manual patching. The Venue 11 Dell Wireless 1537 is still up in the air at this point in time.



Read the Firmware Section for blobs.

Read the Kernel Compiling Section to get things to work.



Optionally add iwup.py into the mix.



Getting WiFi to connect

Before you do anything with your wifi at all:

echo "on" > /sys/bus/platform/drivers/sdhci-acpi/INT33BB:00/power/control

Without power management disabled the card will either not work, not join an AP, connect but have 1000ms+ latencies, crash it's firmware or show other weird behaviour.



You can also try to disable wireless power management but I didn't see any change.

iwconfig wlan0 power off

TL;DR; Have constant traffic of some form going to "keep it going".

Having a flood ping on a seperate TTY generating 8 - 20KB/sec of traffic is a terrible but functional hack.



ping -f 192.168.x.x

A flood ping combined with Kernel 4.11.1 has given 1 Day, 9 hours, 31 minutes of wifi connectivity before dropping. Interestingly in this instance I did not have to remove the ath6kl module I could just rejoin the AP and continue on my way.



On kernel 4.8.0, courtesy of audio fixes, I noticed an interesting observation that connecting to an access point from cold-boot and streaming radio non-stop (~64kbit stream) I've been able to stay connected for as long as 5 hours and 47 minutes.



Wireless then mysteriously dies, on occasion I have to rmmod / modprobe twice in a row and then it stays up again from anywhere to 50 minutes to 2 hours while streaming. On one rare instance Wireless refused to come to the party at all and a reboot was required. Having a charger connected or not doesn't seem to make a difference.



(New record on the 7th of October: From cold boot, 8 hours and 13 minutes with 22% battery left.)



I suspect just enough traffic prevents any deep sleep modes as with non-stop ICMP traffic to a random host on the LAN wireless still dies after the ~35 minute mark. Earlier kernels may exhibit similar behaviour. We have learned new clues.



Meanwhile under low traffic use cases, you may now enjoy 35 (4.7.0 and newer) - 45 (4.4.0) minutes of connectivity before you have to rmmod and modprobe the ath6kl module again. Failing to follow the rmmod procedure has a chance to cause a kernel to panic if you attempt to rejoin your access point.



#!/bin/bash rmmod ath6kl_sdio rmmod ath6kl_core

#!/bin/bash modprobe ath6kl_core modprobe ath6kl_sdio

How WiFi fails

Without debugging enabled you'll find multiple "failure" notices when the interface goes down. A debug mode example can be found further down. It doesn't really matter if you're idling, doing small ICMP packets or pushing full bandwidth transfers.

[7910.515323] ath6kl: wlan disabled [7910.515557] ath6kl: wlan disabled [7910.516008] ath6kl: wlan disabled

Thought: I'm entertaining a theory that maybe WPA key changes is what confuses it.

Testing Complete: Open (non-encypted) mode or WPA mode make no difference.



MMC debug mode

It may help to make the kernel diagnostic buffer larger. Passing "log_buf_len=32M" will allow for such things given the potential for verbosity.



MMC debugging was enabled for this portion and at the end we rmmod the relevant modules. It appears the interrupt is disabled for unknown reasons.



FYI, "mmc0: Too large timeout requested!" is harmless.

[ 2683.960730] sdhci [sdhci_irq()]: *** mmc1 got interrupt: 0x00000003 [ 2683.960750] mmc1: req done (CMD53): 0: 00001000 00000000 00000000 00000000 [ 2683.960756] mmc1: 24 bytes transferred: 0 [ 2683.960775] ath6kl: failed to get pending recv messages: -125 [ 2683.960780] ath6kl: host is going to stop blocking receiver for htc_stop [ 2683.960788] mmc1: starting CMD53 arg 94083004 flags 000001b5 [ 2683.960794] mmc1: blksz 4 blocks 1 flags 00000100 tsac 1000 ms nsac 0 [ 2683.960815] sdhci [sdhci_irq()]: *** mmc1 got interrupt: 0x00000003 [ 2683.960829] mmc1: req done (CMD53): 0: 00001000 00000000 00000000 00000000 [ 2683.960834] mmc1: 4 bytes transferred: 0 [ 2683.960862] SDIO: Disabling IRQ for mmc1:0001:1... [ 2683.962059] sdhci [sdhci_irq()]: *** mmc1 got interrupt: 0x00000003 [ 2683.962076] mmc1: req done (CMD53): 0: 00001000 00000000 00000000 00000000 [ 2683.962082] mmc1: 4 bytes transferred: 0 [ 2683.962105] SDIO: Disabling device mmc1:0001:1... [ 2683.962112] mmc1: starting CMD52 arg 00000400 flags 00000195 [ 2683.962132] sdhci [sdhci_irq()]: *** mmc1 got interrupt: 0x00000001 [ 2683.962145] mmc1: req done (CMD52): 0: 00001002 00000000 00000000 00000000 [ 2683.962424] mmc1: starting CMD52 arg 80000400 flags 00000195 [ 2683.962446] sdhci [sdhci_irq()]: *** mmc1 got interrupt: 0x00000001 [ 2683.962458] mmc1: req done (CMD52): 0: 00001000 00000000 00000000 00000000 [ 2683.965985] SDIO: Disabled device mmc1:0001:1 [ 2683.971995] systemd[1]: Starting Load/Save RF Kill Switch Status... [ 2683.991931] mmc1: clock 0Hz busmode 2 powermode 0 cs 0 Vdd 0 width 0 timing 0 [ 2684.004667] systemd[1]: Started Load/Save RF Kill Switch Status.

ath6kl debug mode

Current: Find clues with debug_mask=0x50480 enabled.



0x50480, irq, wmi, sdio, boot

0x140400, boot, suspend, wmi

0xffffffff, everything

Kernel.org ath6kl debug wiki is incorrect.



ath6kl_sdio has no debug_mask support.

Apply debug_mask to ath6kl_core instead.



Be advised you'll find an increase in CPU usage as the debug option can be quite "chatty".

#!/bin/bash modprobe ath6kl_core debug_mask=0x50480 modprobe ath6kl_sdio

What follows is an example where the chip has decided to disconnect with 0x50480 debug mode enabled.

[ 4596.878491] ath6kl: <-------------------------------> [ 4596.878495] ath6kl: pending mailbox msg, lk_ahd: 0x5E60001 [ 4596.878604] ath6kl: rd addr 0x800 (fixed) buf 0xffff88006a3cdc24 len 1536 [ 4596.878613] ath6kl: wmi rx id 4112 len 1504 [ 4596.878617] ath6kl: WMI_EXTENSION_EVENTID [ 4596.878621] ath6kl: wmi event dbglog len 1500 [ 4596.878631] ath6kl: valid interrupt source(s) for other interrupts: 0x0 [ 4596.878635] ath6kl: bypassing irq status re-check, forcing done [ 4596.878639] ath6kl: proc_pending_irqs: (done:1, status=0 [ 4596.879518] ath6kl: wr addr 0x418 buf 0xffff88005c6a3d5c len 4 [ 4596.879558] ath6kl: cold resetting the device [ 4596.879598] ath6kl: wr addr 0x474 buf 0xffff88005c6a3d54 len 4 [ 4596.879638] ath6kl: wr addr 0x479 (fixed) buf 0xffff88005c6a3d04 len 4 [ 4596.879675] ath6kl: wr addr 0x47a (fixed) buf 0xffff88005c6a3d04 len 4 [ 4596.879712] ath6kl: wr addr 0x47b (fixed) buf 0xffff88005c6a3d04 len 4 [ 4596.879751] ath6kl: wr addr 0x478 buf 0xffff88005c6a3cfc len 4 [ 4596.879759] ath6kl: sdio power off

Bonus round

Neat, and perhaps a source of future pleasure.

Ath-next Repo

cat /sys/kernel/debug/ieee80211/phy0/ath6kl/tgt_stats

Bluetooth

Work in Progress: Not functioning on Venue 8.

FYI: I have not looked at this for a long time. I'm under the impression that this is heavily dependent on WiFi working reliably as well.

This is a big pile of unsorted notes, "qca" is the only protocol that seems to atleast get some form of response out of the chipset.



Current list of clues

UART based device

Dependent on hci_uart module.

Windows: reports manufacturer "69"

69 0x0045 Atheros Communications, Inc.

HCI_UART_ATH3K matches for manufacturer "69"

Windows: H4 protocol.

Enumerates to a ttyS device

RFkill can toggle power when modded per #73081

Found a stack of firmware files...

ACPI

The actual Bluetooth UART

Device (BTH0) Name (_HID, "DLAC3002" /* Qualcomm Atheros Bluetooth UART Transport */) // _HID: Hardware ID UartSerialBus (0x0001C200, DataBitsEight, StopBitsOne, 0xC0, LittleEndian, ParityTypeNone, FlowControlHardware, 0x0020, 0x0020, "\\_SB.URT1", 0x00, ResourceConsumer, , )

Default: 115200, 8, n, 1, flow 0x0001C200 = 115200 0xC0 = 192 0x0020 = 32 0x00 = 0

GPIO toggles sit in the last GPIO pool.

$ cat /sys/kernel/debug/gpio GPIOs 410-511, platform/INT33FC:00, INT33FC:00:

From ACPI table

GpioIo (Exclusive, PullUp, 0x0000, 0x0000, IoRestrictionOutputOnly, "\\_SB.GPO0", 0x00, ResourceConsumer, , ) { // Pin list 0x0034 // gpio-52 // 410 + 52 = 462 } GpioIo (Exclusive, PullUp, 0x0000, 0x0000, IoRestrictionOutputOnly, "\\_SB.GPO0", 0x00, ResourceConsumer, , ) { // Pin list 0x0035 // gpio-53 // 410 + 53 = 463 }

GPIO direct

0x0035 needs to be high for any response to be received.

0x0034 doesn't seem to react much at all.

# Claim echo 462 > /sys/class/gpio/export echo 463 > /sys/class/gpio/export # Power on? echo "high" > /sys/class/gpio/gpio462/direction echo "high" > /sys/class/gpio/gpio463/direction # Power off? echo "low" > /sys/class/gpio/gpio462/direction echo "low" > /sys/class/gpio/gpio463/direction

# debugfs $ cat /sys/kernel/debug/gpio | grep sysfs gpio-52 (sysfs ) in out hi pad-88 offset:0x580 mux:0 gpio-53 (sysfs ) in out hi pad-92 offset:0x5c0 mux:0

HCI Uart

.id = HCI_UART_ATH3K, .name = "ATH3K", .manufacturer = 69, .open = ath_open, .close = ath_close, .flush = ath_flush,

Kernel

Networking support ⌞Bluetooth subsystem support ⌞Bluetooth device drivers ⌞HCI UART driver UART (H4) protocol support Atheros AR300x serial support Qualcomm Atheros protocol support

Debugging Bluetooth

It appears that there's no nice kernel flag and documentation is sorely lacking for such a critical piece of infrastructure. The following a very heavy handed method that will deliver into the kernel log.

#src/drivers/bluetooth #src/net/bluetooth find . -type f -exec sed -i 's/BT_DBG/BT_ERR/g' {} \;

RFkill / ACPI GPIO mod

[ 7.369615] rfkill_gpio DLAC3002:00: GPIO lookup for consumer reset [ 7.369624] rfkill_gpio DLAC3002:00: using ACPI for GPIO lookup [ 7.369630] acpi DLAC3002:00: GPIO: looking up reset-gpios [ 7.369636] acpi DLAC3002:00: GPIO: _DSD returned DLAC3002:00 0 0 0 [ 7.369709] rfkill_gpio DLAC3002:00: GPIO lookup for consumer shutdown [ 7.369714] rfkill_gpio DLAC3002:00: using ACPI for GPIO lookup [ 7.369719] acpi DLAC3002:00: GPIO: looking up shutdown-gpios [ 7.369724] acpi DLAC3002:00: GPIO: _DSD returned DLAC3002:00 1 0 0 [ 7.369854] rfkill_gpio DLAC3002:00: DLAC3002:00 device registered.

#rfkill block 0 gpio-52 (reset ) in out lo pad-88 offset:0x580 mux:0 gpio-53 (shutdown ) in out lo pad-92 offset:0x5c0 mux:0 #rfkill unblock 0 gpio-52 (reset ) in out hi pad-88 offset:0x580 mux:0 gpio-53 (shutdown ) in out hi pad-92 offset:0x5c0 mux:0

RFkill list

0: DLAC3002:00: Bluetooth Soft blocked: no Hard blocked: no

Initialize

We should be using "ath3k" but there's no observable output so, again, we use "qca" while we figure things out.

btattach -B /dev/ttyS1 -P qca Attaching BR/EDR controller to /dev/ttyS1 Switched line discipline from 0 to 15 Device index 0 attached

rfkill unblock 0 + init

[ 1994.993890] Bluetooth: hci0: ROME setup [ 1994.993902] Bluetooth: hci0: Set UART speed to 3000000 [ 1995.392837] Bluetooth: hci0: Frame reassembly failed (-84) [ 1997.299427] Bluetooth: hci0 command 0xfc00 tx timeout

hci0: Type: BR/EDR Bus: UART BD Address: 00:00:00:00:00:00 ACL MTU: 0:0 SCO MTU: 0:0 DOWN INIT RUNNING RX bytes:4 acl:0 sco:0 events:0 errors:0 TX bytes:10 acl:0 sco:0 commands:2 errors:0 Features: 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 Packet type: DM1 DH1 HV1 Link policy: Link mode: SLAVE ACCEPT

rfkill block 0 + init

[ 2035.866828] Bluetooth: hci0: ROME setup [ 2035.866840] Bluetooth: hci0: Set UART speed to 3000000 [ 2038.166100] Bluetooth: hci0 command 0xfc00 tx timeout

hci0: Type: BR/EDR Bus: UART BD Address: 00:00:00:00:00:00 ACL MTU: 0:0 SCO MTU: 0:0 DOWN RX bytes:0 acl:0 sco:0 events:0 errors:0 TX bytes:10 acl:0 sco:0 commands:2 errors:0 Features: 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 Packet type: DM1 DH1 HV1 Link policy: Link mode: SLAVE ACCEPT

Does Nothing

btattach -B /dev/ttyS1 -P ath3k btattach -B /dev/ttyS1 -P h4

"hciattach" is the old and trusted way and doesn't talk the newer init protocols but can be used with ath3k. Using "any" did not result in anything. "btattach" is the successor to "hciattach". In saying that hciattach IS responsible for getting the firmware and rampatch loaded from userspace.

hciattach -n -s 115200 /dev/ttyS1 ath3k flow nosleep hciattach /dev/ttyS1 any 115200 flow

Firmware Files

Windows 8.1, 32-bit

# C:\Windows\System32\Drivers 90K - AthrBT_0x01020201.pst 1.3K - ramps_0x01020201_26_DLAB.pst 1.3K - ramps_0x01020201_26_DLAB_gpio.pst 1.2K - ramps_0x01020201_26_DLAC.pst 1.2K - ramps_0x01020201_26_DLAC_gpio.pst 1.2K - ramps_0x01020201_26_HPAA.pst 1.2K - ramps_0x01020201_26_IAAE.pst 1.2K - ramps_0x01020201_26_IAAE_gpio.pst 1.3K - ramps_0x01020201_26_QDMN.pst 1.2K - ramps_0x01020201_26_SSAD.pst 1.2K - ramps_0x01020201_26_SSAD_gpio.pst

Arch 07.2016 install

# /lib/firmware/ar3k -rw-r--r-- 1 root root 48K May 20 03:24 AthrBT_0x01020201.dfu -rw-r--r-- 1 root root 1.2K May 20 03:24 ramps_0x01020001_26.dfu -rw-r--r-- 1 root root 1.3K May 20 03:24 ramps_0x01020200_26.dfu -rw-r--r-- 1 root root 1.2K May 20 03:24 ramps_0x01020200_40.dfu -rw-r--r-- 1 root root 264 May 20 03:24 ramps_0x01020201_26.dfu

Kernel Compiling

Before you begin

Keep in mind that if you are dependent on a using a MicroSD reader because of the workaround you'll be dealing with a limited power budget. Disabling turbo and dropping down to 2 cores may be beneficial.



Once you have your sources and dependencies installed it's best to only have a keyboard and your MicroSD reader plugged in and nothing else before starting the make process.



The quality and therefore speed of your MicroSD reader may cause the host Kernel watchdog to report hard lockups on one of the cores as the compile process is running while it is doing a write operation.



Failure to keep this in mind will result in comedy. Otherwise it's usual fare.



AUR Linux Kernel Package

With Kernel 4.10 being released and all the essentials contained there in you can opt to do an automated package build. Be advised that due to bug #96571 and the way that the AUR package is compiled you'll find yourself unable to control the backlight. Secondly, due to bug #150881 if you dual-boot with your RootFS on a MicroSD card you'll be out of luck unless you grab an external card reader. Both matters can be addressed manually but for those just testing their hardware this may be a worthwhile method.



#AUR Package AUR Linux-Git # Protip "wget" and "makepkg -si" are your friends. # For your ~/.bashrc to optimize compile concurrency export MAKEFLAGS="-j$(expr $(nproc) \+ 1)"

Venue 8 and 11 Pro

Kernel 4.9-rc4 sees the Venue 8 Pro Wireless identifier mainlined so that negates any need for manual patching. Thanks Adam!

For Venue 11 and older kernels, the following adds support for Dell Wireless 1537 (0x19) & 1538 (0x18).



/drivers/net/wireless/ath/ath6kl/sdio.c #Kernel 4.8.11, go to line 1398. {SDIO_DEVICE(MANUFACTURER_CODE, (MANUFACTURER_ID_AR6004_BASE | 0x0))}, {SDIO_DEVICE(MANUFACTURER_CODE, (MANUFACTURER_ID_AR6004_BASE | 0x1))}, {SDIO_DEVICE(MANUFACTURER_CODE, (MANUFACTURER_ID_AR6004_BASE | 0x2))}, Add in {SDIO_DEVICE(MANUFACTURER_CODE, (MANUFACTURER_ID_AR6004_BASE | 0x18))}, {SDIO_DEVICE(MANUFACTURER_CODE, (MANUFACTURER_ID_AR6004_BASE | 0x19))},

There are no other exotic things to deal with at this time so read on for clues and just follow Arch's kernel compiling guide.

Kernel Config File

May edition is an updated 4.11-rc2 config.

February edition is an updated 4.9.0 config.

December edition is an updated 4.8.11 config.

November edition is an updated 4.8.0 config.

October edition is an updated 4.7.0 config.

August edition adds extra USB, Filesystem and Networking material beneficial to daily use.

If you want to save time use the the July config which is more bare bones.

May 2017 :: DV8Pro-Kconfig-4.11.1-May17.txt - 143.1 KB

February 2017 :: DV8Pro-Kconfig-4.10.0-Feb17.txt - 139.1 KB

December 2016 :: DV8Pro-Kconfig-4.9.0-Dec.txt - 136.8 KB

November 2016 :: DV8Pro-Kconfig-4.8.11-Nov.txt - 135.2 KB

October 2016 :: DV8Pro-Kconfig-4.8.0-Oct.txt - 135.2 KB

August 2016 :: DV8Pro-Kconfig-4.7.0-Aug.txt - 133.6 KB

July 2016 :: DV8Pro-Kconfig-4.7.0.txt - 122.0 KB

January 2016 :: DV8Pro-Kconfig-4.4rc8.txt - 120.3 KB

BTRFS

Add BTRFS to the kernel directly, not as a module if you're using a MicroSD card as rootFS. Bonus points for replacing the "fsck" hook with "btrfs" in your mkinitcpio.conf.

Getting Ready

Baking Dependencies:

pacman -S bc base-devel

The Arch Wiki explains compiling your kernel the best so there's no need to repeat everything.



#Kernel 4.8 compile time, October 2016 config. real 47m28.266s user 125m32.049s sys 10m10.763s #Kernel 4.11-rc1 compile time, February 2017 config. real 43m1.400s user 126m58.409s sys 10m43.063s

Grab your kernel, extract it and to save time do a "make localmodconfig".

Be advised, localmodconfig may disable many useful things. (Like loopback device, FUSE support). It's recommended once ready to do a full compile so you'll have all the kernel goodness with sugar on top.



Automation

A little crude perhaps, but most efficient. This is how I bake my Kernels straight from the tarball. Script sits in the root of the unpacked Kernel source.

#!/bin/bash make -j 4 make -j 4 modules make modules_install cp -v ./arch/x86/boot/bzImage /boot/vmlinuz-linux412 mkinitcpio -k 4.12.0-ARCH -c /etc/mkinitcpio.conf -g /boot/initramfs-linux412.img

Manual Selection

ToDo: Audio, I should make a mention of snd_soc_core and snd_soc_rt5640. localmodconfig should include these though.

MicroSD reader (Bug #150881)

This regression happened from 4.8.x to 4.11.x and is now fixed in Kernel 4.12. The bug prevented the MicroSD reader from working correctly.

This makes sure the root filesystem on a MicroSD card can be found. Device Drivers ⌞ Real Time Clock ⌞ PC-Style 'CMOS' CONFIG_RTC_DRV_CMOS [=m]

Processor Support

Processor type and features We require: /dev/cpu/*msr - Model-specific register support Enables: powertop / cpupower to function correctly CONFIG_X86_MSR [=m]

Atheros 6K Wifi

Enable debug and tracing too if your beard is long like mine.

Device drivers ⌞ Network device support ⌞ Wireless LAN ⌞ Atheros/Qualcomm devices ⌞ Atheros mobile chipsets support We require: Atheros ath6kl SDIO support Enables: Atheros SDIO Wifi Support CONFIG_ATH6KL [=m] CONFIG_ATH6KL_SDIO [=m]

Backlight PWM Support

Device Drivers ⌞ Pulse-Width Modulation (PWM) Support CONFIG_PWM [=y] We require: - Intel Crystalcove (CRC) PWM support - Intel LPSS PWM Support - Intel LPSS PWM platform driver Enables: Backlight PWM CONFIG_PWM_CRC [=y] CONFIG_PWM_LPSS [=m] CONFIG_PWM_LPSS_PLATFORM [=m]

Backlight ACPI PMIC Support

Power Management and ACPI options ⌞ Power management and ACPI options ⌞ ACPI support ⌞ PMIC operation region support We require: ACPI Opration region support for CrystalCove PMIC Enables: Backlight Power Management CONFIG_PMIC_OPREGION [=y] CONFIG_CRC_PMIC_OPREGION [=y]

Backlight Control Support

Device Drivers ⌞Multifunction device drivers We require: Support for Intel Atom SoC PMIC Enables: Backlight Controls CONFIG_INTEL_SOC_PMIC [=y]

GPIO / I2C / Sensor Support

You'll also need basic IndustrialIO support so hid_sensor modules can actually read out values generated by said sensors, if you're doing a localmodconfig these should already be on.



Device Drivers ⌞I2C support ⌞I2C support ⌞I2C Hardware Bus Support We require: Synopsys Designware Platform Enables: Sensors and Backlight GPIO CONFIG_I2C [=y] CONFIG_I2C_DESIGNWARE_CORE [=m] CONFIG_I2C_DESIGNWARE_PLATFORM [=m]

Hardware Buttons

The Venue 8 has 4 buttons. Power, Volume Up, Volume Down and a "home" button with branding.



The Power button is responsible for generating the wake-up interrupt when device has been put to suspend mode.

Device Drivers ⌞Input device support ⌞Miscellananeous devices We require: Windows-compatible SoC Button Array Enables: Physcal hardware buttons CONFIG_INPUT_SOC_BUTTON_ARRAY [=m]

GPIO Keys mapping

Device Drivers ⌞Input device support ⌞Keyboards We require: GPIO Buttons Enables: GPIO buttons to Keyboard mapping CONFIG_KEYBOARD_GPIO [=m]

Industrial I/O Sensors

I completely forgot to document the relevant sensor modules in the original write up.



There appears to be a power problem in that IIO only seems to show up reliably after a cold boot.



ToDo: Sort out correct modules



Device Drivers ⌞Industrial I/O support We require: MODULE ALL THE THINGS. Enables: Hardware Sensors CONFIG_IIO [=m] CONFIG_HID_SENSOR_IIO_COMMON [=m] Device Drivers ⌞HID support ⌞HID bus support ⌞Special HID drivers CONFIG_HID_SENSOR_HUB [=m]

Intel Signal Processor

The Venue 8 has a front and rear camera connected to a MIPI-CSI Bus.



Kernel 4.12 staging brings initial support.

Device Drivers ⌞Staging Drivers ⌞Media Staging Drivers ⌞Enable support to Intel MIPI camera drivers We require: Modules all the things! Enables: Camera(s), potentially. CONFIG_INPUT_ATOMISP [=y] CONFIG_VIDEO_ATOMISP [=m]

At the moment when compiled the Kernel will show a number of trace reports during boot. As the camera modules appear to be in an unpowered state it is not able to finish probing correctly.

[9.257441] acpi INT33BE:00: Failed to find gmin variable INT33BE:00_I2CAddr [9.257451] ov5693 i2c-INT33BE:00: gmin: initializing atomisp module subdev data.PMIC ID 1 [9.258085] acpi INT33BE:00: Failed to find gmin variable INT33BE:00_CamClk [9.258684] acpi INT33BE:00: Failed to find gmin variable INT33BE:00_ClkSrc [9.259280] acpi INT33BE:00: Failed to find gmin variable INT33BE:00_CsiPort [9.259874] acpi INT33BE:00: Failed to find gmin variable INT33BE:00_CsiLanes [9.265595] ov5693 i2c-INT33BE:00: sensor power-up failed [9.265608] ov5693 i2c-INT33BE:00: sensor power-up failed [9.265615] ov5693 i2c-INT33BE:00: sensor power-up failed [9.265622] ov5693 i2c-INT33BE:00: sensor power-up failed [9.265628] ov5693 i2c-INT33BE:00: ov5693 power-up err. [9.265634] ov5693 i2c-INT33BE:00: sensor power-gating failed [9.306753] ov5693: probe of i2c-INT33BE:00 failed with error -22 [9.346612] mt9m114 i2c-INT33F0:00: gmin: initializing atomisp module subdev data.PMIC ID 1 [9.347285] acpi INT33F0:00: Failed to find gmin variable INT33F0:00_CamClk [9.347905] acpi INT33F0:00: Failed to find gmin variable INT33F0:00_ClkSrc [9.348506] acpi INT33F0:00: Failed to find gmin variable INT33F0:00_CsiPort [9.349096] acpi INT33F0:00: Failed to find gmin variable INT33F0:00_CsiLanes [9.349257] mt9m114 i2c-INT33F0:00: sensor power-up failed [9.349264] INT33F0:00: mt9m114 power-up err [9.366735] mt9m114: probe of i2c-INT33F0:00 failed with error -22

That's a wrap

If the "i915" module starts BEFORE gpio is registered, you'll find your dmesg spewing "Failed to own gpio for panel control" at you which then means you can't control your backlight. So if you want early KMS happening correctly make sure you have the Intel and control interface modules loaded like thus.

# /etc/mkinitcpio.conf MODULES="i2c_designware_platform i2c_designware_core i915" #Copy your kernel cp -v arch/x86/boot/bzImage /boot/vmlinuz-linux4120 #Roll a init ram disk: mkinitcpio -k 4.12.0-ARCH -c /etc/mkinitcpio.conf -g /boot/initramfs-linux4120.img

If you haven't already, make sure your Grub is properly configured.

Troubleshooting

Kernel Compiling

First, Check that you did your kernel compile right.

Second, Check that you did your kernel compile right.

Q: Kernel 4.9 (rc4) fails to boot, unknown symbol error (-22), WARNING: __fentry__ reported during compile.

A: Disable CONFIG_MODVERSIONS for the moment.

MicroSD Slot

Q: sdhci-acpi: probe of 80860F14:01 failed with error -16

Q: MicroSD slot is missing during installation / normal use

A: Broke in Kernel 4.8, regression fixed in Kernel 4.12

A: You'll need to compile your own Kernel and make sure to set "RTC_DRV_CMOS" (PC-Style 'CMOS') to module. #150881.

Intel Video

Q: Screen goes black when booting and never comes back.

Q: Screen goes black when KMS / DRM is initialized.

Q: Screen goes / stays black unless I enable nomodeset.

A: Use a recent Kernel. 4.9 and up have the right bugfixes.

A: Use the BIOS "Boot Mode" Menu, start Grub, then boot your preferred Kernel!

A: Slim chance but your trouble might be #96571, #101205 and #100356.

Q: My backlight controls don't seem to function. i915 0000:00:02.0: lookup for GPIO panel failed [drm:intel_dsi_init [i915]] *ERROR* Failed to own gpio for panel control [drm:pwm_setup_backlight [i915]] *ERROR* Failed to own the pwm chip

A: Kernel Bug #96571 may be stopping you. Enable PWM support "CONFIG_PWM", then make sure "CONFIG_PWM_CRC" is not compiled as a module.

A: You need i2c_designware modules to bring up gpio controls.

A: Include i2c_designware and i915 modules (in that order) for early KMS.

Q: Kernel / DRM is complaining about "Atomic update failures" kernel: [drm:intel_pipe_update_end [i915]] *ERROR* Atomic udpate failure on pipe A (start=129675 end=129676) time 8us, min 1272, max 1279, scanline start 1280, end 1280.

A: It seems pretty harmless on the Venue 8, on other hardware it can be responsible for causing Xorg to crash and other happenstances. Regardless of acceleration method or kernel flag options it keeps showing up in the system log in my case but feel free to tinker with all clues provided. #Disables atomic mode setting. drm.atomic=0 #Disables Panel Self Refresh, default is on since Kernel 4.6. i915.enable_psr=0

A: (⌐■_■) Deal with it.

Atheros Wifi

Q: Atheros Wifi, ath6kl complains. ath6kl_sdio mmc1:0001:1: Direct firmware load for ath6k/AR6004/hw3.0/bdata.bin failed with error -2 ath6kl: Failed to get board file ath6k/AR6004/hw3.0/bdata.bin (-2), trying to find default board file. ath6kl_sdio mmc1:0001:1: Direct firmware load for ath6k/AR6004/hw3.0/bdata.bin failed with er