The issue is that Tianocore fails to execute (hangs the system) when used as a legacy boot/alternative bootloader entry on 90% of CrOS devices which support the alternative bootloader feature, and since coreboot disables console output via the CPU UART, I don't have a good way to debug the issue (ie, no CCD output). The exact same Tianocore payload works as the primary/only payload with upstream coreboot on these platforms (all GeminiLake, Kabylake, Cometlake and probably other boards). The only boards it works on are some (but not all) AMD Stoneyridge boards (google/kahlee) and Intel Whiskeylake (google/sarien).
Well, if you want to track this down your best bet is probably to recompile coreboot with serial output enabled. If you cannot reproduce this with upstream, you can build from the respective Chromium OS firmware branch for that device. Then you'll have exactly the same code we build. (You could also try extracting the depthcharge binary from a Chrome OS image and inserting it into an upstream coreboot image you built, if you think it's a problem specifically with how depthcharge loads the payload. But I think it's more likely to be a difference in coreboot.)
I can also just send you Chromium firmware images with serial output enabled for specific boards if that helps (we have those readily available, we just don't have a system to make them public). Let me know which ones you need.