+Scott +Duncan.

Is this still reproducible?  I haven't had any luck repro'ing in brief testing today.

Yes, I was able to repro this just yesterday :/
I believe the issue is specific to the model of charger (see g/usb-c/P23OwLNlkVI/8HrWTL5yAgAJ)

Adjusting summary based on group comments.

This CL from Sam, crrev.com/c/1130000 was mentioned as a possible WA.

I've cpick'd to eve branch here: crrev.com/c/1419777

+some more EC folks in case they have more advice finding to share for this bug.

> (see g/usb-c/P23OwLNlkVI/8HrWTL5yAgAJ)

I cannot access that link. "We are sorry, but you do not have access to this service. Please contact your Organization Administrator for access."

Can you please refer me to the Apple model number? Is it this one (MRW22LL/A)?
https://www.apple.com/shop/product/MRW22LL/A/61w-usb-c-power-adapter

That patch Sam and I worked on should have already been included in the tree. 
However, I think it is only present *IN THE RW* copy of the firmware. Not RO.

The Eve would have to boot *far enough* to have it jump from RO to RW.

Since you are in "dead battery" state, and EC is dead-dead-dead (powered only by leak-through from charger 5v once it comes on), it will not "wait" to open up the ACGATE fet... and therefore will slam an OCP event.

So unless you are willing to push Sam's fix to RO firmware... I don't think it's possible to fix this in dead-batt condition.


Note:
I am not an EC firmware engineer, and am probably botching the explanation I got from Sam and Aseda. Please forgive my attempt to answer quickly (albeit possibly incorrectly).

Right, it depends when the overcurrent is happening in the boot process. If it's occurring before jumping to RW and PD negotiation happens, that's an RO change.

re: apple model number? 

Unfortunately it was never mentioned AFAICT but here's your post from the link,

>> Apple 87w and 61w chargers implement overcurrent protection in a very defensive way.
>> If the device spikes input current beyond allowable limits, the charger will "latch off" until it is removed from AC power and replugged.
>> 
>> Many other chargers [like Google's] will simply reboot ("hiccup") after a short delay. Or, will clamp output voltage to 0v until the load is removed ("constant-current >> limit").
>> From my testing, only the Apple 30w charger uses "hiccup".... the 87w and 61w appear to use "latching off".
>> 
>> This causes me to believe that in dead battery condition, your Corp Pixelbook is overcurrenting the Apple supply.
>> What version OS/firmware are you running?
>> 
>> You can find out in Settings -> About Pixelbook -> Version
>> then -> Detailed Build information -> Firmware, Platform
>> 
>> Based on your description that "priming" the Pixelbook capacitors with another charger fixed the issue, I think it may be this:
>> It is an bug Sam Hurst and myself were banging our heads against the wall for a while on. So I may be biased in assessing cause.
>> 
>> https://Chromium-review.googlesource.com/c/chromiumos/platform/ec/+/1130000
>> 
>> I am not sure if you have it or not, or if it works during "dead-battery condition" in the EC.
>> 
>> Regards,
>> Nathan Kolluru

re: patch applied,

I wasn't able to find the cpick either from gerrit or from w/in the repro.  It was cpick'd to eve-campfire but not eve ( cros/firmware-eve-9584.B ).  That as you and Aseda mentioned may be by design if the fix is known only to work if part of RO.  That wasn't immediately apparent to me from reading CL or other bug however.

If that is the case it may still make sense to land the change to avoid confusion.  If not I'll happily abandon it as well.

Sounds like this is a cant-fix for eve though

We were going to let it soak in the campfire branch first, but it should be safe to pull it to eve firmware now.

As noted it won't help with RO, which is a shame.