[Renate]

Originally Posted by bassme

I ran "edl.exe /lq662.elf /r /pboot_b boot.img /t /v"

Don't.

There are two phases going on here, using two different protocols. When you try to do them in one command there is not in fact any functional problem, merely a problem of you understanding what and where any problems might be.

edl.exe /lq662.elf

First, make sure you have the latest edl.exe, it's 132,608 bytes. Some more specific error messages have been added. Previous versions did not have any functional problems.

The first protocol "Sahara" is very brittle. It can easily mistake "whose turn it is to talk" and it tolerates no interruption. So, in the first phase if anything doesn't work for any reason you must do a reset and get a fresh EDL.

The information part of the first phase should run without problem spitting out some lines. The next part is the loading of the loader. That can barf for four separate reasons:

• The offered file is not a correct ELF file
• The offered file is the wrong 32 bit/64 bit
• The offered file is missing the signing section
• The offered file has the wrong signing

Those are the only reasons that the device itself stops loading before 100%.

There could also be a problem with bad USB cables or flakey hubs. If the desktop machine crashes, there is clearly a problem there because it should not happen under any circumstances.

After the loader loads it should be using the second protocol "Firehose". Sometimes the switchover can be problematic. Firehose is more robust than Sahara so if something bad happens you can usually just retry your command. Normally, edl.exe should say "Firehose detected". Even if it doesn't, it is worth trying the next command to see if you can kick some sense into it.

Next you should do a sanity check and list the partitions:

edl.exe /g

The same processor (SDMxxx) might be using eMMC or UFS memory hardware, so you need to see which it is. UFS memory uses the /u flag for every Firehose command.

edl.exe /u /g

One of these will work, either with or without /u. It should print out the partitions. If you are using UFS it might spit out a panicky error when listing partitions ("OMG, I can't load UFS unit #6!"). This is not a problem. You can then look at the listing and see which A/B slot is being used by looking for "inactive". If you don't see, don't have A/B slots it's simpler.

So now get your boot image or whatever it was that you wanted.

edl.exe /r /pboot_a boot.img /t

Of course, this could be boot, boot_a or boot_b and you will need /u if you used it before. The /t makes it copy the minimal amount for a full Android image and not the whole (useless) partitition. If you were trying to copy a data partition or something else it would tell you not to use /t.

And don't use the /v flag unless there is a specific problem that you're working with me to correct and you can quote verbatim what it prints out.

So, the only question remaining is whether you have the right loader in the first part. If there is an issue you should quote the HWID and Hash (but not the serial number) that it spit out at the beginning and the size and MD5 (if you can) of the loader.

(All of the above information generally applies to the Python EDL utility also.)