yashsingh1/xdaforums huggingface dataset:
[Google Pixel 6 Pro] roirraW "edor" ehT:
Ah, good point. I forgot about that, but that does seem familiar now. My answer is: probably.
[Google Pixel 6 Pro] Zilla0617:
Have an issue that I can't solve. Ever since I upgraded to A13 my device will not sleep, 100% awake. Never had this issue and I'm trying to avoid performing a factory reset.

So I'm seeing system server and Android hardware sensors causing high cpu when I check in terminal. The hardware sensor specifically is Android hardware sensors @2.1-service.multihal. I tried restarting, reflashing with -w, changing kernels. Nothing works

EDIT: After performing a factory reset, still encountered the issue. Tap, Tap ended up being the cause of the high drain. Once I forced stop the app, my CPU went down. Ultimately, deleted the app. Phone enters deep sleep now
[Google Pixel 6 Pro] Lughnasadh:
I know that works for flashing boot images to both slots, but I couldn't say definitively it would work with flashing the whole factory image. I look forward to you trying and telling us how it went 🙃🤣
[Google Pixel 6 Pro] Homeboy76:
@Lughnasadh @roirraW "edor" ehT

:rolleyes::oops: The factory image is large.

So, maybe these edits of the flash-all.bat file are better:

...fastboot update image-bramble-tp1a.220624.014.zip...

fastboot--skip-reboot

fastboot --set-active=a (If you're on slot b)

fastboot --set-active=b (If you're on slot a)

fastboot reboot-bootloader

ping -n 5 127.0.0.1 >nul

- Verify bootloader slot change

- At the command prompt (on your computer), type flash-all to flash the factory image to the other slot.

Or

Flash the factory image to your phone.

After it reboots

- set you phone up

- Reboot

- fastboot adb reboot bootloader

- Change slot

fastboot --set-active=a (If you're on slot b)

fastboot --set-active=b (If you're on slot a)

Flash the factory image to the other slot by typing flash-all at the command prompt.
[Google Pixel 6 Pro] Lughnasadh:
I thought you may be feeling lucky today 😀
[Google Pixel 6 Pro] Lughnasadh:
But seriously, I'm not sure it's even a good idea to do that. What if something goes wrong during flashing and you have both slots end up being corrupted? May be harder to get out of. Not impossible of course since there may be other methods to recover. For me, it's always nice that you know what of your slots is still good (e.g. when you get into a bootloop and it eventually switches to the other slot to boot). It's really just a time and effort saver to do both slots at once but not sure the rewards would outweigh the possible pitfalls, at least for me.

Just my 2 cents...
[Google Pixel 6 Pro] whatsisnametake2:
so what's the definitive situation re going back to 12 after you've updated to 13?
[Google Pixel 6 Pro] roirraW "edor" ehT:
I don't think there is a definitive situation, as no one has expressed wanting to go back. :)

The only thing I know for sure is that if you're still on Android 12, you can definitely flash the Android 13 Stable bootloader ONLY, and I was still able to boot Android 12. Doesn't mean squat, really.

Downgrading without wiping is always a very risky thing: After upgrading to a newer version (even a regular monthly update), system app data may have been updated as well (it's very likely at least some system apps have). Downgrading to an earlier version of Android won't downgrade the app data, so suddenly you're running an older version of Android with app data meant for a newer version. At best, you'll have weird issues. At worst, your phone won't boot. I don't have the time to set my phone up from scratch if I can help it, so I won't be testing downgrading (with or without Android 12's bootloader) any time.

If you have the time and test this process, please let us know how it works out. It's "possible" that you can flash everything from Android 12 but the bootloader itself, and it might still work. Even if so, this doesn't mean that a further bootloader change in Android 13 after more updates will remain compatible with Android 12.

I haven't liked doing mix or match partition images on my device in the last six years, however.
[Google Pixel 6 Pro] whatsisnametake2:
fair enough. what is the technical reason you can't flash a 12 bootloader after a 13 bootloader? is it not just flashing data into a certain area of the phones memory? overwriting any existing data? outside my knowledge zone that one.
[Google Pixel 6 Pro] roirraW "edor" ehT:
This warning at this page:

and:

PSA: You can't downgrade from Android 13 on Google's latest Pixel phones

You can't downgrade from Android 13 on Google's latest Pixel phones, so keep that in mind if you hop between builds a lot.

www.xda-developers.com

I don't know anything technical about it beyond the information given in those two places.
[Google Pixel 6 Pro] whatsisnametake2:
thanks for the info. I don't understand why google is doing this tho. they are very liberal when it comes to flashing and rooting. why implement an anti roll back boot loader? what's wrong with going back to 12 if you have some random issue on 13?
[Google Pixel 6 Pro] CRXed:
But isn't this whole BOTH slots discussion coming from the warning that if it fails to boot on the active slot, it can brick your device??

https://twitter.com/i/web/status/1559397044208402433
[Google Pixel 6 Pro] roirraW "edor" ehT:
There are many possible reasons. It could even be as simple as that they determined that downgrading the bootloader from Android 13's is dangerous/resulted in bricks in testing, so they'll just disable the ability to downgrade it from 13's. There's also this from the XDA article I quoted:

And we don't definitively know that we absolutely can't still flash Android 12 (minus 12's bootloader), at least along with wiping the phone.
[Google Pixel 6 Pro] V0latyle:
Flashing to both slots should not brick your device. The only thing that should cause a brick is if something goes wrong with the bootloader. This is the one disadvantage with the OTA - it only updates one bootloader slot, and it seems that once Android 13 boots, it's no longer possible to go back to an older bootloader.

So, if you want to be really safe, flash the updated bootloader to both slots, then update however you want. If it fails and switches slots, you should still be able to reflash.
[Google Pixel 6 Pro] CRXed:
Then why are people still saying to not flash both slots and to first boot the device after only flashing it to one slot....
[Google Pixel 6 Pro] Lycidias:
Could it be done before flashing the A13 update?

I think of flashing only bootloader to both slots and then install A13 via PixelFlasher.

If yes, which are the right commands to flash only bootloader to both slots ?

Thanks
[Google Pixel 6 Pro] roirraW "edor" ehT:
It's a valid question, however I think we're worrying about it more than necessary. Each person can choose their own standard operating procedure in this case. No matter what way, it's inevitable a few people will have an issue anyway.
[Google Pixel 6 Pro] roirraW "edor" ehT:
Yes (I did). Android 12 still booted with Android 13 Stable's bootloader, but your mileage may vary.

fastboot flash bootloader bootloader-raven-slider-1.2-8739948.img

fastboot --set-active=a
(If you're on slot b)

or

fastboot --set-active=b
(If you're on slot a)

fastboot flash bootloader bootloader-raven-slider-1.2-8739948.img
[Google Pixel 6 Pro] V0latyle:
Yes....you can update the bootloader by itself

fastboot flash bootloader --slot=all <drag and drop bootloader image into command window>

This flashes both slots at the same time, there's no need to switch from one to the other.

As far as those advising against flashing to both slots...I would say that in this specific case, since we are dealing with an issue that is supposed to prevent rollbacks, the safest thing to do if you don't plan on updating both system slots is to update both bootloader slots. That way, if there's something wrong and the system bootloops to the "old" slot, it should still boot.
[Google Pixel 6 Pro] Utini:
Has anyone tried flashing with disabled vbmeta and disabled veritfy on Android 13?

This should be the correct way then:
[Google Pixel 6 Pro] Lughnasadh:
Yes, but as stated here, it shouldn't affect end users...

https://twitter.com/i/web/status/1559410066993938432
[Google Pixel 6 Pro] Homeboy76:
I'll take the 2 pennies. :) :)
[Google Pixel 6 Pro] Lughnasadh:
Don't use the A12 bootloader after being on A13. Whether you can revert to A12 using the A13 bootloader after being on A13 remains to be seen, but seems more probable than what we thought yesterday.
[Google Pixel 6 Pro] V0latyle:
Why would you need to? It would work exactly the same way

fastboot flash vbmeta--disable-verity --disable-verification vbmeta.img

To each his own, but as I pointed out, if there's potential for a brick because of the anti rollback protection in the bootloader, it's best to at the very least flash the updated bootloader to both slots. That way, if something goes wrong, you can still reflash everything, vs possibly having a brick because the device tried to roll back to the old slot which had the previous bootloader.
[Google Pixel 6 Pro] Lughnasadh:
This is the likely reason...

https://twitter.com/i/web/status/1559537708959154177
[Google Pixel 6 Pro] Namelesswonder:
You can boot Android 12 on the 13 bootloader.

https://xdaforums.com/t/android-13-...itory-of-relevant-links.4352027/post-87287915
[Google Pixel 6 Pro] Utini:
Because I am currently on disabled verity and because most problems with custom kernels seemed be related if it having it not disabled.
[Google Pixel 6 Pro] V0latyle:
At some point someone's just going to have to test it. Since the bootloader itself handles writing images to partitions, I suspect the bootloader will simply reject older images - similar to how the factory image checks bootloader and radio version before installing. You -could- create a script to manually flash the images within the factory package (boot, vendor, vbmeta, system, etc)
[Google Pixel 6 Pro] Lughnasadh:
Yes, I know. Saw that yesterday. But he didn't revert to A12 after being on A13. He only used the A13 bootloader while still on A12.
[Google Pixel 6 Pro] Lughnasadh:
Yes, someone will have to be on A13 and then revert to A12 using the A13 bootloader to find out for sure.
[Google Pixel 6 Pro] Lughnasadh:
I flashed A13 with verity & verification disabled. I just put the command in the update line of the flash-all.bat script, as I have done every month since November, lol.
[Google Pixel 6 Pro] V0latyle:
I'm talking about the bootloader itself. I doubt there will be an issue with attempting to flash an older factory image as long as bootloader is excluded.
[Google Pixel 6 Pro] Lughnasadh:
I think we're saying the same thing.
[Google Pixel 6 Pro] gpvecchi:
Same recent app switcher freeze for me as in beta. Stock launcher with gestures.
[Google Pixel 6 Pro] Namelesswonder:
That is true, the bootloader's behavior could change when the efuse is blown, and his wasn't because the Android 12 HAL isn't capable of blowing the efuse. We already know the bootloader doesn't care if the efuse isn't set, it will still function. We know the bootloader prevents you from downgrading itself. We also know that the boot ROM just straight up dies if it somehow encounters the situation of the efuse blown but the bootloader it's trying to load is older. Currently it is unknown if the bootloader does a check to see if the kernel is older when the efuse is present, but I have doubts that it would go that far.
[Google Pixel 6 Pro] roirraW "edor" ehT:
No freeze here. I've been doing a lot of Recents-app switching today (using gestures).
[Google Pixel 6 Pro] V0latyle:
Agreed. I don't think there's a physical "e-fuse", it's just a version check in the bootloader code that prevents older bootloader images from being flashed (or loaded if already flashed). @roirraW "edor" ehT was able to boot Android 12 on the 13 bootloader...BUT, he hadn't booted A13 yet. So this remains to be seen:

Will A13 bootloader prevent flashing an older system image?

Will A13 bootloader refuse to boot an older system image?

I think this is a pretty safe thing to experiment with as the bootloader will at worst simply reject flashing or booting, and at best will just carry on as normal.

If I had a Pixel 6 I'd try it.
[Google Pixel 6 Pro] roirraW "edor" ehT:
Just to add my two cents to anyone thinking of testing this scenario, whereas I do agree it is "probably" safe to attempt flashing Android 12 (sans Android 12 bootloader) after having upgraded to and booted Android 13, if you don't do a full wipe when you flash Android 12, coming from 13, then expect problems that could range from things just working funky to the phone not booting because it will then be Android 12 running with Android 13 app data.

So if anyone wants to test this, be prepared to do a full wipe, and if you don't do a full wipe and you find Android 12 doesn't boot - that itself won't be conclusive due to the fact a full wipe would be required to be considered definitive.

If Android 12 does boot but just exhibits some strange behavior (might not notice right away), then that's definitive to me, although even if you re-upgrade to full Android 13, if you then have strange problems I would still consider a full wipe as then you're dealing with an unexpected 13->12->13 app data situation.
[Google Pixel 6 Pro] Zilla0617:
More info on my issue with my phone not entering deep sleep. Usf_queue and usfsensorhalworker are the 2 wakelocks keeping my phone awake according to BBS
[Google Pixel 6 Pro] Namelesswonder:
It is blowing a fuse.

interfaces/boot/1.2/BootControl.cpp - device/google/gs101 - Git at Google

The bootcontrolhal, on a successful boot, will attempt to blow the efuse. It writes 1 to /sys/kernel/boot_control/blow_ar. It doesn't write anything to the devinfo partition, which is where things like the boot count and current slot are. In fact, devinfo wasn't updated at all for this.

drivers/soc/google/boot_control/boot_control_sysfs.c - kernel/gs - Git at Google

Inside boot_control it uses SMC to speak to the TZ/TEE to set the value, since you can't just let even the OS directly control the hardware. There is no undoing this value once set, there are no methods to undo it. This is permanent.

The only way around this is what GrapheneOS is doing and they reverted the commit, but that just stops it from being set by boot_control.

[temporary] Revert "BootControl: blow AR on boot complete" · GrapheneOS/device_google_gs101@1b73448

This reverts commit 9ecd004e6bf34260c17c39bb29d0a718fa01cd1f.

github.com
[Google Pixel 6 Pro] roirraW "edor" ehT:
Unfortunately, a Google search about those don't tell me anything relevant that I can see. I really am not a wakelock guru, though. I hope someone else knowledgeable about them can assist you.
[Google Pixel 6 Pro] V0latyle:
I guess I'm splitting hairs then, because there's still no physical fuse that gets physically destroyed...but what you described has the same effect, permanently writing a 1.

Question is, when exactly is blow_ar called? What does this change/how is it used? Does this simply mean the bootloader will reject older bootloader images, or that it will reject all images older than the bootloader date?
[Google Pixel 6 Pro] rester555:
If I reflash the bootloader to both slots, I would have to re flash magisk patched image correct?
[Google Pixel 6 Pro] jcp2:
if you want root - correct.
[Google Pixel 6 Pro] rester555:
So just to verify, the boot image that has to be flashed to both slots would be the bootloader-raven-slider-1.2-8739948.img not the boot.img file that we use to patch with magisk correct?
[Google Pixel 6 Pro] roirraW "edor" ehT:
Just to be clear, the bootloader is not boot.img (kernel). The boot.img is what gets patched by Magisk. If, for example, you're still on Android 12, you update ONLY the bootloader to Android 13 Stable's bootloader, then you'll still have root because you haven't overwritten boot.img.

Boot image does not equal bootloader. Don't confuse the two.

Boot image = kernel

Bootloader is just the bootloader.
[Google Pixel 6 Pro] rester555:
Ok, that's what I thought, but being on A13 with root, I should still flash the bootloader to both slots to avoid a brick correct?
[Google Pixel 6 Pro] lesafijndt:
Just upgraded through pixelflashed from android 12, worked perfectly, data kept and no bricking encountered.
[Google Pixel 6 Pro] roirraW "edor" ehT:
You can upgrade to Android 13 your usual way. You can flash to both slots if you're worried about it. I don't know if flashing only the bootloader to both slots will particularly prevent a brick. I only flashed to one slot yesterday (Android 13 full factory image, so including bootloader), and then today I did flash the full factory image to the second slot, but in my case I already knew the first slot was completely working as expected.
[Google Pixel 6 Pro] Sneakyghost:
eFuse: the name is being used way to broadly imho. People call software fuses "eFuse" as well as a "real" a.k.a physical eFuse.

eFuse uses a concept of electromigration, that describes how chips die over time from the metal lanes "migrating" and becoming thinner or thicker in places due to electrons wandering off. This makes the entire metal wander inside the silicon, very slowly. This also kills each and every chip at some point. An eFuse just makes use of this. There will be one or many lanes specifically designed to be very very thin, so that the material almost completely "wanders off" when that place is activated electrically. Say there is a bit that can hold a "1" or "0" and the wiring to that bit contains that fuse (that is how I imagine it visually), flipping that bit from 1 to 0 or vice versa might physically blow the wiring. Maybe after one such write operation, maybe only after several. I dont know.

There is a brief Wiki for the eFuse invention here: WIKI

And the question I find no answer to is: does Google make use of this disgusting tech on the Pixels?

But it also really doesn't matter to us because if the "fuse" is tripped, the Pixel is dead. Who cares if it was software or hardware when the phone does nothing anymore? I havent seen many people dig around with jtag and testpoints these days anymore. A hardware efuse could perhaps prevent those skilled folks from messing on low level with dead devices. A hardware eFuse could even prevent jtag resurrection, while a pure software fuse could be forcefully overwritten with a jtag device and tons of skills. Thats the only benefit in my humble understanding. But who am I? I know nothing.

As long as this Android 13 Update doesn't trip the wire, we can all be happy campers, right?
[Google Pixel 6 Pro] Namelesswonder:
There actually is a physical object being destroyed. Yes, there isn't a typical fuse being blown, as a typical fuse blows and opens the circuit. Instead what is implemented is an antifuse. These are the opposite of fuses ("anti") and are normally open. When enough voltage is passed they blow closed, and they actually do blow, they use oxide-breakdown cells that physically break down when the voltage threshold is met. This is more favorable for integrated circuits as blocking flow is a 0 and flowing is a 1. Old terminology hangs around and still refers to these as a fuse, from IBM's technology they named "eFuses" even though they perform opposite of a fuse. The modern terminology is to call them One-Time Programmable memory, or OTP memory. Modern processors have plenty of these. I don't know how many OTP bits are included on Tensor, but another ARM SoC the Rockchip RK3399 has 2 kibibits worth of OTP.

You can read more about them in this PDF, page 31 chapter 6 section 3.

There are OTP cells being blown, inside boot_control it is invoking a system monitor call with what I think are called contexts or secure applications, SMC_CM_OTP_CONTROL (0xC2001014UL).

OTP_CONTROL being One-Time Programmable Control.

The other things being passed are CMD_W_ANTIRBK_NS_AP (0x7UL) and CMD_W_ANTIRBK_S_AP (0x9UL), which are the bits (7 and 9) being blown. I can only infer that the NS and S are for the normal world (NS) and secure world (S).

As for when /sys/kernel/boot_control/blow_ar is being blown, it is blown inside BootControl::markBootSuccessful, which is what is setting both the fuse and writing to devinfo that the slot had booted successfully. I don't know when exactly a boot is successful, but it is being ran by a service after Android boots up enough to be considered a success.

What does it change and how does the bootloader use this? Well, we'll never know. We're not privileged enough to know this. The source code for the many (there's something like four) bootloaders are kept closed source. Anything below the kernel and device tree we just don't know. Given that there is a bricked Pixel 6 out there due to the bits being blown on A13 and the slot switched back to A12, it isn't just the Android bootloader checking this, it's below that in either the BL1 or BL2 boot firmware. This I assume lines up with the bits being blown for normal world and secure world, as BL1 operates in the secure world while the Android bootloader operates in the normal world.

What can we do about this? Really, nothing.
[Google Pixel 6 Pro] rester555:
I have used physical eFuse's in my EE job IRL, so yeah, I wouldn't want to trip that :). Thanks for the information!
[Google Pixel 6 Pro] rester555:
Would I retain root if I flash-all to the other slot and switch back to my first slot flashed?

EDIT: Currently, I have slot a active with A13 rooted, slot b I haven't flashed to yet.
[Google Pixel 6 Pro] roirraW "edor" ehT:
Maybe. Probably. In my case, I just rooted both slots.
[Google Pixel 6 Pro] V0latyle:
Yes
[Google Pixel 6 Pro] Sneakyghost:
Thanks guys. Always apreciate learning new stuff. I was aware of electromigration as one mechanism but this "oxide breakdown" bit has me interested. I will have to look that up now. Learn more :)
[Google Pixel 6 Pro] V0latyle:
Thanks for the detailed explanation. I wonder why this is the first time we are hearing of the e-fuse? It also makes one wonder why Google is taking such permanent measures, given their generally open attitude towards developers on Pixel/Nexus devices...like, who cares if someone was able to downgrade?

As far as what it does and what it changes, it sounds like this is something we'll have to find out for ourselves unfortunately. But for the time being I would think it's safe to say that everyone updating should flash the A13 bootloader to both slots just to be safe in case of a alternate slot bootloop.
[Google Pixel 6 Pro] rester555:
I've only used eFuses in military applications, never in commercial. My 2 cents.
[Google Pixel 6 Pro] roirraW "edor" ehT:
https://twitter.com/i/web/status/1559537708959154177
[Google Pixel 6 Pro] rester555:
Major flaw most likely
[Google Pixel 6 Pro] V0latyle:
Right, I saw that. Unless there's a major exploit in the Pixel 6/6 Pro/6a bootloader that would allow downgrading even if locked, I can't imagine anything being more severe than that.