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
æ©»ÊíþÞ ð æ©»ÊÞ?? 0 0 ö©»Êíþï¾
??? F @ K ¼ªW
À 4 ǪW
î¾ÞÓªW
åªW
ªõ î¾Þ
°W
î¾Þ°W
@ E °W
PE 4B /°W
Ð@ @ 9°W
xA H°W
î¾ÞS°W
_°W
P 4 i°W
Ð ? v°W
x ?°W
î¾Þ?°W
@ E ?°W
PE 4B ¡°W
Ð@ ¬°W
xA Á°W
î¾ÞË°W
% Õ°W
P% 4" à°W
Ð ï°W
x! B±W
U±W
î¾Þî¾Þ æ©»ÊíþÞ ð æ©»ÊÞ?? 0 0 ö©»Êíþï¾
??? F @ K ¼ªW
À 4 ǪW
î¾ÞÓªW
åªW
ªõ î¾Þ
°W
î¾Þ°W
@ E °W
PE 4B /°W
Ð@ @ 9°W
xA H°W
î¾ÞS°W
_°W
P 4 i°W
Ð ? v°W
x ?°W
î¾Þ?°W
@ E ?°W
PE 4B ¡°W
Ð@ ¬°W
xA Á°W
î¾ÞË°W
% Õ°W
P% 4" à°W
Ð ï°W
x! B±W
U±W
î¾Þî¾Þ
