mal ne Frage an die Freunde des guten alten MC68000:
Ich habe hier ein Gerät mit einem 68000 dessen Firmware ich disassembliert vorliegen habe. Die Firmware bietet die Möglichkeit über einen eingebauten Bootloader eigenen Code ins RAM zu laden und von dort auszuführen (es wird mit JSR an die angegeben Stelle gesprungen). Leider funktioniert das relativ leidlich bzw. habe ich so komische Effekte wie den folgenden.
Es existiert eine kleine Funktion im EPROM bei 0x4ad508 um das Statusregister ins RAM zu sichern:
004ad508 40 f9 00 11 34 9c move SR,(0x0011349c)
004ad50e 00 7c 07 00 ori #0x700,SR
004ad512 4e 75 rts
Wenn ich diese Funktion mit JSR $4ad508 aufrufe stürzt das System ab. Baue ich die Funktion jedoch nach und rufe sie an der neuen Adresse auf funktioniert alles einwandfrei.
Wenn ich diese Funktion mit JSR $4ad508 aufrufe stürzt das System ab.
Baue ich die Funktion jedoch nach und rufe sie an der neuen Adresse auf
funktioniert alles einwandfrei.
Konntest Du den ins RAM geladenen Code wieder erfolgreich zurücklesen?
Schreibt Dein Bootloader byte- oder wortweise?
Falls byteweise, ist das RAM im Zielbereich byteweise decodiert, also werden /UDS und /LDS ausgewertet?
"ist das RAM im Zielbereich byteweise decodiert, also werden /UDS und /LDS ausgewertet?" - ja!
"Weißt du was zu den Hintergründen über die Original Funktion?" - nicht wirklich. Sie wird von eine anderen Funktion aufgerufen die ich gerne verwenden würde
"SR modifizieren nur im Supervisor-Mode" - gutes Argument was jedoch nicht erklärt warum ich die gleiche Manipulation im SR in eigenem Code, der im RAM läuft, machen kann
Eine andere Funktion ohne die SR Manipulation macht die gleichen Probleme. Es sieht aus als ob irgendetwas nicht will das ich Code aus dem EPROM-/FLASHbereich ausführe. Ich habe beispielsweise zwei quasi identische Funktionen die einen Ton ausgeben. Die eine ist vom Bootloader und läuft im RAM und die andere gehört zum Gerät selbst und ist im EPROM/FLASH. Die im RAM kann ich aufrufen, die andere nicht.
Wenn ich diese Funktion mit JSR $4ad508 aufrufe stürzt das System ab.
Da musste mal spezifischer werden und gerade die vielen Exceptions des MC68k bitten viele Möglichkeiten "System-Abstürze" ein spezifische Erscheinungsbild zu geben.
Falls es wie bereits genannt eine Exceptions wegen Verletzung des Supervisormodes ist, sollte das durch die angesprungenen Addresse während des Absturzes deutlich werden. Busfehler wäre auch so erkennbar.
Bei JSR ist im Unterschied zu JMP noch der "Zustand" des stacks wichtig und wenn ich die mnemonics richtig interpretiere werden in dem Schnipsel die Interupt Mask bits gesetzt. Falsch initialisierte Ineterrupts sind auch ein "Quell ew'ger Freude" ;-)
Die eine ist vom
Bootloader und läuft im RAM und die andere gehört zum Gerät selbst und
ist im EPROM/FLASH. Die im RAM kann ich aufrufen, die andere nicht.
Dann schau dir mal den Adressdecoder für die einzelnen Chipselects CS an.
"ist das RAM im Zielbereich byteweise decodiert, also werden /UDS und
/LDS ausgewertet?" - ja!
Ein Tipp: das Forum bietet zwei Zitierfunktionen:
Text markieren und auf "Makrierten Text zitieren" klicken
den gesamten Post zitieren mit "Antwort mit Zitat"
Der Gimmick ist, dass dann ein Link zum zitierten Post eingefügt wird. Aber wie man einen Post über diesem hier sieht: das schaffen selbst einige langjährige Forenmitglieder nicht...
Die Funktion ist durchaus bekannt aber soll ich drei Posts erzeugen nur weil bei jedem der drei Posts auf die ich reagieren will nur einmal markieren und zietieren kann?
Der Gimmick ist, dass dann ein Link zum zitierten Post eingefügt wird.
Aber wie man einen Post über diesem hier sieht: das schaffen selbst
einige langjährige Forenmitglieder nicht..
Man lernt nie aus. Das ist mein Kommentar in der selben Zitatzeile.
Lothar M. schrieb:
Man lernt nie aus.
Das ist mein Kommentar in einer neuen Zeile.
Eine Leerzeile ist nicht nötig. Ein Zeilenumbruch reicht, wenn es kein "zitiertes Zitat" ist, denn sonst geht es (zumindest in der Mobilansicht) schief... :-/
Oder kurz:
mit 1 > am Zeilenanfang braucht es keine Leerzeile
Hab es grade mal in deinem letzten Post "probiert": es funktioniert auch
dort.
Prinzipiell ja - nur - mach mal was anderes als schnell mit der Maus herunterscrollen bei der Seite. Sogar den Scrollbalken zu nutzen könnte schon zuviel sein.
Könnte auch am Browser liegen (Firefox) - jedenfalls habe ich Mühe, dass beim Zitat-Kopieren, wenn ich unten angekommen bin (mit dem Mauszeiger) nicht gleich die Kopie des ganzen Artikels in der Antwort liegt.
Wenn ich aber hier auf der Seite nach ganz oben gehe, Antworttext markiere und auf die Zitat-Antwort klicke, da lande ich sofort unten mit dem Zitat in der Antwortmaske. Das funktioniert allerdings bei den Artikeln nicht, und so muss man halt (oder muss ich) weit von Hand runterscrollen.
Das stört insbesondere dann, wenn die News-Artikel länger sind als üblich.
Ein Tastendruck (zwei Tasten gleichzeitig) springt ans Seitenende, ein anderer an den Seitenanfang. Nervig ist anders.
Allerdings: Die Forensoftware springt schon an die vermeintlich richtige Stelle, bevor sie den Artikel fertig geladen hat, und da keine Platzhalter für Bilder verwendet werden, scrollt einem die "richtige" Stelle nach unten weg, wenn nach und nach die eingeblendeten Bilder geladen werden.
Das ist nervig, aber ich habe nicht den Eindruck, als hätte Andreas viel Lust, noch irgendwas an der Forensoftware zu ändern. Diskussionen über dies und das, was alles nötig wäre, gabs hier schon vor über 15 Jahren ...
Immerhin schreibt jetzt jemand häufiger Artikel, auch wenn Tams Wortwahl manchmal sehr merkwürdig ist, ist das zu begrüßen.
Der Mann ist halt ein in Ungarn lebender Syrer, der hantiert mit mehr verschiedenen Sprachen als die meisten von uns hier.
Ein Tastendruck (zwei Tasten gleichzeitig) springt ans Seitenende, ein
anderer an den Seitenanfang. Nervig ist anders.
Ich weiß jetzt zwar nicht wie du das meinst (welche Tasten?) - aber wenn ich den nach unten Cursor gedrückt halte, und dann bei der Stelle mit dem "Markierten Text zitieren" klicke, dann landet zumindest nicht der ganze Artikel in der Antwort.
Immerhin schreibt jetzt jemand häufiger Artikel, auch wenn Tams Wortwahl
manchmal sehr merkwürdig ist, ist das zu begrüßen.
Ich finde das auch sehr gut, so gibt es immer ein paar interessante Neuigkeiten und kein Gestreite ;)
Allerdings bleibt einiges eher oberflächlich - beispielsweise bei dieser "Rust-Hardware" könnte man den Entwicklern und den Verkäufern auf der Messe schon etwas mehr ein Loch in den Bauch fragen ;)
Die KI hat mir diesbezüglich (also wenn die Artikel wieder mal nur andeuten) schon etliche gute Zusammenhänge aufgezeigt. Zuletzt hatte die KI (jetzt kein Technik Bezug, aber egal) sogar einen wirtschaftlichen Zusammenhang bei den Exporten aus Deutschland nach Iran und Israel aufgezeigt. Während Israel viel Waffen bekommt, importiert der Iran Getreide aus Deutschland. Netter Unterschied oder?
Gut möglich das es nicht im Prozessor an sich liegt sondern am System aus Prozessor und Speicher-devices. Insbesonders da erst dargestellt wird, im System wäre vorgesehen, das initial ROM-Inhalt in den RAM kopiert wird und anschließend im RAM (jsr [RAM-Addresse]) ausgeführt.
Dagegen versucht der TO erfolglos Programm-Code direkt vom EEPROM auszuführen, also ohne vorheriges Kopieren zum RAM (JSR [ROM-Adresse]), neudeutsch XIP (Execute in Place).
XIP ist nicht selbstverständlich, erst recht nicht zu Zeiten des MC68000 (Achtziger/Neunziger). Firmware ins ROM kopieren galt als schneller, manche ROM's der damaligen Zeit, insbesonders die EPROM's hatten schon mal Zugriffszeiten um 500 ns, würden also den Prozessor auf ca. 2 MHz einbremsen.
Die Bus-Zugriffs Signale unterscheiden sich jetzt nicht ob Daten- oder Befehls-Holen, spontan fallen da nur die drei FCO Outputs auf, die aber nur Status sind und nicht notwendigerweise Buszugriffe steuern.
Also es könnte schlicht so sein, das das System nicht ausgelegt ist, (beliebigen) Programmcode aus dem EPROM direkt auszuführen sondern das es erst in den RAM kopiert werden muss, aus dem RAM heraus funktioniert es ja. Schaltplan o.ä. wäre hilfreich.
Beispielsweise könnten die erwähnten FCO-Signale bei dem nicht näher benannten System mit den Steuersignalen für ROM und RAM verbunden sein. Man kann so den Adressbereich über 16Mb hinaus erweitern und ohne MMU eine Speicherverwaltung auf bauen. Im Anhang eine Realisierung mit 74LS138 (aus ISBN: 3-89362-080-X)
Offtopic:
Von den vorhergehenden 18 Beiträgen beschäftigen sich sechse (inkl. Eingangs-Frage) mit dem Thema und elf drehen sich lediglich um eine Moderator-genehme Form von Beiträgen.
Effizientes Arbeiten am Thema geht anders.
Da müssten TOs dann aber auch viel mehr mitmachen.
Nützt ja nicht viel, wenn man oft im Peephole-Modus auf Zusammenhänge schließen muss. Da hilft ja oft das Horchen auf der Motorhaube beim Auto, wenn was nicht stimmt viel besser weiter.
Eine eigene Frage?
Dieser Thread ist über 7 Monate alt.
Stell sie in einem eigenen Thread – dort lesen mehr Leute mit, und sie wird öfter und schneller beantwortet.
