GuC issue

Tue Feb 27 20:03:36 UTC 2024

On 2/26/2024 08:30, maksym at wezdecki.pl wrote:
> Hello,
>
> Thank you for your help.
>
> Is there a possibility to load GuC, then "unload" it and load it again without cold reset?
You need to reset the GuC at least - bit 3 of GDRST. The GuC cannot be 
reloaded 'live'. It must be put into reset first. The last line of 
__uc_sanitize() is a call to reset the GuC, so yes that would be an 
option. Note that fini is more about cleaning up to unload the driver. 
Whereas the sanitise functions are about resets with the potential to 
restart again.

John.

> By loading I mean HuC firmware upload, GuC ADS/log init, GuC firmware upload, CT init, HuC authentication by GuC.
>
> I'm asking because I need to perform severe testing on the target for safety purposes without GPU cold reset.
> What should be done in order to "unload" the GuC? Is it __uc_sanitize() and __uc_fini()?
>
> Maksym
>
> czwartek, 22 lutego 2024 20:31, Harrison, John C <john.c.harrison at intel.com> napisał(a):
>
>>
>> Hello,
>>
>> That worked better. The complaint is that the engine mapping table is invalid. See the i915 code in guc_mapping_table_init () in gt/uc/intel_guc_ads.c for an example of how to initialise the table.
>>
>> John.
>>
>>
>> -----Original Message-----
>> From: maksym at wezdecki.pl maksym at wezdecki.pl
>>
>> Sent: Wednesday, February 21, 2024 07:15
>> To: Harrison, John C john.c.harrison at intel.com
>>
>> Cc: maksym at wezdecki.pl; Wajdeczko, Michal Michal.Wajdeczko at intel.com; intel-gfx at lists.freedesktop.org
>>
>> Subject: Re: GuC issue
>>
>> Ah, I dumped them with Windows new line characters.
>>
>> Here is a new log binary dump.
>>
>> I moved to the newest TGL GuC firmware from linux-firmware repo.
>>
>>
>> środa, 21 lutego 2024 12:16 AM, John Harrison john.c.harrison at intel.com napisał(a):
>>
>>> 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