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@xxxxxxxxxxx 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@xxxxxxxxxxx <maksym@xxxxxxxxxxx> 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@xxxxx natur.produkt@xxxxx napisał(a):
Hello,
Please see my comments below.
piątek, 9 lutego 2024 2:45 AM, John Harrison john.c.harrison@xxxxxxxxx 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@xxxxx 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
