[Google Pixel 3 Questions & Answers] DragonFire1024:
Ok sorry I have been pretty busy. This is the basic rundown. From here you can pretty much navigate to a lot of information. Aside from the citadel stuff, discovering the possibilities of what we might bea ble to do, came from this link: https://chromium.googlesource.com/chromiumos/third_party/hdctools/+/HEAD/docs/ccd.md

In the contents you can click on raw access:

These tools are not made for either of our setups, we're just lucky they still work with our distros. You will need to go here and setup hdctools and ec_tools. You will have to do a lot of small tweaking in the udev files as you go until you get the proper connections. I still haven't yet, but I had made really good progress today and was extatic to see my device to show up at

Here's where is a good place to get started. This tells you the basic stuff. We're going to be doing a lot of Jerry rigging, especially software wise:

hdctools: Chrome OS Hardware Debug & Control Tools - Closed Case Debug (CCD)

A lot of this is going to be hit or miss, except for the Embedded Controller. The one benefit we have with this console is knowing that at least the pixel 3, has an ec.bin in /vendor/bin/hw (it's in the vendor image but I'm not at my PC and it's either in bin or HW). Now is a good time to download the factory images for the pixel 3 but I think your pixels will probably suffice. If you have factory images available you probably want to download the vendor image. Any basic hex editor will do at least if you just want to read the excessively long binary file just to see that it contains pretty much everything in the console that we're first going to get access to, and then some.

Here is the tool set we're pretty much going to be working from and where we've got to do a lot of rigging so to speak. A lot of the stuff just is not going to work or if it does it's going to take a bit to get it to work because it is not designed for our type of environment. With that being said the proper tweaking should get us all the ability to write a file.

chromium / servod-tools · GitLab

Collabora GitLab

gitlab.collabora.com

Here's royal you'll figure out the amount of dependencies you're going to be missing. There are a LOT of udev files and configs. Because each device is different, they'll all need to be tweaked differently. I don't think the kind of pixel matters, this should work of them. For me, the emulated device is 18d1:5014. When you get it to persist (run lsusb in a terminal) then you are almost there. In a terminal:

usb_console -d 18d1:xxxx

X being your emulated device. I say emulated because though you are working at it from a console it is actually connected to your device this is not an emulation per se. Now after entering the USB console if a bunch of rx errors aren't scrolling across the screen every second, then just type in the terminal the word help. There is your first interactive console it's not much but it gives us the basics. I believe this is the AP console but I don't know. So one thing for sure is, it is being done in uart. Anyways that's just to get you started and it may take you a while to get it all running. But when you go to install hdctools, install The other dependency inside of it. So clone into hdctools, build and install. And then when Don don't leave the directory clone into EC, build and install. That was my latest attempt to try and get all of these files to recognize each other and I didn't have much time to look it over but there is quite a difference. So that might cut down on time significantly or it might not.

So I was able to downgrade from the Android 12 build. I think they probably implemented a way for individuals to do that, given the amount of them that may not be able to. It's a new implementation they have and it actually worked. Since you're part of the Android beta program they now have a way where you can opt out of it and within a few hours or less they will send an OTA that will downgrade you back to Android 11 I did that because I thought it would fix my SIM card and so did Google. It did not. I'll get to that in a second. Citadel OEM commands still work on this build. Maybe even more so at least in terms of the consoles we open. When you do have a good connection you're going to notice what look like button values being pressed. Those are virtual buttons and those are your debug messages. I've noticed a few instances in those debug messages where it's a little bit different than it was in Android 12. I can't paraphrase the log and I'm not going to try but it was a little bit interesting. Also through my in Denver's of trying to fix this damn sim card I did several factory resets. During that time I have never seen this before on any Android device much less Google one, one phrase came up at the end before the factory reset was finished

wiping Titan M Citadel Chip

.

I don't know if that always happened and I'm just noticing it because of the debug messages. But this actually appeared on the device screen as the factory reset was literally on its last second. I did not get a screenshot unfortunately I could not and I did not have at the time a way to take a picture. This would explain one thing though only connecting the two, I did see something similar where it seemed like the citadel chip was being erased or formatted while looking around inside EC.bin. so I'm wondering if any of the commands I might have attempted beforehand actually succeeded but also wasn't supposed to have any effect other than hoping it would actually do something.

Since then I have been seeing some weird things in the debug messages in the console that comes up every time we connect. One of them even said

brickv0.0.3:done

That's a brief paraphrase but I am also now seeing in the same console after this a lot of the log messages relating to 'avb_fastboot bl: 0' which in this case might not mean necessarily unlocked but might mean 'not in bootloader mode' but there are a few logs that did suggest that at the moment it was being printed 'bl: 0' meant unlocked. Especially at times when it seems like something is being written in very small blocks in between actions or reboots.

Anyways 'brick' is the name of the firmware for this particular citadel chip on my device. Which brings me to my next to do. I have finally gotten device 5014 to show up in /dev/Google. Also please know as you get things to work you're going to notice that they're not all worded the same. In this case there might be a different console involved here that I am unaware of called proto2, or that just could be the code name for the embedded controller in this case. But anyways in normal instances in a normal environment, proto2 = servo. The issue I have here I think is because according to any schematic I can get while in this mode there is no serial number for 5014 and I'm not sure there's an actual board in terms of the normal setup of all this. So my guess is we have to somehow implement the actual board of the device?

Anyways sorry for such a long post but this is all the time I had and I wanted to get it down because I won't be able to write back or at least be contributing a lot for the next few days because of work. I also ordered a pixel 4a directly from the Google store. Because they actually gave me a $400 line of credit to buy one without a contract. Amazon flat out denied me. So you learn a lesson in this case. You get what you pay for. And I should have went to Google in the first place and saved all this trouble. So in the next week or so this pixel 3 will become my new testing device for what we're doing here and my 4A will be my daily driver.