Tengo OnePlus One con CyanogenMod 12 de fábrica y decidí actualizar a CM 13 (versión nocturna).
Para lograr esto hice lo siguiente desde OSX:
Ahora, ya no puedo desbloquear el gestor de arranque para hacer cosas como instalar/arrancar una herramienta de recuperación personalizada (como TWRP).
Ejecutar 'desbloqueo oem fastboot' simplemente reinicia el dispositivo en modo de recuperación, pero el gestor de arranque permanece bloqueado:
$fastboot oem device-info
...
(bootloader) Device tampered: true
(bootloader) Device unlocked: false
(bootloader) Charger screen enabled: false
(bootloader) Display panel:
(bootloader) console_enabled: 0
(bootloader) exec_console_unconsole: 0
Se agradecería una solución, pero también tengo curiosidad por qué se comporta así después de un bloqueo manual.
Según lo sugerido por @Firelord, parece haber una solución para los usuarios de Windows aquí: https://forums.oneplus.net/threads/important-bootloader-wont-unlock-after-relock.324398/
En mi búsqueda, encontré un tema interesante que estaba relacionado, pero para instalar su script, debe tener instalada una herramienta de recuperación personalizada o poder iniciarla (por ejemplo, fastboot boot recovery.img) .
Tenía la herramienta de recuperación de cianógeno de stock y no podía iniciar TWRP debido a mi problema real (ya no puedo desbloquear el cargador de arranque), así que busqué dentro de su secuencia de comandos y usé el contenido destinado a restablecer los bits de bloqueo y manipulación del cargador de arranque.
Ahora podría ejecutar los comandos manualmente si tuviera acceso de root y, afortunadamente, en la ROM CM 13, puede habilitarlo desde el menú 'Opciones de desarrollador'.
Aquí están los comandos que usé después de habilitar el acceso de root para ADB:
adb root # reiniciar el demonio adbd con permisos de root adb shell # ejecutar shell remoto de forma interactiva dd bs=1 count=1 skip=1048080 if=/dev/block/platform/msm_sdcc.1/by-name/aboot 2>/dev/null | xdd | cut -c 10- # imprime el estado del bit de bloqueo (00 - bloqueado, 01 - desbloqueado) eco -ne "\x01" | dd bs=1 count=1 seek=1048080 of=/dev/block/platform/msm_sdcc.1/by-name/aboot # establecer el bit de bloqueo en desbloqueado (01) dd bs=1 count=1 skip=1048084 if=/dev/block/platform/msm_sdcc.1/by-name/aboot 2>/dev/null | xdd | cut -c 10- # imprime el estado del bit de manipulación (00 - no manipulado, 01 - manipulado) eco -ne "\x00" | dd bs=1 count=1 seek=1048084 of=/dev/block/platform/msm_sdcc.1/by-name/aboot # establecer el bit de manipulación en no manipulado (00)
Resultado:
$fastboot oem device-info
...
(bootloader) Device tampered: false
(bootloader) Device unlocked: true
(bootloader) Charger screen enabled: false
(bootloader) Display panel:
(bootloader) console_enabled: 0
(bootloader) exec_console_unconsole: 0
Supongo que el bit de manipulación se cambia la primera vez que desbloquea el gestor de arranque (desbloqueo oem fastboot) y después de volver a bloquearlo (bloqueo oem fastboot) no le permitirá volver a desbloquearlo.
Si xxdy cutno existen en ubicaciones disponibles en $PATH (como fue en mi caso), prefijo busyboxen esos comandos.
# print the lock bit state (00 - locked, 01 - unlocked)
dd bs=1 count=1 skip=1048080 if=/dev/block/platform/msm_sdcc.1/by-name/aboot 2>/dev/null | busybox xxd | busybox cut -c 10-
# set the lock bit to unlocked(01)
echo -ne "\x01" | dd bs=1 count=1 seek=1048080 of=/dev/block/platform/msm_sdcc.1/by-name/aboot
# print the tamper bit state (00 - untampered, 01 - tampered)
dd bs=1 count=1 skip=1048084 if=/dev/block/platform/msm_sdcc.1/by-name/aboot 2>/dev/null | busybox xxd | busybox cut -c 10-
set the tamper bit to untampered(00)
echo -ne "\x00" | dd bs=1 count=1 seek=1048084 of=/dev/block/platform/msm_sdcc.1/by-name/aboot
Señor del Fuego
codentario