GuC issue

John Harrison john.c.harrison at intel.com
Fri Feb 9 01:45:18 UTC 2024


Hello,

What platform is this on? And which GuC firmware version are you using?

One thing you made need to do is force maximum GT frequency during GuC 
load. That is something the i915 driver does. If the system decides the 
GPU is idle and drops the frequency to minimum then it can take multiple 
seconds for the GuC initialisation to complete.

Did the status change at all during that second of waiting? Or was it 
still reading LAPIC_DONE?

For ADS documentation, I'm afraid that the best we currently have 
publicly available is the i915 driver code. If you are not intending to 
use GuC submission then most of the ADS can be ignored.

If you can share the GuC log, that might provide some clues as to what 
is happening. For just logging the boot process, you shouldn't need to 
allocate a large log. The default size of i915 for release builds is 
64KB. That should be plenty.

John.


On 2/6/2024 23:59, natur.produkt at pm.me wrote:
> Hi,
>
> I'm currently implementing GuC/HuC firmware support in one Safety Critical OS.
> I'm following i915 code and I implemented all paths (I don't want GuC submission or SLPC features). I need GuC to authenticate HuC firmware blob.
>
> I mirrored GuC implementation in my code.
>
> After GuC DMA transfer succeeds, I'm reading GUC_STATUS register.
> HW returns INTEL_BOOTROM_STATUS_JUMP_PASSED as bootrom status and INTEL_GUC_LOAD_STATUS_LAPIC_DONE as GuC load status.
>
> Unfortunately, after one second of waiting, the status didn't get changed to INTEL_GUC_LOAD_STATUS_READY at all.
>
> What is a potential issue here?
> Could you please help me?
>
> In addition to this, could you please point out some documentation about GuC's ADS struct?
>
> Thanks,
> Maksym



More information about the Intel-gfx mailing list