1 votos

¿Cómo flasheo un kernel personalizado en Pixel 7?

Construí un kernel personalizado para mi Pixel 7, para incluir el módulo del kernel NFS. Estoy luchando por flashear esto en mi teléfono y hacer que se cargue.

Después de flashear esto en mi teléfono, aparece el texto Google, pero no la animación G que sigue. Se detiene con el siguiente mensaje:

Recuperación de Android

google/panther/panther

13/TQ1A.221205.011/9244662

user/release-keys

Utilice el volumen arriba/abajo y el botón de encendido.

No se puede cargar el sistema Android. Sus datos pueden estar corruptos. Si continúa recibiendo este mensaje, es posible que necesite realizar un restablecimiento de datos de fábrica y borrar todos los datos de usuario almacenados en el dispositivo.

  • [x] Intentar de nuevo
  • [ ] Restablecimiento de datos de fábrica

Para recuperarme de esto, volví a flashear la imagen panther-tq1a.221205.011.zip/image-panther-tq1a.221205.011/boot.img de fábrica.

Lo único que pude encontrar es donde el registro de arranque /sys/fs/pstore/console-ramoops-0 tiene el mensaje:

[  11.517099] [E] [DPM] check header failed
[  11.517105] [E] [LNXDBG] vendor combined_checksum must be 0x62352e30 but 0x620d2e30

Pensé que esto estaba relacionado con Android Verified Boot 2.0. Para probar esto, intenté flashear la imagen de fábrica y la imagen de vbmeta.img, con AVBv2 deshabilitado:

$ fastboot flash --disable-verification vbmeta vbmeta.img

Esto también sorprendentemente resulta en el bucle de arranque anterior. Para recuperarme tengo que flashear vbmeta.img sin esta bandera:

$ fastboot flash vbmeta vbmeta.img

Intenté parchear las banderas de vbmeta.img en el desplazamiento 0x7B para que fueran 3 (es decir, AVB_VBMETA_IMAGE_FLAGS_HASHTREE_DISABLED | AVB_VBMETA_IMAGE_FLAGS_VERIFICATION_DISABLED). Flasheé esto, y ocurrió el mismo bucle de arranque.

Mi teléfono está rooteado con Magisk.

2voto

Charley Wright Puntos 21

Esto puede no estar respondiendo exactamente a tu pregunta, pero es muy similar. Quería flashear KernelSU en mi Pixel 7, y así es como lo hice.

ESTO BORRARÁ TODOS LOS DATOS

Primero, toma nota de tu número de compilación. Para encontrarlo, ve a ajustes, acerca de, luego en la parte inferior está el "número de compilación". El mío es TQ3A.230605.012. Ve a developers.google.com/android/images y descarga la imagen para tu dispositivo. Asegúrate de descargar el archivo bajo el encabezado de dispositivo correcto, ya que el número de compilación puede ser utilizado para varios dispositivos.

Descomprimir este archivo y luego descomprimir el image-*.zip da como resultado varios archivos .img. Ahora necesitamos habilitar el modo desarrollador y la depuración USB tocando repetidamente el número de compilación, luego yendo a ajustes, sistema, opciones de desarrollador y habilitando la depuración USB.

Antes de que podamos flashear un kernel personalizado, necesitamos desactivar la verificación y la certificación. Hay una buena descripción de lo que son aquí por lo que no lo repetiré. Para desactivarlos, necesitamos volver a flashear vbmeta.img lo que borrará todos los datos en el dispositivo. Para hacerlo, reinicia en fastboot

adb reboot bootloader # Alternativamente, apaga el dispositivo, luego mantén presionado vol-down y power

sudo fastboot flash --disable-verity --disable-verification vbmeta ./vbmeta.img

Sudo se usa aquí debido a mis reglas udev, puede que no sea necesario para ti.
Ahora una vez que el dispositivo se inicie estará en la pantalla de configuración, siéntete libre de configurar el dispositivo aquí, eso es lo que hice yo.

El siguiente paso es preparar la imagen del kernel. Hay buenas instrucciones proporcionadas en la guía de instalación de KernelSU. Descargué Android-Image-Kitchen, desempaqueté boot.img, reemplacé boot.img-kernel con Image (Image se convierte en boot.img-kernel), luego volví a empaquetar la imagen dándole imagen-nueva.img. Nota: Si como yo tu kernel es android13-4, los AnyKernel zips para android13-5 funcionarán perfectamente

Luego podemos flashear nuestra nueva imagen reiniciando en fastboot (ver arriba) luego ejecutando

sudo fastboot flash boot ./imagen-nueva.img

Una vez que el dispositivo se reinicie, KernelSU debería estar disponible. Asegúrate de descargar su aplicación y habilitar su en tu emulador de terminal para que no entres en pánico cuando termux se queje de que no hay un binario su.

2voto

Geo242 Puntos 1

Si su dispositivo tiene el bootloader desbloqueado y está ejecutando un kernel compatible con GKI (como los dispositivos Pixel 6 y 7), entonces es posible actualizar el kernel central sin borrar los datos de usuario o deshabilitar la verificación si no cambia la ABI del kernel central; sin embargo, dado que varios módulos del kernel residen en la partición dinámica vendor_dlkm, no puede actualizar esos controladores en la partición dinámica sin deshabilitar la verificación, ya que el pie de árbol de hashes se verifica en la partición vbmeta_vendor (Consulte la Nota2).

Para hacer esto, necesitas:

  1. Agregar un pie de hash AVB al boot.img. Consulte https://android.googlesource.com/kernel/build/+/50333e298a0f02e7e64ef315f0825884cebd3acb/build_utils.sh#627

  2. Establecer el nivel de parche de seguridad (SPL) para que sea igual o superior al SPL de la plataforma existente en su dispositivo. Recientemente agregué esto a las herramientas de compilación del kernel: https://r.android.com/2795723.

Si utiliza las últimas herramientas de compilación del kernel (https://android.googlesource.com/kernel/build/+/refs/heads/main) para compilar su kernel, entonces debería poder flashear un boot.img personalizado en los dispositivos Pixel 6 y Pixel 7. Consulte https://source.android.com/docs/setup/build/building-pixel-kernels para obtener instrucciones sobre cómo compilar kernels Pixel personalizados y https://source.android.com/docs/setup/build/building-kernels si solo desea compilar el kernel central (no los controladores de Pixel).

Nota: La deshabilitación de la verificación solo es necesaria cuando actualiza una partición dinámica personalizada que espera que las claves AVB estén en las particiones vbmeta_*. Si solo está actualizando el boot.img y tiene un SPL válido con un pie de hash AVB, entonces no necesita borrar ni deshabilitar la verificación cuando el bootloader está desbloqueado. Por cierto, un cambio como [1] le permitirá actualizar las particiones system_dlkm y vendor_dlkm sin necesidad de deshabilitar la verificación cuando su dispositivo tenga el bootloader desbloqueado.

Nota2: Si realmente desea actualizar los controladores en la partición vendor_dlkm sin borrar su dispositivo, simplemente agregue el módulo actualizado (y sus dependencias) a la imagen vendor_kernel_boot (asegúrese de incluirlo también en el archivo module.load) para cargarlo en la etapa inicial. Durante la segunda etapa de inicialización, el módulo original en la partición vendor_dlkm simplemente fallará al cargarse, pero no debería causar ningún problema.

Nota3: Estos pasos solo son aplicables para android11-5.4, android12-5.4, android12-5.10, android13-5.10 y android13-5.15. Las ramas de kernel anteriores a android11-5.4 no son compatibles con GKI con los módulos del kernel vendor para Android en la misma rama de kernel. Eso significa que la ABI del kernel no es estable en esas ramas. Para los kernels android14-* (como el que se envía con el Pixel 8), aunque la ABI del kernel es estable debido a GKI, la introducción de Módulos GKI protegidos ha creado una dependencia entre el boot.img e system_dlkm.img. Eso significa que si actualiza el kernel central (boot.img), los módulos GKI existentes en la partición system_dlkm fallarán al cargarse, lo que puede hacer que su dispositivo no pueda arrancar. Como mínimo, actualizar el boot.img sin actualizar el system_dlkm.img removerá la funcionalidad crítica del dispositivo, como el Wi-Fi. Hasta que se haya fusionado un cambio como [1] para su dispositivo, que le permitirá actualizar las particiones system_dlkm y vendor_dlkm en dispositivos desbloqueados sin deshabilitar la verificación, deberá borrar su dispositivo o mover todos los módulos vendor_dlkm que dependen de los módulos GKI a la partición vendor_kernel_boot.

[1] https://r.android.com/2795415

PreguntAndroid.com

PreguntAndroid es una comunidad de usuarios de Android en la que puedes resolver tus problemas y dudas.
Puedes consultar las preguntas de otros usuarios, hacer tus propias preguntas o resolver las de los demás.

Powered by:

X