R3.2 install on Chell Chromebook

[Trammell Hudson]

Attempting to install R3.2 on a Chell Chromebook with eMMC drive results
in an error when I selected "Delete All Partitions" and selected the
default LVM provisioning:

https://www.flickr.com/photos/osr/30187309306/in/photostream/lightbox/

I was able to use fdisk on /dev/mmcblk0 to manually delete the 12(!)
ChromeOS partitions and restart the install. It is making progress now:

https://www.flickr.com/photos/osr/30136853211/in/photostream/lightbox/

Here is the qubes-hcl-report and attached is the full cpio file.
This is on a machine with a custom coreboot build that uses
Linux-as-a-bootloader in the ROM and kexec's the Xen hypervisor.
I'll be updating my Xen patches for the hacks to make it work on this
mainboard (and also map the Xen console to the Servo debug board).

The Intel m5-6y57 CPU is supposed to support VT-d, so I'm not sure
why the IOMMU is not enabled.


Qubes release 3.2 (R3.2)

Brand: Google
Model: Chell
BIOS: heads

Xen: 4.6.3
Kernel: 4.4.14-11

RAM: 8090 Mb

CPU:
Intel(R) Core(TM) m5-6Y57 CPU @ 1.10GHz
Chipset:
Intel Corporation Skylake Host Bridge/DRAM Registers [8086:190c] (rev 08)
VGA:
Intel Corporation HD Graphics 515 [8086:191e] (rev 07) (prog-if 00 [VGA controller])
Intel Corporation Device [8086:9d24] (rev 21)

Net:
Intel Corporation Wireless 7265 (rev 59)

SCSI:


HVM: Active
I/O MMU: Not active
HAP/SLAT: Yes
TPM: Device present

Qubes HCL Files are copied to: 'dom0'
Qubes-HCL-Google-Chell-20161009-231741.yml - HCL Info


--
Trammell

[Trammell Hudson]

I'm having a problem with S3 resume on this Skylake CPU not correctly
bringing the i915 graphics back online. When it goes to sleep, Xen prints:

(XEN) Disabling non-boot CPUs ...
(XEN) Broke affinity for irq 1
(XEN) Broke affinity for irq 9
(XEN) Broke affinity for irq 17
(XEN) Broke affinity for irq 24
(XEN) Broke affinity for irq 51
(XEN) Broke affinity for irq 121
(XEN) Broke affinity for irq 16
(XEN) Broke affinity for irq 20
(XEN) Broke affinity for irq 34
(XEN) Entering ACPI S3 state.

And I confirm from the EC that the platform goes into a S3 state:

[650.711078 HC 0x8e]
[650.711713 HC 0x8a]
[650.712188 HC 0x8b]
[650.713065 event clear 0x00001000]
[650.713419 ACPI query = 13]
[650.713970 ACPI query = 0]
[650.945016 LPC RESET# asserted]
[650.945570 power state 3 = S0, in 0x003b]
[650.946019 power state 8 = S0->S3, in 0x003b]
[650.946614 chipset -> S3]
[650.946902 power state 2 = S3, in 0x003b]

Upon coming out of sleep I see coreboot do an orderly transition into Xen,
the screen backlight comes on, but nothing is drawn on the screen.
Linux and Xen print a few messages to the console (depending on the
log level):

(XEN) CPU0 CMCI LVT vector (0xf9) already installed
(XEN) Thermal LVT vector (0xfa) already installed
(XEN) Finishing wakeup from ACPI S3 state.
(XEN) Enabling non-boot CPUs ...
[ 694.232046] ACPI: Low-level resume complete
[ 694.232214] ACPI : EC: EC started
[ 694.232214] PM: Restoring platform NVS memory
[ 694.232470] Enabling non-boot CPUs ...
[ 694.237912] installing Xen timer for CPU 1
[ 694.237935] cpu 1 spinlock event irq 128
[ 694.240754] cache: parent cpu1 should notbe sleeping
[ 694.240839] CPU1 is up
[ 694.248932] installing Xen timer for CPU 2
[ 694.248947] cpu 2 spinlock event irq 135
[ 694.251840] cache: parent cpu2 should not be sleeping
[ 694.251908] CPU2 is up
[ 694.259935] installing Xen timer for CPU 3
[ 694.259949] cpu 3 spinlock event irq 142
[ 694.262819] cache: parent cpu3 should not be sleeping
[ 694.262884] CPU3 is up
[ 694.262886] ACPI: Waking up from system sleep state S3
[ 694.284903] xhci_hcd 0000:00:14.0: System wakeup disabled by ACPI
[ 694.285011] PM: noirq resume of devices complete after 21.965 msecs
[ 694.289837] PM: early resume of devices complete after 4.773 msecs
[ 694.291471] rtc_cmos 00:02: System wakeup disabled by ACPI
[ 694.308765] tpm_tis 00:06: A TPM error (38) occurred continue selftest
[ 694.577983] usb 1-7: reset high-speed USB device number 3 using xhci_hcd
[ 695.817091] [drm] RC6 on
[ 695.852808] PM: resume of devices complete after 1562.967 msecs
[ 700.974239] Restarting tasks ... done.
[ 701.112259] audit: type=1130 audit(1476131868.711:160): pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=systemd-suspend comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
[ 701.686614] audit: type=1131 audit(1476131869.286:161): pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=systemd-suspend comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
[ 704.089237] audit: type=1131 audit(1476131871.688:162): pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=qubes-suspend comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'

If I send an apshutdown command to the EC, the xscreensaver window
appears for a few seconds before the platform is halted. This is
a little bit of irony from Intel, I assume.

And, as a further bit of frustration, it occasionally resumes
correctly depending on some parameters that I haven't figured out.

--
Trammell

[Marek Marczykowski-Górecki]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On Sun, Oct 09, 2016 at 06:54:46PM -0600, Trammell Hudson wrote:
> Attempting to install R3.2 on a Chell Chromebook with eMMC drive results
> in an error when I selected "Delete All Partitions" and selected the
> default LVM provisioning:
>
> https://www.flickr.com/photos/osr/30187309306/in/photostream/lightbox/
>
> I was able to use fdisk on /dev/mmcblk0 to manually delete the 12(!)
> ChromeOS partitions and restart the install. It is making progress now:
>
> https://www.flickr.com/photos/osr/30136853211/in/photostream/lightbox/
>
> Here is the qubes-hcl-report and attached is the full cpio file.
> This is on a machine with a custom coreboot build that uses
> Linux-as-a-bootloader in the ROM and kexec's the Xen hypervisor.
> I'll be updating my Xen patches for the hacks to make it work on this
> mainboard (and also map the Xen console to the Servo debug board).

Interesting, last time I've tried kexec Xen from Linux it didn't work at
all. Any hints how to get it working?

> The Intel m5-6y57 CPU is supposed to support VT-d, so I'm not sure
> why the IOMMU is not enabled.

Maybe coreboot does not setup DMAR ACPI tables correctly? This is quite
common reason for broken VT-d support. The only related entry in xen
dmesg I see:
(XEN) I/O virtualisation disabled
Especially I don't see DMAR table in ACPI list there.

Otherwise it looks like a perfect Qubes OS platform :)

> Qubes release 3.2 (R3.2)
>
> Brand: Google
> Model: Chell
> BIOS: heads
>
> Xen: 4.6.3
> Kernel: 4.4.14-11
>
> RAM: 8090 Mb
>
> CPU:
> Intel(R) Core(TM) m5-6Y57 CPU @ 1.10GHz
> Chipset:
> Intel Corporation Skylake Host Bridge/DRAM Registers [8086:190c] (rev 08)
> VGA:
> Intel Corporation HD Graphics 515 [8086:191e] (rev 07) (prog-if 00 [VGA controller])
> Intel Corporation Device [8086:9d24] (rev 21)
>
> Net:
> Intel Corporation Wireless 7265 (rev 59)
>
> SCSI:
>
>
> HVM: Active
> I/O MMU: Not active
> HAP/SLAT: Yes
> TPM: Device present
>
> Qubes HCL Files are copied to: 'dom0'
> Qubes-HCL-Google-Chell-20161009-231741.yml - HCL Info
>
>

- --
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQEcBAEBCAAGBQJX/BTnAAoJENuP0xzK19csgbkIAI4d443SS0E9cJOunnvFXhZF
c9kK81gxgBO0iyITE0dT028Rc4b0pYM0tnz9i9/hxcHsGqbhislmqC7v1r4BLZcl
tK7Ezkf3o1OZ9JQQ7o5qoCxkE3joa084kmvb3+hHsRx3d5OMi6TLgazsNnl6OM/X
K1sZ9T3YzyDf1Fna9QRragRNjUnqh2wKuYbb/EHKBMqwehmz63HOHFn8hJL+N9hS
7FeoaigHRMSA/pdTas93sKzLBdibBYToy8VgWR+gKwtB8W+qU8fBy7B5n8dG92Qo
lajLcvz6ZH2pb9xzviiOMkDAYzu2aZcHp/SAOojueqsUG7UolBJ3LlphacNTdco=
=5o5S
-----END PGP SIGNATURE-----

[Marek Marczykowski-Górecki]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

I assume it works fine on bare-metal Linux, right? What kernel version
there? Maybe 4.4.14 is too old?

- --
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQEcBAEBCAAGBQJX/BU6AAoJENuP0xzK19cs6A4IAITlhCkQra1O0XP2Atuqcu6L
xgPH0quQfWVv1ACFsedycue5R0pK+l1DqLxGojHJBT10O8yLl9i70AaVJ7Yu2q2H
OgMmKT/G+tLbCV6nQkGSccYdXHF43ES/ueff8grYeSa68RRmvtYtOrtXHPjDqZDF
JfEkSJ50+HVeJ+IGAsyQJwX2eE0SmAQgyY9i9uDGs8ppyJYSIZpBPPwMiqbAfecX
3iyxu9Wy9Q/NoF358e6SbVHrElm8tmoLPYmwG28pK+CDuQReI6+LWzYGIngZS0x/
omDJYMf+4p1yBQxOUtKhFhDIaNckRXJCvvDNwjLxjvfp3tjN8mkUG+bC0yt1tC4=
=Zbj2
-----END PGP SIGNATURE-----

[Trammell Hudson]

On Tue, Oct 11, 2016 at 12:23:36AM +0200, Marek Marczykowski-Górecki wrote:
> On Sun, Oct 09, 2016 at 06:54:46PM -0600, Trammell Hudson wrote:

> > [...]

> > Linux-as-a-bootloader in the ROM and kexec's the Xen hypervisor.
>

> Interesting, last time I've tried kexec Xen from Linux it didn't work at
> all. Any hints how to get it working?

I'm not sure about the usual case, but in the coreboot + Linux kexec
it is a problem with Xen assuming that there is a EBDA structure provided
by the BIOS. I posted my fix to xen-devel, in reply to a 2008 post
which appeared to be the last time someone attempted this combo:

https://lists.xen.org/archives/html/xen-devel/2016-08/msg01195.html

There is an additional complication with a non-BIOS system in that
Xen's vga console assumes it can find various structs from the VGA BIOS,
which also don't exist in my setup.

> > The Intel m5-6y57 CPU is supposed to support VT-d, so I'm not sure
> > why the IOMMU is not enabled.
>
> Maybe coreboot does not setup DMAR ACPI tables correctly? This is quite
> common reason for broken VT-d support. The only related entry in xen
> dmesg I see:
> (XEN) I/O virtualisation disabled
> Especially I don't see DMAR table in ACPI list there.

That's likely the issue. In the coreboot tree there is DMAR support
for sandybridge/ivybridge, but not Skylake. I've asked on the coreboot
list if this is an easy fix.

> Otherwise it looks like a perfect Qubes OS platform :)

Fairly cheap ($800 with 8GB of RAM), TPM, super high-res screen, and 5-10W
power draw depending on the brightness. Plus it supports Free Software
x86 firmware (other than the FSP) as well as Free Software in the EC.
And there is an actual serial port for very early debugging.

I'm not a fan of the keyboard and especially not of the trackpad, but
there is just not room for a trackpoint and deep key travel switches
like the x220.

Regarding the S3 issue, it *seems* to be working. The first resume
takes almost a minute for some reason, but from then on it is fast.
I haven't really had a chance to debug that yet and compare it to what
chromeos is doing. Nor have I had a chance to tinker with the ME,
which is a newer generation compared to the x230 that I've explored.

--
Trammell