[BUG] Missing HECI PCI device and SOF firmware failed to load on ADLP Chrome device #4923
Comments
keqiaozhang
added
bug
|
@keqiaozhang can you bisect, must be something recent, I had a quick look but nothing obvious. |
|
This is the first time we run Ubuntu on ADLP Chromebook, I'm not sure whether it's a regression or not. But I did some debugging.
I also did some search and found we have a similar issue on CML chromebook before, Same ROM code |
That is correct and in case of unfortunate timing the retry should address the problem. The interesting part is how it actually works on Chrome OS. I would like to recommend investigation of SOF driver routine that load FW and check if there are no differences between Chrome and Ubuntu OS. Generally from FW perspective there is not much we can do about it. |
|
@mwasko there's no difference at the driver level see above the chrome kernel used in Ubuntu also has a problem And we already retry 3 times before throwing an error, see above. |
In that case you need to contact BIOS/CSME team for support. |
|
@keqiaozhang is this failure from power ON or reboot. Just thinking if this needs @keyonjie IMR PR |
|
@lgirdwood this failure is from power on, so I don't think IMR PR will help. |
|
I run to this issue on another ADLP Chrome device(I2S mode) with same rom error: The rom status I'm checking this issue with coreboot team. |
|
The latest update from CSME team: |
mengdonglin
changed the title
What does "enumerated" mean here? Enumerated by whom? Where can this enumeration be seen or seen missing?
Indeed, with the same coreboot and same kernel even! Pure user space code should not affect low level CSE communication channels like this, this does not make sense. |
|
Coreboot team has found the root cause of this issue. The solution is that we can modify the GBB flags value of coreboot image under ChromeOS to disable the EC sync. |
EC sync (update) is a normal security feature so I don't understand why the Chromebook would enter recovery mode when using it. Recovery mode was never mentioned in this bug before. Also, the OS is not involved in recovery because recovery mode is designed to recover the OS.
How does that follow?
This disables the EC sync flag 0x200 but resets all other (more or less unknown) flags too
There's no need to flash coreboot after updating the GBB flags.
|
The previous GBB set flags are: 0x00000239
This is used to change the GBB flags for the Tianocore Coreboot.
Because set_gbb_flags is only available under ChromeOS, but we aim to flash the coreboot with Tianocore to support UbuntuOS. So we change the GBB flags for the Tianocore coreboot and flash this coreboot image to install UbuntuOS. |
The previous flags can be whatever. To change one line in a configuration file no one overwrites the entire configuration file (makes it impossible to know what fixed what).
This is the first time Tianocore is mentioned in this bug. Previously it was:
Still not clear how the EC version or update affects the CSME or recovery mode. It's all very nebulous https://www.google.com/search?q=programming+by+coincidence |
|
This issue was fixed by coreboot. Close it. |
|
I'm on an unrelated platform, but I ran into this after disabling MEI and found this ticket. Maybe this info might be useful to someone. I'm on Coffee Lake and I disabled Intel MEI via HAP bit so the HECI device isn't present. My platform defaults to the audio DSP disabled and uses a generic HDA driver on Windows with Waves extensions. I intentionally enabled the audio DSP (0xF48 to 1) and set it to Intel SST mode (non UAA compliance, 0xF49 to 0). Prior to disabling MEI, audio with SST worked fine on Windows (after some forced driver installs) and out-the-box on Linux and I noticed in dmesg some new firmware loading info. Now with MEI disabled, I get this in dmesg along with no audio (kernel 6.3.8 Fedora 38): I don't have a particular need for the DSP and was mostly just experimenting with different setting; I can just re-disable the DSP and have no problems on my platform. I've heard of some interesting issues when disabling ME, but I wasn't expecting audio to be tied to it :p |
https://thesofproject.github.io/latest/getting_started/intel_debug/introduction.html#firmware-binary
|
Describe the bug
I tried to run sof on ADLP chrome device w/ ubuntuOS installed, but firmware failed to boot with error:
But same firmware binary can boot under ChromeOS and we used the same coreboot image with chrome team(expect the payload for Ubuntu). This is not the key error and I also force prob i915(i915.force_probe=46a8).
To Reproduce
run sof on ADLP chrome device and check the dmesg after booting.
Reproduction Rate
100%
Expected behavior
firmware can load w/o errrors.
Impact
What impact does this issue have on your progress (e.g., annoyance, showstopper)
Environment
dmesg
Full dmesg can be found here:
dmesg.txt
The text was updated successfully, but these errors were encountered: