Ich habe OnePlus One mit CyanogenMod 12 ab Werk und habe mich für ein Update auf CM 13 (Nightly Build) entschieden.
Um dies zu erreichen, habe ich Folgendes von OSX aus getan:
Jetzt kann ich den Bootloader nicht mehr entsperren , um beispielsweise ein benutzerdefiniertes Wiederherstellungstool (wie TWRP) zu installieren/booten
$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
Eine Lösung wäre wünschenswert, aber ich bin auch neugierig, warum es sich nach einer manuellen Sperre so verhält.
Wie von @Firelord vorgeschlagen, scheint es hier eine Lösung für Windows-Benutzer zu geben: https://forums.oneplus.net/threads/important-bootloader-wont-unlock-after-relock.324398/
Bei meiner Suche bin ich auf einen interessanten Thread gestoßen , der verwandt war, aber um ihr Skript zu installieren, müssen Sie ein benutzerdefiniertes Wiederherstellungstool installiert haben oder damit booten können (z. B. fastboot boot recovery.img).
Ich hatte das Standard-Cyanogen-Wiederherstellungstool und konnte wegen meines eigentlichen Problems (Bootloader kann nicht mehr entsperrt werden) nicht in TWRP booten, also habe ich in ihrem Skript gegraben und den Inhalt verwendet, der zum Zurücksetzen der Sperr- und Manipulationsbits des Bootloaders gedacht war.
Jetzt könnte ich die Befehle manuell ausführen, wenn ich Root-Zugriff hätte , und glücklicherweise können Sie sie in CM 13 ROM im Menü „Entwickleroptionen“ aktivieren.
Hier sind die Befehle, die ich nach dem Aktivieren des Root-Zugriffs für ADB verwendet habe:
adb root # Starten Sie den adbd-Daemon mit Root-Rechten neu adb shell # Remote-Shell interaktiv ausführen dd bs=1 count=1 skip=1048080 if=/dev/block/platform/msm_sdcc.1/by-name/aboot 2>/dev/null | xxd | cut -c 10- # drucke den Zustand des Sperrbits (00 - gesperrt, 01 - entsperrt) echo -ne "\x01" | dd bs=1 count=1 seek=1048080 of=/dev/block/platform/msm_sdcc.1/by-name/aboot # Sperrbit auf unlocked(01) setzen dd bs=1 count=1 skip=1048084 if=/dev/block/platform/msm_sdcc.1/by-name/aboot 2>/dev/null | xxd | cut -c 10- # drucke den Zustand des Manipulationsbits (00 - nicht manipuliert, 01 - manipuliert) echo -ne "\x00" | dd bs=1 count=1 seek=1048084 of=/dev/block/platform/msm_sdcc.1/by-name/aboot # setze das Tamper-Bit auf untampered(00)
Ergebnis:
$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
Ich denke, das Manipulationsbit wird geändert, wenn Sie den Bootloader zum ersten Mal entsperren (Fastboot-OEM-Entsperrung), und nachdem Sie ihn wieder gesperrt haben (Fastboot-OEM-Sperre), können Sie ihn nicht erneut entsperren.
Wenn xxdund cutnicht an Orten vorhanden sind, die in $ PATH verfügbar sind (wie es in meinem Fall der Fall war), setzen Sie busyboxdiesen Befehlen ein Präfix.
# 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
Feuerlord
Codentary