Sonnet M.2 4x4 PCIe Card via SSDT als internes Gerät Konfigurieren - Sage 10/G

Zitat von pgr69

Also würde das Beispiel von DSM2 dazu führen dass eine in dem M.2 Anschluss angeschlossene PCIe-NVMe entsprechend angezeigt wird. Da die SM951 aber eine SATA-SSD im M.2 Format ist erscheint diese im Systembericht unter SATA und nicht unter NVME.

Zum einen ist es eben ein BEISPIEL, zum anderen hast du es immer noch nicht verstanden. Im Systembericht unter PCI würdest du einen Eintrag sehen, so wie du das Gerät unter "name" eben benennst und als Slot eben "M.2". Völlig Wurscht, ob das nun NVMe oder SATA ist. Entsprechend siehst du bei NVMe natürlich nix. Würdest du in der SSDT bei "name" von mir aus "tolles Gerät" schreiben und für den Slot "der kleine" schreiben, dann würde eben das angezeigt werden.

Zitat von pgr69

MEIN PROBLEM liegt ja nicht …

Das hat hier jeder verstanden. Du anscheinend nicht, dass es nur um ein Beispiel ging, dass lediglich die Syntax erklärt.

Zitat von pgr69

Unter PC01.BR1A.SL01.pci-bridge@8 finde ich dann die besagten Laufwerke.

Bingo. In deiner SSDT gibst du nun also diese Adresse ein, anstelle von dem derzeit noch nicht in der ACPI vorhandenem Device "pci-bridge@8" denkst du dir ein neues (vier Zeichen) Device aus. Sofern deine Sonnet eben auf "pci-bridge@8" liegt. Liegt sie davor (SL01), dann beschreibst du eben diesen vorhandenen Scope. Anbei mal ein Versuch aus der Ferne, ohne weitere Hintergründe:

Du siehst, dass hier "hinter" SL01 nun eine neues Device "SOFU" (Sonnet Fusion) eingefügt wurde, mit einer spezifischen Adresse "_ADR, 0x00080000" (pci-bridge@8).

Zitat von pgr69

Und nochmal zur UUID...nehme ich da die selbe wie im Beispiel oder ist das bei mir eine andere ?

Nein, wieso? Ich schrieb doch, es referenziert auf die Methode "DTGP". Du solltest dir schon die Mühe machen, diese Methode auch mal anzuschauen, dann fällt dir sicher etwas auf. In meinem Beispiel habe ich diese Methode integriert.

Zitat von pgr69

Kann ich nun das von DSM2 gepostete Beispiel nehmen und _SB.PC00.RP21.PXSX ersetzen durch _SB.PC00.BR1A.SL01 ersetzen? Wobei die Samsung IDs ja erst unter PC01@0/BR1A@0/SL01@0/pci-bridge@8/pci-bridge@0/pci-bridge@8/pci144d,a808@0 auftauchen. Alles davor sind die Multiplexer für die PCI-Lanes (Vendor 10b5 Device 8747 und 8732)

Es geht NICHT um die angeschlossenen NVMe an den vier Steckplätzen. Es geht um den Sonnet-Controller davor. Der sollte, wie im Beispiel beschrieben, als "internes Gerät" definiert werden.

Zitat von pgr69

Die in Deinem Beispiel verwendete Adresse 0x00080000....ist die erfunden oder woher kommt die?

Nein. Wieso sollte ich die "erfinden"?

Zitat von apfelnico

spezifischen Adresse "_ADR, 0x00080000" (pci-bridge@8).

Zeig mal deine IORegistry mit geladener SSDT. Hast du meinen Quellcode 1:1 übernommen? Was ist im Systembericht/Systeminformationen zu sehen?

pgr69

Nein, es ist "nur" die "@8". Und wahrscheinlich falsch, weil wir damit die "Bridge" beschrieben haben, aber nicht den Controller an sich. Wie ich oben schon schrieb, eventuell das Device davor (SL01), beziehungsweise in einem "Scope" (einem vorhandenen Device weitere Properties hinzufügen). Also noch mal, nun so:

Zitat von pgr69

Oder muss jetzt erst die hintereinander liegenden PCI-Bridges nacheinander als neue Devices definiert werden damit ich ihnen Properties zuweisen kann ?

Genau. Anders geht es nicht via SSDT. Es muss ja ein Device vorhanden sein, das man beschreiben will. Noch mal den Baum genau angeschaut, dann eben ganz tief rein:

pgr69

OK, bis morgen.

Edit: Wahrscheinlich kann man den ganzen Krempel auch in eine Kext packen (Properties Injection). Hätte den Vorteil, falls dieses Problem auch richtige Macs (MacPro) betrifft, könnten diese das unkompliziert nutzen. Denn eine SSDT können die nicht nutzen, es sei denn, die hauen zum Beispiel OpenCore davor.

Aber dennoch interessant, das mal an einer SSDT durch zu exerzieren. Über OpenCore direkt geht das natürlich auch.

Zitat von pgr69

Gestern stellte sich mir die Frage warum bei _ADR einmal was drin steht und dann wieder nichts......aber es ist ja nicht NICHTS sondern Zero also 0 und diese Werte kommen von dem was jeweils hinter dem "@" stand oder ?

Exakt.

Zitat von pgr69

Bei der Benamung der Devices hast du einfach ABCD genommen und wäre es tiefer gegangen wäre es alphabetisch weiter gegangen mit E usw. ?

Genau. Da es so viele sind und ich nix kreatives mehr leisten wollte, eben so. Was da steht, ist letztendlich (oft) Wurscht. Es müssen max. vier Zeichen sein, Buchstaben und Zahlen sind erlaubt, Zahlen allein gehen nicht. Manche Treiber, Kexte reagieren aber auf bestimmte Namen der ACPI-Devices.

Zitat von pgr69

Mir ist im IORegExplorer aufgefallen dass da noch andere Devices rumlungern die nur mit ihrer VendorID und DeviceID aufgeführt sind. Weis nur nicht mehr ob es auf dem Sage10g oder auf meinem derzeitigen Designare EX war. Egal....die Frage ist.....diese Devices kann ich doch dann auf die gleiche Art und Weise mit vernünftigen Properties versehen aus denen hervorgeht um was es sich dabei handelt.

Kann man machen, muss man nicht. Und immer einen Blick in die DSDT werfen. Wenn dort schon eine _DSM-Methode vorkommt – bei den vielen Basis-Geräten ist das der Fall – dann geht das so über eine zusätzlich SSDT nicht. Denn innerhalb eines Devices bzw dessen Scope dürfen nicht gleiche Methoden angewendet werden, dann wird diese SSDT ignoriert. In vielen Fällen ist es einfacher, Device Properties im Bootloader festzulegen. Der Vorteil einer SSDT ist aber, dass hier schon auf ACPI-Ebene Dinge repariert und oder verbessert werden, auch lassen sich hier Properties verschiedenen Typs einsetzen. Zum Zeitpunkt in dem der Bootloader dies macht, ist schon eine Menge gelaufen und es können nur nach Properties mit dem Type "DATA" injiziert werden. Oftmals, gerade für die kosmetischen Dinge, ausreichend. Mitunter möchte man aber "Number" nutzen, das geht dann direkt über SSDT.

Völlig anders. Nur die Grundidee bleibt, einem spezifischen Gerät weitere Properties einzuimpfen.