Skip to content

crosshatch: add new device (Google Pixel 3 XL)

Administrator requested to merge crosshatch into master

Here's my progress so far for the Google Pixel 3 XL port.

What does work as of December 10:

  • USB networking works when connected to a physical Linux computer (and mostly with VirtualBox).
  • SSH works.
  • Flashing rootfs and boot works (once user manually switches to slot A and flashes dtbo from stock factory image)
  • Root filesystem mounts with the pmbootstrap patch.
  • Plasma Mobile almost works (screen displays, although DPI is wrong, apps have half their window off the screen, and rendering is very slow)
  • Touchscreen works.

What doesn't work/needs to be documented in Wiki:

  • Framebuffer doesn't work (so no boot splash image or FDE)
  • Weston doesn't come up yet
  • USB is glitchy - idVendor/idProduct are both currently 0, which somewhat breaks VirtualBox's USB passthrough (attaching the device to a VM works, and I can ssh from within the VM, but I can't detach the device from VirtualBox.)
  • the extra dtbo Device Tree partition isn't built or flashed. Users will need to manually flash this partition with the dtbo image from the stock December factory image prior to flashing postmarketOS.
  • Users must manually switch slot to A by running fastboot set_active a before flashing postmarketOS.
  • this device needs pmbootstrap's image generation to be patched, as it uses 4096 byte sectors instead of the normal 512. (There's a MR on pmbootstrap for this now.)
  • Bluetooth shows up in rfkill, but unblocking it doesn't do anything. (It's a wcn3990).
  • Wi-Fi just doesn't show up. On the stock ROM, Wi-Fi seems to be handled by a kernel module (located in qcacld and qca-wfi-host-cmn) built outside the main kernel tree. Are there any devices using such a setup?
  • (alternatively, the upstream ath10k driver just got support for the wcn3990; I don't know how to backport that down though.)

I have not tested anything else.

I have some questions: (Edit December 10: put answers/decisions below.)

  • This device, like the original Google Pixel, has two system partitions. ojbr's Pixel port mention that for flashing, the "A" partition must be set to active. Is there a reason why the B partition can't be used?
    • Dec 10: My understanding: only one slot can be flashed with pmOS at a time (otherwise boot will break), and that might as well be slot A.
  • This device has two sets of Device Tree files: one set is appended to the kernel, and additional overlays are flashed to a partition on the device. The kernel source builds both. I don't think it's necessary to flash the device tree overlay partition (Android's version works just fine), so I disabled building the overlay device tree files with a kludge. Is this the right approach, or should I build and flash the overlay files as well?
    • Dec 10: In this PR we're not building dtbo files, and we'll just ask the user to flash the stock dtbo files. May build our own this later.
  • Should I rename the kernel package to something like linux-google-bluecross, linux-google-pixel3, or linux-google-b1c1 to signify that it might also work for a future Pixel 3 (blueline) port? steamport's WIP Google Pixel merge request does this.
    • Dec 10: No, keeping it as linux-google-crosshatch to match LineageOS. (Pixel 3 (blueline) port can still depend on the same kernel.)

Also, this is my first time creating a merge request on GitLab - apologies for the previously incorrect commit list.

Edited by Administrator

Merge request reports