pmaports-rtwo/device/testing/device-motorola-rtwo/deviceinfo

# Reference: <https://postmarketos.org/deviceinfo>
# Please use double quotes only. You can source this file in shell
# scripts.

deviceinfo_format_version="0"
deviceinfo_name="Motorola Moto Edge 40 Pro"
deviceinfo_manufacturer="Motorola"
deviceinfo_codename="motorola-rtwo"
deviceinfo_year="2023"
deviceinfo_dtb="qcom/sm8550-motorola-rtwo"
deviceinfo_arch="aarch64"

# Device related
deviceinfo_chassis="handset"
deviceinfo_keyboard="false"
deviceinfo_external_storage="true"
deviceinfo_screen_width="1080"
deviceinfo_screen_height="2400"
deviceinfo_getty="ttyMSM0;115200"
deviceinfo_no_framebuffer="true"

# UN SOLO initramfs, sin initramfs-extra. Es lo que hace que
# 'pmos.debug-shell' sirva de algo: init_2nd.sh (y con el, la rama
#     if [ "$debug_shell" = "y" ]; then debug_shell; fi
# ) vive en el paquete de ficheros -extra, o sea DENTRO del rootfs, que en
# este equipo no podemos flashear. Con extra separado, jump_init_2nd() del
# stage 1 es un no-op, la bandera de la cmdline no la lee nadie y el unico
# camino a la shell de depuracion es agotar los 30 s de wait_boot_partition
# -> fail_halt_boot. Fusionandolo, init.sh salta a init_2nd.sh de inmediato,
# que hace setup_udev + setup_usb_network + start_unudhcpd y ENTONCES entra
# en debug_shell: telnet en 172.16.42.1:23 y getty en /dev/ttyGS0 en cuanto
# el USB enumera, sin depender de ninguna particion.
# El coste (initramfs de 3 MiB -> ~15 MiB) ya no importa: con cabecera v2 el
# ramdisk va DENTRO de boot.img, no en init_boot, y boot_a admite 96 MiB.
deviceinfo_create_initfs_extra="false"
# The stock LineageOS boot chain packs both Android-v4 ramdisks with LZ4
# legacy. When the bootloader concatenates our vendor_ramdisk with the
# init_boot ramdisk, a gzip stream after an LZ4-legacy one makes the
# kernel's unpacker choke ("invalid magic" -> panic unknown-block(0,0)).
# Match the stock format.
deviceinfo_initfs_compression="lz4:legacy"

# Bootloader: Android 13 GKI. The kernel goes in boot, the DTB + cmdline +
# initramfs in vendor_boot. init_boot holds the generic (first-stage)
# ramdisk - it MUST be replaced with pmOS's, or the stock AOSP /init runs.
# Lessons folded in from device-motorola-dubai (the closest working
# Motorola mainline port) and the stock LineageOS images.
deviceinfo_flash_method="fastboot"
# Keep flashing dtbo, and keep it EMPTY. The ABL overlays whatever sits in
# the dtbo partition on top of the DTB it took from vendor_boot, and a stock
# overlay applied to a mainline DTB mangles it - the documented advice for
# mainline on Qualcomm is to erase the dtbo partition or program NULL to it.
# The dtbo.img pmbootstrap generates here is 24 MiB of zeroes (no DTBO magic,
# no entries), so flashing it IS that "program NULL" step: it wipes the
# LineageOS/stock table (32 entries) that a restore-to-stock puts back.
# Do not drop this line expecting the ABL to skip overlays - dropping it
# leaves the stock table in place.
deviceinfo_flash_fastboot_partition_dtbo="dtbo"
deviceinfo_flash_fastboot_partition_vbmeta="vbmeta"
# CONSOLA REAL POR UART (2026-09-13, sin framebuffer en el .dts): console=
# apunta ahora a ttyMSM0 (uart7, GENI QUP0/SE7), no a tty0. Ya no hace falta
# el 'ignore_loglevel'+panic=5-como-sustituto-de-consola: si el UART vive,
# vemos todo en tiempo real.
#
# 'earlycon' AGREGADO DE NUEVO (2026-09-13, segunda pasada). Se habia sacado
# a proposito por el riesgo real y documentado de fragilidad en el handover
# clk/earlycon (serie LKML "clk: help OF platforms with their stdout
# (earlycon) clocks during early boot", aun en v6) combinado con la sospecha
# de que DisableHypUartUsageForLogging() (SMC que el ABL llama antes de
# saltar al kernel, ver rtwo-abl-vs-abl-de-referencia) deje el UART en un
# estado raro para un acceso CRUDO y tempranisimo. Pero: 'console=ttyMSM0'
# SOLO (sin earlycon) no muestra nada hasta que el driver real de
# qcom_geni_serial prueba, lo cual exige que GCC y el pinctrl ya hayan
# probado antes - y CADA cuelgue que vimos en este bring-up paso muchisimo
# antes de eso (reset en 1-2s, antes de fbcon). Si el problema sigue siendo
# pre-driver, sin earlycon no veriamos nada, igual que en todos los intentos
# anteriores con framebuffer. Sin argumento usa /chosen/stdout-path (serial0
# -> &uart7, qcom,geni-debug-uart tiene OF_EARLYCON_DECLARE).
#
# 'panic=5': con consola real ya no es indispensable, pero se deja: si
# panickea en vez de colgarse, lo vemos en pantalla Y el registro queda en
# pstore/ramoops para la proxima vez.
# 'pmos.debug-shell': shell de depuracion por USB (telnet 172.16.42.1) con
# dmesg y pstore montados, si se llega al stage 2 del initramfs.
# 'allow_mismatched_32bit_el0' AGREGADO (2026-09-14): AYN Thor (mismo SoC,
# SD8 Gen 2 = SM8550, arranca ABL-directo sin U-Boot igual que nosotros) lo
# lleva en su receta de cmdline. Sin el, en el peor caso el kernel solo
# restringe apps de 32 bits en runtime (no bloquea el arranque segun el
# codigo fuente) - pero es gratis agregarlo: solo relaja una verificacion,
# nunca puede empeorar nada.
# 'console=tty0 ignore_loglevel' AGREGADO (2026-09-17): consola visual sobre
# el framebuffer@b8000000 reagregado al .dts del kernel, ver ese archivo.
# 'console=ttyMSM0,115200n8' SACADO (2026-09-18): no hay UART real
# enganchado en este bring-up, la consola que se usa de verdad es la de
# framebuffer (tty0, ver foto). Se deja 'earlycon' (bare, sin argumento)
# porque igual sale por /chosen/stdout-path sin bloquear nada aunque nadie
# lo lea.
# 'printk.devkmsg=on' AGREGADO (2026-09-21): con systemd.log_target=kmsg
# (ver qcom-phone.env), TODO el log visible en la consola de framebuffer
# sale de que systemd escribe activamente a /dev/kmsg -- inicialmente se
# penso que el kernel (printk.devkmsg=ratelimit por default) era el que
# cortaba esas escrituras con un rate-limit agresivo, disparando "Too many
# messages being logged to kmsg, ignoring" a los ~2-3s de systemd. FALSO,
# confirmado en hardware: con SOLO este flag el freeze sigue exactamente
# igual, misma linea. Se deja de todos modos (no molesta), ver el flag de
# abajo para el fix real.
# 'systemd.log_ratelimit_kmsg=false' AGREGADO (2026-09-21, segundo
# intento): el rate-limit real es del propio systemd, no del kernel --
# write_to_kmsg() en systemd tiene su PROPIO limitador interno para
# escrituras a /dev/kmsg, totalmente independiente de printk.devkmsg.
# Documentado en systemd(1)/kernel-command-line(7) como
# $SYSTEMD_LOG_RATELIMIT_KMSG / systemd.log_ratelimit_kmsg= (boolean,
# default true). CONFIRMADO EN HARDWARE QUE ESTE FLAG TAMPOCO ALCANZA: el
# usuario reportó que después del freeze NO aparece ningún mensaje nuevo,
# ni siquiera los timeouts de WMI del kernel que se repiten cada ~13s
# (esos SÍ se siguen generando en el ring buffer real, confirmado por
# SSH). Descarta cualquier teoría de "se generan menos mensajes" -- el
# framebuffer literalmente deja de refrescarse, sin relación con volumen
# de logging.
# 'cpufreq.default_governor=performance' AGREGADO (2026-09-21, tercer
# intento, DIAGNÓSTICO): el .dts del kernel
# (sm8550-motorola-rtwo.dts líneas 721-754) ya documenta que dispcc
# habilitado por defecto glitchea disp_cc_mdss_mdp_clk_src (el reloj de
# píxeles del MDP que el ABL/U-Boot deja corriendo para seguir escaneando
# el framebuffer heredado), fix aplicado ahí ('&dispcc { status =
# "disabled"; }', confirmado vigente) -- pero el freeze persiste con ese
# fix puesto, así que algo MÁS sigue tocando ese mismo reloj heredado por
# una vía distinta. Hipótesis: GCC comparte una PLL padre con ese reloj de
# píxeles, y el escalado dinámico de cpufreq (que arranca justo cuando el
# boot termina y baja la carga -- la misma ventana donde aparece el
# freeze) la glitchea indirectamente. Este flag fija el governor a
# 'performance' para probar si evita el glitch. CONFIRMADO EN HARDWARE QUE
# TAMPOCO ALCANZA: freeze idéntico con el governor fijo -- descarta
# cpufreq DVFS.
#
# Con 4 hipótesis descartadas con evidencia real (rate limit kernel, rate
# limit systemd, cpufreq, y el mecanismo de dispcc vía otro controlador --
# dmesg | grep WARNING/clk_rcg2/update_config/genpd no muestra nada salvo
# "PM: genpd: Not disabling unused power domains", y el usuario confirmó
# que el freeze pasaba INCLUSO ANTES de que existieran los nodos de WiFi
# en el .dts, descartando PCIe/ath12k), toca dejar de adivinar QUÉ driver
# específico es y aislar CUÁNDO pasa.
# 'systemd.mask=systemd-udev-trigger.service' PROBADO (2026-09-21, cuarto
# intento): CONFIRMADO EN HARDWARE que con esto el freeze DESAPARECE
# (pantalla mostró "emergency mode" en vez de congelarse) -- prueba
# definitiva de que es un driver/módulo cargado durante el coldplug de
# udev, no un timeout de hardware. Pero bloquear el coldplug entero rompe
# el boot normal (cae a emergency mode sin red, probablemente porque el
# descubrimiento de particiones/interfaz USB de red también depende de
# udev). SACADO, reemplazado por el flag de abajo para bisectar sin
# romper el boot.
# 'module_blacklist=gpucc_sm8550,videocc_sm8550,camcc_sm8550' AGREGADO
# (2026-09-21, quinto intento) -- CONFIRMADO EN HARDWARE QUE ES EL FIX:
# con estos 3 bloqueados, boot completo normal (SSH/red ok) y la pantalla
# llega al login prompt sin congelarse. NO se aisló cuál de los tres en
# particular es el culpable real -- el bring-up actual no necesita
# GPU/video-codec/cámara, así que no vale la pena bisectar más por ahora.
# Si en el futuro hace falta reactivar alguno (ej. GPU para aceleración
# gráfica), sacarlo de esta lista de a uno y probar en hardware; si
# individualmente reproduce el freeze, deshabilitarlo a nivel .dts
# (status = "disabled", mismo patrón que dispcc) en vez de blacklistear
# el módulo. FIX VIGENTE.
# 'gpucc_sm8550' SACADO de la lista (2026-09-21) para empezar el
# bisect de a uno, siguiendo el plan de arriba -- es el primer candidato
# porque es el unico de los tres con un caso de uso real a corto plazo
# (aceleracion grafica). El .dts no tiene NINGUN nodo de GPU (no hay
# Adreno/zap-shader, se verifico: sm8550-motorola-rtwo.dts no menciona
# "adreno"/"gpu@" en ningun lado), asi que gpucc queda habilitado por
# defecto desde sm8550.dtsi (como dispcc, ver comentario de &dispcc mas
# abajo) sin ningun consumidor todavia. Si el freeze vuelve, la sospecha
# recae en gpucc_sm8550 y el fix pasa a &gpucc { status = "disabled"; }
# en el .dts en vez del blacklist. videocc_sm8550/camcc_sm8550 SIGUEN
# blacklisteados -- no bisectar los tres a la vez.
# 'videocc_sm8550' SACADO de la lista (2026-09-21, mismo dia, mas tarde):
# reset random confirmado en hardware CON gpucc_sm8550 ya reactivado (asi
# que gpucc queda descartado como causa unica del reset). Leyendo el
# fuente real de gdsc_init() (drivers/clk/qcom/gdsc.c) contra los GDSC de
# cada controlador: video_cc_mvs0_gdsc/mvs1_gdsc tienen la flag
# HW_CTRL_TRIGGER (control autonomo por hardware del colapso de energia),
# la MISMA clase de flag que mdss_gdsc/mdss_int2_gdsc de dispcc (HW_CTRL) --
# dispcc tambien cambio de habilitado a disabled en el mismo fix del
# freeze, asi que es sospechoso que comparta este patron con videocc.
# camcc_sm8550 NO tiene ningun GDSC con HW_CTRL/HW_CTRL_TRIGGER/VOTABLE
# (todos "planos", solo POLL_CFG_GDSCR|RETAIN_FF_ENABLE) -- por eso queda
# BLACKLISTEADO todavia, es el candidato menos sospechoso de los tres.
# CONFIRMADO EN HARDWARE 2026-09-22: el reset random no volvio a pasar con
# videocc_sm8550 reactivado (junto con cpuidle.off=1 y CONFIG_GUNYAH_WATCHDOG,
# ver comentarios de abajo) -- no se aislo cual de los tres exactamente era
# necesario, pero con los tres juntos el reset desaparecio. No bisectar mas
# a menos que vuelva a aparecer.
# NOTA: esta linea documenta la cmdline "canonica" del dispositivo, pero el
# flujo de arranque VIGENTE es el chainload de U-Boot (ver
# rtwo-uboot-chainload en las notas del proyecto), que ignora esto y usa en
# cambio pmos_bootargs de ~/pmos/uboot-chainload/qcom-phone.env (mantenida
# en sincronia a mano con esta linea).
# 'ath12k.debug_mask=0x66' QUITADO 2026-09-22 (sincronizado con deviceinfo):
# el WiFi ya funciona y ese mask inundaba dmesg con cada header HTC RX y cada
# mensaje WMI (bits 0x2|0x4|0x20|0x40, solo presentes con CONFIG_ATH12K_DEBUG=y).
# Si vuelve a hacer falta diagnostico, re-agregar exactamente asi: ath12k.debug_mask=0x66
deviceinfo_kernel_cmdline="earlycon console=tty0 quiet splash panic=5 allow_mismatched_32bit_el0 random.trust_cpu=on printk.devkmsg=on systemd.log_ratelimit_kmsg=false cpufreq.default_governor=performance cpuidle.off=1 module_blacklist=camcc_sm8550 msm.separate_gpu_kms=1 deferred_probe_timeout=30"
# 'cpuidle.off=1' AGREGADO (2026-09-21): prueba para aislar si el reset
# random (siempre dentro de los primeros 5 min, nunca mientras corre algo)
# es un cuelgue al entrar/resumir de un C-state profundo via PSCI
# CPU_SUSPEND -- no hay overrides de idle-states/cpuidle en este .dts,
# heredamos lo que trae sm8550.dtsi sin validar en este hardware. Con esto
# las CPU solo usan WFI simple, nunca los estados profundos.
# CONFIRMADO EN HARDWARE 2026-09-22: el reset random no volvio a aparecer
# con esto puesto (junto con videocc_sm8550 reactivado y
# CONFIG_GUNYAH_WATCHDOG=y, ver arriba) -- FIX VIGENTE, no sacar. No se
# aislo cual de los tres cambios era el necesario especificamente; si algun
# dia hace falta reactivar cpuidle (ej. por consumo de bateria), bisectar
# de a uno en vez de sacar los tres juntos.
# CONFIG_GUNYAH_WATCHDOG=y (drivers/watchdog/gunyah_wdt.c, protocolo SMC con
# techo de ~32s) tambien esta activo -- no encajaba bien con la
# variabilidad de 0-5min del reset visto originalmente, pero se dejo activo
# sin costo real (el driver apaga el watchdog al hacer probe() si nadie
# abre /dev/watchdog) y forma parte del combo que resolvio el reset.
# CABECERA v2, NO v4 - y esta es la razon de fondo:
# DTBImgCheckAndAppendDT() coge el DTB de sitios distintos segun la version.
#   v3/v4: ImageBuffer = vendor_boot, DtbOffset = dentro de vendor_boot. Si el
#          match de qcom,msm-id/board-id falla, el fallback de "single appended
#          DTB" calcula ImageBuffer(=BOOT.IMG) + DtbOffset(=de vendor_boot), o
#          sea apunta DENTRO DEL KERNEL -> fdt_check_header falla ->
#          EFI_NOT_FOUND -> LoadImageAndAuth falla -> el ABL de Motorola hace
#          "Rebooting to retry" -> bootloop de 7 y a fastboot.
#   v2:    ImageBuffer y DtbOffset son AMBOS del boot.img, asi que el fallback
#          funciona y acepta nuestro DTB SIN comparar ningun ID.
# O sea: con v4 dependemos de acertar msm-id/board-id exactos; con v2 no
# dependemos de nada. device-motorola-dubai (mismo ABL de Motorola, puerto
# mainline que SI arranca) usa v2 por esto mismo.
deviceinfo_generate_bootimg="true"
deviceinfo_header_version="2"
deviceinfo_append_dtb="true"
deviceinfo_flash_offset_base="0x00000000"
deviceinfo_flash_offset_kernel="0x00008000"
deviceinfo_flash_offset_ramdisk="0x01000000"
deviceinfo_flash_offset_second="0x00000000"
deviceinfo_flash_offset_tags="0x00000100"
deviceinfo_flash_offset_dtb="0x01f00000"
deviceinfo_bootimg_qcdt="false"
deviceinfo_flash_pagesize="4096"
# Stock uses base 0 (mkbootimg defaults to 0x10000000, dtb ends up outside
# RAM). os_* to satisfy anti-rollback on the boot image.
deviceinfo_bootimg_custom_args="--base 0x00000000 --kernel_offset 0x00008000 --ramdisk_offset 0x01000000 --tags_offset 0x00000100 --dtb_offset 0x01f00000 --os_version 16.0.0 --os_patch_level 2026-08-01"
deviceinfo_flash_sparse="true"

# UFS storage
deviceinfo_rootfs_image_sector_size="4096"

# A/B device (androidboot.slot_suffix=_a). UFS controller: 1d84000.ufshc.
# Dynamic "super" partition (group "mot_dp_group", ~9.94 GB) holds
# system/system_ext/product/vendor/vendor_dlkm/system_dlkm. Resolve the real
# node from the initramfs debug shell:
#   ls -l /dev/disk/by-partlabel/super
# then uncomment (both fields = the super partition, A and B share it here):
# deviceinfo_super_partitions="/dev/disk/by-partlabel/super /dev/disk/by-partlabel/super"