AMD Port #1
Comments
|
Hello! |
|
The text was updated successfully, but these errors were encountered: |
|
Hi @deineris189, it was not planned, but I had a quick look yesterday at an older AMD datasheet where I found the exact bits that would be required for the XHCI SMI generation. As I don't have an AMD device, I cannot verify if those bits really exist/still work, @jussihi might be able to assist here. What would need to be changed:
I've created a second branch in the repository for AMD, where I'll prepare the changes how I think it should work, maybe we can extend it to multi-platform without big problems 😄 The datasheet can be found here, it is for Bulldozer so the offsets might not work anymore: BIOS and Kernel Developer’s Guide (BKDG) for AMD Family 15h Models 70h-7Fh Processors |
|
Amazing news! I'll keep an eye on the AMD port branch then! |
|
I've been messing around a bit, normally this would be way out of my realm but thanks to you basically giving a full guide it hasn't been terrible. Much appreciated! 😄
|
|
@deineris189 Thanks for the input. We also found out that the MBAR and device array is there (although in different bus & function on my system), just like on Intel, but couldn't toggle the XHCI_SMI_EN bit. Or at least the system instantly turns the bit back off. And since we don't have a reliable way to read out SMI count on AMD (at least on Wind0ze), I couldn't read if it actually issued an SMI and turned the bit off inside SMM. If this is the case, we could then in AMD's case just always toggle the bit back to 1 when executing our SMM code. If you have more time to fiddle with it, please do and report back your findings :) Or if you are able to find some sort of tool to read out the SMI count on Windows. |
|
@jussihi If I'm not mistaken doesn't Zepta have an SMI Counter implemented in his SmmInfect project? Not sure if it works the same or does what we need here but maybe you could look at that and see. |
|
@deineris189 yeah, but his implementation gets the SMI count (not the real count, the amount his SMM module is executed) from the SmmInfect SMM module via memory write to the usermode application buffer. Obviously this could be used but I don't have a flash programming chip (last time I hw flashed a SPI chip was in 2021 or 2022) so cannot do it and check it right now :) |
To add on this topic, we should change the code to use the Host Operational Registers to get the DCAB. This way we would support each XHCI controller following the standard. Looks like this would mean checking the class code of each possible device in PCI to locate only XHCI controllers. For the execution, as @jussihi pointed out we need to have a way to verify if continuous execution is really working. I'll check with Zepta if he can verify this :). |
|
Hi @deineris189, on @jussihi's board the XHCI register block (which contains the bit that would trigger SMI on USB events) is all zero'd out. Can you check if the memory at "0xfed81C00" is empty for you? If it is, there might be a chance that it is only empty on runtime. We would have to check on pre-boot in SMM if it is mapped then. |
|
@pRain1337, you mean like this? |
Yes exactly, so it also is empty on your board. If it is also empty there, I don't see a way to toggle SMI reliably on each USB event based on the available public informations for AMD boards. Redirecting the USB interrupts using the IDT would work, but patchguard will crash the system after like 30 minutes. Using another way of getting SMI (e.g. some timer) will not reliably create a SMI when the USB transaction is happening (thus the actual USB packets wont be overwritten). But the framework could be reused to create something that does not require the USB features (e.g. transfer the data out and then use a hardware device to move the mouse). |
|
Ah, that's a shame but big thanks to both of you for trying to find a way to solve it. |
|
While writing the code for multi-XHCI support I found another bit that could be used to toggle SMI on XHCI events, haven't had time to test it but finally did it (thanks to Zepta). The XHCI specification has so called xHCI Extended Capabilities, here the XHCI controller can define additional capabilities which also includes the "USB Legacy Support" which can be used to trigger a SMI on XHCI events. I see one possibility being a third party PCI XHCI controller which might support it out of the box, but don't have one that I could use to verify (and not sure if they really support this feature). Checking for extended capabilities is pretty simple, take MBAR of the XHCI device (PCI config + 0x10, 64-bit value) and then read the Capability Parameter (Offset 0x10, 32-bit value). The xHCI Extended Capabilities Pointer (xECP) is bits 31:16. Bit 7:0 is the Capability ID, here we would be looking 0x1 (Bit 1). In The AMD Board we tested it was always 0x20 or 0x10. See "7 xHCI Extended Capabilities" in the Intel XHCI datasheet Maybe this helps or someone has a PCI XHCI Controller to verify this. |