Make Intel baytrail based device(s) work better with openSUSE
a project by mkubecek
Updated about 6 years ago. 5 hacker ♥️.

Recently I became a (not very proud) owner of Acer Aspire Switch 10E, a small notebook/tablet convertible based on Intel baytrail platform. Replacing preinstalled (32-bit!) Windows 8.1 with (64-bit) openSUSE proved more challenging than expected, mostly because the device is haunted by a 32-bit UEFI so that it took me a week to make it boot without an external USB flash disk.

Even today, a lot of issues persist. As I do not want to waste a (partially) good hardware, I would like to make it as usable as possible. This is much less selfish than it sounds as there are many other devices based on Intel baytrail platform so that the effort is going to help their owners as well (if successful, that is).

Most pressing issues:

  • kernel needs to be built with CONFIG_EFI_MIXED enabled to be able to interact with 32-bit UEFI properly (enabled now in recent openSUSE kernels)
  • grub2 needs a commit from mainline to use i386-efi target when needed (available in home:mkubecek:baytrail OBS project, going to submit)
  • UEFI seems to keep resetting EFI variables to point to the original location of the windows EFI loader; find if it can be persuaded not to or at least to accept other loader as fallback if that one doesn't exist
  • Realtek 8723BS wi-fi adapter is not supported by mainline kernel; there is an out-of-tree driver available; according to Larry Finger, the chances of it getting it into mainline are negligible but there seems to be a light at the end of the tunnel; for the time being, a KMP with the driver from github would be handy
  • the keyboard/touchpad device in the base needs HID_MAX_USAGES to be raised to an insanely high value; according to Jiří Kosina, this usually means the device reports too many capabilities (without actually providing those); a proper way to handle this is writing a driver which fixes the descriptor (there is also a table of HID device quirks, could it be employed instead?).
  • there definitely is a sound device inside; however, none is detected by openSUSE or seen by lspci or lsusb; I guess it uses some more esoteric interface ({SD,MM,GP}IO?); learn more about those and try to find a way to
  • suspend to disk/RAM doesn't work at all
  • since 4.3.0 (persists with 4.4-rc4), playing fullscreen video in mpv ends up freezing the system; trying to get a crash dump but Alt-SysRq-C is ignored and automatic lockup detectors reboot the system instead of executing kdump for some reason
  • getting "Atomic update failure on pipe A" errors from i915 driver; these seem to be fixed for Haswell GPU's but apparently this Atom APU is also affected
  • when the lid is taken out of the base for long time (1-2 hours), USB sometime stops working; occasionally a message about IRQ#8 being disabled appears; last seen with 4.1 kernel, not sure if this issue can be reproduced with current kernel (haven't tried).
  • rotating the screen in Plasma 5 is way slower than it used to be in KDE4
  • touchscreen tap leads to completely different action than a mouse click when Plasma 5 desktop is displayed; may be intentional but I have no idea how to configure it

Join this project

Looking for hackers with the skills:

hardware kernel bootloader opensuse

This project is part of:

Hack Week 13

Activity

  • over 9 years ago: randybb liked this project.
  • over 9 years ago: pluskalm liked this project.
  • over 9 years ago: alnovak liked this project.
  • over 9 years ago: mlin7442 liked this project.
  • over 9 years ago: aspiers liked this project.
  • over 9 years ago: mkubecek added keyword "opensuse" to this project.
  • over 9 years ago: mkubecek added keyword "hardware" to this project.
  • over 9 years ago: mkubecek added keyword "kernel" to this project.
  • over 9 years ago: mkubecek added keyword "bootloader" to this project.
  • over 9 years ago: mkubecek started this project.
  • over 9 years ago: mkubecek originated this project.


    • Comments

    • mkubecek
      over 9 years ago by mkubecek | Reply

      End of hackweek status: I spent a lot of time on trying to get a crash dump after video playback freezes. No luck so far - and I didn't get to some other interesting topics (like getting rid of the HID_MAX_USAGES hack).

      • ToDo: grub2 submitrequest
      • UEFI ignores BootOrder but one can select his preferred EFI loader in the setup
      • packaged rtl8723bs KMP and added to home:mkubecek:baytrail OBS project; ToDo: check status of the additional patches in patches/ subdirectory
      • keyboard/touchpad usages issue: still ToDo
      • enabling few additional config options allows me to see the sound device; no success to get an actual sound out of it yet, will need to get more familiar with ALSA configuration
      • suspend to disk/RAM: no progress
      • freezing video: spent a lot of time trying to get a crash dump, no success
      • atomic update failures: modified the workaround for freedesktop.org bug 91579 to be used with ValleyView chipsets but the messages are still there; ToDo: report a bug to bugs.freedesktop.org
      • IRQ getting disabled: irqpoll kernel parameter seems to help
      • with current Tumbleweed, screen rotation is as fast as it used to be with KDE4

    Similar Projects

    early stage kdump support by mbrugger

    Project Description

    When we experience a early boot crash, we are not able to analyze the kernel dump, as user-space wasn't able to load the crash system. The idea is to make the crash system compiled into the host kernel (think of initramfs) so that we can create a kernel dump really early in the boot process.

    Goal for the Hackweeks

    1. Investigate if this is possible and the implications it would have (done in HW21)
    2. Hack up a PoC (done in HW22 and HW23)
    3. Prepare RFC series (giving it's only one week, we are entering wishful thinking territory here).

    update HW23

    • I was able to include the crash kernel into the kernel Image.
    • I'll need to find a way to load that from init/main.c:start_kernel() probably after kcsan_init()
    • I workaround for a smoke test was to hack kexec_file_load() systemcall which has two problems:
      1. My initramfs in the porduction kernel does not have a new enough kexec version, that's not a blocker but where the week ended
      2. As the crash kernel is part of init.data it will be already stale once I can call kexec_file_load() from user-space.

    The solution is probably to rewrite the POC so that the invocation can be done from init.text (that's my theory) but I'm not sure if I can reuse the kexec infrastructure in the kernel from there, which I rely on heavily.

    update HW24

    • Day1
      • rebased on v6.12 with no problems others then me breaking the config
      • setting up a new compilation and qemu/virtme env
      • getting desperate as nothing works that used to work
    • Day 2
      • getting to call the invocation of loading the early kernel from __init after kcsan_init()

    • Day 3

      • fix problem of memdup not being able to alloc so much memory... use 64K page sizes for now
      • code refactoring
      • I'm now able to load the crash kernel
      • When using virtme I can boot into the crash kernel, also it doesn't boot completely (major milestone!), crash in elfcorehdr_read_notes()

    • Day 4

      • crash systems crashes (no pun intended) in copy_old_mempage() link; will need to understand elfcorehdr...
      • call path vmcore_init() -> parse_crash_elf_headers() -> elfcorehdr_read() -> read_from_oldmem() -> copy_oldmem_page() -> copy_to_iter()

    • Day 5

      • hacking arch/arm64/kernel/crash_dump.c:copy_old_mempage() to see if crash system really starts. It does.
      • fun fact: retested with more reserved memory and with UEFI FW, host kernel crashes in init but directly starts the crash kernel, so it works (somehow) \o/

    • TODOs

      • fix elfcorehdr so that we actually can make use of all this...
      • test where in the boot __init() chain we can/should call kexec_early_dump()