search

GalliumOS / galliumos-distro

Docs, issues, and artwork sources for GalliumOS
https://galliumos.org/
GNU General Public License v2.0
345 stars 11 forks source link

Skylake Platform Validation #274

Open reynhout opened 7 years ago

reynhout commented 7 years ago

Tracking validation tests and bug reports for GalliumOS support for Skylake models.

Please add observations for any Skylake model in comments!

Current Skylake status

kmishra9 commented 7 years ago

Suspend/resume also seems to work just fine.

Some other problems I've noticed:

Display backlighting control doesn't work. Right-Alt + Brightness keys do nothing. Upon booting, there's a display backlight at full power always on and to turn it off, I just close the screen and then open it back up again. At that point, the display backlight is turned off but nothing I do allows me to turn it back on.

Full-screen works, refresh works, back and forward works, power and escape work, however the "show all things on desktop" F5 button only opens up the Display menu.

Audio input also doesn't seem to work (no options given).

Finally, just curious but Is there an ETA on a fix or update for something like this? Roughly 1 month? 6 months? 1 year? etc.

reynhout commented 7 years ago

@kmishra9: by default, the LCD backlight is controlled by unmodified media keys: F6, F7. This is configurable though: https://wiki.galliumos.org/Media_keys_and_default_keybindings .

When the lid is opened, the screensaver kicks in, and captures all keypresses (including backlight controls). You need to enter your password (sometimes blind) to dismiss the screensaver, then keypresses will reach their usual destinations. This is awkward, and I'd like to find a way to set a minimum backlight level when resuming after suspend...or to allow media keypresses to pass though the screensaver.

F5 is configured to open the display menu, but I don't recall why. It might be a side effect of using modified-F5 for screenshots?

Audio in and out are on the same chip, which isn't inited properly at all yet. Hopefully the config necessary for one to work will fix both.

We do not have an ETA on any of the open issues. We will build some test kernels with some experimental configs, but we will probably also need to purchase suitable test hardware.

reynhout commented 7 years ago

lsmod | grep snd, ChromeOS kernel 3.18 on CHELL (thanks @MattDevo)

snd_soc_skl_nau88l25_ssm4567    20544  0 
snd_soc_hdac_hdmi      16492  1 snd_soc_skl_nau88l25_ssm4567
snd_soc_dmic           12352  0 
snd_soc_skl            33897  0 
snd_soc_skl_ipc        22007  1 snd_soc_skl
snd_soc_sst_acpi       12398  1 snd_soc_skl
snd_soc_sst_ipc        12627  1 snd_soc_skl_ipc
snd_soc_sst_dsp        27573  1 snd_soc_skl_ipc
snd_hda_ext_core       18454  2 snd_soc_hdac_hdmi,snd_soc_skl
snd_hda_core           36706  3 snd_hda_ext_core,snd_soc_hdac_hdmi,snd_soc_skl
snd_soc_nau8825        32883  1 snd_soc_skl_nau88l25_ssm4567
snd_soc_ssm4567        12352  0 
snd_seq_midi           12352  0 
snd_seq_midi_event     12735  1 snd_seq_midi
snd_rawmidi            21355  1 snd_seq_midi
snd_seq                49644  2 snd_seq_midi_event,snd_seq_midi
snd_seq_device         12653  3 snd_seq,snd_rawmidi,snd_seq_midi
kmishra9 commented 7 years ago

^Sorry, what is this?

Also my bad, yeah DISPLAY backlighting works, KEYBOARD backlighting doesn't. That was a typo.

thoughtchad commented 7 years ago

LARS, Acer CB 14 for Work Issues Suspend mode turns fan on high speed indefinitely No internal audio hardware available (output or input) Various keyboard mappings not working (Delete, Home, End, LCD +-, Volume +-, Search (nothing), etc No keyboard backlighting

phelpsw commented 7 years ago

Using a HP Chromebook 13 G1

Suspend appears to mostly work for me with the following two issues:

Other stuff:

reynhout commented 7 years ago

@thoughtchad, @phelpsw Thanks for the reports.

There might be some reusable HiDPI config in the galliumos-samus pkg: https://github.com/GalliumOS/galliumos-samus/tree/master/etc/skel/.config

phelpsw commented 7 years ago

Installing galliumos-samus package fixed my hidpi problems. It looks excellent now. I followed the directions here: https://wiki.galliumos.org/Installing/Samus specifically:

sudo galliumos-repodist --enable testing
galliumos-update
sudo apt-get install galliumos-samus
cp -r /etc/skel/.config $HOME

Followed by a logout.

Before: http://i.imgur.com/5hmWWE7.png After: http://i.imgur.com/BNMZThP.png

My keyboard backlight also appears to be working now although I haven't figured out how to adjust brightness yet.

reynhout commented 7 years ago

@phelpsw Key mappings (on the default keyboard layout) for keyboard backlight decrease/increase are RightAlt + - and RightAlt + =. Do those work for you?

ghost commented 7 years ago

Confirming the samus steps above do enable keyboard backlighting, however:

  1. Backlighting switches off after suspend/resume
  2. Key mappings for enable/disable/adjust brightness do not function
phelpsw commented 7 years ago

@reynhout no those buttons don't work.

I agree with KFriedCode

reynhout commented 7 years ago

@phelpsw OK, it sounds like we'll need new keycode mappings for that model (CHELL?)

kmishra9 commented 7 years ago

Yup I'm on Chell.

Something also just recently occurred where the trackpad requires a lot of pressure to move the mouse pointer (a light finger on it won't move it) and tap-to-click stopped working. Ive recently had to fsck my sd card a couple of times so I'm afraid I may have done something to the mouse driver. This issue also cropped up after I had booted the Linux partition via SD on another Chromebook as well (Toshiba Chromebook 2) where the pointer was working fine but.... Yeah.

Any suggestions? Or ways to update the mouse driver?

coolstar commented 7 years ago

Just a heads up, I'll be getting a chell in a few days to build firmware for. If there's anything of interest I can take a look at it here.

fizal619 commented 7 years ago

@kmishra9 https://github.com/dnschneid/crouton/issues/214 Might shed some light. This is probably too late, but it helped me on crouton may help you figure out why the touchpad is weird on Chell.

polarimetric commented 7 years ago

I'm dual booting GalliumOS (installed through chrx) on a Cave (Asus Chromebook Flip C302CA), my experiences (most echo what is said above):

reynhout commented 7 years ago

@polarimetric Thanks for the report!

I think you're the first person to test the touchscreen, so I will mark that as "working". Hopefully it applies to all models (it probably does).

If you are dual-booting, would you mind pastebin'ing a system log from ChromeOS? I'd like to check some hardware info from the ChromeOS side, could help with getting internal audio working:

You seem to be having trouble with the media keys. Do the others work (volume control, etc)? They should pop a notification overlay window even though internal audio itself does not work. Keyboard and LCD backlight should pop a window as well.

Good news about suspend/resume. I'll mark that as well, at least for CAVE.

Thanks again!

polarimetric commented 7 years ago

Here's the requested log: https://ptpb.pw/0T2s

No, I'm not getting any popups when pressing any of the function keys--keyboard backlight, display backlight, or volume control. There is no visual response to the key presses anywhere that I can discern.

reynhout commented 7 years ago

@polarimetric Thanks for the logfile.

You're on the default keyboard layout, right? It sounds like we will need new maps for all of the Skylake models.

polarimetric commented 7 years ago

No problem. Yeah, default keyboard.

thoughtchad commented 7 years ago

@reynhout here's another dmesg, acre cb 4 work 14 https://ptpb.pw/CYHB

reynhout commented 7 years ago

@thoughtchad Cool, thanks. It looks like CAVE and LARS have the same audio chip, which is different from CHELL.

polarimetric commented 7 years ago

On Cave, installing the Chromebook keyboard backlight driver after adding Cave to the model list in chromebook_kb_backlight.c enables adjustment of the keyboard backlight. Default keyboard shortcuts still don't work so I mapped my own with the provided script, but the adjustment is available at /sys/class/leds/chromeos as it is on Samus and Lulu.

(edit: removed incorrect information about powertop and battery bug, see comments below)

polarimetric commented 7 years ago

Bizarrely, disabling "Use system default" and changing my keyboard model to "Chromebook (most models) | Right alt overlay | F keys mapped to media keys" in the keyboard setting, and then re-enabling "Use system default" fixed all of the default keyboard shortcuts except for XF86KbdLightOnOff, which is not doing anything even though xev shows the correct mapping. (Keyboard light up/down works.) Before I did this (default out-of-the-box behavior), xev did not show right alt as Overlay and Overlay + function key just registered as the regular function key; now all bindings are being reported correctly. This behavior is equivalent to what I see if I enable the Chromebook Falco/Pixel/Pixel2 keyboard model so I think it's just a matter of changing what model is used by default on Cave.

reynhout commented 7 years ago

@polarimetric That's interesting.

Keyboard layout Chromebook (most models) | Right alt overlay | F keys mapped to media keys should be the default for most models, and Use system defaults should be unchecked. I wonder what's different for CAVE (and possibly the other Skylake models?).

polarimetric commented 7 years ago

@reynhout I just created a fresh user account to verify that Use system defaults is checked by default on Cave and it is.

polarimetric commented 7 years ago

Update on the supposed powertop issue: It had nothing to do with powertop, that was just a coincidence. I ran into the same problem again today--the battery says that it will take 10 hours to charge and the charge comes in at a very slow trickle. Restarting does not fix it; the only way to fix it is a hard reset. It's identical to the bug this user on reddit encountered with Ubuntu, but annoyingly, they don't mention what threads on Ubuntu forums referenced the problem and I can't find them. Not sure how to go about debugging this.

polarimetric commented 7 years ago

Figured out what causes it--it's suspend while on battery power, so even though suspend itself technically works fine, I'd revoke "ok" status from suspend/resume on Cave. Steps to reproduce:

  1. Run the laptop on battery power in GalliumOS.
  2. Suspend and then resume the laptop.
  3. Plug in, see charge time to full estimate >7 hours, battery charging at a rate of about 0.1% per minute.
  4. Restart normally into Gallium; see that battery is still charging at extremely slow rate.
  5. Hard-reset the laptop by holding power button and boot back into Gallium; see expected charge rate/time to full (~60 minutes from 0 to 100%).

Here's a thread from Ubuntu forums for reference. Looks like this is a long-standing Ubuntu bug that has affected various devices.

(Also, I've verified this does not occur in Chrome OS, so it's not a hardware issue.)

EDIT: This is also occurring with the mainline 4.10rc3 kernel. Suspending and resuming while on battery power and then plugging in the device again cuts the wattage supplied while charging at 93% from ~9w to anywhere from 0.6w-2.5w, resulting in the slow charge time.

polarimetric commented 7 years ago

The rotation script in the Braswell validation tracker also works without modification on Cave.

polarimetric commented 7 years ago

More information on the Cave battery suspend/resume issue (documenting what I said in IRC here): If the device is plugged in while suspended, i.e.:

  1. Unplug the device if it is plugged in
  2. Suspend
  3. Plug in the device while suspended
  4. Resume while plugged in;

the charge rate is appropriate. The issue occurs when the laptop is plugged in while awake on battery power following a suspend on battery power. This leads me to believe it has something to do with hardware reinitialization on resume, but I can't find a way to confirm this--no errors are showing up in any logs. (I have a hunch it has something to do with xhci/the USB controller but I'm not knowledgeable enough to explore this further independently.)

MrChromebox commented 7 years ago

@polarimetric does booting ChromeOS have any affect on the charging rate? can you reproduce the issue there?

polarimetric commented 7 years ago

@MattDevo

polarimetric commented 7 years ago

From Chrome OS, using ectool, I've discovered something interesting. This gets printed to pdlog every time the charger is plugged in:

2017-01-11 02:11:06.776 P1 SNK (not charging) Charger Unknown 5000mV / 500mA, max 5000mV / 500mA 2017-01-11 02:11:06.830 P1 Disconnected 2017-01-11 02:11:07.024 P1 SNK (not charging) Charger Unknown 5000mV / 3000mA, max 5000mV / 3000mA 2017-01-11 02:11:07.150 P1 SNK Charger Unknown 585mV / 512mA, max 20000mV / 2250mA 2017-01-11 02:11:07.262 P1 SNK Charger Unknown 5068mV / 3000mA, max 5000mV / 3000mA 2017-01-11 02:11:07.464 P1 SNK Charger Unknown 19306mV / 2248mA, max 20000mV / 2250mA

The initial connection at max 500mA is of particular interest because when I encounter this issue in Gallium, that is what lsusb reports in MaxPower for the port with the charger, and the slow charge speed is due to the amperage being limited to this level (I see in acpitool the charge rate hovers around 320 mA, whereas under Chrome OS or using my standby workaround in Gallium, it's ~2000 mA). It looks like Chrome OS is terminating that initial 0.5a connection and reinitializing the charger at 2.25a automatically whereas Gallium remains stuck at 0.5a.

divx118 commented 7 years ago

Did some research on the internal audio. The driver on the v4.9.4 kernel seems to work, Card is detected, but fails to load firmware 9d70-CORE-COREBOOT-0-tplg.bin or as a fallback dfw_sst.bin . I tried the firmware from chromeos 9d70-CORE-COREBOOT-0-tplg.bin. BTW firmware needs to be in /lib/firmware.However that didn't work, the topology manifest fails to load. There should be support in the code for ABI v4 , however for some reason that fails. Still something I have to look at. I can get a card created by letting it get past the firmware load. However it won't work. See http://pastebin.com/JrrmDXWv for a partial dmesg.

Is there any site from intel where we could find new firmware releases? I searched a lot, but couldn't even find a download for the 9d70-CORE-COREBOOT-0-tplg.bin chromeos firmware.

If someone has any suggestions... :)

aBabyPenguin commented 7 years ago

I'm eagerly waiting for audio on Chell, thanks for all your effort guys. If there's anything an amateur user can do to help, let me know. Best of luck!

divx118 commented 7 years ago

Acer chromebook for work (LARS) experience an issue with grub when installing on internal eMMC. When selecting the default boot option it tries to execute save_env recordfail in grub.cfg:

function recordfail {
  set recordfail=1
  if [ -n "${have_grubenv}" ]; then if [ -z "${boot_once}" ]; then save_env recordfail; fi; fi
}

This fails with:

attempt to read write outside of disk (hd0)
Press any key to continue

When pressing any key the system boots ok.

When going to the submenu advanced menu and boot from there save_env recordfail is skipped and boots without the error.

Commenting the line if [ -n "${have_grubenv}" ]; then if [ -z "${boot_once}" ]; then save_env recordfail; fi; fi in /boot/grub/grub.cfg is a quick and dirty fix for now.

PennRobotics commented 7 years ago

@divx118 I have essentially have no idea what I'm talking about, but would the debian binary for Skylake be helpful?

divx118 commented 7 years ago

@usfbrian Unfortunately not, those are already installed on galliumos. We must have 9d70-CORE-COREBOOT-0-tplg.bin or as a fallback dfw_sst.bin I already tried creating links to those firmware files in /lib/firmware/intel from that package firmware-intel-sound as a long shot, but that failed.

carlomakes commented 7 years ago

Hello!

I recently bought a Thinkpad Chrome 13, Skylake-Sentry. I came from Braswell-Celes where everything is smooth as butter.

After I installed galliumos and did the updates, it asked me if I wanted to update the GRUB. I optioned to keep it the way it is. The lock screen button works. If I close the lid, and open it, the lock screen works fine.

I'm having issues with the wifi and some of the suspend/restart/shutdown features.

That should be everything I experienced last night. I don't have my laptop with me at the moment, but if there's anything you'd like me to do I can definitely do it when I get home tonight.

This is my first time participating/contributing here, so I'm really excited. Thanks for your time!

divx118 commented 7 years ago

@carlomakes

  1. I don't have this wifi issue on my acer chromebook for work (lars), maybe for now a workaround so you won't need to reboot is issuing the following command to get wifi back up. sudo service network-manager restart I had this issue occasionally on my regular notebook running xubuntu and used that to get it back up. It is cable connected now, so don't know if it still has this issue. Can you take a look at dmesg output to see what is happening with your wifi?
  2. Never used the suspend button.
  3. restart and shutdown button just do what they are supposed to do for me.
  4. How long do you wait before you press the hardware shutdown?

Did you install galliumos on an external USB/SD-card or on the internal SSD/MMC?

carlomakes commented 7 years ago

@divx118

  1. Thanks a lot for this command. It's a definite work around.
  2. I'll choose not to use the suspend button as well. lol.
  3. I found out this morning that when the wifi is up and working, the restart and shut down buttons work exactly how they should be. Only after when I push the suspend button and the wifi cuts, or when I open and close my lid quickly and the wifi cuts, do the restart and shut down buttons don't work.
  4. Last night when I tried shutting down I waited at least 2 minutes before pressing the physical button.

I installed galliumos on the internal mmc.

As long as I don't touch the suspend button (which I won't anymore) everything works fine. Thanks for your help!

If there's anything I can do for your guys whether it's testing something out or anything else please let me know. Thanks again.

divx118 commented 7 years ago

@carlomakes Just curious. Do you encounter the following error after grub boot menu when starting galliumos?

attempt to read write outside of disk (hd0)
Press any key to continue

If not then it is probably device specific.

BTW I just tried the suspend button, for me it works wifi will get backup. I am however running a newer kernel, I still need to test it with the default galliumos kernel for skylake models.

Update: Suspend button works also fine on 4.8.17-galliumos kernel

carlomakes commented 7 years ago

@divx118 Hey! I just rebooted it to check, and I don't encounter that error. It just boots into the login screen.

I tried the suspend button after the reboot, and all it did was cut off my wifi again. :(

jclulow commented 7 years ago

I have a Lenovo SENTRY (Thinkpad 13 Chromebook), and it's working well except for the audio. I did some digging, and it would appear that there are a few pieces to the solution. First up, I don't think the correct driver is being built (it seems to be off by default in make menuconfig) in the kernel shipped in GalliumOS. I believe the correct driver is the one enabled by CONFIG_SND_SOC_INTEL_SKL_NAU88L25_MAX98357A_MACH. There may be other Skylake ASOC modules that need to get pulled in as well.

Secondly, that driver appears to require a peculiar "topology" file, which is shipped in the ChromeOS image as /lib/firmware/dfw_sst.bin. This file appears to be built from some combination of configuration in alsa-lib and alsa-utils, using the command alsatplg. I was tinkering with trying to use the file from ChromeOS, but it appears the file format (ABI) has evolved several times, and the ChromeOS kernel is using a much older version than the 4.8.17 kernel shipping in GalliumOS. Amongst other things, the UUIDs used to map between the various components and firmware blobs are in a string format in the ChromeOS topology file, but are (in 4.8.17) seemingly a 16 byte numeric value. I tried building a Skylake-ish topology file from the latest ALSA release, but it appeared to be too new an ABI version for 4.8.17.

There appears to be a related issue in the ChromiumOS gerrit, which describes enabling this driver for a different system. It also mentions getting the topology blob (though it was not obvious from where).

I'm not really that familiar with building and installing a custom Linux kernel (I mostly work on illumos, myself). If we could get the right driver shipped, it might be easier to start trying to find the right topology file? It's possible that we'll need a more current kernel, though, to keep up with the evolving topology file format.

divx118 commented 7 years ago

@jclulow The correct driver is build, however to let it quick in you need to blacklist snd-hda-intel. To do that just add blacklist snd-hda-intel to /etc/modprobe.d/blacklist.conf. Do you have a link on how to build that topology file or some more info about that. See also my comment above https://github.com/GalliumOS/galliumos-distro/issues/274#issuecomment-279178252 .

jclulow commented 7 years ago

@divx118 OK, I might have missed the right module. I'll try the blacklist thing, thanks.

As far as the topology file, it's frustratingly difficult to find any real information about where it comes from, whether it needs to contain instructions specific to a particular motherboard or if all Skylake parts can just use the same file, etc.

There are some mailing list posts, like this one, that contain some basic pointers to some of the moving parts. I went trawling through the forest of ChromeOS repositories, but I couldn't find where the topology file for my SENTRY system actually came from -- but I might just not have looked in the right places.

What I'm thinking might be possible is to build a small C program that takes the blob file I have, and uses the struct definitions in the ChromeOS kernel source (3.18?), as well as the definitions from the GalliumOS kernel (4.7.18) and basically transforms the file. I'd really love to not have to do that, though...

divx118 commented 7 years ago

@jclulow Ok thanks for the info. I see if I have some time this weekend to dive again into the wonderful linux audio world.

jclulow commented 7 years ago

@divx118 I'm still not convinced that the correct driver is being built. The one which attaches under ChromeOS is just not present in the /lib/modules tree under GalliumOS. I believe that at least these modules (and possibly others) are missing:

/lib/modules/4.8.17-galliumos/kernel/sound/soc/codecs/snd-soc-max98357a.ko
/lib/modules/4.8.17-galliumos/kernel/sound/soc/intel/boards/snd-skl_nau88l25_max98357a.ko

I think these are disabled in the kernel config that's in the GalliumOS kernel source package; i.e., the macro CONFIG_SND_SOC_INTEL_SKL_NAU88L25_MAX98357A_MACH, and possibly others.

I'm making some progress with a tool to inspect the dfw_sst.bin blob that I lifted from ChromeOS.

divx118 commented 7 years ago

@jclulow Oops I am sorry, it seems indeed that it is not available in 4.8.17-galliumos, but it is in 4.9.4-galliumos-braswell kernel. I am running 4.9.4-galliumos-brasswell on my Acer chromebook for work I also build my own kernels to add some debugging info to the driver. However now it is the standard 4.9.4-galliumos-brasswell kernel from galliumos. btw on my chromebook the firmware/tplg blob is named 9d70-CORE-COREBOOT-0-tplg.bin, however dfw-sst.bin is coded as a fallback in the driver if 9d70-CORE-COREBOOT-0-tplg.bin is not available.

Edit: I tried to create a firmware blob from skl_i2s.conf (fetched from chromeos), however it failed with https://pastebin.com/pfCvYiNr Just need to check, maybe the alsa-utils version is too old on xenial. (version 1.1.0)

jclulow commented 7 years ago

@divx118 Ah hah! Thanks. I've switched to the 4.9.4 kernel, and that includes the right module.

I borrowed the relevant header files from the ChromeOS kernel.git repository, using the chromeos-3.18 branch, and wrote a program to parse the blob (dfw_sst.bin) I extracted from the SENTRY ChromeOS image. Instead of transforming directly to the new blob format, I produced an intermediate file in the format that alsatplg will build. The file I built seems to share a lot in common with the skl_i2s.conf file in the repository already, with a few minor differences. It also contains a number of extra widgets that are not in skl_i2s.conf, which I think are model-specific things that might control the laptop lid microphone, the speakers, etc.

I then built master of both alsa-lib.git and alsa-utils, and was able to use that to build a new dfw_sst.bin. I put this new file in /lib/firmware, and after rebooting I was able to get audio out of the headphone port! I haven't yet been able to get any audio to come from the speakers.

There are a couple of extra blobs in the original file that I haven't yet figured out how to represent in the intermediate format, and I'm hopeful that if I can figure that out, perhaps the speakers will work!