Stuck early in the setup process: am I missing a key piece of the puzzle?

PhAndersson

@messayisto said in Stuck early in the setup process: am I missing a key piece of the puzzle?:

@phandersson It looks like the phone is already unlocked (because of the unlooked message on startup).

TWPR is not absolutely necessary, at least not for me: https://forums.ubports.com/topic/6349/installation-succes-at-the-first-try/7

Maybe the only important thing is to upgrade to android 9 before you try again.

Hello @messayisto. Yes, I agree with you that the TWRP boot issue may not be an immediate blocker, but I'm still concerned that it highlights an underlying problem that will bite me later on. Call me finicky, but I always prefer to build on strong foundations

In parallel, I'll dig and/or enquire on the Xiaomi forums to try and sort out the current status of my bootloader. I'll report back when I know more.

PhAndersson

@mrt10001 said in Stuck early in the setup process: am I missing a key piece of the puzzle?:

@phandersson Check this out.

Excellent! Many thanks. I'll certainly give it a try if it turns out to be needed. This could be a life saver!

PhAndersson

@phandersson said in Stuck early in the setup process: am I missing a key piece of the puzzle?:

In parallel, I'll dig and/or enquire on the Xiaomi forums to try and sort out the current status of my bootloader. I'll report back when I know more.

Well, it didn't take long
[Tips] [ifelixit] Unlocking the Bootloader of Mi A2/Lite (Feb. 2020)
https://c.mi.com/thread-2853583-1-0.html?t=1583843866434

Turns out that on the MI A2 and Mi A2 Lite, 'fastboot oem unlock' IS the official procedure to unlock the bootloader. Great! So at least that step looks sorted out.

PhAndersson

@phandersson OK, yet more troubleshooting results.

1./ getvar issue
I read somewhere that it was also possible to query 'getvar all', so I tried that and it worked. Here is the (slightly doctored) output, in case it reveals something:

$ ./fastboot getvar all
(bootloader) crc:1
(bootloader) anti:2
(bootloader) token:[removed]
(bootloader) unlocked:yes
(bootloader) off-mode-charge:0
(bootloader) charger-screen-enabled:0
(bootloader) battery-soc-ok:yes
(bootloader) battery-voltage:4337
(bootloader) version-baseband:
(bootloader) version-bootloader:
(bootloader) variant:SDM EMMC
(bootloader) partition-type:cache:ext4
(bootloader) partition-size:cache: 0x10000000
(bootloader) partition-type:userdata:ext4
(bootloader) partition-size:userdata: 0xBB77F7E00
(bootloader) partition-type:system_a:ext4
(bootloader) partition-size:system_a: 0xC0000000
(bootloader) has-slot:modem:yes
(bootloader) has-slot:system:yes
(bootloader) current-slot:a
(bootloader) has-slot:boot:yes
(bootloader) slot-retry-count:b:7
(bootloader) slot-unbootable:b:yes
(bootloader) slot-successful:b:no
(bootloader) slot-retry-count:a:6
(bootloader) slot-unbootable:a:no
(bootloader) slot-successful:a:yes
(bootloader) slot-count:2
(bootloader) secure:yes
(bootloader) serialno:dbXXXX
(bootloader) product:jasmine
(bootloader) max-download-size:536870912
(bootloader) kernel:uefi
all: 
Finished. Total time: 0.004s

What is really weird is that this command only works once per session. If I re-execute it, I get the "unknown variable" error. If I try to query specifically for any of the defined variables, I stlll get either "unknown command" or "unknown variable".

2./ USB devices
Going through the 'dmesg' output, I noticed that the phone identified itself as two different USB devices:

idVendor=05c6, idProduct=9091 Manufacturer: Xiaomi
idVendor=18d1, idProduct=d00d Manufacturer: Google
(but both with same SerialNumber property).

So I checked inside the '51-android.rules' file installed by the 'android-udev-rules' package, and noticed two problems:

the idVendor 05c6 was assigned to Qualcomm, not Xiaomi
idProduct 9091 (= Mi A2) was not defined at all

I then hacked the file to make sure it matched what was reported by 'dmesg', but it turned out to be in vain (at least as pertains to my current problem), because I later discovered that these 2 devices are in fact never seen by the PC at the same time:

the Qualcomm/Xiaomi device appears when the phone runs Android
the Google device is only seen when the phone is rebooted in fastboot mode

It's also not clear to me that 'adb' and 'fastboot' commands really rely on these udev rules to work, as I was able to interact (at least minimally) with the phone even while running Android (e.g. 'adb reboot bootloader') before I created a rule for the Mi A2.

PhAndersson

@messayisto said in Stuck early in the setup process: am I missing a key piece of the puzzle?:

Maybe the only important thing is to upgrade to android 9 before you try again.

I checked on the phone (still running Android 8.1.0): there is a pending update identified as "November 2018 security update", but it refuses to apply ("Couldn't update / Installation problem"). I've already retried several times applying it, always with the same result. It's not a problem of space as there's no data whatsoever on the phone (50 GB free space), the wireless connection is at full strength and the Internet connection is stable. Anyway, it's not the download phase that fails, but the installation.

I'll try again after removing the 2 small apps I installed for earlier tests, and after leaving dev. mode just to see whether it makes a difference.

PhAndersson

@phandersson Trying to understand where 'fastboot boot twrp.img' gets suck, I ran it through 'strace'. Here below, the relevant parts.

1./ fastboot appears to sequentially probe attached USB devices until it finds one where a specific string is found, reads the device S/N off it, checks that it offers the fastboot interface and if so claims it:

openat(AT_FDCWD, "/dev/bus/usb/001/018", O_RDWR) = 4
read(4, "\22\1\20\2\0\0\0@\321\30\r\320\0\1\1\2\3\1\t\2 \0\1\1\0\200P\t\4\0\0\2"..., 1024) = 50
openat(AT_FDCWD, "/sys/bus/usb/devices/1-1/serial", O_RDONLY) = 5
read(5, "dbXXXX\n", 255)                = 7
close(5)                                = 0
openat(AT_FDCWD, "/sys/bus/usb/devices/1-1/1-1:1.0/interface", O_RDONLY|O_NOFOLLOW|O_CLOEXEC) = 5
fstat(5, {st_mode=S_IFREG|0444, st_size=4096, ...}) = 0
read(5, "fastboot\n", 8192)             = 9
read(5, "", 8192)                       = 0
close(5)                                = 0
ioctl(4, USBDEVFS_CLAIMINTERFACE, 0x7ffc6192745c) = 0

(as mentioned in an earlier post, I don't see any reliance on udev rules here)

2./ fastboot then reads the entire TWRP image into a memory-mapped area (I left those system calls out) and proceeds to send it on the USB device through 'ioctl()' calls:

write(2, "Sending 'boot.img' (31560 KB)   "..., 51Sending 'boot.img' (31560 KB)                      ) = 51
ioctl(4, USBDEVFS_BULK, 0x7ffc61927b80) = 17
ioctl(4, USBDEVFS_BULK, 0x7ffc61927930) = 12
ioctl(4, USBDEVFS_BULK, 0x7ffc61927bc0) = 16384
[...]
ioctl(4, USBDEVFS_BULK, 0x7ffc61927bc0) = 16384
ioctl(4, USBDEVFS_BULK, 0x7ffc61927bc0) = 8192
ioctl(4, USBDEVFS_BULK, 0x7ffc619279b0) = -1 ESHUTDOWN (Cannot send after transport endpoint shutdown)

Notice how two short strings (17 and 12 bytes) are sent before the image.
If I add the bytes for all 16384 + the last 8192 packets, I come up to the exact size of the TWRP image, to the byte.
But then (last line of the above extract), it tries to send yet another string from a different memory address, and that hangs forever. I would need to dig into the fastboot code to know what that last string is, of course.
The ESHUTDOWN error is triggered when I unplug the phone.

PhAndersson

@phandersson said in Stuck early in the setup process: am I missing a key piece of the puzzle?:

I would need to dig into the fastboot code to know what that last string is, of course.

I found the source code yesterday for an older version of 'fastboot'. C++ is definitely not my forte, but the way I understand it, the hanging ioctl() call is not an attempt to write more data, but rather fastboot blocking on a read operation (ioctl() calls can read or write depending on a flag part of the struct passed as 3rd param), trying to retrieve from the phone the status resulting from it receiving the TWRP image.

If I'm right, that would be on this line inside FastBootDriver::HandleResponse() method:

int r = transport_->Read(status, FB_RESPONSE_SZ);

'fastboot' expects a status of 'OKAY', but never gets anything. If it got something else, it would process it and error out with a different error message.

In any case, since the problem seems to be on the phone side, I'll try with older versions of the TWRP image, see whether that makes any difference.

PhAndersson

@phandersson said in Stuck early in the setup process: am I missing a key piece of the puzzle?:

In any case, since the problem seems to be on the phone side, I'll try with older versions of the TWRP image, see whether that makes any difference.

Just tried with 'twrp-3.3.1-0-jasmine_sprout.img' (released in June 2019). Exact same behaviour.

PhAndersson

@phandersson Success at last!
Tried from my home desktop (I was using my work laptop until now), and there it works perfectly. Don't ask. openSUSE in both cases (15.1 vs 15.2). Custom built vs Lenovo P53. Same version of the platform-tools, obviously (Google's latest).

Anyway:

$ ./fastboot boot ./twrp-3.5.2_9-0-jasmine_sprout.img 
Sending 'boot.img' (31560 KB)                      OKAY [  0.996s]
Booting                                            OKAY [ 10.273s]
Finished. Total time: 11.492s

I can now try to proceed with flashing Android 9. What a relief!

magnargj

@phandersson Hurray! Good job, but very strange...