"chipset" command freezes on Ryzen 9 7945HX platform

[moldimolt]

Hello,

On my Ryzen 9 7945HX, the chipset command does not work properly. I will provide the log with debug messages enabled:

>>> debug
-> Debug: enabled
>>> chipset
Detected chipset:
=> Family: 19
=> Model: 61

-> One dword read from 00:14:03 offset 00000000h: 790e1022h
-> One dword read from 00:14:03 offset 00000004h: 0220000fh
-> One dword read from 00:14:03 offset 00000008h: 06010051h
-> One dword read from 00:14:03 offset 0000000ch: 00800000h
-> One dword read from 00:14:03 offset 00000010h: 00000000h
-> One dword read from 00:14:03 offset 00000014h: 00000000h
-> One dword read from 00:14:03 offset 00000018h: 00000000h
-> One dword read from 00:14:03 offset 0000001ch: 00000000h
-> One dword read from 00:14:03 offset 00000020h: 00000000h
-> One dword read from 00:14:03 offset 00000024h: 00000000h
-> One dword read from 00:14:03 offset 00000028h: 00000000h
-> One dword read from 00:14:03 offset 0000002ch: 14331043h
-> One dword read from 00:14:03 offset 00000030h: 00000000h
-> One dword read from 00:14:03 offset 00000034h: 00000000h
-> One dword read from 00:14:03 offset 00000038h: 00000000h
-> One dword read from 00:14:03 offset 0000003ch: 00000000h
-> One dword read from 00:14:03 offset 00000040h: 0000001ch
-> One dword read from 00:14:03 offset 00000044h: ffffffffh
-> One dword read from 00:14:03 offset 00000048h: ffffffffh
-> One dword read from 00:14:03 offset 0000004ch: ffffffffh
-> One dword read from 00:14:03 offset 00000050h: ffffffffh
-> One dword read from 00:14:03 offset 00000054h: ffffffffh
-> One dword read from 00:14:03 offset 00000058h: ffffffffh
-> One dword read from 00:14:03 offset 0000005ch: ffffffffh
-> One dword read from 00:14:03 offset 00000060h: ffffffffh
-> One dword read from 00:14:03 offset 00000064h: ffffffffh
-> One dword read from 00:14:03 offset 00000068h: ffffffffh
-> One dword read from 00:14:03 offset 0000006ch: ffffffffh
-> One dword read from 00:14:03 offset 00000070h: ffffffffh
-> One dword read from 00:14:03 offset 00000074h: ffffffffh
-> One dword read from 00:14:03 offset 00000078h: ffffffffh
-> One dword read from 00:14:03 offset 0000007ch: ffffffffh
-> One dword read from 00:14:03 offset 00000080h: ffffffffh
-> One dword read from 00:14:03 offset 00000084h: ffffffffh
-> One dword read from 00:14:03 offset 00000088h: ffffffffh
-> One dword read from 00:14:03 offset 0000008ch: ffffffffh
-> One dword read from 00:14:03 offset 00000090h: ffffffffh
-> One dword read from 00:14:03 offset 00000094h: ffffffffh
-> One dword read from 00:14:03 offset 00000098h: ffffffffh
-> One dword read from 00:14:03 offset 0000009ch: ffffffffh
-> One dword read from 00:14:03 offset 000000a0h: ffffffffh
-> One dword read from 00:14:03 offset 000000a4h: ffffffffh
-> One dword read from 00:14:03 offset 000000a8h: ffffffffh
-> One dword read from 00:14:03 offset 000000ach: ffffffffh
-> One dword read from 00:14:03 offset 000000b0h: ffffffffh
-> One dword read from 00:14:03 offset 000000b4h: ffffffffh
-> One dword read from 00:14:03 offset 000000b8h: ffffffffh
-> One dword read from 00:14:03 offset 000000bch: ffffffffh
-> One dword read from 00:14:03 offset 000000c0h: ffffffffh
-> One dword read from 00:14:03 offset 000000c4h: ffffffffh
-> MSR:[c0010058]: 00000000F000001D
-> 000000c4 bytes read from physical Memory 00000000FFFFFFC0
-> Successfully mapped physaddr ffffffc0 to 0000022684860FC0

[n3k]

It seems there are some major differences in the way things are mapped in this particular model.

[moldimolt]

Is there any way I can help?

[bm16ton]

I have same issue on ryzen 7 8840u apu. gpd win max 2, tho the same soc on gpd win mini it works fine.

[bm16ton]

So for me ryzen 7 8840u zen4 for sum reason it was failing too accurately distinguish between new and old amd in function amd_retrieve_chipset_information, failing to set "spi_addr = AMD_DEFAULT_NEW_SPI_ADDR" or "isNewAmdChipset = true" once i hard coded those it goes thru fine now. @moldimolt I would try this. In PlatboxLib/src/amd/amd_chipset.cpp function amd_retrieve_chipset_information replace;
} else {
spi_addr = spi_addr & 0xFFFFFFC0;
_isNewAmdChipset = false;

with

} else {
    spi_addr = AMD_DEFAULT_NEW_SPI_ADDR;
    _isNewAmdChipset = true;

This is a dirty dirty hack, but at least see if its the same issue/area to fix.

[n3k]

I'll be updating some of this portion with the release of the sinkclose exploit soon.

[bm16ton]

Thank you! And again thank you for all your work and time, unbelievably awesome project.

…

On Sat, Aug 24, 2024, 4:09 PM Enrique Elias Nissim ***@***.***> wrote: I'll be updating some of this portion with the release of the sinkclose exploit soon. — Reply to this email directly, view it on GitHub <#9 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ADAWMP7YIOJ5YO6YSTQGPYTZTDR7ZAVCNFSM6AAAAABNBSIVJ6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDGMBYGUZDGNZZGQ> . You are receiving this because you commented.Message ID: ***@***.***>

[m1lua]

@n3k

hello.

same behave on BIOS Model name: AMD EPYC 7702P 64-Core Processor CPU @ 2.0GHz
while debugging saw that whole /dev/KernetixDriver0 (spi_base mapping) filled by 0xff

312     void amd_spi_execute_command(volatile SPI *spi_base) {
313         SPI x = {0};
314         spi_base->CmdTrig = 0xff;
315         memcpy(&x, (const void*)spi_base, sizeof(*spi_base));
316         while((spi_base->CmdTrig & 0x80) != 0);  // infinity loop here
317         while(spi_base->SpiStatus.SpiBusy);
318         while(spi_base->SPI_Cntrl0.SpiBusy);
319     }

any advises?