CFW amsPLUS - Das einsteigerfreundliche All-in-One Paket (für alle Erista Revisionen)

  • Wenn das Leben doch nur immer so einfache Lösung parat hätte

    Ich hoffe, dass du du auch die entsprechende Option über den Extras_Aktivator zum Löschen des Custom Themes genutzt hast, denn dann hättest du tatsächlich den unkompliziertesten Weg gewählt.;)


    Kann ich da kurzfristig was fixen oder ignorieren?

    Du solltest die Einrichtung nochmal durchführen, aber diesmal bitte korrekt! Dann brauchst du auch nichts kurzfristig zu fixen und hast langfristig eine zuverlässig eingerichtete CFW!


    Also die boot.ini anpassen zu loader.bin? Bisher mit amsPLUS 1.1.1 stand dort auch payload.bin drin. Ist das neu oder auschließlich für Erista v1 Konsolen?

    Es muss und darf nichts an den CFW Daten verändert werden. Das Paket ist unter beiden Erista Revisionen sofort einsatzbereit! Hast du den SX Core denn auch auf Spacecraft-NX geflasht oder nutzt du noch immer die TX Firmware?

  • Ich kenn mich bezüglich sx core nicht so aus aber die neue payload die gestartet werden muss ist die loader.bin vlt kannst du damit was anfangen ;)

    Zum besseren Verständnis, was die Funktionen der loader.bin und der payload.bin des amsPLUS Paketes sind und was sie voneinander unterscheidet.


    Der Payload, der für das grundsätzliche Booten des Bootloaders, also von Hekate verantwortlich ist, ist die payload.bin! Diese Datei wird je nach Modifikation der Konsole auf zwei Wegen angesteuert. Bei Konsolen, die mit einem Modchip versehen sind, also eine Erista v2 mit einem SX Core oder eine Erista v1 mit einem Trinket M0 wird die payload.bin unmittelbar von der SD-Karte über den Modchip geladen und dadurch Hekate gestartet. Bei Erista v1 Konsolen, die mit einem externen Payload-Sender gebootet werden, muss das Ansteuern der payload.bin durch das Senden der loader.bin an die Switch erfolgen. Die loader.bin ist sozusagen nur ein Payload, der bei der Ausführung die payoad.bin auf der SD-Karte ansteuert und somit quasi als Forwarder fungiert. Das Endergebnis ist in beiden Varianten (Modchip und externer Payload-Sender) also identisch, nämlich dass letztlich die payload.bin ausgeführt wird. Nun könnte man sich die Frage stellen: Wenn doch die payload.bin der initiale Payload zum Booten ist, wieso kann man diesen denn nicht in seinem externen Payload-Sender nutzen? Die Antwort ist ganz simpel! Grundsätzlich wäre das zunächst möglich, aber nur bis zum nächsten Update von Hekate! Es geht hier jedoch darum, den Payload in einem Payload-Sender (Dongle oder App) nicht jedes mal aktualisieren zu müssen! Die payload.bin kann sich durch ein Update von Hekate ändern und müsste dann jedes mal wieder im Payload-Sender aktualisiert werden. Da durch das Update von amsPLUS diese Datei auf der SD-Karte immer automatisch aktualisiert wird, müssen sich Modchip User darum keine Gedanken machen. Damit aber auch Nutzer eines externen Payload-Senders die gleichen Vorteile haben, um ihren Payload nicht immer wieder aktualisieren zu müssen, gibt es die loader.bin, die durch das Senden immer die aktuellste payload.bin auf der SD-Karte ansteuert, ohne das sie selbst jemals aktualisiert werden müsste.


    Ich hoffe, dass es einigermaßen verständlich rübergekommen ist:)

  • > Hast du den SX Core denn auch auf Spacecraft-NX geflasht oder nutzt du noch immer die TX Firmware?


    Ja natürlich. Wie geschrieben, habe ich nur ein Update von AMS1.1.1 auf 1.2.4 und die FW von 13.0.0 auf 13.1.0 gemacht, d.h. ich war schon auf Spacecraft & AMS ;)


    Wie auch immer. Ich habe das aktuelle AMS Paket einfach nochmal manuell auf die SD geschrieben und nun bootet alles wieder wie gehabt. Irgendwas scheint beim autom. Update via Skript nicht sauber gelaufen zu sein. (Ja, ich habe micht exakt an Punkt 6 gehalten und den Cleaner vorher ausgeführt).

    Danke nchmal zur Aufklärung der Payloads.

  • Du hast keinen emuMMC eingerichtet! Sowas wird mittlerweile (seit Hekate) direkt bestraft!8o

    Halte dich bitte an die Einrichtungsanleitung!

    Ich komme auch gerade von der Athmosphère XL unter 11.0.1 und wurde aufgrund eines nicht vorhandenen emuMMC's bestraft :ll:

    Habe die Anleitung jetzt 2 - 3 mal gelesen und so langsam kommt das Verständnis.


    Folgende Fragen bis hier:


    Ich bin derzeit auf 11.0.1 mit AtmosphereXL, befolge nun die Anleitung von oben bis unten , erstelle ein emuMMC und in Folge der Anleitung update ich die CFW im emuMMC dann auch mit Daybreak auf 13.1.0 - meine OFW im sysNAND ist dann ja weiterhin 11.0.1 - richtig?

    Wie Update ich dann die OFW auch auf 13.1.0?
    Bisher habe ich seit FW 4 (Auslieferungsfirmware) immer mit ChoiDujourNX direkt aktualisiert und noch keine eFuse verbrannt...

  • Ich bin derzeit auf 11.0.1 mit AtmosphereXL, befolge nun die Anleitung von oben bis unten , erstelle ein emuMMC und in Folge der Anleitung update ich die CFW im emuMMC dann auch mit Daybreak auf 13.1.0 - meine OFW im sysNAND ist dann ja weiterhin 11.0.1 - richtig?

    Ja, das ist richtig!

    Wie Update ich dann die OFW auch auf 13.1.0?

    Möchtest du denn auch Nintendo Services nutzen? Andernfalls wäre das nicht nötig.

    Bisher habe ich seit FW 4 (Auslieferungsfirmware) immer mit ChoiDujourNX direkt aktualisiert und noch keine eFuse verbrannt...

    Dann betreibst du die Konsole offenbar die ganze Zeit unter AutoRCM! Du hättest hier zwei Möglichkeiten:

    Entweder du downgradest wieder auf die zur eFuses Zahl passende FW Version und deaktivierst vorzugsweise anschließend den AutoRCM

    oder du updatest auf regulärem Wege auf FW 13.1.0, nachdem du einen Werksreset durchgeführt hast. Das solltest du aber erst nach der Einrichtung von amsPLUS tun, um etwaig vorhandene Spielstände und installierte Titel für die Nutzung unter dem emuMMC behalten zu können.

  • Hey, ihr schreibt das AutoRCM garnicht mehr notwendig ist, aber wenn die konsole mal aus geht muss diese ja dennoch übern Jig+ Dongle gestartet werden oder? bin auch grad erst auf emuNand umgestiegen(schande über mein haupt ^^) habe alles gemacht. was im Tut steht. hatte vorher auch AutoRCM aktiv da ich sowieso nicht die BigN Services bisher genutzt habe und immer in die CFW gebootet bin.

    Fragen:
    Jig noch nötig?
    AutoRCM sagt ihr nicht nötig. warum? wenn sie aus ist startet sie doch in die OFW.

    Oder hab ich da was übersehen?

  • AutoRCM sagt ihr nicht nötig. warum?

    AutoRCM erspart dir lediglich die Nutzung eines Jigs! Den Payload-Sender brauchst du auch noch weiterhin! AutoRCM ist bei nachlässiger Handhabung der Switch unter diesem Zustand maßgeblich für ein vorzeitiges Ableben des Akkus verantwortlich. Außerdem ist es nicht nötig, den sysNand (OFW) in diesem semigebrickten Zustand zu betreiben, wenn man für die CFW einen emuMMC verwendet (Im Hinblick auf die Erhaltung der eFuses)!

  • Möchtest du denn auch Nintendo Services nutzen? Andernfalls wäre das nicht nötig.


    Derzeit nicht, wollte mir die Möglichkeit aber immer offen halten für den Fall das der Tag mal kommt.

    Dann betreibst du die Konsole offenbar die ganze Zeit unter AutoRCM! Du hättest hier zwei Möglichkeiten:

    Entweder du downgradest wieder auf die zur eFuses Zahl passende FW Version und deaktivierst vorzugsweise anschließend den AutoRCM

    oder du updatest auf regulärem Wege auf FW 13.1.0, nachdem du einen Werksreset durchgeführt hast. Das solltest du aber erst nach der Einrichtung von amsPLUS tun, um etwaig vorhandene Spielstände und installierte Titel für die Nutzung unter dem emuMMC behalten zu können.


    Ja genau, AutoRCM ist aktiv, könnte ich aber auch raus holen, die Konsole ist sowieso nie ganz aus.
    Auf regulärem Weg auf 13.1.0 Upzudaten ist aber erforderlich um die Online Services nutzen zu können, verbrennt aber auch alle eFuses bis dorthin, oder?

    Andererseits Frage ich mich wofür ich auf die zu den eFuses passende Firmware Downgraden sollte, damit könnte ich nie aktuelle Spiele spielen und einen Nachteil an einer aktuellen Firmware wüsste ich jetzt nicht.


    Ich Prinzip könnte ich die OFW säubern mit dem Werksreset und online schalten.

  • Andererseits Frage ich mich wofür ich auf die zu den eFuses passende Firmware Downgraden sollte, damit könnte ich nie aktuelle Spiele spielen und einen Nachteil an einer aktuellen Firmware wüsste ich jetzt nicht.

    Du kannst unter der OFW zwar nicht die aktuellsten Spiele spielen, sehr wohl aber über den auf der aktuellsten FW befindlichen emuMMC!!

    Ich selbst nutze u.a. eine Erista v1 mit OFW auf FW 1.0.0 und emuMMC auf 13.1.0!

  • eFuses werden aber nur beim Up-/Downgrade verbrannt, oder? Wenn ich AutoRCM raus hole und die 11.0.1 OFW Boote passiert nichts?

    Wenn du AutoRCM unter der FW 11.0.1 deaktivierst, wird die gebrannte Fuseszahl auf 14 angehoben! Solltest du auf der ursprünglichen Fuseszahl bleiben wollen, musst du vor dem Deaktivieren des AutoRCM erst auf die entsprechend niedrigere FW downgraden! Sollte deine ursprüngliche FW Version 4.x.x gewesen sein, würde die Fuseszahl aktuell auf 4 stehen. Dann müsstest du auf eine FW zwischen 4.0.0 und 4.1.0 downgraden. Nun musst du entscheiden, was du tun möchtest.

  • Wenn du AutoRCM unter der FW 11.0.1 deaktivierst, wird die gebrannte Fuseszahl auf 14 angehoben! Solltest du auf der ursprünglichen Fuseszahl bleiben wollen, musst du vor dem Deaktivieren des AutoRCM erst auf die entsprechend niedrigere FW downgraden! Sollte deine ursprüngliche FW Version 4.x.x gewesen sein, würde die Fuseszahl aktuell auf 4 stehen. Dann müsstest du auf eine FW zwischen 4.0.0 und 4.1.0 downgraden. Nun musst du entscheiden, was du tun möchtest.


    Ja das macht Sinn, deswegen habe ich bestimmt auch AutoRCM aktiviert:ll:
    Scheinbar bin ich jedoch erst bei OFW 6.2.0 zur CFW gewechselt wenn ich das richtig interpretiere

    Dann würde ich tatsächlich auf 6.2.0 runter gehen, heisst Ablauf in dieser Reihenfolge (?) :


    1. Downgrade auf OFW 6.2.0 (Einfach die OFW 6.2.0 mit ChoirDujour installieren so wie ich bisher auch Updates durchgeführt habe?)
    2. Deaktivieren von AutoRCM
    3. Die 5 Punkte Anleitung des Startposts abarbeiten
    4. Sich über eine bedeutend sicherere Switch freuen :)


    Kommt das so hin?

  • Heyho.

    Ich glaube ich habe mir irgendwo selbst ne Falle gestellt... Tinfoil läuft nicht mehr mit "Micro SD Fehler". Alles andere läuft einwandfrei, auch über Hekate Menü auf die SD zugreifen und Datenaustausch. Tippe auf Sigpatches, und hatte dann mit NX Shell die beiden Patches Ordner und noch ein File aus atmosphere Ordner gelöscht. Die Daten waren in der Sigpatches ZIP wieder neu drin. Hab die aufgespielt aber es hat nix gebracht. Alles an sich läuft ausser tinfoil. Aktuell CFW 12.1E, OFW keine Ahnung. Hatte versucht die CFW per AIO und daybreak auf 13.1 zu updaten, aber irgendwie klappte das nicht. Hab dafür jetzt im Konsolenmenü "Bereit zur Installation" stehen.. ? An sich nicht wild, aber bei allem was ich starte muss man nochmal extra "Software starten" wählen, ist nervig. Wo hab ich mich ausgetrickst? :/

  • 1. Downgrade auf OFW 6.2.0 (Einfach die OFW 6.2.0 mit ChoirDujour installieren so wie ich bisher auch Updates durchgeführt habe?)

    Nein! Du solltest das aktuellste amsPLUS Paket und Daybreak für den Downgrade verwenden!!!! Alle anderen von dir aufgeführten Punkte passen!

    Hatte versucht die CFW per AIO und daybreak auf 13.1 zu updaten, aber irgendwie klappte das nicht.

    Logisch, dass das nicht funktionieren kann!! Halte dich bitte an den Spoiler Nr 6 im Titelpost für das Update von amsPLUS! Tinfoil ist kein Bestandteil von amsPLUS und wird hier im Thread auch nicht supportet.

  • Nein! Du solltest das aktuellste amsPLUS Paket und Daybreak für den Downgrade verwenden!!!! Alle anderen von dir aufgeführten Punkte passen!

    Ist den daybreak bis dieser fw kompertiebel haben mal wo gelesen das daybreak nur bis 8.1 geht ? War aber nicht hier im Forum 🤔

  • Ist den daybreak bis dieser fw kompertiebel haben mal wo gelesen das daybreak nur bis 8.1 geht ?

    Das wäre mir neu! Soweit mir bekannt, ist grundsätzlich ein Downgrade bis einschl. FW 2.3.0 möglich. Die FW 8.1.1 ist auch keine reguläre FW Version der westlichen Hemisphäre, sondern lediglich nur auf chinesischen Konsolen zu finden.

  • Das wäre mir neu! Soweit mir bekannt, ist grundsätzlich ein Downgrade bis einschl. FW 2.3.0 möglich. Die FW 8.1.1 ist auch keine reguläre FW Version der westlichen Hemisphäre, sondern lediglich nur auf chinesischen Konsolen zu finden.

    Ok hatte es nur mal gelesen auf dieser dashtherme Seite wo man auch die fw herunterladen konnte zufällig drauf gestoßen ;) vlt meinen die nur die fw 8.1.1 😅

  • Oh, alles anders als zuvor

    Es hat sich eigentlich nichts an der grundlegenden Vorgehensweise geändert, aber du musst schon die im Paket zur Aktualisierung enthaltenen Tools verwenden. Der AIO Updater ist weder im Paket enthalten, noch für amsPLUS geeignet, da er die individuellen Daten Strukturen nicht übernimmt und so das System lahmlegen würde. Der amsPLUS Downloader/Tegra Explorer ist schon immer für das Update von amsPLUS vorgesehen und sollte auch dafür genutzt werden!

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!