Hello, What platform is this on? And which GuC firmware version are you using?
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.
Did the status change at all during that second of waiting? Or was it still reading 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.
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.
John. On 2/6/2024 23:59, natur.prod...@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
