crosshatch: mainlining attempt: progress and questions

I'm currently porting mainline to Google Pixel 3 XL (google-crosshatch). Google and Qualcomm already upstreamed sdm845 support, so all we need is a device tree to boot the phone.

(I'm making this an issue because I think it's a better place to keep a discussion than in Matrix chat. I'll move this to Wiki once this is complete)

Current status: USB networking works.

Screen currently doesn't work, although it's possible to use the screen if USB is disabled.

dmesg: here.

Source: https://github.com/Pixel3Dev/linux/commits/crosshatch-usb-works

The below list isn't updated yet; I'll update it later.

---

Currently, I'm following @opendata26's Qualcomm mainlining guide.

What I've done so far:

• I'm currently compiling/booting the kernel from outside of pmbootstrap, because I want incremental kernel compiles
• I'm using Linux master branch (a bit past 4.20-rc6, 65e08c5e86311143f45c3e4389561af3107fc8f6)
• I copied config-postmarketos-mainline.aarch64 from pmaports into my kernel's .config, then ran make menuconfig and saved to use defaults for newly added params
• I copied the device tree from sdm845-mtp.dts to sdm845-crosshatch.dts, and added it to the makefile
• I commented most of the mtp specific stuff out
• I built a stub dtbo file and flashed it to the dtbo partition.
• I built the kernel, but intentionally added code to reboot before device initialization
  • I haven't changed the device tree yet, and I don't want it to cause damage to my phone
• I built a boot.img
• fastboot boot accepts the boot.img
• device reboots immediately after boot, as expected, confirming that the mainline kernel boots all the way to start_kernel

Edit December 19

• updated the device tree with regulator information and ramoops/memory reserve nodes
• booted the mainline kernel with the resulting tree
• nothing happens - no USB
• made a patch to dump kernel log to RAM, then reboot, when pmOS tries to setup USB networking
• log shows the USB controller isn't being detected

What I still need to do:

• Verify regulator configuration matches between downstream and mainline kernelDone
• Confirm whether mainline even has USB device support (SDM845 MTP forces host on the main USB Type-C port)
• Copy other parts of the device tree from downstream (memory reservations, ramoops, etc)
• Try to boot the device with updated device tree and see how it crashes

Edit December 19:

• Debug the USB networking

Questions and topics:

DTBO

The Pixel 3 XL has two device trees:

• the base device tree, appended to the end of the kernel
• an overlay, in the dtbo partition

At boot time, the bootloader merges the two device trees and passes the result to the kernel.

Google's intention is that the kernel's device tree would contain only SoC specific info, and the dtbo partition would contain device-specific info.

I don't think this fits well with mainline's use of device trees, where each board only has one device tree file that includes both SoC and board info.

Thus, I made an empty device tree, with no extra nodes beyond device name. I built this into a dtbo image and flashed it. So now all device tree information should come from the device tree included in the kernel.

Is this the correct approach? I can split Pixel 3 XL specific parts into the dtbo later, if needed.

Regulators: HPM mode

According to the guide, I need to verify the regulator voltages.

I found the regulator file, sdm845-regulator.dtsi in the downstream kernel:

and I found the mainline equivalent

However, the same regulator (ldo26) is marked as starting in HPM mode in mainline, but LPM in downstream. This seems to happen for all the regulators.

It seems upstream doesn't support LPM mode at all:

  Regulators all default to HPM mode w/ no ability to switch modes.
  Future patches can switch things to LPM and possibly add
  dynamic load switching if we have determined there's a benefit.
  This should only be done for rails where we'll actually be able
  to take advantage of the lower power modes so we don't need to
  churn with lots of patches adding regulator_set_load() calls
  to drivers.

I just want to confirm: is this just for power saving? If I keep everything as HPM mode, would it damage anything?

Getting debug output: pstore-ramoops

I don't have a debug cable, and I don't trust myself to make one.

Instead, I plan to use pstore-ramoops to get logs in RAM. While the Pixel 3 XL has an encrypted pstore-ramoops (which mainline doesn't support), it does offer a /dev/access-ramoops device to dump that memory region directly, bypassing encryption.

I'll try to setup ramoops in mainline (unencrypted), then reboot into TWRP and read /dev/access-ramoops to get the ramoops log.

• Does this sound feasible? Is there a better option that doesn't require soldering?
• Can I force the kernel to keep the /sys/fs/pstore/console-ramoops file even on successful reboot? My Nexus 6P's kernel does this, but later kernels seem to only keep the log if the kernel panics. Previously I tried forcing a kernel oops when I need logging, but there's gotta be a better way.

(Or maybe accessing the memory region directly would give me the log even on successful reboot? I have no idea how/when pstore-ramoops wipes the log on successful reboot)