GuC issue

[John Harrison]

Hello,

Something is very corrupted with that GuC log. The log consists of a 
header page and then a stream of log entry structures. The structure is 
supposed to be 20 bytes long and starts with a four byte time stamp. But 
I am seeing what is conceivably a 32bit timestamp appearing at 21 byte 
increments through the log. Even more curiously, the time stamp seems to 
have an 0x0D, 0x0A after it. Are you doing any printf type operation in 
order to write the log out from memory to disk?

INTEL_GUC_LOAD_STATUS_INIT_DATA_INVALID means that the GuC did not like 
the initialisation data passed in. Most likely, something in the ADS 
structure is not valid. If you try with the latest GuC version, that 
might give you more information as to what is the incorrect. More status 
codes have been added since 70.1.1.

John.


On 2/20/2024 05:03, maksym at wezdecki.pl wrote:
> 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