GuC issue

[maksym at wezdecki.pl]

Hi,

Please see GuC log attached to this email.

Log size is "PAGE_SIZE+Debug Log(64KB) + Crash Log (8KB) + Capture Log (1M)"

Can anybody from Intel decode this log buffer? Thanks.

What am I doing wrong?

Maksym


poniedziałek, 19 lutego 2024 09:44, maksym at wezdecki.pl <maksym at wezdecki.pl> napisał(a):

> 
> 
> Hi,
> 
> I fixed one issue in my driver. Log address was set incorrectly.
> 
> Right now, after GuC uploading, GUC_STATUS changed.
> Right now, intel_guc_load_status is INTEL_GUC_LOAD_STATUS_INIT_DATA_INVALID = 0x71.
> 
> What does it mean?
> Could you please help me with this?
> 
> Thanks,
> Maksym
> 
> 
> 
> piątek, 9 lutego 2024 08:42, natur.produkt at pm.me natur.produkt at pm.me napisał(a):
> 
> > Hello,
> > 
> > Please see my comments below.
> > 
> > piątek, 9 lutego 2024 2:45 AM, John Harrison john.c.harrison at intel.com napisał(a):
> > 
> > > Hello,
> > > 
> > > What platform is this on? And which GuC firmware version are you using?
> > 
> > It's TGL. I'm using tgl_guc_70.1.1.bin firmware blob.
> > 
> > > 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.
> > 
> > Thanks for the hint. I'm not doing that at all in my code. How am I supposed to do this? Is there a specific register for that?
> > 
> > > Did the status change at all during that second of waiting? Or was it
> > > still reading LAPIC_DONE?
> > 
> > It's always 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.
> > 
> > Ok, that great. Which part of ADS is must-have then?
> > 
> > > 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.
> > 
> > I'll collect GuC log as soon as possible. Is it something that can be understood without a knowledge of GuC internals? Or is it simply hex dumps?
> > 
> > > 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
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: fullLog.txt
URL: <https://lists.freedesktop.org/archives/intel-gfx/attachments/20240220/f4ba35a6/attachment-0002.txt>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: fullLog.txt
URL: <https://lists.freedesktop.org/archives/intel-gfx/attachments/20240220/f4ba35a6/attachment-0003.txt>