Red Ribbon: wie CPU/GPU-Temperatur auslesen?

    Diese Seite verwendet Cookies. Durch die Nutzung unserer Seite erklären Sie sich damit einverstanden, dass wir Cookies setzen. Weitere Informationen

    • Red Ribbon: wie CPU/GPU-Temperatur auslesen?

      Servus und hallo!

      Ich frage mich seit Tagen, wie ich die CPU/GPU-Temperaturen unter "Red Ribbon" auslesen kann. :?:

      Ich weiß, dass es für GameOS diverse Apps gibt, "Rebug" gibt das bspw. in der Toolbox aus. Aber unter Linux!?

      Installiert und versucht zu konfigurieren habe ich:
      • lm-sensors
      • xsensor
      • psensors
      • pwmconfig
      Keines dieser Tools liefert erkennbare Hardware zurück.

      Weiters frage ich mich mittlerweile, ob "Red Ribbon" wie damals "YDL" auf einem Hypervisor läuft.
      Unter einem Hypervisor hätten wir keinerlei Zugriffe auf die Hardware direkt, diese wäre nur virtuell vorhanden.
      Sony hat sich da schon geschickt abgesichert. Soll ja jetzt nicht Thema sein, nur frage ich mich zunehmend, ob das "Hypervisor-Problem" gelöst wurde oder ob das überhaupt nicht geht.

      Danke im Voraus für die Tipps und bis bald!
    • Alles und immer läuft über hypervisor, egal ob der lv2_kernel, einer der ps2_emus oder ein linux.
      Alles ist ein guest-OS das auf dem lv1_kernel läuft und als abgesichertes/virtuallisiertes interface zum lv1 nur die hypervisor-syscalls hat.
      Das wird sich auch nicht ändern, außer jemand schreibt 'ne Firmware wo dann z.B. ein linux direkt auf der hardware läuft.

      Ich interessiere mich nicht mehr für linux auf der PS3 und hab seit Jahren kein linux mehr auf PS3 laufen.

      Im lv1 gibt es den Virtuellen UART, port 2, den system manager. Über Kommunikation mit den Servern im lv1 werden Sachen wie start/shutdown,
      LEDs abfragen und ansteuern, der system buzzer und 'ne Menge andere Sachen erledigt.
      Auch die Temperaturen werden so abgefragt und der Lüfter kann auch angesteuert werden.

      Vielleicht lassen sich die von dir gennanten Tools anpassen. Der linux kernel selbst muss ja auch irgendwie mit dem system manager arbeiten, ansonsten würde gar nix laufen.
      Oder man könnte versuchen herrausbekommen wo die RX/TX buffer für vuart_2 sind, dann kannst du mit lv1_vuart_write() Anfragen im richtigen Packetformat über den TX
      senden und die results über den RX bekommen. Kurz gesagt. Es ist natürlich mehr dazu nötig, z.B. auf Synchronisierung achten und was sonst noch anfällt.
    • Nice, wenn man wegen der bekloppten Hitze nicht zum pennen kommt und einem langweilig ist...
      Ich hab eben mal die vmlinux.elf aus dem letzten Red Ribbon durch IDA gejagt.
      Dann nach hv-calls gesucht, lv1_vuart_write(), hat mich zu einer Funktion namens ps3_sys_manager_write() geführt.
      Also die Funktion gegoogelt und die Seite hier mit den PS3 linux drivern gefunden.

      code.woboq.org/linux/linux/dri…tml#ps3_sys_manager_write

      Wie man sieht gibt's hier keinen call wie ps3_sm_get_temperature() im Modul. Man muss ihn also schreiben, ist einfach,
      (service_id, payload und seine size, wo im response liegen die temp Werte... alles bekannt)
      und einen kernel kompilieren der dann eben auch diese Funktion in der API hat.
      Dann müssen die von dir oben gennanten Tools erweitert werden, damit man sie für PS3 PPC64 configure'n und
      kompilieren kann. Läuft halt auf der PS3 als guest-OS(VM) mit dem system manager anders als bei "normaler" PC hardware.
    • Ja, das mit dem Nicht-Pennen-Können kenne ich nur zu gut...

      Also am Kernel soll es nicht liegen: git.kernel.org/pub/scm/linux/kernel/git/geoff/ps3-linux.git
      Hier findet man mit der 4.11er-Version einen stabilen für die PS3, der nur 3 Monate alt ist.

      Was ich nicht ganz verstehe ist: wie können wir diesen Patch bauen? Mir müssten ja dann in der Lage sein den 4.11er-Kernel zu patchen und der hat dann diese temp-Funktionen.

      Was meinst du genau mit "ist einfach"? In deiner Klammer habe ich leider keinen Begriff verstanden. Ergo werde ich das so kurz nebenbei nicht bauen können...

      Aber hey, scheint ja die richtige Spur zu sein! Danke dir dafür!
    • Also ich sehe nix neues in: ps3-linux-4.11/drivers/ps3/ps3-sys-manager.c

      Dem module bekannte service IDs sind:

      Quellcode

      1. enum ps3_sys_manager_service_id {
      2. /* version 1 */
      3. PS3_SM_SERVICE_ID_REQUEST = 1,
      4. PS3_SM_SERVICE_ID_RESPONSE = 2,
      5. PS3_SM_SERVICE_ID_COMMAND = 3,
      6. PS3_SM_SERVICE_ID_EXTERN_EVENT = 4,
      7. PS3_SM_SERVICE_ID_SET_NEXT_OP = 5,
      8. PS3_SM_SERVICE_ID_REQUEST_ERROR = 6,
      9. PS3_SM_SERVICE_ID_SET_ATTR = 8,
      10. };

      Es gibt aber 61 service IDs im system-manager und die sid zum Temperatur abzufragen ist 13, die zugehörige resonse(Antwort) sid ist 14.
      Wenn ich dieses "Namensschema" für die enums in meinem letzten system_manager reversing fortführe:


      Man müsste also erst mal die beiden neuen hinzufügen:

      Quellcode

      1. PS3_SM_SERVICE_ID_TEMPERATURE = 13,
      2. PS3_SM_SERVICE_ID_RESPONSE_TEMPERATURE = 14,

      In ps3_sys_manager_write() zum "senden" von request packets an den system manager hast du folgendes:

      Quellcode

      1. BUG_ON(header->version != 1);
      2. BUG_ON(header->size != 16);
      3. BUG_ON(header->payload_size != 8 && header->payload_size != 16);
      4. BUG_ON(header->service_id > 8);

      Die version und die header_size sind immer 1 und 16, also ok. Aber BUG_ON() bei einer sid > 8, so wird kein header mit sid 13 durchgelassen.
      Ich würde es quick&dirty auf > 61(max) setzen. Die request(Anfrage) payload_size für den get_temperature header ist 8 byte, verursacht also kein Problem.

      Dann braucht es noch die neue Funktion, benutze z.B. eine andere wie ps3_sys_manager_send_attr() als Vorlage:

      Quellcode

      1. static int ps3_sys_manager_get_tempature(struct ps3_system_bus_device *dev, u8 tzone_id)
      2. {
      3. // der header für unsere anfrage
      4. struct ps3_sys_manager_header header;
      5. // der payload der dem header folgt, mit zusatz daten für unsere anfrage,
      6. // welche termal zone wollen wir abfragen?
      7. // tzone_id = 0(CELL) oder 1(RSX)
      8. struct {
      9. u8 version;
      10. u8 tzone_id;
      11. u8 reserved_1[6];
      12. } payload;
      13. // noch mal die payload size checken...
      14. BUILD_BUG_ON(sizeof(payload) != 8);
      15. // und im fehlerfall 'ne debug message ausgeben
      16. dev_dbg(&dev->core, "%s:%d: %d\n", __func__, __LINE__, t_zone);
      17. // den header mit 0 initialisieren und dann ausfüllen
      18. memset(&header, 0, sizeof(header));
      19. header.version = 1;
      20. header.size = 16;
      21. header.payload_size = 8;
      22. header.service_id = PS3_SM_SERVICE_ID_TEMPERATURE;
      23. // den payload mit 0 initialisieren und auch ausfüllen
      24. memset(&payload, 0, sizeof(payload));
      25. payload.version = 1;
      26. payload.tzone_id = tzone_id;
      27. // abschicken
      28. return ps3_sys_manager_write(dev, &header, &payload);
      29. }
      Alles anzeigen


      Jetzt bearbeitet der system manager im lv1 unseren request(Anfrage)...
      Die response(Antwort) messages, die vom system manager kommen, handelt die Funktion ps3_sys_manager_handle_msg().
      Das ist so was wie ein übergeordneter handler, der dann die verschiedenen Typen von responses zum zugehöhrigen
      handler weiterleitet.

      Hier brauchst du einen neuen case im switch, falls ein response mit sid 14 reinkommt, also das Antwortpaket mit der Temperatur die du abgefragt hast.

      Quellcode

      1. ...
      2. // ein request error: z.B. wenn ein request(anfrage) mit einer response(antwort) service ID wie 14 abgesended wurde.
      3. // 14 ist reserviert für einen response(antwort), es ist KEINE request(anfrage) servive ID!!!
      4. // in dem fall wird hier mit dump_sm_header() der header detailiert ausgegeben, um sagen zu können wo der fehler ist.
      5. case PS3_SM_SERVICE_ID_REQUEST_ERROR:
      6. dev_dbg(&dev->core, "%s:%d: REQUEST_ERROR\n", __func__, __LINE__);
      7. dump_sm_header(&header);
      8. break;
      9. // ein response(antwort) auf einen temperature request(anfrage) wurde erhalten
      10. case PS3_SM_SERVICE_ID_RESPONSE_TEMPERATURE:
      11. dev_dbg(&dev->core, "%s:%d: PS3_SM_SERVICE_ID_RESPONSE_TEMPERATURE\n", __func__, __LINE__);
      12. // hier brauchst du einen handler zum handhaben des response(antwort)
      13. return ps3_sys_manager_handle_temperature_request(...);
      14. ...
      Alles anzeigen
      Der Haupt-handler(First stage msg handler) hier sollte nicht mit code zugemüllt werden, er sollte nur weiterleiten.


      Ein Programm wie lm-sensors muss ps3_sys_manager_get_tempature() ausführen um an die Temp's von CELL und RSX zu kommen,
      einen anderen Weg gibt es nicht. Der handler ps3_sys_manager_handle_temperature_request() muss die Temperatur an lm-sensors zurückgeben.

      Ansonsten kann ich dir nur noch das layout des response payloads sagen:

      Quellcode

      1. struct payload {
      2. u8 version; // 0x00: version, immer 1
      3. u8 tzone; // 0x01: die nach der wir gefragt hatten, 0(CELL) oder 1(RSX)
      4. u8 status; // 0x02: 0 = OK, wenn nicht ging was vor den baum
      5. u8 pad_0; // 0x03: padding
      6. u8 temp_0; // 0x04: die "ganzzahl", z.B. 49 °C
      7. u8 temp_1; // 0x05: nachkommastelle, siehe devwiki lv2 syscalls zum berechnen
      8. u16 pad_1; // 0x06: padding
      9. };

      Viel weiter kann ich dir nicht helfen, ich finde es gut wenn sich noch Leute für linux auf PS3 interessieren, aber für mich ist es nicht mehr interessant. :)
    • Das sieht mir jetzt aber nicht danach aus, als würdest du dich nicht mehr mit PS3-Linux beschäftigen. ;)

      Respekt, der Herr!

      Deinen Codes kann ich so weit folgen, würde das mit dem Kernel 4.11 und dem Anpassen ja gerne ausprobieren: nur habe ich gerade keinen TV, der ist gestorben. Suche auch hier im Forum nach Ideen für einen Nachfolger.

      Nachdem wir das ja jetzt suchen mussten wie irre würde mich mal interessieren, wie das "Rebug" macht? Also muss GameOS ja Zugriff auf die Sensoren geben, OtherOS/OtherOS++ aber nicht?

      Mir persönlich würde ja die Temp. des Cell schon reichen: hierauf richtet sich mein Augenmerk, habe paar Bücher hier, die ich mit dem durcharbeiten will. Ist ja eine sehr interessante, wenn auch exotische Architektur. Mein einziger 9-Core, wenn man so will.

      Wie regelt das denn Linux gerade, ohne diese Patches, die man manuell pflegen müsste? Weil der Lüfter unter Linux schon mal stärker, mal weniger stark lüftet, je nachdem, was man macht. Nur eben nicht so häufig, wie ich das z.B. von Laptops gewohnt bin. Und _das_ dachte ich eben kommt daher, dass das OS keinen richtigen Zugriff hat.

      Nun gut, muss ich anstellen. Will eigentlich dran werkeln, aber bin ja derzeit nicht in der Lage. -.-
    • z4z4sh1 schrieb:

      Das sieht mir jetzt aber nicht danach aus, als würdest du dich nicht mehr mit PS3-Linux beschäftigen.
      Das hat nix mit Ahnung zu tun, und die linux API is einfach zu verstehen und es gibt auch genug Erklärungen im Netz. ;)

      z4z4sh1 schrieb:

      Nachdem wir das ja jetzt suchen mussten wie irre würde mich mal interessieren, wie das "Rebug" macht? Also muss GameOS ja Zugriff auf die Sensoren geben, OtherOS/OtherOS++ aber nicht?

      Noch mal zum Verständnis, ich glaub du siehst das mit dem linux hier falsch.

      Wenn die PS3 startet entschlüsselt lv0 die Komponenten(lv1_kernel, lv2_kernel, EID usw) dann wird der lv1_kernel gestartet.
      Im Speicher bleibt vom lv0 eine Liste mit den entschlüsselten Komponenten zurück und natürlich die Komponenten selbst.

      Jetzt startet "ein" guestOS das virtuell auf dem "echten" kernel, dem lv1, läuft. Dieses guestOS hat als Verbindung zum lv1
      nur die beschränkten Möglichkeiten die zugelassen werden: das GOPI(Guest Os Process Interface, aka hv_syscalls).
      Die virtuellen UARTs die man einrichten kann:
      port 0(avsetup, audio video, z.B. HDMI Kram, RSX Audio Kram, ... Sachen abfragen aber auch setzen können),
      port 2(system manager)

      In der "normalen" Konfiguration(XMB, spielen...) läuft der lv2_kernel als guestOS. Ein "zweiter" kernel. Auf
      dem läuft der vsh Prozess, entweder aleine(XMB) oder "minimiert" neben einem Spiel. So wie der lv1_kernel seinem
      guestOS Prozess ein interface zur Verfügung stellt(stellen muss, sonst läuft ja nix), stellt der lv2_kernel seinen
      Prozessen(vsh, game) auch eines, die lv2_syscalls. Der lv2_kernel richtet auch die vuarts ein die gebraucht werden,
      0(avsetup), 2(systemmanager), 10(ss_multiplexer, hat mit der ganzen decrypt scheisse zu tun, piracy interessiert mich nicht)

      Eine zweite Möglichkeit ist die PS2 Emulation. Basierend auf der Hardware(BC/semi-BC/keine PS2 hardware) läuft als
      GuestOS z.B. der ps2_gxemu oder der ps2_netemu. Auch hier als interface die hv_syscalls. Auch hier müssen die vuart
      ports 0(avsetup) und 2(system manager) eingerichtet werden damit sie benutzt werden können.

      Dritte Möglichkeit linux als GuestOS. KEIN UNTERSCHIED, hv_calls als GOPI, vuart port 0 und 2 sind hier die linux kernel module
      die du in ps3-linux-4.11/drivers/ps3/ hast. Und die können nur das was sie können, wenn Temperatur Abfragen fehlt, muss
      es hinzugeschrieben werden. Aber hier gibt es wenigstens einen source code, rate mal wie lustig es war die temp Anzeige in
      den ps2_netemu zu zaubern. Den source code des ps2_netemu werde ich niemals zu sehen bekommen.


      Wenn ich ein Tool mit z.B. psl1ght schreibe, wie damals das PS3 Temp Tool, dann ist das wie die Toolbox ein lv2(gameOS)_process.
      Mit dem lv2_syscall nr 383 sys_game_get_temperature() fragt man hier die temps ab. Der syscall im lv2_kernel bekommt sie intern
      über vuart port 2(system manager), abgefragt mit hv_call lv1_vuart_write(), Antwort mit lv1_vuart_read(). Du verstehst... ;)

      Wenn du dem linux kernel modul für den system manager die Temperatur Abfrage hinzufügst, ist es so wie mit lv2_syscall nr 383 sys_game_get_temperature() im lv2_kernel.

      Quellcode

      1. guestOS: Methode: Programm/Prozess das auf dem GuestOS kernel läuft und es nutzt:
      2. lv2_kernel lv2_sc: sys_game_get_temperature() PS3 Temp Tool/Toolbox/MultiMan/...
      3. linux(kernel) must du schreiben lm-sensors/xsensor/psensors/pwmconfig/...

      Unter der Haube, im lv1 kernel ist es immer das selbe. Und hier z.B. werden Anfragen an den system manager zu Anfragen der syscon, noch ne Ebene tiefer, hehehe.
      Vorher wird nur noch gecheckt ob das guestOS(die LPAR) die Erlaubnis hat es zu tun. Mit dem Toolbox lv1 patches kannst du alle sm Sachen für OtherOS++ "freischalten".

      Und was die Lüfter Regelung angeht, die wird über die gegenwärtige Fan policy automatisch gesteuert. Wenn du in lv2(gameOS) z.B. 'ne eigene mit webman festlegst, dann gilt die auch in linux.
      Den Kram könnte man dem linux system manager natürlich auch noch hinzufügen.