diff --git a/board/qualcomm/qcom-phone.env b/board/qualcomm/qcom-phone.env
index 7e5d9ce9..c2c8846f 100644
--- a/board/qualcomm/qcom-phone.env
+++ b/board/qualcomm/qcom-phone.env
@@ -22,14 +22,242 @@ serial_gadget=setenv stdin serial,button-kbd,usbacm; \
 # then bail out to the boot menu instead (with a pause to read
 # the error message)
 #
-# rtwo (Motorola Edge 40 Pro, SM8550): the ABL loads the FIT image
-# (mainline Image + dtb + initramfs) into the ramdisk slot of the
-# Android boot.img. The ABL writes that address into
-# /chosen/linux,initrd-start of the fdt it hands us, and U-Boot saves
-# it as $prevbl_initrd_start_addr (CONFIG_SAVE_PREV_BL_INITRAMFS_START_ADDR).
-# Try that first; only fall back to the phone menu if it fails.
-pmos_bootargs=earlycon console=ttyMSM0,115200n8 panic=5 pmos.debug-shell clk_ignore_unused pd_ignore_unused regulator_ignore_unused allow_mismatched_32bit_el0 pmos_boot_uuid=d4373976-057c-4cf3-a43d-00734001b405 pmos_root_uuid=09804032-85bb-4d57-95a5-00d1965fb10f pmos_rootfsopts=defaults
-bootcmd=setenv bootargs $pmos_bootargs; echo pmOS: booting FIT at prevbl_initrd_start_addr=$prevbl_initrd_start_addr; bootm $prevbl_initrd_start_addr; echo pmOS: bootm failed; bootefi bootmgr; pause; run menucmd
+# rtwo (Motorola Edge 40 Pro, SM8550): the FIT image (mainline Image +
+# dtb + initramfs) is packed by pack-fixedoff.py at a FIXED FILE OFFSET
+# (0x18c000) inside boot_a -- same offset the ABL uses to load kernel/
+# dtb, discovered via RE because this ABL does NOT follow the standard
+# Android boot.img formula. Confirmed in hardware (2026-09-17): trusting
+# $prevbl_initrd_start_addr (CONFIG_SAVE_PREV_BL_INITRAMFS_START_ADDR,
+# i.e. what the ABL claims via /chosen/linux,initrd-start) fails with
+# "ERROR -91E: can't get kernel image!" (EPROTOTYPE, no FIT magic at
+# that address) -- consistent with the ABL's fixed-offset loading not
+# populating that property correctly either. So: read the FIT ourselves
+# straight from boot_a at the known offset via the UFS/SCSI block layer
+# (preboot already did `scsi scan`) into $ramdisk_addr_r (128 MiB
+# scratch region board_late_init reserves, arch/arm/mach-snapdragon/
+# board.c). Block size is derived at runtime (100663296 / blocks-in-
+# partition) instead of assumed, since we don't know if this UFS LU
+# reports 512B or 4096B logical blocks. Falls back to the old
+# prevbl_initrd_start_addr attempt, then to the phone menu, if this
+# fails -- see memoria rtwo-uboot-chainload-fit-raw-read.
+pmos_bootargs=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 pmos_boot_uuid=d97fabaa-100c-47f0-960c-6c09b2ff0841 pmos_root_uuid=91b412b8-cdef-4021-babe-a4e50295329c pmos_rootfsopts=defaults
+# 2026-09-25: plymouth REHABILITADO y kernel silencioso ('quiet splash'; quitados
+# ignore_loglevel, systemd.log_target=kmsg y plymouth.enable=0 del bring-up).
+# Sincronizado con deviceinfo. Para depurar: opcion 1 del menu (debug shell) o
+# volver a agregar ignore_loglevel.
+# 'clk/pd/regulator_ignore_unused' QUITADOS 2026-09-25 (sincronizado con deviceinfo):
+# probados desde el menu (opciones de PRUEBA, ya retiradas). El kernel apaga
+# relojes (LPASS, rpmh _ao, qdss, ipa) y dominios sin uso; ningun regulador se
+# apaga (Linux nunca voto esos rieles rpmh). Panel, WiFi, USB, tactil, bateria,
+# ADSP/CDSP verificados OK.
+# 'msm.separate_gpu_kms=1 deferred_probe_timeout=30' AGREGADOS 2026-09-25 (sincronizado con
+# deviceinfo): bring-up del panel NT37705. separate_gpu_kms evita que el
+# display espere al GPU (adreno no llega a probe: su SMMU fallo con -110 en
+# r43); el timeout de 30 s cubre modulos que recien cargan al montar rootfs.
+# 'ath12k.debug_mask=0x66' QUITADO 2026-09-22 (sincronizado con deviceinfo):
+# el WiFi del rtwo ya funciona y el mask inundaba dmesg con el header de
+# cada HTC RX + cada mensaje WMI (bits WMI 0x2|HTC 0x4|BOOT 0x20|QMI 0x40,
+# solo compilados con CONFIG_ATH12K_DEBUG=y, kernel pkgrel>=40). Si vuelve
+# a hacer falta diagnostico, re-agregar exactamente: ath12k.debug_mask=0x66
+# 'cpuidle.off=1' AGREGADO 2026-09-21 (sincronizado con deviceinfo, ver
+# comentario ahi con el mismo fechado): prueba para aislar el reset random
+# de un cuelgue en C-state profundo via PSCI CPU_SUSPEND.
+# CONFIRMADO EN HARDWARE 2026-09-22: el reset random no volvio a aparecer
+# (junto con videocc_sm8550 reactivado y CONFIG_GUNYAH_WATCHDOG=y) -- FIX
+# VIGENTE, no sacar sin bisectar primero.
+# UUIDs actualizados 2026-09-18 (de nuevo): cada 'pmbootstrap install' genera
+# UUIDs al azar para pmOS_boot/pmOS_root -- hay que resincronizar esto ACA
+# despues de CUALQUIER install nuevo (paso 3 de rebuild-full.sh), antes de
+# armar rootfs-raw-new.img y reflashear, o el init nunca encuentra el root
+# real. Verificar con: fdisk -b 4096 -l rootfs-raw-new.img (offsets de
+# particion) + dd+blkid sobre cada una (ver conversacion 2026-09-18).
+# 'console=ttyMSM0,115200n8' sacado (2026-09-18), en sincronia con deviceinfo:
+# no hay UART real enganchado, la consola real es la de framebuffer (tty0).
+# 'random.trust_cpu=on' AGREGADO (2026-09-18): sshdgenkeys.service
+# (ExecStart=ssh-keygen -A) se cuelga en getrandom() -- confirmado ping
+# responde pero ssh/sshd nunca arranca, y no hay ningun telnetd en el
+# rootfs real (ese solo vivia en el initramfs de pmos.debug-shell). Sin
+# CONFIG_CRYPTO_DEV_QCOM_RNG matcheando el DT (compatible "qcom,trng" del
+# SoC, ese driver es para "qcom,prng" viejo) y sin confirmar que
+# ARM_SMCCC_TRNG funcione contra firmware downstream de Motorola (mismo
+# patron que QTEE/sleep_clk/cpufreq-hw en este bring-up), el CRNG puede
+# no inicializarse nunca solo. Cortex-X3/A715 de este SoC implementan
+# RNDR (ARMv8.5 FEAT_RNG); esto le dice al kernel que confie en esa
+# instruccion para sembrar el CRNG de una sin esperar entropia de
+# interrupciones ni un HWRNG por DT.
+# 'printk.devkmsg=on' AGREGADO 2026-09-21, INSUFICIENTE POR SI SOLO: se
+# penso que la causa de que la pantalla del framebuffer se "congele" en
+# medio del boot (aunque el equipo siga vivo por red) era el rate-limit del
+# KERNEL a las escrituras de userspace en /dev/kmsg -- confirmado en
+# hardware que NO alcanza: con este flag solo, la linea reveladora
+# "systemd[1]: Too many messages being logged to kmsg, ignoring" sigue
+# apareciendo exactamente igual. '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 (RATELIMIT_STATE_DEFINE, independiente de
+# printk.devkmsg), documentado como $SYSTEMD_LOG_RATELIMIT_KMSG /
+# systemd.log_ratelimit_kmsg= en systemd(1)/kernel-command-line(7)
+# (boolean, default true). Se deja printk.devkmsg=on de todos modos (no
+# molesta, y sigue siendo necesario para que systemd pueda ESCRIBIR a
+# /dev/kmsg sin CAP_SYSLOG restrictions en algunos casos), pero el fix
+# real para el freeze es este segundo flag. Ver comentario igual en
+# device-motorola-rtwo/deviceinfo. CONFIRMADO EN HARDWARE QUE TAMPOCO
+# ALCANZA: el usuario reporto que despues del freeze NO aparece ningun
+# mensaje nuevo en pantalla, ni siquiera los timeouts de WMI del kernel que
+# se repiten cada ~13s (esos SI se siguen generando en el ring buffer,
+# confirmado por SSH). Eso descarta cualquier teoria de "se generan menos
+# mensajes" -- el framebuffer literalmente deja de refrescarse, sin
+# relacion con el volumen de logging.
+#
+# 'cpufreq.default_governor=performance' AGREGADO 2026-09-21 (tercer
+# intento, DIAGNOSTICO): el .dts del dispositivo
+# (sm8550-motorola-rtwo.dts lineas 721-754) ya documenta que dispcc
+# habilitado por defecto GLITCHEA disp_cc_mdss_mdp_clk_src (el reloj de
+# pixeles del MDP que el ABL/U-Boot deja corriendo para seguir escaneando
+# el framebuffer heredado) porque clk_rcg2_shared_init() sincroniza TODOS
+# los RCG del controlador al hacer probe -- fix aplicado ahi:
+# '&dispcc { status = "disabled"; }', confirmado que sigue vigente. Pero
+# el freeze persiste con ese fix ya puesto, asi que algo MAS sigue tocando
+# ese mismo reloj heredado por una via distinta a la del propio driver de
+# dispcc (que ya esta bloqueada). Hipotesis: GCC (habilitado normalmente)
+# comparte una PLL padre con ese reloj de pixeles, y cuando el gobernador
+# de cpufreq empieza a escalar la frecuencia de CPU (justo despues de que
+# el boot termina y baja la carga -- la misma ventana de tiempo donde
+# aparece el freeze en los dumps), toca esa PLL compartida y glitchea
+# indirectamente el reloj heredado, sin que dispcc haga probe. Este flag
+# fija el governor a 'performance' (sin escalado dinamico) para probar si
+# eso evita el glitch. CONFIRMADO EN HARDWARE QUE TAMPOCO ALCANZA: freeze
+# identico con el governor fijo en performance -- descarta cpufreq DVFS
+# como causa.
+#
+# Con este punto YA se descartaron 4 hipotesis con evidencia real: rate
+# limit del kernel, rate limit de systemd, cpufreq, Y (via dmesg | grep
+# WARNING/clk_rcg2/update_config/genpd/regulator_set_voltage, todo vacio
+# salvo 'PM: genpd: Not disabling unused power domains') el mecanismo
+# exacto de dispcc pero via otro controlador (videocc/camcc) -- no aparece
+# ningun warning de esa familia, asi que ese mecanismo especifico tampoco
+# es. Tambien confirmado por el usuario que el freeze pasaba INCLUSO ANTES
+# de que existieran los nodos de WiFi en el .dts -- descarta PCIe/ath12k
+# como causa (la correlacion de ~0.5-0.7s con la deteccion del chip WiFi en
+# los dumps es coincidencia de timing, no causal).
+#
+# 'systemd.mask=systemd-udev-trigger.service' PROBADO 2026-09-21 (cuarto
+# intento, BISECCION): confirmado en hardware que CON esto el freeze
+# DESAPARECE (pantalla se mantuvo viva, mostro "emergency mode" en vez de
+# congelarse) -- prueba definitiva de que es un driver/modulo cargado
+# durante el coldplug de udev, no un timeout de hardware. PERO bloquear
+# el coldplug entero rompe el boot normal (systemd cae a emergency mode
+# sin red -- probablemente porque el propio descubrimiento de
+# particiones/interfaz USB de red tambien depende de udev). SACADO por
+# eso, 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, BISECCION mas quirurgica) -- CONFIRMADO EN
+# HARDWARE QUE ESTE ES EL FIX: con estos 3 modulos bloqueados, boot
+# completo normal (SSH/red funcionando) Y la pantalla llega hasta el
+# login prompt sin congelarse. NO SE AISLO cual de los tres en particular
+# es el culpable real (el usuario no necesita GPU/video-codec/camara en
+# este bring-up, asi que no vale la pena bisectar mas por ahora) -- si en
+# el futuro hace falta reactivar alguno de los tres (ej. GPU para
+# aceleracion grafica), hay que sacarlo de esta lista de a uno, probar en
+# hardware con la pantalla, y si alguno individualmente reproduce el
+# freeze, ese es el candidato para deshabilitar a nivel .dts (status =
+# "disabled", mismo patron que dispcc) en vez de blacklistear el modulo
+# via cmdline. FIX VIGENTE.
+# 'gpucc_sm8550' SACADO de la lista (2026-09-21) para empezar el bisect
+# de a uno (sincronizado con deviceinfo, ver comentario ahi con el mismo
+# fechado para el razonamiento completo). videocc_sm8550/camcc_sm8550
+# SIGUEN blacklisteados.
+# 'videocc_sm8550' SACADO 2026-09-21 mas tarde (sincronizado con
+# deviceinfo, ver comentario ahi para el razonamiento completo sobre
+# HW_CTRL_TRIGGER en video_cc_mvs0/mvs1_gdsc). camcc_sm8550 SIGUE
+# blacklisteado. CONFIRMADO EN HARDWARE 2026-09-22: reset random resuelto,
+# ver comentario de cpuidle.off=1 mas arriba.
+# (Historial de UUIDs viejos borrado -- cambian en CADA 'pmbootstrap install',
+# no vale la pena llevar el registro aca. Ver el comentario de arriba, junto
+# a pmos_bootargs, para el procedimiento de resincronizarlos.)
+# DEBUG rtwo 2026-09-18: systemd.log_level=debug + log_target=kmsg agregados
+# para diagnosticar por que "pmos_continue_boot" se cuelga despues de
+# "Reached target Local Encrypted Volumes" (confirmado que NO es cifrado --
+# /etc/crypttab no existe en el rootfs, --no-fde). Con esto los mensajes de
+# arranque de systemd (que Plymouth normalmente oculta de la consola visible)
+# van al kernel printk, que CONFIG_PSTORE_CONSOLE ya captura en la region
+# ramoops (0xae000000) -- se puede leer el intento colgado desde CUALQUIER
+# boot posterior (incluida la consola de debug) con
+# 'cat /sys/fs/pstore/console-ramoops-0', sin UART. Quitar una vez
+# encontrada la unidad que cuelga.
+# ESTADO 2026-09-17: vuelto a dejar tal cual quedo justo despues del PRIMER
+# cambio de la implementacion EFI (antes de corregir el offset del ramdisk
+# de imxtract y antes de sacar ignore_loglevel) -- checkpoint pedido para
+# retomar la exploracion del camino EFI, esta vez via una particion real
+# (userdata) en vez del RAM-only que se probo primero.
+#
+# DEBUG 2026-09-17 (quinta vuelta): probar el camino EFI en vez de bootm+FIT.
+# bootefi usa boot/efi_loader (AllocatePages/LoadFile2) para el initrd, no
+# boot_ramdisk_high()/LMB "high address" -- codigo completamente distinto,
+# asi que el bug de orden fijo start/loados/ramdisk/fdt de bootm no aplica
+# aca. Ademas, en el lado del kernel, el stub EFI arm64 (CONFIG_EFI_STUB=y,
+# ya compilado) carga el initrd via efi_load_initrd()/LoadFile2, que NUNCA
+# pasa por early_init_dt_check_for_initrd()/reserve_initrd_mem() -- el
+# chequeo memblock_is_region_reserved() que sospechabamos ni siquiera se
+# ejecuta para este camino. bootargs se sigue pasando igual (bootefi
+# convierte $bootargs a UTF-16 como load options).
+#
+# Mismo FIT de siempre (sin repackaging), pero en vez de bootm lo parseamos
+# con imxtract (CONFIG_CMD_XIMG=y, ya compilado) para sacar cada sub-imagen
+# a una direccion de RAM aparte:
+#   - kernel -> $kernel_addr_r (misma que bootm usaba para relocar)
+#   - fdt    -> $fdt_addr_r (la misma que bootmenu_10 ya usa con exito)
+#   - ramdisk -> $kernel_comp_addr_r (NO un offset inventado desde
+#     $ramdisk_addr_r -- eso fue el bug original: $ramdisk_addr_r + 0x8000000
+#     coincidia EXACTO con $kernel_addr_r y piso el kernel ya extraido
+#     ("No UEFI binary known at <addr>"). Investigado en la lista de U-Boot
+#     (parche "mach-snapdragon: dynamic load addresses", 2026): board.c
+#     arma estas variables como bloques LMB DEDICADOS y consecutivos --
+#     kernel_addr_r=128MiB, ramdisk_addr_r=128MiB (por eso el offset exacto
+#     de 0x8000000=128MiB), kernel_comp_addr_r=64MiB, fdt_addr_r=2MiB. El
+#     bug de fondo era usar $ramdisk_addr_r para algo que NO es su proposito
+#     (nuestro buffer crudo del FIT completo, ~55 MiB) y encima calcular un
+#     offset a mano dentro de ese mismo bloque de 128 MiB, invadiendo el
+#     vecino. $kernel_comp_addr_r es un bloque separado, dedicado a
+#     descomprimir un kernel comprimido -- el nuestro (Image sin comprimir,
+#     CONFIG_EFI_ZBOOT apagado) no lo usa, asi que esta libre y garantizado
+#     sin solaparse con ningun otro _addr_r por construccion.
+# imxtract fija $filesize despues de cada extraccion (confirmado en
+# cmd/ximg.c), por eso el tamano del ramdisk y del kernel se guardan aparte
+# antes de que la siguiente llamada los pise.
+#
+# 2026-09-18: "No UEFI binary known at <addr>" seguia apareciendo incluso
+# con las tres direcciones ya sin solaparse (kernel_comp_addr_r confirmado
+# en hardware como un bloque separado y limpio). Causa real, en
+# cmd/bootefi.c:204-226 (do_bootefi_image): si el PRIMER argumento de
+# `bootefi` NO lleva ":tamano", el comando asume que la direccion ya viene
+# de un `load`/`tftp` previo (que actualiza un registro interno de "ultima
+# imagen cargada" via efi_set_image_parameters()) y compara contra ESE
+# registro -- si no matchea (o nunca se seteo, como en nuestro caso porque
+# usamos `imxtract`, que NO actualiza ese registro), falla con este mensaje
+# sin importar que los bytes en esa direccion sean un kernel EFI valido.
+# Fix: pasarle ":tamano" tambien al kernel (no solo al ramdisk, que ya lo
+# llevaba) -- eso fuerza la rama que trata la direccion como explicita
+# (efi_clear_bootdev()) sin depender de ningun registro previo.
+#
+# Si bootefi no funciona por algun motivo, cae al `bootm` de siempre como
+# red de seguridad (mismo fallback que ya existia).
+# Carga el FIT desde boot_a (antes era el bootcmd entero). Lo usan las
+# opciones del menu, cada una con sus propios bootargs.
+pmos_boot=if part start scsi 3 boot_a boot_a_start && part size scsi 3 boot_a boot_a_size; then setexpr blksz 0x6000000 / $boot_a_size; setexpr fit_blk_off 0x18c000 / $blksz; setexpr fit_lba $boot_a_start + $fit_blk_off; setexpr fit_blk_cnt $boot_a_size - $fit_blk_off; echo pmOS: boot_a start=$boot_a_start size=$boot_a_size blksz=$blksz fit_lba=$fit_lba fit_cnt=$fit_blk_cnt; scsi dev 3; if scsi read $ramdisk_addr_r $fit_lba $fit_blk_cnt; then echo pmOS: FIT read OK, addr=$ramdisk_addr_r; setenv verify no; setenv initrd_stage_addr $kernel_comp_addr_r; if imxtract $ramdisk_addr_r kernel $kernel_addr_r; then setenv kernel_stage_size $filesize; echo pmOS: kernel extracted addr=$kernel_addr_r size=$kernel_stage_size; if imxtract $ramdisk_addr_r fdt $fdt_addr_r; then echo pmOS: fdt extracted addr=$fdt_addr_r size=$filesize; run pmos_fdt_fixup; if imxtract $ramdisk_addr_r ramdisk $initrd_stage_addr; then setenv initrd_stage_size $filesize; echo pmOS: ramdisk extracted addr=$initrd_stage_addr size=$initrd_stage_size; echo pmOS: trying bootefi; bootefi $kernel_addr_r:$kernel_stage_size $initrd_stage_addr:$initrd_stage_size $fdt_addr_r; echo pmOS: bootefi returned, should not happen; else echo pmOS: ramdisk imxtract FAILED; fi; else echo pmOS: fdt imxtract FAILED; fi; else echo pmOS: kernel imxtract FAILED; fi; else echo pmOS: scsi read of FIT failed; fi; else echo pmOS: could not resolve boot_a partition; fi; echo pmOS: bootefi path failed, trying old bootm path via prevbl_initrd_start_addr=$prevbl_initrd_start_addr; bootm $prevbl_initrd_start_addr; echo pmOS: bootm failed; bootefi bootmgr; pause; run menucmd
+# 2026-09-25 (DisplayPort): gancho que pmos_boot corre despues de extraer el
+# FDT y antes de bootefi. Por defecto no toca nada. La opcion 2 del menu lo
+# apunta a pmos_nodp_fixup, que deshabilita mdss_dp0: el DP es componente de
+# msm, y si la cadena Type-C (PS5169/FSA4480/QMP/pmic-glink) no hace probe el
+# panel interno tampoco arranca -- esta es la salida de emergencia.
+pmos_fdt_fixup=echo pmOS: FDT sin cambios
+pmos_nodp_fixup=fdt addr $fdt_addr_r; fdt resize; fdt set /soc@0/display-subsystem@ae00000/displayport-controller@ae90000 status disabled; echo pmOS: DisplayPort deshabilitado en el FDT
+# 2026-09-25: menu con cuenta regresiva de 3 s. Sin tocar nada arranca
+# bootmenu_0 (pmOS normal, SIN debug shell); cualquier boton detiene la
+# cuenta (vol arriba/abajo navegan, encendido elige). bootmenu_1 arranca
+# con pmos.debug-shell. Vol abajo al encender sigue abriendo el menu.
+bootcmd=bootmenu 3
 
 # When entering the menu (either from button press or failed boot)
 # remap bootcmd so it will re-open the menu and we won't get stuck
@@ -37,19 +265,25 @@ bootcmd=setenv bootargs $pmos_bootargs; echo pmOS: booting FIT at prevbl_initrd_
 menucmd=setenv bootcmd run menucmd; bootmenu -1
 
 # Pause is used so the output can be read on the display
-bootmenu_0=Boot pmOS mainline (FIT)=setenv bootargs $pmos_bootargs; bootm $prevbl_initrd_start_addr; pause
-bootmenu_1=Boot=bootefi bootmgr; pause
-bootmenu_2=Enable serial console gadget=run serial_gadget
-bootmenu_3=Enable USB mass storage=echo "Press any key to exit UMS mode"; ums 0 scsi 0
-bootmenu_4=Enable fastboot mode=echo "Press any key to exit fastboot mode"; run fastboot
+bootmenu_0=Arrancar pmOS=setenv bootargs $pmos_bootargs; run pmos_boot
+bootmenu_1=Arrancar pmOS con debug shell=setenv bootargs $pmos_bootargs pmos.debug-shell; run pmos_boot
+bootmenu_2=Arrancar pmOS sin DisplayPort=setenv pmos_fdt_fixup run pmos_nodp_fixup; setenv bootargs $pmos_bootargs; run pmos_boot
+bootmenu_3=Boot pmOS mainline (FIT)=setenv bootargs $pmos_bootargs; bootm $prevbl_initrd_start_addr; pause
+bootmenu_4=Boot=bootefi bootmgr; pause
+bootmenu_5=Enable serial console gadget=run serial_gadget
+bootmenu_6=Enable USB mass storage=echo "Press any key to exit UMS mode"; ums 0 scsi 0
+bootmenu_7=Enable fastboot mode=echo "Press any key to exit fastboot mode"; run fastboot
 # Disabling bootretry means we'll just drop the shell
-bootmenu_5=Drop to shell=setenv bootretry -1
-bootmenu_6=Reset device=reset
-bootmenu_7=Dump clocks=clk dump; pause
-bootmenu_8=Dump environment=printenv; pause
-bootmenu_9=Board info=bdinfo; pause
-bootmenu_10=Dump bootargs=fdt addr $fdt_addr_r; fdt print /chosen bootargs; pause
-bootmenu_11=Power off=poweroff
+bootmenu_8=Drop to shell=setenv bootretry -1
+bootmenu_9=Reset device=reset
+bootmenu_10=Dump clocks=clk dump; pause
+bootmenu_11=Dump environment=printenv; pause
+bootmenu_12=Board info=bdinfo; pause
+bootmenu_13=Dump bootargs=fdt addr $fdt_addr_r; fdt print /chosen bootargs; pause
+bootmenu_14=Power off=poweroff
+bootmenu_15=Diag SCSI boot_a=scsi scan; scsi info; pause; if part number scsi 0 boot_a i; then echo scsi0:part=$i; else echo scsi0:no-boot_a; fi; if part number scsi 1 boot_a i; then echo scsi1:part=$i; else echo scsi1:no-boot_a; fi; if part number scsi 2 boot_a i; then echo scsi2:part=$i; else echo scsi2:no-boot_a; fi; if part number scsi 3 boot_a i; then echo scsi3:part=$i; else echo scsi3:no-boot_a; fi; pause; if part number scsi 4 boot_a i; then echo scsi4:part=$i; else echo scsi4:no-boot_a; fi; if part number scsi 5 boot_a i; then echo scsi5:part=$i; else echo scsi5:no-boot_a; fi; if part number scsi 6 boot_a i; then echo scsi6:part=$i; else echo scsi6:no-boot_a; fi; if part number scsi 7 boot_a i; then echo scsi7:part=$i; else echo scsi7:no-boot_a; fi; pause
+bootmenu_16=Diag USB gadget=dm uclass usb_gadget; pause; dm uclass usb; pause; dm uclass phy; pause
+bootmenu_17=Diag UFS=dm uclass ufs; pause; dm uclass phy; pause; ufs init 0; echo ufs_init_ret=$?; pause
 
 # Allow holding the volume down button while U-Boot loads to enter
 # the boot menu