crosshatch: add new device (Google Pixel 3 XL)
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
dtboDevice 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 abefore 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, orlinux-google-b1c1to 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.
Merge request reports
Activity
added 107 commits
-
fb5432a8...542acc19 - 95 commits from branch
postmarketOS:master - c1ac8be9 - crosshatch: create device and linux packages
- 864c7bfd - crosshatch: populate kernel source package
- dd059764 - crosshatch: add patch to always use initramfs
- 9dd1eba0 - crosshatch: remove kernel patches
- 083141fd - crosshatch: save unmodified kernel config
- e7764cc5 - crosshatch: enable required kernel options
- 6202839c - crosshatch: enable NFS client in kernel config
- 91ee62a1 - crosshatch: disable LTO, arm32 vDSO, add dependencies
- c8a3d299 - crosshatch: switch to LineageOS kernel repo
- 468e3723 - crosshatch: fix kernel build
- be5b46dc - crosshatch: add defconfig name
- 2a45113b - crosshatch: fix checksum in device package
By Zhuowei Zhang on 2018-11-28T01:30:06
Toggle commit list-
fb5432a8...542acc19 - 95 commits from branch
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?
@ojbr: can you answer this one? (also: what happened to your pixel1 port, do you want to finish it? see !66 (closed))
- 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?
The only reason I can think of, why one would want to replace the files generated by Android, would be if you have flashed the wrong files previously. But that doesn't seem to be worth optimizing for.
So your approach looks good, and could easily be re-used with other devices (just depend on your dummy package).
- Should I rename the kernel package to something like
linux-google-bluecross,linux-google-pixel3, orlinux-google-b1c1to signify that it might also work for a future Pixel 3 (blueline) port? steamport's WIP Google Pixel merge request does this.
If we can assume that other pixel 3 devices also work with this port, then I'd recommend naming it
linux-google-pixel3.@zhuowei: thank you very much for the MR
By Oliver Smith on 2019-03-18T22:45:08
Edited by Ghost User-
Really sorry about the late response on this. Yes, I absolutely do still want to finish it up and am currently on it! Thanks for mentioning me here, as I would never have seen this.
In regards to the A/B partitioning, I believe you can use either partition, but it's a bit fiddly to switch between them. The "active" slot will be set to the inactive if a kernel panic is discovered, which makes development a bit of a nightmare. From testing, that's the behavior I've witnessed anyway
By Ghost User on 2019-03-18T22:45:08
-
@ojbr On the Pixel 3, the slot switching behaviour is better: it only switches slots after multiple failed boots in a row.
I thought that you warned to always switch to slot A because flashing pmOS system to both slots would confuse the root fs mounting code, which only expects one copy of the pmOS system partition. Is that valid?
By Zhuowei Zhang on 2019-03-18T23:15:03
-
@ollieparanoid I'm probably going to remove my dummy package and just patch the kernel instead, since we eventually might need to package the real
mkdtimgfor a device that needs it.
I still can't get debug out of my device - any advice? Here's what I tried:
- tried using last_kmsg by rebooting to TWRP and checking /sys/fs/pstore.
Doesn't show up in TWRP. I guess this device only supports encrypted pstore-ramoops, and since neither postmarketOS nor TWRP setup any encryption keys, I guess the bootloader discards the output.
- Tried writing the dmesg to the root filesystem partition on bootup with an OpenRC script, then reading it back out later.
Result: the root filesystem won't mount in TWRP. After copying
kpartxfrom postmarketOS initramfs into TWRP, I get the error "device-mapper: resume ioctl on system_a2 failed: Invalid argument". So I can't look at the rootfs.Also, since TWRP and this port uses the same Android kernel, does this mean that kpartx is just broken on this kernel? If so, then maybe postmarketOS couldn't mount the rootfs either, and I would need to try a different flashing method. I might make an OpenRC script that flashes the flashlight to check if the rootfs is even mounted.
Here's what I don't want to try:
- serial - I don't have a serial cable, and I'm also afraid of breaking my device by plugging an incorrect cable into it.
Any other ideas?
I'll try to find if the root filesystem is being mounted, and I'll try different ways to flash the root partition. Worst case scenario, I'll Morse Code the dmesg out the camera flash ;)
Edit: for early-boot graphics:
Looks like TWRP for this device uses /dev/dri/card0 for graphics instead of the usual /dev/fb0. I think this means this device uses a modified mainline drm/msm driver for unaccelerated graphics. Our early boot depends on /dev/fb0, so that would explain the lack of video output. (There's also a /dev/kgsl-3d0 node, so accelerated graphics still use the proprietary driver)
I know the mainline drm/msm driver supports exporting a framebuffer at /dev/fb0, since our mainlined Snapdragon devices use it during boot. I'll look at their kernel configs.
Edit 2: I see. linux-postmarketos-qcom has this in the config:
CONFIG_DRM_KMS_HELPER=y CONFIG_DRM_KMS_FB_HELPER=y CONFIG_DRM_FBDEV_EMULATION=y CONFIG_DRM_FBDEV_OVERALLOC=100I'll add the same and see if I get graphics.
Edit 3: haha nope, turning on fbdev emulation still doesn't give me graphics output. Time to enable msm-fb-refresher?
By Zhuowei Zhang on 2018-11-28T08:04:45
Edited by Administrator -
The issue you are having is probably related to kernel setting root, https://gitlab.com/opendata26/linux/commit/40095e9a8b1eb32ad7ccd705c8990792e692ba1d you will also probably have issues with USB, to fix that, delete the drivers/usb/gadget dir and replace with one from original 4.9 stable kernel, then enable USB_ETH
By Craig Tatlor on 2018-11-30T08:01:47
-
@opendata26 I'm not currently mainlining this device (will need a uart cable for that, and I don't trust myself to make one yet); however, this device's kernel is new enough that Qualcomm has switched to some upstream code.
Specifically, Qualcomm now uses a modified version of the upstream drm/msm driver for unaccelerated graphics. However, I can't get framebuffer to work: Android doesn't use the framebuffer emulation code, and so when I tried enabling it I didn't get any output on the screen from the boot splash.
Are there any special steps (eg msm-fb-refresher, packaging firmware) that I might need for framebuffer to work on this modified drm/msm driver? Do I need to compare the Qualcomm modified driver against the upstream as well?
I don't think the root=? parameter is used by the kernel when initramfs is enabled? I already have the patch to disable skip_initramfs; maximum attention hook works, so it is mounting and executing from the initramfs.
I'll rather not extensively modify the kernel - do you happen to know what specific USB change I would need to revert?
I'm guessing that flashing both A and B with postmarketOS would break, though, since the initramfs won't be able to find the right system partition. I guess that's why the Pixel port always uses A; to make sure only one slot is flashed?
Edit: also, which device are you porting that uses a 4.9 kernel?
By Zhuowei Zhang on 2018-11-30T08:09:01
Edited by Administrator -
You can buy the UART cable here https://www.sparkfun.com/products/14746
All the qcom changes break USB, just patch in the 4.9 normal USB, its gets rid of unneeded qcom gunk as well.
Its good to remove root parameter as some things in user space base off it.
By Craig Tatlor on 2018-11-30T08:30:36
Edited by Administrator -
@opendata26 A friend told me that the Pixel 2 UART cable is different from the Chromebook SuzyQ: it (supposedly) has raw UART instead of USB on the debug pins, because Chromebooks use the embedded controller to do UART->USB conversion, but Pixel 2s don't have embedded controllers. Not sure whether the Pixel 3 still does this.
By Zhuowei Zhang on 2018-11-30T08:31:05
Edited by Administrator