pmaports-rtwo/device/testing/linux-postmarketos-qcom-sm8550/rtwo.config

# Motorola rtwo bring-up fragment, appended to config-motorola-rtwo.aarch64.

# --- hardening OFF (bring-up diagnostic) --------------------------------
# config-motorola-rtwo.aarch64 (heredado de linux-postmarketos-mainline,
# nunca revisado a proposito para este equipo) trae CFI/BTI/PAC/MTE/SCS
# encendidos incluso para el propio codigo del kernel. Todas estas
# protecciones exigen que CUALQUIER cosa a la que el kernel salte o
# retorne indirectamente (trampolines de PSCI/SMCCC, callbacks del
# hipervisor Gunyah - el rtwo corre como VM primaria) respete las mismas
# convenciones (firmas CFI, landing pads BTI, x18 reservado para SCS,
# punteros autenticados). Si algun trampolin de firmware/hipervisor no
# fue compilado con las mismas convenciones, la CPU dispara una excepcion
# de hardware inmediata - encaja con un reset rapido y consistente que no
# cambio en absoluto al sacar reguladores/USB/UART/ramoops no-map. Apagado
# para aislar esto como variable; si el equipo arranca con esto apagado,
# reactivar de a una por vez para encontrar cual puntual es la culpable.
# CONFIG_CFI is not set
# CONFIG_ARM64_BTI_KERNEL is not set
# CONFIG_ARM64_PTR_AUTH_KERNEL is not set
# CONFIG_ARM64_MTE is not set
# CONFIG_SHADOW_CALL_STACK is not set

# --- kernel lockdown OFF (bring-up diagnostic) --------------------------
# config-motorola-rtwo.aarch64 trae CONFIG_LOCK_DOWN_KERNEL_FORCE_INTEGRITY=y
# a secas, asi que el kernel arranca en lockdown "integrity" SIEMPRE,
# independientemente del estado de Secure Boot que reporte U-Boot vía EFI.
# Lockdown activa LOCKDOWN_MODULE_SIGNATURE: cualquier .ko cuya firma no
# verifique contra el certs/signing_key.pem de ESTE build puntual se
# rechaza de plano ("Lockdown: modprobe: unsigned module loading is
# restricted; see man kernel_lockdown.7"), aunque ese mismo modulo haya
# cargado bien ayer. Esto nos exploto justo al reconstruir el kernel (para
# soporte UFS) mientras dejabamos a proposito el ramdisk hand-patcheado
# (dropbear + retry loop del UDC) SIN regenerar: los modulos empaquetados
# ahi quedaron firmados con la clave del build ANTERIOR, asi que el kernel
# nuevo desconfia de todos por igual -- tanto los de UFS recien habilitados
# como los del PHY USB que hasta ese rebuild cargaban sin problema. Apagado
# mientras dure el bring-up activo (vamos a seguir reconstruyendo el kernel
# sin resincronizar el ramdisk cada vez); nada aca necesita lockdown todavia.
CONFIG_LOCK_DOWN_KERNEL_FORCE_NONE=y
# CONFIG_LOCK_DOWN_KERNEL_FORCE_INTEGRITY is not set

# --- VA/PA de 52-bit -> 48-bit (bring-up diagnostic) --------------------
# config-motorola-rtwo.aarch64 trae VA_BITS/PA_BITS en 52 (LPA2), heredado
# del defconfig generico. device-motorola-dubai (unico port mainline de
# Motorola que arranca, mismo ABL/MbmPkg, aunque SIN hipervisor Gunyah de
# por medio) usa 48/48. El rtwo SI corre como VM primaria de Gunyah
# (confirmado: nodo qcom,gh-watchdog real en el DT stock), y el hipervisor
# es quien gestiona el espacio de direcciones intermedio (IPA) del huesped
# - si Gunyah en este equipo solo soporta 48-bit para la VM primaria,
# forzar 52-bit podria romper el establecimiento de la MMU en el arranque
# en ensamblador, ANTES de cualquier codigo en C y antes de parsear el
# device tree - coherente con un reset durisimo que no cambio en absoluto
# con nada de lo tocado en el .dts hasta ahora.
CONFIG_ARM64_VA_BITS_48=y
# CONFIG_ARM64_VA_BITS_52 is not set
CONFIG_ARM64_PA_BITS_48=y
# CONFIG_ARM64_PA_BITS_52 is not set
# CONFIG_ARM64_LPA2 is not set

# --- pstore / ramoops -------------------------------------------------------
# Capture the kernel console into the reserved ramoops region (0xae000000)
# so a failed boot can be read back from a later pmOS boot
# (/sys/fs/pstore/console-ramoops-0).
CONFIG_PSTORE=y
CONFIG_PSTORE_RAM=y
CONFIG_PSTORE_CONSOLE=y
CONFIG_PSTORE_PMSG=y
CONFIG_PSTORE_COMPRESS=y

# --- watchdog ------------------------------------------------------------
# sm8550.dtsi has the APSS watchdog node; build the driver in so the kernel
# pets it early (the bootloader may hand off with it armed).
CONFIG_QCOM_WDT=y
# CONFIG_QCOM_WDT above is the wrong watchdog for what actually matters here:
# it's DT-matched to the APSS timer at 0x17c10000, but rtwo boots as a Gunyah
# primary VM (qcom,gh-watchdog node confirmed in the stock DT) and the real
# watchdog guarding HLOS handoff is the HYPERVISOR's, reached only via SMCCC
# (ARM_SMCCC_OWNER_VENDOR_HYP), never via a DT node - it is registered by
# qcom_scm_gunyah_wdt_init() (drivers/firmware/qcom/qcom_scm.c), which
# unconditionally runs once CONFIG_QCOM_SCM=y probes AND arm_smccc_hypervisor_
# has_uuid() confirms Gunyah - both true for us. That function only skips
# registration if it finds an of_device_is_available() node compatible with
# "qcom,kpss-wdt" or "arm,sbsa-gwdt" - our stock DT's gh-watchdog node is
# neither, so it registers the "gunyah-wdt" platform_device regardless.
# Without CONFIG_GUNYAH_WATCHDOG, nothing ever binds to that platform_device,
# so if Gunyah/firmware hands off HLOS with the hyp watchdog already armed
# (a plausible safety net for a VM that never comes up), nothing ever calls
# gunyah_wdt_stop()/pings it, and it fires -> reset with no kernel-visible
# fault. gunyah_wdt_probe() calls gunyah_wdt_stop() unconditionally as its
# first action after the SMCCC status check succeeds - it does NOT arm or
# start the watchdog itself, so turning this on cannot make anything worse,
# it can only disarm a pre-armed timer earlier than before.
# Depends only on (ARCH_QCOM || COMPILE_TEST) && HAVE_ARM_SMCCC, both already
# satisfied; selects WATCHDOG_CORE (already =y via CONFIG_QCOM_WDT above).
CONFIG_GUNYAH_WATCHDOG=y

# --- framebuffer console ----------------------------------------------
# Reactivado 2026-09-17 junto con framebuffer@b8000000 en el .dts (ver ese
# archivo): con el chainload de U-Boot confirmado en hardware, este
# framebuffer ya esta encendido y con el formato correcto antes de que
# arranque nuestro kernel, asi que simpledrm solo tiene que mapearlo.
#
# CONFIG_FB / CONFIG_SYSFB_SIMPLEFB no hacen falta: DRM_SIMPLEDRM solo
# depende de DRM && MMU (ambos ya =y en la config base) y bindea el nodo
# "simple-framebuffer" del DT directamente, sin pasar por el fbdev legacy
# ni por el sysfb de x86 (SYSFB_SIMPLEFB es para EFI/VESA en x86, no
# aplica aca). CONFIG_FRAMEBUFFER_CONSOLE ya viene =y de la config base
# (usa el struct fb_info que expone DRM_FBDEV_EMULATION, tambien ya =y).
#
# CONFIG_FB_SIMPLE se deja APAGADO a proposito (la config base ya lo trae
# asi): compite con DRM_SIMPLEDRM por el mismo nodo "simple-framebuffer"
# del DT y gana el que bindee primero -- confundio un intento anterior de
# este mismo bring-up (pkgrel 22). Con los dos no hace falta, uno alcanza.
CONFIG_DRM_SIMPLEDRM=y
# CONFIG_FRAMEBUFFER_CONSOLE_DETECT_PRIMARY is not set

# --- misc bring-up aids ---------------------------------------------
CONFIG_MAGIC_SYSRQ=y
CONFIG_LOG_BUF_SHIFT=18

# --- kernel image format ----------------------------------------------
# The Motorola bootloader executes a raw uncompressed arm64 Image from the
# Android boot.img; EFI ZBOOT self-decompression makes it reboot instantly.
# CONFIG_EFI_ZBOOT is not set

# --- build size / speed: device kernel, not the generic arm64 one ------
# CONFIG_RUST is not set
# CONFIG_DEBUG_INFO_REDUCED is not set
CONFIG_DEBUG_INFO_NONE=y
# CONFIG_ARCH_ACTIONS is not set
# CONFIG_ARCH_AIROHA is not set
# CONFIG_ARCH_SUNXI is not set
# CONFIG_ARCH_ALPINE is not set
# CONFIG_ARCH_APPLE is not set
# CONFIG_ARCH_BCM is not set
# CONFIG_ARCH_BCM2835 is not set
# CONFIG_ARCH_BCM_IPROC is not set
# CONFIG_ARCH_BCMBCA is not set
# CONFIG_ARCH_BRCMSTB is not set
# CONFIG_ARCH_BERLIN is not set
# CONFIG_ARCH_EXYNOS is not set
# CONFIG_ARCH_SPARX5 is not set
# CONFIG_ARCH_K3 is not set
# CONFIG_ARCH_LG1K is not set
# CONFIG_ARCH_HISI is not set
# CONFIG_ARCH_KEEMBAY is not set
# CONFIG_ARCH_MEDIATEK is not set
# CONFIG_ARCH_MESON is not set
# CONFIG_ARCH_MVEBU is not set
# CONFIG_ARCH_NXP is not set
# CONFIG_ARCH_LAYERSCAPE is not set
# CONFIG_ARCH_MXC is not set
# CONFIG_ARCH_S32 is not set
# CONFIG_ARCH_MA35 is not set
# CONFIG_ARCH_NPCM is not set
# CONFIG_ARCH_REALTEK is not set
# CONFIG_ARCH_RENESAS is not set
# CONFIG_ARCH_ROCKCHIP is not set
# CONFIG_ARCH_SEATTLE is not set
# CONFIG_ARCH_INTEL_SOCFPGA is not set
# CONFIG_ARCH_STM32 is not set
# CONFIG_ARCH_SYNQUACER is not set
# CONFIG_ARCH_TEGRA is not set
# CONFIG_ARCH_TESLA_FSD is not set
# CONFIG_ARCH_SPRD is not set
# CONFIG_ARCH_THUNDER is not set
# CONFIG_ARCH_THUNDER2 is not set
# CONFIG_ARCH_UNIPHIER is not set
# CONFIG_ARCH_VEXPRESS is not set
# CONFIG_ARCH_VISCONTI is not set
# CONFIG_ARCH_XGENE is not set
# CONFIG_ARCH_ZYNQMP is not set

# --- module compression: OFF ------------------------------------------
# The base config (from linux-postmarketos-mainline) turns on
# CONFIG_MODULE_COMPRESS + CONFIG_MODULE_COMPRESS_ZSTD +
# CONFIG_MODULE_COMPRESS_ALL, so 'make modules_install' writes *.ko.zst.
# The pmOS initramfs loads modules with busybox's modprobe applet
# ('/bin/busybox --install -s' in /init, then 'modprobe -a' from
# load_modules): that applet only knows the plain '.ko' suffix and only
# decompresses gzip/bzip2/xz/lzma by magic - this busybox has NO zstd
# ("no gzip/bzip2/xz magic" is the error it prints). CONFIG_MODULE_DECOMPRESS
# does not help either: busybox reads the file itself and calls init_module(),
# never finit_module(MODULE_INIT_COMPRESSED_FILE).
#
# So with zstd every module in initramfs.load silently fails to load:
# ufs-qcom/qcom_ice/phy-qcom-qmp-ufs -> no root device -> "VFS: Unable to
# mount root fs on unknown-block(0,0)", and phy-snps-eusb2 -> no UDC ->
# no usb0, no telnet on 172.16.42.1.
#
# 7.2 has no MODULE_COMPRESS_NONE symbol (it was replaced by the
# MODULE_COMPRESS bool + a type choice), so turn the bool off; olddefconfig
# then drops COMPRESS_ZSTD / COMPRESS_ALL / DECOMPRESS with it.
# CONFIG_MODULE_COMPRESS is not set

# --- RETRACTED 2026-09-20: CONFIG_QCOMTEE / CONFIG_ARM_QCOM_CPUFREQ_HW --
# were NOT disabled here in the end. Both were disabled for a while
# (2026-09-18) after the screen appeared to freeze right after "qcomtee:
# QTEE version 5.2.0", then right after "cpu cpu0: EM: created perf
# domain" -- diagnosed purely from photos of the framebuffer console, no
# serial/SSH/telnet available at the time to confirm the system was
# actually stuck.
#
# That diagnosis didn't survive scrutiny: in every one of those "hung"
# attempts the device stayed reachable over ping the whole time. A kernel
# truly wedged in a probe function (e.g. an SMC call that never returns)
# would eventually stop servicing network softirqs too, at least once
# nothing else is left running; ping staying up is much better explained
# by the boot actually completing (or getting close) while only the
# on-screen console stopped updating -- unreachable over SSH because
# sshd/networking-online wasn't there yet at that point in the bring-up,
# and unreachable over telnet because no telnet/debug shell was installed
# in userspace yet (added later, see device-motorola-rtwo's
# debug-telnetd.service / dropbear work).
#
# Separately and since confirmed on 2026-09-20 (see sm8550-motorola-rtwo.dts,
# the &dispcc override): the inherited U-Boot framebuffer genuinely does
# freeze on this board, root-caused to dispcc (Display Clock Controller)
# touching disp_cc_mdss_mdp_clk_src -- the MDP pixel clock still actively
# driving that inherited buffer -- during its own probe. CONFIG_QCOMTEE=m
# is a *module*, only autoloaded once udev coldplugs devices in the real
# systemd rootfs; CONFIG_ARM_QCOM_CPUFREQ_HW=y is built-in but its probe
# depends on OPP/interconnect data that isn't ready until roughly the same
# late-boot window (matches the global deferred-probe-timeout retry seen
# at ~11s in current dmesg). Both cluster in the same few seconds of boot
# as dispcc's own module autoload -- entirely consistent with "whatever
# happened to be the last line printed before the screen froze" rather
# than either of them being the actual cause of a hang.
#
# Re-enabled to their config-motorola-rtwo.aarch64 defaults
# (CONFIG_QCOMTEE=m, CONFIG_ARM_QCOM_CPUFREQ_HW=y). Re-test now that a
# debug telnet/SSH shell exists in userspace, so aliveness can be checked
# directly instead of inferred from a photo of a console that we now know
# can freeze independently of whether the system is actually up.

# --- ath12k: debug messages ON (WiFi bring-up diagnostic) ---------------
# The whole "WMI credit exhaustion" diagnosis so far was done BLIND: the
# only hard evidence was ath12k_wmi_cmd_send() printing "wmi command 16387
# timeout" after WMI_SEND_TIMEOUT_HZ, plus -11/-EAGAIN, which in this
# driver can ONLY come from ath12k_htc_send()'s "insufficient credits"
# path (wmi.c:412 wait_event_timeout -> cmd_send_nowait -> htc_send; no
# other error path in that chain returns -EAGAIN). Everything else --
# how many credits the endpoint started with, whether a single credit
# report ever came back -- was inferred, because every one of those facts
# is printed by an ath12k_dbg() call and config-motorola-rtwo.aarch64
# (inherited, never reviewed for this device) has
# "# CONFIG_ATH12K_DEBUG is not set", which compiles __ath12k_dbg() down
# to an empty inline (debug.h). We were reading a silent driver.
#
# With this on, the messages that answer the open question directly:
#   htc.c:543  "Target ready! transmit resources: %d size:%d"
#              -> htc->total_transmit_credits / target_credit_size, the
#                 initial credit budget the firmware advertises.
#   htc.c:104  "htc ep %d consumed %d credits (total %d)"   (every TX)
#   htc.c:166  "htc ep %d got %d credits (total %d)"        (every credit
#                 report parsed out of an RX trailer)
#   htc.c:96   "htc insufficient credits ep %d required %d available %d"
# all under ATH12K_DBG_HTC (0x4). Falsifiable prediction to check against
# them: if the firmware never returns a single credit, the number of WMI
# commands that succeed before the wall (INIT, SET_HW_MODE, ..., then the
# one PMF_QOS in ath12k_mac_start) should come out EXACTLY equal to the
# advertised initial budget -- and not one "got %d credits" line should
# ever appear. If instead credits do come back and then stop, the failure
# is somewhere else entirely and the "firmware never reports" theory dies.
#
# Enabled separately at runtime via the debug_mask module param (0644, so
# also writable through /sys/module/ath12k/parameters/debug_mask, and
# settable from the kernel cmdline as ath12k.debug_mask=0x66 even though
# ath12k is a module). Bits (debug.h): WMI 0x2 | HTC 0x4 | BOOT 0x20 |
# QMI 0x40. Cost when the mask is 0 is one branch per call site, and this
# is a bring-up kernel -- performance is not the constraint here.
CONFIG_ATH12K_DEBUG=y

# Firmware coredump on assert. WANT_DEV_COREDUMP/DEV_COREDUMP are already
# =y in the base config, so this only adds ath12k's own collector. It
# costs nothing while nothing crashes, and it settles a question the
# current evidence cannot: whether the firmware silently asserted at some
# point during bring-up (a dead firmware explains "credits never come
# back" completely). A dump would show up under /sys/class/devcoredump/.
CONFIG_ATH12K_COREDUMP=y

# Native display bring-up (CSOT NT37705 panel, see panel-novatek-nt37705.c).
# DRM_MSM is present as =m in the mainline base config; build it in so the
# mdss/dsi0 probe runs from the boot (the frame is committed by MSM itself,
# no simpledrm handover needed). DRM_DISPLAY_DSC_HELPER is already =y.
CONFIG_BACKLIGHT_CLASS_DEVICE=y
CONFIG_DRM_MSM=y
CONFIG_DRM_MSM_DSI=y
CONFIG_DRM_MIPI_DSI=y
CONFIG_DRM_PANEL=y
CONFIG_DRM_PANEL_NOVATEK_NT37705=y

# dispcc/gpucc built in (2026-09-25): as =m they only load once the rootfs is
# mounted (~17 s), after the 10 s deferred_probe_timeout. Their GDSCs are the
# power-domains of mdss and of the GPU SMMU, and genpd returns -ETIMEDOUT once
# the timeout expires: seen in r43 as "arm-smmu 3da0000.iommu: probe ... failed
# with error -110". Built-in DRM_MSM would hit the same wall on MDSS_GDSC.
CONFIG_SM_DISPCC_8550=y
CONFIG_SM_GPUCC_8550=y

# DRM_MSM "depends on QCOM_LLCC || QCOM_LLCC=n" (same for QCOM_OCMEM): with
# both =m in the base config, DRM_MSM=y above was silently capped to =m by
# olddefconfig (r44: msm.ko in the rootfs, nothing drove the panel from the
# initramfs). Build them in so DRM_MSM can really be =y.
CONFIG_QCOM_LLCC=y
CONFIG_QCOM_OCMEM=y

# DisplayPort por USB-C (2026-09-25). Cadena: mdss_dp0 -> QMP USB3/DP combo
# PHY -> redriver Parade PS5169 (typec-mux-ps5169.c, integrado en este
# paquete) -> conector de pmic-glink (altmode + HPD), con el FSA4480 moviendo
# AUX por los SBU. Todo =y a proposito: el DP es un componente de msm, y msm
# (panel interno incluido) no se enlaza hasta que el DP encuentra su PHY y
# su cadena de bridges; pmic_glink_altmode solo registra su bridge HPD
# despues de conseguir el FSA4480 y el redriver. Como =m, eso esperaria a
# que monte el rootfs (y en la debug shell no llegaria nunca).
CONFIG_TYPEC=y
CONFIG_PHY_QCOM_QMP=y
CONFIG_PHY_QCOM_QMP_COMBO=y
CONFIG_DRM_AUX_BRIDGE=y
CONFIG_DRM_AUX_HPD_BRIDGE=y
CONFIG_QCOM_PMIC_GLINK=y
CONFIG_I2C_QCOM_GENI=y
CONFIG_TYPEC_MUX_FSA4480=y
CONFIG_TYPEC_MUX_PS5169=y