Go 7 bootloop

[gleboss]

Hi!

Yesterday I picked up my Onyx Boox Go 7 and noticed that the battery was completely drained. After charging it, the device no longer boots properly.

Current behavior:

• It shows the BOOX logo
• Then the loading animation with dots
• After a short time the animation freezes and the device reboots
• This repeats indefinitely (boot loop)

What I already tried:

• Entered recovery mode
• Wipe data / factory reset
• Tried reinstalling the latest firmware using
  

  adb sideload update.upx

• The update fails with "signature verification failed"

Could you please suggest possible ways to recover the device?
I saw that you sometimes use custom recovery or EDL tools for BOOX devices and wondered if something similar could help here.

Any advice would be greatly appreciated.

Thank you!

[BunnySonic]

I would say battery is dead and you should replace it. Same thing happened to my android tablet and nothing could fix it.

[gleboss]

Got custom recovery from Renate and tried the following:

.\adb.exe reboot fastboot

.\fastboot.exe flash recovery_a ..\go7-rec.img
Sending 'recovery_a' (57972 KB)                    OKAY [  1.450s]
Writing 'recovery_a'                               FAILED (remote: 'Unrecognized command flash')

.\fastboot.exe reboot-edl
fastboot: usage: unknown command reboot-edl

.\fastboot.exe oem edl
FAILED (remote: 'Command not supported in default implementation')

.\adb.exe reboot edl
error: closed

So I can't even enter EDL, any ideas?

[dcarvil]

Originally Posted by gleboss

Got custom recovery from Renate and tried the following:

.\adb.exe reboot fastboot

.\fastboot.exe flash recovery_a ..\go7-rec.img
Sending 'recovery_a' (57972 KB)                    OKAY [  1.450s]
Writing 'recovery_a'                               FAILED (remote: 'Unrecognized command flash')

.\fastboot.exe reboot-edl
fastboot: usage: unknown command reboot-edl

.\fastboot.exe oem edl
FAILED (remote: 'Command not supported in default implementation')

.\adb.exe reboot edl
error: closed

So I can't even enter EDL, any ideas?

Don't know if this is useful, but boox has removed the flash command from fastboot in recent releases. That is the reason for the "Unrecognized command flash" error.

I think "\fastboot.exe reboot-edl" should be "\fastboot.exe reboot edl" (no dash).

If you are in fastboot mode, ".\adb.exe reboot edl" would not be expected to work.

[Renate]

Yeah, the functionality of abl (fastboot) has been whittled down.
For now that's not a big deal since we have EDL/Firehose.
Just do all your flashing with that.

[gleboss]

I'm trying ".\adb.exe reboot edl" in adb mode. "\fastboot.exe reboot edl" doesnt work either:

.\fastboot.exe reboot edl
fastboot: usage: unknown reboot target edl

Btw, I'm entering ADB the following way: Recovery -> Apply update from ADB, didn't find any other ways of entering into ADB

[Renate]

Enabling ADB is normally under System > Developer settings
That's in regular Android Settings.
Which I guess that you don't have.

You need an EDL cable, you can make one.

[gleboss]

Looks like I managed to enter EDL, but can't write custom recovery:

\edl.exe /l
Found EDL 9008, handshaking... version 2
HWID: 0013f0e100000000 (x3), JTAG: 0013f0e1, OEM: 0000, Model: 0000
Hash: d40eee56f3194665-574109a39267724a-e7944134cd53cb76-7e293d3c40497955-bc8a4519ff992b03-1fadc6355015ac87 (x3)

.\edl.exe /w /precovery ..\go7-rec.img
Found EDL 9008, configuring... bad XML

[gleboss]

I managed to enter EDL mode, flash the custom recovery, and start the autoupdate process.

However, the update seems to be stuck at 11% for about 30 minutes:

Starting ttyscreen
Waiting for flash drive... Ok
Mounting sda1 (114.6 GB) as vfat... Ok
Found update.zip with payload.bin
Starting update in 0
new_update, version:, source_slot: B, target_slot: A, url: file:///flash/update.zip, payload: (size: 1963026337, metadata_size: 138931, metadata signature: , hash: 4E5D5F5AC82463046545536E94C837C45868EFBCDF0FDE23274F3E937103D057, payload type: unknown), hash_checks_mandatory: true, powerwash_required: false, switch_slot_on_reboot: true, run_post_install: false, is_rollback: false, write_verity: true
new_update, version: , source_slot: B, target_slot: A, url: file:///flash/update.zip, payload: (size: 1963026337, metadata_size: 138931, metadata signature: , hash: 4E5D5F5AC82463046545536E94C837C45868EFBCDF0FDE23274F3E937103D057, payload type: unknown), hash_c hecks_mandatory: true, powerwash_required: false, switch_slot_on_ reboot: true, run_post_install: false, is_rollback: false, write-verity: true
Completed 0/? operations
Successfully created snapshot for odm_a
Successfully created snapshot for product_a
Completed 270/2433 operations (11%)

To prepare the update package I decrypted the latest update.upx for the Boox Go 7 using:
https://github.com/Hagb/decryptBooxUpdateUpx

Do you know if this is expected to take this long, or could something have gone wrong with the OTA package or the flashing process?

Any suggestions would be greatly appreciated.

[Renate]

About 5 minutes should be sufficient.
You can try doing it again.

How did you get that text? did you type it or OCR a photo?
You should use the autolog.txt that gets written back on the SD card.
It is much more detailed.

0: Waiting for flash drive... Ok
0: Mapped 8:17 to 253:0
0: Mounting sdb1 (58.2 GB) as exfat... Ok
0: Found update.zip with payload.bin
0: Starting update in 10 9 8 7 6 5 4 3 2 1 0
2: [INFO:sideload_main.cc(190)] Update Engine Sideloading starting
2: fs_mgr_fstab.cpp:348] [libfs_mgr]dt_fstab: Skip disabled entry for partition vendor
2: cutils-trace E 09-14 08:56:54   501   501 Error opening trace file: No such file or directory (2)
2: [INFO:boot_control_android.cc(70)] Loaded boot control hidl hal.
2: [ERROR:prefs.cc(85)] storage_->DeleteKey(key) failed.
2: [INFO:update_attempter_android.cc(162)] Skip ScheduleCleanupPreviousUpdate in sideload because ApplyPayload will call it later.
2: [ERROR:prefs.cc(85)] storage_->DeleteKey(key) failed.
2: [INFO:update_attempter_android.cc(280)] Using this install plan:
2: [INFO:install_plan.cc(91)] InstallPlan: new_update, version: , source_slot: A, target_slot: B, url: file:///flash/update.zip, payload: (size: 1805515511, metadata_size: 105720, metadata signature: , hash: D367D5B5823D3A5715E5578AE14E301DC26FC7CBE5082DC448F0E4707D4B526E, payload type: unknown), hash_checks_mandatory: true, powerwash_required: false, switch_slot_on_reboot: true, run_post_install: false, is_rollback: false, write_verity: true

The fact that the screen and everything is working indicates that there's no problem with my recovery itself.
Update is a hairy (and over-complicated) operation.

[gleboss]

It's a photo OCR. I don't see any logs(

Tried three times - with different USB drives, SD cards - the same result with 11%.

[Renate]

Yeah, it froze somehow and didn't get a chance to write the log.
I tell you, these updates with super and snapshots and CoW and metadate are a recipe for disaster.

Swapping slots might be able to fix it, but swapping is usually the job of abl and your fastboot is limited.

I don't know if the "nuclear option" would fix things or make it worse.
You can safely do it if you backup carefully.
Do not ever say "yes" to wipe the device.

If you have 64 GB space on your desktop:

edl /r big64gfile.img

It will probably take a half hour.

If you don't, or you want to do this also:

edl /r /psuper superfile.img

When you have your copies safely stored:

edl /f /psuper

Then go and do an update again.
If it doesn't work you can always:

edl /w /psuper superfile.img

[gleboss]

Thx, after erasing it fails with another error and here is autolog - autolog.txt

[Renate]

Well, that's progress.

Write just the super back with EDL. Then:

edl /r /psuper /c2048 man.img

Zip it and post it and I'll check what kind of train wreck you have.

[gleboss]

Here it is - man.zip