Bei mir ist AtmosXL noch nie abgestürzt. Das teil läuft butterweich, nutzt du es im high Memory Modus?
Zudem ist AtmosXL bereits das beste Tool.
[Support] Atmosphere-NX mit SX Core / SX Lite Modchip
-
- [Switch]
- kempa
-
-
Mensch klasse!
Auf diese Nachricht habe ich schon die ganze Zeit gewartet!!! Allerdings dürfte amsPLUS unter einer Erista ipatched mit der SX Core FW 1.3 ebenfalls laufen. Kannst du auch über ArgonNX --> Tools --> Reboot OFW in die Original FW booten?Ja, Reboot OFW hat auch geklappt.
-
Ja, Reboot OFW hat auch geklappt.
Hast du auch alle anderen Punkte der Einrichtung problemlos durchführen können? Insbesondere Punkt 4 mit Incognito RCM? Um das Ergebnis auf Erfolg hin testen zu können, solltest du zunächst den Flugzeug Modus aktivieren, dann über NX-Shell die exosphere.ini aus dem SD-Karten Root in einen beliebigen Ordner verschieben, NX-Shell ordnungsgemäß über
beenden, daraufhin über den Payload Launcher die Konsole rebooten, und dann in den Systemeinstellungen --> Konsole --> Seriennummern --> Konsole überprüfen, ob dort eine SN mit 0001 am Ende ausgegeben wird. -
Hast du auch alle anderen Punkte der Einrichtung problemlos durchführen können? Insbesondere Punkt 4 mit Incognito RCM? Um das Ergebnis auf Erfolg hin testen zu können, solltest du zunächst den Flugzeug Modus aktivieren, dann über NX-Shell die exosphere.ini aus dem SD-Karten Root in einen beliebigen Ordner verschieben, NX-Shell ordnungsgemäß über
beenden, daraufhin über den Payload Launcher die Konsole rebooten, und dann in den Systemeinstellungen --> Konsole --> Seriennummern --> Konsole überprüfen, ob dort eine SN mit 0001 am Ende ausgegeben wird.Das habe ich nicht alles getestet. Incognito ging meines Wissens nicht. Lockpick hat funktioniert. Schaue ich mir nochmal an...
-
Schaue ich mir nochmal an...
Das wäre klasse! Endlich mal jemand, der das auf einer ipatched Erista testen kann. Ich habe leider keine solche Revision, um dies alles testen zu können, daher bin ich dafür sehr dankbar!
-
Das wirft doch alles in ein ganz anderes Licht und du bist nicht auf die eingeschränkten Möglichkeiten der Mariko Hardware angewiesen. Lade dir bitte mal das amsPLUS Paket herunter, und versuche die Einrichtung eines emuMMC damit einmal.
Dann werde ich das gleich mal ausprobieren. Allerdings scheint mir das Paket für unpatched Modelle zu sein, da ich ja mit meiner patched Switch nicht über RCM Jig booten muss, sondern über den SX OS.
Ist es unerheblich wenn ich trozdem die gesamten im Paket enthaltenen Dateien auf die SD Kopiere (inkl. der payload.bin, fusee-primary.bin, ArgonNX etc.) oder kann ich damit noch mehr kaputt machen?
Oder sollte ich lieber paar der Dateien nicht mit auf die SD-Kopieren, falls ja welche genau?
-
Allerdings scheint mir das Paket für unpatched Modelle zu sein
Nein, es hat sich herausgestellt, dass auch ipatched Eristas mit einem SX Core unterstützt werden. Siehe auch die Beiträge über dir. Es war bislang nur noch nicht bestätigt worden, aber grundsätzlich sind die beiden Erista Revisionen, bis auf den gepatchten RCM Bug identisch und der Einstiegspunkt wurde durch den SX Core bei diesen Modellen ermöglicht. Es darf darunter nur keine AutoRCM Funktion aktiviert werden, was aber ohnehin nicht möglich sein dürfte, weil Hekate diese Hardware erkennen würde und somit diese Option automatisch deaktiviert sein sollte. So ist es zumindest unter der Mariko Hardware und dürfte wohl auch auf die gepatchte Erista Hardware zutreffen.
-
Das wäre klasse! Endlich mal jemand, der das auf einer ipatched Erista testen kann. Ich habe leider keine solche Revision, um dies alles testen zu können, daher bin ich dafür sehr dankbar!
Also bis auf Incognito RCM was definitiv nicht geht kann ich bisher keine Probleme feststellen.
Unter Atmo/eMMC wird auch die Seriennummer der Switch nicht korrekt angezeigt, sondern steht auf: XAW00000000000
-
Erista (ipatched) funktionieren genauso wie die Mariko. Hab mehrere hier gehabt und das auch bereits mit Atmos getestet.
Natürlich laufen keine Payloads die über den Tegra RCM Bug laufen, diese müssen wie Lockpick angepasst werden.
-
Natürlich laufen keine Payloads die über den Tegra RCM Bug laufen, diese müssen wie Lockpick angepasst werden.
Das stimmt so nicht ganz, denn ArgonNX ist z.Bsp. nicht kompatibel zur Mariko Hardware, sehr wohl aber unter einer ipatched Erista, wie sich herausgestellt hat.
Also bis auf Incognito RCM was definitiv nicht geht
Wie stellt sich das dar? Wird das Tool nicht gebootet oder wie zeigt sich das?
-
Das stimmt so nicht ganz, denn ArgonNX ist z.Bsp. nicht kompatibel zur Mariko Hardware, sehr wohl aber unter einer ipatched Erista, wie sich herausgestellt hat.
Wie stellt sich das dar? Wird das Tool nicht gebootet oder wie zeigt sich das?
Tool startet problemlos. Aber sobald ich ein Backup vom Sysnand machen will kommt:
Keyblob 0 corrupt - das geht dann bis Keyblob 5
-
Es kommt auf die Anwendung an, Argon ist ja auch nur ein Switcher, der halt eine CFW nach Auswahl bootet, kein so tiefer Eingriff. SX GEAR scheint ja auch zu funktionieren, obwohl der eigentlich nicht für SX Core/Lite erschienen ist. Auch eine Art Switcher der "nur" durchwinkt.
Die CFW SX OS (für die ungepatchten Switches) (boot.dat) funktioniert auch mit SX GEAR und bootet, da könnte man auch z.b Autorcm anschalten und sie für immer Bricken!
Lockpick, incognito haben ja einen recht tiefen Eingriff.
Edit: um die payloads zu booten bedarf es ja den Payload injector von SX oder man nutzt den von Hekate oder eben SX GEAR.
Startet hier ArgonNX.bin direkt per SX GEAR? oder wie habt ihr es gestartet?
Auch nicht zu vergessen ist das neue Display welches die Mariko mit sich bringt + die CPU. Meist logisch das es hier nicht funktioniert, durchaus aber auf einer ERISTA gleiches Modell.
-
Tool startet problemlos. Aber sobald ich ein Backup vom Sysnand machen will kommt:
Keyblob 0 corrupt - das geht dann bis Keyblob 5Ok! Danke! Dann werde ich unter Punkt 4 der Anleitung noch einen Hinweis hinzufügen, dass ipatched Eristas kein Incognito RCM anwenden dürfen. Im Grunde ist ja auch mit dem nativen Incognito Modus durch exopshere bereits der gleiche Effekt gegeben. Verschiebe aber die "exosphere.ini" jetzt bitte wieder in den Root der SD-Karte, falls noch nicht geschehen.
-
Ok! Danke! Dann werde ich unter Punkt 4 der Anleitung noch einen Hinweis hinzufügen, dass ipatched Eristas kein Incognito RCM anwenden dürfen. Im Grunde ist ja auch mit dem nativen Incognito Modus durch exopshere bereits der gleiche Effekt gegeben. Verschiebe aber die "exosphere.ini" jetzt bitte wieder in den Root der SD-Karte, falls noch nicht geschehen.
Oh cool - das mit der exosphere.ini kannte ich gar nicht - das erklärt ja auch die XAW000 Seriennummer
Das bedeutet aber auch, das Incognito_RCM gar nicht mehr benötigt wird - wäre es nicht sinnvoller das Tool aus amsPlus zu entfernen ? Hat doch gar keinen Mehrwert mehr oder ?
-
wäre es nicht sinnvoller das Tool aus amsPlus zu entfernen ? Hat doch gar keinen Mehrwert mehr oder ?
Nunja, solange es supportet wird, hat es m.E. schon seine Berechtigung. Denn so wird der emuMMC dauerhaft und absolut in den Incognito Modus versetzt und kann nicht mehr versehentlich davon befreit werden, was ja auch zweckmäßig für einen emuMMC ist. Wenn du jetzt die exosphere.ini versehentlich löschen würdest, wäre der Incognito Schutz dahin! Das würde einen emuMMC, der unter Incognito RCM in diesen Zustand versetzt worden wäre, nicht in dieser Schutz Funktion beeinträchtigen.
-
und vergiss nicht; 90DNS einzusetzen, damit im fall eines "Vergessens" dennoch ein Schutz aktiv ist
-
muxi habe jetzt mal das amsPLUS Paket auf die SD Kopiert und habe Hekate ausgeführt und darüber wie in der Anleitung beschrieben ein emuNAND erstellen lassen. Anschließend noch in Hekate unter Payloads die Reboot_to_ArgonNX.bin ausgeführt. Allerdings Kann ich anschießend trozdem nicht im Argonnx Menü Atmosphere starten -> Blackscreen.
Unter dem Punkt Tools -> Reboot OFW lässt sich jetzt allerdings wenigstens die OFW starten.
-
Hmm, das ist mir ein Rätsel.....welche FW Version wird dir denn in den Systemsettings der OFW angegeben?
-
FW: 11.0.1
-
Dein sysNand ist auf alle Fälle in Ordnung, sonst würde er sich ebenfalls nicht booten lassen! Also sollte der daraus erstellte emuMMC eigentlich auch fehlerfrei booten. Die einzige Erklärung, die ich noch hätte, wäre eine fehlerhafte SD-Karte. Wenn ich an deiner Stelle wäre, würde ich mir eine neue SanDisk Ultra 400 GB Karte zulegen und damit eine Neueinrichtung durchführen. Eine im GC Slot befindliche GameCard wird sicherlich nicht der Grund dafür sein, dass der erstellte emuMMC sich nicht booten lässt.....
Jetzt mitmachen!
Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!
