[Google Pixel 6 Pro] t-m-w:
I did not find a solution, but I did spend a while looking into this for a bricked Pixel 7 Pro before setting it aside a while back. What follows is kind of an info dump, in case it helps anyone else working on this, but it's not enough info in itself to solve anything. Also, the repair shop that was recommended by Google couldn't fix it, either — it wasn't the battery or the screen, of course, but they did try those, including leaving the battery unplugged for a bit just in case. They had estimated several hundred USD to replace the motherboard, so that was where we parted ways.

Anyway, when trying to fix it myself, here's what I found, with the help of info in this thread:

EUB appears to support the xmodem protocol with CRC (it sends the C symbol repeatedly), seemingly to request that you send it specific partitions. You can use the python xmodem library, but you will need to ignore extra characters in your getc method, as the device will spam its eub:req and C lines, and that can lead to confusion and issues with use of the library. If you try to send a file without using xmodem, as others here have done, you'll get a lot of chatter back from the device when it encounters characters like 0x18 in the file, which isn't handled as expected without the xmodem protocol (from what I can tell).

xmodem1k looks to be partly supported, but it will get NAK'd when smaller files are expected.

With standard 128-byte xmodem, I tried to use the NAK responses to guess at the file size that the device is expecting for what it's requesting and (hopefully) make sure I was on the right track, by continuing to send data until NAK. It's kind of a shot in the dark, though.

My Pixel 7 Pro asks for DPM and then for EPBL, unless I hold all the buttons for a while (power, volume up, volume down), in which case it will ask for bl1. Anything I provided was met with "bl1 header fail" and "irom_booting_failure::", each typically followed by several 32-bit hex values separated by a null byte.

The device will need to be unplugged and replugged after enough failures before you can talk to it again, which can be a source of frustration, to say the least. You can potentially automate this by disabling and re-enabling the USB port, by writing to /disable on the USB node.

The bl1 partition has 0x200 of data at the beginning that varies between firmware versions. This might be a signature. Is this the header the device is referring to? (Note that "bl1 header fail" occurs no matter what you send, even if all you send is a few zeroes, a lot of zeroes, or nothing at all.)

Requests for DPM can accept up to 12288 bytes (0x3000 bytes) before getting NAK'd. This happens to be the size of bl1.

Requests for EPBL can accept up to 77824 bytes (0x13000 bytes), which is of unknown significance; for what it is worth, the PBL image provided in factory images is only 40960 bytes, although on a separate device, Pixel 6a, the partition *itself* takes 81920 bytes. There seems to be zero-padding or unused space involved in some places, so that could be related.

Requests for bl1 can accept up to 90112 bytes (704 xmodem blocks) before getting NAK'd. This is the size of bl31.

Every time you send a file for a request, or enter ^X (0x18), you'll receive eub:ack.

DPM and EPBL are requested in a loop. Nothing seems to happen no matter I provide.

bl1 requests, on the other hand, always respond with "bl1 header fail", etc. No other file is requested.

Here are a few tasks/questions I left off with (not expecting anyone to have the answers):

- What does bl1 header fail mean? Is there something I was failing to provide, or was I providing too much / the wrong thing / in the wrong way?

- In the DPM/EPBL loop, do I have to do something to make the device try to use the files we provided in order to proceed, or am I simply providing them incorrectly? And what even is "DPM"? (If I try to pull dpm_a or dpm_b off a rooted device with an unlocked bootloader, it's 36864 bytes and filled with zeroes.)