Bricked Note Air 2

[Renate]

Yeah, it's a hassle, you can't go to EDL from fastboot.
You can get there from system/recovery with ADB.
There is this USB cable thing (that I've never gotten to work).
There are the test points inside, but that requires you to open the device.
(Unless you planned for this like I did and put a magnetic switch inside.)
There is the "nuclear" option, but I wouldn't do that without a copy of xbl.

In your shoes I'd probably just flash recmode to recovery.
But that's presuming that if there is a problem you can use EDL to wipe the start of misc.
Misc is not really a problem since misc-rec is 512 bytes that are supposed to be zero anyway.
I'd still cross my fingers though.

Ok, here's another thought. This is a boot image that I had when I was helping someone (who?) with their NA2. Since the boot partition is already trashed by you you can try flashing this. If it works, then you can get to EDL (maybe) and backup recovery.

Um, you have been flashing the correct boot_a/b partition?
This came out of b, but flash it to your active boot partition.

[darcity]

in fact I did not consider boot_a/b partitioning. I flashed it the same way as I am usually rooting my LOS smartphone

fastboot flash boot boot.img

Should I have flashed the boot.img into boot_a partition?

[darcity]

Originally Posted by Renate

Yeah, it's a hassle, you can't go to EDL from fastboot.
You can get there from system/recovery with ADB.
There is this USB cable thing (that I've never gotten to work).
There are the test points inside, but that requires you to open the device.
(Unless you planned for this like I did and put a magnetic switch inside.)
There is the "nuclear" option, but I wouldn't do that without a copy of xbl.

In your shoes I'd probably just flash recmode to recovery.
But that's presuming that if there is a problem you can use EDL to wipe the start of misc.
Misc is not really a problem since misc-rec is 512 bytes that are supposed to be zero anyway.
I'd still cross my fingers though.

Ok, here's another thought. This is a boot image that I had when I was helping someone (who?) with their NA2. Since the boot partition is already trashed by you you can try flashing this. If it works, then you can get to EDL (maybe) and backup recovery.

Um, you have been flashing the correct boot_a/b partition?
This came out of b, but flash it to your active boot partition.

Ok. I flashed your boot_b partition into boot_a as follows. Is that correct?

fastboot flash boot_a bootb.prc 
Sending 'boot_a' (16796 KB)                        OKAY [  0.083s]
Writing 'boot_a'                                   OKAY [  1.177s]
Finished. Total time: 1.280s

Behavior is the same as the initial bootloop.


Another thing I recognized in fastboot mode, is that it has "secure boot: yes". I read a little bit into it. Could it be some issue with signature verification?

[darcity]

after reading through this: (https://android.googlesource.com/pla...ster/README.md)

I felt more confident flashing the recovery partition since it is not part of avb chaining.
Also the version in the metadata of the update.zip matched the version printed in recovery.
So I flashed the proposed recmod image into recovery but I was unable to enter it.
Instead of getting into recovery it got me in fastboot. From there I flashed the recovery.img from update.zip and in fact recovery works again.
For today this was enough excitement.

Thanks a lot for your help @Renate. Lerned more than I was prepared for on a sunday evening.

EDIT: Realized that I did not erase the first 512Byte of misc partition, because I did not get into EDL due to missing adb authorization. So cannot ensure they are actually zero

[Renate]

Originally Posted by darcity

Could it be some issue with signature verification?

It could be but people are flashing Magisk and that's not signed by any authority.
I honestly don't know what that "secure" means, but it's not SecureBoot.
I proved that with a modded Firehose loader.

The stock recovery is ro.adb.secure=1 so you're unauthorized.

There's a possibility that an EDL cable will get you to EDL.
If you can find the internal UART you can probably get to 900e, but not 9008.
But if it was open you could just EDL test point.

Somebody here (not me) can probably get a copy directly off their device of whatever you want. It might even be in the payload if you unpack it.
OTOH, that stuff doesn't change too much so that it's probably not there.

Me? I'd just flash the recovery. But I live dangerously.

If somebody gave you a copy of the xbl we can do it that way.

[darcity]

So since the recovery partition is not subject to avb and the version in the metadata of the update.zip matched the version printed in recovery, I just flashed it.
The suggested recmod image did not provide a usable recovery. Was unable to enter it.
Instead of getting into recovery it got me in fastboot. From there I flashed the recovery.img from update.zip and in fact recovery works again.

What I was not able to do was writing zeros to the first 512Bytes of misc... no EDL. So as a last resort a bricked device can always theoretically be rescued connecting the EDL test point inside the device to usb data lane?

It's a pity that the device has this EDL 900e mode but no functional loader for it available.

Thanks a lot for your help @Renate. Lerned more than I was prepared for on a sunday evening.

[Renate]

Our messages crossed and I missed yours originally.

Originally Posted by darcity

What I was not able to do was writing zeros to the first 512Bytes of misc.

Not a problem. If you booted a stock recovery it cleared them.

I don't know why that recmod did not work. It was a minor update from one that had previously worked. If you could, post the recovery that you extracted from the update. (There's a 20 MB limit for attachments here.)

Did you try flashing the boot from the update?

I don't know what the scoop with updates are. Did you extract that recovery from payload.bin or was it just in the zip?

[darcity]

Originally Posted by Renate

Our messages crossed and I missed yours originally.


Not a problem. If you booted a stock recovery it cleared them.

I don't know why that recmod did not work. It was a minor update from one that had previously worked. If you could, post the recovery that you extracted from the update. (There's a 20 MB limit for attachments here.)

Did you try flashing the boot from the update?

I don't know what the scoop with updates are. Did you extract that recovery from payload.bin or was it just in the zip?

The content of the zip looks like this:

tree update
update
├── META-INF
│** └── com
│**     └── android
│**         ├── metadata
│**         └── otacert
├── payload.bin
└── payload_properties.txt

Everything seems to be packed inside payload.bin including boot.img and recovery.img
Recovery seems to be too large to attach it here. I will upload it in the lunch break.

λ   du -sch recovery.img 
97M	recovery.img

Tried to flash boot and recovery all together from stock but that also resulted in a boot loop.
could it be that I need to flash vbmeta too?

[Renate]

Originally Posted by darcity

Could it be that I need to flash vbmeta too?

Yup, that's probably it.
I tend to forget about that as I patched my dtb and fstab.

[darcity]

Flashed vbmeta but it did not change a thing. I uploaded a few images and also here is the content of payload.bin

λ  update ls | grep img 
boot.img
dtbo.img
modem.img
product.img
recmod.img
recovery.img
system.img
system_ext.img
vbmeta.img
vbmeta_system.img
vendor.img
xbl.img

zip contains boot.img, recovery.img and xbl.img
https://www.mediafire.com/file/ytswc...tions.zip/file

[Renate]

Originally Posted by darcity

zip contains boot.img, recovery.img and xbl.img

Jeez, this is a horse of a different color.
This is not what I see from a NoteAir2 from 6 months ago.

The partitions for boot/recovery are 100 MB.
The image for boot/recovery are 100 MB because they stick a dozen bytes on the end.
If they didn't the images could be 70-77 MB shorter.
(Because they do this AVB0 signing.)

Ok, moving beyond that. Both boot & recovery have the identical kernel (as to be expected).
But the kernel has increased in size from 35 MB to 50 MB from 6 months ago.
So much for New Year's resolutions to lose some weight.

The dtb sections are the same. There are 3 DTB's in them. And you have a dtbo partition.

So, backtracking a bit. This all started when you tried to Magisk with a boot image you pulled off using EDL? Maybe they started to enforce the AVB0 in abl?

I see that your recovery there has /system/bin/update_engine_sideload which is the new software for working with update.zip with payload.bin
I'm not sure how to use that, but you could try using the decrypted update.zip

C:\>adb sideload update.zip

I see that xbl is using standard Qualcomm factory signing.

[Renate]

Did you get recovery to work using just fastboot boot image?
If you did, could you do an experiment? You're on Linux, right?

$ dd if=recovery.img of=short.img count=61288

You should end up with a file 31,379,456 bytes.

fastboot boot short.img

[darcity]

Originally Posted by Renate

Did you get recovery to work using just fastboot boot image?
If you did, could you do an experiment? You're on Linux, right?

$ dd if=recovery.img of=short.img count=61288

You should end up with a file 31,379,456 bytes.

fastboot boot short.img

$ dd if=recovery.img of=short.img count=61288
$ ls -l short.img
-rw-r--r-- 1 **** **** 31379456 Jan 16 16:06 short.img
$ fastboot boot short.img

Brings me into recovery. But it does not work from fastbootd that can be invoked in recovery. But works from bootloader

[Renate]

== OLD ==

nsymbols=112840

        Size   Compressed  Name
------------ ------------  ------------------------
    29970432     29970432  .text
     4731392      4731392  .data
------------ ------------  ------------------------
    34701824     34701824  2 files

== NEW ==

nsymbols=113484

        Size   Compressed  Name
------------ ------------  ------------------------
    44720128     44720128  .text
     4731392      4731392  .data
------------ ------------  ------------------------
    49451520     49451520  2 files

I don't get it. I don't know what the 15 MB of bloat is.

[darcity]

Originally Posted by Renate

Jeez, this is a horse of a different color.
This is not what I see from a NoteAir2 from 6 months ago.

The partitions for boot/recovery are 100 MB.
The image for boot/recovery are 100 MB because they stick a dozen bytes on the end.
If they didn't the images could be 70-77 MB shorter.
(Because they do this AVB0 signing.)

Ok, moving beyond that. Both boot & recovery have the identical kernel (as to be expected).
But the kernel has increased in size from 35 MB to 50 MB from 6 months ago.
So much for New Year's resolutions to lose some weight.

The dtb sections are the same. There are 3 DTB's in them. And you have a dtbo partition.

So, backtracking a bit. This all started when you tried to Magisk with a boot image you pulled off using EDL? Maybe they started to enforce the AVB0 in abl?

I see that your recovery there has /system/bin/update_engine_sideload which is the new software for working with update.zip with payload.bin
I'm not sure how to use that, but you could try using the decrypted update.zip

C:\>adb sideload update.zip

I see that xbl is using standard Qualcomm factory signing.

Holy **** sideloading worked. And it boots up! The UI looks completely different, all my data is gone and it announces itself as "BENGAL-IDP" and not as "Note Air 2" but it is functional again!

Already saw myself enrolling electical engineering studies ... I will definitely donate some coffee if you send me your paypal address via pm.

One last question. How did you get to the download link for the update.upx for this device? Could be useful also for others struggling with similar issues.